Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / Glitchy collision

Author
Message
Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 5th Nov 2011 05:51
Is there any better way of doing collision with multiple enemies at a time? I have this collision (Its in the MoveEnemies function) but its REALLY glitchy, the enemies will push each other off-screen and just spaz out constantly. I've been trying to fix it, but to no avail.



Also if you can help me with my shooting system, I made it awhile ago, but it still doesnt work, I planned on fixing it later, and its later, but I don't know whats wrong. Its mainly in movebullet function, but there also a bit in playerinput function and the main loop.

nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 5th Nov 2011 08:24
Quote: " ...the enemies will push each other off-screen and just spaz out constantly. "


Two suggestions:
1. If you don't want your enemies going off-screen then add some IF conditions to them when they reach the perimeter ie "IF enemy.x < 0 THEN enemy.x = 0". You could play around with that and expand upon it.
2. Your enemies are "spazzing out" most likely because they are detecting one another and trying to compensate. Basically Sigmund comes too close to Carl so Sigmund moves up. But Carl detects he's too close to Sigmund and he moves up too. Sigmund detects he's too close to Carl... Cycle. This is why having the right array data is important. For example Badguy(n).dir, Badguy(n).hit, etc. That way you can control movement better and set flags.

LBFN
17
Years of Service
User Offline
Joined: 7th Apr 2007
Location: USA
Posted: 5th Nov 2011 14:40
Here is another way you could it. I haven't tested it to the Nth degree, but a few initial tests worked okay:



The enemy(b).x values did not seem to be working, so I put in the check to get the sprite x().

Chris Tate
DBPro Master
16
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 5th Nov 2011 14:49 Edited at: 5th Nov 2011 15:08


Wow, this soo doesn't look right, it has changed alot from the last time you posted it.


Edit: The code posted by LBFN could be used; but at least learn where you made mistakes.

There are problems in this block of code. Take your time as you read this.

1: Firstly, what does status mean? Why not check the status of the other enemy as well?
Quote: "enemy(b).status = 1 and a <> b"
I mentioned this before. If both status should be 1; then some of your enemies without this status setting could be collided into.

2: The following line is checking if a sprite's Y position is within a distance.
Quote: "IF abs(enemy(a).y - enemy(b).y) < sprite height(enemy(b).id)-1"
. What happens if the sprites X distance is far away? They will still think that they are close. You must also check that the X position is close as well.

For example, if A is on the top left corner of the screen and B is at the top right corner; just because their Y position is the same, doesn't mean that they are colliding. This is only half of the collision IF statement, you need to AND check the X position in the same IF block.



3: It appears that you swapped dec enemy(b).x / y with: enemy(b).x = sprite x(enemy(b).id). You know what this is doing? It is telling the enemy to stay still. If enemy A is colliding below B, B should move up: dec enemy(b).y, 1

4: The collision is choppy because of how far you are pushing the enemies when they collide: inc enemy(b).x, 9. 9 Pixels in sync is not very smooth; picture yourself running to the toilet 9 metres per step, not very smooth. . The purpose of the code is to tell the enemies to move away not teleport away.

5: If an enemy is busy moving out of the way, it should not be trying to move towards the player at the same time. You can't walk towards and away from something at the same time; you cannot bump into an enemy, move away then tell it to bump into the enemy because the player is that way.

Instead, use normal movement only when not colliding:



This is getting a bit confusing, you should create seperate functions for movement and collision; and use the movement function to call the collision check, to see if the enemy can move towards the player; to keep seperate tasks seperated; it's easier for you in the long run to be able to reuse the code.

Do not hesitate to let us know how you get on

Your signature has been erased by a mod please reduce it to no larger than 600 x 120.
Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 5th Nov 2011 17:42 Edited at: 5th Nov 2011 17:53
The enemy(b).status makes sure the enemies are placed properly.
Its in this:



And the AND statement I didn't think of that, I'm just kinda confused at alot of this because when your moving them all, then if just one collides does it not go through with the ELSE statement and they ALL stop moving? Thats mainly whats confusing me, I know the computer can handle things extremely fast at times, but it just seems hard.

