WebGL Doom Renderer

[Mare]

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

[Gez]

Mare said:

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.

Beware, ZeniMax might go after you for that. They had already cease-and-desisted a vaguely similar project which also included the shareware data. The rational is that the shareware is free to distribute as-is, but should not be modified or built upon.

You could replace it with Freedoom, which would remove the legal dimension from your project.

[DooMAD]

Mare said:

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).

6600 here and seems to work fine.

[Quasar]

Found an interesting glitch - if you walk into the back wall of the exit room (across from the door) in E1M1, the 2nd coordinate being displayed becomes "NaN" and all you can see around you in any direction is sky texture. Walking back toward the way you came puts you back in the exit room.

[Mare]

Gez: That concerns me too, I actually emailed John about today and he just replied saying it isn't his call and he doesn't know if its ok. Might try finding a contact at Zenimax. Using FreeDoom would be ok but when E1M1 fires up, EVERYONE knows what game it is, is there a FreeDoom version of E1M1?

DooMAD: Cool! Impressive that it runs on that.

Quasar: I suspect that wall is right on the edge of the heightmap, maybe that wall is even the last pixel, would explain the NaN for the height.

---

An extra little thing I forgot to mention, if anyone is wondering what the texture atlases look like, you can view them with a console command. Bring down the console (ala quake style using the ` or ' key depending on your keymap), then use: t_viewer 2

This should should the wall textures, then use the arrow keys left/right to view the other textures. Texture 0 is pre-post processing texture the render uses but the others are game textures. 1 should be the intro screen, 2 for walls, 3 for flats and 4 for things. It should be labelled, the skybox one probably won't show because its a cubemap.

Another console command you can use is r_drawfps 1 (fps counter) and r_drawfps 2 (fps + frame times).

[Maes]

That legal concern is what killed "Javascript Doom", and one of the factors that prevents me from making an Applet or Java Web Start version of my port, Mocha Doom.

Then again...

Plus, there once was the STARK engine's demo (an early attempt at a Java-based Doom by none less than Markus "Notch" Persson) and some shockwave flash 3D engine demos using E1M1 of Doom and Heretic in a similar way as this project. It's all about getting crap past the radar.

[GreyGhost]

Mare said:

Using FreeDoom would be ok but when E1M1 fires up, EVERYONE knows what game it is, is there a FreeDoom version of E1M1?

There's a Freedoom demo to replace Shareware Doom, though one map's only a placemarker and two others appear to be unfinished.

[ducon]

I can see E1M1 in Chromium (but without clipping, the up and down keys are not working), and this in the console in Iceweasel (Debian Wheezy):

Engine 3D Console

User Agent ... Mozilla/5.0 (X11; Linux i686; rv:10.0.11) Gecko/20100101 Firefox/10.0.11 Iceweasel/10.0.11
Include Loaded... Console
Include Loaded... Input
Include Loaded... Tools
Include Loaded... Math
Include Loaded... Renderer
Include Loaded... ContextMenu
Include Loaded... Shader
Include Loaded... Textures
Include Loaded... Particle System
Include Loaded... Effects
Include Loaded... Primatives
Include Loaded... Model Loader
Include Loaded... Camera
Include Loaded... Hud
Include Loaded... Audio
Include Loaded... Net
[Localstorage] Unsupported
Input Manager 223 keys initialised
Input Manager 3 mouse buttons initialised
[Localstorage] Unsupported
Loading Game: WebGL Doom
Requesting Shader File: [collines] Fragment Shader: shaders/collines.frag.shader
Requesting Shader File: [collines] Vertex Shader: shaders/collines.vertex.shader
Requesting Shader File: [flats] Fragment Shader: shaders/flats.frag.shader
Requesting Shader File: [flats] Vertex Shader: shaders/flats.vertex.shader
Requesting Shader File: [sky] Fragment Shader: shaders/sky.frag.shader
Requesting Shader File: [sky] Vertex Shader: shaders/sky.vertex.shader
Requesting Shader File: [splash] Fragment Shader: shaders/splash.frag.shader
Requesting Shader File: [splash] Vertex Shader: shaders/splash.vertex.shader
Requesting Shader File: [things] Fragment Shader: shaders/things.frag.shader
Requesting Shader File: [things] Vertex Shader: shaders/things.vertex.shader
Requesting Shader File: [walls] Fragment Shader: shaders/walls.frag.shader
Requesting Shader File: [walls] Vertex Shader: shaders/walls.vertex.shader
Requesting Map File: gldoom1.wad
FATAL: http://github.int13h.com/he3d/scripts/he3d_effects.js:264 he3d.fx.postProcessing.target is null
Compiling Fragment Shader: collines
Compiling Vertex Shader: collines
Compiling Fragment Shader: flats
Compiling Vertex Shader: flats
Compiling Fragment Shader: sky
Compiling Vertex Shader: sky
Compiling Fragment Shader: splash
Compiling Vertex Shader: splash
Compiling Fragment Shader: things
Compiling Vertex Shader: things
Compiling Fragment Shader: walls
Compiling Vertex Shader: walls
DEBUG: Level Vertexes: 585
DEBUG: Building Nodes Total: 220
Found Spawn Point: -1056x-3616
DEBUG: World Bounding Box 2048,4864,-768,3808,-136,264
DEBUG: Heightmap Size 4576x2816 offsets[768x-2048]
DEBUG: Building Textures
DEBUG: Total Unique Textures 32 [3088x3464]
DEBUG: Max Tex Size 256x128
DEBUG: Total Unique Flat Textures: 21
DEBUG: Total Wall Triangles 5156
DEBUG: Total Flats Triangles 3828
DEBUG: Level Things (Unique): 138 (25)
Finished Parsing gldoom1.wad Transfering Data back from Worker Thread

[Mare]

Maes: Yeah, I guess what is worse is that I have to use a GLBSP'd version of the shareware, John.C said typically the shareware comes as a package (ie a zip) so that is the right way to do that. Maybe I'll go with a FreeDoom wad then have some instructions on the page on how to create a GLBSP'd version of the shareware/original wad files so you can just drag and drop the wad onto the page and load that.

Would require some funky front end to handle that but its not impossible really.

GreyGhost: Cheers, I'll look into it, the first thing I noticed was the file size is a lot bigger which could be an issue for slow net connections.

ducon: up and down only work in 'freecam' mode (press f to toggle). I've heard of issues with Iceweasel and WebGL before, perhaps their implementation of it isn't as robust as standard Firefox. The FATAL in the log suggests that it managed to get a WebGL Context and managed to compile the shaders but could not create the offscreen framebuffer target it needs for post processing, bit strange.

[ducon]

The ICanHasWebGL website says that WebGL works, and some other WebGL thingies do work elsewhere. I’ll wait. ;-)

[boris]

I get the same fatal error as ducon in Firefox (18, on Windows 7). Works on Chrome, though.