Sorry your browser is not supported!

So, I'm sort of new to the physics functions in AppGameKit and haven't used them a whole lot yet. I'm trying to have fast-moving bullets that can shoot in any direction from the player (the player can rotate) plus I want the bullets to bounce off of wall(s). I got the bullets to shoot and move fast from the player by setting the bullets' x's and y's based off of the joystick x and y components. But I don't know the best way to be using the physics so the bullets bounce off walls -should I be using a force,impulse,velocity, and if so, how should I be using these functions to easiest achieve bullets bouncing off walls.

SetSpritePhysicsImpulse( iSpriteIndex, x, y, vx, vy )
SetSpritePhysicsIsBullet( iSpriteIndex, bullet )

walls are sprites with static physics.
SetSpritePhysicsOn( iSpriteIndex, mode )
mode - The physics mode to use for this sprite, 1=static, 2=dynamic, 3=kinematic

useful:
SetSpriteGroup
SetSpritePhysicsRestitution
SetSpritePhysicsDamping
SetSpritePhysicsAngularDamping
SetSpritePhysicsCanRotate
SetSpritePhysicsFriction
SetSpriteShapeCircle

Personally, I'd avoid using physics for bullets. I mean, I think it's kinda asking for trouble, to have a tiny bullet sprite with it's tiny collision frame trying to bounce off stuff. Then there's the problem with them hitting each other, all the organisation and stuff that goes into preventing that effectively.

I would make a type, with position, velocity, sprite ID etc etc and use the collision system directly. So, you'd make a sprite and position it etc, just like you do already, but disable physics on it, then calculate the sprites speed, and each loop, you update each bullet based on it's speed. When you do that, you can also check for ray cast collision between the bullets previous and new location, and if there is a collision, use the collision response stuff, like the normal X and Y could be used to calculate the new angle of the bullet. Then when you have that, work out a new X and Y speed for the bullet and let it keep going. The main benefit in this is the ray cast collision, because that way it won't miss any collisions, as it'd be based on the previous and new position, there's no possibility of gaps appearing. With standard Box2D physics, at bullet velocities, often the bullet sprite will pass right through narraw walls, and doing all the necessary extra collision checks could really slow things down. It might be like comparing 1 line collision check with hundreds.

Thanks VanB SpriteRayCastGroup works very well for my game- I added in walls that destroy the bullets when there is a raycast collision with the sprite group wall (I'll be adding in the bouncing logic later). This all works fine when running at the default 60fps but I tried it at 1000fps just for kicks, and somehow the bullet goes through the wall without ever being destroyed. I can't seem to wrap my head around why this is happening, I am using frame based movement but nevertheless the raycast (line) should always eventually collide with the wall even at a higher fps,right?-any ideas why this is happening?

I found out there must be something wrong with my code because after testing I found out it doesn't always work at 60fps either (sometimes bullets go through the walls, I think it may be something due to how the bullet's x and y are not offset. I didnt set an offset and the bullets are currently 15x15 pixels. Here's the code, hopefully someone can figure out what I've done wrong, also what offset should I be using for bullets?:



Btw: I've never used raycasting and it's really cool- I like the raycasting funcitons!

Edit: On second thought, maybe I'm doing the frame based movement wrong.

Walls surround the entire map, how could a bullet with checking raycasting ever get outside of the bounds-it just doesnt make sense.

I'd cast a ray from bullet's current position to the target position, check for intersection, then using the bullet's direction vector with the reflection formula.

maybe use byoffset you get the middlepoint of bullet.
you can show the SpriteRayCast with drawline as help.

Hmmm, maybe there's some issues with the way your updating the sprite.

You have a type setup for your bullets, so what I would suggest is that you don't use the getspritex etc, and don't set the sprite position axis separately. Like, have the .x# and .y# component of your type, but also store the velocity of the bullet as .xs# and .ys# - and also that angle, because that might be handy later on if you add deflection. Along with that, also store the last position as .lx# and .ly#.

In psuedocode, I'd do something like this:

Loop through all bullets

If bullet is alive then

bullet.lx=bullet.x
bullet.ly=bullet.y
bullet.x=bullet.x+bullet.xs
bullet.y=bullet.y+bullet.ys

If theres a collision between bullet.x,bullet.y and bullet.lx,bullet.ly
bullet.x=collision point x
bullet.y=collision point y
kill bullet
else
position sprite at bullet.x,bullet.y
endif
endif

endloop


This is how I do it, and I've never had an issue with gaps appearing in a bullets trajectory. Although, one thing to keep an eye on is inverted collision checks. Like, some collision detection algorithms don't automatically allow for bi-direction. Like, a sprite tends to get a collision frame, a concave shell that goes around the sprite shape - but with some techniques you'd only detect collision when checking outside of that shape to the inside or through - checking from the centre of the shape might not detect a collision. So, maybe it's the way you've setup the collision perimeter. Anyway, one way to get around that is to do bi-directional checks, like (psuedo)

col=raycast(xa,ya,xb,yb)
if col=0
col=raycast(xb,yb,xa,ya)
endif

So that would check both directions and is necessary with some techniques, not sure if AppGameKit is sensitive to this stuff with Box2D - I know it is with 3D raycast checks - that seems to only detect collisions that are opposite to the normal of the polygon... kinda like 2-way glass, and your collision checks are like rays of light - they get stopped when going in only 1 direction. I'm thinking that maybe the sprite raycast checks are the same.

It's a case of engine developers leaving space for optimisation - you wouldn't necessarily want to detect collisions that are in line with the 'normal'. Like - maybe bullets start from the center of a ship sprite, and enemies are all firing at this ship. If the bi-directional thing is right - then the enemy bullets will be detected if they hit the player ship - but the players own bullets wouldn't, it's what you might want, and making it fool-proof would mean a double collision check. Same goes for 3D - you probably wouldn't need to detect bi-directional collision on a terrain or structure.

Anyway, I'm rambling - if your still stuck I will make a little example as soon as I have time, but just persevere with it, it'll bend to your will before very long

Thanks for all the help Van, I found the issue was just a simple mistake- I was using an integer in my bullet type to store it's x and y, however getx/gety returns a decimal and I should have been using floats uggh. Nonetheless, you've helped a lot and I've learned about raycasting that I didn't know anything about before-it's really useful and I should have used it in some of my previous games.



I feel that this is a good piece of advice- that has gotten me through some difficult problems; thanks!

Glad I could help

The problem I'm having now with using raycasting for bullets is that I dont know the best place to check from - previously I had used the center of the bullet to the new location the center of the bullet will have in the next frame. This works fine for collisions with walls, but when I want to check for a collision with another bullet, they will often pass through each other not detecting a raycast collision. I thought about making a raycast check from each of the 4 corners of the bullet to there new locations but this is difficult for me to figure because my bullets are also continuously rotating (for graphical effect - it looks cool ). There must be a better way of doing this.

Hmmm, I think you could get around that with a line interect function. I'm sure I have one somewhere - I'll dig it out in a bit and explain what I mean. But basically you'd do a range check and any bullets near each other, you'd do a line intersect check with the bullets trajectories. If the lines intersect, get the intersection point, and work out at which point in the bullets 'step' they collide. If they're at a similar point then that's a collision.

Someone will have a really complicated yet straightforward math solution - but it is possible with distance checks and a line intersect, I'll see what I have.