PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : VB6 : Problem mit Spiel programmierung


Hyp3r
2006-06-05, 12:55:58
Hy an alle,
ich programmier grade ein paar simple 2d games auf einer directx 7 basis.
nun ist mein problem die ablauf geschwindigkeit des spiels.
beim pc a) zuckt es und ich hab 20 frames, auf pc b) läuft es flüssig und ich hab 50 frame und auf pc c) lüft es vieeel zu schnell mit 70 frames

wie kann ich eine spielgeschwindigkeit festlegen ?!

ich habe alle spiel operationen (bewegungen , schüsse etc..) in einen timer ausgelagert, der wird jede 0 sek ausgeführt.

oder darf ich das so nicht machen?

was mach ich falsch? ^^

vielen dank schonma für antworten

Kampf-Sushi
2006-06-05, 13:13:29
Hyp3r[/POST]']Hy an alle,
ich programmier grade ein paar simple 2d games auf einer directx 7 basis.
nun ist mein problem die ablauf geschwindigkeit des spiels.
beim pc a) zuckt es und ich hab 20 frames, auf pc b) läuft es flüssig und ich hab 50 frame und auf pc c) lüft es vieeel zu schnell mit 70 frames

wie kann ich eine spielgeschwindigkeit festlegen ?!

ich habe alle spiel operationen (bewegungen , schüsse etc..) in einen timer ausgelagert, der wird jede 0 sek ausgeführt.

oder darf ich das so nicht machen?

was mach ich falsch? ^^

vielen dank schonma für antworten
Ne Timer ist ne bloede Idee.

Mach ruhig alles in der Hauptschleife und trenne zwischen 'Rundenbasierten' Vorgaengen (Objekt positionen aktuallisieren z.B.) und Vorgaengen die immer gemacht werden sollen (Bild Rendern z.B.).
Bei den Vorgaengen die nach Runden ablaufen sollen, machst du einfach ne IF Bedingung vor.

Do While playing 'Hauptschleife
tmpZeit = getTickCount()
If playing And tmpZeit >= letzteRunde + rundenDauer Then
'Runden basierende Vorgänge:
If Not spielPause Then
'Positionen aktuallisieren usw
End If
letzteRunde = tmpZeit
End If
'Bild rendern und aehnliches
DoEvents
Loop


So hab ich das damals zumindest gemacht, ich hab das aber ohne DirectX geschrieben.

Hyp3r
2006-06-05, 13:16:43
ah genau, coole sache, danke dir :)

del_4901
2006-06-05, 13:23:02
Die Idee mit dem Timer ist schon sehr gut, wenn der alle 10-20ms anspringt
Wennde dann noch nur aller 20ms zeichnest wirkt das wie ein 50fps Framelock. DIe Sache mit der Hauptschleife ist semioptimal. Ich hab da nur noch ein while(true) wo er schaut ob's was neues gibt und wenn nicht er sich schlafen legt.

Kampf-Sushi
2006-06-05, 13:52:38
AlphaTier[/POST]']Die Idee mit dem Timer ist schon sehr gut, wenn der alle 10-20ms anspringt
Wennde dann noch nur aller 20ms zeichnest wirkt das wie ein 50fps Framelock. DIe Sache mit der Hauptschleife ist semioptimal. Ich hab da nur noch ein while(true) wo er schaut ob's was neues gibt und wenn nicht er sich schlafen legt.
Warum ist das denn semioptimal?
Ich hab eher die Erfahrung gemacht dass der VB eigene Timer viel ungenau als Taktgeber fuer Spiele ist. Genauso wie die Funktion timer... darum ja auch die GetTickCount API.

Bei meinen Ansatz hat man den Vorteil dass Framerate und Spielgeschehen voneinander entkoppelt sind, d.h. der Spielgeschwindigkeit ist es halbwegs egal ob 30fps gerendert werden oder 120.

