Hello, Guest the thread was viewed417k times and contains 2256 replies

last post from Mephisztoe at the

Heute so gecodet...

    Irgendwann letzte Woche fiel mir auf, dass ich ja noch nie 'n "stable Raster" geschrieben habe. Das ging mir die ganze Zeit nicht aus dem Kopf. (Während an anderer Stelle über einen Mode-7 mässigen Racer diskutiert wird :emojiSmiley-22:) Heute war dann mal Zeit!

    Theorie... alles bekannt, aber halt noch nie mit rumgefummelt. Dieses mal habe ich mir Turbo Macro Pro genommen und direkt auf richtiger Hardware gefriemelt. Für sowas echt super spassig!

    Dabei ist folgender NMI Handler abgefallen, den ich ziemlich hilfreich finde um per RESTORE einfach wieder in den TMP zu springen:



    Auch keine Raketenwissenschaft, aber vielleicht kann es mal jemand gebrauchen.


    P.S.: Ich mag codebase64.org :emojiSmiley-173:

    Ist jetzt nicht direkt Commodore-relevant, aber im Kontext "Heute so gecoded":


    Seit knapp einem Jahr arbeite ich an einer Artikelserie für ein deutsches Fachmagazin (print und online), die sich mit dem Thema "Spiele-Entwicklung für Beginner" auseinandersetzt.


    DASS ich so etwas machen wollte, wusste ich schon seit langer Zeit. Allerdings war ich lange auf der Suche nach einer Spiele-Idee, die nicht all zu umfangreich ist und sich zugleich auch mit eingeschränkten Mitteln umsetzen lässt. An dieser Stelle wird es doch kurz Commodore-relevant. :)


    Ich habe hier die beiden Werke von Derek Morris liegen (RetroGameDev). In der C64 Edition (Vol1 und Vol2).

    In Vol1 zeigt Derek, wie er ein C64 Spiel entwickelt, bei dem Du einen Barman an einer Beachbar spielst, der Getränke verteilt.

    Der Clou dabei: Es gibt insgesamt vier Bildschirme; auf einem ist die Bar zu sehen, auf einem weiteren sind Strandliegen. Das Ziel: So schnell wie möglich die bestellten Getränke servieren und auf Nachfrage Handtücher zu den Liegen bringen. Das Problem: Die Getränke gehen aus und die Handtücher auch. Die Lösung: Auf den anderen beiden Bildschirmen gibt es neue Getränke und neue Handtücher... die Herausforderung: Auf eben jenen Bildschirmen laufen Krebse herum, die Dich daran hindern, Nachschub zu holen.


    Ich wollte das Spiel immer schon nachbauen mit Hilfe des Buches... bin aber nie dazu gekommen.


    Zurück zu der Artikelserie: Ich habe das Konzept nun übernommen und angepasst. Das Setting - passend zu dem Verlag, der das Fachmagazin veröffentlicht - ist eine Entwicklerkonferenz. In den Pausen zwischen den Vorträgen besuchen die Teilnehmenden der Konferenz die Lounge, um sich dort mit Kaffee und Energydrinks zu erfrischen. Deine Aufgabe ist es, sie zügig damit zu bedienen und, sollte der Vorrat zur Neige gehen, Nachschub zu organisieren.

    Tatsächlich ist es langfristig noch der Plan, dass in der Vorratskammer Staubsaugerroboter herumfahren und damit im Weg sind. ;)


    Das Spiel entwickle ich mit dem MonoGame Framework in C# - from Scratch. Nix Unity. Nix Unreal Engine. Nix GoDot. Einzig MonoGame.Extended habe ich mit reingeholt. Und die Assets stammen praktisch ausschließlich aus den kostenfreien Asset Packs von Kenney Vleugels. Die Musik stammt vom gleichen Künstler wie die Soundeffekte und die sind alle ebenfalls CC0 und somit frei verwendbar. Für die Maps nutze ich das Programm Tiled und für die Sprites das Programm Asesprite. Letzteres kostet ein paar Euro; es gibt aber auch kostenfreie Alternativen.


    Veröffentlicht wurden bereits 5 Artikel, die sich im Schnitt auf etwa 10 DIN-A4 Seiten je Artikel einpendeln. Der sechste kommt mit der Ausgabe im November, der siebte einen Monat später und der achte Artikel ist gerade im Entstehen. Neun sind insgesamt (fest) geplant.


    Das, woran ich bisher besonders Spaß hatte, waren diese vier Themen:

    1. Die Frage danach, ab wann sich das Programm (!) eigentlich anfühlt wie ein Spiel!

    2. Der Aufbau und die Struktur der Finite State Machine, die die NPCs steuert.

    3. Die Unterstützung für den Player, beim Laufen um Ecken herumzugleiten.

    4. Einfache "Spezial-Effekte" wie z.B. der flackernde Lichtschein einer Fackel an der Wand.


    Zwar passt eine Fackel optisch nicht so sehr in das Setting... aber in Kenneys RPG Asset Packs gibt es leider keine normalen Büro-Lampen, lol.


    Für den Lichtschein habe ich gerade erst herausgefunden, wie das gut umsetzbar ist. Ich dachte zunächst an PixelShader.. allerdings ist das für meinen Zweck mit Kanonen auf Spatzen geschossen.

    Statt dessen gibt es jetzt eine Lichtkegel-Textur (die ich ebenfalls in einem Asset Pack von Kenney gefunden habe!) und ein Rendertarget mit passender Blend-Operation. ;-)


    Hier gäbe es mal ein Video vom Spielverlauf:

    [External Media: https://youtu.be/C307n32YYhw?si=6ell1NMm8vFItgKb]


    Dass Getränke ausgehen und nachgefüllt werden müssen, ist noch nicht enthalten.

    Außerdem habe ich noch vielfältige Ideen, die noch mit einfließen werden; allerdings muss jetzt erst einmal der achte Artikel fertig werden; es ist nicht mehr viel Zeit bis zum Abgabetermin..


    Besonders interessant:

    Es ging mir auch immer darum, dass auf dem Bildschirm viel "los" ist. In der Tat wuseln während des Spielgeschehens unzählige NPCs herum.

    In der Realität aber gibt es nur sieben NPCs. Und bloss drei davon kommen zur Theke und bestellen etwas.

    Der Trick ist, dass die bestellenden NPCs sich entweder an einen Tisch begeben, sobald sie das richtige Getränk bekommen haben oder direkt beleidigt rauslaufen, falls man sie vergessen hat oder ihnen das falsche Getränk gibt.

    Die anderen vier NPCs laufen entweder durch den Bildschirm einfach durch, oder schauen kurz rein... oder stöbern durch das Bücherregal... ein NPC steht die ganze Zeit nur an einem der Tische.

    DAS und die Tatsache, dass bei jedem Neudurchlauf der WayPoints sich das Aussehen des jeweiligen NPCs zufällig (aus fünf Sets) entscheidet + sich dessen Tshirt-Farbe zufällig ändert, erweckt den Eindruck von einer ganzen Menge NPCs, die da unterwegs sind. ;-)


    Naja... es gäbe noch eine Menge mehr zu erzählen, aber ich will nicht nerven, lol.

    Coole Story :thumbsup:

    Nicht gecodet, eher der umgekehrte Weg: die PAL Version von Space Invaders für Atari 2600 durch den Disassembler gejagt.


    Ich konnte auf die Schnelle kein Disassembly im Netz finden, also durch ein Online-Tool aufgedröselt. Jetzt habe ich ein schönes Puzzle vor mir liegen, in das es Sinn einzubauen gilt. Bekannte Adressen sind bereits durch Labels ersetzt, fehlen also "nur" aussagekräftige Bezeichnungen für die wirren Labels und Kommentare.

    Quote from oobdoo

    Berichte mal davon. Wird interessant sein zu hören, mit welchen Tricks gearbeitet wurde, wenn es um den Hauptspeicher geht. :)

    Die vielen Sprites sind auch getrickst :)

    Das wird eine ganze Weile dauern, bis das irgendwann mal fertig ist.

    Quote from atomcode

    Was hast Du dann damit vor?

    In erster Linie ist das einfach nur für mich.

    Mich interessiert halt, wie das mit den Restriktionen des Ataris umgesetzt wurde. Tricks der alten Meister lernen, so in der Art.


    Deswegen bin ich ja froh, dass Leute sich noch immer die Mühe machen, Spiele zu disassemblieren und zu veröffentlichen – man kann so viel dadurch lernen.


    Mir ist bekannt, dass z.B. bei Atariage schon lange ein Disassembly von Space Invaders in Arbeit ist, dass aber noch nicht zur Verfügung steht. Sollte wider Erwarten meines eher fertig werden, würde ich es durchaus teilen.

    Inspiriert durch eine Aufgabe, die der Sohn eines Freundes in der Schule zu lösen hatte: SUDOKU Löser



    - Win-32 Kommando Zeile

    - Löst ein gegebenes Sudoku oder gibt aus dass unlösbar

    - Aus- und Eingabe ist etwas rudimentär



    Es funktioniert erstaunlich gut muss ich sagen.

    Hat bisher jedes Sudoku gelöst, in quasi Nullzeit.

    Und es hat nur 2 Stunden Arbeit gekostet.

    Es läuft mit nur 280 Code Zeilen (könnte man aber locker noch auf ein drittel reduzieren.







    .

    Mein Sudoku-Löser hab ich vor (uh schon rund 10) Jahren in Perl geschrieben. Es lässt auch Farb-Sudokus als Eingabe zu. D.h. die Fläche ist nicht gleichförmig in 9 x 3x3-Block-Flächen aufgeteilt, sondern in in 9 farbige Bereiche, die je eine zusammenhängende Fläche bilden.

    Ich bin regelmäßig irgendwo "hängen" geblieben, wo ich mir gedacht habe, das muss es doch eine Lösung geben. Und das Programm hat in diesen Fällen immer die Lösung gefunden (ich immer etwas übersehen). ;)

    Mit der Debug-/Trace-Version kann man dem Script auch beim "Arbeiten" zuschauen, was für mich interessant war, besonders an den Knackstellen, wo ich nicht mehr weiterkam und auch das Script zwangsläufig verbei kommen musste (außer ich hab schon davor etwas übersehen).


    Wer mag, kann sich gerne auch diese Variante mal ansehen.

    sudoku.zip (sudoku.pl Script + Kurzanleitung sudoku.txt)

    Archaisch, typischerweise für die Linux-Commandline oder alles was eine CLI und Perl hat. ;)


    Übrigens, was ich immer komisch finde, ist das Sudoku oft bei Erklärungen vorkommt, wenn es um Problemlösung und deren Komplexität geht. Da wird oft Sudoku als NP-Problem (Non-Polynomial-Problem) angeführt, allerdings ist der Aufwand meines Erachtens P (Polynomial) oder gar linear, wenn man die gängigen Lösungsregeln bzw. Denkweise zur Auflösung anwendet.

    Offenbar gehen manche davon aus, dass man die Felder so besetzt, dass man den Inhalt errät (oder einfach eine Annahme trifft) und dann schaut, ob es sich irgendwie ausgeht. Wenn nicht, muss man wieder zurück und neu raten. Ja, so könnte man einen Computer zur Lösung beschäftigen, aber ein Mensch (auch ein vernünftiger Sudoku-Solver) würde nie nach diesem Schema vorgehen. Das muss wohl irgendwie von Leuten stammen, die selbst nie ein Sudoku gemacht haben. :D

    Ja meine Lösung ist auch nur eine Brute Force Methode.


    Alles andere wäre zwar viel interessanter, aber das braucht dann statt 2 Stunden wahrscheinlich 20 oder 30 Stunden.


    Die PC's sind heute so abartig schnell, dass man keine intelligente Methode benötigt für die Lösung eines Sudoku. Man probiert einfach jeder Kombination bis man eine Lösung hat.


    Interessant wäre ein Code für den C64. Da kommt man nur mit intelligentem Code weiter. Weil die CPU so langsam ist.


    Vielleicht versuche ich mich mal damit. 😊

    Für normale Sudokus langt die Brute Force Methode ganz leicht.


    Wenn man jedoch nur die erste Zeile ausfüllt, dann hat der Algo schon ganz schön daran zu knabbern.

    Es kommen dann fast 18 Millionen Fehlversuche zustande.

    Man merkt nun schon dass er rechnet, es braucht ca. 100 ms für die Lösung. :D


    Quote from Diddl

    Ja meine Lösung ist auch nur eine Brute Force Methode.


    An den Weg hab ich nicht mal im Ansatz gedacht. Das wär mir irgendwie gegen die Programmierehre gegangen, da "brute force" zu lösen. Ich wollte ja irgendwie auch meine Lösungsstrategie einfach nur automatisieren, weil ich selbst oft irgendwelche Fehler machte.

    Vielleicht kann man das so gar mathematisch in die Darstellung linearer Gleichungen bringen und das Gleichungssystem mit gängigen Methoden "einfach" lösen. Den Gedanken hab ich aber nicht bis zum Ende geführt. Nur so eine vage Vermutung.

    Quote from Diddl

    Alles andere wäre zwar viel interessanter, aber das braucht dann statt 2 Stunden wahrscheinlich 20 oder 30 Stunden.

    Ja, so ist es (interessanter). Da hatte ich auch länger Spaß an der Sache, weil halt länger daran zu tüftelt ist. Für mich ist das keine Last bzw. ich hab's ja nicht eilig gehabt.

    Quote from Diddl

    Die PC's sind heute so abartig schnell, dass man keine intelligente Methode benötigt für die Lösung eines Sudoku. Man probiert einfach jeder Kombination bis man eine Lösung hat.

    Ja, die Geschwindigkeit hilft hier freilich.
    Es ist halt nicht mein "Duktus" etwas nach Hau-Drauf-Methode zu lösen, nicht wenn es die Zeit erfordert. ;)

    Quote from Diddl

    Interessant wäre ein Code für den C64. Da kommt man nur mit intelligentem Code weiter. Weil die CPU so langsam ist.

    In der Tat, würde ich mich auch mal schon dran wagen eine Portierung meines Scripts zu machen. So oberflächlich aus meiner Implementierung mal gedacht, scheint das ziemlich 1:1 übernehmen. Ich glaub ich verwende da schon etwas auch ein assoziatives Arrays - mal schauen, wie gut sich das auf normale Arrays abbilden lässt (für diese Anwendung).

    Quote from Hoogo

    Müsste das nicht heißen, dass ein Sudoku mit 5 leeren Feldern 5mal so lange braucht wie eines mit 1 leerem Feld?

    Nein, das heißt, dass sich das linear entwickelt (die Gerade geht nicht durch den 0-Punkt). Da es einen Sockelaufwand gibt, der sich nicht vervielfacht, ist das beim 5 Feldern nicht das 5-Fache der Zeit, wie für ein 1 Feld, sondern Fixaufwand + 5 x Aufwand_für_ein_weiteres_Feld.
    Linear in dem Sinn, dass der Aufwand für eine weiteres Feld dann ziemlich gleich bleibt und nicht irgendwie (im schlimmsten Fall) exponential steigt (polynomial wäre auch schon schlimm, wie etwa bei der klassischen Garbage-Collection, wo es polynomial mit quadratischem Aufwand geht).