ehe jemand Angst bekommt - Open Party existiert weiter und wird auch weiter entwickelt, aber ich brauchte Abwechslung.
Der Grund
Wie viele von euch wissen oder wissen könnten, besitze ich einen GP2X. Das ist eine freie Spielekonsole. Die groben Eckdaten (vor allem die, die für mich relevant sind ) sind
ein 200 Mhz ARM Prozessor (bis min 285 Mhz übertaktbar)
ein winziger NAND mit einem 2.4er Linux
Support für SDL, aber nicht z.B. für OpenGL (es existiert eine Art Koprozessor, den jedoch zu nutzen ist recht kompliziert, vor allem für Grafik)
320x240 Pixel Auflösung bei 16 Bit Farben
Die klassichen Konsoleneingabegeräte: D-Pad, 4 Actionbuttons, Start+Select, Schulterbuttons, Volume-Buttons (die man aber beliebig belegen kann)
SD-Karten Reader (die NAND ist mit dem OS gut beschäftigt)
Von der Größe und Ausrichtung perfekt für Open Party, aber das verlangt (man mag es nicht glauben) doch zu viel von der Grafik. Worauf ich hinaus will: Durch dieses Gerät bin ich in verschiedenen Chats und Foren und bekam von einem Wettbewerb für die Pandora mit. Die Pandora ist eine alte Idee, die nur sehr langsam realisiert wird, weil die Produktion mit einigen Problemen verbunden ist. Grob ist es eine noch freiere Spielekonsole, da sie von keiner großen Firma, sondern von Idealisten produziert wird. Ihre Eckdaten sind:
ein 600 Mhz (Standardtakt) ARM Prozessor (66 Mhz bis 1,1 Ghz sind der freie Taktungsspielraum)
512 MB NAND mit einem 2.6er Linux
Support für SDL und z.B. für OpenGL ES (mit Hardwarebeschleunigung)
800x480 Pixel Auflösung bei 16 Bit Farben und wahnwitzigen 4,quetsch Zoll Bildschirmdiagonale
Die klassichen Konsoleneingabegeräte, aber auch eine Tastatur und ein Bildschirm, wo man drauf rumklicken kann.
Die Aufgabe des Wettbewerbs war nun einen Plattformer zu schreiben und da es mir da schon länger in den Fingern juckt, bin ich das angegangen. Der Wettbewerb lief dort jedoch doch schon einen von zwei Monaten, weshalb mir nur noch die halbe Zeit übrig blieb. Nun ist bestimmt der eine oder andere verwirrt: Ich besitze einen GP2X und schreibe ein Spiel für eine Pandora (die mir btw. im Moment viel zu teuer ist). Ich nutze meinen GP2X erst seit letzter Zeit wieder vermehrt, stehe damit jedoch leider recht alleine da. Es gibt im Moment neben dem GP2X und der Pandora noch den WIZ, den Dingoo und den Caanoo. Alles mehr oder minder freie Spielekonsolen mit Linux als Kern. Um nun mit meinen kleinen Spieleideen trotzdem noch an die/den Openhandheldnerd(in) zu kommen, programmiere ich deshalb dank SDL sehr plattformunabhängig und kann es für diese 5 Systeme + PC kompilieren.
Umsetzung der Plattformunabhängigkeit
Da bis auf einen PC-Windows-Build alle Systeme mehr oder minder normale Linuxe verschiedener Alter sind, ist eine Portierung kompiliertechnisch fast zu einfach. Die meisten Toolchaininstallationen bestehen daraus ein tar.gz-file nach /opt zu extrahieren. Meine (sehr dreckige ) Makefile muss dann nur minimal angepasst werden und schon unterstütze ich ein neues System. Mehr Probleme macht die konkrete Umsetzung von SDL auf den Plattformen. Viele SDL-Umsetzungen sind teils sehr schlampig geschrieben und die Eingabegeräte und vor allem deren Nummern sind natürlich nicht überall gleich. Ich muss also im Kern meiner "Engine" (dazu später mehr) ein bisschen mit #ifdef's (Deppenapostroph zur besseren Kenntlichmachung des Statements #ifdef) hantieren, bin dafür außerhalb dieser einen Datei dann vor rumgepräprozessoredirektivitieren gefeit.
Die meisten Handheldsysteme (alle außer Pandora), die ich beliefere haben eine Auflösung von 320x240, was eine Portierung einfacher macht. Jedoch ist mir die Pandora als modernster Handheld aller sehr wichtig, deshalb nutze ich den guten alten OpenGL-like-Weg: Ich gebe alle Position relativ an und nicht auf Pixelpositionen bezogen.
Außerdem habe ich mir gedacht, dass man bei 200 000 000 Rechenschritte die Sekunde und nur 76 800 Pixeln bestimmt auch ein bisschen Pseudo-3D hinbekommt. Nach einigen Versuchen ging das sogar sehr gut. Ich habe eine Engine geschrieben, die ein paar Ähnlichkeiten mit OpenGL hat. Die grobe Renderpipeline ist hier geklaut. Es gibt eine Projektionsmatrix, eine Modellviewmatrix und die Mathematik dahinter ist natürlich auch gleich.
Ein sehr wichtiger Unterschied ist, dass der GP2X als schwächstes Glied in der Kette keine FPU besitzt. Deshalb ist meine gesamte Engine mit Festkommazahlen realisiert worden. Dadurch sind meine Berechnungen sehr fix auf dem GP2X. sin und cos lese ich aus vorberechneten Tabellen aus und eine Wurzel ziehe ich in nur 7 Takten mit Code, den mir jemand gegeben hat und der wohl auf irgendeinen Mathematiker zurückgeht - er funktioniert zuverlässig. Theoretisch habe ich sogar ARM-Assembler-Divisionscode bekommen, den habe ich bisher aber noch nicht implementiert.
Außerdem nutze ich keinen z-Buffer. Ich sortiere natürlich im Abstand zum Betrachter die Primitive (die kommen vorher in einen Buffer bis zum Flush), aber wenn Objekte sehr nah beeinander sind, kann es zu Unstimmigkeiten kommen. Die Methode ist ungenau und verursacht unnötigen Zeichenaufwand, ist aber schneller als ein z-Buffer, wo ich den z-Wert eines jeden Pixels interpolieren, vergleichen und gegebenenfalls speichern muss. Denn im Moment bin ich in der Lage durch ARM-Assembler die Zeichenfunktion am GP2X und allen anderen ARM-Geräten (also alle außer dem Dingoo, der hat so ein MIPS-Ding) massiv zu beschleunigen. Im best case zeichne ich so 22 Pixel in nur wenigen Takten. Im Average Case bin ich mindestens doppelt so schnell wie mit dem trivialen for-Schleifen-Weg ohne Optimierung. Wie gesagt, besitzt der Dingoo keine ARM-CPU, dafür jedoch die doppelte Rechenleistung des GP2X + einen neuren prozessor, der sicherlich besser optimiert, wodurch sich das ausgleicht. Nur am PC werden hohe Auflösungen langsam, da der Softwarerenderer hier den trivialen Weg nutzt. Dazu auch später mehr.
Das Spiel
In einem Monat einen kleinen Software-Renderer + ein Spiel, dass diesen nutzt und nicht nur eine Demo ist (Wettbewerbsregeln), zu schreiben war mir nur möglich, weil ich Semesterferien hatte und so viel Zeit zum Coden hatte. DIe Spielidee ist schnell umrissen. Man ist ein Schneemann in einem klassischem Jump and Run. Man beginnt als Kopf und sammelt Schneeflocken, um größer zu werden. Jeder Sprung, Schuss und das Berühren von Gegner(geschosse)n kostet einen Größe. Zumindest die ersten beiden Dinge sind jedoch erforderlich um ein Level zu meistern, da man eine gewisse Anzahl an Gegner elliminieren muss. Es ist also ein Spiel, wo man a) töten muss und b) mit Munition und Health haushalten - vor allem, da sie identisch sind. Als kleines Special gibt es die Möglichkeit die unterste der drei Schneemankugeln abzuwerfen, welche dann Gegner tötet und am Ende unter Freisetzung von Schneebällen explodiert. Außerdem kann man einen Besen einsammeln, mit welchem man zwar nahe an die Gegner ran muss (Verletzungsgefahr), aber ohne Verlust von Masse Schaden zufügen kann. Ich denke, es ist ein guter Zeitpunkt, das Spiel hier einmal vorzuführen. Das aktuelle Video konnte ich bisher nciht bei YT hochladen - fragt nicht, YT scheint mcih zu hassen, deshalb hier eine 80MB-ogv-Datei: http://ziz.delphigl.com/vids/snowman.ogv In meinem YT-Channel finden sich jedoch auch 4 Videos, die gut meinen Fortschritt bei der Entwicklung dokumentieren. Die Musik ist (wie so oft) von incompetech.com.
Der Wettbewerb
Im Verlauf des Wettbewerbs wurde gesammelt und ein Topf von ca. 250£ angehäuft. 50% gehen an den Ersten, 30% an den Zweiten und 20% an den Dritten. Ich wurde dritter. Das Spiel ist also schon spielbar, aber ich habe noch soooooo viele Ideen für das Spiel, wird also demnächst noch mehr Level und Features geben.
Ausblick
Neben neuen Leveln und ein paar Kleinigkeiten, will ich vor allem den PC-Build erweitern. Wenn ihr das Spiel testet und es auf einem langsameren System spielt, wird auffallen, dass es ab einer gewissen Auflösung stockt. Die Berechnungen für die Darstellung bleiben stets konstant ob der immer gleichen Anzahl an Primitiven. Die Füllrate geht jedoch in die Höhe und da ich die bisher nicht optimiere... Ich habe vor hier OpenGL zu nutzen. Das wird recht trivial machbar sein, muss jedoch einfach mal getan werden.
Download
Wie gesagt, ist das Spiel fertig und ausprobierbar. Der Window-Build ist nicht von mir, aber aktuell. Ich würde es ja cool finden, wenn jemand von euch eine der Konsolen hat und es damit testen könnte.
_________________ Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut. Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’. Und du schaust mich an und fragst ob ich das kann. Und ich denk, ich werd' mich ändern irgendwann. _________________Farin Urlaub - Bewegungslos
Mitglieder in diesem Forum: Google [Bot] und 4 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.