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.