The biggest issue with refixing Browsercade has been Globals.. But why has that been such an issue?

-=-=-

The thing about Browsercade is that it IS actually written in a well coded manner.

Each and every function is full of local variables, things are very "properly" coded, and the whole engine worked well enough without too much of an issue.
Each game uses a bunch of globals, though. There's a giant plr[] array, a few grid[] arrays, and along with a few of the standard a-z single character variable names, much of the game is standalone.

Browsercade was written in the style of "Functions are their own set of individual local variables, games use the main globals"

JSE was originally written like this, too. Functions be functions, your script is it's own thing, and in-between are the globals for storing the parsed script and your variables and what not.

But during all the many stages of Optimisationalism that I've been doing to JSE, one thing was increasingly apparent.
Every time Javascript has to hop in and out of a function, it creates these local variables, and then discards them at the end.
.. Every time.
A LOT..
And the Garbage Collector would come along every 10 or so frames and go "oh, gosh, oh golly, there's a lot of garbage here. All these discarded variables.."
And that would slow the engine down quite a fair bit.
Constantly creating and freeing variables is REALLY quite bad when you're whizzing through hundreds and thousands of functions every single frame.

And I know what you're thinking.. You're thinking "But Jay.. .. That's how you're supposed to do it."
And I know..
I agree.
That's why Browsercade (and Shoebox, and Foldapuz) are all coded in that way.
And if you ask anyone out there, they'll also tell you to be adding little const declarations all over the place, because "it's quicker for Javascript to read a const than it is to read a variable"
And that's true, too.
Absolutely.
100%

But..
Let's say that const is in a function..



That's the sort of thing that people will tell you is incredibly "correct"
But it isn't.
Because if you do that 10000 times per frame, you're creating, and freeing 10000 slots of "const c" memory, every frame. Not to mention the speed of the jump into the function, the localising of a and b. And then the return value on top.
It's actually really quite bad.

In most cases, you won't ever notice this. It's only when you're pushing things thousands of times, every frame, for the purpose of a high framerate based game, that it becomes apparent that this methodology just isn't really very well optimised!

Which is why, over the past few years, I've been doing a ton of "undoing" of that sort of thing, throughout JSE. I've taken things back to the style of globals-everywhere, and that's actually freed up a ton of these little tiny stuttering bits that would impact the games.

Now, that's not to say that YOU should do this.
I'm working on my own, I'm managing all of these functions, and .. generally I can spot when an error's cropped up because of my own Global issues.
Most people will be coding "for other people's eyes", and .. I can tell you, the more I'm "fixing" browsercade, the worse the code is getting!
At this point, it's almost as bad as JSE's internal code, and I'm fairly sure it's only going to get worse.
Managing this code in future will be horrific, especially if I start forgetting bits of things.
For right now, at this particular moment, things are "better" this way. For me. In this particular situation.

Please don't learn my bad habits!

... BUT..
Do always try things out, do always stress test them, and do always see what's "really" going to work the best.
Don't just take other people's word for "best practices", especially when optimising for speed and compatibility.