Platformer Wettbewerb (Homebrew Competition)

[EvilDragon]

Die Kirby-Reihe gehört definitiv zu den besten Jump'n'Run Serien
Nix mit Mädchen

 

[Granitehead]

Nix mit Mädchen

:huh:

Also du meinst nicht im negativen Sinne von "Mädchenspiel".

 

[Ziz]

Du solltest Kirby wirklich mal testen, Fusion Power. Das ist Jump and Run mäßig echt ne Bildungslücke. ;-)

Ich habe heute übrigens ne Menge geschafft. Das meiste sieht man direkt im Video (neuer Baum, Eismünzen, eine Gummibandkamera, neue Figur, Wolken, die Figur beginnt klein und wird größer mit Eismünzen, Level-zu-Level-Übergang), aber was man nicht sieht, sind die Engineverbesserungen. Konnte nochmal einiges optimieren, dass es auch ja weiter aufm GP2X läuft. ^^

Übrgens wird es später weniger Eismünzen geben. Das ist nur zum Testen. Und man wird sie auch nutzen können. Denn irgendwann muss sich der arme Schneemann ja gegen Gegner wehren. :juhu:
[youtube]kJXRwcThYFs[/youtube]

LG Ziz

 

[relei]

Hi,

Echt cool, wie machst du die Wolken? Hast du dafür selbst was geschrieben oder nutzt du eine Lib (OpenGL)?

Eigentlich gilt die Frage für das gesamte Spiel.

Schönen Gruß
Rebe

 

[Ziz]

Echt cool, wie machst du die Wolken? Hast du dafür selbst was geschrieben oder nutzt du eine Lib (OpenGL)?
Eigentlich gilt die Frage für das gesamte Spiel.

Hab mich schon gewundert, warum du gerade die Wolken hinterfragst, aber den Rest nicht. ^^

Ich habe mir in den letzten 1,5-2 Wochen eine kleine 3D-Engine geschrieben.
Die ist sehr simpel aufgebaut und bei mehr Polygonen würde die auf dem GP2X auch schon zusammenbrechen, aber im Aufwand-Nutzen-Vergleich ist die OK.

Sie basiert wie OpenGL auf Matrizen. Ich nutze aber gar kein OpenGL für mein Projekt. Ich mache im Prinzip alles selbst. Selbst die Polygone. Da greife ich sogar ein bisschen in die ARM-Assembler-Trickkiste. Wobei der Flaschenhals wirklich bei den Matrizen liegt, weshalb ich da probiere zu optimieren, wo es geht.

Ich denke komplett ohne Matrizen oder mit anderen Strukturen wie Quaternions wäre sogar noch mehr rauszuholen, aber Matrizen finde ich einfach schön verständlich.

Da mein GP2X keine Floating Point Unit hat, mache ich alle Berechnungen mit 32 Bit Festkommazahlen. Mit floats käme ich nie so weit wie ich jetzt bin. :juhu:

Im Endeffekt habe ich folgenden Renderpfad:
Ich bearbeite die Modellviewmatrix, wie ich sie brauche.
Dann haue ich Dreicke und Vierecke, die mit dieser und der Projektionsmatrix multipliziert wurden, in einen Puffer. Dabei werden sie aber noch nicht gezeichnet. Ein z-Buffer würde mit meinem ARM-Gefrickel kollidieren und den muss man auch pflegen und so. Deshalb wird einfach nach z-Wert sortiert, NACHDEM alle Polygone angegeben wurden, gezeichnet. Sozusagen direkt vor dem Flip.
Dann wird halt von hinten nach vorne gezeichnet und geflipped.
Für die Optimierung nutze ich Backface Cullung. Bei der Lichtberechnung berechne ich den Winkel zwischen des Betrachtungsvektors und des Normalenvektors (bzw. den Cosinus davon. Aber da mir das reicht, spare ich mir einen teuren acos-Aufruf) und wenn da was positives rauskommt, weiß ich, dass die Fläche in die andere Richtung zeigt. So spare ich mir immerhin 50% Füllrate und ca. 25% Berechnung.

Die Physik ist auch selbst gemacht, aber da darf man gar nicht zu viel verraten. Die ist ziemlich hingefrickelt und so sieht sie auch aus (quelltextmäßig). ^^ Aber sie funktioniert und da bin ich schon sehr froh drüber, dass man nirgends stecken bleibt (scheinbar).

