Sprünge bei Netzwerk Spiel verhindern

Übersicht

BlitzBasic

Beginners-Corner

	Bobo2040 Betreff: Sprünge bei Netzwerk Spiel verhindern	Sa, Jul 05, 2014 23:19 Antworten mit Zitat
Hallo Ich habe ein Netzwerk Spiel (PVP Orbit) und wenn man dort Spielt, wird alle 90ms ein TCP Paket gesendet das sind ca. 8-10 Pakete pro sekunde je nach Verbindung so in dieser Zeit bewegt sich der Spieler aber so schnell das es den anschein erweckt, das es "laggt" weil er kleine Sprünge macht also der Gegner.. wie kann ich diese Verhindern? Also das es "weiche" bewegungen sind Mfg EDIT: Noch eine Frage Man kann ja mit Vektoren ein Punkt bewegen so das bekomme ich hin xD Aber bei Lasern ist der Abstand immer unterschiedlich und führt zu Grafik Fehlern ausserdem Siehts doof aus wenn ein Schuss unterschiedlich schnell ist... Mein Code wie ich auch zum Bewegen benutze wollte ich nun auch für den Laser schuss benutzen aber leider "löst" sich der Schuss nicht von meinem Spieler Schiff...Ich stehe gerade ein wenig aufm Schlauch was in der Formel falsch ist ... Mein Code: BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] VX#=Enemy\x_coor+KameraX-SpielerX# VY#=Enemy\y_coor+KameraY-SpielerY# VektorX#=VX#/Sqr(VX#VX#+VY#VY#) VektorY#=VY#/Sqr(VX#VX#+VY#VY#) LaserX#=SpielerX#+VektorX#LaserSpeed# LaserY#=SpielerY#+VektorY#LaserSpeed# ;Laser Zeichnen Color 50,255,50 Line LaserX#-KameraX,LaserY#-KameraY,LaserX#+VektorX#2LaserSpeed#-KameraX,LaserY#+VektorY#2LaserSpeed#-KameraY Bin auch für andere Lösungen offen! Mfg
bitro.de

Bobo2040

Betreff: Sprünge bei Netzwerk Spiel verhindern

Sa, Jul 05, 2014 23:19
Antworten mit Zitat

Hallo

Ich habe ein Netzwerk Spiel (PVP Orbit) und wenn man dort Spielt, wird alle 90ms ein TCP Paket
gesendet das sind ca. 8-10 Pakete pro sekunde je nach Verbindung so in dieser Zeit bewegt sich der Spieler aber so schnell das es den anschein erweckt, das es "laggt" weil er kleine Sprünge macht also der Gegner..
wie kann ich diese Verhindern? Also das es "weiche" bewegungen sind Smile

Mfg

EDIT:
Noch eine Frage Smile

Man kann ja mit Vektoren ein Punkt bewegen so das bekomme ich hin xD
Aber bei Lasern ist der Abstand immer unterschiedlich und führt zu Grafik Fehlern ausserdem Siehts doof aus
wenn ein Schuss unterschiedlich schnell ist...
Mein Code wie ich auch zum Bewegen benutze wollte ich nun auch für den Laser schuss benutzen aber leider
"löst" sich der Schuss nicht von meinem Spieler Schiff...Ich stehe gerade ein wenig aufm Schlauch was in der
Formel falsch ist ...
Mein Code:
BlitzBasic: [AUSKLAPPEN]


					VX#=Enemy\x_coor+KameraX-SpielerX#
					VY#=Enemy\y_coor+KameraY-SpielerY#
			
					VektorX#=VX#/Sqr(VX#*VX#+VY#*VY#)
					VektorY#=VY#/Sqr(VX#*VX#+VY#*VY#)
			
					LaserX#=SpielerX#+VektorX#*LaserSpeed#
					LaserY#=SpielerY#+VektorY#*LaserSpeed#
					
					;Laser Zeichnen
					Color 50,255,50
					Line LaserX#-KameraX,LaserY#-KameraY,LaserX#+VektorX#*2*LaserSpeed#-KameraX,LaserY#+VektorY#*2*LaserSpeed#-KameraY

Bin auch für andere Lösungen offen!

Mfg

bitro.de

	DAK	So, Jul 06, 2014 9:11 Antworten mit Zitat
