Collab: Entwicklung eines TSB-Puzznic-Klons

Es gibt 1.089 Antworten in diesem Thema, welches 110.326 mal aufgerufen wurde. Der letzte Beitrag (1. November 2024 um 23:56) ist von Omega.

  • Die mit einem Micro-Compiler erzeugten schon. Die sind ja wie kleine Maschinenspracheprogramme.

    Das ist ja interessant! Könnte man sowas um solche Befehle wie REPEAT..UNTIL und LOOP..ENDLOOP erweitern? Die kann man ja in MS relativ leicht nachstellen!

    Omega : In deinem VB-PRG wäre "Hintergrundsetzen" der MAP-Befehl, sehe ich das richtig? Sollen die Steine in Multicolor gepixelt werden?

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • In deinem VB-PRG wäre "Hintergrundsetzen" der MAP-Befehl, sehe ich das richtig?

    Ja, so ist es. Und "HintergrundLesen" wäre der PEEK-Befehl. Es sei denn, du baust noch das Gegenstück zum Map-Befehl in TSB ein.

    Sollen die Steine in Multicolor gepixelt werden?

    Nein. Multicolor ist böse.

  • Übrigens: Die "NachUntenSchieben"-Prozedur ist nur die eine Prozedur, die in Assembler umgesetzt werden müsste. Ich hätte dann noch eine "TeileAuflösen"-Prozedur im Angebot, die für BASIC ebenfalls zu langsam ist. Das wär's dann aber auch schon. Ich wollte nicht direkt zu viele Sachen in den Ring werfen.

  • Ich würde das in Deinem Fall erstmal in Basic schreiben, damit man es dann schrittweise in Ass...Ctrl-W eine bessere Sprache übersetzen kann.

  • Ich würde das in Deinem Fall erstmal in Basic schreiben

    Wozu? Ich weiß ja, was ich brauche. Und der VB-Code ist gut getestet. Und allgemein verständlich ist er auch, oder?

    Ich könnte allerdings erstmal einen Ansatz in Basic schreiben, damit der (bisher noch unbekannte) Assembler-Coder weiß, was für Gegebenheiten auf dem Bildschirm sind. D.h. wo die Teile an welchen Adressen im Bildschirmspeicher zu finden sind, welches Teil aus welchen Zeichen im Zeichensatz besteht usw.

    In diesem Ansatz würde ich es so machen, dass man die Teile nach-links und nach rechts-ziehen kann. Und sie fallen dann runter. Und dann erstmal nichts mehr.

  • Ich könnte allerdings erstmal einen Ansatz in Basic schreiben, damit der (bisher noch unbekannte) Assembler-Coder weiß, was für Gegebenheiten auf dem Bildschirm sind. D.h. wo die Teile an welchen Adressen im Bildschirmspeicher zu finden sind, welches Teil aus welchen Zeichen im Zeichensatz besteht usw.

    Das halte hier für am Sinnvollsten. So weiß dein Sklave Mitarbeiter dann ganz genau, wo er wie ansetzen soll.

    Die Alternative wäre eine exakte Beschreibung, was du wie in deinem Programm machen willst. Nur halte ich das hier für aufwendiger als gleich deinen TSB-Ansatz zu coden.

  • Nur halte ich das hier für aufwendiger als gleich deinen TSB-Ansatz zu coden.

    Ja, da hast du wahrscheinlich recht.

    Ich sollte vielleicht noch kurz erwähnen, dass nur die mutigsten und erfahrensten Assembler-Meister diese Herausforderung beherrschen können.

  • Übrigens: Die "NachUntenSchieben"-Prozedur ist nur die eine Prozedur, die in Assembler umgesetzt werden müsste. Ich hätte dann noch eine "TeileAuflösen"-Prozedur im Angebot, die für BASIC ebenfalls zu langsam ist. Das wär's dann aber auch schon. Ich wollte nicht direkt zu viele Sachen in den Ring werfen.

    Vielleicht könnte man in TSB auch zwei neue Befehle, "NachUntenSchieben" und "TeileAuflösen", einbauen? Kann man immer gut gebrauchen. :whistling:

  • Das ist ja interessant! Könnte man sowas um solche Befehle wie REPEAT..UNTIL und LOOP..ENDLOOP erweitern? Die kann man ja in MS relativ leicht nachstellen!

    Vielleicht...müsste man dann aber im Klartext parsen, diese Befehle hätten ja keinen Token. Und im normalen Interpreter würde das dann auch nicht mehr laufen. Ich weiß aber nicht, wie gut der wirklich zu erweitern ist.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • dass nur die mutigsten und erfahrensten Assembler-Meister diese Herausforderung beherrschen können.

    Ja, denn im Hintergrund sitzt Omega :bgdev

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Vielleicht...müsste man dann aber im Klartext parsen, diese Befehle hätten ja keinen Token.

    Ach so, man kann ihm also keine neuen Token unterschieben? Wär ja schade, so könnte man ein paar wichtige TSB-Befehle kompilierbar machen...

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Die Spiele-Idee sieht eigentlich nicht so kompliziert für Basic aus.
    Müßte eingentlich gut machbar sein.
    Der Schirm-Aufbau im 2x2-Modus funktioniert schnell.
    Wie Arndt gesagt hat ist Steinefallen eigentlich kein Problem.
    Ich persönlich benutze in der Regel keine Arrays, sondern lese alles direkt vom Bildschirm mit der Bildschrim-Peek() Funktion.
    Schau dir mal den Kisten-Schieber in dem Thread "Die besten 10-Zeiler" an.

    Schönen Gruß.

  • Was bereitet dir bei der POKErei Schwierigkeiten?

    Ich glaube das liegt wohl auf der Hand. Um mit dem normalen BASIC ein Sprite darzustellen braucht man etliche POKEs und bei TSB braucht man nur ein paar klar lesbare Kommandos. Mit Sprites und Tönen verhält es sich genauso. Außerdem bin ich dafür, dass POKEs generell weltweit verboten werden. ;)

    Man braucht wenige Pokes. Die sind auch total logisch, wenn man sich mal die VIC Register ansieht. Das müsstest du eigentlich in ein paar Minuten verstanden haben, wenn du dir die Grundlagen durchliest.

    Zu Access 2000: das ist doch dann simples VBA. Sollte leicht auf jede andere Office Anwendung umzusetzen sein. Oder auf VB Script. Und Access 2000 Dateien sollten doch auch mit jeder neueren Access Version zu öffnen sein.

  • GoDot: In welchem Speicherbereich bietet es sich an, Assembler-Routinen für TSB abzulegen?

    Wenn du die hochauflösende Grafik nicht bemühst, aber mit eigenem Zeichensatz arbeitest (was ja wohl unumgänglich ist) hast du zweimal 1 KB frei: den normalen Screen ab $0400 und den Hires-Farbbereich ab $c000. Dort musst du - wenn noch Sprites ins Spiel kommen - die letzten acht Bytes natürlich freihalten (selbstdefinierte Zeichensätze verwaltet TSB in VIC-Bank 3, die Zeichensatzdaten dann ab $e000). Frei ist auch der Kassettenpuffer und der Bereich von Spriteblock 11, der ja nur gebraucht wird, wenn es in VIC-Bank 0 laufen würde.


    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Ach so, man kann ihm also keine neuen Token unterschieben? Wär ja schade, so könnte man ein paar wichtige TSB-Befehle kompilierbar machen...

    Ach so...du meinst explizit die TSB-Token...das geht bestimmt, ich denke nur nicht, dass das besonders sinnvoll wäre. Diese Dinger sind ja doch recht eingeschränkt in dem, was sie so können.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Die Spiele-Idee sieht eigentlich nicht so kompliziert für Basic aus.
    Müßte eingentlich gut machbar sein.

    Bist du sicher, dass du die Spiel-Logik 100% verstanden hast?

    Wie Arndt gesagt hat ist Steinefallen eigentlich kein Problem.

    Das einspaltige Runterfallen der Steine ist natürlich kein Problem. Aber die Kettenreaktionen, die sich daraus ergeben können. Ich sehe keine realistische Chance, wie man das mit reinem BASIC umsetzen könnte. Und ich habe in den letzten Tagen ernsthaft darüber nachgedacht. Jede Vereinfachung, die ich versucht habe, führte dazu, dass das Spiel nicht mehr richtig funktioniert hat. Meistens macht sich das dadurch bemerkbar, dass Steine einfach in der Luft hängen bleiben anstatt vollständig runterzufallen.

    Zu Access 2000: das ist doch dann simples VBA. Sollte leicht auf jede andere Office Anwendung umzusetzen sein. Oder auf VB Script.

    Das Spiel ist in der Tat in VB geschrieben. Aber die Grafikdarstellung ist sehr speziell auf Access2000 zugeschnitten. Das funktioniert noch nicht mal mit Access97. Um eine Version zu erstellen, die mit dem normalen "Visual Basic" läuft, müsste ich das ganze Grafiksystem im Spiel neu programmieren. Das könnte ich machen. Das ist aber nicht das, was ich möchte. Ich möchte das Spiel auf den C64 umsetzen. Oder zumindest schauen, ob das irgendwie geht.

  • Die große Frage des Tages ist, ob die in Bitte melde dich an, um diesen Link zu sehen. dargestellt VB-Prozedur (und noch eine andere, sehr ähnliche) in C64-Assembler nachgebildet werden kann und ob man das Resultat in TSB reinquetschen kann.

  • Die große Frage des Tages ist, ob die in Bitte melde dich an, um diesen Link zu sehen. dargestellt VB-Prozedur (und noch eine andere, sehr ähnliche) in C64-Assembler nachgebildet werden kann und ob man das Resultat in TSB reinquetschen kann.

    Ja und ja.

    Wie weit ist dein TSB-Code schon gediehen?

    GoDot: Welche Zeropage-Adressen stehen unter TSB noch zur freien Verfügung?

  • Ja und ja.

    Das nenn ich mal ein Wort.

    Wie weit ist dein TSB-Code schon gediehen?

    Ich arbeite daran. Das kann etwas dauern, da ich immer nur abends Zeit habe mich damit zu beschäftigen. Ich muss ja auch erstmal einen Zeichensatz und die notwendigen Sprites erstellen und so. Zumindest provisorisch. Ich wollte auch erstmal sicherstellen, dass ich hier nicht in eine Sackgasse renne.