Einfache Spieleentwicklung am Beispiel :-)

Garbage? Sollte nicht sein
Welche Version von x64 benutzt Du?
Naja, das GBA reversen ist ja nicht zwingend Teil der Spieleentwicklung. Daher ging ich darauf auch nicht weiter ein und statt dessen basiert das Testlevel auf der sehr groben Preview-GFX
Vielleicht doch mal kurz etwas Code damit man sieht wie einfach das sein kann:

Das ist bereits der vollstaendige Konverter fuer Preview.png -> Leveldaten.
(wenn das PNG als indexed color vorliegt).
Oben ein kurzer Array mit dem ich die 10 Farben des Previews auf meine 4 mappe.
Dann zwei FOR-Schleifen ueber Y und X.
Das print-Gebastel ist nur um immer eine Zeile ".byte $00, $01, ..." auszugeben.
Ich mag da immer PRINT fuer so einfache Tools und leite die Ausgabe direkt in eine Datei um.
Ein sauber formatiertes file.write() ist netter, aber so gehts ruckizucki.

uU liegt es sogar tatsaechlich an Vice
Ich untersuche das mal genauer. Am Exomizer sehr sicher nicht.
Hier jetzt eine weitere Version.
Es geht voran
neu:
- Rotor aus 3 Segmenten (wie man leider auch noch sieht
- Rotor hat jetzt sehr genau die Laenge UND Geschwindigkeit des Originals am GBA.

Das Level ist allerdings nun etwas schwerer als am Original weil ja der Rand mit 2x2 chars voll dazuzaehlt. Wenn das eine 'Bande' draus wird, ragen die Ecken ja nicht mehr so in die Bahn versteht sich...

Edit:
jetzt auch ohne seltenen Timing-bug

Ja, ich weiss
Aber im RAM verbrauchen die inaktiven Level eben entsprechend weniger.
Die meisten Scroller koennen (wollen) sich den CPU-overhead nicht geben fuer verschachtelte maps...

rotor.prg geht immer
Bei den anderen gabs Probleme je nachdem wann genau der Kollisionsregister zuerst ausgelesen wurde.
Vice handhabt das ETWAS anders als der C64 aber falsch war es vorher auf jeden Fall.
Siehe Regel ganz oben: Vice ist nicht schuld

Es gibt etwas Neues
Und zwar ist Erfolg zu vermelden was das Reversen des GBA-codes angeht.
Kniffeliger als ich erst dachte. Die Maps sind in der Tat gepackt im ROM, aber ich kann jetzt alle extrahieren.
Die Rohdaten sind teils etwas obskur, aber jetzt liegt alles in echter Tileaufloesung vor.
Ich habe mal eben das eine Testlevel von vorher neu aufgesetzt.
Mit dabei ein Rotor in Originalgroesse und -geschwindigkeit.
Ebenfalls eine recht nette Kollisionskontrolle die noch amok laeuft wenn man in Waende faehrt.
Die lohnt es sich aber erst feinzujustieren/debuggen wenn man auch pixelweises Scrolling hat.
8-directional Scoftscrolling und bessere Levelaufbereitung/extrahierung stehen jetzt auf dem Plan erstmal.
Danach bessere Kollision die DANN auch doch auf charebene wird laufen muessen (bisher nicht damit man die Federn abfangen kann.
Ebenfalls geht es dann auch an die Scrollgeschwindigkeit die variabel ist...

Und ein grosser Schritt ist getan
Das Projekt hat seinen ersten Speicherplan bekommen:

das erschien mir erstmal ganz zweckmaessig.
Und auch das etwas laestige Softscrolling ist drin.
8-Wege Softscroller mit Doublebuffer (bisher ohne color RAM!).
Aktuell nur 20 Zeilen wie im GBA Original. Ob ich das auf 30x20 einschraenken sollte?
Man gewinnt CPU-Zeit, verliert aber ein Sprite und natuerlich schraenkt es die Sichtbarkeit ein.
Das gilt es also abzuwaegen.
(Man verliert ein Sprite weil man (fast) nur mit einem Sprite den flackernden Softscroll-Rand verdecken kann. Bei 40 Zeichen Breite sorgt ja der 30 Spalten-Mode dafuer).
Der Hardscroll ist schon recht fix und passiert sogar in einem Rutsch!
Dadurch gibt es weniger Aerger mit dem Softscroll und der Vorhersagbarkeit der noetigen Richtung.
Darauf gehe ich bei Bedarf gerne nochmal genauer ein.
Der Code benutzt "halben Speedcode", also lda source,x - sta destination,x Serien.
Und zwar fuer jede der 8 Richtungen und beide Buffer. Also 16 insgesamt.
Aktuell scrollt es fix mit 2 pix pro Schritt aber das ist auf jeden beliebigen Wert aenderbar mit dieser Methode.
Das Original erlaubt auch verschiedene Geschwindigkeiten.
Das muss noch 'vermessen' werden.
Das Kollisionshandling liefert jetzt auch schon recht brauchbare Ergebnisse auch wenn es nach sehr einfachen Regeln arbeitet und dazu neigt im wahrsten Sinne des Wortes durchzudrehen
Viel Spass, es ist so quasi schon spielbar

als nächstes bastel ich mal nettere Grafik denke ich (um damit dann auch den scroller noch zu debuggen

Ah! Es liest hier also doch jemand mit
Per Hardwareregister kann man immer nur die volle Bildschirmbreite scrollen (0-7 Pixel).
Das kann man auch nicht IN einer Zeile aendern. Selbst wenn ich nur z.B. die linke Haelfte oder um bei Kuru zu bleiben 30 chars scrollen moechte, wackeln die rechten 10 dann trotzem fies hin und her.
Genauer gesagt bewegt sich alles per Hardscroll in eine Richung und springt dann zurueck.
Es gibt da 4 Loesungen die mir grade einfallen.

1) man laesst den Teil der nicht mitscrollen soll schwarz.
Problem: Trotzdem eiert der Rand dann dumm rum.
Loesung dazu: man legt ein (hier schwarzes) Sprite an die Stelle an der man den Rand haben will. Prioritaet dann ueber der Bitmap (und ueber allen anderen Sprites).
Wieso nur ein Sprite? Man kann es ja Problemlos immer wieder nach unten verschieben sobald es dargestellt wurde. Nach unten schieben geht sogar immer, so dass das Timing kaum eine Rolle spielt.
In dieser 'gecrackten' Proof-of-concept Engine von mir hab ich das z.B. so gemacht:
http://csdb.dk/release/?id=114516
Das ist die einfachste Variante obwohl es in dem Beispiel da oben etwas kniffeliger war, weil der Multiplexer das beruecksichtigen musste, dass immer das Sprite mit der hoechsten Prioritaet an der Stelle bleibt.

2) Man macht das wie bei 1) moechte aber Text oder sowas darstellen am Rand. Den plottet man dann in (z.B. weisse) Sprites. Damit es leserlich wird, verliert man aber nochmal 1-3 Sprites pro Zeile.

