Crash on Gore [Software Renderer]

[Graf Zahl]

Yeah, I thought of that one, too, when I added the FSoftwareRenderer class, but ultimately it wouldn't really have made anything better. It's a start but it would not have solved any of the underlying problems of initializing stuff 5 miles from where it is needed...

[randi]

Fixed. You guys made me think this was going to be hard, but it was easy.

[dpJudas]

Haha, good one Randi. Don't mind our "here there be dragons" talk.

[Rachael]

XD. I thought I was going to have to re-translate this for the truecolor renderer but this is the high level code so it should be the same. Wow, thanks!

Don't mind our "here there be dragons" talk.

Experience. >_<

Something Randi has a lot of - and you and I are just beginning to get, compared to her. (At least, as far as the r_* code goes)

[randi]

To be fair, it did take me several months to wrap my head around the original software renderer, but now it seems so straightforward.

[Graf Zahl]

Something Randi has a lot of - and you and I are just beginning to get, compared to her. (At least, as far as the r_* code goes)

Well, even many years can not help sometimes. I never gained more than a superficial understanding of how these things work.

[Edward-san]

Uh, sorry for the newbie question, but how about more documentation in the sw renderer code?

I mean, even Graf, from what I can see, couldn't understand the code, so it sounds like there would be the need of a better documentation...

[Graf Zahl]

More importantly, there's need for better structure so that the less initiated are capable of adding new features as well. There's tons of stuff I'd like to do but I see no chance to implement it because of the messy dependencies on those global variables.

[Rachael]

I think the best way to understand the SW code is to look at it from the original Doom source before ZDoom's additions. It's just as confusing there but there's a LOT less lines of code, so it's a bit easier to follow what's happening...

That being said, I wouldn't mind some documentation, myself. dpJudas gave me his understanding of it and suddenly I was able to understand a whole lot more of it than I was before, so there is that.

The other thing is, you HAVE to play with it. You have to change code, recompile, and see what it does. There's really no other way around it, and no amount of documentation is ever going to replace the experience and knowledge you will gain from that. That comes with the understanding that the low-level drawers (r_draw*.cpp) are doing the actual byte-to-pixel mapping on the screen, and the high level code (r_segs.cpp, r_things.cpp, r_plane.cpp, etc) are all doing different things, and do their own calculations which in turn call the low-level r_draw* drawers.

Do it in Chocolate Doom first, though, because if you can change the draw code in that, I think you will much more quickly gain an understanding of the mechanics in Doom's drawing code - ZDoom's code does a lot of repeats and expansions of that stuff which makes it more confusing.

As far as the globals Graf mentioned: I've found most of them are just pointers. They either point to raw data, or they point to data composited on the fly by the high-level code.

[Graf Zahl]

I think the best way to understand the SW code is to look at it from the original Doom source before ZDoom's additions. It's just as confusing there but there's a LOT less lines of code, so it's a bit easier to follow what's happening...

That doesn't help in any way if you need to track down the use of some variables in order to add some functionality. I am really not interested in how every minute detail of it works, but if I can't even figure out, where, for example, I have to alter the current colormap to use a different one for a specific piece of wall, I cannot work on such features.

[dpJudas]

That doesn't help in any way if you need to track down the use of some variables in order to add some functionality. I am really not interested in how every minute detail of it works, but if I can't even figure out, where, for example, I have to alter the current colormap to use a different one for a specific piece of wall, I cannot work on such features.

The primary reason this gets so difficult is because the code transfers function arguments by globals rather that using, well, function arguments. For a simple example, here's the beginning of R_MapPlane:

Code: Select all

void R_MapPlane (int y, int x1)
{
    int x2 = spanend[y];
    ...
}

The function should have been R_MapPlane(int y, int x1, int x2), but the second argument is passed via working data of the parent function. This gets particular bad when it comes to colormap, light and texture coordinate handling where the code mixes this with placing the variable in its eventual final destination before being sent to a column/span drawer. It effectively means you have to have a firm understanding of the entire process from R_RenderBSP to colfunc to track a specific feature.

[Graf Zahl]

Yeah, that was precisely the reason why I got nowhere with this stuff...

[Major Cooke]

Not to mention some of it still needs floatifying, doesn't it? What better of a time than now to do so?

[dpJudas]

Actually, those particular variables will always be integers.

[Major Cooke]

Eh, I was told the renderer wasn't finished with floatification switches yet.