# Bitte um Hilfe bei Animationen



## Titanpharao (30. Jan 2008)

Hallo,

da im Anfänger Bereich mir keiner Antwortet, dachte ich frage ich nochmal "fachspezifisch".

Ich habe mein Spiel, was schon sehr groß ist auf einem JFrame aufgebaut. Auf dem befinden sich 4 JPanels. Das ganze ist ein Null-Layout. Damit ich die Position der einzelnen Labels und Buttons exakt setzten kann. 


1.Ebene/JPanel:Spielwelt
2.Ebene/JLabel:Spieler
3.Ebene/JPanel:HUD

So ist das in etwa aufgebaut. Das HUD liegt auch immer schön über den andern Panel. Jetzt ist das Problem, das ich auf der Spielwelt auch gern ein "Animiertes GIF" mit z.b. Wellengang haben möchte.
ich linke mal ein Bild rein...

http://img441.imageshack.us/my.php?image=gamexg9.jpg

Wie man sieht, müste beim gelben Rahmen, noch das HUD sein. Es funktioniert auch alles wunderbar. Nur sobald ein Animiertes Bild drunter liegt, "flimmert" das durch. Sicher wegen der "repaint()" Methode, die immer bei Gifs aufgerufen wird.
Kann ich das irgendwie verhindern? 
Oder das HUD Panel irgendwie "unüberschreibbar" machen? Bitte um Hilfe, will nicht sone triste Spielwelt haben.

Mgf Oli


----------



## Gast (31. Jan 2008)

Es könnte helfen, wenn du dein HUD nicht in das Fenster einfügen, sondern  es auf das Panel legst. Sonst weiß das untere Panel nicht, dass da noch eins ist und übermalt es einfach. Das obere Panel muss sich dann neu zeichnen->so entsteht dein Flimmern. 
Wenn du das HUD zu dem unteren Panel hinzufügst und darauf positionierst, müsste es gehen. Eventuell musst du dann noch in der paint- Methode des unteren Panels dafür sorgen, dass es die Stelle tatsächlich nicht übermalt. Ich kann aber nicht versprechen, dass das hilft (warum? Siehe unten)

Insgesamt klingt das aber ziemlich unperformant. Für Spiele nimmt man im Normalfall kein Swing/AWT, weil bei diesen Packeten die GUI- Verarbeitung in einem eigenen Thread läuft. Die Spiellogik braucht dann noch einen Thread, was Performanceprobleme hervorruft. Deshalb setzt man im Normalfall Packete ein, mit denen eine echte Spielschleife möglich ist (z.B. JMonkeyEngine). Was eine Spielschleife ist, erklärt der Macher der JME unter http://www.jmonkeyengine.com/wiki/doku.php?id=main_game_loop

Ich hoffe, dass hilft.


----------



## Titanpharao (31. Jan 2008)

Probiers mal aus...danke 

Ich möchte aber gern Spiel und Aufbau dahinter verstehen. ich denke wenn man nur eine Bibliothek nimmt schaut man sich nicht genau an, wie es funktioniert.


----------



## Titanpharao (31. Jan 2008)

Hm...würde vielleicht so gehen. Aber das problem ist das P2 sich immer im Fenster bewegt. Wobei P1 "star" auf dem Fenster liegt. Also wenn ich jetzt P1 auf P2 setze verschiebt sich das mit...

Aber es geht so. Nur halt jetzt wird P1 immer auf P2 mitgerückt....das ganz schlecht icon_wink.gif Vielleicht die beiden nochmal in ein Panel packen?


----------



## Campino (31. Jan 2008)

1) Das Problem ist, dass du den Aufbau, den ein Spiel normalerweise hat mit Java- Hausmitteln nicht hinbekommen wirst. Dazu musst du eine Engine nehmen. Mit JME versteht man das Konzept der Spielschleife eigentlich auch, weil man doch noch ziemlich viel selber programmieren muss. 

2) Du hast ein Panel Spielwelt, dass ist unbeweglich. Ein Panel P2, dass ist beweglich. Also musst du P2 in Spielwelt einfügen und anschließend P2 bewegen. Ansonsten erklär mal genauer, was du machst.


----------



## Wildcard (31. Jan 2008)

> Das Problem ist, dass du den Aufbau, den ein Spiel normalerweise hat mit Java- Hausmitteln nicht hinbekommen wirst.


Ach? Und besagte Engine ist dann mit Perl geschrieben oder wie ist diese Aussage zu verstehen?  :autsch:


----------



## Titanpharao (31. Jan 2008)

Also ich komme ziemlich gut damit hin. Ist eigentlich schon fast fertig. Nur halt das überlagern der Animationen über das HUD.

Die Spielwelt ist nicht fest. Sie bewegt sich unterhalb des Spieler, indem sie im Fenster verschoben wird. Das klappt wunderbar und sieht super aus. 
Das ist Panel 1 was auf dem Fenster liegt. Panel 2 ist "fest" auf dem Fenster. Ist auch klar das ist das GUI. Es wird aber zuerst auf das Fenster gelegt, weil auch das ein NULL Layout besitzt. Erste immer ganz oben...nur leider kommt durch die Animation diese durch. Sieht man doch wunderbar auf dem Bild was ich oben verlinkt habe.