del_4901
2006-06-05, 14:07:24
Kampf-Sushi[/POST]']Warum ist das denn semioptimal?
Ich hab eher die Erfahrung gemacht dass der VB eigene Timer viel ungenau als Taktgeber fuer Spiele ist. Genauso wie die Funktion timer... darum ja auch die GetTickCount API.

Bei meinen Ansatz hat man den Vorteil dass Framerate und Spielgeschehen voneinander entkoppelt sind, d.h. der Spielgeschwindigkeit ist es halbwegs egal ob 30fps gerendert werden oder 120.

Sone Hauptschleife verbrezelt einfach zuviel CPU Zeit. Ich hab ein schoenes Event system, das schon dafür sogrt das meine Time-Events als erstes durchkommen. Und wenn dabei sogar nen ZeichenEvent "verschluckt" werden muss. Dabei ist die animation genauso Unabhänig von der Framerate. Die Zeit wo sich mein Hauptprozess schlafen legt kann ich dann dafür verwenden andere Unter-Prozesse anzuschmeißen, bzw. weiter laufen zu lassen.

Coda
2006-06-05, 14:31:28
AlphaTier[/POST]']Sone Hauptschleife verbrezelt einfach zuviel CPU Zeit.
Huh? Eigentlich macht man das wirklich so. Du renderst halt so schnell wie geht, CPU-Zeit sparst du normal nur wenn du beim Frame-Anzeigen auf die GPU warten must.

del_4901
2006-06-05, 14:40:27
Coda[/POST]']Huh? Eigentlich macht man das wirklich so. Du renderst halt so schnell wie geht, CPU-Zeit sparst du normal nur wenn du beim Frame-Anzeigen auf die GPU warten must.
Wenn ich jedesmal bei einem Framelock abfrage ob ich denn schon rendern darf ... verbrezel ich allein mit der ständigen wiederkehrenden Abfrage unnötig CPU Zeit. Meine Engine ist z.B auf 50Fps gelockt. In der Zeit wo grad nichts zu tun ist ... sprich kein DrawEvent/TimeEvent abzuarbeiten ist. werden andere Events bearbeitet. Sprich (ist zwar noch nicht eingebaut) in der freien Zeit könnte man die PhysikEngine rocken lassen.

Gast
2006-06-05, 16:10:52
AlphaTier[/POST]']Wenn ich jedesmal bei einem Framelock abfrage ob ich denn schon rendern darf ... verbrezel ich allein mit der ständigen wiederkehrenden Abfrage unnötig CPU Zeit. Meine Engine ist z.B auf 50Fps gelockt. In der Zeit wo grad nichts zu tun ist ... sprich kein DrawEvent/TimeEvent abzuarbeiten ist. werden andere Events bearbeitet. Sprich (ist zwar noch nicht eingebaut) in der freien Zeit könnte man die PhysikEngine rocken lassen.... und wenn dein Spiel dann auf einem Rechner mit einer "unerwartet" schwachen CPU läuft, funktioniert gar nichts mehr. Na super.

-zecki

del_4901
2006-06-05, 17:07:12
Gast[/POST]']... und wenn dein Spiel dann auf einem Rechner mit einer "unerwartet" schwachen CPU läuft, funktioniert gar nichts mehr. Na super.

-zecki
Ach komm, hauptsache du gibst deinen Senf dazu. Das Eventsystem ist schon soweit durchdacht, das es diesen speziellen Fall abfängt.

Trap
2006-06-05, 17:10:40
AlphaTier[/POST]']Ach komm, hauptsache du gibst deinen Senf dazu. Das Eventsystem ist schon soweit durchdacht, das es diesen speziellen Fall abfängt.
Und was macht es dann? Das zu erkennen ist einfach, das zu behandeln ist nicht so einfach...

del_4901
2006-06-05, 17:13:36
Trap[/POST]']Und was macht es dann?

Ich wusste das Diese Frage kommt. Was da genau passiert ist und bleibt mein großes Geheimniss. Aber soviel kann ich veraten, es werden Sachen verworfen.