Ok, zur ersten Frage: Ruckeln im Netzwerk verhindern. Dazu gibt es hier im Forum schon ganz viele und ausführliche Posts. Mal ganz billig zusammengefasst: liefere nicht nur die Positionen sondern auch die Bewegungsrichtungen mit (z.B. die momentan gedrückten Tasten) und berechne die Bewegung zwischen Positionsupdates lokal weiter. Wenn also Vorne gedrückt ist, dann lass ihn weiter nach vorne fliegen. Kommt ein neues Positionsupdate, dann überschreibe die momentane Position usw. mit dem Inhalt des Updates. Dabei ist es sehr wichtig, dass du FRAMEUNABHÄNGIG programmierst, was du momentan scheinbar nicht tust. Ansonsten bewegen sich Spieler mit einem schnellen Computer schneller, als solche mit einem langsamen PC. Zur zweiten Frage: Bist du dir sicher, dass die Kameraposition in die Berechnung rein gehört? Außerdem hast du die Vektor-Sache falsch verstanden. Was du hier tust ist: LaserXY = SpielerXY + LaserDirXY * LaserSpeed Merkst du was? Jedes Frame wird der Laser zuerst an die Spielerposition gesetzt, und bewegt sich dann ein Frame weit vom Spieler weg, weswegen er hängen bleibt. Was du brauchst ist beim Schießen: LaserXY = SpielerXY Und dann jedes Frame LaserXY = LaserXY + LaserDir * LaserSpeed
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

So, Jul 06, 2014 9:11
Antworten mit Zitat

Ok, zur ersten Frage: Ruckeln im Netzwerk verhindern.
Dazu gibt es hier im Forum schon ganz viele und ausführliche Posts. Mal ganz billig zusammengefasst: liefere nicht nur die Positionen sondern auch die Bewegungsrichtungen mit (z.B. die momentan gedrückten Tasten) und berechne die Bewegung zwischen Positionsupdates lokal weiter. Wenn also Vorne gedrückt ist, dann lass ihn weiter nach vorne fliegen. Kommt ein neues Positionsupdate, dann überschreibe die momentane Position usw. mit dem Inhalt des Updates.

Dabei ist es sehr wichtig, dass du FRAMEUNABHÄNGIG programmierst, was du momentan scheinbar nicht tust. Ansonsten bewegen sich Spieler mit einem schnellen Computer schneller, als solche mit einem langsamen PC.

Zur zweiten Frage:
Bist du dir sicher, dass die Kameraposition in die Berechnung rein gehört?

Außerdem hast du die Vektor-Sache falsch verstanden.
Was du hier tust ist:

LaserXY = SpielerXY + LaserDirXY * LaserSpeed

Merkst du was?

Jedes Frame wird der Laser zuerst an die Spielerposition gesetzt, und bewegt sich dann ein Frame weit vom Spieler weg, weswegen er hängen bleibt.

Was du brauchst ist beim Schießen:

LaserXY = SpielerXY

Und dann jedes Frame

LaserXY = LaserXY + LaserDir * LaserSpeed

Gewinner der 6. und der 68. BlitzCodeCompo

	Bobo2040	So, Jul 06, 2014 20:09 Antworten mit Zitat
Ich benutze einen Timer also läuft das Spiel auf 60 FPS solange es der PC natürlich zulässst... Und erstmal DANKE für die Antwort Mit der Bewegungsrichtung ist das so das ich die Rotation des Gegners geliefert bekomme also den Winkel wie sein Schiff ist weil die Steuerung per Maus ist Das müsste ich denke mal hinbekommen es zurückzurechnen ... dein Lösungsvorschlag werde ich gleich mal ausprobieren! Mfg
bitro.de

Bobo2040

So, Jul 06, 2014 20:09
Antworten mit Zitat

Ich benutze einen Timer also läuft das Spiel auf 60 FPS solange es der PC natürlich zulässst...
Und erstmal DANKE für die Antwort Smile

Mit der Bewegungsrichtung ist das so das ich die Rotation des Gegners
geliefert bekomme also den Winkel wie sein Schiff ist weil die Steuerung per Maus ist Wink

Das müsste ich denke mal hinbekommen es zurückzurechnen ... dein Lösungsvorschlag werde ich gleich mal ausprobieren!

Mfg

bitro.de

	DAK	So, Jul 06, 2014 20:42 Antworten mit Zitat
