|
Viewing 121 to (2126 Total) |
|
Currently, to use Haxe 3 you must also be using NME development builds. There are directions onhttp://github.com/haxenme/NME if you are interested
Posted on March 05, 2013 at 10:10 AM
|
|
I have just updated the server, so now it can perform development builds again.
You should be able to usehttp://www.nme.io/builds/latest... to get the most recent build. I believe the NDLL should be compatible between this version and NME 3.5.5 if you want to do a direct copy. Of course, you can use "haxelib test" to install the build, but the development builds require Haxe 3 and Neko 2
Before the next release, I am hoping we may be able to update to use OpenAL for all the desktop (and most mobile) targets, but we will have to see.
Posted on March 05, 2013 at 10:04 AM
|
|
Try adding <ios deployment="4.1" /> or whichever version of iOS matches what you are using, and see if it helps.
The default deployment was increased, because new installs of Xcode on Mountain Lion were failing when trying to maintain backward compatibility (like including armv6 in the binaries)
Posted on March 05, 2013 at 12:39 AM
|
|
They might be following an X, Y, Z convention
On my SteelSeries Free, I found that the four standard buttons come through as buttons 0, 1, 3 and 4, I believe. I think this is allowing for other devices which have six (A, B, C, X, Y, Z) buttons.
On the one hand I'm afraid to force a hack, but it's possible that an axis index of 3 or higher could be treated as a new ID. The axis[] array would be the same, so maybe this would still be safe, except for developers who use event.x and event.y but don't check event.id
Posted on March 03, 2013 at 11:22 AM
|
|
When you use your right analog stick, does it come through as axis[2] and axis[3], or does it come through as axis[3] and axis[4]?
If it is the latter, I am considering adding a hack. Instead of providing an axis array, we could assume that anything more than three values must actually be a new physical input, so we forcefully update the index.
So it would come through as ID 1 with an x and y axis, rather than ID 0 as the fourth and fifth axis.
Posted on March 03, 2013 at 9:22 AM
|
|
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
|
