Scrolling Game Development Kit Forum
SGDK Version 2 => Help, Errors, FAQ => Topic started by: Jam0864 on 2007-03-30, 11:10:53 PM
-
How do you detect when one sprite hits another in SGDK2?
-
There are two rule types that can be used in a sprite definition or a plan to determine if sprites are colliding: TestCollisionRect determines if the sprites' solidity rectangles are overlapping (this is a simple/quicker test); TestCollisionMask determines if the sprite's collision masks intersect (as defined by the Mask Alpha Level on the Sprite Definition - States tab). The second is similar to the per-pixel collision tests from version 1, but it's more flexible and more optimized (faster) than the collision testing in version 1.
For a detailed example, you can check durnurd's awesome new project :)
Look in Maps - TestMap - Layers - Foreground - Plans - Sprite interaction
-
I can't seem to find that rule type. I seen it in durnurd's project before I asked and couldn't see it in mine, so I thought he must have used scripting. I looked in the unfinished features topic and couldn't see collision detection there so I asked here. So in my project those rule types don't exist for some reason. I can't select them because they aren't there. :(
-
I vaguely remember durnurd asking me about why that rule didn't exist for Plans, so maybe he manually copied/adjusted the code to work with plans, and I haven't implemented that in the alpha yet. The rule is probably only defined for Sprite Definitions right now. But you can copy the rule implementation from the PlanBase.cs file in durnurd's project and put it into your own PlanBase.cs file and then the rule will be available after you re-compile your project (F7). (See how easy adding rules is? :))
-
Actually, it's the other way around. They ONLY exist for plans, not for sprite defs.
-
In that case you'll want to copy said function from durnurd's SpriteBase.cs to your SpriteBase.cs.
-
Actually it doesn't really matter if the collision functions don't exist in the sprite definitions since you can do it with plans. Thanks! ;D
-
After testing the collision mask can you make the sprite bounce of each other or stop them from going through each other?
-
I haven't written any code to support that yet.
-
ok, in that case here is what I have done so far, in an example project of my own. ;D
http://www.box.net/shared/p0dh2ykozs (http://www.box.net/shared/p0dh2ykozs) (approx 200kb)
You don't have to follow the arrows if you don't want to, there's no real reason for them yet anyway. I just put them there to see how they looked and to set up a general course. ;)
Controls are,
Player 1
up-accelerate
left-turn left
right-turn right
down-brake
right ctrl-Nitrous (you have unlimited at the moment but I plan on changing that.)
Player 2
W-accelerate
A-turn left
D-turn right
S-brake
left ctrl-Nitrous
So, what do you think. :)
-
The turning looks pretty weird. I think it would look better if you used RelativePosition.CenterMiddle instead of RelativePosition.TopLeft in your Turn Right and Turn Left rules. Also the solidity is not working properly because you are moving the sprite before reacting to solidity. You should have your "Move" rule after your "React to solid walls" rule.
-
Yeh the turning is better like that. :) I wondered why the solidity wasn't working, thanks. :) What other stuff should I add to it? ??? I was thinking some computer-controlled racers. To race against, having to do laps of a track or something. Maybe some traffic. Also I reckon a slow-mo function. You get a certain amount of slow-mo, you can press a button and the game goes slow to assist with cornering. Sort of like Need for Speed Carbon. Is there a frame limiter in SGDK2? I was thinking only to turn it on when using slow-mo. ;) or I could do it a different way, constantly add heaps of transperant sprites, the game will slow down because the computer can't keep up a good frame rate. lol But I'd prefer not to do it that way. ;)
-
Slowing down the game by means of CPU usage is highly discouraged, since it means your game is taking up 100% of the CPU, which slows down other processes, and is uncontrollable, and most importantly, acts differently on different processors.
A frame-rate limiter would be the best option, or if you had a Speed counter that you multiplied all velocities by before moving, then you could set the speed simply by changing the counter, which also allows for some things to not be affected by slowing down the game.
For example, a default speed of 100, then you multiply all velocities by Speed value(100) then divide by normal value(100), so if you set speed to 80, a car going at a speed of 5 would then go at a speed of 5*80/100, or 4.