Rewriting Doom's renderer to be completely horizontal?

[Spleen]

As some of you may know, Doom's software renderer calculates the pixels to render for flats and textures in vertical columns (it then actually renders the flats horizontally, but that's a separate and unrelated issue). I've been wondering whether it is feasible to calculate them in horizontal rows instead, and if so, how much it would slow the renderer down. Doing so might allow some interesting rendering tricks. Has anyone ever tried this?

[Viewtiful-Chris]

I already consider basic zDOOM to be gaming perfection, and I ardently dislike OpenGL. So tell us more about what "interesting rendering tricks" might be gained from fixing something that isn't broken.

If it's full mouselook, do we really actually NEED full mouselook? The enemies aren't 3D, so looking directly above or below at them wouldn't render correctly.

[Spleen]

Viewtiful-Chris said:

If it's full mouselook

Yeah, hehe.

Viewtiful-Chris said:

The enemies aren't 3D, so looking directly above or below at them wouldn't render correctly.

I've been thinking about how to correct this issue as well. I could introduce a new top-down sprite rotation which appears when you look straight down at something. This would take a lot of sprite work, but it would be feasible (maybe in the next 10 years....), since it's only one more rotation. Anyways, I'd have to put together a prototype for one monster (maybe the imp?) at some point to see if it would really improve how things look. But that's a whole 'nother issue....

[Kagemaru_H]

Viewtiful-Chris said:

I already consider basic zDOOM to be gaming perfection, and I ardently dislike OpenGL.

I just see GL as a gimmick that's not really needed. Most of my engines are software-based (Skulltag has GL mode but I never use it. Every time it reboots my computer when I quit).

But it really depends on what you want. For classic gameplay, use Boom, PrBoom, Eternity, Chocolate Doom, or play vanilla Doom in DOSBox. ZDoom and Skulltag are great for modding.

And spleen, if you're going hardware for the new renderer, you could use 3D models, and even if it's just software, 3D models would be useful in the process.

[Viewtiful-Chris]

For classic gameplay, use Boom, PrBoom, Eternity, Chocolate Doom, or play vanilla Doom in DOSBox. ZDoom and Skulltag are great for modding.

What do you mean by classic?

I think zDOOM can play in perfect classic-style. Just because it saves at the beginning of a level for you (saving those few seconds) and it has some fairly minor technical differences, it's still very much 1993's masterpiece.

It just looks nicer and runs at silky-smooth framerates.

[Kagemaru_H]

Some people here would disagree, but I don't see how ZDoom deviates from the 1993/1994 masterpiece, besides some technical differences. I might understand Skulltag for all the crap it added, like railguns and runes (still a good mod). PrBoom and Eternity are usually hyped here for classic gameplay and demo recording, and if you want to make an old-school map and want to test for compatibility, Chocolate/Vanilla Doom.

[Jodwin]

Viewtiful-Chris said:

What do you mean by classic?

I think zDOOM can play in perfect classic-style. Just because it saves at the beginning of a level for you (saving those few seconds) and it has some fairly minor technical differences, it's still very much 1993's masterpiece.

It just looks nicer and runs at silky-smooth framerates.

There are quite a few differences, fixing of the hitbox glitch in ZDoom being probably the biggest and definitely not minor. It's big enough that maps that otherwise work perfectly in Vanilla or Boom that were only tested in ZDoom might end up having big ammo issues in other ports because the mapper didn't take the bug into account.

Also, prboom+ has uncapped framerate too. And big resolutions. It looks pretty much the same as ZDoom does.