Ich weß, dass es bisel sinnlos ist an der Pandora einen Softwarerenderer zu nutzen, aber soll halt überall laufen. :-D

LG Ziz

 

[Schnatterplatsch]

Interessant
Wenn der Wettbewerb vorbei ist, wirst du dann den src evtl. veroeffentlichen? Wuerde mir das gerne mal ansehen.

 

[Ziz]

Ja klar, sowieso.

Ich stell meine Sachen so gut wie immer unter MPL und (L)GPL .

 

[relei]

Hi Ziz,

Echt super und großen Respekt!!!!

Schönen Gruß
Rene

 

[fusion_power]

Du solltest Kirby wirklich mal testen, Fusion Power. Das ist Jump and Run mäßig echt ne Bildungslücke. ;-)

Ich habe heute übrigens ne Menge geschafft. Das meiste sieht man direkt im Video (neuer Baum, Eismünzen, eine Gummibandkamera, neue Figur, Wolken, die Figur beginnt klein und wird größer mit Eismünzen, Level-zu-Level-Übergang), aber was man nicht sieht, sind die Engineverbesserungen. Konnte nochmal einiges optimieren, dass es auch ja weiter aufm GP2X läuft. ^^

Übrgens wird es später weniger Eismünzen geben. Das ist nur zum Testen. Und man wird sie auch nutzen können. Denn irgendwann muss sich der arme Schneemann ja gegen Gegner wehren. :juhu:
LG Ziz

Ja, ich sollte Kirby wohl echt mal testen. Mit dem Gameboy ging die Serie los, wenn ich mich recht erinnere, oder?

jedenfalls sieht deine neue Demo schon viel besser aus, die Kamera fühlt sich nun auch natürlicher an. Man könnte die Kamera-Verzögerung beim springen noch grösser machen, natürlich muss die Kamera die Figur immer wieder schnell einholen können.
Du verwendest Software Renderer? Ich vermute, da wird die Polygonzahl irgend wann ein Performance Problem. Die Wolken im Hintergrund z.B. brauchen doch eig. gar keine 3D Objekte zu sein oder? Kann man da ein schönes BG Bild mit Landschaft und beweglichen 2D Wolken nehmen? Das gäbe nen tollen Parallax Effekt und man muss keine 3D objekte dort benutzen, so bleibt mehr power für den Vordergrund übrig. - Das ist aber nur ne Idee, ich weiß ja nicht wie deine Engine sowas handhabt und ob es wirklich sinnvoll währe. Aber Parallax muss rein!
Und könnte man trotzdem optional die HW nutzen beim berechnen, dann halt nur für die Pandora während GP2X einfach im Software Mode läuft?

Ich hätte noch ne Idee für ne Sprung-Animation: Der Schneemann hat da kurz Lücken zwischen seinen Kugeln, beim auftreffen aufm Boden klatscht es ihn aber wieder zusammen. :-D

 

[Ziz]

Ja, ich sollte Kirby wohl echt mal testen. Mit dem Gameboy ging die Serie los, wenn ich mich recht erinnere, oder?

Du irrst. Es begann auf der SNES. Es kann sein, dass es da den Gameboy schon gab, als das Spiel rauskam, das weiß ich nicht. Ich spiele Kirby immer auf einem GBA-Emu, die Spiele sind echt gut gemacht, da es gpsp bestimmt auch für deinen Lieblingshandheld gibt, würde ich dir das empfehlen. ;-)

jedenfalls sieht deine neue Demo schon viel besser aus, die Kamera fühlt sich nun auch natürlicher an. Man könnte die Kamera-Verzögerung beim springen noch grösser machen, natürlich muss die Kamera die Figur immer wieder schnell einholen können.

