Rewriting Doom's renderer to be completely horizontal?

It's an accuracy vs speed tradeoff, and the actual way looking up/down is implemented in software renderers (at least in the Doom Engine, there are full raycasting engines like Duke Nukem's or Descent's).

But then, if you're going to bother with OpenGL anyway, why use a software renderer at all? That would be like combining the worst of two worlds.

beetlejoose said:

I'll answer based on what I think you mean, but if I'm wrong then please give some more details.

Do you mean to render the output onto a series of large flat surfaces?

If we restrict view patch so that you can't see what's exactly below you, then three will suffice. If Doom had narrower horizontal field of view, then more would be needed.

beetlejoose said:

Simple, but unfortunately that won't produce the desired effect.
As you rotate the view the image on the surfaces become compressed.

I don't understand what you're talking about. I can't see any distortion of the sky if it's made as a skybox.

beetlejoose said:

Imagine when you have rotated so that your viewpoint is in the plane of a surface then you won't see anything at all.

You can't. You're always inside a skybox,and you don't move relative to it.

beetlejoose said:

A sphere produces the correct projection. But even when rendering a sphere on a graphics card its an approximation made out of small flat surfaces - triangles. Each triangle has the same distortion as above but because they can be made small and many a better approximation can be achieved and the distortion minimized.

Let me explain again.
Doom already correctly projects the scene on the screen, but only if the view pitch is zero. So if we want to render a scene with view pitch P and yaw Y, we make a temporary skybox : front side - view with yaw Y, left side with yaw (Y + 90) , right with yaw (Y - 90), all three views made with doom renderer, assuming that horizontal FOV is 90 degrees (if not, replace 90 with hor.FOV and rotate skybox walls accordingly) Now, render the skybox. Your viewpoint: in the center of the skybox,yaw=0 (we took care of it before) and pitch P.

Maes said:

But then, if you're going to bother with OpenGL anyway, why use a software renderer at all? That would be like combining the worst of two worlds.

As stated earlier, the lighting! :P

beetlejoose said:

A sphere produces the correct projection. But even when rendering a sphere on a graphics card its an approximation made out of small flat surfaces - triangles. Each triangle has the same distortion as above but because they can be made small and many a better approximation can be achieved and the distortion minimized.

That's only if you use the GPU to directly render it, instead of using OpenCL. OpenCL allows you to program a GPU directly, using it as a slow but massively parallel CPU with few operations.

Anyways, my original point is that a sphere is not even needed. All you have to do once you make the renderer only render stuff in horizonal rows (as to opposed to vertical columns as it does now) is to adjust the length of the lines and spacing between the lines, and stretch everything to fit the screen. It will look like perfect 3D then.

The reason I'm thinking up a series of seemingly nonsensical things to do - like using OpenGL when I already have a software renderer is because I am talking specifically about add-on features for Doom95. The Doom95 engine cannot be altered directly. You would already have Doom95 installed - but then you can run a patch that corrects a load of problems with it (I've already fixed the mouse) but can also optionally give you extras - such as vertical rotation - but still keeping the original engine unchanged with its retro feel. Doom95 on steroids you might say. The whole point is how good can I make Doom95 look without actually reverse engineering the original software. I was already resigned to using OpenGL as the final rendering stage anyway. With the ability to use hardware acceleration, using a relatively simple sphere will have negligible impact on speed. I want to implement the best quality vertical rotation I can without compromising Doom95's already pixelated output too much and a sphere fits the bill perfectly.

Once I have a sphere and the correct texture coordinates compiled on graphics hardware - all thats left to do is get Doom95's rendered output into the sphere texture as fast as possible. If I can make Doom95 render directly into the texture without any intermediate copies then that will be great.

There's also the question of how the final output should be presented on screen. By narrowing the vertical field of view you'll be able to have more rotation - infact you would need the rotation to be able to see everything. So I'm kind of thinking that making it look like you're wearing a helmet might be good - for example.

I am hoping I can get all this to work by hooking and overriding the 'swap buffers' function in DDRAW.dll. It will also need to cooperate with the mouse patch to get its control input etc.

I'm sorry Spleen for hijacking your thread with my own ideas. Its just that this thread inspired me and I was already trying to think of modifications for Doom95. I know you wouldn't need a sphere if you could modify the original software.

beetlejoose said:

I'm sorry Spleen for hijacking your thread with my own ideas. Its just that this thread inspired me and I was already trying to think of modifications for Doom95. I know you wouldn't need a sphere if you could modify the original software.

I don't mind, the conversation that resulted was interesting to read.

