Possible improvement to freelook in software renderers?

So, it's definitely not news that when looking as high or as low as possible in a software rendering port with freelook, you see significant distortion. When looking all the way down, squares on the floor stretch into elongated diamonds. In lieu of a helpful screenshot, I'll point you towards the last panel of this Dr. McNinja strip, which exhibits essentially the same perceptual gaffe. This is certainly quite unlike anything that the naked human eye ever sees. Now, I realize that the software renderer's "eye" is permanently affixed to a horizontal line of sight, and that all that freelook does is refocus the screen onto a portion of that eye's "peripheral vision". I realize that a truly realistic view of the gameworld, when looking up or down, is impossible under this restriction. However, what the current freelook system emulates is what the human eye would see in its peripheral vision if the retina was a flat, vertical surface (and if the image projected on the retina translated perfectly to what the human perceived). I believe that it may be possible to improve the appearance of freelook in software rendered ports by crudely emulating the retina's curvature.



What one could do is vertically compress the portions of the player's view that can only be seen when looking up and down beyond the usual field of view, with some circular, parabolic or logarithmic function. Just some slight compression may, counter-intuitively, raise the quality of the image. Then again, it might be impossible to code, or too resource intensive, or it would just look like ass! But I'm willing to take that risk.

What it would do most likely is slow down the renderer. This requires calculations at the innermost loops in the rendering code that has to be executed for each pixel. About the visuals - hard to say. I think it'd look odd.

It would be a lot easier to simply shorten the viewplane (vertically) as the view angle moves further away from zero (the horizon).

I also doubt it would look any better, and probably weirder, plus sprites are going to get vertically squished which will introduce a weirdness that is currently not there.

It'd probably be easier to rip out all the rendering code and start from scratch. Or modify Quake to load and run Doom games. Either way would probably require similar amounts of work.

MikeRS said:

Or modify Quake to load and run Doom games.

That already exists. It's called Vavoom.

Even with proper looking up and down, the issue remains to some extend at the edges. The higher the fov the more prominent it becomes.

Fisheye Quake has the most advanced software renderer, and yes, it is slow, but worth a try anyway. Choose a fov which matches your screen distance, and the distortions aren't distracting at all.
Here is a good comparision with differen fov settings: http://strlen.com/gfxengine/fisheyequake/compare.html

DelphiDoom cheats in a different way to simulate 3D view.
http://delphidoom.sitesled.com/screenshots.html

It's an interesting software renderer, as it is as far as I know the only Doom software renderer with 32-bit colors and dynamic light.

I agree that this would probably look odd, but software freelook already looks odd. Maybe some new form of visual distortion would actually be preferable once you were equally familiar with it. Meh, just a thought.

Fisheye Quake looks very interesting. I briefly imagined an effect like that for Doom but I know that Doom's renderer has no business attempting such a thing.

MikeRS said:

It'd probably be easier to rip out all the rendering code and start from scratch. Or modify Quake to load and run Doom games. Either way would probably require similar amounts of work.

Using the software renderer is useful for staying as close as possible compatible to vanilla Doom's renderer while looking better. Using a renderer of a different engine pretty much defeats this point.

What would be better in Quake's software renderer than any existing GL renderer in those various Doom ports? I can't think of any advantage.

And if I had to choose a different engine, I would use Build. It has Polymost, it is 2.5D, and it should be far easier to implement all Doom features as it would be with a full 3D engine.

LogicDeLuxe said:

And if I had to choose a different engine, I would use Build. It has Polymost, it is 2.5D, and it should be far easier to implement all Doom features as it would be with a full 3D engine.

But what of the fanboys? THINK OF THE FANBOYS!

Creaphis said:

I believe that it may be possible to improve the appearance of freelook in software rendered ports by crudely emulating the retina's curvature.

