oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Mar 12, 2010 17:31:16 GMT -5
....Each game has its own specific collision requirements, so a custom solution is always best.... moon is absolutely right If there is a universal way to implement collision detection, that works for 90% of games, then I will implement it in assembly . There is really no easy way to detect collisions between individual non-transparent pixels of sprites without the use of the Status register collision bit. This bit is asserted to 1 if any sprite's pixel overlaps another. The only kind of collision detection I can think of is associating a rectangular vector to each sprite, which has a resolution of 1 pixel. Then I could make a routine to check the collision between other vectors, and then decide which sprite collided. Basically, when the collision bit is set to 1, then we go and execute our collision detection routines, so our slow collision detection routines are not running 24/7. It doesn't work for very complicated games, but for the ones like Galaxian, ect, it works.
|
|
|
Post by theelf on Mar 12, 2010 17:54:34 GMT -5
there is a way to detect collission between a sprite and a tile? because is difficult to me to explain my idea in text, i made a graphical example, i have a map of tiles Scroll A or B, with transparent background, and put a sprite There is a way to detect that my sprite overlap a object?? think that the objects really are tiles that are part of the tile map If is possible to make this, i can use for example scroll A to objects, an scroll B to the rest of the level Thanxs!!!
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Mar 12, 2010 18:01:36 GMT -5
To detect a collision between a sprite and a tile in the tile map....you'll have to do some calculations of your own Yea, I can't describe the process 100% right now. Kaneda has some great tutorials on how to do this though! spritesmind.net, then go to tutorials
|
|
|
Post by theelf on Mar 12, 2010 18:09:07 GMT -5
Thank you. I told my wife, I shall pass all Sunday with BasiEgaXorz.. ;D Hope in one day, i can do something usefull!! because of work, rest of week is very difficult to find time...
|
|
|
Post by theelf on Mar 22, 2010 21:53:19 GMT -5
Hi, im still thinking in the collision() function, is broken or not? i think yes
I need simple collision between 2 sprites, dont care what sprite is
I found a old PONG example, that use the collision function, and not work now ... but in a old version sure works..
Any workaround?
Thanxs
|
|
|
Post by TheMVRules on Mar 24, 2010 14:27:52 GMT -5
' Collission Detection Calculation check_x1 = ((car_x [and] &hFFF8) - 128) >> 3 if (car_x [and] &h0007) = 0 then check_x2 = check_x1 else check_x2 = check_x1 + 1 endif check_y = top_location+15 if check_y > 63 then check_y=check_y-64 ' locate 10,10: print readtile(check_x1,check_y) tile_1 = readtile(check_x1,check_y) [and] &h07FF tile_2 = readtile(check_x2,check_y) [and] &h07FF if tile_1=&h0DB [or] tile_2=&h0DB then locate 10,16: ink 2 print "Crashed!" if score& > high_score& then sleep 60*3 locate 12,16: ink 2 print "New High Score!" high_score& = score& endif waitpadup while (joypad().7 = 0) for a=0 to 500: next b++ randomize b wend goto reset_game elseif tile_1=asc("$") [or] tile_2=asc("$") then score& = score& + 100000 if tile_1=asc("$") then drawtile &h020, check_x1, check_y if tile_2=asc("$") then drawtile &h020, check_x2, check_y endif This is Devster Turbo Cars' tile-sprite collision detection (and game over screen) You could try with it however it would need some edits.
|
|
|
Post by theelf on Mar 25, 2010 11:29:15 GMT -5
Thanxs for the code, i see the demo of the cars.
But this is done in software true?
i read that the collision detection routine read a hardware flag.. this is 0% CPU
|
|
|
Post by TheMVRules on Mar 25, 2010 11:37:18 GMT -5
Well, as you can see the VDP are doing all of the dirty job for the 68000 here... Ask DevSter about it.
|
|
|
Post by Alex Khan on Mar 26, 2010 14:15:43 GMT -5
Build your own collision routines. Each game has its own specific collision requirements, so a custom solution is always best. Compile collision data to be suited for a initial broad-phase collision sweep ( grid / quadtree / proprietary ) instead of relying on complex data such as sprites. www.metanetsoftware.com/technique/tutorialA.htmlwww.metanetsoftware.com/technique/tutorialB.htmlHere are two tutorials on collision for a 2D platformer .. written for modern hardware, but can be adapted easily. Oh very nice tutorials moon.
|
|
|
Post by TheMVRules on Mar 26, 2010 14:17:46 GMT -5
They are not nice for 16-bit 8mhz crappy 68000-based systems. And they wont fit you since you're making a Double Dragon styled game, those are for platformers only.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Mar 26, 2010 14:37:11 GMT -5
TheMVRulesYou don't want to copy the techniques used in those tutorials 1-on-1 obviously .. but the concepts they mention ( AABB for sprites, grid as spatial index for tiles ) are solid and applicable for low-spec hardware. Heck, one of the first things I tried in BEX was a simple 2D physics engine written entirely in Basic, and that ran just fine. You're right though, a Double Dragon type of game requires completely different collision techniques.
|
|
|
Post by TheMVRules on Mar 26, 2010 14:41:49 GMT -5
I say that Kaneda's tutorial is better, but I haven't tried them hard yet, but I will... You're also right that every game needs different routines. Remember Sega Megadrive's limited 64 kb RAM, that's a large limitation.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Mar 26, 2010 20:20:44 GMT -5
Just had a look at the "sprite collision" document on SpritesMind, and it's not all that different from the tutorials I mentioned .. although Kaneda's write-up is far more detailed and is optimized for a specific type of game. But it only covers sprite vs sprite collisions, while the metanet tutorials primarily focuses on a solution for sprite vs tiles.
|
|
|
Post by TheMVRules on Mar 27, 2010 10:18:31 GMT -5
Because we already know sprite vs tiles. Look at Turbocars example source.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Mar 27, 2010 12:10:45 GMT -5
The turbo cars routine only checks whether collision has occurred after movement has already taken place. For your game that is sufficient since you want to explode upon collision .. in a RPG you usually don't want the character to explode when walking into a table.
Anyway .. in the end people should just use / read / do what they think serves their game best.
|
|