One of the reasons Doom uses vertical rendering is that the path traced through a given texture is then also vertical and straight provided there are no slopes in the walls. If you use scanlines then you introduce the problem that the path through the texture is curved. There are a few ways to approximate the curve though. The simplest is to approximate it with a line. But that gives unnatural distortion. The next best way is to fit a quadratic curve to 3 points properly generated in the texture. These methods all add CPU time. Another reason it uses vertical rendering is that it greatly simplifies clipping off the vertical edges of the 2D sprites. You would lose all if not most of the optimizations possible with vertical rendering - but I'm not saying I think its impossible - maybe it is using todays faster hardware?

beetlejoose said:

You would lose all if not most of the optimizations possible with vertical rendering - but I'm not saying I think its impossible - maybe it is using todays faster hardware?

Yeah, that's what I'm thinking. A little loss in speed for the sake of good freelook while preserving the original lighting would be fine.

Right now I'm just procrastinating until someone eventually draws a good top-down sprite of a Doom monster (maybe an imp, that should be one of the easier ones), so I can test whether it will actually look alright with an extra sprite rotation for when you see things top-down.

After all, in my opinion full freelook looks ugly either way if you don't have top-down sprites, because the monsters either look paper thin or like they are laying down, depending on how they are billboarded. The current software renderer with limited freelook is better at preserving the 3D illusion of the sprites, despite its shortcomings.

It's not enough to have a single top-down sprite; you need an intermediate step which requires rotations. The floating platforms in Rise of the Triad and the ships in Wing Commander 1 & 2 are the only sprites I can think of off the top of my head that have vertical rotations. You could try ripping those to experiment with.

david_a said:

It's not enough to have a single top-down sprite; you need an intermediate step which requires rotations.

Why? Can't you simulate the intermediate step by Y-billboarding instead of XY-billboarding?

Spleen said:

Why? Can't you simulate the intermediate step by Y-billboarding instead of XY-billboarding?

Sure, but it will look like ass. Just imagine a rectangle being deformed into a trapezoidal shape.

Maes said:

Sure, but it will look like ass. Just imagine a rectangle being deformed into a trapezoidal shape.

I guess I have lower standards than all of you. :P It looks fine for me in GL ports like GZDoom and Skulltag until you look at monsters at such an extreme angle that they look paper-thin. The plan would have been to replace the "paper-thin" range with the top-down sprites.

I don't understand why you think that would look good :) It would be a jarring shift to go from a badly deformed sprite to something at a 90 degree angle to it.

david_a said:

I don't understand why you think that would look good :) It would be a jarring shift to go from a badly deformed sprite to something at a 90 degree angle to it.

Well it's not a question of it looking super great, it's a question of it looking not as bad. You think it would look better if the sprite was deformed to the point of being paper-thin or just left alone so the monster looks like it's lying on its back, when you look straight down on it? Those are the options for full freelook right now. Maybe you're right, but it's hard for me to visualize without having tried it experimentally. :P

More spriting work would be required, but it may look better if there are 8 new sprites for 8 angles looking 45 degrees down at the monster, and 1 sprite looking directly down (which would be spun depending on the angle of viewing).

As a quick proof of concept for this style, model rips of a monster model may be easiest, though they would clash with the original iwad sprites.

phi108 said:

As a quick proof of concept for this style, model rips of a monster model may be easiest, though they would clash with the original iwad sprites.

...and at this point, why not move to a port with fully polygonal monsters which have none of the above mentioned issues?

Maes said:

...and at this point, why not move to a port with fully polygonal monsters which have none of the above mentioned issues?

I guess it has always seemed to me that making top-down sprites of monsters would be much easier than making polygonal models that preserve their classic feel. I hate to offend the people who made models of the Doom monsters, but I much prefer the way the sprites are animated. Since neither has been done, maybe it's a moot point and good-looking full freelook in Doom is something requiring extreme amounts of effort after all.

Spleen said:

I hate to offend the people who made models of the Doom monsters, but I much prefer the way the sprites are animated.

Anything having to do with re-animating sprites to give them more rotations/higher resolution/etc. has been debated and beaten to death, and then some.

There are some mods Like KDiZD that draw extra rotation frames for bonuses/pickups, but that was limited to 8 because defining more rotations would require changes to the enging.

Anyone trying to poke into the innards of the software renderer knows how convoluted and distributed even such an apparently "simple" change like adding more sprite rotations or sprite-specific distortions is. Any such rewrite would be so extensive that it would make more sense ditching the engine altogether and go to OpenGL/whatever.

Plus, the only way to recreate/complement the ORIGINAL sprites would be to either be a professional clay modeler, or make really high-quality 3D models that look like the original clay ones and use them to extract low-res sprites. None (?) would bother drawing extra "top view" frames by hand for EVERY monster.

Making 3d models that are functionally identical the to the original sprites in terms of detail etc wouldn't be hard. I could do it (experience modding HL, etc.) but just don't have the time.

