Not too lomg ago decided to make a quick test project to try out tilesgeet and drawTiles for rendering for windows target, and gotta say I am pleased with the performance gains over drawtiles! But then I got around to trying out the blendmodes in drawTiles and came across some strangeness. Either I am lacking the correct parameters format (there is literally no documentation on how to use them properly then), or the feature is incomplete? Anyways I drew a quick gradient in gimp for use in the project as a png.
^^^^^^^ there is a white gradient here lol
Then, when I tried drawing 5 of them in a row using each blendmode, on top of my tiled world render I get strange results. Namely, multiply and subtract I thought would be dark instead. The relevant code is to the left of the pic consistent across openfl 3.0.3/0.6 and lime 3.3.2?/4.0.2? (adding this info from dayjob lol)
Anyways, thanks for taking a look at this post!
Edit: just realized I am supplying a 4th parameter to the tempArray without using say, Alpha or Scale. Would this effect blendmode though?
http://haxecoder.com/post.php?id=21
This is a pretty neat tutorial on how to use the drawTiles API. For the flag parameter (where you placed your useBlendMode int), you are suppose to supply all flags that you want, using the “|” operator, for example like Tilesheet.TILE_SCALE | Tilesheet.TILE_ALPHA.
This is an old library that mimics the display list structure and levelage the drawTile API, take a look as well on how the blendmode is implemented.
I also found an inconsistency in your program – your tile data array, the tempArray, has an 1 at the end which is useless since you have no flag other than the blend mode flag which does not require extra parameter in tile data array, so you probably drew another tile with ID 1 by accident.
For your question though, As far as I know, not all blend modes work in native target, so play around with your deploy targets and see if that is causing the problem.
If you are using legacy, the drawTiles blendModes are kind of broken, if you aren’t using legacy, the current release have incorrect blendModes but they are fixed on git.
(normal, add, screen, multiply, subtract)
Flash is using Bitmaps and neko is using drawTiles (it, of course, also work with bitmaps)
Thanks for the responses! I haven’t had a chance to look at it again yet (and remove the erroneous extra 1 param to see what, if anything, it is doing) but yeah, those examples you posted are exactly the results I was expecting to see! (Well, cept for multiply being completely blank but w/e lol) at least it is consistent
You see, in my projects I am using bitmapdata.draw for non-basic rendering like this, and the blendmode param for bitmapdata.draw() actually works beautifully, but for flash target only (its absolutely wrong/ inconsistent/ broken/ or prohibitively slow for windows native, legacy or no, across the horrid # of openfl/lime combinations ive tried so ive given up on that) which is the main reason I tried looking into drawTiles. So here I am at wits end, devving around the problem (again) on other things while hoping.
Ideally, I just want blendmodes to work well on native windows target one way or the other. non legacy preferably. Its probably just something still in development. When you say that it is fixed in git, does that mean it will be in the next openfl or lime you think?
consistent across openfl 3.0.3/0.6 and lime 3.3.2?/4.0.2? (adding this info from dayjob lol)