Zurückrechnen geht per cos(winkel)/sin(winkel). Rein den Timer verwenden ist bei einem Netzwerkspiel zu wenig. Einerseits sind dann immer noch Spieler mit schlechten PCs langsamer, und auch plötzliche Lags stoppen den Spieler, und andererseits lässt sich diese Beschränkung mit so simplen Tools wie der CheatEngine aushebeln. Frameunabhängigkeit ist ein solches Basis-Ding, das sollte schon jedes normale Spiel verwenden. Für Netzwerkspiele ist es ein absolutes Muss.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

So, Jul 06, 2014 20:42
Antworten mit Zitat

Zurückrechnen geht per cos(winkel)/sin(winkel).

Rein den Timer verwenden ist bei einem Netzwerkspiel zu wenig. Einerseits sind dann immer noch Spieler mit schlechten PCs langsamer, und auch plötzliche Lags stoppen den Spieler, und andererseits lässt sich diese Beschränkung mit so simplen Tools wie der CheatEngine aushebeln. Frameunabhängigkeit ist ein solches Basis-Ding, das sollte schon jedes normale Spiel verwenden. Für Netzwerkspiele ist es ein absolutes Muss.

Gewinner der 6. und der 68. BlitzCodeCompo

	Bobo2040	So, Jul 06, 2014 21:18 Antworten mit Zitat
Okay gut Danke Ich habe mir das Tut Frameunabhängig Programmieren von IonPainter eben mal angesehen...schwer ist das ja nicht xD aber warum hat mir das keiner vorher gesagt :'((((( muss jetzt sehr viel Code umschreiben :/ Mfg
bitro.de

Bobo2040

So, Jul 06, 2014 21:18
Antworten mit Zitat

Okay gut Danke Smile

Ich habe mir das Tut Frameunabhängig Programmieren von IonPainter eben mal angesehen...schwer ist das ja nicht xD aber warum hat
mir das keiner vorher gesagt :'((((( muss jetzt sehr viel Code umschreiben :/

Mfg

bitro.de

	DAK	Mo, Jul 07, 2014 6:48 Antworten mit Zitat
Steht im BlitzFAQ als Antwort auf die allererste Frage. Und das BlitzFAQ ist dazu da, häufig gestellte Fragen aus dem Weg zu räumen, so dass wir sie nicht jedes Mal von neuem erklären dürfen. Und so viel Aufwand ist die Frame-unabhängige Programmierung meist nicht, auch wenn man sie erst nachträglich einbaut.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mo, Jul 07, 2014 6:48
Antworten mit Zitat

Steht im BlitzFAQ als Antwort auf die allererste Frage.
Und das BlitzFAQ ist dazu da, häufig gestellte Fragen aus dem Weg zu räumen, so dass wir sie nicht jedes Mal von neuem erklären dürfen.

Und so viel Aufwand ist die Frame-unabhängige Programmierung meist nicht, auch wenn man sie erst nachträglich einbaut.

Gewinner der 6. und der 68. BlitzCodeCompo

	Bobo2040	Mo, Jul 07, 2014 14:40 Antworten mit Zitat
joar aber es müssen doch alle Variablen errechnet die verändert werden mfg
bitro.de

Bobo2040

Mo, Jul 07, 2014 14:40
Antworten mit Zitat

joar

aber es müssen doch alle Variablen errechnet die verändert werden Smile

mfg

bitro.de

	DAK	Mo, Jul 07, 2014 15:25 Antworten mit Zitat
Im Grunde berechnest du dir nur ein Mal pro Frame die Framedauer in Sekunden (oder in 1/60 Sekunden) und multiplizierst alles was du frameunabhängig haben willst, mit dem Wert. deltaT = (MilliSecs()-lastFrameMS)60/1000 (Die 1000 um auf Sekunden zu kommen, die 60 für die 1/60-Sekunden) x = x + speed wird also x = x + speeddeltaT Machst du 1/60-Sekunden musst du keine Werte ändern, ist also einfach zu implementieren. Machst du ganze Sekunden, dann ist es zwar mehr Aufwand jetzt (da du alle Werte anpassen musst), kannst dafür alle Werte in z.B. Pixel pro Sekunde angeben, was schöner ist.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mo, Jul 07, 2014 15:25
Antworten mit Zitat

Im Grunde berechnest du dir nur ein Mal pro Frame die Framedauer in Sekunden (oder in 1/60 Sekunden) und multiplizierst alles was du frameunabhängig haben willst, mit dem Wert.