3) wie 1) aber statt Sprites nimmt man chars fuer den Text. ABER die scrollen ja mit?! Also erstellt man die Grafik fuer den Rand so, dass sie fuer jeden Scrollschritt entgegengesetzt scrollt. Wenn da 'A' stehen soll und das Spiel immer in 2 Pixelschritten scrollt, braucht man also 8 chars.
zwei Nebeneinander und das A scrollt in 4 schritten von links nach rechts entgegen dem Rest des Screens. Das sieht man meist nur bei Scrollern mit 4 oder 2 Pixeln pro Scrollschritt, da man sonst einfach zuviele der 256 chars verliert.
Ich habe hier ein Projekt mit 1 Pixelscroll rumliegen, dass das macht Beruehmtes Beispiel ist Operation Wolf und Co.

4) Man kann auch ALLE Levelgrafiken so designen, dass jedes Char in mehreren Scrollstufen vorliegt. Dann kann man ganz ohne VIC-Scroll auskommen. Das braucht aber sehr viele chars, so dass die Grafik sehr limitiert ist.
Vor allem wenn man nicht nur links-rechts scrollen will. Es gibt einige wenige Beispiele aber. Auf meiner Festplatte und mal in der 64er irgendwann auf jeden Fall.

Im Prinzip entsprechen 3) und 4) einer echten Parallax-Scrolliung-Engine, aber statt einige wenige Zeichen so zu behandeln, besteht eben sehr viel mehr Grafik daraus.
Siehe auch Fluglevel bei Turrican 3, Flimbos Quest, Hawkeye 2.
Bei diesen 3 koennte man die Hintergrundgrafik nehmen und daraus einen Scroller basteln, der OHNE Hardwarescroll auskommt.
(und dann auch nicht Bildschirmbreit sein muss natuerlich).

Bei _diesem_ Spiel hier wollen wir aber schon viele Chars fuer die Levelgrafik verwenden.
Ich ueberlege noch ob man es auch auf 30x20 begrenzen sollte.
Vorteile:
- die Level funktionieren wie im Original (was man sieht und nicht sieht).
- mehr CPU-Zeit fuer Farbscrolling (evtl. ist es am Ende sogar noetig deswegen)

Nachteile:
- entweder kleineres Bild, oder man opfert Sprites fuer Leben/Score-Anzeige die dann im schwarzen Bereich neben dem Hauptschirm liegen wuerden.

Edit:
- Der Rotor benutzt 3 Sprites. +1 fuer die Kugel in der Mitte. gerne haette ich fuer die beiden 'Arme' noch ein Overlaysprite. Das sind dann schon 6 + 2 fuer Randabdeckung:
Score/Leben koennte also nur ueber oder unter dem Rotor rechts stehen. Das passt aber auch noch locker.

Vielleicht gibt es dazu ja Meinungen?
Ich tendiere zu 30x20 momentan...

Zitat von Hexworx

Das macht mich nervös

Mich auch
Ich bin eher erstaunt, dass es ueberhaupt SO gut aussieht.
Das obliegt am Ende einem Zusammenspiel von Grafiker und mir jeden Animationsschritt sauber auszurichten.
Das jetzt von Hand zu machen waere nur vertane Zeit.
Das hier ist uebrigens der (schlampige!) Pythoncode fuer die Korrektur-Tables der beiden aeusseren Rotorsprites:

Das ist beim Testen etwas gewachsen und liesse sich enorm verkuerzen/verschoenern. Wie immer ist Zeit knapp
per "prg = False" kann ich die Koordinaten direkt ausgeben und dann durch Gnuplot jagen zum testen.
Rx und Ry separat sowie das bisschen Tuning +/- sind einfach noch uebrig geblieben als ich etwas ganz anderes ausprobiert habe

Zitat von Endurion

Würde man den Spielausschnitt mit 30x20 nicht fast besser horizontal zentrieren? Dadurch geht vermutlich noch ein Sprite flöten, aber nach links gequetscht sieht doch komisch aus.
Als Bonus hat man dann das X-Extend-Bit an der Backe

klar, das waere dann zentriert bei diesem Spiel natuerlich, das mit dem 1 Sprite war eher fuer das Prinzip
MSB der X-Koordinate stoert mich nicht.
Ich glaube nichtmal dass man in den Bereich > 255 kommt? Selbst wenn: das ist ja immer bekannt wann welches Sprite wo ist beim Rotor - das ist ja das schoene wenn der Scroller pixelexakt ist