|
Viewing 1 to (2129 Total) |
|
Does <app swf-version="10.2" /> work? 
Posted on May 20, 2013 at 7:21 AM
|
|
I have a fix so your main class always has "stage" defined, but it is not available yet. In the meantime, try Lib.current.stage in the body of a function (requesting it in a static variable may not work)
Posted on May 18, 2013 at 3:53 PM
|
|
Does .scrollRect work?
Posted on May 18, 2013 at 3:52 PM
|
|
I have the problem and fixed the mouse range when using both landscape and portrait on both a BlackBerry Z10 or the Dev Alpha C (which is similar to the Q10), I have not tried a PlayBook but believe that will properly as well.
There were two things going on... the older version of BlackBerry SDL had a patch I made which allowed an environment variable, FORCE_PORTRAIT, to get portrait rendering instead of only landscape. I do not recall which version of BlackBerry SDL 3.5.5 was using, so if this is the version, you need to be sure to use <window orientation="portrait" /> instead of allowing NME to choose portrait by default, since only when you specifically requested portrait did you get the FORCE_PORTRAIT define.
Later, this was improved in the BlackBerry SDL library, allowing portrait and landscape without the environment variable. However the mouse ranges were still being switched when FORCE_PORTRAIT was defined. If this is the version of BlackBerry SDL NME 3.5.5 uses, you should create a template version of your bar-descriptor.xml file, that does not define FORCE_PORTRAIT, so that the mouse range will not be swapped and you will have correct values.
Again, this is fixed on the development builds, so I apologize for the problem. The next release should be fine, but in the meantime, the above should help with getting NME 3.5.5 working as it should
Posted on May 17, 2013 at 8:46 AM
|
|
Hi and welcome!
The Assets class will perform synchronous loading, which usually occurs as requested, but in the situation of Flash or HTML5, there are preloaders automatically added at the start of your application to be sure all asset data is available before starting (so it can then be synchronous). The Loader and URLLoader classes are used for asynchronous loading.
When you create multiple BitmapData objects, they all allocate memory, but usually they can be shared, so you reference an identical BitmapData object from multiple Bitmap instances. In order to provide convenience, the Assets uses a cache (Assets.cachedBitmapData, I think) which maintains references and returns the previously loaded BitmapData object rather than taking more memory.
When you must have an object like this cleared from memory, you either call Assets.getBitmapData with cache set to false, or you go and remove the references on the cachedBitmapData map object, after removing references elsewhere, so it can be garbage collected.
When you create a Float in a function (like test1 above) it will be on the stack, so it will clear once the function exits, so I don't see a problem there. Creating a Sprite instance will be done on the heap, but that still isn't necessarily wrong -- though the most optimized would be to pool your Sprite objects, or to keep them persistent from frame to frame (like maintaining an objects[] array, and updating positions each frame instead of destroying and creating them).
You can generally assume that a local var will be put on the stack, while a class level reference will be put on the heap, though in the case of creating a new class instance, it will be placed on the heap and the pointer will be on the stack.
Posted on May 17, 2013 at 7:14 AM
|
|
I think these are issues that were fixed since 3.5.5
Does it work on HTML5 to listen to contentLoaderInfo for Event.COMPLETE, then to take the event.currentTarget.content field and add that to the display list?
Posted on May 17, 2013 at 7:02 AM
|
|
In the next week you be seeing a new release that supports WebGLView on mobile
There's also an NME 3.5.6 release on the new haxelib, for those who are using Haxe 3 RC2, which should support everything but iOS for WebGLView
Posted on May 17, 2013 at 12:57 AM
|
|
Try getting it set up to work zoomed out.
Then try and write the code to zoom in when you want to. That will let you remain zoomed in most of the time, then zoom out when you have to. Assuming performance is alright, that should do it
Posted on May 17, 2013 at 12:55 AM
|
|
Thanks! This should be fixed on GIT for now, but I agree... better to implement something that generates a UUID and stores it locally on the device.
I found this article that may be helpful:
http://oleb.net/blog/2011/09/how-to-replace-the-udid/...
...but I probably can't try to implement it now. At the very least it should be possible now to submit applications without being rejected, which is good!
Thanks again for your help
Posted on May 17, 2013 at 12:42 AM
|
|
Have you had any success trying to set your game so the default view of your game is the size you want when it is zoomed out?
Posted on May 17, 2013 at 12:29 AM
|
|
Fun! Oh, but it gets hard... my horrible, horrible clones 
Thanks so much sharing
Posted on May 17, 2013 at 12:25 AM
|
|
Huh, I've never loaded graphics this way.
Does this work?
var loader = new Loader (new URLRequest ("http://test/test.png"));
addChild (loader);
Posted on May 17, 2013 at 12:12 AM
|
|
Haxe expects all packages to be lowercase, where types are started with an uppercase letter, always.
I think it may have been treating "DCI" as a class name, so it got confused where there was going on in the import
Using "dci" should probably fix it for you
Posted on May 17, 2013 at 12:08 AM
|
|
Hi!
It's a lot easier if it all fits in a single spritesheet... there are ways to intelligently determine a batch render. On the upside, a single drawTiles() command, rendering only one object, performs about the same as a Bitmap on the display list, so any ways you can batch at least two, three or more objects, are saving you performance.
There are also other immediate rendering methods, such as the drawTriangles() and drawRect() APIs. On the other hand, even though the display list is a persistent API, there's nothing stopping you from using it each frame (pooling objects, or keeping them connected to your logical game objects) and updating positions and scales rather than doing an actual render call
Posted on May 17, 2013 at 12:06 AM
|
|
You can also try <ndll name="path/to/library.a" />
Posted on May 17, 2013 at 12:00 AM
|
|
Does it work if you use <dependency name="path/to/library.a" />?
Posted on May 16, 2013 at 11:58 PM
|
|
...but the good news is that good news is coming next week at WWX ;)
Posted on May 16, 2013 at 11:56 PM
|
|
In other words, yes, I agree, great idea, and sorry I'm too busy to fix it
Posted on May 16, 2013 at 11:56 PM
|
|
Hi, welcome!
The default for HTML5 target is a special FPS of 0, which leverages requestAnimationFrame to regulate the frame rate. This is often the recommend path for HTML5 development, so altef's recommendation above of handling a "delta time" between frames is the best to handle game code, especially since that method handles frame drops well when a target machine runs slow.
<window fps="30" if="html5" /> should set the FPS to a timed 30 FPS, similar to what you're asking. I think 30 is the default for other targets, but either way you could just use <window fps="30" /> if you want the same on every platform
Posted on May 16, 2013 at 11:55 PM
|
|
Groovemastercox, welcome!
There's a more recent build of NME on the new haxelib. If you give Haxe 3 a try, you can "haxelib install nme" to get a newer version, which includes the above improvements. Otherwise, its certainly possible to check NME out from the source and build yourself, but using the version on the new haxelib should be easier!
We have plans to post an updated version for Haxe 2, once its clear the build is ready for a full release
Posted on May 16, 2013 at 11:48 PM
|
