Preview gibt's schon von Laxity: https://csdb.dk/release/?id=213958
Posts by mrsid
-
-
Ist Mikkel Hastrup hier angemeldet? Kann sich auch ein paar Lorbeeren abholen. Die Umsetzung ist irre gut gelungen.
Darf man wissen, welchen Tracker er verwendet?
Ich glaube das er Mangels Deutschkenntnissen sich nicht hier rumtreibt, aber ich kann mich täuschen... Er hat GoatTracker verwendet.
-
mrsid was mich interessieren würde:
Wird auch die Swap Funktionalität der REU genutzt?
Ja.
-
Meine zweite Frage wäre wo ist der Einsprungspunkt im Spiel (sonic 1v2) wo der VIC (rasterIRQ, D018 usw) und CIAs auf richtige Werte gesetzt werden.
$07ff setzt das voraus und 03F8 crashd nach dem entpacken des Spiels.
Das wird so nicht funktioneren. Der Einsprungspunkt ist bei $0340, aber der Code der das Spiel initialisiert wird später mit anderem Code überschrieben, aus Platzgründen. Damit wirst du also nicht weit kommen. Du müsstest das Hauptprogramm entpacken, patchen und neu packen.
-
Ja, natürlich. Verwende jetzt seit ein paar Tagen die neue 3.6.1 version von VICE, und bin sehr happy damit...
-
Wenigstens paar stichworte so Braindumping ? Welche Tools ?
Selbst gemachte Tools um Daten zu konvertieren...
-
Könntest du mal ein Interview machen auf Deutsch wie das mit der Toolchain funktioniert.
Nein, keine Lust.
"wie hat er all das im Vice und ACME gemacht und vorallem getestet?"
Ganz einfach nicht ACME verwendet...
Am Ende war das Programm weit länger und 5x langsamer geworden... Schade
müsste noch ein Optimizer bauen aber das ist mega Zeitaufwändig...
Drum hab ich's gleich von Hand gemacht.
-
Wär super, wenn du für dein nächstes großes Projekt eine Kameracrew dabei hättest, die das alles dokumentiert.
Und die sitzt dann immer abends hier bei mir auf der Couch, oder wie?
-
Danke Mr. Sid. - Was ich seit gestern gesehen habe ist das nicht nur das Coolste Spiel am C64 auch eines der komplexesten.
Aus meinem kleinen test -> "gehts am NeoRam?" ist ganz schön viel arbeit geworden ...
Bastel noch am REU Emulator. Stress mit pagegrenzenüberschreitung... was mich am meisten wundert ist warum mein Level immer bei dem Totem beginnt (bei der Kugelrinne) seit ich meinen Emulator verwende. Wenn ich auf 03f8 springe beginnt das Spiel wieder dort ?
wo weiß das Spiel welchen Scrollschirm der Sonic aktuell ist ? Würde gerne ganz links im 1. Schirm beginnen...
und was macht der 9c00 Bereich genau ?Du hast wahrscheinlich die Start position von Sonic überschrieben...$a00d/$a00e ?
Bei $9c00 liegt eine Tabelle mit den Lo-Bytes für jede Zeile in der REU. Bei Levels die 256 Blöcke breit sind (z.b. Level 1) sind dort nur 00er, aber in anderen Levels schaut das anders aus. D.h. nicht unbenutzt.
Und ja, das Spiel ist sehr gross und komplex. Ich hab mir eine komplett neue Toolchain basteln müssen, damit ich die Datenmengen gut managen, konvertieren und verwalten kann. Sonst hätt' ich da nicht die Übersicht behalten können...
-
Grad einen freien Platz bei 9c00 gefunden 256 byte... und gleich nach sterben wird der Bereich aus dem Georam überschrieben grrrr !
Dort liegen Tabellen. Wie gesagt, es ist fast kein Platz. Der Bereich bei $a000 ist die Levelbeschreibung. Bei weniger Gegnern im Level ist dort ein wenig Platz, aber auch nicht wirklich. In manchen Levels ist das weniger.
Der einzige Ort den ich noch nicht verwendet hab ist der untere Teil vom Stack. Ich denke der wächst nicht sehr weit nach unten, d.h. von $0100 bis ca. $01c0 oder so sollte frei sein.
-
Also mal eben 12.000 Zyklen (von den ca. 19500 eines Videoframes), wenn der gesamte Bildschirminhalt ausgetauscht wird, also beliebig schnelles Scrolling (Transportation).
Was aber die Frage offenlässt, wie viel Zeichen man im Worst-Case wirklich schreiben müsste.
Nicht mal Sonic scrollt so schnell, dass wirklich der gesamte Bildschirminhalt von einem Frame zum nächsten mit Hardwarescrolling neugefüllt werden müsste (dann könnte man im Prinzip gar nicht mehr nachverfolgen, wohin eigentlich gescrollt wird.)
Guckst du:
-
624f-6271 ist die Scroll x Reu Routine (!) Also doch noch gefunden das beast
Nein, das hat nix mit dem Scrolling zu tun. Da wird in $cc00 kopiert... Ausserdem würde ich mal die 1.2 version vom Spiel runterladen, da hat sich alles ein wenig verschoben...
-
Hier ein Beispiel Frame:
Weiss ist Update der Game Entities, also in dem Fall Sonic, der Crabmeat Gegner, der Monitor und die Plattform (da sind auch Interrupts dazwischen, z.b. vom Multiplexer und für die Musik, etc.).
Rot ist das HUD (in diesem Frame ändert sich keine Zahl, d.h. fast nix zu tun).
Cyan ist Sprites updaten und sortieren.
Grün ist Screen Update, also kopieren von REU. Dazwischen sind aber Interrupts vom Multiplexer und dergl.
Blau ist Charset Update, d.h. kopieren von Animationen aus der REU
Gelb ist das Kamera Update.
Lila ist der Check welche Entities im nächsten Frame aktiviert werden müssen, bzw. welche deaktiviert werden können.
-
Als DAU/noob kann ich da zwar nicht mitreden, aber da es ja etliche GEORam Nachbauten, Originale und NeoRAM's gibt, wäre so eine "Portierung" ja schon ne feine Sache - was könnte man denn ggf. machen (Abstriche zur REU-Portierung), um es doch per Neo/GEO-RAM zum Laufen zu kriegen?
Lass dich nicht von dem hier irritieren. Ich würde mir da keine Hoffnung machen...
-
Display More
Nur mal so aus Interesse...
Der REU-Transfer zum Scrollen (Teleportieren) ohne Farben dauert ja im Prinzip nur so um die 1000 Zyklen (plus Badline- und Sprite-DMA).
Was passiert in den restlichen knapp 18500 Zyklen eines PAL-Frames?
(Die REU kann vermutlich nicht direkt ins Farb-RAM schreiben, oder?)
Ja klar kann sie ins FarbRAM schreiben (kann ja auch in I/O schreiben, z.b. $d418).
Allerdings kann das nicht in einem Transfer passieren, d.h. es wird zeilenweise geschrieben, und zwar abwechselnd Video und Farb RAM (damit man immer vor dem Rasterstrahl bleibt, weil oft beginnt das erst kurz vor Rasterzeile 50). Nach jeder Zeile müssen einige Register neu gesetzt werden, dadurch wird etwas an Bandbreite verbraten.
Der grösste Teil ist allerdings die Logik von Sonic und den anderen Entities, gerade wenn mehrere davon sichtbar/aktiv sind, braucht das gut mehr als ein Drittel vom Frame, u.U. mehr wenn die Gegner alle auch mit der Welt kollidieren können.
Dann natürlich noch das übliche wie Sprites sortieren, Musik, die REU transfers für die Sonic Sprites, das Zeichnen von Zahlen in die HUD Sprites, das Kamera Update (Bewegung, Interpolation, Clipping, etc.), die Entity Aktivierung/Deaktivierung, die Charset Animationen von Wasser und dergl.,
-
ja der Code ist nicht optimiert ich weiss, war ein test zu schauen ob es mit georam auch geht- aber warum geht das Links / Rechts Scrolling eigentlich nicht ? Was ist da anders ? werden die Screens nicht per Index Variable (0 - ff) in den Videoramgeladen wobei der Index angibt in welcher spalte vom Bild wir beginnen ?
Nein, wozu eine Index Variable? Die REU schreibt ja direkt ins Video RAM, also braucht man das nicht. Das liegt alles in der Berechnung der Adressen in REU und C64 RAM. Und wenn du immer 256 Bytes kopierst, wirst du irgendwo was überschreiben. Und es gibt REU Transfers die länger als 256 Bytes sind, d.h. du musst das ganz anders machen. Und natürlich wird auch in die REU geschrieben, d.h. wenn du das nicht machst wird gar nix lange funktionieren... Wie gesagt, das ganze ist sinnlos, aber viel Spass noch.
-
Display More
Dein Spiel is so cool das ich es schade finde das man eine Reu braucht und meine ist noch nicht fertig weil ich den Fehler nicht finde.
ich teste georam Port - dazu einen reu auf georam treiber und habe im moment einen Platz bei $a080 gefunden.
im Moment geht das Scrolling auf und ab aber nicht links/rechts keine Ahnung warum. Habe aber noch nicht alle sta DF01 gefunden...
ich biege $1166,$1167 im Moment.
Habe eine volle REU (gesamtes Spiel geladen) 512K weggespeichert und lade sie als GEORAM.bin (512K)
ich bin davon ausgegangen das die Levels zeilenweise im REU liegen und ein teil (der Sichtbar ist ) in den videomem $c800 gefetcht wird.
Hoffe nicht das Store (b1) benötigt wird. mein Treiber kann im moment nur lesen...
im Archiv ist der Vice Snapshot der das Sonic im aktuellen Moment darstellt... (samt Treiber und einigen Patches bei $1100-11ff)
So ein Blödsinn... Wie stellst du dir vor das das dann funktioniert, wenn das Spiel jetzt schon fast keine Rasterzeit mehr frei hat?
Die Kopierschleife in georamreu.asm wird dafür nicht ausreichen, d.h. 25fps vielleicht. Und der Code kann aber noch kleiner sein, da verschwendest du etliche Bytes...
-
Wo habe ich im Speicher noch platz für 192 bytes ? egal wo ich schaue alles wird anscheinend permanent überschrieben....
Habe bei 0200, 8800,e040 usw probiert keine chance.
Wozu brauchst du 192 bytes? Es ist praktisch nix frei, also das wird schwierig. In der REU ist noch ein wenig Platz, da kann man evtl etwas hin- und herkopieren, aber das ist eher kompliziert...
-
-
