by Rachael » Tue Oct 04, 2016 7:17 am
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.
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.