Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

1

29.06.2007, 16:53

ProgrammDesign Fragen

Hi

ich melde mich auch mal wieder :) nach längerer abstinenz im bereich spieleprogrammierung gehts mal wieder frisch ans werk. ich hab mir also gleich mal ein mmn recht gutes buch aus unserer örtlichen bücherei ausgeliehen. das ganze trägt den namen Computerspiele - Design und Programmierung.

Das hab ich mittlerweile durch, die interessanten stellen sogar mehrmals.

Allerdings hab ich zu einigen sachen fragen, wie ihr das realisieren würdet. (Es geht um ein 3D Projekt)

1. Die Spielgeschwindigkeit: Im Buch werden 2 wege vorgestellt die spielgeschwindigkeit auf allen rechnern konstant zuhalten.
einerseits das normale multiplizieren mit der Zeit für den letzen Frame. Das kannte ich bisher auch. Dann wird noch ein sogenanntes Frame-Skipping vorgeschlagen. Dabei durchläuft der Mainloop eine konstante Anzahl an durchlaufen pro Sekunde (Im Buch wird von etwa 30 gesprochen) aber nicht jedesmal erfolgt eine grafische ausgabe. soll man das jetzt so verstehen, das ein grafische Ausgabe sooft erfolgt wie es der rechner leisten kann? also evlt auch häufiger als 30mal pro Sekunde?
Welches Verfahren würdet ihr mir empfehlen?

2. Es wird im Buch gesagt das 90% der neueren Spiele eventbasiert sind. dann wird schön auf das windowsmessage system eingegangen und was zur windowsfenster programmierung gesagt, allerdings hilft mir das für das verstehen eines eventbasierten Spiels nicht wirklcih weiter. Ist das etwa so, das in der Hauptschleife dann eine switch anweisung steht und die Module praktisch nur noch Messages verschicken um bestimmte Prozeduren aufzurufen? (z.B. das Input da is tun ddas er jetzt verarbeitet werden muss, oder das die Physik berechnet werden muss).

Jetzt eine Sache unabhängig von diesem Buch:

3. Würdet ihr eure Grundengine in eine eigene .lib packen?
also das man nacher in der eigentlichen exe nurnoch relativ wenig code hat, oder würdet ihr alles zu einer .exe kompilen lassen. das mache ich im moment noch, aber ich könnte mir vorstellen das das demnächst nicht mehr so toll seien wird.

Das waren erstmal meine Fragen. Ich würde mich auch über Teilantworten freuen.

MfG
Eldarion

rewb0rn

Supermoderator

Beiträge: 2 773

Wohnort: Berlin

Beruf: Indie Game Dev

  • Private Nachricht senden

2

29.06.2007, 18:40

zu 1) Also ich hab von dem 2. noch nix gehört, ich mache es so, dass am Ende eines jeden Frames solange gewartet wird, bis die Zielzeit für den Frame abgelaufen ist. So kriegt man dann eine konstante Anzahl Frames pro Sekunde.

zu 2) Also unter "event-basiert" kann man ja viel verstehen.. input und physik müssen auf jeden fall immer abgefragt bzw berechnet werden. ich habe jedenfalls keien große switch anweisung in meiner hauptfunktion ;)

zu 3) Ich mache das so, hat den Vorteil, dass man die Engine dann ohne Redundanz in Spiel und Mapeditor verwenden kann.

grek40

Alter Hase

Beiträge: 1 491

Wohnort: Dresden

  • Private Nachricht senden

3

29.06.2007, 18:49

Zu 3.: deine Frage ist glaub ich eher, ob man die Engine in eine DLL packen würde... eine statische Lib würde bedeuten, dass man den Code letztendlich mit in die Exe packt.
Was ich an Dlls problematisch finde ist halt, dass man arge Probleme bekommt, sobald man an der Schnittstelle irgendwelche Templates hat... das wird echt eklig. Wenn man allerdings Templates nur Intern oder garnicht verwendet spricht nichts gegen eine Dll

4

29.06.2007, 19:06

schonmal thx.

@rewb0rn: was machst du wenn der rechner nicht die von dir erdachte framerate schafft? also wenn du z.b. auf 25frames in der sekunde runterbremst, der rechner aber nur 15 schafft, dann ist das ganze ja wieder unterschiedlich.
zu dem eventbasierten, das ganze wurde wie gesagt mit dem winapi messageloop und den interupts verglichen. ich hab ja auch gefragt weil ich nicht weiß was das buch damit genau meint.

ich werde dann meine engine in eine dll packen.

Black-Panther

Alter Hase

Beiträge: 1 443

Wohnort: Innsbruck

  • Private Nachricht senden

5

29.06.2007, 19:33

1) Ich kenne nur zwei Arten: Time-based-rendering und Frame-based-rendering.
Beide multiplizieren alle Änderungen mit der Zeit, jedoch wird bei letzteren versucht genau diese Zeit konstant zu halten. Wenns nun drunter gehen sollte, dann wird halt mit einer längeren Zeit multipliziert...

