repaint() blockieren

[Network]

Hi,

ich wusste nicht nach was ich googlen sollte, deshalb stelle ich meine frage hier:
Wie blockiere ich, dass sich das Fenster ständig repainted?
(Wenn notwendig auch Vollbild, aber mir ist aufgefallen, dass das nur ein Fenster ohne Dekoration ist)

Ich habe ein Spiel geschrieben, dort wird nach jedem durchlauf (alle 10ms) das gesammte Tile-Spielfeld zurückgesetzt (Sichtbereich) und dann neuberechnet.
Aus irgendeinem Grund jedoch aktualisiert sich das Fenster in genau diesem Prozess hin und wieder. Was passiert ist, dass das Spielfeld gezeichnet wird mit der Information das manche Bereiche als "nicht sichbar" gekennzeichnet sind - Lampen fangen an manchen Stellen an zu flackern.

Mal abgesehen, dass der Effekt sehr toll aussieht... er ist unkontrolliert.

Deshalb die Frage ob ich irgendwie das neuzeichnen entautomatisieren kann?
Ich habe bereits davon gelesen, auch in diesem Forum, aber es wurde häufig dazu gesagt, man soll es nicht tun, weshalb ich nie weitergelesen hatte oder mir irgendetwas davon gemerkt.

Vielen Dank
Gruß
Net

 

[Marco13]

Meine Kristallkugel sagt, dass du dieses "Zurücksetzen" alle 10ms auf einem anderen Thread als dem EDT macht, und er deswegen manchmal einen Zustand zeichnet, der "halb zurückgesetzt" ist. Mehr code und infos könnten helfen.

 

[Network]

Meine Kristallkugel sagt, dass du dieses "Zurücksetzen" alle 10ms auf einem anderen Thread als dem EDT macht, und er deswegen manchmal einen Zustand zeichnet, der "halb zurückgesetzt" ist. Mehr code und infos könnten helfen.

Kristallkugeln sind toll.
Entschuldige meine eigentliche Frage lautete ja eig. ob man irgendwie repaint entautomatisieren kann und nicht was im Code falsch ist.

Also

System.out.println( "EDT: " + SwingUtilities.isEventDispatchThread() );

liefert EDT: false

Meine Kristallkugel erzählt mir jetzt, vieleicht ist es auch nur Hirn.exe dass ich keinen eigenen Thread starten sollte, sowie es bei vielen anderen Programmen eine art Pflicht darstellt.
Hilft aber leider auch nichts... Weiterhin ein flackern.
Das Codefragment von oben gibt weiterhin false zurück.

Hier der Originalcode, der alle Schritte beinhaltet, von der Main bis zum oben genannten isEventDispatcherThread-Code.
(Die Loop-Klasse ist unvollständig)

Main:

public class Main {
	
	public static void main(String[] args) {
		new Loop();
	}
}

Loop:

public class Loop /* extends Thread */ {
	
	public Loop() {
		logic = new Logic();
		
		DataInOutput datainoutput = new DataInOutput();
		Database database = new Database( datainoutput, new Editor( datainoutput ), logic );
		
		logic.setDatabase(database);
		look = new Look( logic, database );
		
		for( int i = 0; i < 10; i++ ) {
			database.setDigged(21+i, 10);
		}
		
		database.createUnit(30, 10, "Drill");
		database.createUnit(29, 10, "Constructor");
		
		run();
		//new Thread( this ).start();
	}
	public void run() {
		try {
			
			System.out.println( "EDT: " + SwingUtilities.isEventDispatchThread() );
			// "EDT: false"
			
			last = System.nanoTime();
			
			while( !logic.exit() ) {
				logic.compute();
				look.repaint();
				
				initiateDelta();
				if( delta > 0 ) Thread.sleep( delta );
				computeDelta();
			}
			
		} catch (Exception e) {
			e.printStackTrace();
		}
		System.exit( 0 );
	}
}

 

[Marco13]

Dort wird das "run" jetzt im Main-Thread ausgeführt (wie man bei sowas wie
System.out.println("Thread: "+Thread.currentThread());
auch sehen würde.

Das entscheidende ist wohl, das Zeichnen des Spielfeldes und das "zurücksetzen" (was auch immer das heißt) so zu synchronisieren, dass nicht ein halbes Spielfeld gezeichnet wird. WIE man das genau macht, kann man allgemein nicht sagen. Mit Locks/Conditions/Semaphores, synchronized, Double-Buffering (nicht beim Zeichnen, sondern bei der Berechnung) oder den "verändernden" Teil, falls möglich, auf dem EDT machen lassen.

 

[Michael...]

Grundsätzlich gibt es die Möglichkeit mittels active rendering sich selbst um das neuzeichnen zu kümmern.
Vergleiche auch: Passive vs. Active Rendering (The Java™ Tutorials > Bonus > Full-Screen Exclusive Mode API)
Ob das in diesem Fall sinnvoll ist kann ich so nicht beurteilen.
Wenn Du hier ein KSKB postet könnte man aber schauen wo der Fehler/ das Problem liegt und ob das ganze nicht auch mit dem standardmäßigen passive rendering zu lösen ist.

 

[Network]

@Marco13
Leider würde ein Posten des Codes den Rahmen hier sprengen, wobei deine Stichworte sehr gute Ansätze sind die sehr weiterhelfen.

Selbstverständlich habe ich mir auch eigene Gedanken gemacht, jedoch mit dem jetzigen Programmaufbau/Referenzen hat jedes Objekt nur die Referenz auf sein an der selben Position liegendes Tile. Und dieses wiederum die Referenz auf die 8 Nachbartiles.
Natürlich könnte man sich jetzt von Tile zu Tile durchcrawlen, was aber in zigtausend Methodenaufrufen enden kann. Performanceängste hab ich da.

@Michael...
Ok vielen Dank, genau das hatte ich gesucht. Perfekt Danke.
Ein KSKB ist denke ich nicht nötig.
Active Rendering ist auch nicht (mehr) direkt notwendig.
Jetzt muss ich natürlich abwägen ob ich mir Marco13s Tipps zu herzen nehme und diese umsetze - was natürlich dann später bei der Ersetzung durch eine OpenGL-Visualisierungs-Klasse Probleme machen könnte.
Oder es mit ActiveRendering aufnehme und all seinen Nachteilen (Obwohl ich keine wirklich sehen konnte in dem hilfreichen Link).
Das wird aber das kleinste Problem sein.

Ich danke nochmals
mit freundlichen Grüßen
Net

 

[Marco13]

Jetzt muss ich natürlich abwägen ob ich mir Marco13s Tipps zu herzen nehme und diese umsetze - was natürlich dann später bei der Ersetzung durch eine OpenGL-Visualisierungs-Klasse Probleme machen könnte.

Welche Tipps meinst du genau? Bei OpenGL ist es fast noch wichtiger, dass alles auf dem richtigen Thread passiert, aber der konzeptuelle Unterschied zu Swing ist so groß, dass man sich für eine Infrastruktur, die "wahlweise" eine von beiden Visualisierungen unterstützt schon sehr genau die möglichen Ansätze überlegen sollte...