|
Viewing 421 to (2129 Total) |
|
This has been included in the 3.5.2 release 
Posted on December 31, 2012 at 1:10 PM
|
|
This change has gone out in NME 3.5.2
Please let me know when you get an opportunity to give this a try, and if it resolves the issue
Posted on December 31, 2012 at 1:10 PM
|
|
NME 3.5.2 was just released, and it includes a hack that will assume that a project file with an NDLL called "std", "regexp" or "zlib" without a haxelib is actually going to come from HXCPP. Hopefully this should help prevent unnecessary errors from old project files, and won't cause other problems.
Posted on December 31, 2012 at 1:08 PM
|
|
First, can you tell if the distinction between "LandscapeLeft" and "LandscapeRight" is coming through?
Also, you probably should not store an "initialX" or "initialY" value, but instead remember an offset... for example, in one orientation you may have to rotate the results by 90 degrees. In another, it may be 180 degrees.
If you specify an "initialX" and "initialY", then you'll be basing movement on whatever position the phone was in initially. What if the user was holding it a strange angle?
Worse, when you begin to rotate to a new orientation, it is going to catch the very first moment that it triggered changing the orientation, which might be approximately 90 degrees different than where the user will finish rotating the device to. It might trigger while the device is portrait, just between landscape left and landscape right... make sense?
Give it a try without and see what it does
Posted on December 31, 2012 at 12:59 PM
|
|
What are you using for your windowing?
Have you left <window width="" height="" /> undefined in your NMML, or have you used <window width="0" height="0" />?
NME does not automatically stretch your content if you specify a lower window size than the mobile device, though some mobile operating systems will.
Posted on December 31, 2012 at 12:54 PM
|
|
Sorry about that, it appears that the call to minify was improperly translated from the old tools to the new.
I've just committed an improvement that should fix it. I'm getting an error that my machine cannot find "java", but that might just be me. Not quite sure what's going on there.
If you go tohttp://www.nme.io/builds, you can download a development build of NME. The fix should be r2294. Download a ZIP file, then use "haxelib test path/to/the.zip" to install the development build locally. Let me know if it works now
Posted on December 31, 2012 at 12:32 PM
|
|
I'm not sure if the volume buttons are exposed for use in an application, but perhaps I am wrong.
If there is a way to get the buttons in Java, perhaps we can pass them on, but we would have to decide what key code to use
Posted on December 31, 2012 at 12:14 PM
|
|
Hmm, so I suppose we haven't quite solved the problem of why Windows XP doesn't work anymore.
I suppose I will have to try and get my hands on a license for Windows XP... I don't even have a copy
Posted on December 31, 2012 at 12:13 PM
|
|
It is looking great so far, I love the XP/Ubuntu theming you have done already. I have wondered what the best path for cross-platform UI would be, and I'm inclined to believe that this approach -- A haxe-based UI framework -- plus quality theming -- could be it.
Using macros to compile at build-time rather than run-time is a great idea. Keep going!
Posted on December 31, 2012 at 12:11 PM
|
|
Travis is currently configured to verify features in the HTML5 target. I'm not certain how it works, but the test has not been passing recently -- it wasn't as a result of your contribution.
I believe I have fixed the problem. Would you mind downloading a development build to verify?
If you're already on the source, you can update and try again. Otherwise, try downloading revision 2293 from here:
http://www.nme.io/builds/
You can run "haxelib test path/to/nme-3.5.2-r2293.zip" to install it
Posted on December 31, 2012 at 11:41 AM
|
|
I just committed a patch that should help prevent that error from occurring, but it actually is because your BLACKBERRY_DEBUG_TOKEN variable appears to be undefined.
Before building, try and run "nme setup blackberry" and say that you want to configure a device. That will let you specify (or walk through the creation) of your debug token so you can deploy to a device.
If you wanted to compile for the BlackBerry simulator instead, use "-simulator" when compiling. It should not require a debug token. Otherwise if you wanted to perform a signed BlackBerry build rather than using a debug token, make sure you have <certificate path="to/your/author.p12" if="blackberry"/> in your NMML.
When the certificate node is present it will prompt for a password, and go online to connect to RIM's servers to sign each build. You can add "password" as an attribute if you don't mind having it plain text in your NMML, and don't want to type it. You may desire not to sign each build, though... that's what I do. You can make up your own define, such as "release-sign", and use that in an "if" attribute. Then when you build, add "-Drelease-sign" or whatever you called your custom define, and it will enable those tags in NMML.
Posted on December 31, 2012 at 11:05 AM
|
|
Would someone mind posting a small sample project where a call like 'Assets.getBitmapData ("assets/image.png");' works on one platform (Flash, etc) but fails for OS X? I still can't recreate this.
What version of OS X are you guys using?
Posted on December 31, 2012 at 10:56 AM
|
|
Interesting, so changing to fullscreen during runtime allows OpenGL to continue rendering, but setting fullscreen in NMML causes it to fail on setting the OpenGL mode, and fallback to software instead?
Posted on December 31, 2012 at 10:54 AM
|
|
It's called "rymdkapsel" ... it is a very fun game that hasn't been released quite yet:
http://rymdkapsel.com/
Posted on December 31, 2012 at 10:48 AM
|
|
The installer for NME 3.5.2 includes HXCPP 2.10.3. Unfortunately, HXCPP hasn't been updated on haxelib yet.
Posted on December 31, 2012 at 10:45 AM
|
|
Could you run "haxelib list" and see what version of NME and HXCPP you are running?
If you are using HXCPP 2.10 or an older version of NME there may be problems
Posted on December 30, 2012 at 3:36 PM
|
|
The latest version of HXCPP on haxelib is 2.10, but the version included with NME is 2.10.3
Hopefully haxelib will updated with the current version, soon
Posted on December 30, 2012 at 8:45 AM
|
|
I think you want to use Haxe and NME.
NME provides a basic platform abstraction so you can access graphics, sound, device input and other features with one standard API. NME is also focused on providing support for mobile platforms, which gets a lot trickier than cross-platform desktop can be.
Personally I always use NME without another framework -- it's high enough level that I'm steeped in unnecessary detail, but then I am not forced to use an entity system or some other abstraction I don't prefer. Compare to native C++, NME is already a pretty good level of abstraction. You can add bitmaps, sound, animations and other features with only a line or two of code.
NME supports Linux 32-bit and 64-bit, and if you ever encounter issues I'll be glad to help support it. Linux is an important platform for us.
If you did decide to use a game library, I've heard good things about awe6 and HaxeFlixel. I'm not sure HaxePunk is as bulletproof right now. Personally, I still would recommend trying to get a feel for things without any additional frameworks, but everyone has their own tastes
If you have a strong C++ background, NME might be a great choice for you. There's enough abstraction here to help accelerate the game development process -- focus on your game logic, your game content -- all the things that make your game distinct and unique. If you ever, ever need to do more and dive deeper, the source is all open and is almost entirely written in C++. We would be more than glad if you had improvements you were interested in making, and NME is compatible with C++ extensions, if you wanted to add some additional modular functionality
Posted on December 28, 2012 at 11:41 AM
|
|
Accelerometer and orientation are tricky. Personally, I wish accelerometer input was always relative to the display orientation. I suppose we should be striving to make NME provide that abstraction.
You found the code in "/project/iPhone/UIStageView.mm" for the accelerometer?
It appears that it is using the standard accelerometer events. I'm not sure if there's something else that can be done to ensure the events are reported correctly? Searching for the Objective-C solution to this problem will likely be the answer we need.
Posted on December 28, 2012 at 11:34 AM
|
|
I also just updated the binaries in sdl-static, using Visual Studio 2010, which I believe should restore Windows XP compatibility.
Would you mind updating, and seeing if NME will run on Windows XP again, using the latest revision of sdl-static and NME?
Thanks!
Posted on December 28, 2012 at 11:25 AM
|
