Lights

An important part of Doom is the lighting. Even without dynamic shadow volumes or per-pixel illumination, Doom's lighting gave the game tons of atmosphere.

In my last post I called my lighting scheme "a bit flat", figuring that a few tweaks here and there would be enough to fix it up. Let's look at that screenshot again:

map01 in Gloom

Not bad. But compare this to the same view in Doom:

map01 in Doom

Yikes! Just look at that contrast! You can really see the light growing progressively brighter on each step. In my game the difference is hardly noticeable (you can see it on the ceiling if you look closely).

Unfortunately, while The Internet is more than happy to divulge exactly how the renderer in Doom works, the lighting algorithm seems to be a lot less exciting. So I went on an investigatory adventure past various blogs, lots of in-game testing, map editing, shader writing and even the Doom source code itself.

Now, while I'm still not completely sure how things work, or what *dest = dc_colormap[dc_source[(frac>>FRACBITS)&127]] means exactly, this is what I've gathered:

• Each sector in Doom has a brightness value between 0 and 1. A brightness of 0 means it's black and a brightness of 1 means it's fully lit.
• Actually, each sector has a brightness value between 0 and 2! Anything with a brightness of 1 or more is completely lit.
• If you move away from a sector, the brightness gradually decreases. The maximum distance modifies brightness by -1.
• So: sectors with a starting brightness value of more than 1 will never go completely dark, no matter how far you move away from them. A sector with an initial brightness of 2 won't ever go dark at all!

How does this look in-game, you ask? Well, have a look:

nailed it!

Implementing this system meant that I had to chuck BasicEffect and write my own vertex and pixel shaders. Luckily XNA is great at providing templates and integrating shaders into the logic, so it wasn't as difficult as I had feared. Plus, in the end, we all learned something. And that's all that matters, right?

Where is All the Data?

In my previous post I showed how the level editor can load vertices and edges from the original Doom wadfiles. I´ve since completed the holy trinity of Doom map data by loading sectors!

Sectors have proven to be the single most difficult thing in this game so far. I´ve already discussed my troubles dividing them into triangles, and that remains a problem area. To get the Doom levels working properly I had to expand my algorithm to account for sectors inside of other sectors, which included creating fake extra lines to connect them and treat them as a single polygon.

I´ll probably do a separate blog post to describe the whole process of creating triangles out of sectors after (if?) I fix some last niggling issues. I also read an article by Carmack about how he did it for the iPhone port of Doom, and he just used a 3rd party library. What a hack!*

Small issues aside, the level loading already works pretty well:

Top left: Gloom, Bottom right: Doom

What brightened my day when I tried this is that my assumptions turned out to be correct: the whole level renders super smooth, without any optimizations at all! I just brute force draw every wall and floor, regardless of whether it´s actually visible or not, and the game runs without a hitch.

After all that I had to go all the way, so I spent some time fixing the lighting in my engine, found a set of original Doom textures online (they´re also in the wad file but stored in a weird way) and added those, as well as lighting information, to the level loader.

I think the result is quite nice:

MAP01: ENTRYWAY

It still needs a little bit of tweaking (the lighting is a bit flat, the textures aren´t offset correctly and there´s still some sector problems).

At this point, though, I think it would be a lot more interesting to get some collision and physics in there so we can actually walk around in this thing!

*Carmack is not a hack

Connect the dots

Can you guess what this is?

dots

How about now?

connected dots

And if you're still unsure:

and here's one we made earlier!

With special thanks to the excellent Doom Wiki!

Metal

stealth edited on 19-9 with slightly newer song
and then stealth edited again on 20-9 with even newer song

No youtubes today, but instead an auditory preview. Musical mastermind Pete Brannan has graciously offered to write some original tracks for Gloom.

A few years back Pete astounded me with a top notch soundtrack for Revenge of the Evil Aliens*. I had decided to put that game up for sale which meant replacing all the music which consisted of (unlicensed) tracks of some of my favorite artists such as UNKLE. I handed him the soundtrack and said I wanted something that "sounds like this", not expecting much. Imagine my surprise when he came through with some great sounding tunes that have even been noted by reviewers as a high point of the game!

But enough flattery, here's a first draft of what a Gloom song might sound like:

Peter Brannan - Metal1


And for reference of how a completed song sounds, here's the final level for Evil Aliens:

Peter Brannan - Revenge of the Evil Aliens (Stage 3)


*available now FREE on personal computer and CHEAP on xbox live indie games!

Check out what I can do!

If you're not familiar with the limitations of the original Doom engine then the following might not impress you much, but check this out:



Yeah baby, rooms above rooms!

Check out how wonky that looks in the editor:

Hax

I'm not sure if this trick will work once I put in collision detection and physics, but if it does I'm totally going to make a tower level!

Gloom Does Undo

 "Repeatedly adding and removing nodes, lines and sectors doesn´t look like much, so I won´t make a video out of it."

I lied.

Post holiday update

Gamescom 2010

Had a great couple of weeks of vacation, spent going to Gamescom, Lowlands and Berlin, and reading Kevin Smith´s diary cover to cover.

Unfortunately I didn´t get to do as much coding as I´d have liked to, but still managed to get a couple of days of solid work in.

I noticed, especially after taking a short break from the project, that the code was getting messy. I was using the same classes in the game as in the editor, so stuff like 3D rendering was living confusingly alongside 2D editor drawing. I´d also put a lot of editor UI code directly in the classes that dealt with the actual editing, so they were busy changing the level and updating the screen at the same time, leading to more muddledness.

So I cleaned up! I now have a nice layer between the level and the editor (aptly called EditableLevel) that exposes whatever data the editor needs to change but hides all of the hardcore engine stuff. While I was in there I also improved on a bunch of other stuff, among which a move to the new XNA 4 framework (potential winphone support yo!).

I´m pretty happy with the results!

Using the new architecture I´ve put an undo-list in place. Repeatedly adding and removing nodes, lines and sectors doesn´t look like much, so I won´t make a video out of it, but I assure you it´s pretty neat!

In other news, I´ve asked the talented Pete Brannan (of Evil Aliens fame) if he´d be interested in doing the soundtrack and he´s into it! This guy´s great and I really hope we can make it work. If so, I´ll be sure to post some tune previews!