aaaah ok, nice

I guess that's the power of assembly ^^

I'm not because I can't think of any fast way to do it. Unlike Galaga-like games, there's not really any pattern as to what is going to hit what.

One thought was to only check for enemies that are in it's path, but this takes more time than just checking all.

Wow!  You plan to use x^2, /, Enter, and On as the boundaries of the square?  That's a big square!   Also, if you're using On you must use check it differently than the other keys and use some combination of Mode 1 and Mode 2 interrupts (I'm assuming you're already using some.)  That sounds hectic.  Good luck!
I can't wait for this game.

Oh, and are you going to update your other games so they don't display the warning?  Thanks!

I see how I could do that, I would just add an extra byte to each enemy data set. That is a good idea but I see a few problems that it would cause.

1. When an enemy or bullet straddles two partitions, (I guess I could just use a bitmap system and check both)

2. The other problem I see is the guys who dodge bullets, but they could just always be checked for collision.


Well with that out of the way I guess I'll do this. I'll relocate the enemy data buffer to extra ram because it completely fills saveSScreen. I will use 8 sections so that it will bitmap one byte. Four vertical columns with a middle splitter.

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).

The only last problem that I see is when original problem 2 occurs. Partitioning won't work here and when the circles are the only enemy on screen, it will be right back where we started.


In response to the new posts while I was previewing this.

I currently have mirage interrupts enabled, but that obviously won't work so I will probably kill them completely as I don't actually use them.

The attachment doesn't display the message. But then again, a lot of stuff is changed, this is just my current updating version.

Edit:
    As far as too big of a change, I just converted the whole program from 3 bit physics to 8 bit, I will basically change anything if it is for the better.

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?

The partition code sounds neat.  It also sounds hard, so good luck!

It's too hard to control with 16 buttons, going back to the way it was before.

I think I'd personally prefer the way it was originally, so I would have used it that way anyway.

For the extra ram page, I only have 1 so I never use more than one. And I was actually the person who put that info about 2.53 in wiki ti . (Missile was being restless)

The Penguin, you're awesome.

Nice!  I really like the new version!  Excellent job.

Dividing the game area into 4 parts for the collision detection is a smart idea.
It can be used in any game that has a lot of objects that enter into collision checks.

Continue the progress. ^^