Ich mach das so, dass die Kamera und die Spielerposition unabhängig von einander ausgelesen werden. Die Kamera bewegt sich jedoch immer in Richtung der Spielerposition mit dem Geschwindigkeitsvektor von Kamera zu Spieler. Wie man sich selbst erschließen kann, wird dieser mit größerem Abstand zum Spieler auch immer größer, weshalb sich automatisch ein Maximalabstand ergibt. Was ich nur einstelle ist der Faktor für die X- und die Y-Komponente dieses Geschwindigkeitvektors. :yes:
Problem bei Y ist nur, dass die Beschleunigung konstant und die Maximalgeschwindigkeit potentiell unendlich ist. Wenn man sich in die Tod stürzt, merkt man das. Die Kamera kommt noch hinterher, aber die Verzögerung wird größer. Ich denke aber, ich werde den Y-Faktor trotzdem leicht vergrößern. Wenn der Spieler nicht mehr zu sehen ist, stürzt man eh gerade ne Klippe runter, was nicht Sinn der Sache ist. ^^

Du verwendest Software Renderer? Ich vermute, da wird die Polygonzahl irgend wann ein Performance Problem. Die Wolken im Hintergrund z.B. brauchen doch eig. gar keine 3D Objekte zu sein oder? Kann man da ein schönes BG Bild mit Landschaft und beweglichen 2D Wolken nehmen? Das gäbe nen tollen Parallax Effekt und man muss keine 3D objekte dort benutzen, so bleibt mehr power für den Vordergrund übrig. - Das ist aber nur ne Idee, ich weiß ja nicht wie deine Engine sowas handhabt und ob es wirklich sinnvoll währe. Aber Parallax muss rein!

Vielleicht mache ich einen Parallaxeffekt, indem ich im Hintergrund Berge aus groben Polygonen darstelle. Ich nutze die 3D-Engine aus zwei Gründen: 1. Weil ich es cool finde und 2. damit es überall gleich groß aussieht, ohne dass ich Sprites hin und her vergrößern/verkleinern muss oder mir überhaupt welche ausdenken (*schauder* Kreativität *schauder*). Einzige Ausnahme ist Schrift. Die wird in "Stufen" größer. Aber das ist auch das einzige, weil Schrift mit Polygonen meinen Softwarerenderer tötet und die keymap in 3 Größen liegt auch schon bereit. Aber du hast Recht, dass mein Software Renderer Grenzen hat. Die sind am GP2X (mit 200 Mhz, keine gefrickelten Ram Timings) gerade erreicht (20-40 fps). Ich konnte heute nochmal ne Menge rausholen, indem ich die Rückseite der Wolken z.B. entfernt habe. Er hat sie nie gezeichnet, aber doch immer "mitgeschleift", d.h. mit der Modellviewmatrix multipliziert und die Punkte auch projeziert, ehe man merkt: "Hoppla, Polygon nicht zu sehen.". Genau das gleiche bei den Würfeln aus denen das Level aufgebaut ist: Die sind nun hinten offen.

Und könnte man trotzdem optional die HW nutzen beim berechnen, dann halt nur für die Pandora während GP2X einfach im Software Mode läuft?

Könnte man. Aber ich tue es aus zwei Gründen nicht.
1. Was auf dem GP2X flüssig läuft, läuft auf den anderen Handhelds erst recht flüssig - MIT Untertaktung. WIZ und Co haben z.B. modernere Prozessoren mit 533 Mhz Takt. Die können das später bestimmt locker flüssig bei 300 Mhz und wengier spielen. Auf der Pandorra lief es laut letzten Aussagen mit irgendwas um die 60 fps (und da gibt es eh eine Begrenzung, KA, wo die in echt wären) bei 500 Mhz. Man darf auch nicht vergessen, dass das Gros der Berechnungen Matrixmanipulationen sind. Die sind überall gleich, egal ob 320x240 oder 800x480. Der Leistungsunterschied ist nur an der Füllrate auszumachen und die nimmt allgemein nicht viel Zeit ein.
2. Ich müsste mich in eine Grafikbeschleunigung einarbeiten, die ich nicht zur Hand habe. Einiges mache ich ja auch etwas anders, um effizient zu arbeiten und das wäre dann recht frickelig.

Ich hätte noch ne Idee für ne Sprung-Animation: Der Schneemann hat da kurz Lücken zwischen seinen Kugeln, beim auftreffen aufm Boden klatscht es ihn aber wieder zusammen. :-D

Die gleiche Idee hatte ich auch schon, aber erstmal verworfen, weil die Umsetzung mit meiner Physik kollidiert (Wortspiel) und wenn es ungenau ist, weiß man auf einmal nicht mehr, warum man gerade irgendwo gegenknallt. :-D