Just an off the wall thought - and I don't know if this's been talked about before - and I expect there would be a lot of problems with it. But - couldn't you create depth maps for the existing sprites? This could be used to smooth out the transition between a very coarse sequence of vertical to horizontal sprites. Although that would be a lot of hard work and hard to optimise. I can't imagine how you would manually decide on the depth values for each pixel either!

Just as a side note, Spleen. You don't have to use lighting in OpenGL - it can just be turned off. There needn't be any effect turned on that will change the colours you tell it to draw. If you want you can also draw textures pixelated just like dooms.

Also purely for informational value : a GPU implements more of a 'long' processing pipeline rather than a 'wide - slow' parallel architecture. Imagine a row of factory workers on a production line each passing their result onto the next worker. The parallelism comes from each worker being able to do their own job independently.
This architecture is easier to think about when you start with the geometry and end up with pixels. But if you consider starting with the pixels and working backwards to the geometry - like a ray tracer - then a 'wide' parallel architecture makes more sense. It would be nice to have a GPU like that - far cleaner and intuitive.

Then you'd transition to a Voxel-based engine. A half-assed one at that, as sprites with just frontal-view depth would look like half-assed bronze busts (you know, those that are hollow/incomplete from the sides/behind.

If you have a depth map that covers all 4 directions + top/bottom guess what you have...yes, FULL VOXEL SPRITES.

Yep, I can imagine that looking very half assed indeed! Although I did imagine that you would jump to the next rotation frame before any artifacts like that became too apparent. Note that I don't think this would really be a good direction to go in - its just sort of lateral thinking. Sometimes if you consider the redic ulous - it can give you a spark of inspiration.

Mr. T said:

Making 3d models that are functionally identical the to the original sprites in terms of detail etc wouldn't be hard. I could do it (experience modding HL, etc.) but just don't have the time.

LOL


I've thought about bump-mapped sprites too, but I think it would look... odd.

There's simply no easy way to get around the problems of freelook with sprites other than hiding them to limit the vertical FOV.

With the contraint that you have to use 2D sprites then you have to manually create extra frames for the above and below views and some number of intermediate angles. Nobody wants to manually draw enough images to cover all that for all monsters. So it boils down to manually designing the least number of angles that are either acceptable just used by themselves or can be used for some sort of tweening method. Whatever method is used its going to boil down to hundreds or thousands of man-hours to accomplish for a result that falls far short of the quality attainable using 3D models.

The original designers of Doom based their design decisions on the real constraints of the time. Those constraints are no longer applicable due to an advance in the hardware technology. Obviously we are not talking about rewriting the software according to todays constraints or we'd be talking about using completely different methods! So we are talking about applying some artificial constraints and we have to decide what they are. Is it that everything has to be done in software mode and the monters have to be done as sprites. Or can we relax the sprite limitation and use some other method such as polygons for drawing the monsters in software. Or can we relax having to do everything in software and use some hardware acceleration. Or can we just completely start again and write a new engine that can load the old maps etc etc.

These questions further depend on your motives. If its all just for the fun of it then the above questions actually mean something. If its because you actually want to create software thats relevant to today then ofcourse choosing to write a software renderer in the first place is not the best option to say the least.

Bear in mind that just because you use modern methods for doing something dosent mean you cant make it look retro. You could in principle completely change the algorithms used in doom and use as much hardware acceleration as you want but still make it look like the original doom. The question then of whether or not to use OpenGL dosent matter. OpenGL is a low level graphics library and you can do almost whatever you want with it. If you want it to reproduce what doom does then you can!

I like how this thread began as "Rewriting Doom's renderer to be completely horizontal", passed through matrix transposition (which at least is directly related), and somehow ended up in OpenGL, Voxel sprites, spherical texture-mapping and 3D models. This should be split in at least three branches :-p

My depth buffered sprites were an attempt to keep it scanline oriented - you turned it into full fledged voxel sprites, Maes! Whats wrong with discussing alternative methods for drawing the monsters if nobody has yet come up with a feasable way in a scanline oriented software renderer?

Maes said:

I like how this thread began as "Rewriting Doom's renderer to be completely horizontal", passed through matrix transposition (which at least is directly related), and somehow ended up in OpenGL, Voxel sprites, spherical texture-mapping and 3D models. This should be split in at least three branches :-p

Sorry, my "3D model rips as a proof of concept" post is probably to blame...

And to think all of this stuff and the "hi-res spites" debates could all have been avoided if ID had gone ahead and saved some hi-res pictures for monster angles, and taken some pictures from 45 degrees down and top down in anticipation of possible engine enhancements. But were a few monsters drawn digitally, not modelled at all? Those would have still needed some work.