Chilly Willy wrote: ↑Fri Jan 11, 2019 2:26 pm
Hardware collision detection was more of an 8-bit thing than 16-bit. When you had a 6502 running at 1MHz, you really needed all the help you could get.
The other day watching a speed run on "Super Mario Bros" I discover that it's code only checks for character collisions only once every two frames. Previously, creating a prototype game on NES I discovered it’s a pretty tight scheduler what you got, sure you can't have more than 4/5 characters on screen, but I didn't thought it was that limiting.
kubilus1 wrote: ↑Wed Jan 09, 2019 11:28 pm
Also, why would this use 50% of the CPU? Check a flag once per frame should be well within the power of the mighty 68000.
The 68k was designed at the very late 70’s with a very small amount of gates compared with nowadays cpu’s, even so was SO revolutionary because it could do many advanced things for that time. How they did it? Using microcode to avoid having specialized large groups of gates for a single function, the downside: it takes time to run the microcode. Today there are cpu’s that can do a context exchange in a simple single instruction time, how? Having a piece of the die only for that.
Even more, the 68k is compatible with older peripheral interfaces and that takes extra time to check for.
In addition, it waits for the start of certain timer before the interruption even starts; this time is usually not taken into account when doing the maths or in emulators.
If you take this considerable amount of cycles and add the save/restore for all the used regs, and then multiply by 60 fps and then by 224 (or so) exceptions per frame, you get that 50% aprox.
In synthesis, the 68k was astonishing at calculus at that time, but it’s not intended to be a device attending sub-cpu (Just the contrary of the SNES cpu). The idea was to use another chip for those tasks, Motorola conveniently sold you the 6800 back then.
kubilus1 wrote: ↑Wed Jan 09, 2019 11:28 pm
If ball.y pos is below the midpoint of the screen then the collision could only have occurred between ball and player2. The ball x,y would indicate the location of the collision in this simple example. Why would it not?
Following your game example, notice you don’t get the x coordinate for the collision that way. And no, it’s not the same as ball.x. And why we need that coordinate? Well even “Pong” for 2600 returned the ball with an angle, otherwise you don’t need to move the paddles at all. How do you think that angle is obtained?
kubilus1 wrote: ↑Wed Jan 09, 2019 11:28 pm
So in the example I gave, if you have three sprites, a player sprite above middle of the screen, a player sprite below the middle of the screen, and a ball sprite, if we have VDP_COLLISION set, this can *only* mean there is a sprite collision between player1 and ball or player2 and ball.
Correct, but notice all the things you have lost to only avoid four simple comparisons:
- Around cpu 50% time
- No more than 3 strictly functional (meta-)sprites
In the other hand you can deal with it with 1-4 lines of code and an average of in worst case scenario, let’s say, 64-88 cycles per collision detection (I did some fast math); in other words: no effort both for you and the cpu.
Sik wrote: ↑Fri Jan 11, 2019 2:06 am
Also there's the problem that in practice you really don't want pixel-perfect collision [...]
Even today not a few big selling games have evolved nothing from 30 years ago, except going with one more dimension; for example, fighting games still use 2 collision boxes. Or even going back, many games only check one point when checking the feet (or the wheels).
A lesson to learn here?
HELP. Spanish TVs are brain washing people to be hostile to me.