Man I really hope the spec for those functions is fleshed out somewhere else to actually-useful detail. I didn't see anything at a cursory glance.
What format is the frame buffer in? What kind of "key events" need to be passed?
What format is the frame buffer in? What kind of "key events" need to be passed?
It's pretty common at that level to "just read the source", or to at least look how others use the interface.
Obviously I can dig this out of the code if I wanted to. I've reverse engineered programs with nothing but a debugger and stubbornness[0], that's not the point.
Like, what if I'm not a C programmer and I'm just using a C binding?
[0] Most recently, that was a DOS updater for an old HP Elitebook with a battery that no longer functioned. The updater requires that the AC be plugged in, which it loudly complains about, but fails to mention that it also requires the battery to be charged. Fortunately this wasn't a 90s game or it probably would have been more complicated than finding the check and turning a conditional jump into an unconditional one.
> What format is the frame buffer in?
It's a pointer to a screen-sized number of u32s. I'd hazard a guess that it's either RGBA or ABGR, and if you render one and everything looks wrong, it's the other. (Where the A channel is unused, as it's a framebuffer.)
Certainly not fool-proof and vulnerable to endian swaps if you somehow ended up on a big endian device. But this is also a port-doom-to-my-toaster level thing?
150-line example impl https://github.com/ozkl/doomgeneric/blob/master/doomgeneric/...
As other commenters said, the code is good enough to read for that task.
The only weird thing is that you don't control main... That means this isn't a DOOM library, it's a DOOM framework :/