Teilung der Hauptschleife in zwei Teile

Übersicht

BlitzBasic

Allgemein

	Clonker Betreff: Teilung der Hauptschleife in zwei Teile	So, Feb 01, 2004 19:58 Antworten mit Zitat
Moin. Ich möchte die Hauptschleife in meinem Spiel in zwei Teile Aufteilen. In dem Ersten sollen alle Grafiken gezeichnet werden. Dieser soll die ganze Zeit ablaufen. In dem Zweiten sollen alle Berchnungen ablaufen, wie zum Beispiel die Veränderung von Positionen der Grafiken. Dieser Teil soll in einer Sekunde 60 Mal ablaufen. Das sollte eigenlich ganz einfach sein, aber irgendwie bekomme ich das nicht hin. Ich wäre dankbar für Hilfe.
Die exzessive Akkumulation von Fremdwörtern suggeriert pseudointellektuelle Kompetenz. Athlon XP 2800\|Radeon 9600 Pro\|512MB DDR RAM\|240GB Festplatte

Clonker

Betreff: Teilung der Hauptschleife in zwei Teile

So, Feb 01, 2004 19:58
Antworten mit Zitat

Moin.

Ich möchte die Hauptschleife in meinem Spiel in zwei Teile Aufteilen.
In dem Ersten sollen alle Grafiken gezeichnet werden. Dieser soll die ganze Zeit ablaufen.

In dem Zweiten sollen alle Berchnungen ablaufen, wie zum Beispiel die Veränderung von Positionen der Grafiken. Dieser Teil soll in einer Sekunde 60 Mal ablaufen.

Das sollte eigenlich ganz einfach sein, aber irgendwie bekomme ich das nicht hin.
Ich wäre dankbar für Hilfe.

Die exzessive Akkumulation von Fremdwörtern suggeriert pseudointellektuelle Kompetenz.

Athlon XP 2800|Radeon 9600 Pro|512MB DDR RAM|240GB Festplatte

	IonPainter	So, Feb 01, 2004 20:04 Antworten mit Zitat
das ist absolut nicht nötig... eine normale hauptschleife sollte so aussehen: Code: [AUSKLAPPEN] [EINKLAPPEN] while not keyhit(1) ;Berechnungen hier hin! ;Grafikzeichnenzeug hier hin flip wend

IonPainter

So, Feb 01, 2004 20:04
Antworten mit Zitat

das ist absolut nicht nötig... eine normale hauptschleife sollte so aussehen:

Code: [AUSKLAPPEN]

while not keyhit(1)

;Berechnungen hier hin!

;Grafikzeichnenzeug hier hin

flip
wend

	Clonker	So, Feb 01, 2004 20:53 Antworten mit Zitat
Ich wollte das nur so machen weil, ich festen Frameraten nicht so gerne mag.
Die exzessive Akkumulation von Fremdwörtern suggeriert pseudointellektuelle Kompetenz. Athlon XP 2800\|Radeon 9600 Pro\|512MB DDR RAM\|240GB Festplatte

Clonker

So, Feb 01, 2004 20:53
Antworten mit Zitat

Ich wollte das nur so machen weil, ich festen Frameraten nicht so gerne mag.

Die exzessive Akkumulation von Fremdwörtern suggeriert pseudointellektuelle Kompetenz.

Athlon XP 2800|Radeon 9600 Pro|512MB DDR RAM|240GB Festplatte

	IonPainter	So, Feb 01, 2004 21:02 Antworten mit Zitat
dann musst du jede bewegung mal z.b. 60 nehmen und durch die fps teilen

IonPainter

So, Feb 01, 2004 21:02
Antworten mit Zitat

dann musst du jede bewegung mal z.b. 60 nehmen und durch die fps teilen

	Clonker	So, Feb 01, 2004 21:06 Antworten mit Zitat
Dann läuft das aber auf schnelleren Computern schneller, als auf langsammeren. Ich dachte da eher an eine feste Zeitangabe wie MILLISECS().
Die exzessive Akkumulation von Fremdwörtern suggeriert pseudointellektuelle Kompetenz. Athlon XP 2800\|Radeon 9600 Pro\|512MB DDR RAM\|240GB Festplatte

Clonker

So, Feb 01, 2004 21:06
Antworten mit Zitat

Dann läuft das aber auf schnelleren Computern schneller, als auf langsammeren.
Ich dachte da eher an eine feste Zeitangabe wie MILLISECS().

Die exzessive Akkumulation von Fremdwörtern suggeriert pseudointellektuelle Kompetenz.

Athlon XP 2800|Radeon 9600 Pro|512MB DDR RAM|240GB Festplatte

	Rallimen Sieger des 30-EUR-Wettbewerbs	So, Feb 01, 2004 21:20 Antworten mit Zitat
