Complete Doom rewrite

[Khojan]

Hey all,

I mentioned in another thread that I'm working on a full ground-up rewrite of Doom. This isn't a port as I'm using none of the original code.

Here are some pics of what I have done so far:

http://www.flickr.com/photos/31512620@N00/254569267/
http://www.flickr.com/photos/31512620@N00/254567761/
http://www.flickr.com/photos/31512620@N00/254567760/
http://www.flickr.com/photos/31512620@N00/254567759/
http://www.flickr.com/photos/31512620@N00/254567757/
http://www.flickr.com/photos/31512620@N00/254567756/
http://www.flickr.com/photos/31512620@N00/254567754/

The images are a little deceiving. It isn't nearly as done as it may look (I'm under 7000 lines of code). None of the monsters do anything yet except stand there and look pretty, I can't fire my weapon, and I can't interact with anything in the level. I am able to wander around the level with full collision detection working (wall and item collisions plus vertical positioning due to stairs and stuff) and I can pick up items and switch my weapons. I'm using DirectX for everything. Super high resolutions are supported (up to 1600x1200 right now but that will go higher) and the textures are nicely smoothed.

My intention is to make it as close in functionality to the original Doom / Doom2 as possible. Just replace the exe from the original with mine. I'll also have some extra functionality in there too (I'm planning a 3rd person camera angle for example).

It's going to be quite a while before I finish it since my regular job (also in game programming) takes up a lot of time. But I thought I'd let you all know about it.

I don't have a name for the project yet. I'm open to suggestions.

Cheers

[leileilol]

Why rewrite? I don't see the point in a complete rewrite unless you were to implement your own unique quakec-ish scripting engine and such.

While you're at it, make Heretic work on it too without peeking at the code for that :)

[Quasar]

Yeah, a replacement for Raven's code that does 100% accurate emulation would be more useful, at least if/until this GPL effort gets off the ground (we've still not even really started it :/ )

[Khojan]

I actually started it as a way to improve my C++ skills before I came to my new job (I was all Java before). But it was fun to work on so I kept it up in my spare time. A friend and I have now turned it into a competition to see who can do the better job of completely rewriting it from scratch on our own.

I don't really have any real reason to do what I'm doing other than just to prove to myself that I can. And to see some different aspects of game development that I normally don't touch in my day-to-day job.

In the end the community will have two more versions of the game they can play with.

[myk]

The monsters look squat because they have the screen ratio for Windows; is that just the screen shot or does it look like that ingame as well for now?

leileilol said:
Why rewrite? I don't see the point in a complete rewrite unless you were to implement your own unique quakec-ish scripting engine and such.

I've always liked the idea of a rewite using the game resources only, and seeing someone pull it through would be cool. It's very typical for people to ask for "reasons" for other people to do stuff, but they don't need them. You are saying "this isn't useful to me". If Khojan likes coding, the idea of reporducing the game mechanics from scratch should be a fun challenge for him.

[Khojan]

Yeah, they're all a little squat right now because I haven't spent the time to work our a proper formula to create the right view perspective angle based on my screen resolution so that it's give me the equivalent to the original 1.6:1 ratio. It actually looks even more squat in widescreen (which I'm supporting) right now because I'm using that same angle for all resolutions. That will be changed later. There's still a LOT to do :)

[Manc]

Quasar said:

Yeah, a replacement for Raven's code that does 100% accurate emulation would be more useful, at least if/until this GPL effort gets off the ground (we've still not even really started it :/ )

I strongly second this motion.

While this is definitely some cool stuff and kudos for even coming this far, if you take what you get from this and enhance it to be a heretic/hexen replacement then not only will you learn even more but you'll be doing an even greater service to the community.

[myk]

Mancubus II said:
if you take what you get from this and enhance it to be a heretic/hexen replacement then not only will you learn even more but you'll be doing an even greater service to the community.

If the base code is totally different from Doom's code I bet it would be quite incompatible with any sources based on Doom.

[Anders]

Having working code to peek at is a great help, even if it's not possible to just cut n' paste.

[Scet]

You look to be around where I was when I stopped working on Doom.Net because I couldn't figure out the AI. I would suggest you just aim to be "close" and not 100% correct, because a complete rewrite will likely never be 100% correct. Good luck, it would be nice if someone where to actually complete a rewrite.

[Khojan]

Yeah. It's not going to be 100% compatible. The AI in particular is going to be very different since I'm doing it all myself. Unfortunately this means that it's not going to be compatible with the demos created with the original Doom. I'm hoping that will be the only incompatibility with the original though. Well, my network code will be very different too.

I'm more or less trying to replicate the experience. But if you put mine side by side with the original there will be some behaviour differences for sure.

[Udderdude]

Cool stuff.

[Aliotroph?]

