Periodic actions

Newbie & Debugging Questions
#1

Hi . I am trying to develop a small 2d game . I use Timer and TimerTask for the “bad guys” movement . The only problem is that I want them to move only while they are on the screen . The problem is that if I use cancel() on the Timer(each monster has its own Timer) and then try to schedule again the movement if I come back to “visit” the bad guy I get an exception that tells me that I already scheduled or canceled the Timer.Even if i initialize the Timer again each time I get the same error. How this should be done ? ???

Thanks in advance.

#2

You really shouldn’t be using individual timers to update positions/logic/etc, you’ll get into all sorts of race conditions and such. The usual method is to have a ‘game loop’ - basically a big loop which runs for the entire lifetime of your app. Every frame it runs all your update logic (such as updating player and enemy positions) and then draws the updated frame. Rinse, wash, repeat. You’ll then be keeping a list of enemies to update and removing them just means removing them from this list.

This gets slightly hairy when you’ve got to deal with Awt/Swing repaint issues, where the actual paint callback may happen in a different thread at some unknown time in the future. For this it’s much easier (and cleaner) to use a BufferStrategy which lets you do your redraw and buffer swap within your game loop.

#3

I was using a game loop . Now it just doesn’t make sense using timers or other threads and it did so much sense before… :).Thanks a lot .

I was wondering if someone knows a good link to a perfect pixel collision detection . I found only rectangle collision . If it makes any difference I use transparent gifs (not made transparent by using java) .

#4

I’ve found that for a simple game circle detection is enought… I think pixel detection would require per pixel scanning and would be very slow(er).
about pixel detection, kind off: http://www.java-gaming.org/forums/index.php?topic=14024.0
about using a circle for collision detection: http://www.java-gaming.org/forums/index.php?topic=13412.0

#5

10x.I used rectangle and circle collision for other games , but here it won’t do the job well since all the fun is based on escaping at limit . Plus this is mainly a lesson not a real project so even if in this case it is going to be a bit slow this is not a problem . I will try to create a secondary program that makes a bounding polygon from an image . Then I could use polygon collision witch is faster(is it ??) . I am not sure I can do this algoritm , but I will try. I will begin with learning how to get the color of a pixel :D. 10x again. :wink:

After about 2 hours I did it :).At least I managed to do something close to the program with polygons.After the first algoritm the polygon resulted of an image(98 x 176)(most of the images in the game have this size) had about 34000 points :’(…Now I managed to make the polygon have about 1300 points witch i still belive is not fast enough , but I am pretty sure that my algoritm is not really the best…

#6

1300 point polygon for a single small image? wow, isn’t that a overkill?

I don’t have a clue about it, but here’s a quick thought:
Have you considered using pixel like collision all the way? Like, you have your image that needs detection. At load time you can take it’s data and put into a double byte array, so you’ll have byte [ x ] [y] to use as coordinates. You do that for all objects (images) that are displayed and need collision detection. Then you can make an algoritham that would see if byte [ x ] [y] overlaps byte [ x ] [y] of another object. I know that for 100x100 image you would have 10000 bytes but algoritham will be dealing with bytes and not float or double point (?) stuff from java2d. Also it might be possible you only deal (and store) those pixels who are the border where collision detection is needed and not whole thing.

Edit: why the hell [ x ] (without spaces) is rendered as new line here ??? Test: 1:[v] 2:[x] 3:[z]

#7

That algoritm is not complete. In the end I hope there will be under 100 points.Else I will make with the mouse a polygon that surrounds the sprite and that polygon will have probably under 15 points.I won’t use java2d I will use just java with integer coordinates not float or double .

#8

ppcol goes like… box/box intersection test… if positive the overlapping pixels are compared. Its pretty fast, because in most cases the boxes wont overlap to begin with and if they overlap, the check is stopped at the very first hit. (So the slow part isnt run often and if its run it ends quickly in most cases.)

Well, imo ppcol is overrated. It feels way more random then simple circle/box checks.

Oh noes! Critical anime-hairstyle hit! x_x

#9

What if the 2 images do not collide ? The check won’t end until it’s finished .I still want to try the polygon collision. If I won’t be able to do it I will try with the pixels. I’ve managed to do the hole program .The perfect polygon has about 1000 points,but I sacrifieced just a little precision (I don’t think it’s visible while playing) and I got a 65 point polygon . Hope this will be fast enough . If not I will try what onyx said.

Edit : 22 points . This is the best I can do , but I think it will work just fine .

#10

What if the 2 images do not collide ? The check won’t end until it’s finished .

In that case the overlapping area will be usually very small. Like 2x8 pixels for example. So, finishing the check wont take that long.

Btw try to fix your typing.

#11

Seconded. You’re basically coupling the gameplay (collision detection) very tightly with the graphics, which means a random art change can suddenly change the way the whole game plays. If you need more precision than just bounding circle/square then either use a collection of shapes to represent one object, or a more complex shape like a poly.

The only time per-pixel makes sense imho is in a worms game, and even then it’s only used on the landscape, not on the worms themselves.

#12

public boolean collide(Polygon p1, Polygon p2){
for(int i=0; i<p1.npoints; i++){
if(p2.contains(p1.xpoints[i], p1.ypoints[i]))
return true;
}
return false;
}

I used this to check the collision between the polygons created with the other program. If an edge of a polygon completely crosses one of the othe polygons this won’t work . But since I use about 22 points for a 100x200 polygon … this will never happen :). It works great and it’s blazing fast. 10x a lot guys! 8)

#13

You should use a circle collision test before your ppcol, so that you only test on sprites which circles overlap. You could do this one hierarchical and get a much faster algorithm than polygon collision.

#14

I check collision only for the sprites that are in a range of 200 pixels . This is not actually polygon collision . It’s just a fast polygon collision algoritm that has some cases that do not work (but those kinds of cases will never occur in my game ).This makes it very fast . I do not see any performance difference before implementing the collision detection and now . When I will finish the game it might work fast enough to allow me more precision on the polygons .

#15

well nice to see you solved the problem… and one question I was wondering, can you rotate your poligons? If you can, does collision algorithm works the same? Sorry but I didn’t checked it how it works.

#16

No , I don’t think that works ,but some math might do the job :frowning: . Maybe if I rotate this in the developing stage and get the bounding polygon for the rotated image … The algoritm just checks if polygon 1 contains any of the polygon 2 points . If it does then they collide. The math sollution for the rotation it might a bit slow if you need to rotate the sprite too many times . I didn’t used too much java2d ,but I guess the rotation is around the center of the image.So all you have to do is to change the coordinates of each point of the polygon by rotating it with an angle. This should be easy done by using sinus and cosinus . I will leave for some days . I will continue the game and answer any other questions when I’m back . Bye.

#17

Then it only works for convex polygons, and they shouldn’t be too sharp (<=90 degrees). Else their corners can become ``sticky’’ depending on your mode of movement :). Anyway, that method works independently of rotation if I understand you correctly.

#18

I do not use convex polygons :smiley: . There are no distances that long to completly pass a part of another polygon . The method is not really independent of rotation , but you can get the new coordinates with some math .

#19

Hmm okay, I may have misread something, convex polygons should be okay. But the problem with sharp corners is that two polygons can become `lodged’ near their corners even if they are only moved in very small steps at a time. Regarding rotation, my point was that if it works for a polygon, and rotating a polygon yields another polygon, then it works for a rotated polygon (which would not necessarily be true for an axially aligned rectangle since it will no longer be axially aligned after rotation, and I only bothered to note this because of this previous context).