Java Operations per Second

Übersicht

Sonstiges

Smalltalk

	US-Blitz ehemals "SimssmiS" Betreff: Java Operations per Second	So, Feb 03, 2013 14:35 Antworten mit Zitat
Ich habe mich nun auch mal an Java gewagt nachdem mir die Möglichkeiten von Blitz3D doch etwas zu beschränkt waren. Mein Problem ist nun aber das ich nach einer Funktion suche mit der ich die Operations per Second eingrenzen kann (wie in b3d mit waitTimer()) habt ihr da Erfahrung/Tipps

US-Blitz

ehemals "SimssmiS"

Betreff: Java Operations per Second

So, Feb 03, 2013 14:35
Antworten mit Zitat

Ich habe mich nun auch mal an Java gewagt nachdem mir die Möglichkeiten von Blitz3D doch etwas zu beschränkt waren.
Mein Problem ist nun aber das ich nach einer Funktion suche mit der ich die Operations per Second eingrenzen kann
(wie in b3d mit waitTimer())
habt ihr da Erfahrung/Tipps

	BladeRunner Moderator	So, Feb 03, 2013 14:54 Antworten mit Zitat
WaitTimer begrenzt ja nicht wirklich die Operationen die pro Sekunde ausgeführt werden, es stellt ja (wie der Name schon sagt) einen Timer dar der Regelmäßigkeit in der Ausführung bringen soll. Java hat sicher Timerklassen zur Verfügung (hat es, wie ich in zwei Sekunden Google erfahren habe)
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

So, Feb 03, 2013 14:54
Antworten mit Zitat

WaitTimer begrenzt ja nicht wirklich die Operationen die pro Sekunde ausgeführt werden, es stellt ja (wie der Name schon sagt) einen Timer dar der Regelmäßigkeit in der Ausführung bringen soll.
Java hat sicher Timerklassen zur Verfügung (hat es, wie ich in zwei Sekunden Google erfahren habe)

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	Addi	So, Feb 03, 2013 15:18 Antworten mit Zitat
Thread.sleep(...) lässt den laufenden Thread für die in den Klammern eingegebene Anzahl an Millisekunden schlafen.
BP/B3D/BMax : Lerne Java : Früher mal Lite-C : Gewinner BCC 62

Addi

So, Feb 03, 2013 15:18
Antworten mit Zitat

Thread.sleep(...) lässt den laufenden Thread für
die in den Klammern eingegebene Anzahl an Millisekunden
schlafen.

BP/B3D/BMax : Lerne Java : Früher mal Lite-C : Gewinner BCC 62

	US-Blitz ehemals "SimssmiS"	So, Feb 03, 2013 17:04 Antworten mit Zitat
Danke schonmal @Blade Hatte ich auch schon gesehen kam aber nicht mit der Timer Klasse zurecht. Jetzt müsste ich nurnoch wissen wie ich die vergangene Zeit messe wie z.B. mit Millisecs() bei b3d

US-Blitz

ehemals "SimssmiS"

So, Feb 03, 2013 17:04
Antworten mit Zitat

Danke schonmal
@Blade Hatte ich auch schon gesehen kam aber nicht mit der Timer Klasse zurecht.

Jetzt müsste ich nurnoch wissen wie ich die vergangene Zeit messe wie z.B. mit Millisecs() bei b3d

	Addi	So, Feb 03, 2013 17:18 Antworten mit Zitat
System.currentTimeMillis() Rückgabetyp dürfte long sein (wenn ich mich nicht irre)
BP/B3D/BMax : Lerne Java : Früher mal Lite-C : Gewinner BCC 62

Addi

So, Feb 03, 2013 17:18
Antworten mit Zitat

System.currentTimeMillis()
Rückgabetyp dürfte long sein (wenn ich mich nicht irre)

BP/B3D/BMax : Lerne Java : Früher mal Lite-C : Gewinner BCC 62

	Starwar	So, Feb 03, 2013 17:42 Antworten mit Zitat
Wenn du eine GUI-Applikation machen willst verwende die AWT/Swing-Timer da diese Eventbasiert arbeiten. Wenn du eine Gameloop machen willst bist du mit Thread.sleep besser breaten, weil du da die Wartezeiten flexibler anpassen kannst (allerdings blockiert Thread.sleep den gesamten Thread). Wenn du Spiele in Java schreiben willst guck dir http://www.lwjgl.org/ oder Slick2D http://www.slick2d.org/ an. Wobei Slick dir den einfacheren Einstieg ermöglicht (es baut auf LWJGL auf). Java2D ist NICHT für Spiele geeigent. Man kann damit wunderbare (interaktive) Diagramme und Visualisierungen zuabuern, aber für Spiele bringt es zu wenig Geschwindigkeit. MFG

