Jim

Da ich jetzt seit einiger Zeit mal eine gescheite Homepage habe (nichts mehr mit Lycos) möchte ich hier mal auch eines meiner aktuellen Projekte vorstellen an dem ich seit gut 1,5 Jahre arbeite. Es ist noch nicht ganz fertig, aber es sind mittlerweile alle Features und Funktionen in ihrer Grundfunktion eingebaut (also Sachen wie Kollisionsabfrage, Eingabe, Soundmixer, etc.).

Nun zum Spiel:
Es ist ein Beat'em Up mit Ranma (männlich und weiblich) als einzigen spielbaren Charakter. Im Grunde ist es ein Remake des dritten Ranma Beat'em Ups auf dem SNES. Also Sprites, Soundeffekte und das Gameplay sind eigentlich 1 zu 1 übernommen. Der Hintergrund ist noch aus dem ersten SNES Spiel.
Das Spiel wurde komplett in Assembler geschrieben, da ich damit mittlerweile am besten auf dem GBA klarkomme und man auf dem Advance auch noch effektiv in Assembler seine Sachen schreiben kann.

Als Zusatz kann man sich auch noch eine kleine Animation mit Musik anschauen. Hier hab ich das Animationsformat von Goldmomo verwendet und zusätzlich noch Musik im 8ad Format von tepples mit eingebaut. Die Animation wiederholt sich sehr schnell, da ich bis jetzt noch keine Zeit gefunden habe das Ending der 7. Staffel komplett einzubauen.

Download: RanmaBattle_20080324.gba (1950 KB)

Für weitere Infos über die verschiedenen Modi die man im Hauptmenü auswählen kann oder über die Optionen die man einstellen kann verweise ich auf meine Homepage (auf Englisch).

Miniaturansicht angehängter Grafiken

       

goldmomo

Tolles Spiel, habe es schon mal vor einigen Wochen ausprobiert, gefaellt mir gut. Besonders die Bewegungen/Animationen passen vom Timing her super. Wie hast du das mit der Kollisionsabfrage geloest (Pixelgenau oder Schnittpunkte, ...)?

Jim

Das mit der Kollisionsabfrage kannst du dir in der neuesten Version auch selber anschauen wenn du willst. Hab dafür im Optionsmenü den Punkt Debug eingebaut.
Die Abfrage besteht nur aus einer Abfrage zweier Rechtecke auf einen Schnittpunkt. Und die Rechtecke werden im entsprechenden Debugmodus mit dem eingebauten Windowsfeature des GBAs angezeigt.

Debugmodi:
0 = keine Anzeige
1 = Standartkollision (z.B. für die Kollisionen beim Laufen)
2 = Ranma-Chans Treffer Kollisionen (bei Attacken)
3 = Ranma-Kuns Treffer Kollisionen (bei Attacken)

Hab schon überlegt das ganze auszubauen, vielleicht auf 2 Rechtecke um mehr Genauigkeit zu erreichen, aber das hab ich bisher sein lassen. Ich seh dafür auch momentan keine Notwendigkeit.

Kamikaze_Attack

Darf ich eine vllt. dumme Frage stellen?

Wie kann ich dieses (selbstprogrammierte, also ich meine ausdrücklich keine ISOs) Spiel auch auf dem Gameboy selbst spielen ohne mich irgendwelcher illegalen Dinge zu bedienen (Module brennen (oder wie man das bei einem Modul nennen will o_o) etc.) ?

Oder ist es nur möglich es per Emulator auf dem PC zu spielen?

P.S.: Die Charakteranimationen gefallen mir sehr Genau wie die Schatten am Charakter selbst

__________________

goldmomo

Per Emulator auf PC gehts, ueber Flash-Hardware wird hier im Forum aber aus diversen Gruenden nicht gesprochen (im Dev-Forum nur wenn es um direkte Ansteuerung solcher Geraete/Karten geht), siehe Forenregeln. Also google benutzen ...

Ranma1/2

sieht ja voll witz aus

__________________

Jim

