Eruanna wrote:but because of the licensing restrictions I simply refuse to use it. All of his work can be redone another way.
dpJudas wrote: What parts in the renderer is using Silverman's code? I noticed some voxel code - anything else?
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.
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.Eruanna wrote:I suspect (but would have to check) the slope code.
InsanityBringer wrote:Randi once provided a list of parts where build code was being used, but the slopes aren't really part of it.
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.
Eruanna wrote:I am fully aware of this - and this is one of the few things that still makes QZDoom actually useful over GZDoom.
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.
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.
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?
Users browsing this forum: No registered users and 1 guest