2) Eventbasiert... Im prinzip implementierst du dein eigenes Nachrichtensystem. Alles so zu machen, hat den enormen Vorteil, dass du alles ziemlich übersichtlich gestalten kannst einerseits, und andererseits, ist das ganze Spiel dann recht einfach multiplayerausbaubar!
Für nähere Informationen zu so einem MessageSystem schau mal in die Gems4, da wird eines vorgestellt

@rewb0rn
Welche Funktion benutzt du fürs warten? (frame-based-rendering)
stillalive studios
Drone Swarm (32.000 Dronen gleichzeitig steuern!)
facebook, twitter

rewb0rn

Supermoderator

Beiträge: 2 773

Wohnort: Berlin

Beruf: Indie Game Dev

  • Private Nachricht senden

6

29.06.2007, 19:53

Sleep(), die ungenauigkeiten gleiche ich dadurch aus, dass ich einfach immer eine fixe Zeit in meinen Wert TimePassed schreibe, dadurch gibt es aber nicht immer exakt die gewünschte Anzahl an Frames pro Sekunde, das Spiel hat also minimale Geschwindigkeitsänderungen, ich weiß noch nicht genau wie ich das netzwerkfähig mache.. Hatte schonmal drüber nachgedacht, sleep nur solange zu verwenden, solange die restzeit über einer bestimmten grenze ist und ab dann halt einfach eine while(timepassed < frametime) timepassed = timer.getTimer();

das müsste dann ziemlich genau sein, wenn auch natürlich cpu-lastig.. habs aber noch nicht implementiert oder getestet

@eldarion: wegen meiner oben erwähnten technik läuft das spiel dann in zeitlupe.. ist an sich aber auch nicht schlimmer als wenn ich mit der echten zeit arbeite, denn dann verhält sich die phyisk total anders (wenn die framezeiten auf einmal größer sind)

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

7

29.06.2007, 20:48

Zum Thema Static Lib oder DLL:
Ich persönlich komme mit der Static Lib besser zurecht und für kleinere Sachen ist das meine bevorzugte Lösung. Bei einer großen Engine o.ä. denke ich aber, dass eine DLL sich durchaus lohnt. Die Frage, die du dir stellen musst: Wie umfangreich wird das ganze und lohnt sich da eine DLL?

Zum Thema FrameBasedRendering:
Was spricht gegen folgende Lösung? Gut Sleep ist nicht wirklich genau und die Timeraufrufe vielleicht nicht ideal, aber eigentlich sollte das doch eine ausreichende Lösung sein:

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
    DWORD LastFrame = 0;
    while(true)
    {
        DWORD start = timeGetTime();
[...]

        //Ende: Die Restzeit bei Bedarf absitzen und DeltaT errechnen

        {
            sektor->TimeNeeded = timeGetTime() - start;

            if(sektor->fire->FrameTimePerSektor > sektor->TimeNeeded)
                Sleep(sektor->fire->FrameTimePerSektor - sektor->TimeNeeded);

            LastFrame = timeGetTime() - start;
        }
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

LagRange

Frischling

Beiträge: 26

Wohnort: dzt. Aalborg, DK

Beruf: Student

  • Private Nachricht senden

8

29.06.2007, 20:56

Ich bevorzuge es keine sleep Anweisungen in meine Hauptschleifen einzubauen, sondern lass die Grafikausgabe lieber mit maximaler Geschwindigkeit laufen (jeder freut sich über hohe FPS-Werte :lol: )
Wenn ein Teil vom Programm (z.B. Physikengine) empfindlich auf variierende Framezeiten reagiert, wird das nicht in jedem Frame aktualisiert sondern in fixen Zeitintervallen.

Pseudocode:

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
unsigned int time, delta, last, delta_phyics;
delta_physics = 0;
last = getTime( );

while( keep_running ) {
  time = getTime( );
  delta = time - last;
  last = time;

  updateGraphics( delta );

  delta_physics += delta;
  if( delta_physics >= 100 )  // Physik alle 100ms updaten

  {
    delta_physics -= 100;
    updatePhyics( 100 );
  }
}
Science is common sense applied to evidence.

rewb0rn

Supermoderator

Beiträge: 2 773

Wohnort: Berlin

Beruf: Indie Game Dev

  • Private Nachricht senden

9

29.06.2007, 22:13

darüber hab ich mir auch schon gedanken gemacht, aber was bringt dir eine hohe fps wenn sich in der physikalischen berechnung nix ändert? das einzige was mir einfällt sind animationen und sprites, aber da merkt doch bei 50 fps keiner einen unterschied zu 100.

LagRange

Frischling

Beiträge: 26

Wohnort: dzt. Aalborg, DK

Beruf: Student

  • Private Nachricht senden

10

29.06.2007, 22:55

Es geht hauptsächlich darum dass aufwändigere Physikinteraktionen die Framerate ganz schön drücken können. Man spart einiges an Rechenzeit wenn man die nicht so oft aufruft.

Ausserdem kann man (in manchen Simulationen) Bewegungen zwischen einzelnen Physikaufrufen interpolieren, was dann auch bei niedrigen Updateraten zu flüssigen Bewegungen führt.
Science is common sense applied to evidence.

Werbeanzeige