Remaining OpenFL 8 issues

[Gama11]

trafficstars

This is the list of currently known issues still remaining with OpenFL 8. Most of them are fairly minor. The ones I consisder most important are printed in bold.

• Performance:

  • [ ] On some systems, FlxBunnyMark is significantly slower with drawQuads than drawTiles - note that the "bunny-performance" is close to identical, the culprit seems to be UI elements and/or textfields (press space to toggle)
  • [ ] Performance in the FlxSpriteFilters demo is bad when animations are enabled

• Shaders:

  • [x] ~~The scanline effect in the Filters demo isn't quite correct (there's a "flickering")~~
  • [x] ~~The dropdowns in the BlendModeShaders demo vanish when used~~
  • [x] ~~openfl_TextureSize doesn't seem to work in regular per-sprite filters, only shader filters (see MosaicEffect demo)~~

• HTML5:

  • [x] ~~The Filters demo produces an out of memory crash~~
  • [x] ~~There are "Could not generate web font" warnings on the first build~~

• Misc:

  • [x] ~~FlxPreloader doesn't seem to behave correctly on Flash~~
  • [x] ~~The debugger buttons look broken on some systems (https://github.com/openfl/openfl/issues/1857)~~
  • [x] ~~The DynamicShadows demo is broken (https://github.com/HaxeFlixel/flixel-demos/issues/252)~~
  • [x] ~~Flixel's fonts aren't working on some old Android devices (https://github.com/openfl/lime/issues/885)~~
  • [ ] FlxBitmapText.textColor doesn't work as expected (https://github.com/HaxeFlixel/flixel/issues/2143#issuecomment-383978432)

[larsiusprime]

What about this one?

• [ ] Blend modes don't seem to work?

Or is that fixed already?

[Gama11]

No, but that's more of a limitation of the drawQuads() API rather than an actual issue / bug. Not sure how much of a problem that is, as I still doubt that blend modes are actually being used that extensively.

[larsiusprime]

Ah, so are you suggesting just accepting that as a breaking change, then?

I don't use them extensively, but I do use them... do per-sprite shaders still work with OpenFL8+HaxeFlixel, and if so what are said shaders allowed to sample? If that checks out I could use that to accomplish my needs, and lots of other cool things too probably.

[Gama11]

Yes, with some adjustments per-sprite shaders still work (as well as per-camera and "per-game" shaders). I think per-sprite shaders only sample the BitmapData of the sprite in question. Perhaps there's some advanced options though (@jgranick)?

[larsiusprime]

I can't remember entirely, but basically for full "photoshop style" blend modes implemented in shaders, one needs access to BOTH the pixels of what you're trying to draw AND the pixels of what you're trying to draw it on top of. Some of the blend modes only require what you're drawing, but others require both.

[jgranick]

OpenFL custom shaders do allow sampling from multiple textures.

Add a second sampler to your shader, and it will generate a new ShaderInput<BitmapData> with that name. The default shader input is going to be set automatically by OpenFL, but you can set the .input yourself to a second/third/fourth/tenth BitmapData object 😀

[kennygoff]

Not sure if this is the blend mode thing you're talking about, but FlxBitmapText's textColor isn't working as expected, or at least not like it used to.

• Adding textColor to FlxBitmapText now causes bitmaps to be filled rather than tinted; Whereas before it would tint the bitmaps, now it simply fills the entire color into the bitmap by pixel
• FlxBitmapText not using textColor at all for certain colors (Pure red 0xFFFF0000 works, off red 0xFFF00000 works, my red 0xFFE0330F doesn't)

[Gama11]

Not sure if this is the blend mode thing you're talking about, but FlxBitmapText's textColor isn't working as expected, or at least not like it used to.

No, I don't think FlxBitmapText uses blend modes. Nice catch, I've added it to the list.

[kennygoff]

Making a frame have width/height of 0 seems to stop all rendering for what seems to be a frame tick, although I'm not sure on that measurement since I'm testing this in a full game, not isolated. In my case, I had a hacky little progress bar that was just a FlxSprite I would grow and shrink. Elsewhere where I use clipRect to do this and that works, so I've just refactored this for my own project anyway.

progressBar = new FlxSprite();
progressBar.makeGraphic(Math.floor(progress * 200)), 2, 0xFFFFFFFF);

Since I updated it every frame, this meant the entire game was just blank until this progress bar was 1 pixel wide. There is a warning that gets thrown into the Flixel log when in debug mode, so maybe it might just need to be escalated to an error.

Warning in FlxFrameCollection.checkFrame

Version details:

• Flixel 4.3.0 + OpenFL 3.6.1: Warning, no problems
• Flixel 4.4.0 + OpenFL 3.6.1: Warning, no problems
• Flixel 4.4.0 + OpenFL 8: Warning, stops entire scene from rendering
• Tested on cpp target for Mac/Windows and neko