EDIT: I think I was right, nothing moves now O.o

EDIT TWO: No, its not the ELSE thats doing it.

I guess I'll just figure it out, now I just need help with my shooting system.

(Look at top, its kinda spread out everywhere, which is probably one of the reasons it doesnt work)

Chris Tate
DBPro Master
16
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 5th Nov 2011 19:31
Quote: "The enemy(b).status makes sure the enemies are placed properly"


Cool. Still check if the other enemy is placed properly and in active status, as clear consistent practice: IF enemy(a).status = 1 and enemy(b).status = 1 and a <> b

You could do the a <> b check in its own IF branch if you wanted to save a few CPU ticks.

About the collision Else branch; the block of code after the Else keyword should only run on the current enemy (B), and not all of them; and it will only perform the actions when it does not collide with another enemy.

If the enemies never move, they are always colliding, or always think they are colliding because something was not coded properly in the IF statement, or are always thinking that the player is nearby
or are not moving more than 1 pixel per loop. No other reason could possibly cause them to stay still from what I can see.

Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 5th Nov 2011 21:18 Edited at: 5th Nov 2011 21:27
WORKS!

Some of the >'s were <'s and that messed it up, but its fixed (You also forgot to update the positions afterwards)



They still will kinda sink into each other if they collide from both the x and y (Colliding diagonally)

EDIT: This doesnt work either, im not sure why.



And here's TrackStats()



Chris Tate
DBPro Master
16
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 5th Nov 2011 22:07
Quote: "EDIT: This doesnt work either, im not sure why. "


Explain. What's gone wrong?

Do you want it to display the health gradually increasing? If so, you'd need to let the user see what is going on by using Sync somewhere in the repeat loop.

Quote: "Htmr = timer() + 0050"


Do you use prefixed zeros for style? 0050 should just be written as 50. It will still recognize it as 50 ms (20th of a second).
Quote: "

They still will kinda sink into each other if they collide from both the x and y (Colliding diagonally)"


True, they will move diagonally because we have not made them very smart yet. If a number of them collide they will get confused, moving north east, then south west over and over again until the blocker moves out of the way. This issue is your next phase in AI programming; you need to now help them to understand how to avoid over crowding each other.

Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 5th Nov 2011 22:22
How would I do that? Would I need to add xDirection and yDirection in the entity type, and have to track all of that? I don't like having to do that, but I can if I need too, it probably won't be the first thing I work on, that would be the bullet system, the collision is fine. Though I will do it at some point because I need to learn this stuff.

Chris Tate
DBPro Master
16
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 5th Nov 2011 22:44
Quote: "I don't like having to do that"


Good, keep thinking like that

Less is more, more time for

The less code you have to write, the better; just try to think how the problem can be solved without too much work. Currently you are not using the Sprite Angle system and the Move Sprite command; so you could do with an enemy crowd prevention solution that works with 2 forces (x & y).


I'm not the man to give advice for creating bullet systems, but
just remember that projectiles, enemies and players are all just sprites as far as the engine can see in your system.

Just think about the similarity projectiles have with enemies and reuse them; as an example, if you wanted to check the collision between the ground and a falling rock; the ground is 1 pixel thick, the rock is 2 pixels in diameter and the rock is falling 20 pixels every loop.

[]
.
.
[]
_____________
.
[]
^

The rock will fall through the ground if you tried to detect collision on with a radius of 1 pixel. So what needs to be done? We need to check collision at a larger radius; the speed of the rock.

Now how you choose to handle moving elements like that is up to you; but inbetween large steps of movement, collision needs to be calculated along the path of movement from the current position to the next. There are plugins that help you with this, and maybe some snippets around the forum.

Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 5th Nov 2011 22:59
Should this work?



And this is in playerinput()



Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 6th Nov 2011 03:03
I hate it when my post gets pushed down really far.

Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 6th Nov 2011 22:48


O.O

Login to post a reply

Server time is: 2024-11-27 18:25:32
Your offset time is: 2024-11-27 18:25:32