...which is exactly what Dark Forces engine did, with no significant performance penatly (I recall it was one of the few engines that worked as smooth as Doom's). The press described it as having a "clever fish-eye effect"

From _CD-ROM Magazine_:
"So how much had id Software's Doom influenced the team.[sic]

"When Doom first came out it made us set our sights a bit higher," said Stinnet[sic]. "We knew we wanted to do a first-person [i]Star Wars game, but we didn't know what programming technology we'd use. But it is our own engine, which we developed internally." Is it better than the Doom engine? "It has quite a bit more capability -- ours can look up and down and it has 3D objects."

"However, there's no rivalry going on, just a lot of healthy American mutual respect. Both teams keep in touch through E-mail and the id team has played Dark Forces and (according to a Lucas PR person) loved every bit of it. This is probably because Dark Forces includes some of the features which id is supposedly including in its latest title, Quake. The most obvious difference is that in Dark Forces, you can look up and down. To create the right perspective, the programmers employed a clever fish-eye effect which makes buildings look as if they're really looming over you."

The real problem is another:

alien8 said:

But what of the fanboys? THINK OF THE FANBOYS!

Dark Forces and fisheye? Did I miss something?

I tried an old demo of Dark Forces I had in one of my old shareware CDs, and can confirm: looking up and down is implemented differently than in e.g. Heretic, although it's not a complete true 3D perspective correction: it looks like a modified Y-shearing algorithm, which makes parts of the view near the edges appear curved, especially when looking up/down. It's definitively there, but really subtle, and you have to be looking for it to notice it.

It looks like this for me:

It's one step forward right into the first room and looking all the way up. I see nothing curved at all.
Is the demo you have different? If so, could you upload it somewhere?

It's best noted in larger, outdoors areas, or where you can put some height between you and the floor. It's really a very large curvature radius though, yet enough to see tilted walls and proper perspective on floor tiles, unlike e.g. in Heretic. Don't go looking for a pronounced warping effect, it just ain't there. It also only affects stuff in the Y direction.

However, what you're looking for is right in front of your eyes: in ZDoom, the perspective of those ceiling panels would be fucked up ;-)

Maes said:

However, what you're looking for is right in front of your eyes: in ZDoom, the perspective of those ceiling panels would be fucked up ;-)

In Dark Forces, I can look up a little more than in ZDoom, but I get the same kind of distortion. In fact, I loaded the TC demo into ZDoom, and the ceiling panels look even slightly less distorted than they do in Dark Forces.
Could you post some screenshots in which the difference is really obvious?

And far as outdoor areas concern, I noticed that the sky behaves quite differently. It effects how motion is perceived, but it has no effect on how buildings are rendered. And also has nothing to do with fisheye.

Yeah, tried the same thing myself and it didn't look any better (although I don't know if ZDoom is still doing simple Y-shearing with no other corrections)




I just reported what I had read back then, it could have been a load of bull for all I know now, or a removed early feature (screens are from the released demo version, I don't know if it's easy to come by).

To answer the OP's question, of course it's possible to make a perspective-perfect software renderer: just don't cheapen out when rendering "horizontal" surfaces and curve them properly instead of keeping them always flush with the view. This of course will result in more calculations, but it's possible. A better example of this would be Descent, if we stick to 90s games, which however also had a full 3D environment with free rotation, so cheapening out the way Doom did would look butt-ugly.

Just an idea, I don't know how feasible this is technically but... Couldn't you just render in OpenGL, and use the z-value of each pixel and the texture coordinate to pick the corresponding color from Doom's original palette? That way you'd have the correct 3d-view while preserving the look of the software renderer. Plus you could use that as a base for other OpenGL effects (colored lighting, fog, etc.).

plenty of GL ports of doom exist. The question is how to make improvements to software rendering

I understand that. What I'm trying to suggest is that if it's possible to emulate the look and feel of the software renderer with OpenGL, is there any need to make improvements for it?

mrguytodd said:

Just an idea, I don't know how feasible this is technically but... Couldn't you just render in OpenGL, and use the z-value of each pixel and the texture coordinate to pick the corresponding color from Doom's original palette? That way you'd have the correct 3d-view while preserving the look of the software renderer. Plus you could use that as a base for other OpenGL effects (colored lighting, fog, etc.).

Yes, it is doable

A year or two ago, Timmie posted a couple of screenshots taken using an experimental new renderer for his ZDoomGL 2.0 project. Apparently those screenshots were rendered with world lighting done using fragment shaders. The lighting certainly did look a lot closer to software DOOM. To my knowledge he never released binaries for that project.

Unfortunately that is as close as we've come to seeing something like this in a GL DOOM port.

I expect this situation to change in the not-to-distant future.

mrguytodd said:

Just an idea, I don't know how feasible this is technically but... Couldn't you just render in OpenGL, and use the z-value of each pixel and the texture coordinate to pick the corresponding color from Doom's original palette?

And sacrifice one of the greatest benefits of GL (true color?) Thank you, but no - thank you!

That way you'd have the correct 3d-view while preserving the look of the software renderer. Plus you could use that as a base for other OpenGL effects (colored lighting, fog, etc.).

I don't think that many will appreciate such a butchery. The biggest complaints about GL renderers is not the greater color resolution but

- the way sprites are displayed
- the inability to reproduce certain software rendering tricks.

So what you'd end up is a renderer that still has these problems and on top of that also reduces color resolution. So you neither get the software rendering proponents nor the GL supporters in the boat.

What would be worth investing time in is an algorithm that preserves the brightness fading of the software renderer without compromising the overall quality.

More limiting than the freelook is the limitations of the 2d bsp, imho. How about using a portal renderer instead? The Build engine and the Jedi engine both proved that it is feasible with adequate performance. Overlapping sectors would be no problem. And the stacked sector effect would be less limited since no unwanted sectors can obstruct the view, ie. this effect would be simply a vertical portal.
Of course, the physics' clipping code has to be rewritten for portals as well.

LogicDeLuxe said:

More limiting than the freelook is the limitations of the 2d bsp, imho. How about using a portal renderer instead? The Build engine and the Jedi engine both proved that it is feasible with adequate performance. Overlapping sectors would be no problem. And the stacked sector effect would be less limited since no unwanted sectors can obstruct the view, ie. this effect would be simply a vertical portal.
Of course, the physics' clipping code has to be rewritten for portals as well.

Having a portal renderer is something I eventually plan to implement in GZDoom (if I find some free time for that, that is...)

The physics code is another matter altogether. It's doable as Eternity shows but the problems are so extensive that it's very hard to get right. And I don't think it can be done without disabling some of Doom's glitches which many players consider essential features of the engine.

LogicDeLuxe said:

More limiting than the freelook is the limitations of the 2d bsp, imho. How about using a portal renderer instead? The Build engine and the Jedi engine both proved that it is feasible with adequate performance.

Depends what you mean by a "portal renderer". The classic meaning is that every "gap" between any two convex spaces is a portal, and all portals are rendered recursively (making sure to restrict drawing only to the portal(s) being rendered). CrystalSpace is one project that used this concept. It's _very_ inefficient for even moderately complex scenes. The advantage is perfect support for mirrors, space-crossing and space-warping portals -- which is not very useful imo.

Build certainly wasn't a true portal renderer, even in 2D. Maybe "wall sorting" renderer is a better term. Like DOOM it doesn't support true room-over-room (where you can see two or more floors at once), which again makes it only slightly useful imo. Main advantage then is not having to create a BSP for the map.

Physics is the killer though, DOOM physics is not predicated on one or two "world trace" functions like in Quake, and rewriting everything to follow that paradigm is such a huge job that it's just not worth the effort.

Graf Zahl said:

Having a portal renderer is something I eventually plan to implement in GZDoom (if I find some free time for that, that is...)

Nice to hear. I'm certainly looking forward to it.
The advantage of portal rendering and an appropriate clipping code replacement is obviously that there is no need to place "connected rooms" at coordinates far away of each other. Having connected (horizontal or vertical) rooms actually at coordinates next to each other should simplify interaction, monster AI, sound code, projectiles, bullet impacts whatever a lot. No teleportation tricks required. The only downside I can think of: Such endless coridors like shown in the Eternity portal demo map won't be possible. But on the other hand, no one seems to miss that option in Build or the Jedi engine either.
With UDMF, it should be easy to add a layer attribute (like Dark Forces does) to make editing and also the automap easier to use.

Graf Zahl said:

The physics code is another matter altogether. It's doable as Eternity shows but the problems are so extensive that it's very hard to get right. And I don't think it can be done without disabling some of Doom's glitches which many players consider essential features of the engine.

True. If compatibility is important, the old renderer must stay as an option. There is no way a completely different renderer plus clipping code would be 100% compatible.

andrewj said:

Depends what you mean by a "portal renderer". The classic meaning is that every "gap" between any two convex spaces is a portal, and all portals are rendered recursively (making sure to restrict drawing only to the portal(s) being rendered).

Something like that, yes. This alone makes the stacked-sector-effect less limited, as said.
Not sure about the convex part, though. Sure, it makes things easier, but also more restricted.
Build seems to work well with any shape, but requires that no parts of overlapping sectors are visible.
The Jedi engine handles overlapping sectors better, ie. it is even possible to see parts of two overlapping sectors simultaneously (not talking about the stacked-sector-effect here), but this engine has glitches with certain non-convex shaped sectors. Most of them still work fine, though.

andrewj said:

Build certainly wasn't a true portal renderer, even in 2D. Maybe "wall sorting" renderer is a better term.

I guess, that is the part which removes the restriction of requiring convex sectors. Though basically, any 2-sided wall can be seen as a portal. Dark Forces editors call them adjoins, which is pretty much the same thing.

andrewj said:

Like DOOM it doesn't support true room-over-room (where you can see two or more floors at once), which again makes it only slightly useful imo.

Not exactly. It is true that Build wasn't exactly created with this feature, and in fact, Duke3d can't do this. The 3D floors in Duke3d are constructed of sprites, which have several issues: They are less efficient than sector rendering, they suffer from clipping glitches (at least in the original software renderer) and they can't be sloped.
However, since the render technology of Build was a good base for this effect, it was added to both Shadow Warrior and Blood.

Besides the stacked-sector-effect, it could handle 2-sided polyobjects much better. In fact, you could construct a dummy sector which doesn't appear in the map yet it shares the space of actual game space, but just connects all vertices which should be moved, thus you could move constructs with any number of sectors or lines.

I'm not really worried about the performance. On my Pentium 200 mmx at 640x480, Duke 3D had about twice the framerate Doom95 had. I only observed notable framerate drops with either many sprites (more than Vanilla Doom would show to begin with) were on screen, or slopes took big parts of the screen. Besides this, computers are much faster nowadays to begin with.