Mein Hauptprojekt hat Fortschritte gemacht, aber diese sind noch nicht vollständig eingebaut. Deswegen wollte ich jetzt mal das kleine Nebenprojekt präsentieren.

Unter dem Menüpunkt "Ending" findet man ja eine kleine Animation mit Musik. Nun hab ich mir gedacht das ich mal eine komplette Animation mache und dies als eigenständige Datei umsetze. Hier ist das Ergebnis:

Download: AkaneRanmaRunning.gba (4786 KB)

Die Kompressionsarten hab ich im 1. Post ja schon erwähnt (Goldmomos Animations- und Tepples 8ad-Format). Leider langt die Kompression nicht um eine ganze Folge von Ranma umzusetzen. Die Szene die man in der oben verlinkten Datei sieht, hat schon einiges an Bewegung drin was den Kompressionsalgorithmen schon schwer zu schaffen macht. Am Anfang und am Ende wird am besten komprimiert.

Einige Zahlen und Daten:
Länge der Animation: 23 Sekunden
Anzahl Bilder: 231
Größe der Bilddaten (gepackt): 4592 KB (bei 52 % Komprimierung)
Größe der Audiodatei: 149 KB
Programmgeschwindigkeit: 10 FPS (obwohl ich lieber 12 FPS hätte)

Und eine Frage zum Schluss: Wer erkennt die Szene und kann die Folge nennen?

Miniaturansicht angehängter Grafiken

 

Tharo

Hmm, ich bin mir nicht sicher. In Ranma sind die Leute ja praktisch alle Tag lang irgendwo rum gerannt.

Aber wollte an dieser Stelle auch von meiner Seite aus deine Arbeit loben. Ist nett geworden

__________________
Ja!!
Ich lebe noch! :P

Jim

Danke, sitze auch schon lange genug dran. Hab mir auch ein sehr hohes Ziel gesteckt. Es soll ein Hobbyprojekt werden das fertig wird.

Das Bild das ich hier reingestellt habe soll mit Absicht nichts groß aussagen, aber wenn du dir die Szene mal anschaust wirst du sie sicher erkennen können, wenn man denn die paar (80) deutschen Ranma Folgen kennt. Fand die Szene halt lustig. Leider kommt das nicht mehr so genial raus wie in der kompletten Folge.

Und momentan krieg ich die komplette Folge nicht auf ein GBA-Modul. Bin momentan bei 48% Kompression. Tendenz: Langsam sinkend, aber noch nicht bei 5% (was ich bräuchte).
Bin grad dabei die Ausgangsbilder zu bearbeiten, um sie besser komprimieren zu können.

Hab mir auch ein paar profesionelle Codecs angeschaut und muss leider feststellen, dass diese einen komplett anderen Ansatz haben. Größter Unterschied ist der Bildmodus. Bei mir läuft alles im Mode 4 (und damit auf 256 Farben beschränkt), bei den Profis (majesco und caimans) im Mode 3.

Ich hab ja gehofft das Goldmomos Ansatz für eine komplette Folge reichen könnte, aber dafür müsste man doch noch einiges an Zeit reinstecken. Außerdem passt das Verlustfreiekomprimieren zu diesen Zwecken doch nicht ganz. Deswegen werd ich mich wohl demnächst wieder stärker an mein Beat'em Up setzen, oder zum Rennspiel, oder zu einer weiteren Zelda Demo, ...

Edit: Ich hatte eine ganze Weile den Link zu einer alten Version hier (im 1. Post) angegeben. Mittlerweile ist das ausgebessert. Wers von der Homepage hat, hat ja schon die neuere (vom März) Version.

Tharo

Also ... ich gehe mal davon aus, dass du die volle GBA auflösung willst. Sprich mode3, nicht mode 5.

