ZDoom

One thing that needs investigation: There seems to be a discrepancy in particle size between ZDoom and GZDoom. But I haven't changed anything in the GL code about it so I suspect some incorrect scaling in the software renderer.

Or A problem with cameras.
And Texture alignment issues.
This seems also to be a floatification related problem.

Not floatification related, but decals are not being rendered on 3D floor sides.

That's everything I could find by scanning through the list of open bugs.

randi wrote:Does somebody have a list of issues? I forgot where I was with it.

Three major issues were found, from what I've seen

Particles weren't rendering, this was fixed. There were some projection issues with the fix, but I believe these were fixed also
Also from that thread, slopes weren't rendering right under most circumstances. This has also been fixed, and I don't think any issues have shwon up
Skyboxes aren't rendering. This problem still seems to be present

I also noticed a problem with Midtextures getting scaled weirdly when transparent and wrapped.

If it's of any help, it seems you stopped on the renderer itself now that I'm looking at your commits alone, beginning of May.

Does somebody have a list of issues? I forgot where I was with it.

Indeed. It's just the particles had issues a while ago from the floatifying being incomplete so I still wonder if it needs finishing yet.

That may or may not be, but it will always remain integer to some degree.

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

Actually, those particular variables will always be integers.

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

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

Graf Zahl wrote: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:
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.

Eruanna wrote: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.

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.

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.

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...