aber was soll das bringen.. ?? das bild was am Moni angezeigt wird muss doch erst erneuert werden wenn sich das Bild geändert hat.. warum dann öfter das gleiche Bild ausgeben, wenn doch nichts passiert ist! besser wäre es die framerate höher zu setzten und bewegungs schritte zu verkleinern obwohl 60 FPS meiner Meinung voll reichen dafür
[BB2D \| BB3D \| BB+]

Rallimen

Sieger des 30-EUR-Wettbewerbs

So, Feb 01, 2004 21:20
Antworten mit Zitat

aber was soll das bringen.. ??

das bild was am Moni angezeigt wird muss doch erst erneuert werden wenn sich das Bild geändert hat..
warum dann öfter das gleiche Bild ausgeben, wenn doch nichts passiert ist!
besser wäre es die framerate höher zu setzten und bewegungs schritte zu verkleinern
obwohl 60 FPS meiner Meinung voll reichen dafür

[BB2D | BB3D | BB+]

	Clonker	So, Feb 01, 2004 21:33 Antworten mit Zitat
Ok, ihr habt mich übereugt. Würde den Computer nur unnötig auslasten. Ich dachte nur das dadurch eventuell kleine Rukler verschwinden.
Die exzessive Akkumulation von Fremdwörtern suggeriert pseudointellektuelle Kompetenz. Athlon XP 2800\|Radeon 9600 Pro\|512MB DDR RAM\|240GB Festplatte

Clonker

So, Feb 01, 2004 21:33
Antworten mit Zitat

Ok, ihr habt mich übereugt. Würde den Computer nur unnötig auslasten.
Ich dachte nur das dadurch eventuell kleine Rukler verschwinden.

Die exzessive Akkumulation von Fremdwörtern suggeriert pseudointellektuelle Kompetenz.

Athlon XP 2800|Radeon 9600 Pro|512MB DDR RAM|240GB Festplatte

	Travis	So, Feb 01, 2004 23:28 Antworten mit Zitat
IonPainter hat Folgendes geschrieben: dann musst du jede bewegung mal z.b. 60 nehmen und durch die fps teilen Diese Methode hat aber einen Haken. Wenn man das Spiel programmiert und selbst mit 60 Fps arbeitet, stellt man auch die Speed-Variable für die Bewegung dementsprechend ein. Bei 60 Fps reicht dann z.B. ein Faktor von 5 um die gewünschte Geschwindigkeit zu erreichen. Spielt man jetzt auf langsameren Systemen, die z.B. nur 20 FPS schafften (also ein Drittel), wird der Faktor von 5 auf 15 Erhöht. Also macht das Bewegliche Objekt jetzt größere "Sprünge". So kann es passieren, daß kleinere Objekte einfach übersprungen werden und die Kollisionsabfragen nicht mehr funktionieren, weil die Objekte überhaupt nicht mehr aufeinander treffen. Da würde ich dann doch dazu raten eine feste FrameRate einzustellen, bei der die Bewegungsschritte so klein wie möglich (oder nötig) gehalten werden. Langsamere Systeme haben dann eben Pech gehabt und es läuft entsprechend langsamer.
www.funforge.org Ich hasse WASD-Steuerung. Man kann alles sagen, man muss es nur vernünftig begründen können.

Travis

So, Feb 01, 2004 23:28
Antworten mit Zitat

IonPainter hat Folgendes geschrieben:

dann musst du jede bewegung mal z.b. 60 nehmen und durch die fps teilen

Diese Methode hat aber einen Haken. Wenn man das Spiel programmiert und selbst mit 60 Fps arbeitet, stellt man auch die Speed-Variable für die Bewegung dementsprechend ein.

Bei 60 Fps reicht dann z.B. ein Faktor von 5 um die gewünschte Geschwindigkeit zu erreichen. Spielt man jetzt auf langsameren Systemen, die z.B. nur 20 FPS schafften (also ein Drittel), wird der Faktor von 5 auf 15 Erhöht. Also macht das Bewegliche Objekt jetzt größere "Sprünge". So kann es passieren, daß kleinere Objekte einfach übersprungen werden und die Kollisionsabfragen nicht mehr funktionieren, weil die Objekte überhaupt nicht mehr aufeinander treffen.

Da würde ich dann doch dazu raten eine feste FrameRate einzustellen, bei der die Bewegungsschritte so klein wie möglich (oder nötig) gehalten werden. Langsamere Systeme haben dann eben Pech gehabt und es läuft entsprechend langsamer.

www.funforge.org

Ich hasse WASD-Steuerung.

Man kann alles sagen, man muss es nur vernünftig begründen können.

	walski Ehemaliger Admin	Mo, Feb 02, 2004 0:02 Antworten mit Zitat
