Mare
Newbie

Posts: 3
Registered: 01-13 |
Hi everyone!
I've been lurking on here for a while and thought I would join in, I've been working on a Doom wad file viewer using WebGL (Basically OpenGL ES 2.0 bindings for Javascript/Web Browsers if you've not heard of it). It's well supported on modern web browser like Firefox, Chrome or Opera (NOT Internet Explorer at all sadly), you can see if your browser/platform supports it here.
You will ofcourse need a GPU with WebGL support (I believe a Nvidia 8xxx series or above will work, I test this on a 9500GT which does 60FPS easily).
With that out the way, I've been messing around with this for a few months now and its starting to look quite 'doomish', thanks doomwiki.org and some very helpful people in the #doom-tech channel I might add.
This is not a source-port but more of a reverse-engineering/poking around in the wad file and peaking at the original source type effort, so its not implementing things 'the right way' but the further I get into it the more I can see why they did it the way they did. It's been a great learning experience so far and I don't aim to have it 100% authentic but it's cool to show off anyway.
All the code is viewable on GitHub.
You can see the live demo of it here (uses a GLBSP version of the Shareware DOOM1.WAD), some maps work better than others, E1M1 and E1M2 are the most complete looking.
A little bit of technical background if you are interested...
I am preprocessing all the level information and turning all the walls into 1 big interleaved data array which GL will draw in 1 call, currently the doors are drawn as walls so they will need to change later so they can move. The walls are divided for upper, middle and lower faces (when needed) and all the textures for the walls are stored in a single texture atlas.
The floors/FLATS are generated using the lines in each sector then crudely triangulated and textured by the shader in 64x64 steps using the texture id to look up into another texture atlas.
The THINGS are again sprite sheet'd into an atlas for all the frames on the current level then generated into camera facing quads (yes this is the wrong kind of 'always facing the camera' at the moment, I will axis align it soon ;)).
The player movement is as basic as it gets, don't be surprised if you get stuck in a wall, see through the level or jitter up and down on ledges. Collision detection is probably next on the list of things to do.
Lastly the latest update has an over the top heightmap that seemed like a good idea at the time but will likely be removed later as I think the BSP tree will probably be a more correct way to do it (ofcourse), it will currently go through all the floor flats to gather verts then using a basic software rasteriser it will convert the verts into a giant(!) bitmap, so technically its a per-pixel heightmap for the entire level =P
Anyway, I hope someone finds this interesting at least and I hope I don't get blasted too much for not 'doing it right' =P
|