LG Ziz

 

[fusion_power]

Ja, ich sollte Kirby wohl echt mal testen. Mit dem Gameboy ging die Serie los, wenn ich mich recht erinnere, oder?

Du irrst. Es begann auf der SNES. Es kann sein, dass es da den Gameboy schon gab, als das Spiel rauskam, das weiß ich nicht. Ich spiele Kirby immer auf einem GBA-Emu, die Spiele sind echt gut gemacht, da es gpsp bestimmt auch für deinen Lieblingshandheld gibt, würde ich dir das empfehlen. ;-)

kleine Korrektur laut Wiki:
http://de.wikipedia.org/wiki/Kirby
"Kirbys Dreamland" 1992 Gameboy
"Kirby's Dream Course" 1994 SNES
...gab echt sau viele Kirby Spiele seit dem wie ich beim lesen gerad feststelle. ^^

Wegen der Kamera, ich hatte das nur so gemeint, das anfangs die Kamera halt kurz hinter her hängt wenn die Spielfigur die Richtung ändert oder beschleubnigt, aber dann nach kurzem delay umso schneller aufholt, insofern ist es egal wie schnell sich die Figur bewegt, denn die Kamera ist am Ende immer schneller als die Figur und zentriert die Figur wieder.

 

[Ziz]

Tatsache, ich hatte Unrecht. Ich vergesse immer wie lange es den Gameboy gab. Ich bekam meinen vielleicht '96 oder so.

Ich habe mal wieder ein kleines Video
[youtube]q4kvKtEuSbc[/youtube]
Neu dazugekommen sind Waffe, Feinde, Feinde mit Waffen, sone Art Superwaffe, die das letzt Segment abwirft und VIEL Buggefixe.
Es ist wirklich nervig, dass mit jedem neuen Feature exponentiell Bugs hinzukommen, weil die neuen Funktionen mit den alten zusammen auf einmal zu Fehlern führen könen. <_<

Aber bis auf einen Bug (der eher lustig und selten ist. ^^), sieht es im Moment wieder ganz gut aus. Es scheint immerhin nicht mehr abzustürzen. An der Stelle sei gesagt, dass gdb aufm GP2X sehr sehr geil ist. ^^

Was ist nun noch zu tun? So viel. -_- ich wollte noch eine dritte Waffe einbauen, bisel mehr Gegnertypen (wobei die recht gut in der Leveldatei definiert werden können, was Größe, Farbe und Health angeht), vielleicht was mit dem Zoom, auf jeden Fall Musik und Geräusche und was auch ein Muss ist: Ein Partikelsystem.
Und da ich den 29. und 30. auch noch Weg bin, noch weniger Zeit. ^^

Naja, wird schon, hatte ja auch in der Vergangenheit wenig Zeit und bin schon weit gekommen. :juhu:

LG Ziz

 

[fusion_power]

Die Gegner ballern ja wie blöde. Hätte der Schneemann Arme, könnte man noch animieren, wie er mit Schneebällen oder Kohle wirft. Vllt kann er auch mit Karotten werfen, dan hätte man 3 verschiedene Muni, vllt. mit unterschiedlichen Eigenschaften?
Kann die Engine auch Schrägen? Dann könnte der Schneemann als Kugel runter rollen und die Feinde so plätten, währ sicher auch lustig.

 

[abc]

Also durch die Perspektive sieht das echt spannend aus

 

[Ziz]

Die Gegner ballern ja wie blöde.

Nur ein Test. ^^ Ich denke, ich lass die Schussfrequenz wie den Rest des Gegners in der Level-Datei einstellen. In jedem Fall wird es in späteren (ersten) Leveln NICHT so viele wild um sich ballernde Gegner geben.

Hätte der Schneemann Arme, könnte man noch animieren, wie er mit Schneebällen oder Kohle wirft. Vllt kann er auch mit Karotten werfen, dan hätte man 3 verschiedene Muni, vllt. mit unterschiedlichen Eigenschaften?

Werfanimationen sind doof, weil schwer zu machen. Ne, aus Zeit und Faulheitsgründen erstmal ohne. Und eine dritte Waffe wird es ja noch geben. Aber die wird... unerwartet werden. ^^

Kann die Engine auch Schrägen? Dann könnte der Schneemann als Kugel runter rollen und die Feinde so plätten, währ sicher auch lustig.

