Global variables... depends on the application. I've yet to actually hear any real arguments against them outside of "compiler confusion" and "name collision". The first can be fixed by forcing compiler makers to get off their lazy asses and fix their shit, and the second can be fixed by forcing coders to get off their lazy asses and fix their shit. You obviously don't always use globals, because in normal coding, local variables are often more efficient, and the larger the application, the more noticeable it becomes. However, in HuC, it's the other way around... globals are noticeably better for a multitude of reasons, not the least of which being the fact that HuC has *still more bugs* when it comes to variables... I discovered this when fully entrenched in MSR's code. It's hard to explain and even harder to trace, but it worked like this...
In two cases, global variables declared at the module level were not acting as designed. This was noticeable when doing cutscenes. The values of two variables were being ignored by if statements and were incrementing to their full values before overflowing and coming back to levels where if would recognize their value range. This was especially apparent in the case where I was using one to do a palette rotation... the colors spazzed out for quite awhile before they finally started cycling correctly. However, this problem only manifested when the game had been running for awhile... if you just started up the game and used the debugger to go directly to the parts where the bug happened, they worked as designed. So I figure it was memory corruption of some kind. However, by moving these variables out of the module and into globals.h, the problem disappeared entirely and things worked as designed all the time.