Hast du mal darüber nachgedacht mode 4 zu benutzen in einer art gekachelten paleten modus? Ich glaube dadurch könntest du eine zusätzliche sehr hohe kompression erreichen. Ich bin mir eigentlich ziemlich sicher, dass du mit den GBA onboard agorythmen + einen guten sound kompressor auf die benötigte größe kommen müsstest. Wenn nicht solltest du vllt einen einfachen mpeg (falls du dich damit mal befasst hast) nehmen und auf den GBA zuschneiden. Speziell was die Farbinfomationen betrifft.
Das du halt selbige überhaupt völlig aus dem MPEG raus lässt und seperat behandelst. In etwa wie 16*16 farbpaletten und dann pro MPEG source bild eine komplette liste der benutzten Paetten und pro update bild nur die update infos der globalen paletten "boxen" ... Das dürfte nach wie vor sehr schnell sein da du mit indexen arbeitest und die paletten quasi schon "vorgerendert" im GBA liegen hast.
Natürlich müsstest du dazu vorher die "optimalen" paletten für das video mit einer selbst geschriebenen C applikation vorberechnen damit alles optimal läuft.

Ich halt es aber alles in allem für gut machbar. bei der auflösung ist MPEG gut realisierbar .. zumal der GBA ja den letzten schritt mit der HW unterstützt. Und mit der vorberechnung der perfekten paletten baukästen sollte das eigentlich reichen

__________________
Ja!!
Ich lebe noch! :P

goldmomo

Bei meinem RLE/XOR/LZSS wird man leider immer Probleme bei starken Änderungen zwischen den Frames haben. Bei einfachen Animationen ist die Kompression/Performance sehr hoch (ähnlich wie bei gif oder anim5(7 usw.) Format), bei Animationen wo es aber schon zwischen den Frames einzelne Pixel in der Farbe abweichen (weil z.B. Video-Aufnahme) bricht es aber stark ein. Hier bringt die RLE&XOR Stufe nichts, da wäre ein RLE (evtl. Zick-Zack) und eine Differenz zum letzten Bild besser. Eine Huffman am Ende wäre auch nicht schlecht (weil die Einzelcodierungswarscheinlicht nie gleich sein wird (sonst wäre es Noise)), aber irgendwann dauert dann das Framdecodieren ewig.

Wenn das nichts mehr hilft, dann muss eine verlustbehaftete Kompression her (z.B. diskrete Cosinustransformation). Da sollte hohe Kompressionsraten drin sein, was aber bei reinen Pixel/Flaechen Animationen stark auf die Bildqualität geht.

Ich würde sagen einfach mal ausprobieren :-)

Jim

Also, ich hab jetzt mal versucht den 1. Teil der Animation getrennt zu behandeln und den Hintergrund soweit anzupassen (von Hand) wie möglich. Und ich komme auf 5% kompression. Dann kommt die Laufszene und ich lande bei über 70%.
Den meisten Anteil an der Dekompression macht der RLE-XOR-Teil aus. Während ich das Berechnen der Palette, das Löschen und der LZSS-Algorithmus in ein VBlank kriege, passte der RLE-XOR-Teil nicht mehr mit rein. So meine Erfahrungen von der Ending-Sequenz. Das liegt mit höchster Wahrscheinlichkeit an den intensiven "Laden und Speicher"-Schleifen. Durch eine kleine Überarbeitung (Thumb in Arm und alles in den IWRAM) konnte ich da jedoch noch ein paar Optimierungen vornehmen, es reichte allerdings noch nicht für 12 FPS. Arm-Code im IWRAM ist im übrigen mindestens genau so schnell wie die Bios-Funktionen. Was Tharo mit Hardwareunterstützung doch gemeint hat, oder? Also ich halte diesen Vorteil für nicht so groß.

Ich hab jetzt auch mal nach den ganzen Stichwörtern gesucht die ihr beiden hier genannt habt. Auf dem NDS gibt es ja ein MPEG-1 Format: DPG. Obs allerdings für den GBA reicht ? Ich weiß auch gar nicht ob das die Anstrengung wert ist. Werd das Thema im Auge behalten.

Zum Hauptprojekt wollt ich noch sagen, dass der Computergegner endlich eine kleine KI bekommen hat. Somit greift dieser auch endlich an. Allerdings dauerts noch mit einer neuen (öffentlichen) Version.

