it helps with everything.What do you mean? Do you simply mean that buffering values in variables is faster than looking them up in arrays? Or do you mean that accessing RAM would be faster than accessing ROM, so that code runs faster when I copy it to RAM first?
So while you can look up tables in ROM, you also have to have the table in the same ROM as your code, maybe that works maybe it doesn't. But you will still need to read a value from an index into another index and then look up the value, vs just read the value. The fast calculations are the ones you don't have to do.
So how often do you need to update the collision, well once the object leaves its current spot and crosses a "boundary" when does it do that? well you can mostly work that out on the fly, but then you only want to change the state or do more logic if that value changes, i.e its going left and it was on ground and still is on ground then do nothing, no change to make. Knowing what it was on is faster. But you need RAM to cache it.
Ent to Ent collision, having an X or Y sorted table really speeds it up, as you will know what a sprite can stop checking faster. I.e you know the sprite is 16 pixels high, then once you get to entity that is above y+16 you abort, as no entity down the list can collide with you. Y tables need RAM. Do I look up its 16 high, or do I just store my table of upper Ys, lower Ys, lower Xs, upper Xs. When I inc y I just inc both, dec x etc but this way I don't need to look up the ent size, by getting its type, moving to the right ROM bank, reading, doing the maths and doing the compare again and again as I loop through, I just read them all with the same index.
Need to look up 2d data, such as map collision data, put each row into its own page so you have 10 rows then you can storeY into the hi, keep the lo 0, and then lda (zp),y where y is the x index. But you have RAM and now you can self mod, so
lda $XX00,y is 4 clocks, not 5, but then you don't have to keep 2 ZP locations, you don't have to store the lower as 0 to be sure, it will always be zero, you just write the the XX byte and go. Don't want to trash the y for this, then store X in the 00 and don't use y. Need to use a value again down the code, don't waste a ZP that is precious, just store the value into the param of a LDA, LDX, LDY # ahead when you need it again, its smaller and faster.
You can build unrolled loop to handle each entity update you currently have on the screen to avoid doing loops and look ups each time. I.e you know entity 2 is a Bat and so you can just
Code: Select all
ldx #0
jsr routine
ldx #1
jsr routine
ldx #2
jsr routine ; set this to be the bat update
RAM is speed, it boosts practically every aspect of code, reduces index pressure, smaller code, faster code, gives you more ZP back for other optimizations.