1. FrameBremsen sollten wohl für alle kleineren Geschichten langen. 2. Wer es professioneller mag sollte sich dafür begeistern: - Berechnungen SO schnell es geht durchführen. - Jeder "zeitabhängige" Berechnung (dazu gehören vor allem Bewegungen, aber eben auch zufalls "Erschaffungen" von Objekten etc) mit einem Faktor multiplizieren der auf den aktuellen FPS oder der Zeit die für einen "Schleifendurchgang" benötigt wird (bessere Variante!) beruht. - Wer es jetzt noch ganz toll machen will, der lässt die Zeichen Routine trotzdem nur 100 mal pro Sekunde ans Werk um so mehr Zeit für Berechnungen zu haben Denn was nützen einem 100000000 FPS? Wenn 100 FPS langen völlig und MEHR Berechnungs-Durchgänge = MEHR Genauigkeit und MEHR Geschmeidigkeit! Ich werde die Tage mal eine Demo dazu ins CodeArchive stellen. Das ganze dreht sich dann zwar eher um ein anderes Problem, aber diese Art von Limiter habe ich gestern mit freundlicher Hilfe von DC entwickelt und er funzt fantastisch. Deshalb wird er in meinen nächsten "CodeBeitrag" einfließen. walski
buh!

walski

Ehemaliger Admin

Mo, Feb 02, 2004 0:02
Antworten mit Zitat

1. FrameBremsen sollten wohl für alle kleineren Geschichten langen.
2. Wer es professioneller mag sollte sich dafür begeistern:
- Berechnungen SO schnell es geht durchführen.
- Jeder "zeitabhängige" Berechnung (dazu gehören vor allem Bewegungen, aber eben auch zufalls "Erschaffungen" von Objekten etc) mit einem Faktor multiplizieren der auf den aktuellen FPS oder der Zeit die für einen "Schleifendurchgang" benötigt wird (bessere Variante!) beruht.
- Wer es jetzt noch ganz toll machen will, der lässt die Zeichen Routine trotzdem nur 100 mal pro Sekunde ans Werk um so mehr Zeit für Berechnungen zu haben Wink

Denn was nützen einem 100000000 FPS? Wenn 100 FPS langen völlig und MEHR Berechnungs-Durchgänge = MEHR Genauigkeit und MEHR Geschmeidigkeit!

Ich werde die Tage mal eine Demo dazu ins CodeArchive stellen.
Das ganze dreht sich dann zwar eher um ein anderes Problem, aber diese Art von Limiter habe ich gestern mit freundlicher Hilfe von DC entwickelt und er funzt fantastisch. Deshalb wird er in meinen nächsten "CodeBeitrag" einfließen.

walski

buh!

	adba	Mo, Feb 02, 2004 0:20 Antworten mit Zitat
Um deine Anfangsfrage prefekt zu lösen bräuchte man threats, also zwei paralel laufende prozesse aber leider unterstützt das blitzbasic nicht also musst du das irgendwie selber aufteilen. meistens reicht es aber einfach ein while wend zu haben und darin in functionen verpack die einzelnen sachen durchzugehen: Code: [AUSKLAPPEN] [EINKLAPPEN] frameTimer=CREATETIMER(60) ;für konstant 60fps oder weniger :-) while not keyhit(1) WAITTIMER (frameTimer) ; der wartet so lange wie nötig für 60 fps KeyTest() ; Macht die ganzen tastaturabfragen MoveCam() ; berechnet die ganze camerafürhung updateMove() ; berechnet zb eine bewegung updateworld() renderworld() calcfps() ; Berechnet un stellt die Frames per secon dar. flip wend end

adba

Mo, Feb 02, 2004 0:20
Antworten mit Zitat

Um deine Anfangsfrage prefekt zu lösen bräuchte man threats, also zwei paralel laufende prozesse aber leider unterstützt das blitzbasic nicht also musst du das irgendwie selber aufteilen. meistens reicht es aber einfach ein while wend zu haben und darin in functionen verpack die einzelnen sachen durchzugehen:

Code: [AUSKLAPPEN]

frameTimer=CREATETIMER(60) ;für konstant 60fps oder weniger :-)
while not keyhit(1)
WAITTIMER (frameTimer) ; der wartet so lange wie nötig für 60 fps
KeyTest() ; Macht die ganzen tastaturabfragen
MoveCam() ; berechnet die ganze camerafürhung
updateMove() ; berechnet zb eine bewegung
updateworld()
renderworld()
calcfps() ; Berechnet un stellt die Frames per secon dar.
flip
wend
end

Übersicht

BlitzBasic

Allgemein

Nach Oben

BlitzBasic Portal

Teilung der Hauptschleife in zwei Teile

Betreff: Teilung der Hauptschleife in zwei Teile