(Jetzt kommt bestimmt wieder die Antwort ... das dann nichts mehr funtioniert, weil alles verworfen wird ... auch diesen Fall habe ich beachtet)

Gast
2006-06-05, 17:57:54
AlphaTier[/POST]']Ach komm, hauptsache du gibst deinen Senf dazu. Das Eventsystem ist schon soweit durchdacht, das es diesen speziellen Fall abfängt.AlphaTier[/POST]']Ich wusste das Diese Frage kommt. Was da genau passiert ist und bleibt mein großes Geheimniss. Aber soviel kann ich veraten, es werden Sachen verworfen.Das funktioniert nur für Gimmicks. Wenn deine "rockende" Physik nur ein zusätzlicher Effekt sein soll, dann hast du natürlich kein Problem wenn du diesen Effekt weglässt. Es wird aber zwangsläufig Jobs geben die man nicht einfach verwerfen kann ohne den Spielablauf zu verändern.

Und völlig ab davon für wie clever und magisch du dein System hältst, oder wie sehr du dich von mir genervt fühlst: wenn du deine Idee nicht so weit (öffentlich) erklären willst dass da auch ein robustes System draus wird, wird der Threadstarter damit kaum glücklich werden.

-zecki

del_4901
2006-06-05, 18:16:08
Gast[/POST]']Das funktioniert nur für Gimmicks. Wenn deine "rockende" Physik nur ein zusätzlicher Effekt sein soll, dann hast du natürlich kein Problem wenn du diesen Effekt weglässt. Es wird aber zwangsläufig Jobs geben die man nicht einfach verwerfen kann ohne den Spielablauf zu verändern.

Und völlig ab davon für wie clever und magisch du dein System hältst, oder wie sehr du dich von mir genervt fühlst: wenn du deine Idee nicht so weit (öffentlich) erklären willst dass da auch ein robustes System draus wird, wird der Threadstarter damit kaum glücklich werden.

-zecki

Physik dann man Aproximieren, jeh mehr Zeit man hat umso genauer wird der Verlauf. Und ja du hast recht, es gibt Events die man nicht so ohne weiteres verwerfen darf ... da muss man sich dann drauf "einstellen".

Das Problem des Threadstartes ist einfach nur das sein Timer nicht genau genug für eine Solche Aufgabe ist, und deswegen der Event durchkommt, wenn das System es für sinnvoll erachtet ... Bei einem TimedEvent von 0s ist mir klar warum das Verhalten so "undefiniert" ist.

Kinman
2006-06-05, 18:27:45
Also in Relation zu den anderen Dingen verbrezelt man net wirklich viel CPU Zeit ;)

mfg Kinman

del_4901
2006-06-05, 18:30:03
Kinman[/POST]']Also in Relation zu den anderen Dingen verbrezelt man net wirklich viel CPU Zeit ;)

mfg Kinman

Wenn dein Rendervorgang nur 2-10ms in Anspruch nimmt. und die Framerate auf 50fps gelockt ist verbrezelt man immerhin zw. 90% und 50% das ist schon erachtlich!

Hyp3r
2006-06-05, 20:16:40
mhm aber wenn ich eine do .. loop schleife benutze dann läuft das spielt doch jeh nach dem langsamer oder schneller jeh nach rechner power halt.

naja nun hab ich erstma nen anders prob^^ der background muss scrollbar sein ^^

Kinman
2006-06-05, 20:27:14
AlphaTier[/POST]']Wenn dein Rendervorgang nur 2-10ms in Anspruch nimmt. und die Framerate auf 50fps gelockt ist verbrezelt man immerhin zw. 90% und 50% das ist schon erachtlich!

