At this point I’d already proven with QuakeBox that you could more or less rewrite OpenGL calls into s&box Graphics calls and things will work just well enough to get shit on screen. Maybe it’s not perfect or accurate, but with enough fiddling it’s good enough to see what’s happening and you don’t really care that it’s not 1:1 because how the fuck is this running in s&box anyway. But that was a custom-made solution, I had to modify the Quake code so that it could represent the objects in the scene system.
But you can’t really do that with an emulator, because who’s to say what is and isn’t an object, you don’t really know what’s UI, most of the time you don’t even know where the camera is, you just render what the game tells you in the way it tells you.
But you can’t really do that with an emulator, because who’s to say what is and isn’t an object, you don’t really know what’s UI, most of the time you don’t even know where the camera is, you just render what the game tells you in the way it tells you.
So what if instead of hacking the scene system into the game, I hack OpenGL into the scene system? Easy peasy. (Just kidding.)
Anyway, I call this faux OpenGL driver ‘DexGL’.
The first and most obvious hurdle here is GLSL. You can emulate draw calls all you want, but at the end of the day, if the shaders aren’t right things will just break down.
The way I saw it, I had two options:
- Translate the GLSL into HLSL, formatted in a way s&box would accept it (easy but inaccurate and chock full of edge cases)
- Compile the GLSL into shader_c (what?)
I brought this idea up in the s&box discord and they suggested I go with the first option. So naturally I went with the second option.