deltaT = (MilliSecs()-lastFrameMS)*60/1000

(Die 1000 um auf Sekunden zu kommen, die 60 für die 1/60-Sekunden)

x = x + speed

wird also

x = x + speed*deltaT

Machst du 1/60-Sekunden musst du keine Werte ändern, ist also einfach zu implementieren. Machst du ganze Sekunden, dann ist es zwar mehr Aufwand jetzt (da du alle Werte anpassen musst), kannst dafür alle Werte in z.B. Pixel pro Sekunde angeben, was schöner ist.

Gewinner der 6. und der 68. BlitzCodeCompo

	Bobo2040	Mo, Jul 07, 2014 17:28 Antworten mit Zitat
Okay Aber noch eine klitze kleine Frage : Es heist immer kein Timer o.ä. ist schlecht! Aber ich benutze doch garkeinen Timer in diesem Falle weil ich ja das maximum ausm PC holen will und somit auf einem Kern IMMER 95-100% Auslastung habe... sogar bei nem kleinen Pacman o.ä. was soll ich also machen ? bin gerade ein wenig verwirrt weil man ja immer nen Timer oder sowas benutzen sollte aber dennoch sagen viele das man Frameunabhängig Programmieren soll... °-° Mfg
bitro.de

Bobo2040

Mo, Jul 07, 2014 17:28
Antworten mit Zitat

Okay

Aber noch eine klitze kleine Frage :
Es heist immer kein Timer o.ä. ist schlecht!
Aber ich benutze doch garkeinen Timer in diesem Falle weil ich ja das maximum ausm PC holen will und somit auf einem Kern IMMER 95-100% Auslastung habe... sogar bei nem kleinen Pacman o.ä.
was soll ich also machen ? bin gerade ein wenig verwirrt weil man ja immer nen Timer oder sowas benutzen sollte aber dennoch sagen viele das man Frameunabhängig Programmieren soll...
°-°

Mfg

bitro.de

	Tennisball	Mo, Jul 07, 2014 18:15 Antworten mit Zitat
Du sollst ja einen Frametimer verwenden, aber die Logik des Spiels unabhängig davon berechnen. Sprich, du machst z.B. nicht x = x + 10/60 in einem Schleifendurchlauf, sondern x = x + 10/1000 * vergangene_zeit. (vergangene_zeit gibt die vergangene Zeit seit der letzten Berechnung an.) Bei beiden Berechnungen würde sich x um 10 pro Sekunde erhöhen, beim ersten allerdings nur, wenn dauerhaft genau 60 FPS eingehalten werden. Das zweite ist nicht frameabhängig, sondern eben zeitabhängig.

Tennisball

Mo, Jul 07, 2014 18:15
Antworten mit Zitat

Du sollst ja einen Frametimer verwenden, aber die Logik des Spiels unabhängig davon berechnen. Sprich, du machst z.B. nicht x = x + 10/60 in einem Schleifendurchlauf, sondern x = x + 10/1000 * vergangene_zeit. (vergangene_zeit gibt die vergangene Zeit seit der letzten Berechnung an.) Bei beiden Berechnungen würde sich x um 10 pro Sekunde erhöhen, beim ersten allerdings nur, wenn dauerhaft genau 60 FPS eingehalten werden. Das zweite ist nicht frameabhängig, sondern eben zeitabhängig.

	Holzchopf Meisterpacker	Mo, Jul 07, 2014 18:38 Antworten mit Zitat
