|
Viewing 1321 to (2126 Total) |
|
My apologies! I'm not sure why I didn't catch the fix that was posted in this thread.
I just committed it to SVN. I'll try and boot Linux and see how it behaves
Posted on February 23, 2012 at 4:07 PM
|
|
It looks like this is an issue which appears if you try to compile for "armv6" and "armv7" at the same time.
I just made some small modifications to my makefile, using an $(ARCH) variable. I was able to compile for armv6 first, then armv7, and to use "lipo" to package them together into one fat static library:
lipo -output libz.iphoneos.a -create -arch armv6 libz.armv6.iphoneos.a -arch armv7 libz.armv7.iphoneos.a
This may be a good solution for SDL static, and might be handled more elegantly (since I'm not real experienced with makefiles). If it were simpler to support in HXCPP, I might suggest that we build for armv6+armv7 by default for iOS, but if we are going to move to OpenGL ES 2.0 this may be moot, since we would need armv7 only, anyway.
I vote to store "fat" libraries in sdl-static, and at least support an "armv6" flag in HXCPP:
<flag value="armv6" if="armv6" />
<flag value="armv7" unless="armv6" />
This provides the ability to compile for armv6 on demand, which could be linked by hand for a release. By default, however, we'll at least support armv7, which is a requirement to target iOS 4.x or 5.x as the minimum OS, and which is the only device architecture used by default in newer copies of XCode.
(I can gladly share my "fat" versions of the sdl-static libraries, but that probably isn't necessary?)
Posted on February 23, 2012 at 11:14 AM
|
|
Also, I would double-check to be sure that you have added an <icon /> node with the size of icon your device is expecting
Posted on February 23, 2012 at 10:30 AM
|
|
I'll try and build off the GM2D SVN from now on. That probably explains some of the SVG compatibility issues that have cropped up
Posted on February 23, 2012 at 10:15 AM
|
|
Are you using NME 3.2, and using <haxelib name="sqlite" />, with no additional <ndll /> or <extension /> nodes?
Posted on February 22, 2012 at 10:13 PM
|
|
Well, it shouldn't be something you have to think about, much. When you run "nme setup android" it will prompt you to install "SDK Platform-tools" and "API 8" from the Android SDK manager. When you have your dependencies set up, NME should just work automatically for you 
Posted on February 22, 2012 at 3:19 PM
|
|
Android uses different "API levels" depending on the minimum version of Android OS you are targeting.
NME is designed to support Android 2.1 or greater, which is actually API 7. However, in order to enable installation on the SD card, there is an extra property that is available in API 8 which is backward compatible with 2.1 devices (API 8 is for 2.2 devices)
Theoretically it may be possible to always use the latest API for old devices, but I have a feeling that could lead to trouble.
Posted on February 22, 2012 at 3:10 PM
|
|
The DPI scale property is only populated on iOS, which has an actual DPI scale property. In the case of other platforms, you can check Capabilities.screenDPI, which is more robust, and make your own determinations on screen scale.
I've thought about populating the DPI scale property using a formula like the one I'm about to share, but I'm not sure. It sort of depends on how many levels of scale you wish to support.
Here is an example of how you can check Capabilities.screenDPI (cross-platform) to decide on a screen scale:
http://gist.github.com/1762072
Posted on February 21, 2012 at 11:11 AM
|
|
You can also play with toggling cacheAsBitmap, which toggles whether NME will use the hardware renderer or software. You may get faster results from using the software renderer for certain shapes
Posted on February 21, 2012 at 10:46 AM
|
|
Yes, NME does support hardware-based convex drawing, now (added in NME 3.2). It's a little rough looking for curves, but should absolutely be fine for debug drawing
Posted on February 21, 2012 at 10:45 AM
|
|
Great! So it's working for you guys now?
I set up the SQLite add-on to use "sqlite3" instead of "sqlite" because it creates a conflict on platforms like Android, which would load their own copy of "sqlite.so" instead of loading the haxe-ified version. It isn't until later versions of Android that you actually can specify that you want to load your local library first.
Posted on February 21, 2012 at 10:44 AM
|
|
If you call Lib.exit () on Android, it will call System.exit () underneath. Lib.exit () is kind of nice because it works on more platforms using the same API.
All of the things I see for iOS shows that they recommend that you do not quit your application yourself. Apparently there is a property you can set in your info.plist which specifies that the application should close when the user presses the home button.
Personally, if Apple accepts applications which do make a system exit, and there don't appear to be issues, then I'm behind having our own exit call. Please let me know how System.exit () behaves differently than Lib.exit (), which should trigger a "graceful shutdown" rather than killing the whole process.
If Lib.exit () doesn't work as expected, we can try and improve the behavior, or switch to System.exit () for iOS. Thanks for your help
(Oh, by the way, if you want to exit an Android application using the back button, here's a little recipe:http://gist.github.com/1877209)...
Posted on February 21, 2012 at 10:26 AM
|
|
Yes, currently "sudo haxelib run nme setup" assumes that "/usr/lib/haxe" is your haxe directory. I apologize that this isn't a little smarter.
There is an "nme.sh" file in /tools/command-line/bin inside the NME directory. It's a simple little script that makes it so you can run "nme" instead of "haxelib run nme"
Please feel free to copy the script to where you feel comfortable (like ~/lib/haxe/nme) and then if necessary, create a symlink somewhere like /usr/bin/ or /usr/local/bin, or you could just put the shell script (without the extension, and flagged as executable) in one of those directories, directly. Or just add it to your path.
There's a few options here, but understanding that this script is all the "haxeilb run nme setup" command currently does should probably be of help?
Posted on February 20, 2012 at 11:38 AM
|
|
Hi!
I updated the SQLite library for NME 3.2, but it appears that I forgot to submit it to haxelib.
Please upgrade to 1.06 by running "haxelib upgrade" from the terminal. Then it should work if you add <haxelib name="sqlite" ></haxelib> to your project's NMML. Please let me know if it works for you!
Posted on February 20, 2012 at 11:29 AM
|
|
If it is an empty keyframe, it would normally disappear in Flash, right?
The way to avoid this would be to have a keyframe on the first frame, but to allow it to extend through "over", right? Does that work?
NME on SVN was changed to use armv7 instead of armv6 for iOS builds. I released an "NME 3.2.1" beta today which includes compiled binaries for NME and an updated version of HXCPP. It'll be a little bit awkward to use SVN until sdl-static gets updated with armv7 libraries, unless you modify and run the makefile there.
Posted on February 17, 2012 at 6:31 PM
|
|
Interesting. So this is both an issue of display order and incorrectly assigning instance names?
Posted on February 17, 2012 at 6:28 PM
|
|
Upgrade to SWF 1.08
Posted on February 17, 2012 at 5:22 PM
|
|
It should be reusing Shape instances already, so I don't think (maybe I'm wrong?) it is calling the draw APIs over and over. Is that what you were asking about, or were you talking about the actual render step of Flash or NME, in displaying those shapes?
BTW, I'd also love to hear if buttons are working for you. I added support in SWF 1.08 and NME 3.2.1 Beta, but I haven't used it enough to know if it covers every possible button
Posted on February 17, 2012 at 3:42 PM
|
|
Okay, that's where I would start. I often use "flash", then "windows -neko", then "windows", since Flash, then Neko, then C++ for the desktop, compile fastest and give me the shortest "round trip" between testing code and seeing the result.
There's some debugging support in HXCPP, but I don't fully understand it (unfortunately!), but if you comment off your code and throw in some trace statements, it should not be too hard to find where the application breaks. I have to admit that print/trace statements are how I debug applications, even when I have a debugger I do so out of years of habit. If it works in Flash, then works for your desktop, then you should be pretty sure it will work for mobile, too.
Posted on February 17, 2012 at 3:34 PM
|
|
This can either be handled in NME's rendering, or by committing the object to a bitmap with code.
Currently, NME will render the object again if it moves to a position other than even pixels, rotates or changes size. This is probably similar to Flash.
If it is drawn to BitmapData, then (obviously) these changes will be possible without requiring another render. If the library did this automatically, it probably would be a combination of setting child objects to visible=false, and adding a bitmap copy of the contents
Posted on February 17, 2012 at 2:59 PM
|
