optimization o'clock

good morning.

let's talk optimizations.

we all know that essentials is, uh, slow. in fact, it's so slow, that 18.4 isn't even the first release to be at least partially based on making it faster.

what is difficult to overstate is just the sheer extent to which this is not necessary.

everyone who makes the game knows this.

that second meme was a big enough deal that it got me to make another release. after everything i've been through. it was just such a big speedup that keeping it to just the devs actively felt bad.

so let's do storytime.

Event Optimizing

this is the real basic stuff. in-game events on the map (trainers, doors, anything that results in a change to the map as a result of some kind of interaction) are easily the biggest sources of lag. you can tell what maps have a large number of events simply based on how slowly the map runs. calcenon Gym is my baseline for how laggy the game is simply because of the sheer event density on that map. so a few months ago, when all this optimization shit started, it began by seeing what events were unnecessary and could simply be condensed to a smaller number without resulting in any changes to the overall gameplay. 

an excellent example of this is spinel.

every disappearance in spinel takes up some quantity of events. originally this was done with one event per tile that changed as a result of one teleport.

take the pokemart. here's how it disappears in 18.4:

the pokemart uses 16 events to disappear.

here's how it is in e19: 

three! one for the graphic, and two to trigger the change if you touch them. the entire graphic is just moved into the one event.

some areas will definitely be faster because of this, but the downside of this sort of optimization is that it's limited to the areas that have been checked over- and we really have a lot of places that would need to be checked. 

which leads me to

Script Optimizing

we've known that there's bloat in the scripts for a while, but the script-side of things is so obscenely large that it'd take ages to find anything to fix that has any sort of impact on actual gameplay.

and then: toothpastefairy.

toothpastefairy is our newest, freshest dev. i've mentioned him before as the person behind the battle factory- y'know, the thing that we literally did not expect to happen. this was before he joined the team, too. the sheer number of bugs on our to-do list was enough for him to be promoted from honorary dev to actual real life dev. since then we've been getting shit done left and right. bugs getting squished. memes gettin made.

then, one day, he comes in with this.

i hooked up the profiler for myself, and we just went to town on this shit.

here's some of what we've got.

Quad-calcing the terrain tag

the above snippet of code is used to determine whether or not a sprite would reflect off the tile in front of it. in doing so, it grabbed the terrain tag four separate times- which is, itself, a time consuming process. fixing this was as easy as assigning the output to a variable and then using the variable for the comparison.

is this a map?

the terrain tag checking process itself involves taking the coordinates of a tile on the map and shuffling through every layer until you hit one that correctly has a tag.

however, it also includes this.

are you on a map?

of course you are. you're playing the game.

this was removed.

128*4

so we know that 128*4 = 512 because we can do math.

the in_range? function calculates it again just in case.

and it does so four times.

and is one of the most frequently called functions in the entire scripts.

why.

this was changed to 512.

is this a control?

every frame, the game processes whether or not you have a button pressed down. it does so using a process along the lines of this:

here's the thing. there aren't 256 keys on the keyboard. we barely even have half of that. 

this was carved into three separate sections that go through the keys that actually exist.

the one line change

this is the big one.

*breathes

okay.

so let's talk about what this does.

essentials uses a function to determine whether or not a sprite should have a reflection.

this conditional is what essentials uses to add sprites to the list of sprites that should be reflected.

under normal circumstances, this is determined by whether the event itself specifically says it is not to be reflected. essentials will assume that all sprites should be reflected unless they are explicitly told not to.

the issue here is that we literally have thousands of events. no one is ever going to put /noreflect/ on every single one of them

so instead, the new code checks one thing and one thing only: whether the player is currently in serra's gym (map 506).

do you know what's easier than quad-calcing the terrain tag?

literally never calling that function at all.

we've been working up a storm over at Not GameFreak HQ with patching things up left and right

but it is truly difficult to overstate exactly how huge of a change this is.

every single event in the game used to go through this giant function, and now it doesn't.

the change was so freakishly huge, it dropped the frame time reported by the profiler by over 60%.

now granted the profiler isn't exactly the best at calculating the total time spent on individual functions... but look at the sheer size of that drop for such a minor change. it was inspirational- so much so that i put out another update. after everything i've been through. my computer crashed twice. i had to rebuild my mac vm. but we did it. it's here.

it's worth noting that 18.4 only includes the one line change right now. it's small enough that it doesn't need to be tested in advance. anything else and i'm worried some weird aspect of this engine will just make everything break completely. 

but you bet your ass this shit'll be in e19.