I suspect that replicating DooM's AI would be nearly impossible without looking at the original code, or at least a very good spec written by someone who did.

What would be really cool is if you managed to replicate the look of the "light diminishing" effect DooM and similarly old software engine were known for. Quite a few maps were designed with it in mind and don't look right at all in GL/DirectX engines. It's not a realistic effect but it does look nice in cramped maze-crawl maps. :D

[Khojan]

Yeah, the AI is going to be trouble but it will be far from impossible. I'm aiming for the casual Doomer to not know the difference between mine and the real thing. Hardcore people will be able to tell the difference though. But I'll be posting the game when I reach something of a beta state so I can get some feedback and I can tune it from there.

What do you mean by the light diminishing effect? Jut how it kind of gets darker as you look into the distance?

[esselfortium]

Khojan said:

What do you mean by the light diminishing effect? Jut how it kind of gets darker as you look into the distance?

Well, things actually get brighter as you get closer to them. Try it. In a dark hallway, walk right up to a wall and it'll be brighter than the brightness level you have set. (In Zdoom, I think it'll always be fullbright when you're right in front of it, even if the brightness level is 0. In the original engine it wasn't like this.)

[Aliotroph?]

In vanilla DooM I think it was something like half brightness when you walked right up to a dark wall. That's just a guess though. The specific combination of the way things get darker in the distance, the way thins get brighter up close, and the automatic shading of the walls, makes DooM look neat. Some of the effect is probably due to the limited way the engine converts the colours because it can only display 256 of them. At any rate, I've never seen a GL engine that even came close to replicating the look of the darkness. Most just try and throw some fog in (GL fog usually looks horrid anyway).

[Khojan]

Yeah. I actually started in on this two days ago. It's easy to make things look darker farther away but I'm not sure I will be able to make them look bright close up. To make then darker in the distance it's just a matter of using a stack of mostly transparent black surfaces that move around to always be in front of you. The further you look into the distance the more surface you look through to make it look darker.

But that effect is only supposed to happen indoors I think...

I'm actually using the exact same mechanism to handle item pick-up white flashes, red damage and berserk, and green radiation suit. It's just a different color surface with different transparency and always right in my face.

I haven't thought of a way to make things bright up close yet.

[Scet]

I don't know much about shaders, but I think a vertex shader could be used for the lights and a pixel shader for the palette effects.

Does the actual light level of a sector have any effect? Seems brightly lit sectors have a slower "fade out" rate.

Having the vertex shader calculate the distance between the player and each vertex would also likely be expensive. I thought about the "black surface stack" idea too, but then all sectors fade away at the same rate.

The pixel shader stuff is easy. Just hook it up to the render target surface and then just tint each pixel red or green depending on the effect.

The transparent surface thing would probably work too, but I plan on adding more shader support for Doom.Net since the fixed function pipeline is gone in DX10. Plus what about the invincibility effect?

Also Khojan, how are you rendering the floors? I found that to be one of the hardest parts and I'd be interested to know how you're doing it.

[Khojan]

Yeah. I've actually gotten that transparent surface stack thing done but it doesn't look very good. I don't think I'd be able to not do it outside and because my surfaces are always in front of my sky the sky ends up always being darker than it should. And it kind of makes things look grayer than they should. Plus having multiple full screen alpha-blends takes off about 35fps. So I think I'm just going to scrap it and try something different.

It took me quite a while to get the floors working. I wrote an algorithm to create a trangle list based on all the segments making up the edges of the sectors. The donut sectors (like sectors 1 and 32 in E1M1) gave me problems for a bit. And the snakey sector 87 in E1M2 also broke it for a while. The end result is that I just have a bunch of polygons for the floor and ceiling, just like my walls.

That and collision detection were the two things I've done so far that have caused me the most problems.

[Scet]

Khojan said:

It took me quite a while to get the floors working. I wrote an algorithm to create a trangle list based on all the segments making up the edges of the sectors. The donut sectors (like sectors 1 and 32 in E1M1) gave me problems for a bit. And the snakey sector 87 in E1M2 also broke it for a while. The end result is that I just have a bunch of polygons for the floor and ceiling, just like my walls.

Interesting, I could never get enough info out of the segments or sub-sectors to form anything. I can get all the lines making up a sector, but I have no idea how to triangulation the information. Actually I have an algorithm, but it fills the whole sector so it only works on ones without "holes".

[Khojan]

That's the same thing I had done at first. Then I realized I could add dummy segments between the closest vertices in the inner and outer loops. Then the entire thing forms one big loop that sort of curls inside itself. It took me a while to get it working right but I haven't seen a sector it fails on.

The entire process is slow though so the maps don't load very fast for me. Some of them are up over 5 seconds :O

[Vegeta]

If you have the time and interest, once you acomplish your goal I think you could make your own game using it and the Freedoom graphics and sounds as a base.