Also eating my free time: Codeglue's moved to a new office! |
Sunday, October 31, 2010
PC Borked
Development on Gloom has been temporarily put on hold as my PC is broken and will reside in the shop for a few weeks.
See you in November!
Monday, October 18, 2010
Collision Detection
Small update for this weekend.
I've put in some collision detection and have made a video of this. It also shows the new lighting, the WAD level loading and a bunch of glitches that still need to be ironed out.
I've put in some collision detection and have made a video of this. It also shows the new lighting, the WAD level loading and a bunch of glitches that still need to be ironed out.
Sunday, October 10, 2010
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:
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).
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 |
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?
Sunday, October 3, 2010
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:
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).
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 |
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
Subscribe to:
Posts (Atom)