Hm, die 3D-Engine in jedem Fall. Die Physik aber nicht. Die ist sehr simpel gehalten, weil die Zeit für mich so knapp war. Das nächste mal würde ich mal nach einer performanten 2D-Festkommazahlen-Physikengine Ausschau halten.

LG Ziz

 

[fusion_power]

Was sind denn in der Praxis die Unterschiede zwischen einer Festkomma und einer Fliesskomma-Engine? ist da vieles anders?

 

[Ziz]

Was sind denn in der Praxis die Unterschiede zwischen einer Festkomma und einer Fliesskomma-Engine? ist da vieles anders?

Alle Multiplikationen, Wurzeln, Sinus, Kosinus, Division und Modulo müssen von float auf die die Fließkommazahl (meist 32 Bit Singed Int) umgestellt werden.

Wenn ich die Zahl 3.75 als Festkommazahl mit insgesamt 8 Bit und 4 Bit für "nach dem Komma" darstelle, komme ich (binär) auf:
0011.110 = 0*8 + 0*4 + 1*2 + 1*1 + 1*½ + 1*¼ + 0*⅛ + 0*1/16

3.75*3.75 = 14.0625

Wenn ich das direkt mit der Festkommazahl mache:

00111100*00111100 = 111000010000

Das Problem ist, dass bei der Muliplikation das Komma "verrutscht". Deshalb müssen wir bei der Zahl die letzten 4 Bit streichen und erhalten:
1110.0001 = 14.0625

Man merkt, das haut hin. Wenn man intern jedoch nur eine 8Bit CPU hätte (in der Realität habe ich 32 Bit zahlen auf einem 32 Bit System, die 8 Bit dienen der Veranschaulichung), würde 00111100*00111100 ohne Extraregister direkt 00010000 ergeben. Die letzten Stellen werden gecuttet. Wenn man das nun wieder um 4 Bit schiebt, kommt sogar nur 00000000 raus. Was vollkommen falsch ist. Deshalb bewege ich beide Faktoren vorher um die Hälfte der Nochkommastellen.

Damit erhalte ich:
00001111 * 00001111 = 11100001
1110.0001 = 14.0625 <- haut hin

Bei der ARM-CPU habe ich Shift Operationen direkt in Multiplikations oder Additionsoperationen mit drin, deshalb kostet mich meine Muliplikation ca. 2 Takte. Bei Float wären das VIEL mehr, weil es keine FPU gibt.

Ich bin bei mir ganz froh, dass das von Anfang an ohne floats auskommt. :yes:

Man KANN alles ändern, ist aber ziemlicher Aufwand und sehr fehleranfällig (!).

LG Ziz

 

[fusion_power]

Zu kompliziert für mich. :-D
Aber ich kann mir nun vorstellen, warum Ports von Spielen, die viel Fließkomma enthalten so viele Probleme machen können, wenn sie auf (ARM) Festkomma portiert werden müssen, ARM hat ja glaube von haus aus keine Floatpoint Einheit drinne sondern muss das "extern" lösen?

 

[Letalis Sonus]

Es ist ja nicht so, als ob Fließkomma Berechnungen komplett tabu wären. Wenn die Menge nur unwesentlich ist, kann man einfach auf die langsame Emulation vom Cortex zurückgreifen, indem man die Problematik einfach ignoriert. Dann gibt es ja noch NEON, wobei einem aber geraten wird, den NEON Assembler Code per Hand zu schreiben, weil GCC wohl nicht besonders gut im Generieren von NEON Code sein soll. Man könnte wahrscheinlich sogar den DSP als generische FPU missbrauchen, aber der Aufwand wäre es wohl nicht wert.

 

[Ziz]

Richtig.
Geringe Mengen sind nicht tragisch.
Wenn man z.B. eine OpenGL Implementierung hätte, die von außen Floats entgegennimmt aber intern mit Fixed Point arbeitet, fällt der Konvertierungsaufwand kaum ins Gewicht.

Bei meinem Spiel errechne ich z.B. zu Beginn eine nicht unbeachtliche Menge an Kosinus- und Sinuswerten für eine Lookuptable.
Aber da ich es nur einmal am Anfang tue, merkt man es nicht/kaum.