|
Viewing 141 to (2128 Total) |
|
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
|
|
Interesting, we listen to the "mousedown", "click" and "mouseup" DOM events. Is it possible one is not dispatching from the browser?
Posted on February 22, 2013 at 8:36 AM
|
|
Thanks, I've just added this in the development builds
Do you know what the "common objects" code was about, that existed before? Does it seem that focus events are dispatching to all the objects it should? I'm not sure if that code was very old (to avoid trying to dispatch to, say, Bitmaps) or if it replicated an important behavior from Flash
Posted on February 22, 2013 at 8:33 AM
|
|
For a while now, I have been thinking about building an official NME editor.
Unfortunately, there is a shortage of good, clean two-dimensional editors, where you can drag-and-drop objects in 2D coordinate space, save the layout and grab it on the other side. Some of the advantages of an official editor, I could imagine assets being from the NME project file automatically, and having tight integration with either "Assets.getMovieClip" or perhaps a new "Assets.getLayout" if it makes sense not to instantiate the child objects at runtime, but instead to define them.
The editor could include some UI to call the NME build, test and clean commands. Some people want a visual button to push when compiling a project, rather than finding a code editor or using a command-line. An official editor could be a place for people to get this button, and could be nice when you are testing graphic changes only.
Is the server component an important feature for your bachelor's degree? It seems to me like an ideal editor would be simple and would not require a server component, but if that is what makes it match what you are hoping to achieve for the project, then I'm happy for all the other things that would come along with it. I think the server component should be optional, but you can do a lot of interesting things (you probably have thought of this already?) using the same codebase (or at least libraries) for both your server and client, since Haxe will cross-compile to PHP, Neko and Node.js for you.
Ideally, adding objects should be drag-and-drop and easy to do, since that's the "bread and butter" of what you'll be doing with a tool. Adding layers or defining custom properties (such as adding weight and friction if you are using a physics engine) would be nice. Eventually I could see an editor supporting automatic conversion, other to combine objects into a tilesheet, to change the output format of an image, or to change format for other assets such as sound, but those could always come later.
As for integration for the project files, it could either be deeply integrated such that adding a new asset path from the editor actually modifies your NME project file, or it could be a read-only relationship, in which case the NME command-line tools should likely expose a variant of the "nme display" command which allows you to get important detail, such as asset files, without trying to process all the complexities of the NME project files
Posted on February 18, 2013 at 8:51 AM
|
|
Glad to hear its working now
Funny that "lies" wasn't a valid argument
Posted on February 17, 2013 at 9:06 PM
|
|
This is a limitation of SDL_mixer, which is currently used for Windows, Mac, Linux, BlackBerry and webOS.
We are in the process of looking to improve the backend audio API before releasing NME 3.6, probably OpenAL, similar to what is used for "sound" on the iOS target.
You can work around this by using a WAV or OGG format file, and allowing it to be embedded as "sound" instead of "music", at least until we are ready with audio improvements
Posted on February 17, 2013 at 8:52 PM
|
|
I believe the HTML5 TextField may support DOM text if you use "htmlText" instead of "text", which may be helpful.
What I would like to see for the HTML5 target is an integrated "DOMDisplayObject" which allows you to custom define your own DOM element tag and control the contents. Currently, most (or all?) of the DisplayObjects (with the possible exception of htmlText or Video) are Canvas.
Your code looks good, but the DIV you create might not be visible if the canvas elements are layering on top of it. I'm not sure if you are using a Haxe 3 development build, and if the use of jQuery has changed, but in Haxe 2.10 you will want to use jQuery as a class in order to use its functionality, as "$" is not a valid symbol for Haxe language references:
new JQuery (".my-selector").append(div);
However, I think most anything you would want jQuery for might be covered, using Actuate or other available functions
Posted on February 15, 2013 at 8:31 AM
|
|
Currently the SWF works for native and Flash, but there is a development library that does provide HTML5 support. I found there was a minor (but difficult to find) that prevents the new library from being used with anything older than Neko 2, which hasn't been released yet.
If Haxe 3 and Neko 2 are released soon, we may be able to pick up development of the new library again
Posted on February 14, 2013 at 12:09 AM
|
|
Try "var h" (type inference) instead of "var h:Header"
The rest looks good
Posted on February 13, 2013 at 11:50 PM
|
|
Use "var h = Assets..." instead of "var header = Assets..." or type it as format.display.MovieClip
The classes are not generated like in previous versions of NME. After Haxe 3 releases I think it should be possible for the returned type to be nme.display.MovieClip, so that may change in the next major version.
Hope this helps!
Posted on February 13, 2013 at 11:47 PM
|
|
If you open a terminal and run "nme trace blackberry", from the directory of your project, does it return any new information?
You can also try adding trace() statements in your code. It will be returned when you run "nme trace blackberry"
Usually this type of issue is caused by trying to access a null value
Posted on February 09, 2013 at 8:39 PM
|
|
Rather than answering things in the forums, I'm going to try and starting populating documentation on these topics. I'm sorry that it hasn't existed.
Here you are:
http://www.nme.io/developer/documentation/conditional-compilation/...
Posted on February 06, 2013 at 10:47 AM
|
|
NME should define the target, the platform type and Haxe defines the target language. Between these defines, most everything you need should be covered:
windows
mac
linux
ios
android
blackberry
html5
desktop
mobile
web
js
cpp
neko
flash
These can be accessed using declarations like "#if blackberry" and "#if (neko || cpp)"
Similar defines (with the exception of the language defines) should be available in NMML as well, for "if" and "unless" attribute values
Posted on February 06, 2013 at 9:25 AM
|
|
I don't have an OUYA, but based on a recommendation I ordered a SteelSeries Free wireless gamepad, which should arrive on Friday.
The nice thing is that it seems to work for the desktop, iOS, Android and BlackBerry.
When it comes I will try and wire up support. With the "extra" pipes it should be simple to integrate support for the OUYA gamepad as well
Posted on February 06, 2013 at 9:09 AM
|