But, if you only care about playing Doom or making ZDoom maps, it doesn't matter which port you use. However if you're going to make vanilla or Boom maps, start testing in the proper ports right now. >:(

[andrewj]

No doubt many source port authors have considered it.

Without lighting it may actually be faster on modern machines to draw horizontally, since drawing vertically can cause a lot of L1 cache thrashing (since 320 or 640 are multiples of the size of a cache line).

You'll be doing a division on every pixel (for perspective) and a colormap lookup for the lighting, and that is where the slowdown will be. Impossible to say how much slower -- you'd have to try it to find out.

I can't see any real advantage. If you wanted "sloped walls" then you'd have much bigger fish to fry (the physics code), and sloped floors does cover that albeit not very elegantly.

[Quasar]

As I mentioned on IRC, this is pretty close to what Polymost does (rendering generic scanlines, similar to polygon rasterization). At that point, you may as well go the one extra step and use a fragment system like it does, or even further and just use real polygons. But if you're going to do that, it makes more sense to use hardware acceleration than to write your own rasterizer. So you can see the dilemma ;) There's just not a lot of territory between DOOM and a true 3D renderer that makes much sense from a cost-vs-functionality point of view.

[RestlessRodent]

You can do it, but you'd have to rework all the resources and such.

Basically, the way walls are normally drawn you can draw a single wall without problem and use normal slope stuff to detemine how to draw it. However, you'd need to flip that to use it the other way. At least from the way I see it.

[Spleen]

Thanks for the insightful responses, everyone!

The reason to go with the software renderer rather than OpenGL (or using Quake's renderer like Vavoom does) is to preserve how DOOM looks in general. Extending the Doom renderer to have full freelook, even if very difficult, is still much less work than extending it until it has all the features of a 3D renderer! Hopefully, if I rework small pieces at a time, I can avoid changing the appearance too much.

So there. :P

[SaladBadger]

Didn't Kaiser once state that the Jaguar Doom renderer drew walls horizontally in the old "Console Doom Hacking Project" thread? Or am I just misquoting something?

[Enjay]

"Classic"?

Source ports have now been in existence and changing elements of Doom longer than doom.exe existed alone before sourceports. Sourceports are just as classic as "classic" Doom. :P

[Maes]

Actually, rewriting everything to be completely horizontal would only help speed things up a bit in cached architectures if there was a vertical/horizontal disparity at some point. E.g. textures and sprites are stored as columns-first arrays, FORTRAN style, which is not a problem if all computations are done in that style (I always wondered if a FORTRAN Doom would be faster, back in the day): the cache will read ahead the correct bytes each time.

The only potential slowdown would be if there was a horizontal/vertical hybrid at some point: in that case, the cache would register a lot of misses. Since sprites + textures are read-only inside the engine, the only place where writing array-style occurs is the main screen buffer.

If that one is stored rows-first, then drawing to it columns-first will not help much with cache locality. In layman terms, it could have been faster, even back in the day. Of course, to avoid this, you would have to rearrange sprites + textures to be horizontal, but I recall they settled on the unusual (for C programming at least) columns-first arrangement for rendering optimization reasons, which privileged column-based rendering.

In any case, doing it either way won't allow any particular "renderer tricks": the choice is brought upon by convention, programming convenience and cache locality issues. E.g. for some reason the engine designers felt that drawing stuff columns-first was better for their renderer (which makes sense, since there are no slopes or freelook in the original engine and "see through" spots were limited), and objects would be more likely to be hidden from view width-wise, rather than height-wise, it made sense to draw columns first (and store objects in this way, to avoid unnecessary pointer arithmetic or cache misses).

Now, if the above conditions cease applying (e.g. freelook, a lot of see-through) then yeah, switching to another "array gender" may be preferable.

[Bastet Furry]

Quasar said:

[...] There's just not a lot of territory between DOOM and a true 3D renderer that makes much sense from a cost-vs-functionality point of view.

On modern IBM compatible PCs i would agree, but there are surely other (tiny fraction to PCs i must admit) platforms out there that are regularly used but have no hardware acceleration.

[Viewtiful-Chris]

I still don't see the point in full freelook.

Software's freelook is just fine - it's rather unnecessary to see directly above or below you.

[Spleen]

Viewtiful-Chris said:

I still don't see the point in full freelook.

Software's freelook is just fine - it's rather unnecessary to see directly above or below you.

Really, what's the point of freelooking at all?

Bastet Furry said:

On modern IBM compatible PCs i would agree, but there are surely other (tiny fraction to PCs i must admit) platforms out there that are regularly used but have no hardware acceleration.

I've heard the Intel video cards found on laptops are terrible and unfit for hardware acceleration. Unfortunately, they are still quite common....

[Gez]

Spleen said:

Really, what's the point of freelooking at all?

Visual comfort.

I don't use it to look 90° above or below me, but to have my field of vision match where I'm going (e.g., looking up when climbing stairs).

Also, some maps have a beautiful architecture that deserves to be watched at several angles.

As far as gameplay goes, freelook allows to disable autoaim entirely, which is welcome when you want to use the rocket launcher; or when you're trying to kill some annoying revenants on the other side of a chasm rather than the harmless demons below in said chasm. It also makes it easier to spot hitscanners atop tall pillars, and it makes Icon of Sin-type maps so easy that it should hopefully dissuade mappers from making more of this silliness. :p

[Maes]

Spleen said:

Really, what's the point of freelooking at all?

I've heard the Intel video cards found on laptops are terrible and unfit for hardware acceleration. Unfortunately, they are still quite common....

They are basically purely 2D and video (mpeg, mpeg2 etc.) accelerators, at least the older GMA 9x0/9x5 series, with just 1 pixel rendering pipeline. That's less 3D functionality than an S3! OpenGL and Direct3D are supported at the driver level (leading many people to believe that they are full-fledged), but they are entirely emulated. Much like the softmodems of video cards.

The latter models (X1x000 etc.) have some crude vertex and shader pipelines, but they are basically like overblown S3s straight from 1996. At least they have "real" hardware acceleration, but it's incomparable even with a TNT or ATI RAGE PRO from 1997-1998.

[printz]

Viewtiful-Chris said:

Software's freelook is just fine - it's rather unnecessary to see directly above or below you.

I don't like Software's distorted freelooking at all. This is why I prefer GZDoom over ZDoom.

[Spleen]

Gez said:

Visual comfort.

I don't use it to look 90° above or below me, but to have my field of vision match where I'm going (e.g., looking up when climbing stairs).

Also, some maps have a beautiful architecture that deserves to be watched at several angles.

As far as gameplay goes, freelook allows to disable autoaim entirely, which is welcome when you want to use the rocket launcher; or when you're trying to kill some annoying revenants on the other side of a chasm rather than the harmless demons below in said chasm. It also makes it easier to spot hitscanners atop tall pillars, and it makes Icon of Sin-type maps so easy that it should hopefully dissuade mappers from making more of this silliness. :p

Exactly. Full freelook expands on that. I've never seen anyone against it until now..

[RestlessRodent]

Freelooking in Doom is a complete hack in Doom as was done in Heretic. All it does it pan the image down. So what this means for example is take a large vertical picture, and put a box on it which is your view. Move the box up to look up and move the box down to look down. It's simple but it only works to a certain extent.

If you did decide to go Horizontal you wouldn't have this problem. However since rows are being drawn instead of columns you can't easily tell what columns to draw (for example columns behind walls). So in this sense, for every row you would need a new way to figure out what part of the row is to be drawn and what part is not to be drawn.

[Viewtiful-Chris]

Really, what's the point of freelooking at all?

There's no need to be a smartass, as I'm sure I and everyone else are fully aware of its advantages. I use freelook all the time outside of classic/vanilla maps.

So, I'll restate the question.

What possible situation could we be in that would require us to look DIRECTLY up or DIRECTLY down, as those are the only two blind spots in Software?

[Spleen]

Viewtiful-Chris said:

What possible situation could we be in that would require us to look DIRECTLY up or DIRECTLY down, as those are the only two blind spots in Software?

Off the top of my head:
-Monsters at the top or bottom of a very high lift or ledge
-Flying monsters far above you vertically, but right next to you horizontally

They can be annoying when you don't have freelook, especially when you're playing with Vanilla physics (infinite height).

GhostlyDeath said:

Freelooking in Doom is a complete hack in Doom as was done in Heretic. All it does it pan the image down. So what this means for example is take a large vertical picture, and put a box on it which is your view. Move the box up to look up and move the box down to look down. It's simple but it only works to a certain extent.

If you did decide to go Horizontal you wouldn't have this problem.

Precisely. Even if you think it's useless to be able to look all the way up or down, it will still look nicer than the hacky Y-shearing freelook introduced in Heretic. I'm still trying to figure out why you're so against it, Chris.

GhostlyDeath said:

However since rows are being drawn instead of columns you can't easily tell what columns to draw (for example columns behind walls). So in this sense, for every row you would need a new way to figure out what part of the row is to be drawn and what part is not to be drawn.

Hmm, thanks, you made the problem a bit clearer for me. I guess I need to think a bit more..

[RestlessRodent]

Viewtiful-Chris said:

There's no need to be a smartass, as I'm sure I and everyone else are fully aware of its advantages. I use freelook all the time outside of classic/vanilla maps.

So, I'll restate the question.

What possible situation could we be in that would require us to look DIRECTLY up or DIRECTLY down, as those are the only two blind spots in Software?

If some enemy is directly below you, you could SSG him from the ledge.

[Gez]

Viewtiful-Chris said:

What possible situation could we be in that would require us to look DIRECTLY up or DIRECTLY down, as those are the only two blind spots in Software?

void.wad readme:

Mlook especially
will become a necessity in one of the final spots (you'll know it when you see it)

The necessity in question being choosing on which platform to jump down if you do not want to plummet to your death because falling damage is on.

It's just one example, but one that has the advantage of being old, famous and spelled out in the readme.

[phi108]

GhostlyDeath said:

If you did decide to go Horizontal you wouldn't have this problem.

This really sounds intriguing. The beauty of software mode, with full freelooking, while maintaining software mode quirks, sounds wonderful. (I know nothing about the technicals of it, but I would be grateful if any coders decided to take on the job...)

I assume it might be easier to convert all the code in the "simpler" vanilla renderer as opposed to ZDoom/Eternity.

[Spleen]

phi108 said:

This really sounds intriguing. The beauty of software mode, with full freelooking, while maintaining software mode quirks, sounds wonderful. (I know nothing about the technicals of it, but I would be grateful if any coders decided to take on the job...)

I assume it might be easier to convert all the code in the "simpler" vanilla renderer as opposed to ZDoom/Eternity.

Yeah. My guess is that the easiest engine to work with (as a proof of concept) would be Chocolate Heretic, since it's probably the simplest open-source port with freelook. If that works out well, then work on more complicated ports can be attempted.

Anyone else have opinions on which engine to work with?

[RestlessRodent]

You could do it with Doom but it would require a major rewrite to change how the code works. As I said before since walls are no longer always 90 degree angles and walls are drawn horizontally instead, you will loose the ability to quickly clip textures. For everytime you draw a sprite on the screen for example you must determine which part of the sprite to draw and what not to draw (if for example a sprite is hiding behind a wall).

[Maes]

GhostlyDeath said:

you will loose the ability to quickly clip textures.

Exactly, because most of the clipping and visual obstruction in Doom is done sideways, rather than height-wise, due to how the levels are constructed. So the choice of storing textures and sprites columns-first is a visual optimization which allows even a small cache like those used in 486 and 386 PCs to contain the next column of the sprite to be drawn, instead of jumping all over main memory.

If most of the clipping occurred in the height direction (e.g. levels with deliberately many vertical obstructions and see-through walls) then the situation would be reversed. This is what happens to flats and ceilings, which change a lot horizontaly due to distance and ceiling floor clipping, that's why they're stored rows-first.

Certain full 3D engines can't use either optimization, since both scenarios are equally likely.

It's like discussing little vs big endian here.