[MinaciousGrace]

Originally Posted by MarioNintendo

He removed all code Kyzentun wrote from his stepmania fork

Well, the statement was made mockingly. Even if I do arrive there eventually that's not how it is now. All I'm doing now is using basic performance analysis tools to find out what areas of the code take the longest to execute. Deconstructing those segments of code to figure out what they're doing, why they're doing it, and how they're doing it, independent of the original author. Then I determine whether or not what's happening is fucking stupid.

For example, the ragevcolor function was doing almost as much if not more work during the gameplay screen than the entire 3d rendering engine. All this function does is take 0:1 float values and convert them to unsigned characters to represent the 255 rgb values which are then fed into said rendering engine. A little more digging revealed that this was because of an lrintf call inside the color function.

Essentially they were doing this, value*256 - 0.5. Basic math right. Then they passed it to lrintf, pretty straightforward. What does lrintf do? It rounds. Very slowly. As far as I can tell with 20 minutes of research lrintf and the standard library lround accomplish the exact same thing, except that lrintf will round towards the current rounding mode (apparently you can set the rounding mode to always round towards 0, or away, and so on and so forth) and lround will always round using standard convention.

I think to myself, gee, there must be a really fucking good reason why they're using lrintf to round rather than lround which is 10x faster. They must have a round mode set somewhere in the game. So I looked. Nope, not that I could find. I mean, I wouldn't put it passed them to have done it in a way that intentionally obscures that its happening, but I doubt that. It's just a case of pure fucking ignorance, laziness, and probably the fact that none of the devs have ever run performance analysis on the game despite being told it runs like shit.

So the solution? Replace lrintf with lround. All the colors look the same. Fps doubles.

FPS DOUBLES.

FPS DOUBLES.

FPS DOUBLES.

You see then I thought to myself hold on, wait, wait, wait. Do we even need to round? They're subtracting 0.5 and rounding, isn't that more or less (apparently the details of this get pretty messy) like using floor, or even better, directly converting to integer?

Here is the original comment regarding the function: "lfintf is much faster than C casts. We don't care which way negative values are rounded, since we'll clamp them to zero below. Be sure to truncate (not round) positive values. The highest value that should be converted to 1 is roughly (1/256 - 0.00001); if we don't truncate, values up to (1/256 + 0.5) will be converted to 1, which is wrong".

I don't see why or how (1/256 - 0.00001) should be converted to 1 when (1/256 + 0.5) shouldn't be. You also probably shouldn't be mistyping the function you're calling in the comment about it. What's lfintf?. The fucking irony. Anyway, if you don't care about negative values, and you are only going to truncate positive values, WHY THE FUCK ARE YOU ROUNDING? Just truncate it, aka, class to int and drop the decimal points. Now, now, hold up. It turns out that technically rounding and truncation do NOT provide the same results. Here is the comment message I left: "Casting as int results in 128 out of the 10million possible values converted to be one shade different compared to using lround. This is not a level of precision I care about. However if we want to be nitpicky about 1/256 not being rounded up to 1 we can very well do that. - Mina"

We turn :

int ret = lrintf(a*256.f - 0.5f);
if( ret<0 ) return 0;
else if( ret>255 ) return 255;
else return (unsigned char) ret;

into:

int ret = static_cast<int>(a*256.f - 1/128000);
CLAMP(ret, 0, 255);
return static_cast<unsigned char>(ret);

Now the practical reality of any colors displaying incorrectly on the screen is 0 (incorrect according to the original function, at least, whose correctness I dare not guess at), and even if it happened the 1 shade difference would go unnoticed to any human observer. Oh, right, and FPS is just about tripled during gameplay. But here's the thing. I don't give a shit about rainbow diffusing things in my theme. I don't care about them changing colors all the time, so I don't have much that actually changes colors. Now I don't know this for sure because it was irrelevant after changing the function, but, even with the pre-existing inefficient function there's no way that it should be hogging that much processing power while calculating new colors whenever an actor changes color. So the only conclusion is that actors recalculate their color each time they update whether or not they actually change their color.

Basically that means your "red" note travelling up the screen, like a fundamental homophobic christian who walks into a mens bathrooms and sucks off strangers to see whether or not he magically turned gay last night, needs to recalculate its "redness" to make sure that actually is still "red" every 1/120th of a second (or whatever your refresh rate is, probably once every 2 seconds for whatever cereal box kyz is playing on). Nice.

edit: in fact now that I'm looking at this again I'm pretty sure I misinterpreted the original comment and that 1/256 should be rounded up whereas 1/256 - 0.00001 should not be, what threw me off was the fact that what they're currently using doesn't do that anyway. Either that or "up to" means "up to and including" and they want 1/256 + 0.00001 to be rounded up while 1/256 isn't. Except that isn't what's typed. Also the qualifier of "roughly" -0.00001 isn't helping me here either. I actually have no goddamn clue what they precisely want, all I know is that functionally I could add a random value between -0.01 and 0.01 every time color is calculated and nobody would notice. So I'm just going to go ahead and change it back to a pure integer cast until jousway comes in here and tells me that because I incorrectly rendered a colored pixel a non-widescreen kawaii-quarkwave was generated that literally destroyed the entire universe of xAnime245 where particles only exist in 1:0.

So @jellowave and @klowntunez. I don't have anything to prove. If you want to intentionally avoid reading through my commits and what I changed and why, and then come in here and make snide comments assuming nothing has changed and that we're all in a collective hysteria, then fine. You can do that. It doesn't functionally matter to me or anyone else in this community. I'm going to keep doing what I'm doing and if what I'm doing works people are going to use what I give them. Maybe not everything I changed is for the better, but it's you who have something to prove, not me. It's you who have something to explain. You want to prove that your code isn't shit? Then don't implement any of the changes I've made, or will make in the future.

Gauntlet thrown, bitches.