03 June 2018, 20:02 | #21 | |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Quote:
Right now I could have a code like this: Code:
for f =0 to num_enemies for g = 0 to num_bullets if enemyx(f) > bulletx(g) - 8 if enemyx(f) < bulletx(g) + 8 if enemyy(f) > bullety(g) - 8 if enemyy(f) < bullety(g) + 8 colide() endif endif endif endif next next But this is very slow and if you have many bullets and many enemies, it will take a huge portion of a frame to do it. |
|
03 June 2018, 20:04 | #22 | |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Quote:
If you only check one object against one object per loop your game won't work properly, missing collisions all the time. I really think the Grid idea works great with checks against background, since it's easier to keep everything on a grid and you can probably do a whole shift in a grid when the screen moves very quickly (I guess). But with stuff that moves freely on screen to many different directions I am not sure it would help at all. |
|
03 June 2018, 20:07 | #23 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,773
|
Your still trying to check them all in 1 game loop they only move what 4 pixels max per loop you won't miss anything.
Even if you check them all at once like your code above it should be quick. |
03 June 2018, 20:17 | #24 | |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Quote:
[ Show youtube player ] if I remember correctly, enemies move 2 pixels when they move, player laser moves at 8 pixels. What I did on that game (and keep in minding I was still learning a lot of this stuff and I know it wasn't the smartest way) was first check if the laser sprite was colliding with the color of the enemy (all the enemies have a color in common). If it is, then figure out what enemy the laser is hitting. With all 12 enemies on screen, I had to do just 48 checks. Believe it or not, THIS CAUSED a hiccup on the game. I switched to test just half of enemies at one loop then half of the enemies at the following loop. Many times I just missed the collision on the next loop because the laser had already moved past the enemy. So when the laser hits an enemy, on the next frame if its not destroyed (when it didn't detect what enemy it was hitting), the laser does not move. But the enemy still moves and sometimes I'd STILL MISS the collision because of this. So I changed the movement of the enemies, which ended up helping gameplay. Half of enemies move in a frame, half of the other enemies move at the other frame, up until you have just 6 enemies on screen. This made the enemies move faster when you have less enemies (something that was already planned, but I wasn't going to do it this way), so I was ok with it, but I really scratched my head on how hard this was. Of course on this game specifically I could have used a grid approach since the movement is a lot more restricted (and there was no need to check sprite collision against playfield before checking what was causing the collision, I am pretty sure this just created unnecesary extra overload), but like I said, I was still learning (and still am ) |
|
03 June 2018, 20:24 | #25 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,773
|
Good luck dude I'm sure Daedalus holds the key in his knowledge of Blitz
Also I would say dont move all Bullets at once move them 1 by 1 per game loop or maybe ive totally lost it |
03 June 2018, 20:27 | #26 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
This is a test I've made
the blue balls are just bouncing around the screen. They are 3 bitplanes 16x16 bobs, they are blitted every frame and their logic add a value to X and Y and test if they are at the border of screen (if so, invert speed), then blit it on screen. On this test I have a total 16 "blue balls" the red on the background is time the frame takes to run its logic (plus erasing and blitting all of them on screen, with no background restoring) the purple on background is the time I waste checking if any of the blue balls colide with *one* sprite (the ship), using the method I showed above the yellow is how much free time I have in the frame If I wanted to check against 6 sprites instead of just one, that purple area would be 6 times bigger. This little test alone wouldn't fit on a frame. I am also baffled of how long it takes to process this simple logic of the enemies + blitting (I should test how much of this is just the blitting), but for now I am just thinking about how to better collision checks This is running on Winuae, FULL ECS Cycle Exact, 68000 , Cycle Exact CPU Frequency 2X (A500). Not sure how much accurate is this though Last edited by Shatterhand; 03 June 2018 at 21:02. |
03 June 2018, 20:35 | #27 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,773
|
is it not possible?
*****Main Game Loop**** For I= To Eternity Joystick stuff Text Stuff Move Hero BoB BulletX[N] BOB + 4 ; **Move Bullett*** IF BulletX[N] = Ship Then Hit N=N+1 if N=Max Bullet N=1 Wait Blitter Next I |
03 June 2018, 21:02 | #28 | |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Quote:
And then you are considering I am testing all bullets against one single "ship", not several ones. |
|
03 June 2018, 21:07 | #29 |
Banana
Join Date: Jul 2016
Location: Darmstadt
Posts: 1,214
|
You could check one sprite per frame, but rather than checking just the current position, check the sum of positions since the last check. Create a bounding box based on the vector. That would deal with collisions missed since the last check, although you might see the bullet going through the enemy in some cases.
|
03 June 2018, 21:09 | #30 | |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Quote:
I thought about this. Maybe not 1 sprite per frame because it's too low, but half of them per frame. It could be good enough, though still a little heavy on the cpu. |
|
03 June 2018, 21:24 | #31 |
Banana
Join Date: Jul 2016
Location: Darmstadt
Posts: 1,214
|
You could also do a bit of loop unbundling - test all sprites each iteration. It'll save a good amount of jumps and a comparison each time.
Code:
For each bob do If (is collision (sprite1) then... Else if (is collision (sprite2) then.. ... Else if (is collision (sprite n) then... End if Next |
03 June 2018, 23:28 | #32 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,336
|
Even coordinates can be unbundled to save some checks - there's no point comparing the Y coordinates if the X coordinates aren't within collision range, for example. Compare the short side of the hitbox first and you'll eliminate more redundant checks.
If you're actually using sprites, there's hardware collision detection available which is more or less for free on real hardware (though it's CPU-intensive to do under emulation) - it's one advantage of using sprites versus blitting. |
03 June 2018, 23:44 | #33 | |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Quote:
Sprite vs Sprite collision is great and very fast indeed. Unfortunately it's not the case here.. sprite vs Playfield collision only tells me a collision happened, not where did it happen, so you have to do the checks anyway. Also about sprite X sprite collision, each pair of sprite channels share collision detection too. If you check sprite Channel 0 against, say, sprite 7, a collision between sprite 1 against 6 will return a positive too. |
|
03 June 2018, 23:57 | #34 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,773
|
|
04 June 2018, 00:07 | #35 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,336
|
|
04 June 2018, 00:28 | #36 | |
Registered User
Join Date: Jul 2016
Location: ware
Posts: 3
|
Quote:
Can you turn the division into a multiplication in this instance and get the same result? I’m assuming if cellsize is always constant it might be doable? Sent from my iPhone using Tapatalk |
|
04 June 2018, 00:33 | #37 |
Banana
Join Date: Jul 2016
Location: Darmstadt
Posts: 1,214
|
I just wrote the dullest game - random bullets bounce around the screen and if one touches the enemy, it dies.
8 bullets (sprites) vs 10 enemies (bob), seems to work fine with collision detection, under standard A500 config (winuae). 16 colours, not that you'd know from my graphics. Granted, there's no sound or control or anything, but it seems to run fine with "everything vs everything" collision detection, and I'm not using the sprite vs playfield. Full source attached. It could probably be optimised, I just threw this together to create a test-bench. One question - how do I get the damned sprites to disappear once I don't want them? If I stop doing DisplaySprite they just stay where I left them... |
04 June 2018, 00:52 | #38 | |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Quote:
My sprite 0 is always just a blank sprite and a draw it on the channel I want the sprite to dissapear. |
|
04 June 2018, 01:12 | #39 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
E-Penguin, just tested your code here. On my Winuae configuration its NOT running on one frame.
I really need to test this on real hardware, I don't trust winuae for those timing tests too much (Even though I know Toni does a hell out of a job with it ) |
04 June 2018, 07:09 | #40 |
Banana
Join Date: Jul 2016
Location: Darmstadt
Posts: 1,214
|
How can you tell its taking longer than a frame? I assumed because the red bar was relatively constant (not flickering between frames) it was all done before each vwait.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
SetCol/DoColl-How to test collisions with different sprites against different colors? | Shatterhand | Coders. Blitz Basic | 1 | 12 January 2017 18:51 |
Quickest code.... | Galahad/FLT | Coders. Asm / Hardware | 10 | 01 January 2017 17:23 |
[REQ:ASM] Sprite collisions basics | jman | Coders. Tutorials | 5 | 03 September 2011 00:07 |
What is the quickest way | Doc Mindie | support.WinUAE | 6 | 17 October 2007 21:15 |
Disable Sprite Collisions | DeAdLy_cOoKiE | Retrogaming General Discussion | 4 | 24 March 2006 17:56 |
|
|