ZDoom

Quick question since I saw that dpJudas has been doing some work on the software renderer... There was some talk on how messy the software renderer is, with globals thrown around everywhere. If the software renderer were to be rewritten, would Silverman's Build code still be needed?

Silverman's code is the first thing I would get rid of - if I was the one rewriting it.

So it really depends on who you ask.

Don't get me wrong - Silverman's code is great and has its place, but because of the licensing restrictions I simply refuse to use it. All of his work can be redone another way.

That talk of redoing the software renderer isn't the first time it's been thought of, though, and with the bug report I posted I've given some very serious consideration of doing it myself. I don't care if slopes, voxels, and 3D floors would slow me down - at least I'd have something started, and the latter 3 can be added back in.

Keep in mind though, I haven't committed to that, yet. I want to do it, but as they said it is a pretty big task.

Eruanna wrote:but because of the licensing restrictions I simply refuse to use it. All of his work can be redone another way.

My thoughts exactly. Well, good luck! Keeping a close eye on QZDoom. Take all the time you need... I've been here since 2001, I'm in no rush.

If you decide to try do a rewrite then the classes I created in r_swrenderer2.h should be a good start. Be warned tho: The task is so big it would take forever to get it finished - mostly because there's so many edge cases that have been tracked down in the old renderer. What parts in the renderer is using Silverman's code? I noticed some voxel code - anything else?

dpJudas wrote: What parts in the renderer is using Silverman's code? I noticed some voxel code - anything else?

I suspect (but would have to check) the slope code. Possibly the map reader (the build format can be removed, or just refactored, either will work I think, but I suspect Randi actually wrote the map reader anyway).

dpJudas wrote:If you decide to try do a rewrite then the classes I created in r_swrenderer2.h should be a good start. Be warned tho: The task is so big it would take forever to get it finished - mostly because there's so many edge cases that have been tracked down in the old renderer.

If I do anything at all (again, I haven't committed to this) I am going to start simple. I've written a 3D renderer before (granted it was in QB, not C++) and the concepts are not altogether foreign to me. What I will do is start with nothing more than walls, sprites, and flats. That was enough to render basic DOOM maps.

After that, add in slopes, 3D floors, voxels, and portals (which includes mirrors).

No city was built overnight.

Just keep in mind that if you do decide to try rewrite it that a large set of maps and such are built around the exact way ZDoom renders things. For example, a basic depth buffer will reveal that Doom sprites go into the ground.

Eruanna wrote:I suspect (but would have to check) the slope code.

Slope code was actually developed by randi, it isn't derived from the Build source. Randi once provided a list of parts where build code was being used, but the slopes aren't really part of it.

Of that list, the wallscan family dependency is gone in QZDoom. The rest is still there, though. I don't think they will disappear anytime soon.

InsanityBringer wrote:Randi once provided a list of parts where build code was being used, but the slopes aren't really part of it.

Thank you for that.

dpJudas wrote:Just keep in mind that if you do decide to try rewrite it that a large set of maps and such are built around the exact way ZDoom renders things. For example, a basic depth buffer will reveal that Doom sprites go into the ground.

I am fully aware of this - and this is one of the few things that still makes QZDoom actually useful over GZDoom.

What I was going to do was actually render the floors as part of the wall - and render each wall as an infinitely tall column because of it. This would very effectively simulate Doom's flat overfill, as well, a feature that I've noticed is needed quite a lot in Heretic and in Plutonia.

But the main reason why I want to redo the code is to be able to customize it a bit more. Right now, things feel very static and rigid in the software renderer, and I don't like that. What worked well in Carmack's day just doesn't fit the mold for ZDoom, in my opinion. I don't even know if I am going to use the BSP tree (though I might, since it sure as hell does simplify things).

It would also give me a chance to shelve the entirety of the ASM code and write in pure C++, at least for a bit, and possibly later being able to write assembly routines simply for floor and wall point/texture calculations and nothing more.

I admit slopes are going to be a challenge. I know they will be, I am not fooling myself, there. But I think they will be considerably easier to deal with, if I at least get Doom itself to render, first.

Eruanna wrote:I am fully aware of this - and this is one of the few things that still makes QZDoom actually useful over GZDoom.

Sorry, just wanted to make sure you know what kind of challenges are facing you down this road.

Eruanna wrote:It would also give me a chance to shelve the entirety of the ASM code and write in pure C++, at least for a bit, and possibly later being able to write assembly routines simply for floor and wall point/texture calculations and nothing more.

Been wanting to get rid of the assembly drawers too. Mostly because it will allow palette and true color to become more alike. I can't remove/fix certain globals when the assembly code needs them.

Eruanna wrote:I admit slopes are going to be a challenge. I know they will be, I am not fooling myself, there. But I think they will be considerably easier to deal with, if I at least get Doom itself to render, first.

Actually, for me, it is more fake and 3D floors that I find daunting.

Everything this project is aiming to do with the software renderer sounds very promising. I'm impressed.

I don't suppose it will be able to do away with y-shearing, though, will it? That, and the low-color rendering (which I understand you're addressing already) are the main reasons I can't play without GZDoom's hardware renderer, lest I get severe headaches and nausea.

I had plans to fake y-angling by doing a perspective warp on the canvas, itself, possibly even doing the same to the canvas behind the player if he looked up/down far enough.

With the way these drawers are already giving me headaches though, that might not going to happen without a refactor of the code. I'm sure it could still be done using the perspective warp method by redirecting to a fake canvas, but then I ask if it's even really worth it if I am going to trash the renderer entirely and start from scratch. So the answer is - "maybe, but I wouldn't expect it too soon."

Ah, well. One step at a time.

Finally managed to give this a run




This does amazing things to some of the worse colormapped ranges in the game. Its definitely really cool

Just as a minor thing, since I've wanted to see it in action, but is there any chance of incorporating dpJudas's PR with optional altered sky projection?

InsanityBringer wrote:Just as a minor thing, since I've wanted to see it in action, but is there any chance of incorporating dpJudas's PR with optional altered sky projection?

It's even less realistic than Doom's version, but I personally have no objection to it being an option. It works in paletted mode, too, if I recall correctly.

I don't know why it was removed, so I am going to wait on his comments about it before I reverse the removal. I do remember it defaulted to being turned on, though.