G
Guest
Gast
hey,
hätte die frage eigentlich auch ins forum für allgemeines bzw. anfängerfragen posten können, denke jedoch es könnte auch an den swing-komponenten, genauer der repaint() methode liegen.
in meinem tetris spiel taucht ein merkwürdiges problem auf, nach dessen auf den grund gehen ich eigentlich nur noch den entschluss fassen konnte, dass das, was passiert, nicht logisch sein kann.
Vielleicht könnt ihr mir das erklären/mutmaßen:
ich habe 3 threads (bzw. 2 "echte" trheads und nebenher läuft die main-methode).
Zwei davon schlafen jeweils 10 ms in einem cylce, der letzte schläft 500ms (dieser bewegt die fallenden steine nach unten)
Das komplette Spiel läuft sehr gut, bis auf einen fall:
wenn eine reihe voll ist, ruckelt es kurz.
Genauer: Wenn ich einen Spielstein droppe, und es füllt keine komplette Reihe aus, droppt er ohne jede Verzögerung.
Wenn er aber unten angekommen, eine Reihe ausfüllt, dann sieht man ihn erst noch kurz "warten", bevor er droppt.
Das heisst, er droppt später runter.
Was daran aber meiner Meinung nach nicht aufgeht:
der einzige (!) unterschied vom Programmablauf her zwischen den Situationen "stein füllt nach dem drop keine reihe aus" und "stein füllt nach dem drop eine reihe aus", besteht darin, dass in letzterem Fall NACH (!!) dem drop des steines noch ein paar zusätzliche berechnungen durchgeführt werden.
Weil das wie gesagt erst NACH dem drop passiert, müsste der stein genauso schnell, ohne jede verzögerung droppen (und dann höchstens unten wenn er in der reihe ankommt eine verzögerung verursachen)
es ist also nicht logisch.
das einzige, was nun sein kann, ist auch die konkrete frage an euch jetzt:
könnte es sein, dass repaint() nicht immer "funktioniert" ? Denn ich rufe im Falle einer kompletten Reihe mit absicht
repaint() vor den zusätzlichen berechnungen auf.
Falls das aber nicht erkannt wird oder so, dann könnte es natürlich wiederum verdammt gut sein, dass das verzögert, wegen den zusätzlichen berechnungen.
damit ihr euch das besser vorstellen könnt, hier mal mein main-thread in grober struktur:
also wie gesagt: solange if (element füll eine reihe aus) FALSE ist, läuft alles super.
wenn es true ist, ruckelt es kurz. aber das kann eben meiner meinung nach nicht sein, weil ich extra nochmal
ein repaint() vor der abfrage ausführe, und in dem moment ist der stein schon unten, da müsste er ihn also auch zeichnen !! er zeichnet ihn ja gemäß seinen werten!
where's the problem :bahnhof:
hätte die frage eigentlich auch ins forum für allgemeines bzw. anfängerfragen posten können, denke jedoch es könnte auch an den swing-komponenten, genauer der repaint() methode liegen.
in meinem tetris spiel taucht ein merkwürdiges problem auf, nach dessen auf den grund gehen ich eigentlich nur noch den entschluss fassen konnte, dass das, was passiert, nicht logisch sein kann.
Vielleicht könnt ihr mir das erklären/mutmaßen:
ich habe 3 threads (bzw. 2 "echte" trheads und nebenher läuft die main-methode).
Zwei davon schlafen jeweils 10 ms in einem cylce, der letzte schläft 500ms (dieser bewegt die fallenden steine nach unten)
Das komplette Spiel läuft sehr gut, bis auf einen fall:
wenn eine reihe voll ist, ruckelt es kurz.
Genauer: Wenn ich einen Spielstein droppe, und es füllt keine komplette Reihe aus, droppt er ohne jede Verzögerung.
Wenn er aber unten angekommen, eine Reihe ausfüllt, dann sieht man ihn erst noch kurz "warten", bevor er droppt.
Das heisst, er droppt später runter.
Was daran aber meiner Meinung nach nicht aufgeht:
der einzige (!) unterschied vom Programmablauf her zwischen den Situationen "stein füllt nach dem drop keine reihe aus" und "stein füllt nach dem drop eine reihe aus", besteht darin, dass in letzterem Fall NACH (!!) dem drop des steines noch ein paar zusätzliche berechnungen durchgeführt werden.
Weil das wie gesagt erst NACH dem drop passiert, müsste der stein genauso schnell, ohne jede verzögerung droppen (und dann höchstens unten wenn er in der reihe ankommt eine verzögerung verursachen)
es ist also nicht logisch.
das einzige, was nun sein kann, ist auch die konkrete frage an euch jetzt:
könnte es sein, dass repaint() nicht immer "funktioniert" ? Denn ich rufe im Falle einer kompletten Reihe mit absicht
repaint() vor den zusätzlichen berechnungen auf.
Falls das aber nicht erkannt wird oder so, dann könnte es natürlich wiederum verdammt gut sein, dass das verzögert, wegen den zusätzlichen berechnungen.
damit ihr euch das besser vorstellen könnt, hier mal mein main-thread in grober struktur:
Code:
while (true){
try{ Thread.sleep (10) } catch ...
v.repaint() // funktioniert wunderbar, zeichnet sehr flüssig
if ( element wurde gedroppt ){ // hier wurde der stein schon bewegt, also seine koordinaten geändert !!
v.repaint() // <- müsste den block zeichnen, wie er jetzt schon unten angekommen ist!
if (element füllt eine reihe aus){
... // zusätzliche berechnungen
}
}
}also wie gesagt: solange if (element füll eine reihe aus) FALSE ist, läuft alles super.
wenn es true ist, ruckelt es kurz. aber das kann eben meiner meinung nach nicht sein, weil ich extra nochmal
ein repaint() vor der abfrage ausführe, und in dem moment ist der stein schon unten, da müsste er ihn also auch zeichnen !! er zeichnet ihn ja gemäß seinen werten!
where's the problem :bahnhof:
