Doomgeneric: Make porting Doom easier | Hacker News Reader

Doomgeneric: Make porting Doom easier

github.com

215 pointshomarp37 comments

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!

I love this bot, thanks for creating it!

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.

My porting notes for anyone interested: https://github.com/floooh/doom-sokol#porting-notes

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.

https://freedoom.github.io

Free as in freeDooM data.

Strange, they left in platform-specific code:

https://github.com/ozkl/doomgeneric/blob/bec8ced5887df55b818...

Why not strip that out? And it leads me to wondering what sort of gotchas are throughout, and what basic system assumptions are being made.

Ie, it's a little surprising that math routines aren't stubbed out, as well.

That code comes from Chocolate Doom, itself a project to create a portable "vanilla" Doom engine.

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).

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?

> I didn't see anything at a cursory glance.

> 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?

The SDL code snippet on the last screenshot says SDL_PIXELFORMAT_RGB888, which is in XRGB order (not a 24-bit format, that would be RGB24).

Quick, open a PR to add this documentation ;)

Wouldn’t be too hard to check out the existing implementations already using doomgeneric and write them for your own requirements!!

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.

Build a system that even a fool can use, and only a fool will want to use it

Interface https://github.com/ozkl/doomgeneric/blob/master/doomgeneric/...

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 :/

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.

If curious, here's the online demo: https://www.barebox.org/jsbarebox/?graphic=1

There's a game called Anarch, that has a similar API for porting. It also provides functions for handling mouse, sound and save/load.

https://news.ycombinator.com/item?id=25168549

So kind of like having a D-Machine then?

In the vein of a Z-Machine or SCUMM? My first thought was also: why not run it in a VM?

(I guess providing a Doom HAL like this allows one to remove the real time interpreter...)

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.

The current epitome of this currently being Complex Doom Invasion.

Dev here! I've just realized that you shared this. Thanks for sharing doomgeneric!

> Ported platforms include Windows, X11, SDL, Soso.

"Soso"?

EDIT: This[1] I guess?

[1]: https://github.com/ozkl/soso

SerenityOS as well: https://youtu.be/a0P_bB6wjhY

yep, same author: https://github.com/ozkl?tab=repositories

Dev here. When I was trying to port doom to my OS soso, I tried to keep it generic and doomgeneric was born!

Doom is the new Hello World.

Yes!!!

In 3D, maybe. For 2D, the obvious choice would be... Tetris.

or pong

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

    Doom is the new 'Hello World!!'

There is, in the 'doomgeneric/' directory.

Reply on news.ycombinator.com