Frameunabhängig programmieren ist kein Widerspruch zur Benutzung von Timer Wenn du nur ein Timer benutzt aber alle Bewegungen und Berechnungen auf Hauptschleifendurchlaufbasis (also stur in jedem Frame das selbe) berechnest, wird es zu Asynchronitäten kommen, sobald "Frames" verloren gehen. Und Frames werden verloren gehen, sei es, weil ein anderes Programm kurzzeitig mehr Leistung saugt und das eigene ausbremst, weil der Benutzer das Fenster verschiebt, wodurch die Programmausführung angehalten wird, oder ganz einfach, weil der Rechner zu langsam ist. Mit einem Timer begrenzt du die Ausführungsgeschwindigkeit - was durchaus Sinn macht, denn 100% CPU-Auslastung ist auf die Dauer ungesund. Die Begrenzung mit Timer hat sogar einen entscheidenden Vorteil gegenüber anderen Methoden (die mittels Zeitmessung und Delay das Programm für x Millisekunden anhalten). Denn WaitTimer wartet immer auf den nächsten "Tick". Ist dein Programm auf 50Hz gedrosselt, läuft es effektiv mit 50Hz, 25Hz, 16.667Hz oder 12.5Hz etc. Das schaut auf den ersten Blick ganz grausig aus, aber: Diese Frequenzen ergeben sich aus der Schleifendurchlaufzeit, die dann halt immer ein Vielfaches von der Periode 20ms ist (20, weil 1000 / 50Hz = 20ms). Angeblich liefert WaitTimer die Anzahl verstrichener Ticks zurück, aber das konnte ich hier im herkömmlichen BlitzBasic nicht rekonstruieren. Wie dem auch sei: Sobald du weisst, wie viele Frames ausgeführt wurden oder auszuführen sind, kannst du einfach dementsprechend oft die Update-Routine (nicht die Zeichen-Routine) ausführen. So hat man auch keine Einbussen bei der Genauigkeit von Kollisionsroutinen, die andernfalls entstehen könnten. Hoffe, das hat einiges geklärt MfG Holzchopf
Erledige alles Schritt um Schritt - erledige alles. - Holzchopf CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018) Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm

Holzchopf

Meisterpacker

Mo, Jul 07, 2014 18:38
Antworten mit Zitat

Frameunabhängig programmieren ist kein Widerspruch zur Benutzung von Timer Exclamation

Wenn du nur ein Timer benutzt aber alle Bewegungen und Berechnungen auf Hauptschleifendurchlaufbasis (also stur in jedem Frame das selbe) berechnest, wird es zu Asynchronitäten kommen, sobald "Frames" verloren gehen. Und Frames werden verloren gehen, sei es, weil ein anderes Programm kurzzeitig mehr Leistung saugt und das eigene ausbremst, weil der Benutzer das Fenster verschiebt, wodurch die Programmausführung angehalten wird, oder ganz einfach, weil der Rechner zu langsam ist.

Mit einem Timer begrenzt du die Ausführungsgeschwindigkeit - was durchaus Sinn macht, denn 100% CPU-Auslastung ist auf die Dauer ungesund. Die Begrenzung mit Timer hat sogar einen entscheidenden Vorteil gegenüber anderen Methoden (die mittels Zeitmessung und Delay das Programm für x Millisekunden anhalten). Denn WaitTimer

wartet immer auf den nächsten "Tick". Ist dein Programm auf 50Hz gedrosselt, läuft es effektiv mit 50Hz, 25Hz, 16.667Hz oder 12.5Hz etc. Das schaut auf den ersten Blick ganz grausig aus, aber: Diese Frequenzen ergeben sich aus der Schleifendurchlaufzeit, die dann halt immer ein Vielfaches von der Periode 20ms ist (20, weil 1000 / 50Hz = 20ms). Angeblich liefert WaitTimer

die Anzahl verstrichener Ticks zurück, aber das konnte ich hier im herkömmlichen BlitzBasic nicht rekonstruieren. Wie dem auch sei: Sobald du weisst, wie viele Frames ausgeführt wurden oder auszuführen sind, kannst du einfach dementsprechend oft die Update-Routine (nicht die Zeichen-Routine) ausführen. So hat man auch keine Einbussen bei der Genauigkeit von Kollisionsroutinen, die andernfalls entstehen könnten.

Hoffe, das hat einiges geklärt Wink

MfG
Holzchopf

Erledige alles Schritt um Schritt - erledige alles. - Holzchopf
CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018)
Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm

	DAK	Mo, Jul 07, 2014 20:31 Antworten mit Zitat