Starwar

So, Feb 03, 2013 17:42
Antworten mit Zitat

Wenn du eine GUI-Applikation machen willst verwende die AWT/Swing-Timer da diese Eventbasiert arbeiten. Wenn du eine Gameloop machen willst bist du mit Thread.sleep besser breaten, weil du da die Wartezeiten flexibler anpassen kannst (allerdings blockiert Thread.sleep den gesamten Thread).
Wenn du Spiele in Java schreiben willst guck dir http://www.lwjgl.org/ oder Slick2D http://www.slick2d.org/ an.
Wobei Slick dir den einfacheren Einstieg ermöglicht (es baut auf LWJGL auf).
Java2D ist NICHT für Spiele geeigent. Man kann damit wunderbare (interaktive) Diagramme und Visualisierungen zuabuern, aber für Spiele bringt es zu wenig Geschwindigkeit.
MFG

	Vertex	So, Feb 03, 2013 20:42 Antworten mit Zitat
Du kannst auch die schedule-Methode von Timer nutzen: Code: [AUSKLAPPEN] [EINKLAPPEN] // true bedeutet Daemon-Thread, canceled also, wenn main-Thread ended final Timer timer = new Timer(true); timer.schedule(new TimerTask() { @Override public void run() { System.out.println("tick"); } }, 0, TimeUnit.SECONDS.toMillis(1)); Der erste Parameter ist ein Objekt der annonymen Klasse, die TimerTask implementiert. Der zweite Parameter ist delay, also ab wann der Timer losgeht. Der dritte Parmater ist die period, also aller wieviel Millisekunden die run-Methode des übergebenen Runnable-Objekts aufgerufen werden soll (hier jede Sekunde).
vertex.dreamfall.at \| GitHub

Vertex

So, Feb 03, 2013 20:42
Antworten mit Zitat

Du kannst auch die schedule-Methode von Timer nutzen:

Code: [AUSKLAPPEN]

   // true bedeutet Daemon-Thread, canceled also, wenn main-Thread ended
   final Timer timer = new Timer(true);
   timer.schedule(new TimerTask() {
      @Override
      public void run() {
         System.out.println("tick");
      }
   }, 0, TimeUnit.SECONDS.toMillis(1));

Der erste Parameter ist ein Objekt der annonymen Klasse, die TimerTask implementiert. Der zweite Parameter ist delay, also ab wann der Timer losgeht. Der dritte Parmater ist die period, also aller wieviel Millisekunden die run-Methode des übergebenen Runnable-Objekts aufgerufen werden soll (hier jede Sekunde).

vertex.dreamfall.at | GitHub

	DAK	So, Feb 03, 2013 21:50 Antworten mit Zitat
Thread.sleep() in der Hauptschleife zählt als ziemlich böse (kann unter relativ häufigen Umständen Exceptions werfen). In Java sollte man das so machen, wie Vertex es gesagt hat.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

So, Feb 03, 2013 21:50
Antworten mit Zitat

Thread.sleep() in der Hauptschleife zählt als ziemlich böse (kann unter relativ häufigen Umständen Exceptions werfen). In Java sollte man das so machen, wie Vertex es gesagt hat.

Gewinner der 6. und der 68. BlitzCodeCompo

	Tornado11	Mo, Feb 04, 2013 2:54 Antworten mit Zitat
Übliche "Game-loop" findest du in diesem Tutorial schön erklärt: http://www.java-gaming.org/top.../view.html [Englisch] Zitat: Thread.sleep() in der Hauptschleife zählt als ziemlich böse (kann unter relativ häufigen Umständen Exceptions werfen). In Java sollte man das so machen, wie Vertex es gesagt hat. Ne ne, die meisten Java-games brauchen Thread.sleep() zum synchronisieren. Z.B. Das sehr bekannte Lwjgl (opengl wrapper für Java) braucht unter sync() auch Thread.sleep() (und macht noch ein paar sachen um die Loops "weicher" zu machen). Java ist manchmal schon ein bischen komisch. z.B. dieser recht häufig angewendete "Hack" Code: [AUSKLAPPEN] [EINKLAPPEN] new Thread() { public void run() { try{ Thread.sleep(Long.MAX_VALUE); } catch(Exception exc) {} } }.start(); macht Thread.sleep() Aufrufe viel genauer auf einige Plattformen wie z.B. Windows.

Tornado11

Mo, Feb 04, 2013 2:54
Antworten mit Zitat

