How easy is it to support other "idtech 1" games in a from-scratch source port?

[Maes]

It's obvious why I'm asking, and I never closely examined the source code of other stuff like Heretic, Strife etc.

However, from my experience with the GPL Linux Doom source code, I'm under the impression that the whole thing is essentially giant hack. There is a lot of hardcoded, static stuff (though a great deal of it could be easily moved somewhere else and generated from configuration files procedurally), and the various code modules "talk" to each other.

Modularizing/isolating them has revealed some of their dependencies (e.g. the automap and various modules of the rendering subsystem need to be aware of the level loading module, the level loading module needs to be aware of the things module, most modules need to be aware of the status stored in doomstat.c, etc. and column-based rendering doesn't reside in one module either, but there are ad-hoc functions spread throughout various modules (e.g. screen melt, column rendering, bunny scrolling, etc.)

so I wonder, once a "basic" source port that supports -mostly- plain doom is stable enough, how easy is it to adapt it to something else like Heretic? Is it a matter of renaming some static defines, some status enums and throw in some extra functions/modules, or is everything wired entirely differently on the inside, as to warrant a major rewrite?

[Gez]

Depends on what you want to do, "one port to play them all" like ZDoom or Eternity, or separate programs like Choco or Doomsday.


There are some important physics change (Heretic and Hexen do not have infinitely tall things, addition of bouncing code (note: Heretic bouncing, Hexen bouncing, Strife bouncing and MBF bouncing are all different implementations), etc.

Most of the game simulation code remains globally the same, just with a lot more hooks and hacks. Of course with Hexen you've got ACS, and with Strife you've got conversations. The devil is in the details, though. Several ports have added Heretic support, for example (Legacy, ZDaemon, Eternity...), but never got it working entirely right. Heh, even ZDoom has had some minor bugfixes about the accuracy of its Heretic and Hexen support this year.

In a unified port approach, a big issue is dealing with the conflicts between editor numbers for things, line types, sector effects, flags, and so on.

[fraggle]

Maes said:

However, from my experience with the GPL Linux Doom source code, I'm under the impression that the whole thing is essentially giant hack. There is a lot of hardcoded, static stuff (though a great deal of it could be easily moved somewhere else and generated from configuration files procedurally), and the various code modules "talk" to each other.

I think it's a bit unfair to call it a "giant hack". It certainly isn't divided into neat conceptual classes like you might expect a Java program to be, and there is a lot of static data and tight coupling between modules. However, the code has been obviously and carefully organised into distinct modules. Basically, if you're used to Java, it probably looks like a mess, but as a C programmer I can tell you that things could be much, much worse.

In terms of the actual question, I'm not completely sure. I suspect Heretic support wouldn't be a huge amount of effort, but Hexen support I'm sure will require a lot more work. Quasar or DaniJ can probably give you a much better answer.

[entryway]

Maes said:

the whole thing is essentially giant hack

See Duke Nukem 3D sources for giant hack. Doom is just nice! :)

[Maes]

To be fair, the Doom code does have some clear remnants of OO-programming in its code, which I'm slowly bringing back to life (and which is one major difference of my approach vs past attempts). For some stuff like e.g. function pointers, menu and status bar widgets, this seems to work wonders so far. Still, I hate it when I see that in order to continue, e.g. I have to find out where that "extern" variable or array is supposed to be stored.

Still, I wonder if, when it's completed, it will be relatively easy to bring in support for other idtech 1 titles or if I will have to start all over from scratch.

And I dare not think how bringing OpenGL support to the engine must be: the codebase is RIDDLED with functions that manipulate the framebuffer directly...

[DaniJ]

As has already been said, this is entirely dependent on your other goals.

Doomsday approaches this from a higher level than ports like Eternity and Zdoom which fold all functionality into a single binary. Naturally this results in an explosion of complexity at the engine/game boundary as you can't generally get away with special cases in existing code.

Certainly the first time this division was attempted (for the initial Doomsday 1.0 release) too much of the game(s) were left game-side. A major trend since that point has been reworking the object model so as to move concepts to their 'rightful place'.

Although I will freely admit that much of this complexity is unnecessary if you are only interested in supporting id Tech 1 based games.