drfrag wrote:I see now the startup screens are being ported to OpenGL, that could be a problem. But no big deal, may be switching earlier to the graphics mode like in ancient ZDoom would solve it and would be also cool.
I don't plan to port them to OpenGL but to the hardware independent render backend. The software-rendered backend would be able to deal with them just as well - but if that worked out they'd no longer be Windows exclusive.
What I managed so far is to initialize the frame buffer earlier in the startup code to be able to use it here, but there's several gotchas to sort out first:
* currently the screen resolution maintenance is not properly encapsulated. Messing around with the frame buffer during startup affects the global setting which it should not - it should be the other way around that this is being maintained externally and then sets the framebuffer's size instead of letting the frame buffer maintain its size and the global backing setting for that.
* another issue is the messed up exit code which may have made sense on DOS in 1998 (but even then only in Lee Killough's mind
) but on modern systems is a genuine hassle. The main blocker here is that the Posix backend is quite careless in how it terminates in case of a fatal error.
Without these two out of the way, it'd be a bit problematic - the core feature itself is not that hard to pull off - I got a 2D screen, turn it into a texture and render it. Case closed.
(But even that has to wait, because I am currently trying to untangle Build/Polymost's texture management from the high level rendering - the details of what textures are filter up far too high in the logic, causing spurious errors in many places - probably one of the reason why they went the palette-only route...)
So yeah, right now I'm spread a bit thin...
[quote="drfrag"]I see now the startup screens are being ported to OpenGL, that could be a problem. But no big deal, may be switching earlier to the graphics mode like in ancient ZDoom would solve it and would be also cool.[/quote]
I don't plan to port them to OpenGL but to the hardware independent render backend. The software-rendered backend would be able to deal with them just as well - but if that worked out they'd no longer be Windows exclusive.
What I managed so far is to initialize the frame buffer earlier in the startup code to be able to use it here, but there's several gotchas to sort out first:
* currently the screen resolution maintenance is not properly encapsulated. Messing around with the frame buffer during startup affects the global setting which it should not - it should be the other way around that this is being maintained externally and then sets the framebuffer's size instead of letting the frame buffer maintain its size and the global backing setting for that.
* another issue is the messed up exit code which may have made sense on DOS in 1998 (but even then only in Lee Killough's mind :twisted:) but on modern systems is a genuine hassle. The main blocker here is that the Posix backend is quite careless in how it terminates in case of a fatal error.
Without these two out of the way, it'd be a bit problematic - the core feature itself is not that hard to pull off - I got a 2D screen, turn it into a texture and render it. Case closed.
(But even that has to wait, because I am currently trying to untangle Build/Polymost's texture management from the high level rendering - the details of what textures are filter up far too high in the logic, causing spurious errors in many places - probably one of the reason why they went the palette-only route...)
So yeah, right now I'm spread a bit thin...