Und bei Dir wird die Zeit genutzt um andere Dinge zu tun, die nicht notwendig, aber z.B. für eine bessere Optik zuständig sind?
D.h. anstatt so schnell als möglich zu rendern (ungebremste Loop), lockst Du das Rendern auf eine bestimmte Geschwindigkeit und nutzt die Zeit um andere Dinge zu nutzen...
Mir persönlich wäre das viel zu gefährlich, da es meiner Meinung nach viele Unterschiede zwischen den einzelnen Bildern anliegen...
Wenn das nicht der Fall ist, dann verbrätst Du die Leistung in nutzlose Dinge.

Oder hab ich das falsch verstanden, Du schickst die CPU schlafen bis der nächste Frame kommt?

mfg Kinman

EDIT:
Hyp3r[/POST]']mhm aber wenn ich eine do .. loop schleife benutze dann läuft das spielt doch jeh nach dem langsamer oder schneller jeh nach rechner power halt.

naja nun hab ich erstma nen anders prob^^ der background muss scrollbar sein ^^

Was ist bei Dir der Background? Machst Du das mit DirectDraw?
http://www.vb-fun.de/cgi-bin/loadframe.pl?ID=vb/directx/directx7.shtml

del_4901
2006-06-05, 20:53:55
Ja Kinman, sicherlich ist sowas gefährlich, aber das macht ja gerade den Reiz aus ^^. große Unterschiede zw. den Frames gibt da nicht, es gibt nur mehr Genauigkeit und oder Effekte ... oder ich bereite irgendwas vor z.B könnte man die Physik für einige Sachen "vorberechnen".
Außerdem ist ein netter Nebeneffekt das man die Klassen unabhänig voneinder bearbeiten und testen kann, da ich alles voneinander entkoppelt habe. (soweit dies möglich ist) Den Performance Mehraufwand nehm ich gern in Kauf um die SW. übersichtlich zu gestallten.

Also da gibt es soviele Sachen wo man die CPU-Zeit-hinstecken kann.

Kinman
2006-06-05, 20:59:35
Stimmt eigentlich. Solange der Weg das Ziel ist, ist sowas interessant und sinnvoll ;)

SimonX
2006-06-05, 22:30:06
Eine Busyloop ist z.B. für Notebooks der Baterietot. Naja, sie werden halt schnell leer gesaugt. Events und Timer ist der einzige Weg hier.

Soo schlimm können Timer-Events unter Windows doch nicht sein. Und genaue 10ms Timer sollten doch in einem Single-User OS definitiv exakt getriggert werden.

del_4901
2006-06-05, 22:31:53
SimonX[/POST]']Eine Busyloop ist z.B. für Notebooks der Baterietot. Naja, sie werden halt schnell leer gesaugt. Events und Timer ist der einzige Weg hier.

Soo schlimm können Timer-Events unter Windows doch nicht sein. Und genaue 10ms Timer sollten doch in einem Single-User OS definitiv exakt getriggert werden.
Meine Rede 10ms liegen absolut im grünen Bereich. (getestet)

Kabelsalat
2006-06-05, 22:46:53
[Klugscheiß]
Stop: Windows -> Multi-User-OS, es sei denn du bist bei Win 98 stehen geblieben.
[/Klugscheiß]

Trap
2006-06-05, 23:07:10
SimonX[/POST]']Eine Busyloop ist z.B. für Notebooks der Baterietot. Naja, sie werden halt schnell leer gesaugt. Events und Timer ist der einzige Weg hier.
Was spricht gegen busy-loop mit sleep(1)?

del_4901
2006-06-05, 23:11:45
Trap[/POST]']Was spricht gegen busy-loop mit sleep(1)?

Das ist Ok, ich machs ähnlich, denn irgendwie muss man das Programm ja in der main "anhalten". Aber das ist dann auch nichtmehr busy Trap.

Trap
2006-06-05, 23:14:28
AlphaTier[/POST]']Aber das ist dann auch nichtmehr busy Trap.
Doch, das ist busy-sleeping :tongue:

del_4901
2006-06-05, 23:27:50
Trap[/POST]']Doch, das ist busy-sleeping :tongue:
Ah das kenn ich noch aus Schulzeiten! :whistle: