cristicbz/rust-doom

Arm GLES / OpenGL 1.x compatibility

Closed this issue · 6 comments

Any chance of having GLES rendering? Or just to test if the app's working, software OpenGL 2.0 using Mesa?

On older x86 hardware it would be useful to have OpenGL 1.x compatibilty which, in addition, would instantly enable those gles arm devices that get accelerated OpenGL 1.x through the glshim wrapper.

I would be open to an alternative implementation of the gfx module which solely used OpenGL 2.0 (or even 1.x) features. It would be tricky to do palette/colormap lookup without shaders (plain palette lookup would be easy, but the colormap stuff makes it trickier). The only constraint I'd put on such an implementation: it should be safe code exclusively (this may mean writing a glium-like library for OpenGL 1.x and linking into that).

I think realistically, the better way to do this is using an SDL2 based software renderer. This may require further optimisations like frustum and some occluder-based culling to prevent it from being prohibitively slow (currently the renderer just draws everything relying on the stupid amount of silicon GPUs have these days).

When all is said and done, I think this would be really cool, but a lot of work. Currently my roadmap is still focused on features, but if you want to try your hand at a flag protected software renderer, I'd be happy to review and merge such a change, as well as help with any refactoring needed to decouple rendering better.

What's the outlook here?

Hi @petevine, sorry for being so unresponsive, and I do appreciate the interest! It's just that, unless it's a small feature or bugfix, I tend to work on this project in bursts (on holidays etc.)

I'd be open to implementing or accepting a PR for a shaderless implementation or a software renderer as mentioned in my previous comment at some point, but it's not going to happen soon.

I'd like to keep this issue open though, to allow me to reference it when some big refactor or other piece of work may lead up to the possibility.

I remember playing Doom on my first PC (386DX 40MHz) so I'm puzzled why a 2D game can't can't be drawn purely in SDL (regardless of the backend) similar to what rustzx is doing.

@cristicbz If you really think there are actionable items here I'd appreciate if you could open a more focused issue and close this one.

@petevine this project was originally designed as an exercise around the lines of: imagine you're a Rust game dev from 2016 (or 2014 at the time) told to write a renderer from these assets provided by the art department in some fixed format. I wanted to see what a modern, retained mode implementation (in a modern language) of a Doom renderer would like.

That said, I think a pluggable SDL2-only renderer should be possible and again, I'm open to it. I'd like to open some focused issues, but even that takes bandwidth I don't currently have.

I wouldn't want to close this issue as 'wontfix' when I fully agree with the intent behind the issue and hope to provide a solution eventually. I'd rather I close it a six months as "fixed by SDL2 renderer implemented in PR #999" or whatever :).

If you'd rather this issue was just closed for whatever reason (you don't want to have anything to do with this project any more), then you may close it and I won't open it again. I am grateful for your input regardless.