Hallo Besucher, der Thread wurde 9,3k mal aufgerufen und enthält 66 Antworten

letzter Beitrag von DATA-LAND am

Portierung des Spiels Downfall

    Zitat von Salator

    Die Sprites, ich bekomme momentan zwischen Musik und Charset 32 Blöcke unter. 8 davon gehen für die Spielfiguren drauf: Animation aus 2 Sprites, das ganze gespiegelt, und für den 2. Spieler dasselbe nochmal.

    Ganz generell würde ich bei einem Grafik-Großprojekt wie einem Spiel die Musik nicht unbedingt in der selben VIC-Bank parken wie die Sprites, um Grafik-Platz zu sparen. Natürlich kann man auch hard-coded/pixeled Sprite-Daten aus anderen VIC-Bänken rüberschaufeln, aber unnötig kompliziert. Außerdem bieten sich die Bänke $C000 und $4000 für Grafik eher an als die anderen beiden, wo aus VIC-Sicht das Character-ROM im Weg steht (so dass man gerade dort, genauer: bei $1000/$9000, wiederum ganz gut Musik ablegen kann, ohne potenziellen Grafik-Platz zu vergeuden).


    Und evtl. lohnt sich, Spiegelungen zu generieren statt hard-pixeled/coded abzulegen. Gab hier im Forum mal einen interessanten Fred dazu, den ich mal wieder nicht finde. Den Source habe ich aber noch, frag mich mal, von wem der ist, ich glaube(!) von Spider-J, vielleicht aber auch von mir oder jemand anderem. <-- Edit: alles Käse, war aus Lemon:
    http://www.lemon64.com/forum/v…d33a3017feb511e34065fda57
    Egal, vielleicht hilft es Dir ja


    Zitat

    Zitat von »Salator«
    Die Sprites, ich bekomme momentan zwischen Musik und Charset 32 Blöcke unter


    ...läßt mich vermuten, dass die Musik eh nicht bei $1000 liegt. *ausdemfensterlehn*


    Naja... :D Schau einfach mal in den Code statt zu orakeln, das ZIP-File enthält auch Source ;)

    Jau, sorry, schon gemerkt und Urheber gefunden, sorry, vgl. Edit oben ;)
    <- Edit/Antwort auf Antwort gestrichen wegen Edit in der Antwort oder so


    Der F64 Fred drehte sich damals ums Drehen, nicht ums Spiegeln, vielleicht ja auch für Salator hilfreich
    Sprite drehen

    Zitat von TheRyk

    Naja... :D Schau einfach mal in den Code statt zu orakeln, das ZIP-File enthält auch Source ;)

    Oh ja, klassicher Fall von "Prager Fenstersturz" :rotwerd:
    ...klammerte mich an den Gedanken, die Grafikdaten wären schon unter $d000... Das Gute daran: es gibt noch viel, viel Speicherpotential für viele Level :)

    Also Platzprobleme sehe ich im Moment überhaupt nicht. Wenn ich gestern Andeutungen über die Lage der einzelenen Komponenten gemacht habe, das sind nur die Komponenten die ich derzeit verbaut habe und die direkt an ihrem Ursprungsplatz im Speicher liegen. Passt eigentlich alles schön nebeneinander. Die größten Brocken sind das Koala-Bild mit 10000 Bytes und die Leveldaten mit 9000 Bytes. Der Rest ist dank moderner Cross-Assembler relativ unkompliziert umzustapeln. Ein Fallstrick war bis jetzt nur der VIC mit seinen Adressierungs-Beschränkungen. Ist aber noch lange nicht kritisch, man muss diesen Fakt nur im Hinterkopf behalten und kann sich halt nicht ganz so frei bewegen.


    Sind die 32 Sprite-Blöcke zu wenig für eine vernünftige Grafik? Das wäre das geringste Problem. Die Blöcke müssen ja nicht zusammen liegen, nur für die Playeranimation brauch ich je 4 zusammenhängende. Wobei das eh wieder alles hinfällig ist wenn die Animation aus mehr als 2 Sprites und 2 Richtungen besteht. Derzeit mache ich das nämlich einfach nur durch Adress-Bits umschalten.
    Und mehr als 3 Sprite-Objekte sind nie auf dem Schirm, da wäre auch noch Luft wenn man mit Overlay-Sprites arbeiten will.
    Die Spiegel-Routine guck ich mir mal genauer an, die lässt sich bestimmt verwenden. Und sei es nur, um dem Zeichner die Arbeit zu ersparen. Zur Laufzeit ist es dann aber bestimmt einfacher, die Sprites direkt im Speicher zu haben. Ich muss doch nicht sparen, koste es was es wolle ;)
    Wo die Sammelobjekte letztendlich liegen ist völlig banane. Da erscheint alle paar Sekunden ein neues, das kann auch aus der hintersten Ecke geholt werden.


    Dass die Musik derzeit bei $1000-1a64 liegt habt ihr ja schon selbst gesehen. Wobei das auch keine Vorgabe ist, die Datei war halt gerade an der Stelle. Ich habe beim Durchhören auch $1800 und $8000 öfter gesehen, das müsste sich genauso problemlos einbauen lassen.



    Ach und weil hier der Vorschlag mit mehr Leveln kam, das hatte ich eigentlich nicht vor. Die Daten sind direkt vom Amiga konvertiert. Es gibt 10 Level mit steigender Schwierigkeit, wobei jedes Level 3 Blöcke hat von denen einer zufällig gewählt wird. Danach beginnt die Sache von vorn. Dazu kommen noch die Sammelobjekte. Ich denke das ist ausreichend Abwechslung.

    Zitat von Salator

    Sind die 32 Sprite-Blöcke zu wenig für eine vernünftige Grafik?

    Naja, theoretisch sind 256 möglich(!) pro Bank. Allerdings auch nur, wenn man keinen Platz mehr für sonstige Grafik haben will. Ich habe Deinen Code jetzt auch noch nicht superintensiv studiert, denke aber einfach mal, Du hast bereits Bank $4000 oder $C000 aktiviert und gehst von 8kB für Sprites und 8kB für sonstiges (Font/Screen/Bitmap/was-weiß-ich) aus. 32 ist schon okay, reicht evtl. sogar für manch simple Animation.

    Zitat von Salator

    Die Spiegel-Routine guck ich mir mal genauer an, die lässt sich bestimmt verwenden. Und sei es nur, um dem Zeichner die Arbeit zu ersparen.

    Wenn's nur um letzteres geht, dass kostet den Künstler oder Dich lediglich einen Mausklick in einem Crossdevelopment-Tool (z.B. SpritePad hat X/Y-Flip IIRC).

    Zitat von Salator

    Dass die Musik derzeit bei $1000-1a64 liegt habt ihr ja schon selbst gesehen. Wobei das auch keine Vorgabe ist, die Datei war halt gerade an der Stelle.

    Wie oben gesagt, dort liegt sie gut, eben weil(!) der VIC an der Stelle ohnehin blind ist/nur CharROM sieht.

    Zitat von Salator

    Ich habe beim Durchhören auch $1800 und $8000 öfter gesehen

    $1800 ist eher selten, default für Future Composer IIRC, nutzt kaum noch jemand. $8000 finde ich eigentlich unpraktisch, wenn, dann wäre $9000 zu bevorzugen (praktisch das $1000 dieser Bank aus Sicht des VIC). Hoffe, das war nicht zu verwirrend.


    Nachtrag/Wow:
    http://csdb.dk/release/?id=118185
    Hoffe für den Fortgang des Projekts sehr, dass das mit Dir abgesprochen wurde bzw. Du Dich darüber nicht ärgerst. Ich hätte ja (wenn schon PD Sachen 'cracken') wenigstens auf die Vollversion gewartet und da dann auch wirklich noch was dran gemacht außer Intro, aber egal, kann nur orakeln, dass es um First Release Stats geht, ansonsten macht das so wenig Sinn. Einerseits ist sowas mittlerweile fast normal/vorhersehbar und ein Grund, warum ich von meinen unfertigen/WIP Spielen grundsätzlich keine Previews release/ins Netz stelle, andererseits kann man es auch einfach als schmeichelhaft abhaken unter: Any publicity is good publicity. :rolleyes:

    Zitat von TheRyk

    http://csdb.dk/release/?id=118185

    *PRUST* Also ich hab ja damit gerechnet dass sowas kommt, aber noch nicht zu diesem Zeitpunkt...
    Das setzt mich nu natürlich weiter unter Druck, die Sache zuende zu bringen. So ein halbfertiges Ding kann doch nicht in der Sammlung bleiben...

    Zitat von Salator

    nur für die Playeranimation brauch ich je 4 zusammenhängende

    Selbst die sind nicht zusammenhängend nötig. Es reicht einfach eine Tabelle mit den Sprite-Pointern, dann kannst du wahllos zwischen den Sprites springen...


    Zitat von Salator

    Ach und weil hier der Vorschlag mit mehr Leveln kam, das hatte ich eigentlich nicht vor. Die Daten sind direkt vom Amiga konvertiert.

    Wär´ doch cool, wenn die C64-Version (wieder einmal) mehr bietet als die Amiga-Version ;)


    Zitat von TheRyk

    http://csdb.dk/release/?id=118185
    ... und ein Grund, warum ich von meinen unfertigen/WIP Spielen grundsätzlich keine Previews release/ins Netz stelle,

    Das habe ich auch gerade gelernt...


    @Salator:Gratulation zu deinem Crack ! ;)

    Zitat von Squidward

    Ich persönlich hab immer das Problem, dass mir dann irgendwann die "1.Draft"-Grafik so ans Herz gewachsen ist, dass ich sie nicht mehr ändere.


    Ein Trick aus der Spieleentwicklung um dem entgegen zu wirken: Die Grafiken absichtlich so dermassen schlecht machen, dass einem später keine andere Wahl bleibt, als dass sie noch einmal neu gemacht werden müssen. Ansonsten bleiben immer irgendwelche Sachen übrig, die eigentlich nur als Platzhalter gedacht waren :)

    Zitat von TheRyk

    Und statt in der Summary zu schreiben:

    hätten die das jawohl zumindest mal schon mal erledigen können :D


    Hätt ich das mal letzte Woche gewusst hätte ich mir die Arbeit sparen können *g*
    Highscoresaver ist inzwischen drin


    Dafür hab ich den heutigen Tag mit einem Credits-Screen verplempert. Als ob ich nix wichtigeres zu tun hätte...

    Aktueller Testreport:


    Bugs:
    Der Levelzähler ist kaputt, es wird die falsche Stelle hochgezählt: 001, 011, 021, ...
    Wenn man ein Spiel ohne neuen High-Score beendet, findet dennoch irgend ein Diskzugriff statt.


    Nice-to-have:
    Der 2-Spieler-Modus wird hoffentlich Simultanspiel erlauben?
    Werden Up/Down/Firebutton noch irgend eine Funktionalität bekommen? Wenn die Figur springen könnte, wären nicht so viele Extras unerreichbar. Und falls es einen 2-Spieler-Simultanmodus gibt, könnte man über gegenseitiges Anrempeln nachdenken... :whistling:


    Sonstiges:
    Der Levelzähler ändert sich, sobald Ebenen des neuen Levels auf dem Bildschirm auftauchen. Ist es evtl. sinnvoll, die Zahl erst dann zu ändern, wenn die Figur den neuen Bereich erreicht hat?
    Um hilfreichere Bugreports schreiben zu können, sollte irgend eine Art von Versionsnummer/Releasedate/whatever angezeigt werden.


    Weitermachen! :thumbup:

    Levelzähler wird korrigiert. Da hatte ich mal die Text-Position verschoben.
    Disk-Zugriff muss ich mal gucken, is mir gestern auch aufgefallen. Spontan sehe ich die Ursache nicht.
    Versionsanzeige, hm, hat ACME dafür ne Automatik? Ansonsten müsste ja auch das Datei-Datum dafür nutzbar sein.
    Bevor der 2-Spieler-Modus kommt will ich erstmal die Kontrollen für 1 Spieler fertig haben. Mir ist nämlich nicht klar wie ich in ASM Funktionen hinbekomme die für beide nutzbar sind, also wirds auf Code kopieren hinauslaufen.
    Der 2-Spieler-Modus wird simultan sein. Als Extra gibts dann auch die Schneeflocke, die den anderen für 2 Sekunden einfriert. Ich hab leider niemand zum Testen hier und kenne auch die Amiga-Version nur vom 2-Joysticks-gleichzeitig-drücken.
    Dass die Figur nicht springen kann - keine Ahnung ob es an der dann komplizierteren Steuerung liegt. Mir kommt dieser Umstand zumindest entgegen, und man ärgert sich ja auch viel mehr wenn so ein Bonus unerreichbar ist, bzw versucht dann risikoreiche Flug-Aktionen.
    Die Level-Umschaltung müsste ich mal beim Amiga angucken wie das dort gelöst ist. Ich halte das aber für vernachlässigbar, für die gelegentlich mal 100 Punkte zuviel müsste ich die ganze Steuerung anders machen. Derzeit nutze ich nämlich die Kollisionsregister und weiß programmtechnisch gar nicht wo sich die einzelnen Objekte gerade auf dem Screen befinden.


    Und dann hätte ich mal noch ne Frage zu dem
    lda #$e0 ;Joystick-Eingänge schalten
    sta $dc02
    Dieser Code kommt aus der Joystick-Abfrage im C64-intern-Buch (dort allerdings Basic-Code). Wofür ist das nötig? Außer Tastatur blockieren kann ich keinen Unterschied erkennen wenn ich das weglasse. Und die Tastatur soll ja möglichst nicht blockiert werden.

    Das kommt darauf an.


    Kann mir vorstellen, dass Handbücher und Tutorials empfehlen, vor Joystickabfragen Tastatur auszuschalten, um zu verhindern dass die Tastatur zwischen die Abfrage funkt.


    Stichwort: sich kreuzende Leiterbahnen von Tastatur und Joysticks Richtung CIA. Steht hier genauer erklärt bei Bedarf:
    http://www.c64-wiki.de/index.php/Tastatur

    Zitat

    Und dann hätte ich mal noch ne Frage zu dem
    lda #$e0 ;Joystick-Eingänge schalten
    sta $dc02
    Dieser Code kommt aus der Joystick-Abfrage im C64-intern-Buch (dort allerdings Basic-Code). Wofür ist das nötig? Außer Tastatur blockieren kann ich keinen Unterschied erkennen wenn ich das weglasse. Und die Tastatur soll ja möglichst nicht blockiert werden.


    um die tastatur abzufragen wird ein port auf ausgang und der andere auf eingang gestellt, dann im ausgangsport bits gesetzt und am eingangsport geguckt was ankommt. (tastatur verbindet über die matrix ausgangsport mit eingangsport) um die joysticks abzufragen muss der port der abgefragt werden soll auf eingang stehen (joystick verbindet eingangsport mit masse)