Posts by ssdsa

    Quote

    Bitte senden Sie Ihr Gebot an [email protected]. [...] Falls Sie mehrere Gebote abgegeben haben, werden wir das jeweils Letzte, nicht das Höchste auswerten.


    Hm, die Absenderangabe einer Mail lässt sich bekanntlich fälschen. Ich hoffe nur, dass jetzt nicht besonders kriminelle Interessenten einfach kurz vor Schluss die Gebote Ihrer Mitbieter heimlich nach unten korrigieren. :bgdev

    Könnte hier dran liegen:

    Code
    1. 8ad6 A9 17 LDA #$17
    2. 8ad8 8D 0E DD STA $DD0E
    3. 8adb 8D 0F DD STA $DD0F


    Demnach sollte jeder folgende Unterlauf von CIA2 Timer A/B PB6/7 zwischen lo und hi umschalten. Das die Watchpoints im Emu da nicht anschlagen ist auch verständlich.


    Ist vermutlich einfach Schludrigkeit gewesen, bei CIA1 wär das evtl. eher aufgefallen weil die Tastatur u.U. nicht mehr wie erwartet funktioniert hätte.


    Klasse, gut kombiniert! Boulder Dash nutzt ja beide CIA2 Timer, um daraus dann mit EOR & Co. "echte Zufallszahlen" zu ermitteln. Diese Zufallszahlen werden allerdings nicht beim Generieren der Caves verwendet, sondern nur für Aspekte wie das "schwergängige" Schieben von Steinen.

    Damit das für die Leser keine blanke Theorie bleibt, habe ich hier mal unseren QR-Code-Screen angehängt. (Ich habe da natürlich wieder unnötig lange dran herumgepixelt – aber der Code sollte sich ja in die restliche Umgebung harmonisch einfügen.) ;)


    Normalerweise würde der Link auf die Monster Buster Scores-Seite bei P1X3L.NET zeigen und den Score als URL-Bestandteil übertragen aber da das natürlich alles noch nicht ganz fertig ist, habe ich erst einmal einen Dummy-Link erzeugt.


    Wow, ich finde echt klasse, dass Ihr QR-Codes erzeugen wollt. Ich habe so etwas auch mal überlegt und wollte es ursprünglich in mein Spiel "Match Buster" einbauen, aber ich habe den Gedanken damals recht schnell wieder verworfen, weil ich davon ausging, dass die dafür nötige Programmcode-Menge auf keinen Fall mit in meine 16K passen würde. Ich bin gespannt, wieviel Speicher Euer Programmcode zum Erzeugen der QR-Code belegen wird.

    Ah! Es liest hier also doch jemand mit ;-)

    Aber natürlich! Ich find's richtig klasse und sehr gut und verständlich beschrieben.


    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.

    OK, hier muss ich der Vollständigkeit halber anmerken: Doch, man kann das Hardwareregister $D016 auch mitten in der Zeile ändern und die Änderung wird sofort wirksam. Wenn man also in jeder Rasterzeile das Hardwarescrollregister $D016 zweimal beschreiben würde, könnte man damit theoretisch auch die linken 30 Chars soft scrollen und die 10 rechten Chars fest stehen lassen. Das kostet aber so viel Rechenzeit, dass es in einem Spiel nicht sinnvoll nutzbar ist.

    In vielen Threads um Beschreibungen von euren Lieblingsspielen wird immer wieder Rockman als Boulder Dash-Version für den C-16 erwähnt.
    [...]
    Mittlerweile bin ich der Meinung, diese Einordnung ist falsch.
    Bin mal auf eure Meinung dazu gespannt.


    Das sehe ich auch so. Ich verstehe aber, dass es oberflächlich betrachtet in dieselbe große Schublade wie Boulder Dash gesteckt wird, weil es halt Felsen, einsammelbare Diamanten, Erde, Wände und Gänge hat. :roll:


    Für den C-16 Plus/4 sind auch andere Boulder-Dash-orientierte Spiele erschienen, kommerziell und auch innerhalb der Szene.
    Es wurde auch mal einige Versionen von Boulder Dash konvertiert, aber perfekt ist in meinen Augen was anderes. Alles zu finden hier:
    http://plus4world.powweb.com/sl.php?o=1&ptid=113


    Oh, die dort zu findenden Versionen von "Boulder Dash" und "Boulder Dash 2" sind aber doch ziemlich perfekt, oder? Ich wusste gar nicht, dass der Plus/4 so gute Grafikfähigkeiten hat, denn das Scrolling ist doch in alle Richtungen flüssig und sanft und im Gegensatz zur C64-Version ist nicht mal ein dicker schwarzer Balken zwischen Punkteanzeige und scrollendem Spielfeld.

    Ja wird sich zeigen, das Cartridge-gefriemel kommt am Ende :-\. Ich weiß nicht, ob das Compilat dann noch den Basicinterpreter braucht (z.T. vlt.) aber man kann die cartridge ja abschalten, erst sobald alles an seinen Platz ist im Speicher, soweit ich weiß und dann ist Basic und Kernal wieder verwendbar vom Prg. .

    Diese Annahme würde ich an Deiner Stelle am besten als Erstes prüfen. Ich dachte, bei den RGCD-Cartridges hat man 16K ROM ($8000-$BFFF), und wenn man das via $01 abschaltet, dann hat man dort ($8000-$BFFF) stattdessen RAM, also kommt man niemals an das BASIC-ROM.

    Was für den umgekehrten Fall ebenso gilt.


    Ich setze hier mal ein Preisgeld von 100 Euro aus, für den, der ein altes (bereits existierendes) BASIC-Programm findet, das an genau diesem Punkt scheitert und nachweislich nur daran. Dieses Preisgeld gilt für 6 Monate. Viel Glück.

    Ich habe sehr gehofft, dass mein BASIC-Spiel "4k-BASIC-Dash" mit gepatchtem BASIC-ROM die Steine oder Diamanten in den Levels anders zufällig verteilt als mit Original BASIC-ROM, und unter diesem Aspekt habe ich das Spiel jetzt bis zum Level "F/2" zweimal parallel (einmal mit gepatchem BASIC-ROM und einmal mit Original BASIC-ROM) gespielt. Leider gab es dabei bis dahin keine Unterschiede. Noch mehr Levels doppelt durchzuspielen, habe ich jetzt keine Lust mehr. Schade, die 100 EUR hätte ich gerne genommen. :)

    Ich werde am 24.12. wohl keine Gelegenheit haben, hier im Forum etwas zu schreiben oder hochzuladen. Meine 6 Beiträge (3 für C64 und 3 für C128) und eine Beschreibung dazu sind aber alle in der Datei "simonstelling.d64" in dem ZIP-Archiv (siehe Post #97) enthalten. Vielleicht kann einer von Euch diese Datei dann am 24.12. hier der Vollständigkeit halber hochladen?

    Um das Charset nur bei $1000 einzublenden, müsste man in Hardware die beiden Adressleitungen A15 und A14 in der Logik berücksichtigen. Um es bei $1000 und $9000 einzublenden, muss man nur A14 berücksichtigen. Man braucht also ein Logik-Gatter weniger. Vielleicht war das der Grund?

    Wegen VSP/FLD, ich glaube, ich habe eher einen FLD-Effekt. Sprich, wenn alles verrutscht ist, ist die unterste Scrollfeld-Zeile nochmal darunter in der Display-Anzeige zu sehen. Wenn ich richtig begreife (ich begreifstutze grade so schön), dann sollte ich mit dem FLD-Effekt die Anzeige komplett eine Zeile tiefer erzwingen?

    Ziel sollte sein, die feststehende Score-Anzeige immer mit YSCROLL=7 darzustellen.
    Wenn der obere Scrollbereich mit YSCROLL=7 so weit wie möglich per Soft-Scrolling nach unten gescrollt ist, dann kann die feststehende Score-Anzeige direkt (ganz ohne Lücke) daran anschließend dargestellt werden.
    Wenn der obere Scrollbereich mit YSCROLL=N (wobei N<7) weniger weit per Soft-Scrolling nach unten gescrollt ist, dann muss Du dafür sorgen, dass genau N Pixelzeilen Abstand zwischen dem Scrollbereich und der feststehenden Score-Anzeige sind.
    Bei N zwischen 4 und 6 machst Du es so: 1-2 Rasterzeilen vor dem Ende des aktuell sichtbaren Scrollbereichs schreibst Du 7 nach YSCROLL.
    Bei N zwischen 0 und 3 machst Du es so: 1-2 Rasterzeilen vor dem Ende des aktuell sichtbaren Scrollbereichs schreibst Du zunächst den Wert (N+4) nach YSCROLL. Anschließend, so 2 Rasterzeilen nach dem Ende des aktuell sichtbaren Scrollbereichs, schreibst Du 7 nach YSCROLL.
    Ist das so verständlich?

    Folgendes bringt vielleicht die meiste Ersparnis:


    12x dieses Code-Stück wiederholen:

    Code
    1. ldx _scrBuf,y ; --- char
    2. lda _chrCol,x ; --- color
    3. sta _colBuf,y
    4. sta _colBuf,y ; -- das "+40" ist hier absichtlich weggelassen

    Dann in der Init-Routine nur noch die jeweils nötigen Offsets (+0, +40, +80, usw.) auf die Adressen draufaddieren. Da Du exomizer und prepack6502 verwendest, müsste sich das 12x wiederholte Code-Stück ganz prima komprimieren lassen. Es kommt halt drauf an, wie kurz Du die Init-Routine hinbekommst.