Tharo

Wie gesagt.
Ich bin der Meinung wenn du die cosinus transformation aus mpeg1 dahingehend erweiterst, dass du die "palette" ebenfalls nur auf updatebasis speicherst und nicht für jedes bild einzeln .. und die bilder for-optimierst, dass du dann den benötigten Platz bekommen solltest.
Rechentechnisch ist das natürlich schon ein wenig knapp. Aber dadurch, dass du in mode4 wärest sollte das mit ein wenig gutem assembler und unter berücksichtigung der BUS Geschwindigkeiten eigentlich kappen

__________________
Ja!!
Ich lebe noch! :P

Jim

Zu den Paletten kann ich noch sagen, dass für jede Szene eine eigene Palette verwendet wird die dann auch über mehrere Bilder (bis zu einem größeren Wechsel) beibehalten wird. Allerdings wird für jedes Bild die Palette neu berechnet, auch wenn es meistens keine Veränderung gibt. Da müsst ich also das Animationsformat anpassen, dann könnte ich mir auch die unnötigen Berechnungen ersparen.

Dann schau ich mir jetzt mal die Cosinustransformation an, bzw. ich informier mich jetzt erstmal was das überhaupt ist. Deinem 2. Post hier konnte ich am Anfang noch nicht so recht folgen, langsam wird aber alles ein bisschen klarer.

Jim

So, ich meld mich hier mal wieder, da ich meine Ergebnisse in Sachen Videokompremierung mal niederschreiben wollte.
Einziger vorzeigbarer Fortschritt ist, dass die unnötigen Neuberechnungen der Paletten weg sind, dadurch wurde die Animations-Datei um 1KB kleiner.

Desweiteren hab ich mich mit den einzelnen Komprimierungsstufen von MPEG befasst und ein paar nützliche Links gefunden. Hieraus ist leider keine neue Demo geworden, da ich mich zur Umsetzung nicht wirklich motivieren konnte. Aber hier mal das was ich habe:

Quither: Ein Programm um Bilder in den 16 Paletten Modus vom Mode 4 umzusetzen. Der Code ist auch im Download enthalten.

DTC Example: Eine Excel-Tabelle in der man ausprobieren kann wie die diskrete Cosinustransformation funktioniert.

Huffman Code Discussion And Implementation: Eine gute Erklärung und ein gutes Beispiel Programm für den Huffman Algorithmus.

Berkeley MPEG Encoder: Und hier ist eine Umsetzung eines MPEG Encoders. Wenn man die Funktionen die man braucht findet, kann man aus solchen Beispielen immer viel lernen.

So viel zu den Quellen für diesen Teil.
Jetzt noch was zum Beat'em Up-Anteil des Spiels:

Als erstes erstmal 2 Links zu Threads die allgemein über die Programmierung eines Beat'em Up-Spiels gehen. Wer sich für den Programmieranteil interessiert kann sich das mal durchlesen. Ich selber erkenn die nützlichen Tipps in solchen Beitragen immer erst wenn ich das Problem soweit gelöst habe.
2D Fighting Game - Programming Techniques
Actor (sub)system

Und als Abschluss wollt ich hier vermelden, dass ich nach ein paar Monaten Pause (in der Gitarre und Schule wichtiger waren) ich wieder stärker am Spiel arbeite. Meine selbst gesetzte Deadline ist ja im Juli 2009. Wo es momentan am meisten habert, ist dass ich keine wirklich komfortable Erstellung der Animationen habe (also keinen Editor für Windows programmiert habe oder ähnliches), deswegen ist die Motivation für solche Arbeiten (wie eben das Erstellen der Animationen) nicht sehr hoch. Das muss ich leider auf meine wenigen Kenntnisse in der Windows-Programmierung schieben. Deswegen bau ich jetzt einen Demonstrationsmodus für Animaionen ins Spiel ein, wo alle Animationen langsamer ablaufen. Ich hoffe das dann wieder was vorangeht.