ok i have this game where you pick the angle and power and then shoot. as is i draw things in the run statement. however i think im going about this all wrong. for example when the ball hits the ground i would like to draw an explosion. is there a good way to get different animations to pop up when things happen? perhaps make them their own threads? for example when space bar is pressed stop current thread and start thread that draws the flight of the ball? then when it hits ground stop that thread and start one that draws exposion?

I'm pretty sure that spawning new threads for animation purposes is bad idea. The least you'll have - dozens of synchronization issues and deadlock headaches.

To simplify development a bit create separate class that will hold data that is needed for animation (i.e. list of frames, current frame, time till next frame). Then update your animation based on time passed since last update.

Quote

is there a good way to get different animations to pop up when things happen?

Try implementing Observer pattern. Create a list of listeners, then notify them of certain action happened.

Don't ask the same question (or at least near the same question) twice.

And no, threads are a very very bad idea. They have a very high overhead on creation and you will need a lot of animations. Just have good encapsulation and individual timers that are dependent upon the main timer (i.e. pass the delta time to each animation so it knows how much to update).

Threads are a good idea! The problem is that people don't know how to use them. I'm currently developing a game for advanced software engineering (postgrad) and I have to use Agent Oriented Software Engineering, to put it simply everything is in a thread.

Use executors.Use atomic variables/data structures.Create your own lock-free algorithms (if you have to, but this can be very difficult).

The easiest way of doing things is what the other suggest, but if you have the time and want to learn what every software developer will need to know in the next decade then go with a proper threaded model.

Threads are a good idea! The problem is that people don't know how to use them. I'm currently developing a game for advanced software engineering (postgrad) and I have to use Agent Oriented Software Engineering, to put it simply everything is in a thread.

Use executors.Use atomic variables/data structures.Create your own lock-free algorithms (if you have to, but this can be very difficult).

The easiest way of doing things is what the other suggest, but if you have the time and want to learn what every software developer will need to know in the next decade then go with a proper threaded model.

I wasn't saying that multi threading itself is bad; of course it is an incredibly important idea to know and technique to use.

I was saying that using a different thread for every single animation you have is a horrible misuse of threads and definitely not the best way to do an animation.

I wasn't saying that multi threading itself is bad; of course it is an incredibly important idea to know and technique to use.

I was saying that using a different thread for every single animation you have is a horrible misuse of threads and definitely not the best way to do an animation.

I second that - this would be one of the worst possible uses of threads, since the frame updates in each animation all have to happen in lock-step. You'd end up spending far more time figuring out how to make that happen right than it would take to just set up an extremely simple timed animation handler.

If you're getting to a point where you have thousands of these things and you really need to spread them out over processors, that's when you would consider multi-threading, but it doesn't sound like that's what's going on.

A very simple example of how to do this the way people are suggesting would be to have an Animation interface, something like:

1 2 3 4 5

publicinterfaceAnimation{publicvoidupdate(floatdeltaT);publicvoiddraw(Graphicsg);publicbooleanisFinished(); //return true if the animation is done and should be removed}

which you could implement as needed for each type of animation. Then in your main loop handling class you just hold onto a list of animations. Here's some sample code (untested) that should give you an idea how to handle things:

//this next bit would be in your main loop's update methodfor (Animationanimation:animations) {animation.update(deltaT);}

//clean up the finished animations...there are probably better//and faster ways to do this, but this is the first way that pops//to mind that doesn't require me to actually test the code first. :)AnimationkillMe = null;do {killMe = null;

//...and remove itif (killMe != null) animations.remove(killMe);} while (killMe != null); //repeat until there are no more finished animations in the list

//this would go in the draw methodfor (Animationanimation:animations) {animation.draw(g);}

There are probably ways to better design this (you can probably turn it into several hundred lines of code by properly GoF pattern-izing it, YAY!), but IMO unless you're trying to create a framework, just go with something simple that works.

Then in your main loop handling class you just hold onto a list of animations.

sorry if this is elementary but can we break it down. so each animation is what? and array of images? and how do you declare each separate animation? so far i have just drawn everything in the run method.sounds like each separate animation is its own class?

An animation could be an array of images if you wanted, or it could be some sort of movie file or GIF or sprite sheet or something like that.

At your level of knowledge, just have an animation represented by multiple images, then make your animation an array of them. Have you dealt with creating classes and objects before? If not, I suggest reading up on that before trying to continue.

The above is a very simple way you might implement an animation class, rather than an interface as ewjordan showed above. Really I think how you want to do it is based on your needs - if an animation is more of an abstract thing and does not necessarily entail an array of images, go the interface route. If you know that every single animation is going to specifically need one implementation, go the class route. Also you should be able to see more of the guts of it above. I wouldn't use System.currentTimeMillis(), by the way... instead your main loop should be periodically passing that information to your animation so that it is called only once per timestep.

By the way, you basically restart the animation if you find that it was done from the last time you drew it. But there's a bagillion other ways you could do that sort of thing, and many better (more complicated) ones. Also the above will permanently loop all the animations. To make them stop or whatever you could add new functionality, or you can start to get more complicated and make every drawn object contain its own list of animations, and then each animation has a certain priority, so standing would have a low priority whereas jumping would have a higher priority, meaning that jumping will play if it is asked to (i.e. you press a jump button) instead of standing, which is always played unless something else is (because it's the default).

It's ImageIO.read(...), not ImageIO.readImage(...), I suspect that was just a typo in the code posted earlier. Make sure you've added "import javax.imageio.ImageIO;" to your imports, too, otherwise it still won't work.

