Is there any way to guarantee hardware acceleration when targeting desktop builds in OpenFL?
For most players our game initializes OpenGL and has no problems. However, we had one player recently who complained of graphical issues. When we asked him to post screenshots, it turned out their game was using Cairo instead of OpenGL. We think this happened due to the game running off their integrated GPU instead of their dedicated GPU. We tried to provide technical help for them, but to no avail.
I figure this kind of request is a longshot…but nothing ventured, nothing gained.
I guess it’s a graphic card with bad opengl support…
There are some lime and openfl defines that you can try. I’ve started a spreadsheet.
Maybe these ones can help:
Thank you very much!
I’ll be sure to bookmark that spreadsheet.
Could you make a feedback when you will have tested these defines if it’s working or not? So I can add comments in the spreadsheets.
I did test this out and it seems to work for regular bitmap rendering.
But there is a drawback – using it means that some (or all) of the graphics API commands like beginBitmapFill(…) no longer work. I’m guessing these commands are tackled by the software renderer, even when OpenGL is initialized. Our game does use the beginBitmapFill command to draw and tint tiled patters for UI backgrounds, so unfortunately it seems I can’t use this flag.
I don’t know why
beginBitmapFill doesn’t work in HW only. It should be accelerated…
Maybe it’s a bug in older versions of OpenFL? We’ve been compiling against 8.9.6 for quite a while now.
So something interesting I’ve noticed when adding the openfl_force_hw_graphics flag.
If you call beginBitmapFill(…)+drawRect(…)/drawRoundRect(…), and then display whatever DisplayObject you used on the screen, it won’t render.
But if you draw the DisplayObject to a BitmapData, then assign that to a Bitmap and show that, it will render.
Also, using just beginFill(…), it will render a DisplayObject just fine if you use drawRect(…), but not if you use drawRoundRect(…).