Do you need tutorials ?

SGDK only sub forum

Moderator: Stef

kubilus1
Very interested
Posts: 237
Joined: Thu Aug 16, 2012 2:25 am
Contact:

Re: Do you need tutorials ?

Post by kubilus1 » Wed Jan 09, 2019 11:28 pm

Miquel wrote:
Wed Jan 09, 2019 5:43 pm
kubilus1 wrote:
Wed Jan 09, 2019 1:30 am
we know exactly where the collision occurred.
No, you don't. You only know that in a line graphical sprites overlap, nothing more. And that's after losing about 50% of the cpu.

Anyway, if you are sure just do it. We learn more from our failures than from our success, so it’s a win/win, don’t worry.
Is that so.

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.

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?

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.

Our generous host here on spriteminds talks about essentially the same simple case: http://gendev.spritesmind.net/page-collide.html

Chilly Willy
Very interested
Posts: 2763
Joined: Fri Aug 17, 2007 9:33 pm

Re: Do you need tutorials ?

Post by Chilly Willy » Thu Jan 10, 2019 8:26 pm

It uses 50% of the CPU because of all the overhead for 16000 ints per second. Hblank ints aren't free, and one per line absorbs a massive amount of CPU time, even with a small routine. It's probably not 50%, but it's a significant percentage that could be spent doing other things.

kubilus1
Very interested
Posts: 237
Joined: Thu Aug 16, 2012 2:25 am
Contact:

Re: Do you need tutorials ?

Post by kubilus1 » Thu Jan 10, 2019 9:24 pm

Gotcha, for hblank interrupts. Makes sense.

The specific simplified example wouldn't need that, however. Sorry if that wasn't clear. It would only check the collision flag during the main loop.

But yeah, basically what you are saying about the number of checks in the further examples I gave being a lot of wasted clock cycles.

Sik
Very interested
Posts: 868
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Do you need tutorials ?

Post by Sik » Fri Jan 11, 2019 2:06 am

Just firing an interrupt every line (with an interrupt that returns immediately) will eat up about 10% of the CPU. So yeah…

Also there's the problem that in practice you really don't want pixel-perfect collision: e.g. with enemies or other hazards you want to allow some contact before it registers (to be more forgiving towards the player), or be more loose and allow some transparent pixels to count towards collision for things like collectibles (again, to be more forgiving towards the player), and some parts of a sprite outright may have been never meant to be collidable, etc.

For context of how bad it can be: the reason why ET falls into pits as soon as you exist them in the Atari 2600 game is because pixel-perfect collision is used and ET happens to be touching the pits (even though one would expect only the feet to collide!).
Sik is pronounced as "seek", not as "sick".

Stef
Very interested
Posts: 2967
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Do you need tutorials ?

Post by Stef » Fri Jan 11, 2019 8:41 am

Only a very few commercial games rely on the collision bit.
Barbie Super model game uses it to determine collision in the driving section, i guess they located sprites in a way it could work... but let's be honest, it's probably the worst MD game ever released officially. I remember another game using it but it was just to help the collision detection... still about 99% of games don't use the flag at all, probably for a good reason ;)
Still if you can find some situation where it can help, ok why not using it but these are edge cases which happen rarely in 16 bit games (too many sprites, gameplay mechanic too complex to rely on perfect sprite pixel collision).

Chilly Willy
Very interested
Posts: 2763
Joined: Fri Aug 17, 2007 9:33 pm

Re: Do you need tutorials ?

Post by Chilly Willy » 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. :lol:

The Amiga had some of the best hardware collision detection, being able to record collisions based on the sprite group, and which plane for sprite/plane collisions. That made it easier to determine what actually needed further checking. And then most games don't use it, because as mentioned, pixel perfect collision detection tends to piss off gamers.

kubilus1
Very interested
Posts: 237
Joined: Thu Aug 16, 2012 2:25 am
Contact:

Re: Do you need tutorials ?

Post by kubilus1 » Fri Jan 11, 2019 9:14 pm

Interesting about the interrupt itself using a lot of clock. For my many collision FPS tests, I wasn't showing a big impact, but I was 'ifdef'ing out the logic _inside_ of the hblank interrupt, rather than the entire hblank interrupt. Dropping this entirely going forward.

(Though I suppose for some games that use hblank interrupts, Thunderforce III, Sonic, various racing games, it's not enough overhead to be a problem.)

Agree about pixel-perfect collision. It intend to use a bounding box for objects/sprites. Otherwise, I'm going to take the approach of checking sprite rows first, then bounding box. Using a sort of list based approach with a callback so I can check stuff like my_bullets vs enemy_sprites and call 'explosion' that kind of stuff.

Chilly Willy
Very interested
Posts: 2763
Joined: Fri Aug 17, 2007 9:33 pm

Re: Do you need tutorials ?

Post by Chilly Willy » Sun Jan 13, 2019 6:45 pm

When you use hint a few times per frame, it uses little time and is a powerful tool for effects. When you use it EVERY LINE, then it becomes a huge time sink. Granted, there are times when such a thing can be warranted and useful, but it's going to absorb a lot of cpu time, so keep that in mind.

Miquel
Very interested
Posts: 446
Joined: Sat Jul 30, 2016 12:33 am

Re: Do you need tutorials ?

Post by Miquel » Tue Jan 15, 2019 1:50 am

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. :lol:
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? ;)

kubilus1
Very interested
Posts: 237
Joined: Thu Aug 16, 2012 2:25 am
Contact:

Re: Do you need tutorials ?

Post by kubilus1 » Tue Jan 15, 2019 11:33 pm

Okay, you convince me. The VDP_COLLISION flag is pretty much completely useless.

mallow
Newbie
Posts: 1
Joined: Wed Jan 30, 2019 8:29 am

Re: Do you need tutorials ?

Post by mallow » Thu Jan 31, 2019 8:25 am

I'm a beginner and would like to ask Stef to get back to doing the tutorials if he is ever free to do so. They've helped me feel less intimidated going into this. Only problem is now I'm mostly stuck looking between the included sprite example and the open source Cave Story port just to get any further examples on how an actual game works. The Sprites tutorial is also too old, as mentioned on the tutorial itself. It references a VDP_setSpriteP function which doesn't even exist anymore. I thought maybe this was just VDP_setSpritePosition, but the parameters for that one clearly differ from whatever that old function was.

Anyway, I'm glad to at least see Stef is still updating the tool and talking about it :D

Stef
Very interested
Posts: 2967
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Do you need tutorials ?

Post by Stef » Thu Jan 31, 2019 12:23 pm

The best way to learn SGDK is to look into the 'sample' folder from SGDK, you have several examples and the 'Sprite' sample is probably the best one to look at as it covers many aspects.

nekete
Newbie
Posts: 3
Joined: Mon Nov 07, 2016 5:52 pm

Re: Do you need tutorials ?

Post by nekete » Tue Apr 02, 2019 1:22 pm

I would be great to have something with an scrolling map + collision detection example.
Something to know how to scroll "huge" maps and collide with them.

Post Reply