### Author Topic: Problem with shooting  (Read 11230 times)

#### paulscode

• double
• Posts: 863
##### Re: Problem with shooting
« Reply #15 on: November 17, 2008, 10:42:52 pm »
I don't know if this helps, but you could check if the bullet is going to collide before actually moving it.  If it would collide, then calculate how far the bullet is able to move before the collision would occur.  This might help avoid the bullets jumping past their targets if they are moving too far.  Use something like this:

Code: [Select]
`// SimpleVector position is the bullet's position// SimpleVector direction is the bullet's heading (normalized)// float distance is how far you plan to move the bullet// Calculate the distance to any target that would be hit:float targetDistance = world.calcMinDistance( position, direction, distance );        // See if the bullet is going to collide with something:if( targetDistance != Object3D.COLLISION_NONE ){    // targetDistance is the distance at which the bullet will collide with the target}`
That won't make the bullets move smoothly, though.  A visual trick might be to stretch the scale of the bullet (make it longer) when it has to jump a far distance.  Movie special effects sometimes use this to trick the eye.  You'd have to experiment with it to figure out how much to stretch the bullet given the distance, but it should work as long as the bullets are moving fast enough.  I don't know how difficult something like that would be to program, though.
« Last Edit: November 17, 2008, 10:55:41 pm by paulscode »

#### Melssj5

• double
• Posts: 724
##### Re: Problem with shooting
« Reply #16 on: November 17, 2008, 11:06:15 pm »
mmmmmm doing that algorytm would work only for cases when the bullets is already ver close to the target, remember that the bullets moves independent from the ships, so until the collision is done, anything can happen. That algorythm may work on the 1% of cases and could make wrong results on a higer percentage. I guess, I have not done any statuctucal work on the bullets.

#### paulscode

• double
• Posts: 863
##### Re: Problem with shooting
« Reply #17 on: November 17, 2008, 11:24:15 pm »
This code should work in every case, regardless of how far away the target is.  If the bullet was going to jump a huge distance, it would detect if something was in it's path.  Same thing if the bullet was going to jump a small distance.  Varriable 'distance' determines how far in front of the bullet to check for a target.  Note: I would use this code immediately before actually moving the bullet, so even though the ships move independantly, it should be accurate.  Just be sure that varriable 'distance' is not larger than how far you plan to actually move the bullet.

As for the ships moving independantly from the bullets, I'd say just make sure the ships never move a further distance than their total size at one time.

-- EDIT --
The only exception I could think of is if the ship were to jump to a point where the bullet was inside the ship, in which case the collision would not be detected.  I'll think about that problem, not sure of a solution off hand.
« Last Edit: November 17, 2008, 11:32:26 pm by paulscode »

#### Melssj5

• double
• Posts: 724
##### Re: Problem with shooting
« Reply #18 on: November 17, 2008, 11:33:39 pm »
mmmmmm, now I understand what you told me before. Accuracy is still a problem in some cases but I guess its a great suggestion. I will implement them as soon as I can work on the project again. I will post the results later.

I will joing the 3 methods, EGon, Pauls and creating Threads for moving the bullets, but instead of doing on thread for each  bullet I will create 3 Threads for that and distribute the amount of living bullets into those 3 Threads.

#### paulscode

• double
• Posts: 863
##### Re: Problem with shooting
« Reply #19 on: November 17, 2008, 11:39:12 pm »
Another idea I had (not sure if it would work though) is to make use of the fact that motion is relative.  Whether the ship moved or all the bullets moved depends on your point of reference.  So you could take the inverse of the direction the ship would move and how far it would move, then plug that into the same formula for each bullet to see if any of them would collide with the ship.

#### paulscode

• double
• Posts: 863
##### Re: Problem with shooting
« Reply #20 on: November 18, 2008, 02:05:13 am »
I experimented a little with the code I posted before, and realized that I was using calcMinDistance incorrectly (I misinterpreted the third parameter).

You should change it to someting like this instead:

Code: [Select]
`// SimpleVector position is the bullet's position// SimpleVector direction is the bullet's heading (normalized)// float distance is how far you plan to move the bullet// Calculate the distance to any target that would be hit:float targetDistance = world.calcMinDistance( position, direction, 10000 );        // See if the bullet is going to collide with something:if( (targetDistance != Object3D.COLLISION_NONE)    && (targetDistance <= distance) ){    // targetDistance is the distance at which the bullet will collide with the target}`

#### paulscode

• double
• Posts: 863
##### Re: Problem with shooting
« Reply #21 on: November 18, 2008, 03:45:25 am »
I did some experimenting with the "inverse target direction" idea, and it seems to work fine.  I posted a simple example applet:
http://www.paulscode.com/source/BulletTargetCollision/

(source code)

I don't know how well it would work on a large scale (i.e. hundreds of bullets).  Also, there would need to be further logic involved if there were multiple targets.  But it does prove the concept, though.

#### paulscode

• double
• Posts: 863
##### Re: Problem with shooting
« Reply #22 on: November 18, 2008, 04:49:36 am »
I ran a test on my applet where there were hundreds of bullets flying at once (by adding a for loop which fires 20 bullets at a time when the mouse is pressed).  I noticed no prerformance reduction on my computer no matter how fast I clicked the mouse.  I wonder why your program takes so long to move the bullets?

Are you calling System.currentTimeMillis() for each bullet?  If so, that could be slowing you down.  If that is the problem, you could try calling the method once and storing the value in a varriable.  Then pass the value to each bullet in the moveBullets loop.  Don't know if that applies to your situation though, so just a suggestion.

#### EgonOlsen

• Posts: 12060
##### Re: Problem with shooting
« Reply #23 on: November 18, 2008, 10:27:31 am »
The problem on that is the precision and collision detection, doing the bullets jumping large distances will make them look bad on the game and will avoid doing a correct collision detection. I am talking about 350 ms for moving 40 bullets, so I guess that a normal game may have more that a hundred alive bullets on the fly, so having 1 sec for moving all the bullets will make that bullets moves at huge speeds.
350ms for 40 bullets is way too much. Are you testing the bullets for collision against some very complex geometry? If so, are you using an OcTree with collision use enabled (http://www.jpct.net/doc/com/threed/jpct/OcTree.html#setCollisionUse(boolean)) on it?

#### Melssj5

• double
• Posts: 724
##### Re: Problem with shooting
« Reply #24 on: November 18, 2008, 05:33:00 pm »
mm I am doing a new Date ().getTime () for each movement to get the time and then print a message for each bullet, this is for logging only, I guess I will need to redefine my solution for this problem. I will post any results by the next week.

BTW: NICE APPLET. Was LOL!