Dwedit wrote:
So yeah, I might be making a NES version of Chu Chu Rocket at some time. I've calculated that you can get all possibilities of mice entering and leaving squares, as well as different wall positions, within 256 tiles per scanline.
So you're char-plotting the mice then? I suppose that's the only viable option given that that the original game often shows whole columns of 16x16 mice parading across the screen.
I'm not entirely sure what you mean by 256 tiles per "scanline" but personally I'd just pre-render all the combinations of mice entering and leaving the various tiles from various directions into CHR-ROM. And since all of the mice move in step with each other you'd easily be able to animate the entire movement across the a tile without actually touching memory simply by switching ROM pages (e.g each page would correspond to one phase of the animation.) Plus with a bit of double buffering there would be plenty of time to replace the old tilemap within the blanking periods.
But perhaps that was what you meant?
Dwedit wrote:
The big question is how to iterate over a map and calculate new values for mice on the map, can it be done within 16 frames?
I honestly don't see how it's much of a problem. 16 frames is a great deal of CPU cycles, and it's not as if the movement patterns are very complicated. Plus you only have to deal with nice integral coordinates on a grid with less than 256 squares. Hell, you could handle the mice as cellular automata rather than game objects in the usual sense if you wanted to.
Why not simply pre-calculate the next step at each square and for each direction into a table in RAM? That, plus some collision detection so you don't run into another mouse, ought to account for most things in the game as far as I can recall. Granted, I never actually got all that far so perhaps there's worse things to deal with later on in the game.
Good luck with the project at any rate, it's certainly a nice little puzzle game well-deserving of a NES port!
edit: Lets make a rough estimate of the worst-case scenario. Say there a hundred mice on the screen, we've got half of the total CPU time to dedicate to movement logic, and we're in "turbo" mode so we want to perform each move in only four frames instead of sixteen. This still leaves 600 cycles per mouse.
I don't care what method you adopt, you'd have to be trying not to fit the movement routine within that limit!