Posts by ssdsa

    Das Spiel soll ja auf Disk und auch auf Cartridge veröffentlicht werden. Welche Speicherkapazität wird das Cartridge haben? Wird das Spiel auf Disk ein Single-File sein, oder wird es nachladen?

    Mir gefällt sehr gut, dass der Entwickler besonders darauf achtet, dass das Spieler-Sprite und die Gegner-Sprites optisch einen starken Kontrast zum farbigen Hintergrund bilden. So kann man immer gut erkennen, wo die Gegner sind.

    Hier ist ein neues C64-Spiel in Entwicklung, das ziemlich ausgefuchstes Parallax-Scrolling hat und mit besonders vielen weichen Mischfarben aufwarten kann:
    Parallaxian
    https://www.kickstarter.com/pr…e-c64/description?lang=de
    Der Author scheint schon recht weit mit der Entwicklung zu sein. Das Ganze sieht zumindest bereits lauffähig und spielbar aus.
    Er beschreibt das Spiel kurz als 'A stunning "next generation" shoot-em-up-bomb-em-up game for the Commodore 64'.
    In seinem Blog https://kodiak64.com/ erläutert er ausführlich, wie er die Mischfarben erzeugt und welches Vorgehen er beim Sprite-Multiplexing verwendet.
    https://kodiak64.com/blog/luma-driven-graphics-on-c64
    https://kodiak64.com/blog/toggleplexing-sprites-c64
    Tatsächlich ist das Spiel streng genommen nicht "neu", denn der Author hatte bereits in den 90er Jahren mit der Entwicklung begonnen. Damals wollte er dem Spiel den Namen "Colony" geben. Die unfertige Fassung von damals landete schließlich bei "Games That Weren't": https://www.gamesthatwerent.com/gtw64/colony/


    Kickstarter-Ziel: 12.500 GBP (entspricht ca. 14.241 EUR)
    Noch 25 Tage verbleibend

    Die Priorität ist beachtet, zuerst Multi, darüber Hires (zuletzt die AFLI-Pixel, die sind aber jetzt noch ganz hinten).

    Hut ab! Ich glaube, dass das Bild schon fast perfekt aussehen wird, wenn Du die AFLI-Vordergrund-Pixel nach ganz vorne holst. Der Rest sind dann bestimmt nur noch ein paar Kleinigkeiten.

    Aber ich hab schon wieder Schwierigkeiten: Irgendwie haben die Jungs eine geniale Methode, die Sprites zu positionieren, ohne die Positionsregister damit zu belästigen... Da ich kein Demo-Programmierer bin, muss ich da erstmal hintersteigen! Jedenfalls werden für die beiden Bitmaps im NuFli nur jeweils ein einziges Mal (soweit ich das jetzt überblicke) die Spritepositionen ausdrücklich gesetzt (für die oberste Zeile).

    Die Sprites werden durch Sprite-Crunching und Stretching so manipuliert, dass sie 127 Zeilen hoch sind. Die Manipulation geschieht durch mehrmaliges Beschreiben von $D017 zu genau definierten Zeitpunkten. Dies ist erstmals in der Crest-Demo "Krestage 1" (von Roland) genau beschrieben und erklärt. http://csdb.dk/release/?id=2968


    Die Sprite-Y-Positionsregister werden zu Beginn der IRQ-Routine auf den "oberen" Y-Wert #$2B gesetzt und dann, sobald der VIC diese Rasterzeile erreicht hat, auf den "mittleren" Y-Wert #$AA, und dann im Laufe des Speedcodes (ab $1000) auf den "unteren" Wert #$D4 gesetzt. (Dafür sucht der NUFLI-Generator "freie" Stellen im Speedcode, an denen keine Umschaltung der Spritefarben nötig ist, und patcht diese Stellen dann so, dass die Y-Position neu gesetzt wird.)


    Diejenigen Spritedaten, die zwischen Y-Position #$2B und #$AA auf dem Bildschirm zu sehen sind, liegen wild zerwürfelt in vielen Spriteblöcken. Grund dafür ist, dass der VIC in diesen 127 Rasterzeilen beim Anzeigen der Spritedaten immer wieder durch die nur 64 Bytes großen Spriteblöcke läuft. Zur Anzeige des NUFLI Bilds ist es aber nötig, dass in jeder Rasterzeile andere Spritedaten zu sehen sein sollen. Roland hat es geschafft, dieses Ziel zu erreichen, durch das ständige Umschalten der Screenposition via $D018, das ja auch die Lage der Spritepointer mit umschaltet. Die Spritepointer in den verschiedenen Screens sind alle unterschiedlich gewählt. Es ist wirklich ein sehr großes Puzzle.

    Ich fand die Compo auch äußerst gelungen. Es war eine schöne Aufgabenstellung, die viele Teilnehmer (mit Asm und mit BASIC) angelockt hat. Danke für die Idee und die Durchführung!
    Ich würde mir das "Genöhle" nicht zu Herzen nehmen, denn natürlich kann man immer irgendetwas anders machen oder sich für andere Details entscheiden, aber das entscheidende bei einer Compo ist doch, dass es sie überhaupt gibt und das klare Regeln abgesteckt werden - und das ist hier toll gelungen. Vielen Dank dafür!

    Irgendwie irgendwo irgendwann scheint ein Buchstabe meines Usernamens "ssdsa" abhanden gekommen zu sein, hm. Die Buchstaben sind die Initialen meines Namens.
    Hier ist jedenfalls mein ASM-Source (zu "ssda_drehsprite-ssdsa-asm-20170205.prg"):


    Ich hatte bei meinem ersten Lösungsansatz für die ASM Version nach etlichen Optimierungen schließlich auch das Gefühl, dass ich die irgendwie nicht mehr kleiner bekomme. Daher habe ich noch mal neu angefangen mit einem anderen Lösungsansatz, und siehe da: Meine neue ASM Version ist (nach allen Optimierungen) 3 Bytes kürzer als die vom ersten Lösungsansatz. Ist schon irre, wie man nach einer Weile doch immer noch irgendwo ein oder zwei einzusparende Bytes rausschlagen kann.


    Trotzdem kann ich kaum glauben, dass es "eine ASM Lösung mit einer 4 vorne" geben soll. Das ist vielleicht nur ein Bluff, um die restlichen Teilnehmer entweder zu demotivieren - oder aber, um sie weiter zum Optimieren anzuspornen - so nach dem Motto: Wenn man erst mal weiß, dass das Unmögliche doch möglich ist, dann ist es auch nur noch halb so schwer.


    Oder heißt "mit einer 4 vorne", dass die ASM Lösung mit
    4000 SYS2061
    beginnt? ;)

    Ich kann bestätigen, dass es eine BASIC-Lösung unter 100 Bytes gibt. 8)


    Wie man in ASM auf 51 Bytes kommt, ist mir allerdings ein Rätsel.


    Kann ich eigentlich auch zwei Lösungen abgeben, die dann beide am Ende der Compo veröffentlich werden? Ich würde gerne eine BASIC-Version und eine ASM-Version einreichen.

    Aber MIT Doppelpunkten!

    Roland ist Crossbow/Crest, ihm passieren schonmal seltsame Dinge in seinen Programmen. Da war doch mal was in einer Compo vor 5-10 Jahren, wo Xmal fast der ganze Speicher "irgendwie" durchgenudelt wurde. Lief 1000mal länger als die anderen Lösungen, erinnert sich wer?


    Eigentlich war's eine Art "verstecktes" Kompliment. Roland hat doch auch mal einen Sprite-Multiplexer in BASIC(!) gebaut und ist generell recht fit, was den C64 betrifft :)

    Nur so für's Protokoll: Roland ist Crossbow/Crest und hat 2005 in der "Mini Competition für Grid-Problem" am Ende eine extrem kurze Lösung mit ca. 10 Sekunden Laufzeit abgeliefert.


    Der "Sprite-Multiplexer in BASIC" (CSDb release id 91459) ist aber nicht von Roland, sondern von mir: ssdsa = S.E.S./Crest.


    Roland und ich haben allerdings beide schon seit sehr langer Zeit eine Verbindung über das Thema Sprite-Multiplexer. Weiß jemand, welche?

    Quote

    Bitte senden Sie Ihr Gebot an shop@icomp.de. [...] 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.