Slashdot Mirror

:: insert lame humour apology here ::

:: insert lame humour apology here ::

I think I saw that at doomworld. check it out

Slashdot's influence is spreading...

Flash to court scene 10 years from now
Judge: Would you like to make the opening address now, Counsel?
Lawyer: Yes! Yes! first comment! Ahha, D sux0rz!
Judge: -1, Offtopic

Actually, there are already quite a few versions of Doom with some updated technology in them. OpenGL implementations are a good example (though the first GLDoom didn't get finished, unluckly :-( ) There are hacks that add better handling of sectors for more advanced maps, hacks that add the look up / look down, all sorts of stuff.

Depending on what you mean by Doom with 'updated tech', just adding better graphics won't bring it up to par with Quake3 or Unreal Tournament. Doom uses 2D sprites, which only leaves 8 positions that the bad guys can be viewed from (on the up side - that's also the reason why you can have tons and tons of enemies on screen without major slowdowns!) Look up / Down is highly problematic (partialy because of the 2D sprite issue), the maps are "2.5 D" maps - while they have a height setting, areas cannot cross over each other, etc., etc., etc.

Doom is pretty old tech... Damn I love Doom still! Just upgrading the tech isn't quite enough, however, it would require a complete re-write, and everyone would end up bitching about some of the failings of Doom if they didn't. I do hope they do the next Doom correct - a nice scary atmosphere, tons of monsters, etc.

Meanwhile - go look at some of the current modified Doom engines out there:

Doom Legacy offers quite a few extended things from Doom, including 32 player multi-player games

DoomWorld is a good site for tracking down all the other Doom source ports and modifications, plus news of things like Doom for Daikatana (why?), Doom for QA3, etc.

> I don't think anything would stop it from running ... DOOM!

Well, you probably already know this, but Linux has had a (semi-official) Doom port for quite a while. And since iD released the source, there are at least 2 more ports under active development right now.

I'll also take this opportunity to shamelessly plug psDooM again. :-)

Actually, there have been several Doom source projects, and I can only assume Quake will follow in its footsteps.

Doom Source Ports

Well, it becuase people who play the game simply download the latest version of their favourite port and play it. If they don't like it, they go get another port.

And if they want to develop Doom further, they either join a source-port project that exists already, or use, one as a code base. If their port lets them cheat, it won't get hosted on the large Doom sites (like Doomworld). Sure, people can still find and use cheatable versions, and make DoomServ clients for it, but why go to that much work so that you can beat people at a game? People who you don't even know? And especially, people who will notcie within the first 5 minutes of gameplay that you aren't getting hurt by their rockets and you can fly.

Conclusion: People should start "source port" (please come up with a better name) projects, and define strict sets of rules for your projects. Client side cheating will Always be possible simply becuase of the way the game works. But if people simply download an open-source client and use it, without modifying it, we should be fine.

I think I've said just about everything.

Note: most, if not all, of these "source ports" are open-source and probably GPL'd. Lots of them have Linux versions, too. Go get some! Doom is a great game... and you haven't played it till you've played DoomGL with the Eternal Doom levels (get them at TeamTNT).

Dude! I can't believe that no one has mentioned WolfenDoom yet! It's so mind-bogglingly awesome I... lack the words.

There is a link to the Source Ports page from the page the story links to
http://www.doomworld.com/ports/index.sht ml

There are at least two things that you can do when attempting to reverse engineer a piece of software. The first one (not legal in several countries) is to decompile the code: take a debugger or decompiler and check what instructions are executed. The second one (legal in most countries) is the "blackbox" approach: consider the software as something that produces some output(s) depending on its input(s), and try to guess what is inside.

This second approach is the "real" reverse engineering. By carefully crafting some inputs and observing the outputs, you can often draw some conclusions about how the software behaves. With some patience and a lot of trial and error on simple inputs, you can find some patterns in the software: stuff that does not change, stuff that changes depending only on one of the inputs, and so on.

In the good old days (well, five years ago), I was the author of DEU (Doom Editing Utilties), the first program that was able to create new levels for Doom. I also contributed to Matt Fell's Unofficial Doom Specs and Olivier Montannuy's Unofficial Quake Specs, the documents that describe the WAD and PAK file formats and other internal details about Doom and Quake. Almost everything in the Unofficial Doom Specs was gathered by reverse-engineering. It was only later (with the release of Doom II) that id Software released some information to the community, presumably after they saw that editing Doom levels was a very popular activity. I am grateful for id Software's support of the editing community in their later games, but the first informations about Doom had to be found the hard way.

Most of my efforts in decoding Doom's WAD file format (and later Quake's PAK file format) involved an hex editor for viewing and editing the raw files, and custom tools that I built along the way for making editing easier (or tools that I received from other people, like DEU 3.0 from Brendon Wyber). A key thing is also to share as much information as possible with other people who are progressing on the same front because you often get more in return than what you found by yourself. For WAD files, it was easy to find that the file was organized a bit like a tar archive: a header, a directory containing names of objects and offsets within the file, and the data for the objects. Then the trial and error starts: try to guess what an object might be, modify a few bytes, run the game and see what happens. If your changes produced something useful, write it down and share the info with others. If the game crashed, try again. Repeat until you have understood everything.

Sometimes, you will find data structures that you do not understand. That was the case for Doom's NODES, SEGS and SSECTORS data. If you share enough information with others, maybe someone will have an idea and find that the data structures are related to something that they know. This is exactly what happened for Doom: Alistair Brown and a group of students from Bradford suggested that the unknown data might be a BSP tree. After reading some papers on that topic (I didn't know anything about BSP trees), I was able to implement a first BSP builder in DEU. And then it became possible to create brand new levels for Doom, instead of only changing the textures and location of the monsters as we did in the first few months. Releasing the source code for the tools has probably helped a lot. Other people were able to create their own tools based on that, and then the next reverse-engineering steps became much easier when the other games based on the same engine were released (Doom II, Heretic, Hexen, Strife,...)

Ah well... The good old times... Sigh!

Well, the next best thing is WolfenDoom, which basically translates all the original six episodes to doom faithfully, and even adds some of their own. Really nifty.