This is epic, its so awesome to actually have a full port of a pokemon game for the calculator.  Its really well made and i cant wait to see where you take this

I know that i was able to get a shade of blue using xLibs contrast change, and by changing it rabidly from max to min and back again.  I dont think its equivalent to the BSOD.

Sounds awesome!  What other kinds of features are in the works/planning to be worked on?

DJ, I leave for one week and this is what happens seriously though, a long time ago i saw this from the outside, and thought the same thing many of the haters think today.  But when you get on the inside and learn the full story, you realize how courageous and amazing you really are.  Do what you have to, get some R&R, and take your life where it needs to go.

Actually storing the data by adding on a byte to each object would not work in speed critical scenarios i think.  The fastest way that i can think of is to have 4 stacks, one for each partition.  At the start of each frame, when you figure out which partition an object resides in (it may reside in more than one, as you said) it would add a pointer to that object to the appropriate stack. Then when collision is calculated, you would go through each individual stack and calculate the collision inside of them.

I don't feel like doing all the math for this, but this should give a significant increase in speed. In your math, couldn't you just simplify 4((B/4)*(N/4)) to 1/4 * B * N. I also don't understand why you add in the 2(N + B).

Yes you could simplify this, but that equation isnt for computational purposes, it is just an equation to show how efficient on average this partitioning is going to be.  I left it unsimplified so that we could see the math behind calculating how many collision would happen on average.  The 2(N+B) is because at the start of each frame, we dont know which partitions the objects are in, so we need to quickly run some comparisons to figure out where to put them.  It takes 2 comparisons (>middleX and >middleY) to figure out where to put them, so it would be 2 comparisons for every object (N+B), so 2(N+B), and since this is independent of the actual collision process, we add it to the end of our equation.

How to the circles dodge bullets?  That would be an interesting challenge.  Then again, we could leave the space partitioning handling when bullets actually collide with enemies, and then leave regular N^2 for all of the special effects such as dodging.  Im curios as to how the dodge though, what do they do?

EDIT: And if your running out of ram, since you have about 200 objects max, and the partition data needs only a byte (pointer) for each object, could you use perhaps appBackUpScreen?  Or tempSwapArea? Or textShadow if you want to limit yourself to 128 ish objects max? or just increase file size by a meak 200 bytes to get some free ram without breaking compatibility with newer calcs?

Yeah both of those would be great i think.  Although im not sure how well the HLine() VLine() would work in his current parser, it might be completely token based right now, and hard to change o.O

Yeah because with 30 bullets and 90 enemies you're doing some 3000 collision detections every frame :O Are you using any sort of space partitioning to decrease this amount?

Looks pretty monstrous to mee Now i am thinking about how i would accomplish this myself