Übliche "Game-loop" findest du in diesem Tutorial schön erklärt:
http://www.java-gaming.org/top.../view.html [Englisch]
Zitat:

Thread.sleep() in der Hauptschleife zählt als ziemlich böse (kann unter relativ häufigen Umständen Exceptions werfen). In Java sollte man das so machen, wie Vertex es gesagt hat.

Ne ne, die meisten Java-games brauchen Thread.sleep() zum synchronisieren. Z.B. Das sehr bekannte Lwjgl (opengl wrapper für Java) braucht unter sync() auch Thread.sleep() (und macht noch ein paar sachen um die Loops "weicher" zu machen).

Java ist manchmal schon ein bischen komisch. z.B. dieser recht häufig angewendete "Hack"

Code: [AUSKLAPPEN]

new Thread() {
public void run() {
try{
Thread.sleep(Long.MAX_VALUE);
}
catch(Exception exc) {}
}
}.start();

macht Thread.sleep() Aufrufe viel genauer auf einige Plattformen wie z.B. Windows.

	Vertex	Mo, Feb 04, 2013 11:21 Antworten mit Zitat
DAK hat Folgendes geschrieben: Thread.sleep() in der Hauptschleife zählt als ziemlich böse (kann unter relativ häufigen Umständen Exceptions werfen). In der sleep-Methode wird die InterruptedException geworfen, wenn ein anderer Thread versucht, den Thread zu unterbrechen (Thread#interrupt). Durch Aufruf von Thread#interrupt wird dem Thread gesagt, dass er so früh wie möglich unterbrechen soll (der Thread kann das mit Thread#isInterrupted abfragen). Während der Ausführung von sleep wird unmittelbar aus sleep zurückgekehrt, indem die InterruptedException geworfen wird. Standardverhalten sollte dann sein, so früh, wie möglich die run-Methode zu verlassen. Andere Exceptions sind in der JavaDoc auch nicht verzeichnet. Tornado11 hat Folgendes geschrieben: Code: [AUSKLAPPEN] [EINKLAPPEN] new Thread() { public void run() { try{ Thread.sleep(Long.MAX_VALUE); } catch(Exception exc) {} } }.start(); macht Thread.sleep() Aufrufe viel genauer auf einige Plattformen wie z.B. Windows. Was soll der Code oben denn bewirken? Wie gesagt, die InterruptedException sollte man nicht ignorieren. Das interrupted-Flag wird gecleart, und deswegen hat man keine weitere Möglichkeit mehr abzufragen, ob der Thread beendet werden soll. Und mit Aussagen zur Plattform würde ich mich auch nicht beschäftigen. Für eine best. Plattform zu optimieren kann auch in die Hose gehen. Schließlich gibt es dort auch versch. JVMs mit unterschiedlichen Verhalten. Zumal macht es den Quelltext schwerer verständlich.
vertex.dreamfall.at \| GitHub

Vertex

Mo, Feb 04, 2013 11:21
Antworten mit Zitat

DAK hat Folgendes geschrieben:

Thread.sleep() in der Hauptschleife zählt als ziemlich böse (kann unter relativ häufigen Umständen Exceptions werfen).

In der sleep-Methode wird die InterruptedException geworfen, wenn ein anderer Thread versucht, den Thread zu unterbrechen (Thread#interrupt). Durch Aufruf von Thread#interrupt wird dem Thread gesagt, dass er so früh wie möglich unterbrechen soll (der Thread kann das mit Thread#isInterrupted abfragen). Während der Ausführung von sleep wird unmittelbar aus sleep zurückgekehrt, indem die InterruptedException geworfen wird. Standardverhalten sollte dann sein, so früh, wie möglich die run-Methode zu verlassen. Andere Exceptions sind in der JavaDoc auch nicht verzeichnet.

Tornado11 hat Folgendes geschrieben:

Code: [AUSKLAPPEN]

new Thread() {
public void run() {
try{
Thread.sleep(Long.MAX_VALUE);
}
catch(Exception exc) {}
}
}.start();

macht Thread.sleep() Aufrufe viel genauer auf einige Plattformen wie z.B. Windows.

Was soll der Code oben denn bewirken? Wie gesagt, die InterruptedException sollte man nicht ignorieren. Das interrupted-Flag wird gecleart, und deswegen hat man keine weitere Möglichkeit mehr abzufragen, ob der Thread beendet werden soll.
Und mit Aussagen zur Plattform würde ich mich auch nicht beschäftigen. Für eine best. Plattform zu optimieren kann auch in die Hose gehen. Schließlich gibt es dort auch versch. JVMs mit unterschiedlichen Verhalten. Zumal macht es den Quelltext schwerer verständlich.

vertex.dreamfall.at | GitHub

	Addi	Mo, Feb 04, 2013 15:17 Antworten mit Zitat
Bin mir nicht sicher, aber Thread.wait() ist doch besser für synchronisation geeignet (so wie ich das verstanden habe), oder?
BP/B3D/BMax : Lerne Java : Früher mal Lite-C : Gewinner BCC 62

Addi

Mo, Feb 04, 2013 15:17
Antworten mit Zitat

Bin mir nicht sicher, aber Thread.wait() ist doch besser für synchronisation geeignet (so wie ich das verstanden habe), oder?

BP/B3D/BMax : Lerne Java : Früher mal Lite-C : Gewinner BCC 62

	DAK	Mo, Feb 04, 2013 16:55 Antworten mit Zitat
Okay, klar kann man Thread.Sleep() verwenden, aber Netbeans haut mir da immer mit einem Warning auf die Finger. Ich hab mir immer meine Hauptschleife per Timer.schedule realisiert. Ist mir hald auch schöner vorgekommen. Thread.Sleep() hat mir hald doch sehr viel vom BB-Delay-Befehl, der ja auch als bitterböse gilt. Außerdem kann man damit nicht wirklich sinnvoll auf eine Framerate/Taktrate beschränken, sondern nur die Wartezeit zwischen Frames einstellen, was hald bei weitem nicht so genau ist.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mo, Feb 04, 2013 16:55
Antworten mit Zitat

Okay, klar kann man Thread.Sleep() verwenden, aber Netbeans haut mir da immer mit einem Warning auf die Finger. Ich hab mir immer meine Hauptschleife per Timer.schedule realisiert. Ist mir hald auch schöner vorgekommen. Thread.Sleep() hat mir hald doch sehr viel vom BB-Delay-Befehl, der ja auch als bitterböse gilt. Außerdem kann man damit nicht wirklich sinnvoll auf eine Framerate/Taktrate beschränken, sondern nur die Wartezeit zwischen Frames einstellen, was hald bei weitem nicht so genau ist.

Gewinner der 6. und der 68. BlitzCodeCompo

	Tornado11	Di, Feb 05, 2013 19:05 Antworten mit Zitat
@Vertex: schau mal hier : [url] http://lwjgl.org/forum/index.p...pic=3852.0 [/url] Zitat: Yeah this looks like voodoo, but it's a (sad) known fact... Bei Linux wird etwa alle ~1ms zu deinem Thread gewechselt (auflösung des Schedulers). Bei Windows ist das etwa ~10ms und führt manchmal zu Problemen (stuttering). Da bei 60fps nicht zwischen allen Frames gleich lang "pausiert" wird (da die sleep() Dauer von diesem Wechseln abhängt). Zitat: Unfortunately, things are now choppy. It's not severe, but sporadically the game looks like it's running at 20-30 fps auf java-gaming.org und auf dem lwjgl Forum hat es schon längere Diskussion gegeben, die dieses Thema auch ausführlich behandelt haben. Zitate sind aus dem Link entnommen Hier der "Timing" Code von lwjgl, unter sync(int fps). Ich behaupte nicht, dass dies die allerbeste Lösung ist, aber nach meiner Erfahrung ein sehr solides Stück Code.

Tornado11

Di, Feb 05, 2013 19:05
Antworten mit Zitat

@Vertex: schau mal hier : [url] http://lwjgl.org/forum/index.p...pic=3852.0
[/url]
Zitat:

Yeah this looks like voodoo, but it's a (sad) known fact...

Bei Linux wird etwa alle ~1ms zu deinem Thread gewechselt (auflösung des Schedulers).
Bei Windows ist das etwa ~10ms und führt manchmal zu Problemen (stuttering). Da bei 60fps nicht zwischen allen Frames gleich lang "pausiert" wird (da die sleep() Dauer von diesem Wechseln abhängt).
Zitat:

Unfortunately, things are now choppy. It's not severe, but sporadically the game looks like it's running at 20-30 fps

auf java-gaming.org und auf dem lwjgl Forum hat es schon längere Diskussion gegeben, die dieses Thema auch ausführlich behandelt haben.

Zitate sind aus dem Link entnommen

Hier der "Timing" Code von lwjgl, unter sync(int fps). Ich behaupte nicht, dass dies die allerbeste Lösung ist, aber nach meiner Erfahrung ein sehr solides Stück Code.

Übersicht

Sonstiges

Smalltalk

Nach Oben

BlitzBasic Portal

Java Operations per Second

Betreff: Java Operations per Second