Eventually that will go poof, too. As dpJudas said, one thing at a time. This was indeed the lowest hanging fruit to get rid of.
What I find interesting here is that 90% of the assembly's justification was make-believe, not fact. In the grand scheme of things the improvement here was perfectly zero, or even less, because this code utterly blocked any genuine renderer optimization that may now be doable.
Multithreaded rendering
Moderator: GZDoom Developers
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Multithreaded rendering
That's merely the cached info. If you clean out the cache and start a fresh build, they are no longer there.Nash wrote: [EDIT] should the CMake files be updated too? Those Assembly checkboxes should be irrelevant now... ?
Re: Multithreaded rendering
It did remove one build thing from the list. I rewrote the slab (voxel) drawer, as it was build code before, when moving the drawers to those command classes.Graf Zahl wrote:Eventually that will go poof, too. As dpJudas said, one thing at a time. This was indeed the lowest hanging fruit to get rid of.
By the way, I forgot to delete the r_drawt.cpp file in my PR. That file is no longer used (replaced by r_drawt_pal.cpp).
Well, to be fair, in the early days the C++ compilers were a lot worse at optimizing and the maps were simpler. Back then they did improve performance. It is a nice example of how stuff once thought as fact can change over time, though.Graf Zahl wrote:What I find interesting here is that 90% of the assembly's justification was make-believe, not fact. In the grand scheme of things the improvement here was perfectly zero, or even less, because this code utterly blocked any genuine renderer optimization that may now be doable.