Articles tagged “MDX DOOM”

You can download the source to the DOOM project below here. It's a real mess in places, mainly in the way it loads level geometry. DirectX initialisation is hard-coded with no fallback code if some feature is missing or unsupported. Usage: DOOM <iwad> <level>
eg:
DOOM DOOM2.WAD MAP31
DOOM DOOM.WAD E1M3
DOOM TNT.WAD MAP03
Keys: use the cursor keys to move around, A and Z to move up and down. Broken:
Floor splitting is abysmal. It is highly inefficient and occasionally wrong. The floor splitting code breaks sectors into horizontal spans which it then splits into triangles - uneven vertex placement results in largish cracks between sectors or "hairline" dancing-pixel cracks inside sectors.

I've also added a MUS lump (music format used by DOOM) player, using the MIDI message functions in winmm. The only feature left unsupported is the pitch wheel, as I can't quite work out the MIDI command for it. If somebody could please explain the logic behind MUS, please tell me. It's essentially the same as MIDI, except each command has a different byte (so you have to convert to the correct byte first), uses channel 15 for percussion (so you have to swap 15 with 9 and 9 with 15 - as 9 is the MIDI percussion channel) and uses a controller for a patch change, whereas MIDI has a specific patch change command rather than lumping it with the controllers.

It might have looked liked I'd got all the walls drawing and texturing correctly, some particular combinations were still wrong. Some walls looked completely wrong until you got up close, and with a flickering burst of z-fighting they'd resolve themselves. Or rather, fuzzy patches would resolve themselves. This would not do! Here's a good (or bad) example of where things were going wrong:
Something tells me I shouldn't hire the UAC's architect. The problem, it turns out, is the way connected sectors handle which coordinates to use for upper, middle and lower sections.

With the exception of some very bizarrely shaped sectors, I've patched up the holes by making the floor splitter a bit more intelligent. It also removes some redundancies. The more exotic levels generate about 5000 triangles, which is fairly reasonable. Now I need to do battle with the physically impossible levels DOOM creates... In DOOM, skies and floors are actually marked as the special texture SKY_1. However, rather than drawing it using the normal mapping, it's drawn fixed to the background.

As with many programming problems, a potential solution presents itself at about 2AM when you suddenly awake and hunt paper and pencil before the brilliant idea vanishes into the groggy murk that is forgetfulness. In this instance, a solution did present itself, but it's far from 'brilliant'. I was pondering DOOM's floors, and how to split them up. I came up with a simple, optimal solution - optimal, provided that the sector I was splitting into triangles was a rectangle with sides perfectly aligned the the (x,y) axes.

A few years back I had a go with DirectX 8, helped along by the excellent DirectX4VB website and tutorials. The best thing I cranked out was a simple DOOM-ish 3D engine, minus sprites (just walls and floors). (All images are click-for-big). I fancied another go, this time not in VB6 but in C# and not with DirectX 8 but Managed DirectX 9. I had an old copy of the SDK so got the obligatory spinning coloured untextured triangle going, then hunted for a proper project to learn with. Keeping with the theme of last time's venture, I decided to go back to DOOM, but not DOOM-ish - I'd load the levels and graphics from an original DOOM WAD file.

RSSSearchBrowse by dateIndexTags