k4zmu2a
Hardware accelerated rendering?
Hi there!
Firstly, thanks for releasing this publicly.
I've been working on a somewhat updated version of the game myself (coincidentally also on top of SDL2), and it's been a great resource to compare notes.
I'm nowhere near ready to release anything yet, but I've put in some research and came to the conclusion that it should be possible to get rid of the CPU-based graphics blitting and invalidation logic by using OpenGL (and likely other 3D graphics APIs) -- it should be more than possible to just fully render all sprites on every frame in hardware. This wouldn't necessarily benefit the base game much, but it should allow for easy use of variable and/or very high input sprite resolution (with some file loading changes to accommodate a higher fidelity format), and also could potentially provide a path for a determined individual or group to start replacing the graphics with true 3D models (2D component: apply bitmap as texture to flat quad, 3D component: apply texture to supplied geometry).
I assume this might be of interest to you based upon your recent changes that extend upon the original game?
One possible implementation with OpenGL would be to use gl_FragDepth so that a fragment shader can override the 3D geometry's depth with values taken from a second texture (the Zmap). Then you can use regular depth testing to remove occluded pixels.
gl_FragDepth should be supported since OpenGL 2.0 (all current desktop platforms) and OpenGL ES 3.0 (>90% of Android devices in use as per Google's dashboard), which seems to be an adequate level of support. It also seems to be available in WebGL 2, should a web port ever be attempted.
Hello.
I am glad that you enjoyed my work.
It is nice to see someone else working on 3DPB, I assume you are doing a reimplementation rather than decompilation. I am looking forward to seeing your superior (graphically, legally) rendition of the game in the future)
While HW rendering in general does interest me, for this project I chose to keep SW renderer. This is to avoid extra complexity and to not needlessly raise system requirements. I followed the same principle with SW renderer for ImGui.
As you said, the original game runs fine with its SW retained renderer, even on its contemporary hardware. On modern systems, I think it will run just fine with upscaled sprites. I will reconsider if some problems with SW render do arise.
In my opinion, replacing sprites with 3D models is too much; sprite replacement is where I draw the line. At the moment, I don’t plan on making HD upscales of sprites. For me, 1024x768 sprites from FT with linear upscale are enough to play comfortably.
To summarize: I say no to HW rendering, open to including it as an optional render path if is truly needed.
I'm not really sure what to call mine -- it's somewhere between decompilation and reimplementation. Things that aren't critical to the gameplay are generally being replaced with compatible alternatives (timers, graphics, text rendering, objlist, etc.), but at the moment most of the pinball component architecture and state management remains quite similar to the original code. At least while I'm still working on getting things up and running, I don't want to risk making incompatible changes, and I haven't really decided whether I'll rewrite much of it yet.
And I can agree with those reasons for keeping the SW renderer. It will be quite interesting to compare how performance scales between the two approaches after I make enough progress to perform testing.
I have added HW ImGui renderer in V2.1.0. My rendering approach now looks like this: Out of draw loop: • Original retained SW renderer updates the table in memory as needed. Draw loop: • HW SDL presents the latest table state from memory. • HW SDL renders ImGui.
This solution is kind-of HW accelerated, I probably won’t change it anymore.