![]() One need only look at later generation shooters on the SNES and some of the amazing work Compile did on a great many platforms to see that collision detection doesn't have to be an albatross around the neck of a shooter. Even non-optimal code will run faster when you ramp up the clock speed of the chip running it. While "porting" the game up to the SA-1 certainly helps, because the SA-1 is effectively a slightly more modern and faster version of the SNES CPU, the actual collision code is probably only minimally altered. Red roms are similar between all versions but green roms differ, which means that if you wish to change the game's region or language, it may be possible make the change simply by reprogramming fresh roms with other version's contents. Collision detection calculations can be performed a number of different ways, and my suspicion is that early SNES games like Gradius III use collision routines that are simply not at all optimal for the CPU architecture. Konami 1989 Below is a table representhing the roms for Gradius III (Japan) and its clones (if any). Once you have lots of bullets and enemies on the screen, the system has to monitor all those different objects to see when they collide with each other. ![]() The major cause of slowdown in older games is collision detection calculations. Even though the SNES CPU is really not all that fast, I do think with better coding it could have kept up with Gradius III much more effectively than it did.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |