optimization o'clock part 2 electric boogaloo revengeance & knuckles.8 final mix director's cut golden edition for Wii U

so apparently it's been a week since last post???? and i didn't even notice. 

anyway the bois n i have been at this coding shit and it's all like dam gurl so fast like wo

lemme show u a sample of what we got.

Zoom

so let's start off with an easy one

this code is parked at the end of the script that updates every single event that has a sprite. each of these lines calls a function that calculates a lot of data about where the event is relative to you, and how zoomed in its sprite should be.

i'm mostly interested in the zoom lines.

now, TILEWIDTH and TILEHEIGHT are both defined variables. their purpose is kind of obvious. both of them have set values since the tile size doesn't change when you're in game.

let me show you those values.

now, class.

could someone please tell me what you get when you divide either of the two tilesize variables by 32?

anyone?

essentials?

here's what the code looks like now.

better.

this probably doesn't look like that substantive of a change, and, yes, compared to the sheer number of calculations that need to be done per frame, this is kind of a drop in the bucket. to this, i counter:

- this keeps two functions from being called per event per frame. if you're in, say, charlotte's gym, these functions would get called a grand total of 9,120 times each every second

- it's literally just one 

- it doesn't even do anything

- it's just like "oh hey let's change the zoom from 1 to *shuffles notes um, 1" which is literally not even a thing

which leads me to

Math

if you read through my entire last post (thx btw!) you'll remember that i was very tilted by the fact that essentials calculated the value of 128*4 a grand total of 8 times per event per frame via the in_range? function (which i'll be coming back to!). so, 72,960 times per second in charlotte's gym.

this was not necessary. it was never necessary. it filled my heart with despair and my soul with rage.

well.

WE GOT A WHOLE LOT MORE WHERE THAT CAME FROM

Weather Updates!

the snow and sandstorm lines hurt me. why would you have the thing multiply something by two and then divide by four. why not just divide by two? better yet, why not just set them all to the same value in the first place and then drop the value in there? this isn't even nearly as big of an issue as the 128*4 thing but it just bugs me.

you can't even see the whole time because rmxp's script editor is ass, but i think you can get the idea here: all this does is multiply a bunch of shit together that doesn't need to be multiplied, and it gets called thousands of times every second.

it doesn't have to be this way.

i could go on, but like, do you really want to see me complain about math more? no, you don't. suffice it to say that about half the time i see a function is running absurdly often or absurdly long, it tends to be doing a whole bunch of stupid math. it offends my sense of justice.

are you SURE you're in range??

this one i particularly wanted to include in the event that you also happen to make these games and are particularly interested in some shit that can help speed things up.

good news!

this is some easy shit that you can just grab for yourself.

nearly every single aspect of the code that affects the overworld operates through one central script: the Scene_Map update function. nearly every aspect of your entire gaming experience has some sort of roots in that single function. it pushes all the overworld processing to two separate scripts: Game_Map which deals with the mechanics of the map itself (where events are, what maps are connected to it, etc) and Spriteset_Map, which handles everything you see on your screen. essentials comes with some helpful anti-lag scripts that use the in_range? function and the event trigger to determine if an event actually needs to be updated. it's actually helpful! it saves some time updating events that literally do not matter.

here's the thing.

despite the fact that the two major functions handle a lot of the same objects, they don't coordinate with each other at all. that leads to a lot of duplicated calculations.

but there's a fix for that!

in game_event:

in game_map:

in spriteset_map:

and boom. ur game already goes at the speed of zoom.

is this a deep bush?

this is gonna be a short one because i'm getting tired.

i've mentioned functions that run on a per event per frame basis. what this basically means is that the code runs for every event on the map regardless of what is, every single frame of the game. these functions are the core of why some places simply lag to hell: the game is updating so much shit that your computer- even with the hippest, hoppest, newest CPUs- can't keep up (especially on speedup). the reason that 18.4 was such a huge improvement is because it took a massive chunk of those updates and yeeted them.

well, i'd now like to give you part 2: bush edition.

when something is in a bush in pokemon, it looks different. we all know this. when something is in a big bush, it looks big different.

but in reborn, nothing is in a big bush- except for you.

so we just 

yeeted the code that dealt with that!

and wow is it faster.

you can even see for yourself!

(i've updated the patch on the downloads page, too, but not the main downloads. it's not worth that level of effort.)

anyway. trying not to pass out on my keyboard.

there's still a lot of fixes i haven't mentioned that will be in e19 and just require more testing before i let them out into the wild.

but that patch has some fancy new in_range functions along with it.

if it breaks someone's game i will cry.