|
Viewing 181 to (2181 Total) |
|
The NME 3,5.5 release installer should also include Neko 1.8.6
Posted on March 03, 2013 at 9:16 AM
|
|
Instead of adding an "import" at the top, it might be able to address the full name of the class, and surround it with calls, based on the OS version of the device. I wonder if that would work, still using API 8? Otherwise, it may be necessary to target API 9, but I'm concerned that may make it easy to accidentally include content that won't run on older versions.
Based on the statistics, it would appear that we support 99.8% of Android devices actively in use. If we move to API 8, we move to 97.6% of users, and API 9, 89.5%
This is not-withstanding losses we may have based on GLES2 support (which probably coincides with API 8 or 9 devices)
It will be cool if we can handle the joystick input without altering the key codes, because I believe catching the Android back button is currently dependent on that code.
This is working fine with the JoystickEvent class, dispatched from the stage, now? Do you think this class is fine, or do you think there are ways it could be improved? I'm considering a minor rewrite, since we're targeting a new version of NME to coincide with Haxe 3, which will give an opportunity to make breaking changes... not for kicks, but if it should be more polished for the future.
Posted on March 02, 2013 at 8:51 PM
|
|
Interesting, should we generate black launch screens for any image sizes you do not include on your own?
Posted on March 02, 2013 at 9:27 AM
|
|
That's weird. It looks like it's picking up two copies of crtbegin?
Which Android SDK and NDK are you using?
Posted on March 02, 2013 at 3:26 AM
|
|
Hi,
I am sorry, I forgot a step.
Run "sudo haxelib run nme setup" to install the "nme" command alias
It sounds you need to build the native library for Mac? The NME command-line tools rely on the library for your current platform in order to run.
Run "nme rebuild mac"
I accepted your pull request, but InputDevice is not available until API 9. I'm wondering if there's some way we can put it inside conditional code, based on the API we are targeting, or if we should do an OUYA-specific flag, or consider targeting a new base version. We currently support Android 2.1 and greater, although the next release may have to be Android 2.2 and greater, because of OpenGL ES 2. Still need to determine if GLES2 can be required by default or if we are going to have to include multiple binaries (or find a way to link GL dynamically?)
Anyway, I commented out a few things under MainView.java in order to get things to compile, but the bindings appear to compile fine 
You should be able to uncomment the lines and keep working with it. I found someone today who has an OUYA around here, so I may drop by there (next week?) to try it
Posted on March 02, 2013 at 3:10 AM
|
|
Can you look at the output and see if it appears to be picking up a Java 6 JDK, or if it is pointing to Java 7 or a JRE?
Posted on March 01, 2013 at 10:01 AM
|
|
NME 3.5 introduced a new object called "OpenGLView", which provides a flexible DisplayObject that allows direct OpenGL calls.
wighawag has been working on a Stage3D compatibility layer. There is a sample he created, "23-Stage3D", that is included with NME, that I believe should work on the desktop. In 3.5.5, OpenGLView is available for both the desktop and for WebGL. Our next release should be enabling OpenGLView for mobile, and work has continued on the compatibility layer to support more features.
If you would like to use OpenGLView directly, it may offer more flexibility than using the Stage3D API. You can try "nme create SimplOpenGLView" or "nme create HerokuShaders" for examples.
Otherwise, a good step may be to get your AS3/Stage3D engine running on Haxe, still targeting Flash. Then closing the gap on using the NME/Stage3D layer will be a lot simpler, and provide a reference so we can make sure that the Stage3D layer is solid and complete.
Please let me know if you have more questions, or anything I can do to help make this possible!
We also provide the "drawTiles" API for batched 2D rendering, which gets very fast performance, without having to use a Stage3D-like API. "drawTriangles" should also perform well on native platforms
Posted on March 01, 2013 at 8:32 AM
|
|
Are you trying NME 3.5.5 using Haxe 3?
NME 3.5.5 is only compatible with Haxe 2 and Neko 1.8.6 right now.
The development builds are currently compatible with Haxe 3 and Neko 2, so whether you want a final release of NME, or you want to be able to use the latest Haxe 3 RC, you can decide what you want to have installed right now
Posted on March 01, 2013 at 8:24 AM
|
|
HXCPP 3.0 has improvements that make it compatible with Haxe 3. It also rolls up all the improvements that were made since the previous 2.10 release on haxelib, which were represented by 2.10.1, 2.10.2 and 2.10.3, bundled with various NME releases.
In my experience, HXCPP 3.0 appears to be a safe upgrade whether you are using Haxe 2 and NME 3.5.5, or you are using Haxe 3 and the development builds of NME
Posted on March 01, 2013 at 8:23 AM
|
|
In the development builds, we have moved from Haxe 2 compatibility to Haxe 3.
If you can install Haxe 3 and Neko 2, you should be able to compile. The error above comes from a change in Haxe 3, so "implements" is used without a comma, "class MyClass implements MyInterface implements MyOtherInterface" rather than "class MyClass implements MyInterface, implements MyOtherInterface"
Posted on March 01, 2013 at 8:19 AM
|
|
Cute! I love it
Posted on March 01, 2013 at 8:08 AM
|
|
Try it in the command-line, like "nme test windows -debug"
Posted on February 28, 2013 at 9:59 AM
|
|
There is a lot of work going for UI, but a lot of the projects are newer, so they haven't matured yet to a full solution.
MadComponents looks cool. If you're interested, I am more glad to offer advice/help when it comes to moving from ActionScript to Haxe. What do you use for all your graphics? Are they rendered dynamically, does it bitmaps, or is it coming from a SWF?
Posted on February 28, 2013 at 8:20 AM
|
|
Could you try overriding your ApplicationMain.hx, and defining the nme.Lib properties using template values? (::APP_PACKAGE::, ::APP_VERSION::, etc)
Then we can merge your ApplicationMain improvements into the dev builds
Posted on February 26, 2013 at 10:28 AM
|
|
Hi!
I think the NyanCat SWF does not have anything added to the stage. When you pass an empty string, it should try to instantiate the stage. However, you can pass the name of any clip that's been flagged to export to ActionScript, and it should pull that up. For the SWF files that report "no stage", can you try and bring in a named symbol instead, and see if that works?
Posted on February 26, 2013 at 8:39 AM
|
|
I believe those values are defined for C++ or Neko projects, but probably not for Flash or HTML5.
Have you tested it native, to see if it works?
I agree this would be nice to have, and shouldn't be too difficult to define in the Flash and HTML5 ApplicationMain templates
Posted on February 26, 2013 at 8:34 AM
|
|
I am sorry that I wasn't able to wire up some joystick bindings using my gamepad. It looks like, Android supports gamepads only on 4.1? My test device runs 2.3, I haven't bothered upgraded that has seemed like where the majority of the Android market has been.
Hasufel, would it be possible to do a pull request, so I can get your code and make sure it compiles?
I apologize that the source builds have been in transition lately. The next version of NME is going to be designed for Haxe 3 and Neko 2, so building the development builds may require that both are installed. Also, instead of using "../sdl-static" there has been a transition to use "nmedev" off of haxelib to provide the headers and static libraries required to rebuild NME. More information is located on thehttp://github.com/haxenme/NME page
Posted on February 26, 2013 at 8:32 AM
|
|
Could you check ".hxcpp_config" in your user directory, and see if it defines its own JAVA_HOME value? If it does, NME will respect that value over the one defined in your system variables.
Make sure the JAVA_HOME NME is picking up is a JDK. Also, make sure it is Java 6, as I believe Java 7 is not compatible with Google's tools.
Posted on February 26, 2013 at 7:51 AM
|
|
This is done for convenience.
Instead of constantly checking in order to make sure BitmapData is cached (so you don't load the same data more than once), it is, by default, cached on the Assets object, in a Hash (Map) called, I think, "bitmapCache"
If you change levels or know you don't need data anymore, you should be able to clear the value in that cache to allow it to be garbage collected. Otherwise, if you are only going to use a file once, such as a background image, you might flag it not to cache, so you don't have to think about it anymore.
If you have recommendations for improving the API, I'd love to hear your input
Posted on February 24, 2013 at 4:11 PM
|
|
Check to see if you still have HXCPP 2.10.3 set, or if it downgraded you to HXCPP 2.10
Unfortunately, HXCPP has not been updated on haxelib, so "haxelib upgrade" tries to bring you down to the older release. If you still have it installed (use "haxelib list" to check) you should be able to use "haxelib set hxcpp 2.10.3" to set it back.
There were some trace improvements that occurred since HXCPP 2.10 that might be related
Posted on February 22, 2013 at 8:39 AM
|