BTW, this seems like a good opportunity to suggest that you get to know and use Eclipse or Netbeans if you're not doing so already (though I'll only personally vouch for Eclipse), because in a good IDE a list of static member functions will pop up as soon as you type "ImageIO.", and stuff like that makes it a lot easier to explore various APIs. I barely refer to actual Java documentation anymore because any properly Javadoc-ed library is almost trivial to poke around in and use once you know the base package name.

And yeah, the ImageIO thing from before was a typo. That code, along with the code above, comes from the top of my head and is specifically written here in the forum. As such I'm not bothering to compile it or anything, but it should give you an idea of what you're doing.

ok i don't think i entirely understand. so can i keep my original code that i posted in the first post? as it stands i draw everything in the run method which works fine but at certain points i would like to call an animation but then have it disappear completely once it has run through all of its frames. so do i have to modify the existing code or not?

ok everything is working pretty good but i am having some problems reading my images in. first it takes forever to start applet....im guessing this is just java being slow loading images. second when the applet does start and i have loaded images if i try to draw them the applet either starts as a blank white screen or if i try to call an image with an if statement then the thread stops and the applet doesnt do anything.

ummm they are gif images and they are 70x70 pixels.... i can get them to load using getImage(getCodeBase,"..."); and they appear and stuff but i cannot use that outside the main class. ImageIO seems to load the images just fine but when they are displayed either something goes wrong or the images are blank and the size of the entire applet.

Oh, are you not storing them? You should only load them once, then store them in a map or list for subsequent access. If you make that collection global or you pass it around via parameters, then you can use it in other classes.

i would like to store them with the ImageIO.read method you wrote in the code above. however like i said i am having a problem getting them to display. should the animations class be nested in the applet class? as it stands its outside the applet class. if i call ImageIO from inside the applet class everything works fine. however if i use parameters to pass the file name to another class(nested or outside) as your example shows i cannot display the images.

i would like to store them with the ImageIO.read method you wrote in the code above. however like i said i am having a problem getting them to display. should the animations class be nested in the applet class? as it stands its outside the applet class. if i call ImageIO from inside the applet class everything works fine. however if i use parameters to pass the file name to another class(nested or outside) as your example shows i cannot display the images.

Hmm, Abuse is definitely right to a certain extent. It seems like you don't yet understand programming basics.

When you load an image with ImageIO, you want to do it once so that you're reading the image from memory rather than your hard drive. Then you need to give the applet access to that stored image so it can be drawn.

well you are correct i do just jump into stuff but thats just me.....sorry. however i figured it out. in your animations class you declared the frames array but did not initialize it. after the parameters are passed i initialized frames[] to refs.length and everything works great. im not trying to correct you though cuz i know you said you didnt test it.

ok and i actually have a game related question for you. i want my characters to have two animations. if forward or backwards is pushed the legs should move like they are walking and if the up or down is pushed they should move their arm up or down. whats the best way to implement this? i was thinking maybe an image matrix? increasing one index moves feet and and the other the arms....

Ha, no worries, correct me all you want. I'll never claim to know the best way to do things. And maybe it's good you got that error because now you'll learn to spot them in the future.

As for your question...

There are several ways you could implement that. The simplest way with your current animation method would be to simply allow one Unit (we'll say your objects that can play Animations are called Unit) to have multiple animations going off at once. Logically, however, you probably don't just want to have an array of Animation lists, because that's confusing and makes little sense. Instead, you probably want to create a new object, like UnitElement or something, that contains independent information pertaining to that section of the body. As such, no Unit actually has references to animations; instead their UnitElement(s) do. A UnitElement knows its local position (i.e. the offset from the Unit's position where it should draw itself, etc.), local rotation, and has its own Animation List.

publicabstractvoiddoLogic();/* An abstract method can't have a body. Instead, you make a subclass that inherits * the method and overrides it, thereby creating unique functionality. You might want * to have classes like LegElement, ArmElement, BodyElement, or whatever that represent * different useful functionality. Below is an example of what LegElement's implementation * might look like.

I think that should give you the idea. I made UnitElement abstract because doLogic() doesn't make sense generically... you're going to want different types of UnitElements that handle input differently.

You could also just allow a Unit to contain more Unit's as children, and do the functionality in the same sort of way as above. Basically instead of worrying about local position and whatnot they can just be stored in the same place for easy access, but using global coordinates. I don't recommend this, but it might be easier to grasp.

is there an easy way to, once one key is pressed, tell the computer not to accept any other key presses until the initial key is released?

i am just concerned with the direction keys mainly.....i dont want the user to be able to move in two directions at once. i was able to implement this behavior with if statements contingent on four conditions.....is there a more simple way to do this?

is there an easy way to, once one key is pressed, tell the computer not to accept any other key presses until the initial key is released?

i am just concerned with the direction keys mainly.....i dont want the user to be able to move in two directions at once. i was able to implement this behavior with if statements contingent on four conditions.....is there a more simple way to do this?

is there an easy way to, once one key is pressed, tell the computer not to accept any other key presses until the initial key is released?

i am just concerned with the direction keys mainly.....i dont want the user to be able to move in two directions at once. i was able to implement this behavior with if statements contingent on four conditions.....is there a more simple way to do this?

And as for Orangy Tang's suggestion, he's totally right. It is a perfectly acceptable method of learning to dive in, but you've got to have some general knowledge of what you're doing when you do so. So get yourself and book you can look at alongside this programming. Most of the advice I've given you is really simple, especially the stuff in this post.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org