Make Flixel GPU accelerated #219
Conversation
Only FlxBlittingRender is drawing something, the FlxGenome2DRender is displaying a bunny and ignoring all state members.
I've used placeholder code everywhere, but FlxGenome2DRender is rendering single-frame FlxSprites in simpleRender.
This is not the best approach to achieve that, but I've tried to keep changes to a minimum. This commit also differs from my original idea of implementing a render that is completely decoupled from renderable entities (e.g. FlxSprite). I've left some hardwired rendering code in FlxSprite (see calcFrame(), for instance), but they will be removed as I progress.
I've tried my best to implement the GPU render without affecting the current drawing API, but that was not possible. The way Flixel draws entities is completely unfriendly for a GPU render using cameras. My best bet was to use render to texture to overcome the problems, but that didn't work either. I was forced to change the draw() method to draw(c:Camera), which means the Flixel render will now invoke draw() for each entity, telling it to render to the specified camera.
It's not perfect and a little bit unpleasant since fxColorAcumulator must be reset by the GPU render, not the camera itself, but it's a start already.
The debug buffer is based on blitting and it enables Flixel to draw dynamic graphics to the screen, such as debug lines (VIS). The debug lines used in tilemaps are not working yet.
The code is extremely ugly and it needs some serious love. It's just a prof of concept for now, but it's not good. When showing debug tiles, the framerate dropped from 30 to 20 because the tilemap is being rendered twice. I've left several TODOs and clues to refactor the code later.
Several method in the FlxRender class were renamed to better mimic BitmapData method names. I did that to make the new rendering pipeline look more similar to the old one Flixel was using.
The FlxCamera code is simpler and easier to understand regarding the GPU rendering. I've added the FlxTexture class that abstracts the concept of graphics (Bitmap or GPU texture). FlxCamera should be tweaked in the future to use screen.texture instead of bgTexture. It should save some memory and performance.
|
Awesome work! I have never played with GPU rendering, so this is over my head. You are going to have to find someone else to do the double checking. Or if you have tested the code enough and feel comfortable that it is stable, I trust your judgement and coding. We can always open new issues and fix any unexpected bugs that arise further down the line. Is there a flag or variable you can set to switch between Bitmap and GPU rendering, or is it always on? |
|
i want to play with your code this week (while i'm on vacation and have plenty of time), but can't promise anything |
|
@IQAndreas Thanks! :D I will try to get as much feedback as I can (code review, play testing, etc) before merging this. If it is not stable/smooth enough, we can ship it as an experimental feature disabled by default.
Yep, during the game creation, the last parameter of @Beeblerox Awesome! Just let me know if you need anything. |
|
Nice news. While gpu render is better for mobile games, software render is better for web games, you are going to keep both renders ? |
|
Yes, both renders are available. It's up to developers to choose the best one during the game creation. |
|
How to get this running? I've download several Genome2D repositories, imported in FDT and FlixelCommuntiy got reference to them. Still getting error. |
|
@WingEraser You have to download Genome2D SWC at build.genome2D.com and include it in your project. It should compile just fine after that. If you have any problems, let me know. |
|
Downloaded. I'm not sure why there are a lot of errors which doesn't make sense. I'm better off getting rid of FDT4 and use other IDE. |
|
I've updated our fork of Mode to make it run against version 2.57 (with GPU support). Using FlashDevelop, all you have to do is clone the dev branch and add Flixel code (Genome2D SWC is already included in the project). |
|
Do you feel the the GPU support stable enough to be merged into I have some free time this week (a rare commodity these days) and would like to spend it rearranging the functions, and merging some of Flixel Power Tools. I figured if these massive changes are merged, there will be less merge conflicts to deal with.
Actually, he would have to clone |
|
I think it is stable enough to be merged, but there are a few rough edges we need to smooth. I think it's a good idea to merge it now to avoid any merge conflicts. The GPU acceleration is disabled by default, so I think it will not bite anyone. I will try to finish all my pending pull requests, so we can merge them as well. |
I am really happy to issue this pull request. It makes Flixel Community GPU accelerated by using Genome2D as a render.
This is the first step to bring Flixel to the GPU world, there is still room for improvement. Despite of that I've ran some tests and the new GPU render is way faster than the CPU blitting one.
I have tried to keep changes to a minimum, avoiding modifications that would break too many things. I think the only significant modification I've made that deeply changes the current API was the addition of a
Cameraparam inFlxBasic#draw(), which is nowFlxBasic#draw(Camera:FlxCamera). There was no way I could think of to implement multiple cameras without that change.Special thanks to @pshtif and @Beeblerox for helping making it happen!
Fix #90