Zeichnen-Berechnung (Laufen will gelernt sein)

Es geht darum, beim laufen den Screen zu zu wechseln(Neuer Hintergrund, neue Spielerkoordinaten).Das habe ich schon vor Monaten gemacht, aber eine Sache hat mich da gejuckt, also schreibe ich die Sache um. In der Game-Loop gibt es eine Methode checkKlicks(), die für den Screen gerade eine Metode zum Laufen ausführt.

switch(screen){
case 1:
				le.move(this, spPosaktX, spPosaktY, klickx, klicky, 1, anim);
				break;
			case 2:
				le.move(this, spPosaktX, spPosaktY, klickx, klicky, 2, anim);
				break;
			case 3:
				le.move(this, spPosaktX, spPosaktY, klickx, klicky, 3, anim);
				so.GesprächInitiiren(new Point(klickx, klicky), 1);
				break;
			case 4:
				le.move(this, spPosaktX, spPosaktY, klickx, klicky, 4, anim);
				break;
			}
			klick = false;
		}

Es soll von screen 3 nach screen 2 gehen.In der Methode move() wird gelaufen und nach dem laufen eine Methode, namens zumNächstenScreen aufgerufen, die prüft, ob die bestimmte Fläche zum Wechsel geklickt wurde.

switch (screen) {
		case 0:
			break;
		case 1:
			if (positionx > s.getWidth() - 200
					&& positiony > s.getHeight() - 400) {
				s.neuerscreen = true;
				s.screen = 2;
				s.spPosaktX = 100;
				s.spPosaktY = 100;
				s.currentindex = 1;
				s.currentbackgroundindex = s.screen + 1;
				s.repaint();

			}
			break;
		case 2:
			if (positionx < 300 && positiony < 200) {
				s.neuerscreen = true;
				s.screen = 1;
						s.spPosaktX = 1400;
						s.spPosaktY = 300;
						s.currentindex = 1;
						s.currentbackgroundindex = s.screen + 1;
						s.repaint();

			} else if (positionx > 600 && positionx < 1000 && positiony > 200
					&& positiony < 700) {
				s.neuerscreen = true;
				s.screen = 3;
				s.spPosaktX = 100;
				s.spPosaktY = 0;
				s.currentindex = 1;
				s.currentbackgroundindex = s.screen + 1;
				s.repaint();
			}
			s.neuerscreen = false;
			break;
		case 3:
			if (positionx > s.getWidth() - 200) {
				s.screen = 4;
				s.spPosaktX = 100;
				s.spPosaktY = 0;
				s.currentindex = 1;
				s.currentbackgroundindex  = s.screen +1;
				s.repaint();
			} else if (positionx > 200 && positionx < 500 && positiony < 400) {
				System.out.println("geht1");
				s.neuerscreen = true;
				s.screen = 2;
				s.spPosaktX = 550;
				s.spPosaktY = 200;
				s.currentindex = 1;
				s.currentbackgroundindex = s.screen + 1;
				s.repaint();
			}
			s.neuerscreen = false;
			break;
		case 4:
			if (positionx < 300 && positiony < 200) {
				s.neuerscreen = true;
				s.screen = 3;
				s.spPosaktX = s.getWidth() - 100;
				s.spPosaktY = 300;
				s.currentindex = 1;
				s.currentbackgroundindex = s.screen + 1;
				s.repaint();
				
			}
		}

Bei ALLEN funktioniert es wunderbar, bloß bei screen 3, zweite if-clause, passiert folgendes:
Die Figur läuft auf die Tür zu, „durchschreitet“ jene, der Hintergrund ändert sich, doch die Figur bleibt nicht bei den angegebenen Koordinaten stehen, sie läuft munter weiter und beamt sich erst nach kurzer zeit zu den angegebenen Koordinaten.
Meine Frage: WARUM ???
:confused:

ich fürchte aus dem Code kann man nicht genug erkennen,
hast du kein genaues Programmlog, zu welchen Zeitpunkten ein Neuzeichnen mit welchen Koordinaten stattfindet?
wie ist der Verlauf, gemischt mit Logausgaben wie das System.out.println(“geht1”); in Zeile 49

evtl. auch alle Zugriffe wie
s.spPosaktX = 550;
durch set-Methodem ersetzen,
ist mühsamer, dafür kann man da wieder eine Ausgabe reinsetzen und sieht was alles passiert,
noch besser wenn man dann jeweils den Aufrufer findet,
im einfachen Fall mit
new Error().printStackTrace(System.out);
oder irgendwas schöneres aus dem StackTrace zaubern

Debugger gibts natürlich auch noch


oder allgemein mehr Code/ ganzes Programm (möglichst klein zusammengekürzt) zum Ausprobieren für andere

