Speculation on why the methods exist:
http://pastebin.com/P2w2C42H
...
[18:15] <10Kaphotics> so ya the methods are caused by the IRQ handler chewing up frames as it so desires?
[18:34] <Bond697> not exactly
[18:35] <Bond697> the calls to create the pkm are extra calls from outside the one at the end of the main loop
[18:35] <Bond697> the way it works
[18:36] <Bond697> the game runs through one main set of calls that interpret movement, play a bit of sound, play a bit of graphics, handle controls, check for a battle, check for being in/approaching a tile where a battle can happen, etc
[18:36] <Bond697> at the end of the loop, the vblank runs and clears the screen for the next to bed rawn
[18:36] <Bond697> *to be drawn
[18:37] <Bond697> the frame probably advances right before that
[18:37] <Bond697> (the rng frame) through a rand(); call or something
[18:37] <Bond697> so when it’s creating a poke, those are extra calls
[18:38] <Bond697> the methods could be a result of the main loop running at specific times during encounter creation
[18:38] <Bond697> instead of all the calcs running through one trip through the main loop
[18:39] <Bond697> honestly, it’s probably their own fault
[18:39] <Bond697> everything i’ve ever read about gba programming says not to use division and not to use modulus
[18:40] <Bond697> they have no computational accelerator on the gba and so have to be done through software
[18:41] <Bond697> the fact that most everything is done via modulus might cause weird timing issues that leave the game to catch up
[18:42] <Bond697> fishing, for example needs to have running water drawn, has to do a bunch of modulus calcs, there’s a lot going on
[18:43] <Bond697> so the game probably falls behind, finishes the main loop, and starts over again, leaving a gap in the calcs
[18:44] <Bond697> the methods outside of specific event stuff might only exist due to bad programming
[18:45] <10Kaphotics> well said :D
[18:46] <10Kaphotics> the game still uses mod for the *100 level calc in gen 4/5 tho
[18:46] <10Kaphotics> guess it isn't as bad compared to fucking %100 a 65536
[18:46] <Bond697> well
[18:46] <Bond697> there’s a computational accelerator in the ds
[18:46] <Bond697> for div and mod
[18:46] <10Kaphotics> ah yes
[18:46] <10Kaphotics> and then that too
[18:46] <10Kaphotics> however they did the mod
[18:46] <Bond697> in fact, the div i/o registers always return both
[18:46] <10Kaphotics> revealing the errors in nintendos ways :D
[18:46] <Bond697> the div and the remainder
[18:46] <10Kaphotics> you should post that
[18:47] <10Kaphotics> "the mystery of Method 1/2/3/4
[18:47] <Bond697> maybe
[18:47] <10Kaphotics> and one can definitely argue that no spreads are exclusively one method or another
[18:48] <10Kaphotics> due to that "game runs through the main set of calls", milliseconds of time
[18:48] <Bond697> 60x/sec
[18:48] <10Kaphotics> which explains how I was able to get multiple Methods with different tiles
[18:48] <Bond697> it probably just falls behind
[18:50] <Bond697> i would put money on it not being a coincidence that modulus is hard on the system and that there’s weirdness in the calcs that create the method
[18:56] <Bond697> actually
[18:56] <Bond697> every other frame
[18:56] <Bond697> after the game makes the pid
[18:57] <Bond697> it has to run a modulus of a small number (0x19) against a large number(0-0xFFFFFFFF, usually closer to the high end)
[18:57] <Bond697> well, after it makes the temp pid
[18:57] <Bond697> i’ve run through those so many times, they take an incredibly lrge amount of instructions
[18:57] <Bond697> *large
[18:58] <Bond697> because it avoids division and has to do mod and div out via shifting and adding
[18:59] <Bond697> thats probably it right there
[19:01] <Bond697> err, it does mod 25 every time
[19:01] <Bond697> either way, it’s a lot of reducing