Say I have a stealth game. In this game, I can sneak up behind guards and stab them/snap their neck/etc.. What is a good way to handle the stabbing death animations with the sprites? It's a little weird because not only does the guard need to be shown getting a knife through the back, but the player needs to cover the guard's mouth and force the dagger through. That's not accounting for different enemies either.

Is there a good OO way to combine the animations? Or, do I really need to make stealth killing animations for each enemy (and if that's the case, how would painting/rendering work)?

The easiest way would be to have a single kill animation for the player and and a single "killed" animation for each different enemy. It'll look fine, and you really REALLY want to avoid having to animate all the combinations of killer/enemy...

If you're doing 2D, you're pretty much going to have to draw out allll of the animations by frame (picture by picture, cycle by cycle).But you can draw images over certain images, by rendering them before that image (the illusion of your players knife/hand over your enemys sprite).Hope it helps some mate, need anything drop me a pm.

The rendering is not hardware accelerated, so it's orders of magnitude slower.

This isn't really true. Swing uses Java2D, which in turn will be hardware accelerated if possible (and extremely likely on Windows, for example). "Swing is slow" is a stigma that's unfortunately stuck with Swing for the past 10+ years. If you're Swing GUI is slow, then you're just not doing it rightTM, just like with any other widget toolkit.

If anything, it'll be your doing non-UI tasks on the EDT that makes your Swing app appear sluggish, not its rendering performance.

The rendering is not hardware accelerated, so it's orders of magnitude slower.

This isn't really true. Swing uses Java2D, which in turn will be hardware accelerated if possible (and extremely likely on Windows, for example). "Swing is slow" is a stigma that's unfortunately stuck with Swing for the past 10+ years. If you're Swing GUI is slow, then you're just not doing it rightTM, just like with any other widget toolkit.

If anything, it'll be your doing non-UI tasks on the EDT that makes your Swing app appear sluggish, not its rendering performance.

Except that Java2D's g.drawImage(...) sucks, performance wise. Even when you're doing it rightTM. It's obvious that's it's either falling back to a software rasterizer or the hardware accelerated pipeline is somehow extremely inefficient. This has nothing to do with whether or not your executing time consuming code on the EDT, this is purely the rendering part: Java2D is slow, and Swing therefore too.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Perhaps, but it's not slow enough to matter for the vast majority of GUI's most people will throw together. If your Swing application seems sluggish and you try to blame it on the fact that you're drawing too many JButtons, you really need to get out a profiler.

I'm well aware that games in Java2D cannot compete with OpenGL bindings, but we're talking GUI's here (well, since Swing was brought up, guess we're a little off-topic here). Perceived performance is all that matters, and the human eye won't be able to detect a speed difference between a JMenu dropping down and a native Win32 one. Visual fidelity is a different matter though.

No. The author of this thread is purely talking about rendering. When he mentions the 'slowness' of Swing, it's clear it means 'Java2D'.

Fair enough. The "does it open a thread per component" question made me think he was also looking at Swing proper since games don't usually create more than just a Frame and Canvas. Sometimes my zealotry gets the better of me.

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