----------



## Campino (31. Jan 2008)

wildcard: Ich sagte: "Das Problem ist, dass du den Aufbau, den ein Spiel normalerweise hat *mit Java- Hausmitteln* nicht hinbekommen wirst."
JME und ähnliches setzen JLWGL oder JOGL ein. Einige (z.B. odejava) sind eigentlich C++- Engines, die über das JNI für Java nutzbar gemacht wurden. Keine einzige setzt auf Java3D, Java2D oder Swing/AWT auf. 
Er kann natürlich seine eigene Engine schreiben. Aber aus den oben beschriebenen Gründen (Multi- Threading) nicht mit Swing oder AWT.

Titanpharao: Schieb nicht Panel1, sondern ändere die Position an der du dein Bild in das Panel malst. Dann verschiebt sich die Darstellung, das Panel aber nicht. Somit bleibt auch dein HUD fest.


----------



## Wildcard (31. Jan 2008)

Campino hat gesagt.:
			
		

> wildcard: Ich sagte: "Das Problem ist, dass du den Aufbau, den ein Spiel normalerweise hat *mit Java- Hausmitteln* nicht hinbekommen wirst."
> JME und ähnliches setzen JLWGL oder JOGL ein. Einige (z.B. odejava) sind eigentlich C++- Engines, die über das JNI für Java nutzbar gemacht wurden. Keine einzige setzt auf Java3D, Java2D oder Swing/AWT auf.
> Er kann natürlich seine eigene Engine schreiben. Aber aus den oben beschriebenen Gründen (Multi- Threading) nicht mit Swing oder AWT.


Dir scheint der unterschied zwischen einer Bibliothek und einer Engine nicht klar zu sein. Natürlich setzt JOGL nicht auf Java3D auf, denn es ist genau andersrum, Java3D verwendet die JOGL Rendering Pipeline.
JOGL ist lediglich ein Java Binding für die OpenGL API.
JLWGL? Du meinst sicherlich LWJGL, oder  :wink: 
Was du nun aber als Java Hausmittel bezeichnest...?
Wenn du die JRE meinst, nein, die sieht kein 3D vor, denn das ist zu speziell um damit die JRE weiter aufzublähen.
Spiele kannst du allerdings sehr wohl mit AWT/Swing erschlagen. Im Fullscreen exclusive mode spricht zB nichts dagegen Page Fliping und Active Rendering zu verwenden und das übliche Threading Modell das für *Desktop Anwendungen* konzipiert wurde, einfach nicht zu verwenden.


----------



## Quaxli (1. Feb 2008)

@Wildcard: Dem kann man nur zustimmen!

Was hier, meiner Ansicht nach, das grundsätzliche Problem ist: Es wurden zuviele Swing-Komponenten verwendet. Wenn ich lese, daß jemand für den Spieler eine Swing-Komponente verwendet, stellen sich mir persönlich immer etwas die Fußnägel auf.
Meiner Ansicht nach sollte man bei einfachen Spielen nur eine Swing-  oder AWT-Komponente haben: Nämlich das Fenster. Alle anderen Komponenten, wie z. B. Status-Anzeigen, etc. sollten über eigen Klassen realisiert werden, die direkt in das Graphics-Objekt des Fensters zeichnen. Dann hat man auch keine Probleme Animationen, Transparenz, etc. zu realisieren.
Das soll jetzt nicht heißen, daß andere Swing-Komponenten grundsätzlich als tabu anzusehen sind, aber man sollte deren Einsatz gut abwägen. Natürlich kann man z. B. das Innere eines Hauses in einem RPG oder einen Shop als JDialog realisieren (hab ich auch schon gemacht) - nur ein Spiel mit Swing-Komponenten zu realisieren, weil man sich (nur) damit auskennt erscheint mir der falsche Weg.
Meiner Ansicht nach, muß man bei der Programmierung von Spielen sich vom GUI-Denken wegbewegen und das Ganze etwas abstrakter sehen.

Soweit meine Meinung zum grundsätzlichen Problem


----------



## Titanpharao (1. Feb 2008)

Das alte Spiel basierte auf zeichenfunktion. War aber mehr umständlich als Hilfreich. 
Mit dem Spielwelt auf Panel zeichnen, würde ja gehen, wenn ich nicht alles in Labels gepackt hätte. Dann läst sich etwas blöd die "laufen" animation realisieren. Sonnst müste ich die labels alle einzeln auf der welt verschieben um x Pixel. So liegen sie auf dem Panel und nur das wird um x verschoben. 
Vielleicht nicht ganz perfekt, aber mitlerweile wurde eh die Animationen rausgehauen aus der Welt. Wirds halt ohne Wellengang^^


----------

