About what I've been trying to achieve in the SW renderer is always one out of two things:
1) Either it is the futile attempt at doing 'separation of concerns' in a codebase nobody ever heard about it for 20+ years. I.e. notice just how many places the light calculation code is copy-pasta in that codebase. I'm trying to move things closer and closer to their true home. Basically I want to make the renderer first figure out what it can see, then setup a drawing of the object (wall, flat or sprite, light and renderstyle), then tell the drawer to do it. Light calculations should be shared as that setup, not be copy pasta 50 places in the code. The clip list management likewise needs to happen in classes meant to only do that. The wall coordinates needs to be by itself, etc etc. Normally I would just rewrite this kind of code, but in Doom's case I don't fully understand the reasons why #23 of the 50 copy-pastas are arranged a little bit different, has a check missing, and so on. Is it because I'm looking at a bug where someone forgot to update the copy pasta? Or are all the other places missing that check? Or is the check redundant? Is there a special case rule that needs to be accounted for? Ah it is lovely to work with this kind of code.
2) Or, I'm trying to isolate the code for multithreading purposes. In simplified terms, in order to multithread things I need things done so you can see them as what would be called a Task in modern frameworks. That means certain things needs to be done at certain cutoff points in order for me to be able to move the next processing to another thread. I also need the data in question to be clustered right so that I can move a single struct for the task input or output.
In this particular commit I've been doing #1. However, the larger reason I might have been doing it was to achieve #2 in a series of multiple commits.