Holzchopf, deinen Post hab auch ich zwei Mal lesen müssen^^ Noch mal alles zusammenzufassen: -) Wenn du nicht frameunabhängig programmierst und das Programm zu langsam rennt, dann wird das Spiel langsamer = böse -) Wenn du frameunabhängig programmierst, aber den Timer vergisst, dann rennt das Spiel zwar normal schnell (da frameunabhängig), dafür verbrennt dein Computer unnötig Leistung, da er immer auf 100% rennt. Timer weglassen und damit 100% CPU verbrennen ist NICHT das Maximum aus dem Computer holen, sondern Stomverschwendung! Wenn du den Timer weg lässt, dann geht die ganze Rechenzeit in mehr FPS. Leider kann dein Bildschirm üblicherweise nicht mehr als 60 FPS darstellen, diese ganzen schönen Frames, die dein Computer rendert, gehen direkt in den Abfall und sind völlig verschwendet. Renderst du mehr als 60 FPS, dann lässt du den Computer also Bilder berechnen, die gleich verschwinden. Hohe CPU-Auslastung bedeutet mehr Strom verbraucht (freut vor allem deine Eltern und Laptopbenutzer) und nutzt die CPU unnötig ab (freut den, der eine Neue zahlt). Las das also bitte.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mo, Jul 07, 2014 20:31
Antworten mit Zitat

Holzchopf, deinen Post hab auch ich zwei Mal lesen müssen^^

Noch mal alles zusammenzufassen:

-) Wenn du nicht frameunabhängig programmierst und das Programm zu langsam rennt, dann wird das Spiel langsamer = böse

-) Wenn du frameunabhängig programmierst, aber den Timer vergisst, dann rennt das Spiel zwar normal schnell (da frameunabhängig), dafür verbrennt dein Computer unnötig Leistung, da er immer auf 100% rennt.

Timer weglassen und damit 100% CPU verbrennen ist NICHT das Maximum aus dem Computer holen, sondern Stomverschwendung!
Wenn du den Timer weg lässt, dann geht die ganze Rechenzeit in mehr FPS. Leider kann dein Bildschirm üblicherweise nicht mehr als 60 FPS darstellen, diese ganzen schönen Frames, die dein Computer rendert, gehen direkt in den Abfall und sind völlig verschwendet.
Renderst du mehr als 60 FPS, dann lässt du den Computer also Bilder berechnen, die gleich verschwinden.

Hohe CPU-Auslastung bedeutet mehr Strom verbraucht (freut vor allem deine Eltern und Laptopbenutzer) und nutzt die CPU unnötig ab (freut den, der eine Neue zahlt). Las das also bitte.

Gewinner der 6. und der 68. BlitzCodeCompo

	Bobo2040	Di, Jul 08, 2014 17:22 Antworten mit Zitat
Okay gut danke also zusammengefasst: - max. 60 FPS sind sinnvoll - Timer trz. Frameunabhägnig benutzen - Frameunabhängig bei allen, pro Schleifendurchlauf geänderten Werten benutzen Danke Leute! Mfg
bitro.de

Bobo2040

Di, Jul 08, 2014 17:22
Antworten mit Zitat

Okay gut danke also zusammengefasst:

- max. 60 FPS sind sinnvoll
- Timer trz. Frameunabhägnig benutzen
- Frameunabhängig bei allen, pro Schleifendurchlauf geänderten Werten benutzen

Danke Leute!

Mfg

bitro.de

	DAK	Di, Jul 08, 2014 17:53 Antworten mit Zitat
Jup, genau das triffts. Zusatz: nicht alle pro Frame geänderten Werte müssen frameunabhängig gemacht werden. z.B.: x = MouseX() y = MouseY() Das hier braucht nicht frameunabhängig gemacht werden (darf es gar nicht!) da das Setzen einer Variable schon frameunabhängig ist. x = x + MouseX() y = y + MouseY() Das hier muss frameunabhängig gemacht werden, weil x/y jedes Frame erhöht werden, und das nicht von sich aus frameunabhängig ist.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Di, Jul 08, 2014 17:53
Antworten mit Zitat

Jup, genau das triffts.

Zusatz: nicht alle pro Frame geänderten Werte müssen frameunabhängig gemacht werden.

z.B.:
x = MouseX()
y = MouseY()

Das hier braucht nicht frameunabhängig gemacht werden (darf es gar nicht!) da das Setzen einer Variable schon frameunabhängig ist.

x = x + MouseX()
y = y + MouseY()

Das hier muss frameunabhängig gemacht werden, weil x/y jedes Frame erhöht werden, und das nicht von sich aus frameunabhängig ist.

Gewinner der 6. und der 68. BlitzCodeCompo

Übersicht

BlitzBasic

Beginners-Corner

Nach Oben

BlitzBasic Portal

Sprünge bei Netzwerk Spiel verhindern

Betreff: Sprünge bei Netzwerk Spiel verhindern