Die Koordinaten werden richtig gesetzt, doch “geht1” ist zweimal da, also wird die Screen-Wechsel Methode zweimal durchgeführt, was auch bedeutet, dass die lauf-Methode auch zweimal durchgeführt wird, bloß warum ?

Ich weiß ja nicht, ob das was zu bedeuten hat, aber mir fällt auf, dass du in aller Regel die Sequenz s.neuerscreen, s.screen hast, nur da nicht, da kommt nur s.screen:

		case 3:
			if (positionx > s.getWidth() - 200) {
				s.screen = 4;

Ändert nix.

und überhaupt…
if (…){
}
else if (…){
}
das sind so Konstrukte…ich würd da mindestens ne Klammer mehr machen.
if (…){
}
else {
if (…){
}
}

Ändert sich nichts

Unübersichtlicher Spaghetti code erzeugt unauffindbare, seltsame Fehler. Was soll das ganze? Hast du in deinem Spiel 4 Räume die du mit dieser switch Konstruktion wechselst? Wäre es in dem Fall nicht sehr viel besser eine Klasse Raum zu machen in der du deine Positionsberechnungen und Bilddaten auslagern kannst?

und wenn du dann nach dem inneren if noch ein else anhängst ?
if (…){
}
else {
if (…){
} else {
System.out.println(“da bin ich”);
}
}

Ich bin schon ziemlich weit und mit deiner Methode müsste ich ALLES umschreiben, außerdem funktioniert es bei den anderen Screen-Wechsels doch auch fehlerfrei.(bERt0r) @pappawinni : Die if-clauses weden ja korrekt ausgeführt und ja, es wird “da bin ich” ausgegeben

wenn aber “da bin ich” ausgegeben wird, dann trifft ja keine deiner anderen Bedingungen zu. Ist das an dem Punkt auch so gewollt ?

Immer wieder das gleiche, du musst es auf die harte Tour lernen…

Es soll nur die bedingung else des 3. screens ausgeführt werden. 1 mal. @bERt0r : Wie meinst du das ?

[quote=Zombiepriester]Ich bin schon ziemlich weit und mit deiner Methode müsste ich ALLES umschreiben[/quote]Gibt es ein kurzfristiges Budget-Limit dass Du nicht überschreiten darfst?
Langfristig würde sich eine Umstellung OOP sicher rentieren…

[quote=Zombiepriester;79170]außerdem funktioniert es bei den anderen Screen-Wechsels doch auch fehlerfrei.[/quote]Und? was nützt es Dir, wenn Du keine Analogieen aus Deinem Code extrahieren kannst, die den Fehler eingrenzen helfen? OOP würde sowas erleichtern.

bye
TT

OOP ?

Ach so.Aber so gesehen ist mein HauptPanel die Klasse “Raum”, weil dort allespassiert, was etwas mit den verschiedenen Räumen zusammenhängt. Anderes ist dann wiederum in anderen Klassen

OOP ist kein Selbstzweck,
nur weil man allen Code in eine Klasse schreibt, in Java geht es eh kaum anders, muss sich nichts wesentlich verbesser haben

genauso kann man aber auch nicht pauschal sagen ‚nutze OOP und alles wird gut‘, eben weil es kein unfehlbares Rezept ist

an dieser Stelle wüßte ich zumindest keine ganz direkte OOP-Verbesserung, mein erster Vorschlag wäre, Code-Blöcke a la

                s.screen = 3;
                s.spPosaktX = s.getWidth() - 100;
                s.spPosaktY = 300;
                s.currentindex = 1;
                s.currentbackgroundindex = s.screen + 1;
                s.repaint();

in einen Methodenaufruf
zeigeScreen(3, s.getWidth() - 100, 300, 1, s.screen + 1);
umzuwandeln,

ein paar Zeilen ergeben sich automatisch, anderes ist von den Werten her wie bisher,
gewisse Gefahr gar, Parameter zu vertauschen,
aber in der Methode wird auf jeden Fall gleich gearbeitet, kein Befehl kann vergessen werden,

und einmal mehr eine gute zentrale Stelle für Logging :wink:


aus meiner Sicht gilt weiterhin: selber mehr untersuchen oder Code posten,
viel ist sonst bisher nicht herausgekommen,
‚es muss aber funktionieren‘ und ähnliche Basta-Argumente helfen jedenfalls nicht weiter,
Tipps wie OOP, naja, grundsätzlich schon richtig

Wie wäre es, wenn man die Parameter “3, s.getWidth() - 100, 300, 1, s.screen + 1” in einem Objekt raum1 speichern würde und dann einfach zeigeScreen(raum1) aufrufen kann? Man könnte auch das Strategy Pattern verwenden um sich diesen Switch-Case gleich zu sparen.

Danke für die Tipps, ich habs jetzt so ähnlich gemacht, und es funktioniert.