Great project! I used it to create a Twitter bot that posts Doom videos (@tweet2doom). Back then it didn't have sound support, but it is great to see that it supports it now.
Edit: I just realised it uses the modifications that I made for my bot to support SDL audio :) Funny thing is, I took these from some other Doom project - ah, the joys of open-source!
Hey! I realized your PR months later and wanted to merge but it could not. So I add your project as a remote and cherrypicked that commit just to include your commit in the history! Thank you!
I started my DOOM port to the cross-platform sokol headers (https://floooh.github.io/doom-sokol/) from doomgeneric which was helpful at first, but since I had to 'slice' the various modal loops in Doom in order to make it work in a frame-callback app model (mainly for WASM without Emscripten's ASYNCIFY) it wasn't all that helpful in the end unfortunately since I had to rip out the original frame loop anyway.
I clicked around your Github profile. You've implemented heaps of cool wee projects! I particularly linked "tinyemus" :D
edit: maybe I should actually link the page in case people think you're trying to create a smaller pet-sized Emu through selective breeding: https://floooh.github.io/tiny8bit
I noticed this project also today. From zserge's latest post: https://zserge.com/posts/fenster/. He uses it along with a minimal cross-platform graphics library to get doom running. Really impressive.
Just because it's inside an platform-ifdef doesn't mean it's not useful in a cross-platform application. That code would only be active when built on Windows and provide some optional functionality that probably isn't worth writing a cross-platform abstraction layer for (especially since this is accessing the Windows registry, which doesn't have an equivalent on other platforms).
This is one of those things where if you actually plan to port DOOM, you will figure it out pretty quickly on your own, by just glancing at the actual code.
It's pretty common at that level to "just read the source", or to at least look how others use the interface.
Sure, but like, if the point of this is to make porting DOOM super easy by requiring the programmer to only implement a few functions, I don't think it is a ridiculous notion that those few functions be well specified.
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.
Fair enough. I think anyone who wants to port DOOM to new/old hardware (or old and/or exotic OSs) would not see this as much of a barrier, but maybe thorough documentation would help easy ports to who knows what outside of that. We don't even know what people could come up with if that were made even easier.
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?
I had used Doomgeneric as basis for bareDOOM; DOOM running within the barebox bootloader. Back then there was no sound, but it was fun adding support for PWM PC speakers.
The zdoom/gzdoom port has a ton of programmability including the original ACS (action code script) from Hexen and a newer scripting language called zscript. It's basically a fully scriptable doom engine--enemies/actors, events in the level, etc. can all do custom stuff.
This is a great idea.
It would be even better if there was a Makefile for the Linux/BSD folk.
Might be able to open the .sln in VS Code though?
Thanks for putting this together.
I like the comment lower down
Edit: I just realised it uses the modifications that I made for my bot to support SDL audio :) Funny thing is, I took these from some other Doom project - ah, the joys of open-source!