OsX GameDev First Steps Entwicklertagebuch

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Aufgrund der Corona-Krise: Die Veröffentlichung von Stellenangeboten und -gesuchen ist bis 31.12.2020 kostenfrei. Das beinhaltet auch Angebote und Gesuche von und für Freischaffende und Selbstständige.

  • OsX GameDev First Steps Entwicklertagebuch

    Hi,

    Ich hoffe sowas ist hier gewünscht, falls nicht entschuldige ich mich schonmal im Vorraus.

    Ich habe über die letzten 1,5 Monate begonnen mich der Spieleentwicklung unter Cocoa und Mac OsX zu widmen und schreibe periodisch im Stile eines Tagebuchs/Tutorials über einzelne Themen aus diesem Gebiet.

    Das ganze ist ein simples, aufeinander aufbauendes Tutorial, das vielleicht für den einen oder anderen Cocoa Anfänger ganz interessant sein könnte.

    Bisher existieren 3 Teile:


    Gruß,
    Herr Rabe
  • Grundsätzlich find ich das ne gute Sache, was mir aber aufgefallen ist (hab nur den ersten Teil kurz überflogen)

    Legacy-Code, für den Einstieg aber sicherlich ok um die Basics zu lernen


    glEnable(GL_DEPTH_TEST);

    glClearColor(0, 0, 0, 0);
    gehören nicht in den Render-Code sondern in die Initialisierungs-Methode, da die nur einmal gesetzt werden müssen

    Der Würfel macht ganz seltsame Bewegungen, ich denke mal das liegt an deiner Zeitberechnung

    [self setNeedsDisplay:YES];

    kann man sich sparen.


    Ansonsten subba
  • Hi Wolf,

    Was die Initialisierung vs. Rendercode angeht, hast du mit

    wolf_10de schrieb:

    glEnable(GL_DEPTH_TEST);

    wohl recht.

    Was den clear color Aufruf angeht, stimmt das nicht so ganz, denn wenn ich den nicht jeden Frame erneut ausführe, wird der neue Frame einfach über den alten gezeichnet, was dann ziemlich stränge aussieht.


    wolf_10de schrieb:

    Der Würfel macht ganz seltsame Bewegungen, ich denke mal das liegt an deiner Zeitberechnung

    Echt? Bei mir eigentlich nicht. Hm... Er rotiert eben um alle drei Achsen gleichzeitig. Was meinst du denn mit 'seltsamen Bewegungen'?

    wolf_10de schrieb:


    [self setNeedsDisplay:YES];
    kann man sich sparen.

    Hatte ich auch schon drüber nachgedacht. Ich muß den Framerefresh wohl nochmal überarbeiten und wie DisplayLink oder Timer realisieren. Momentan ist diese Zeile das was Cocoa dazu anregt, drawRect immer wieder aufzurufen. Allerdings bekomme ich FPS Messungen jenseits von Gut und Böse. Sprich zwischen 2 und 3 millis delta_t, was umgerechnet 500 fps bzw. 333fps. entspricht.
    Oder anderst ausgedrückt: Mit lediglich diesem Aufruf ist der drawRect Aufruf nicht mit der Refresh-Rate des Bildschirms synchronisiert, da ich ansonsten auf maximal 60 fps kommen müßte.

    Hab allerdings bisher noch keine leicht verständliche Erklärung zu dem ganzen DisplayLink Geraffel gefunden.

    wolf_10de schrieb:

    Ansonsten subba

    Thx. :)


    Gruß,
    Herr Rabe
  • hr_rabe schrieb:

    Was den clear color Aufruf angeht, stimmt das nicht so ganz, denn wenn ich den nicht jeden Frame erneut ausführe, wird der neue Frame einfach über den alten gezeichnet, was dann ziemlich stränge aussieht.
    clearColor musst Du nur einmal setzten, den Bildschirm löschen natürlich in jedem frame (glClear)
    Wenn Du den Bildaufbau mit der Framerte sync's (hast Du ja so eingestellt) kannst Du niemals 500/333 FPS haben, maximal 60 (oder je nachdem was der Bildschirm und die GraKa hergibt).
  • wolf_10de schrieb:


    Wenn Du den Bildaufbau mit der Framerte sync's (hast Du ja so eingestellt) kannst Du niemals 500/333 FPS haben, maximal 60 (oder je nachdem was der Bildschirm und die GraKa hergibt).


    I know.
    Deshalb ist es ja ziemlich strange, daß ich tatsächlich lediglich eine delta_t von 2 oder 3 millis messe.
    Ich nehme aber an, daß das mit der Tatsache zusammenhängt, daß ich keinenTimer oder DisplayLink verwende, sondern lediglich durch den 'needsRedisplay' Aufruf ein Neuzeichnen anrege.
  • hr_rabe schrieb:

    wolf_10de schrieb:


    Wenn Du den Bildaufbau mit der Framerte sync's (hast Du ja so eingestellt) kannst Du niemals 500/333 FPS haben, maximal 60 (oder je nachdem was der Bildschirm und die GraKa hergibt).


    I know.
    Deshalb ist es ja ziemlich strange, daß ich tatsächlich lediglich eine delta_t von 2 oder 3 millis messe.
    Ich nehme aber an, daß das mit der Tatsache zusammenhängt, daß ich keinenTimer oder DisplayLink verwende, sondern lediglich durch den 'needsRedisplay' Aufruf ein Neuzeichnen anrege.
    needDisplay wird vom System selbst geregelt, weshalb es nicht der richtige Weg ist, nimm nen DisplayLink, das ist die Methode die Apple inzwischen vorschlägt.
  • Hallo,

    bei den Sourcen fehlen die Sounddateien. Das Beispiel hängt sich bei mir auf, keine Tastatur, Mouse-Events.
    Das compilierte Beispiel funktioniert allerdings. Was mir auffällt ist, das es mit anscheinend 500 FPS läuft, obwohl du den vertikalen Swap eingeschaltet hast, kann also eigentlich nicht sein.
    Die Bewegung des kleinen Würfels ist manchmal sehr abgehackt, liegt wohl an der Berechnung von Timedelta, da muss ein Fehler drin sein (genau hab ich mir es nicht angeschaut), aber auch diese smal gute Arbeit!
  • Shit, du hast recht.

    Irgendwie dachte ich, daß Xcode die Sound-Dateien direkt ins Projektverzeichnis kopiert, wenn ich die an das Projekt anfüge. Werde das heute Abend mal fixen.

    Wg. der syncs: Ja, ich glaube das liegt weniger an der time-delta Berechnung, als daran, daß ich es immer noch nicht geschafft habe den DisplayLink einzubauen. Kommt noch.
  • Ich habe gerade eine IM mit essentiell folgendem Inhalt bekommen:
    Ich habe grundlegende Kenntnisse von Objective C. Will jetzt in Richtung Spieleentwicklung gehen und habe nicht wirklich eine Idee wie ich am besten mit einem Spiel starte.

    Kann ich dien Tagebuch welches du führst als eine Art Step by Step Erklärung sehen oder ist dies nicht dein Anliegen?


    Da die Antwort möglicherweise auch allgemein von Interesse ist, beantworte ich das mal hier im Thread:

    Kommt drauf an, was du unter einem 'Step by Step' verstehst. Wenn es dir darum geht Schritt für Schritt einige Grundlagen und Basis-Tool zu lernen, die dir in deiner späteren Spiele-Entwicklung helfen sollen, dann JA. Genau so war das gedacht.

    Wenn du allerdings hoffst dieses Tutorial sei eine Art 'Kochrezept' zur Entwicklung von Spielen, muß ich dich leider enttäuschen. Ich versuche lediglich Grundlagen zu erarbeiten. Das Konzept einer Spiele-Architektur ist nochmal eine ganz eigene Sache für sich, die ich im Laufe dieses Tutorials nicht anschneiden werde.
  • hr_rabe schrieb:

    Ich habe gerade eine IM mit essentiell folgendem Inhalt bekommen:
    Ich habe grundlegende Kenntnisse von Objective C. Will jetzt in Richtung Spieleentwicklung gehen und habe nicht wirklich eine Idee wie ich am besten mit einem Spiel starte.

    Kann ich dien Tagebuch welches du führst als eine Art Step by Step Erklärung sehen oder ist dies nicht dein Anliegen?


    Da die Antwort möglicherweise auch allgemein von Interesse ist, beantworte ich das mal hier im Thread:

    Kommt drauf an, was du unter einem 'Step by Step' verstehst. Wenn es dir darum geht Schritt für Schritt einige Grundlagen und Basis-Tool zu lernen, die dir in deiner späteren Spiele-Entwicklung helfen sollen, dann JA. Genau so war das gedacht.

    Wenn du allerdings hoffst dieses Tutorial sei eine Art 'Kochrezept' zur Entwicklung von Spielen, muß ich dich leider enttäuschen. Ich versuche lediglich Grundlagen zu erarbeiten. Das Konzept einer Spiele-Architektur ist nochmal eine ganz eigene Sache für sich, die ich im Laufe dieses Tutorials nicht anschneiden werde.
    Die hab ich auch bekommen, muss man nicht wirklich ernst nehmen.