Performance Testing, and OpenGL/BunnyMark Integration
I decided to stress test my normal-mapped OpenGL project today, to get an idea for how feasible it would be. For reference, my early estimates on ship complexity are about 200 sprites. That's a ship larger than the screen, about the scale of the Millenium Falcon for crew of 32-pixel diameter. And that ship has skeletal beam sprites underneath floor and wall sprites.
The test setup was using the same 512x512 cushion texture with diffuse and normal maps, and the point light plus ambient light shader I showed yesterday. Using the neko VM, I was able to get about 300-350 sprites before framerate dipped below 60. Not bad! Neko, though, is mainly for testing purposes due to its quick compile time. The VM makes it a bit slower than native apps.
Switching to a native Windows target in release mode, I was able to get 1350 sprites with 54fps. I think I can work with that :) Scaling it down to 500 sprites kept framerate pegged at 60, so I think it'll work.
Now the tricky part: how do I integrate this with the ship-building and simulation prototype I've been making in HaxeFlixel?
The stuff I've been doing is raw OpenGL. HaxeFlixel abstracts a lot of that to make things simpler, and to protect me from doing dumb things that break on certain platforms. And realistically, HaxeFlixel would probably run faster than what I could write in raw OpenGL. But the problem is that it doesn't support the arbitrary shader code that I've written for this lighting.
OpenFL (note, not GL, FL) is the medium-level code that HaxeFlixel is built upon. And it's also where I wrote my raw GL code. So in theory, there's a way to smush these together.
So far, however, I haven't seen a clean way to do so. I could probably get my ship code to initialize a GL sprite at the correct position and orientation, and shim an GL render call in there when the HaxeFlixel stuff renders. But I'm not sure how those would layer. (Probably HaxeFlixel on top of GL, at a guess.)
But then, I worry that my raw GL code is going to fall apart as soon as it goes to, say, Linux, or Android. In theory, it should be okay, since OpenFL is designed to catch this stuff. But I'm not sure if I'm using OpenFL correctly. Like, are there certain conditional compiler branches that OpenFL does behind the scenes when using its built-in sprite stuff? Branches that I'd be missing if I skipped OpenFL's sprite.shader technique, and just jammed vertex arrays and shaders straight into GL?
That's where I am now. And this is pretty virgin territory. Little, if any documentation is out there on doing this in HaxeFlixel. I know of a few out there doing experiments with this, and even OpenFL/HaxeFlixel devs on github are building better tools for this. But I'm just kinda bobbing on a rickety scaffold I cobbled together from moldy blueprints I pieced together from various sources.
I hope I don't fall :)