|
Viewing 61 to (261 Total) |
|
You can also run the build command from the command line.
Posted on July 21, 2012 at 5:08 PM
|
|
Refactored a bit the code to separate the bitmap grid and the input handling.
I made it multi-touch friendly also - works great although the framerate drops to 30fps on my iPod 4 when I'm using 5 fingers at once 
Posted on July 21, 2012 at 3:11 PM
|
|
Mobile bottlenecks is often about the amount of memory manipulated: a wide image means you access a lot more memory than a smaller image (images are a linear memory area). Non power of two images sizes also come with a cost.
Posted on July 20, 2012 at 10:30 AM
|
|
Works beautifully on my TouchPad ICS too - it needs a bit of refactor though to handle multi-touch BTW.
Posted on July 20, 2012 at 9:28 AM
|
|
I've made a test drawing app using this techique: a grid of bitmaps and copyPixels to draw the brush (lines drawn by drawing the brush every 5px).
It's perfectly smooth on iPad1 and iPod4 using 128x128 bitmaps and 32x32 brush
http://github.com/elsassph/nme-drawingstage...
Posted on July 20, 2012 at 7:08 AM
|
|
I was thinking about small bitmaps because it would be manipulating less memory when drawing into, also you can create very large images and showing only the visible ones.
So you say doing copyPixel into a big bitmap is slow? This should be the fastest option. Did you compile the iOS app in Release mode? xcode by default does debug builds even if you don't specify -debug.
Posted on July 20, 2012 at 2:27 AM
|
|
Calling bitmapData.dispose() in Flash makes the bitmapData unusable too, but at least you're sure the memory is generally saved.
Posted on July 19, 2012 at 2:18 PM
|
|
Of course drawTiles doesn't work for that (cf "short answer")...
So you tried to use bitmaps? A fullscreen bitmap isn't going to perform too well but dividing the image into a grid of (separate) bitmaps should work. For what it's worth that's how drawing apps work usually.
Posted on July 19, 2012 at 12:11 PM
|
|
In the nmml:
<window antialiasing="4" />
http://code.google.com/p/nekonme/source/browse/trunk/tools/command-...
Posted on July 19, 2012 at 9:34 AM
|
|
Joshua, to behave similarly to Flash, calling bitmapdata.dispose() should always release the image data (even if for some reason the bitmapdata object isn't freed otherwise).
Also nerik says he's specifying the 'no cache' flag when calling the getBitmapData method.
Posted on July 18, 2012 at 3:21 PM
|
|
Yeah there may still be issues in Flash/HTML5 (notably one bug I fix with removeChild that I just committed now).
Tilesheet isn't implemented in Jeash, I have declared a dummy Tilesheet class in SparrowTilesheet for the JS target to avoid the problem you mention.
Posted on July 18, 2012 at 9:08 AM
|
|
Yeah it has to be implemented for Flash/HTML5. That's TODO, I just haven't a need for it atm.
Posted on July 18, 2012 at 8:11 AM
|
|
bitmap.smoothing = true;
Posted on July 18, 2012 at 6:33 AM
|
|
You must set 'layer.useTint'.
Note that it's only implemented for native nme targets.
Posted on July 18, 2012 at 5:16 AM
|
|
Do you listen to stage.RESIZE event?
On iOS the app reports non-retina resolution then is resized to the right resolution.
System class should report the scale also.
Posted on July 13, 2012 at 4:15 PM
|
|
It's not as crazy as it sounds, but you should draw lines:
drawTiles now supports non-uniform scaling using a matrix, so for each line segment you can compute a transformation matrix combining scaleX & rotation. And of course your texture atlas can contain the different line colors you need.
For what it's worth, my nme-tilelayer library provides a DOM for tiles with nice scaleX/scaleY/rotation properties and the matrices are cached:
http://github.com/elsassph/nme-tilelayer...
Posted on July 12, 2012 at 2:21 AM
|
|
I think xcode doesn't like this kind of external updating - I have similar problems with Titanium for instance and the project needs to be regenerated once in a while.
Posted on July 12, 2012 at 2:09 AM
|
|
As soon as you work with a GPU (especially on mobile) you must do batch rendering as much as possible. This applies if you write your openGl code manually as well.
Now as you noticed, NME adds a bit of overhead when you're sending lots of numbers through CFFI to the runtime - this is why drawTiles is relatively efficient for batching: most of the geometry computation happens in the runtime, and I agree the same should be done for the SWF vector renderer. Eventually either this conversion can be solved or the renderer should be moved in the runtime.
Posted on July 11, 2012 at 1:11 PM
|
|
@raould
There is no miracle to expect from any tech, especially low-end devices like iPad 1 and Droid 2 ; maybe you should look into Spaceport.io or Scaleform which are entirely optimized for vectors. Spaceport.io could leverage haxe-js.
Targeting mobile means using images and careful optimization using batch-rendering as much as possible. That rule applies to all mobile engines without exception, vectors are just too expensive there.
SWF vectors support is still (and should clearly be indicated as) experimental and in-progress, and even if it was mature it should just be discouraged on mobile where the CPU is too weak.
Posted on July 11, 2012 at 2:40 AM
|
|
As I said try to reduce the app startup job to displaying a loading image, then wait a bit before loading the rest of the assets. Aside from that, AFAIK, there isn't much you can do on Android to reduce the initial black screen.
Posted on July 10, 2012 at 6:01 AM
|
