|
Viewing 1 to (16 Total) target api differences |
Total Posts: 9
Joined: July 22, 2012
|
I'm very new to Haxe and NME, and while it's mostly been a very positive experience, I feel the need to express a little frustration.
I've been using "nme test foo.nmml flash" and the Flash Debug Player with Sublime Text 2 on Mac, and sailing quite smoothly, but just now I decided to try "nme test foo.nmml mac". Changing to this target revealed the following api differences:
UInt is not implemented. (no big deal I guess; find and replace)
nme.display.BitmapData has no field perlinNoise (I will try a refactor using ncannasse.fr/blog/optimizing_perlin_noise)
nme.display.BitmapData has no field threshold (not sure yet how to work around this one)
BitmapData.draw method takes blendmode string instead of BlendMode enum (weird)
I'm feeling somewhat disillusioned and wondering what other speed bumps lie ahead.
I know it's lame to complain about open source software.
Is there a better way to learn of these differences in advance of coding up features that aren't going to compile on every target?
Is it generally a bad idea to put off testing on all platforms until one has a working application. What's the least common denominator target (ignoring HTML5)?
Thanks. Sorry my first post is a negative one.
Tags:
Posted on July 22, 2012 at 1:21 PM
|
|
|
Total Posts: 2140
Joined: August 25, 2011
|
Re: target api differences
Hi, and welcome!
I apologize for the inconvenience. In general, NME does implement a consistent API between targets.
The biggest shift occurs when you change between languages. Flash uses SWF bytecode and the Flash Player runtime. Almost all the other targets are C++. If you test against the Mac target, it should give a great idea of how things will work on other native targets.
Haxe doesn't use a UInt type except for the Flash target, for compatibility.
We are going to try and continue to improve the documentation to help cover some of these small areas. I'm sorry you've hit some bumps, but I wouldn't say this is something that will continue to be a big problem. I also try to test against my current desktop (like "mac") or the current desktop using Neko (like "mac -neko") in oder to make sure everything is working with native code 
Posted on July 22, 2012 at 3:15 PM
|
|
Total Posts: 9
Joined: July 22, 2012
|
Re: target api differences
Alright thanks, Joshua. I will continue by testing mostly Mac builds, with frequent peeks at Flash.
Posted on July 22, 2012 at 3:22 PM
|
|
Total Posts: 2140
Joined: August 25, 2011
|
Re: target api differences
Would you like to help add the perlinNoise and threshold methods?
Perhaps we can integrate Nicolas' method for perlin noise, and threshold seems easy to implement. Otherwise, I can look into implementing them. That way we won't have to worry about this anymore
Posted on July 22, 2012 at 3:32 PM
|
|
Total Posts: 9
Joined: July 22, 2012
|
Re: target api differences
Nice try; get me invested so I won't leave ;)
I'd be happy to, but I won't commit to a time frame for now. I'm still pretty uninitiated, and laser-focused on getting a game built.
Posted on July 22, 2012 at 3:45 PM
|
|
Total Posts: 9
Joined: July 22, 2012
|
Re: target api differences
I should start a new thread for this, but I'm not sure how to title it.
I was generating background bitmaps with perlin noise multiplied by a color, then multiplied by a radial gradient (to fade it out toward the edges). This was done with blendmodes in the bitmapdata.draw method, which aren't there in cpp targets.
Nicolas' perlin class works fine, but I can't find a way to apply the color and the gradient.
I'm also not sure how to avoid triggering software rendering.
I've been searching around, and I'm sure the answers are all there (in the sources if nothing else), but if you have the time to advise me I would really appreciate it.
Posted on July 22, 2012 at 4:00 PM
|
|
Total Posts: 2140
Joined: August 25, 2011
|
Re: target api differences
Hey! It wasn't a ploy ;)
I'll see if I am able to implement these for you today.
NME supports a few blend modes right now, like ADD, but we should be able to be able to add hardware support for more modes after we finish building out OpenGL ES 2.0 support. For compatibility, NME has used OpenGL ES 1.1, which does not support shaders, which will make it easier to allow the hardware graphics to be extended.
Posted on July 22, 2012 at 4:06 PM
|
|
Total Posts: 9
Joined: July 22, 2012
|
Re: target api differences
No way, man. Don't "hurry up and implement" anything on my account.
I'm just wondering if there's another technique available to give my noise map a color and a fade.
And incidentally, I was using threshold() on a noise map to create a starfield; but I wasn't really pleased with it and couldn't decide whether to keep messing with it or drop it. The missing threshold method made the decision much easier.
Posted on July 22, 2012 at 4:28 PM
|
Total Posts: 261
Joined: September 08, 2011
|
Re: target api differences
For what it's worth, NME's BitmapData implementation is basic - if you plan to do advanced blending or drawing you're likely to bump into problems. For instance blendmodes apparently aren't implemented at all in bitmapData.draw. Also keep in mind that bitmap manipulations will be very slow on mobile.
AFAIK hardware-accelerated additive blendmode is only supported by native targets in Tilesheet.drawTiles (it's a flag) and Graphics.drawTriangles (non documented but I saw it used). Same for color transform, it's accelerated when used through Tilesheet.drawTiles.
You'll get a decent "vignette" effect by just overlaying (or drawing) a transparent PNG without specifying a blendmode.
PS: Joshua if you want to spend a few hours on NME, please create a page with a detailed list of everything that triggers software rendering ;)
Posted on July 22, 2012 at 4:41 PM
|
|
Total Posts: 9
Joined: July 22, 2012
|
Re: target api differences
Thanks, Philippe.
Perhaps I should reconsider my decision to use all procedural graphics.
Posted on July 22, 2012 at 5:06 PM
|
|
Total Posts: 2140
Joined: August 25, 2011
|
Re: target api differences
NME tries to use hardware rendering where possible. Some of the blend modes are enabled. I believe they are implemented as OpenGL blending modes. NME also has a software renderer. When you use bitmapData.draw it triggers the software renderer. If I understand it correctly, OpenGL ES 1.1 does not support some features, such as radial gradients, which will currently go to the software renderer. As well, the ability to repeat (tile) textures that are non-power-of-two is not supported on many graphics drivers, so that my also revert to software.
If you set "cacheAsBitmap" to true, it triggers the software renderer. It can be somewhat confusing, because the call is synonymous to faster performance (generally) on Flash Player. That is because the object is drawn as a bitmap in memory, rather than redrawn as a vector. Since NME is using hardware, committing the object to a software rendered bitmap can be slower than allowing OpenGL to do its job with your surfaces.
I've just added an initial support of perlinNoise using Nicolas' function. I'm not sure if its working, but perhaps I used it wrong. It's compiling for now, and I bet we're pretty close to having an implementation. I agree with Philippe, though, you may have the best results for now if most of your graphics are prerendered.
However, I definitely understand why cetain elements, like a starfield, might be generated dynamically, though it isn't easy to do! I worked out an algorithm for generated random star maps. I suppose it was a mixture of what you have above -- noise, threshold and blending. I think we'll be able to have noise and threshold handled soon.
Posted on July 23, 2012 at 3:07 AM
|
|
Total Posts: 9
Joined: July 22, 2012
|
Re: target api differences
Okay. I knew that the bitmap.draw operations would be done on the CPU, but I assume that afterward they can be drawn with OpenGL. Correct?
Is using drawTiles() or drawTriangles() the only way to use OpenGL? Or is the display list accelerated also?
Thanks for helping me; I really appreciate it.
For my purposes the decision seems to have come down to either using Adobe Air and hoping that my game tree search runs fast enough (with a backup plan to use alchemy and native extensions), and giving up some platform reach and the much nicer language & tools, or contributing to this project where necessary. The latter seems to be the smarter investment.
I still want to use mostly procedural graphics. The bitmap operations I mentioned are pretty simple and only done at startup and maybe once in a while afterward. The idea is to avoid including texture assets and to support any screen size without scaling.
So today I will start reading through the sources and see if I can get oriented. I think that all I need to catch up to where I am in the Flash target is to add the multiply blend mode to bitmap.draw. (And I will look at your perlin integration, too, but I'm sure you're the better coder here ;)
Thanks again.
Posted on July 23, 2012 at 11:28 AM
|
|
Total Posts: 261
Joined: September 08, 2011
|
Re: target api differences
Yes of course the display list is accelerated, but some features (mask, blendmode, filters, cacheAsBitmap,...) may locally trigger a software renderer - the resulting temporary bitmap would be displayed in opengl after that.
If you're caching generated bitmaps it's obviously a good thing, I didn't imagine you would use it intensively
PS: a simple black vignette effect doesn't need multiply blendmode
Posted on July 23, 2012 at 1:23 PM
|
|
Total Posts: 9
Joined: July 22, 2012
|
Re: target api differences
Perfect. (Ahead full impulse. Pew! Pew!)
Point taken about the black vignette. But for adding color to the noise it still seems necessary.
I'm looking at BitmapData.hx now...
Posted on July 23, 2012 at 1:34 PM
|
|
Total Posts: 261
Joined: September 08, 2011
|
Re: target api differences
You may also try bitmapData.colorTransform.
Posted on July 23, 2012 at 1:53 PM
|
|
Total Posts: 9
Joined: July 22, 2012
|
Re: target api differences
...And of course a colorTransform does the trick. I had tried it earlier, and had it commented out because it didn't work as expected. Turns out that in my impatience I had misused the color property. I expected it to set the multipliers to the passed color, but it sets the offsets to this color's values, and the multipliers to zero. Duh. The docs are fine; it's my brain that's broken.
Thanks!
Posted on July 23, 2012 at 2:32 PM
|
