okay lets say a game uses a slowrom, which is about 2.7 Mhz, and it is space shooter that slowsdown at with about 10 bullets on screen and 10 enemies. 2,700,000 cycles per second / 60 frames per second = 45,000 cycles per frame 10 bullets * 10 enemies = 100 collision pairs 45,000 cycles per second / 100 collision pairs = 450 cycles per collision pair What kind of collision detection takes 450 cycles? I myself made an algorithm that only takes up to 44 cycles at max (with 11 cycles being the minimum) but I have no idea how anyone spend a month making such a complicated formula for something that is that fairly simple. I know collision isn't the only thing the cpu has to do but you would think it must take up a large portion of it's time. I just don't get what is running these programmers minds. People say programmers make slow code when they're rushed, but the only reason why my code is so fast is because I actually made it easy on myself. It's like this, any normal person, when put in the task of writing something like a collision detection algorithm will think of two options: Will I make the simplest code so I can get done easily, or will I make a complicated code and spend a year on it? Any normal person will choose the first one. But programmers, they think, "I don't have enough time to make any decision what so ever, I must pick the worst of the two because I didn't have enough time to pick the better one" and makes the most complicated codes that take up both their time and also the cpus time. My brain just doesn't work that way sorry. I don't care if your brain works like that, my brain doesn't and will never do. EDIT: looking around these forums, I found this: Yes it explains it, A LOT!
It does seem that taking the complicated road early on would be smart because it makes things easier later in development, where taking the simple method makes it harder to have a "tight" game. But I'm also sure that many programmers don't pour their heart into things early on because they expect there to be changes that they'll have to rewrite things for anyway...
Yeah, no. Being a programmer myself and having worked with quite a few others, I can safely say that not all programmers think that way. Actually, I'd be surprised if anyone thought that way. From my experience, programmers (myself included) start with the most obvious solution, then, if they have enough time, consider other possibilities. Sometimes there won't be enough time, or the programmer can't see any other ways to accomplish a certain task, so a bad solution may exist in the codebase - that's where code refactoring comes in. Then stop complaining about it. Going around saying "I'm really smart, why isn't everyone else as smart as me?" isn't really going to accomplish anything other than making you look arrogant. Are were ever going to see this collision detection stuff you're harping on about? Or are you just going to keep telling us how great you are, without providing any evidence?
And as mentioned, the game will never come anywhere near that many cycles dedicated to just hit tests. The game has to go through each sprite and check that it's in bounds, then is has to update its position and velocity if it's supposed to be speeding up / slowing down. On top of that decisions have to be made about what state the objects on stage are in and what their current sprite is. Add in managing the score and any effects and the list goes on and on. It may even turn out that their algorithm is actually better than yours and all of the other factors are causing the slowdown.
You are incorrectly assuming that the game does absolutely nothing except blow through collisions every frame. Most of the memory bandwidth will be used by the PPU for graphics. As far as Japanese programmers using C, that's mostly false. I bet they were the ones who used the most hand-optimized 65816 assembly code. The one instance where that might have stemmed from is Chrono Trigger - the game engine's written in C. You'll still have to use assembly for direct hardware access (possible in C but not elegant.)
first of all, updating the coordinates with a specific velocity, only requires one add. Wow if it takes someone 100 cycles to do, than he must be mentally insane. Second of all, how can the PPU take up most of the CPUs cycles, if the CPU is only allow to access it only during V-blank and H-blank anyways. third of all, most special effects can be done with only a prerendered table in the rom and the using HDMA. forth of all, I actually have faster collision detection algorithms, I just wanted to be nice.
Well, darkangel I have a good idea for you. I suggest that you disasm Gradius III and figure out how the game works. As I mentioned in another thread, the game suffers pretty obvious slowdown when you have 4 options and laser. Perhaps you could find how they determine collision and put in your own optimized version in place of it. Another thing, the comment about SNES games and programming in C is false. While some SNES games were programmed with C, generally they were not all so. The only way to find out if a game was is to disasm it and study it. Compilers tend to produce code that can be spotted as being C and not written in ASM by a human.
