Hello, Guest the thread was viewed11k times and contains 342 replies

last post from Drachen at the

Collab: Entwicklung eines TSB-Puzznic-Klons

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

    Wenn sie deinen Code nicht überdauern müssen, bist du relativ frei ($be enthält die Drivenummer für alle Disk-Befehle). Wenn doch, wird‘s eng. Ausprobieren!


    Arndt

    Ich sichere dann besser die betroffenen Adressen. Gibt es ZP-Adressen, auf die TSB in seiner Interrupt-Routine zugreift? Die ich also besser gar nicht anfassen sollte, um keine unvorhergesehenen Nebeneffekte auszulösen.

  • Ich sichere dann besser die betroffenen Adressen. Gibt es ZP-Adressen, auf die TSB in seiner Interrupt-Routine zugreift?

    Sichern ist nicht nötig, außer für $BE. Die von TSB verwendeten Zeropageadressen sind $BE und $B0 bis $B5, die letzteren nur während eines Befehlslaufs (allerdings bei vielen Neo-Befehlen und im Interpreter). Im Interrupt kommen keine Zeropageadressen ins Spiel.


    Arndt

  • Ich hab mal (vor allem) die Backsteine und das Herz um ein paar Pixel verändert:



    Damit es rechts nicht so einen Flatterrand gibt und das Herz ein bisschen "weicher" aussieht. Welches ist denn dein "Glasstein" überhaupt?


    Fallenlassen: Du checkst also, ob unter dem Stein Luft ist, oder? Auch bei dem blauen? Oder hat der eine andere Funktion?


    Arndt

  • Ich habe bei dem Beispielprogramm aus Post #74 die Map mal so verändert, dass die Spielsteine in der Luft hängen.

    Kann man TSB so maipulieren, dass ein Spiel automatisch geladen und gestartet wird?


    ogd: Bist du da noch dabei? Wenn du keine Lust hast, ist es übrigens nicht schlimm. Ich würd's nur gerne wissen. :)

    Ja, aber der Super Bowl geht immer vor.


    Im Interrupt kommen keine Zeropageadressen ins Spiel.

    Das erleichtert die Sache.

  • Damit es rechts nicht so einen Flatterrand gibt und das Herz ein bisschen "weicher" aussieht. Welches ist denn dein "Glasstein" überhaupt?
    Fallenlassen: Du checkst also, ob unter dem Stein Luft ist, oder? Auch bei dem blauen? Oder hat der eine andere Funktion?

    Die Grafik ist ja noch provisorisch. Das Ganze ist ja im Moment noch im "Proof-of-Concept" Stadium.

    Fallenlassen: Du checkst also, ob unter dem Stein Luft ist, oder?

    Jawohl. Genau so ist es.

    Auch bei dem blauen? Oder hat der eine andere Funktion?

    Der blaue Stein ist der Glasstein. Der fällt genauso runter wie die anderen. Der Unterschied zwischen dem Glasstein und einem regulären Spielstein ist, dass sich Glassteine nicht auflösen wenn sie sich gegenseitig berühren. Die anderen Steine lösen sich auf, wenn sich zwei (oder mehr) berühren.

    Kann man TSB so maipulieren, dass ein Spiel automatisch geladen und gestartet wird?

    Man kann einen Loader schreiben, der sowohl TSB als auch das Spiel lädt. Das ist von führenden Wissenschaftlern schon erfolgreich durchgeführt worden.

    Ja, aber der Super Bowl geht immer vor.

    Okay. Das freut mich.

  • Die Grafik ist ja noch provisorisch.

    Schon klar. Aber sowas (die unregelmäßigen Steine) lässt mich immer schauern...

    Der blaue Stein ist der Glasstein.

    Hätt ich mir auch denken können, sieht doch aus wie ein Glasbaustein!

    Die anderen Steine lösen sich auf, wenn sich zwei (oder mehr) berühren.

    Ah, verstehe. Die können also hinderlich sein, wenn man alles aufgelöst haben will. Kriegt man die überhaupt weg? Was ist, wenn die bis oben gestapelt sind?


    Arndt

  • Aber sowas (die unregelmäßigen Steine) lässt mich immer schauern...

    Ich weiß gar nicht, was du meinst. Kann sein, dass der Emulator die grafische Darstellung ein bisschen verzerrt hat.

    Und der Screenshot oben stammt direkt von meinem PC. Komplett mit der unschönen Emulator-Darstellung. Wenn du dir die Kacheln im Zeichensatzeditor anschaust, wirst du feststellen, dass es da keine Unregelmäßigkeiten gibt.

    Ah, verstehe. Die können also hinderlich sein, wenn man alles aufgelöst haben will. Kriegt man die überhaupt weg? Was ist, wenn die bis oben gestapelt sind?

    Die Glasblöcke kriegt man nicht weg. Man muss sie so auf dem Spielfeld anordnen, dass die anderen Spielsteine drumherum gezogen werden können.


    Und ich garantiere folgendes:

    Jeder Level wird mehrmals auf Spielbarkeit getestet. Jeder Level kann gelöst werden. Die Lösung ergibt sich durch logische Analyse.

    Wenn es einen Level geben sollte, der nicht lösbar ist, erhalten Sie Ihr Geld zurück.

    hier mal ein Bild von eienen ähnlichen Spiel wie deins

    Danke. Aber so etwas brauche ich nicht. Ich mache lieber ein Spiel mit schlechter Popel-Grafik, als dass ich die Grafiken irgendwo klaue oder abmale. Ich brauche auch keinen Hinweis, dass es noch andere Puzznic-Klone gibt. Das ist mir bekannt.

  • Ich weiß gar nicht, was du meinst. Kann sein, dass der Emulator die grafische Darstellung ein bisschen verzerrt hat.

    Schau dir bei deinem Screenshot die rechten Kanten der Mauern an und dann vergleich das mit meinem Screenshot, siehst du? Aber ich hatte überhaupt nicht vor, dich irgendwie abzulenken. Ignorier das einfach!


    Arndt

  • Schau dir bei deinem Screenshot die rechten Kanten der Mauern an und dann vergleich das mit meinem Screenshot, siehst du? Aber ich hatte überhaupt nicht vor, dich irgendwie abzulenken. Ignorier das einfach!

    Ah ja. Stimmt. Jetzt seh ich's auch. Und nein, das lenkt mich gar... Oh! Da draußen läuft eine Katze. Die muss ich mir ansehen.

  • Omega , ich habe mir gedacht, wie wäre es mit einem Gamepack für TSB, wo alle für eine Spieleumgebung wichtigen Zusatzbefehle auf einmal eingebunden und aktiviert werden. In so ein Pack könnten Sachen rein, die im normalen TSB keinen Platz finden. Damit es sich lohnt, was könntest du dir als Inhalt so eines Packs vorstellen, was brauchst genau du für die Entwicklung und Durchführung von Spielen? Dieses Gamepack würde die DOS Wedge 5.1 ersetzen, d.h. es steht dann der Raum zwischen $cc00 und $cfff zum Coden zur Verfügung.


    Arndt

  • In so ein Pack könnten Sachen rein, die im normalen TSB keinen Platz finden.

    Eine eigene TSB-Version nur für Spiele? Klingt gut. Aber auch nach viel Wartungsaufwand. Wenn man zwei Versionen vom selben Programm parallel weiterentwickelt, dann ist das (organisatorisch betrachtet) die Hölle.

    Damit es sich lohnt, was könntest du dir als Inhalt so eines Packs vorstellen, was brauchst genau du für die Entwicklung und Durchführung von Spielen?

    Das ist schwer zu sagen. Jedes Spiel hat andere Anforderungen. Das wird man in mehreren Schritten überlegen müssen. Ich denke, ein erster Schritt könnte sein, die nicht benötigten Befehle loszuwerden. Dann hat man mehr Platz für Befehls-Erweiterungen. Vielleicht auch für eigene Assembler-Routinen. Je flexibler desto besser.


    Was ich mir persönlich in einem Spiel nicht vorstellen kann sind:

    - Die Grafikbefehle zum Zeichnen.

    - Alles was mit Drucken zu tun.

    - Die Spritekollisionsbefehle.

    - Die High-Speed-Grafik (hsg).

  • Was ich mir persönlich in einem Spiel nicht vorstellen kann sind:

    - Die Grafikbefehle zum Zeichnen.

    - Alles was mit Drucken zu tun.

    - Die Spritekollisionsbefehle.

    - Die High-Speed-Grafik (hsg).

    Verstehe, das läuft auf besser unterstützte Zeichensatzgrafik hinaus. Die Kollisionsbefehle: wenn die täten, was sie sollen, wären sie aber nützlich, oder? Grafikroutinen: Leider hat DS die ziemlich mit den Spritesteuerungsbefehlen verquickt, weshalb man die nicht einfach so rausnehmen kann. Das ergäbe ziemliches Flickwerk.


    Dein Ansatz mit den Kacheln (vier aufeinanderfolgende Zeichen bilden eine Kachel) ist platzraubend, finde ich. Man kann darin Zeichen, die öfter vorkommen, nicht wiederverwenden bzw. muss sie dann nochmal definieren. Vielleicht überlege ich mir da auch was. Womöglich ist es auch besser, die Farben zeichenweise zuzuordnen und nicht kachelweise (das ist mir bei dem Platman-Screen besonders aufgefallen). Bei viel umzufärbenden Stellen braucht FCOL ja doch einen spürbaren Moment und vor allem viel Programmierung.


    TSB4games: Ich stelle mir einfach einen Befehl vor (nämlich INST), der die ganze Umstellung vornimmt. Zwei getrennte Dinge lassen sich besser verwalten als zwei vermischte.


    Aber das alles ist erstmal nur Projektbeschreibung. Nichts erwarten, bitte!


    Arndt

  • Ich wollte mal wissen, ob man das in kompiliertem BASIC "schnell genug" hinbekommen könnte, weil ich da oben ja behauptet hatte, mit einem Micro-Compiler müsste das gehen, wenn man nur den Part mit dem Fallen/Auflösen damit macht. Das war mir jetzt aber zu anstrengend, also habe ich mal eine Demo in normalem BASIC geschrieben und die mit meinem "normalem" Compiler übersetzt. Das ist auch schon ganz ok, denke ich.

    Also von daher würde wohl auch der Brute-Force-Ansatz mit einem Micro-Compiler klappen...


    P.S.: Ich weiß nicht, ob diese Demo alles "richtig" so macht, wie es das Spiel dann machen müsste...aber war mir auch egal. Es soll nur ein Beispiel für sowas ähnliches sein, um die Geschwindigkeit einschätzen zu können.

  • Wäre es nicht einfacher, ein Programm zu haben wo man seine Tiles erst zusammenbauen kann, die dann im Speicher ablegt werden, und bei gebrauch sie dann aufruft und patziert.

    So wurde das bei Turrican gemacht. Aus wenige Chars wurden dann viele Tiles zusammengebaut.

    Als Bestes Programm wie das aussehen könnte wäre CharPad. Darin kann man seine Tiles erstellen und den Zeichensatz nach doppelten Chars durchsuchen lassen.

    Also ich meine jetzt nicht, das Arndt ein Programm für den C64´er schreiben soll um Titles zeichnen, sondern ein Programm das die Daten von CharPad nimmt und sie ins Programm einliest damit man das im Spiel verwenden kann.

    Der einzige Wermutstropfen ist halt das man dann mit dem PC arbeiten muss, zwecks CharPad.

    Aber vielleicht gibt es ja auch schon ein Programm für den C64´er, das weis ich aber leider nicht.

    So ein Programm würde ich mir wünschen um ein Spiel zu Programmieren.

  • Dein Ansatz mit den Kacheln (vier aufeinanderfolgende Zeichen bilden eine Kachel) ist platzraubend, finde ich. Man kann darin Zeichen, die öfter vorkommen, nicht wiederverwenden bzw. muss sie dann nochmal definieren.

    Ich finde das ausreichend. Wenn einem die Zeichen nicht reichen, kann man ja auf die Groß/Kleinbuchstaben umschalten. Und wenn das immer noch nicht reicht, kann man einen anderen Zeichensatz von Diskette laden. Warum soll man das so kompliziert machen? "Turrican" mit TSB wird wohl keiner entwickeln.

    TSB4games: Ich stelle mir einfach einen Befehl vor (nämlich INST), der die ganze Umstellung vornimmt. Zwei getrennte Dinge lassen sich besser verwalten als zwei vermischte.

    Hmm. Ich weiß nicht. Ich glaube, ein einziges, universelles TSB ist der beste Weg. Also eigentlich so wie bisher.

  • ...also habe ich mal eine Demo in normalem BASIC geschrieben und die mit meinem "normalem" Compiler übersetzt. Das ist auch schon ganz ok, denke ich.

    Wow! Das ist nicht nur okay sondern ziemlich beeindruckend. Die Geschwindigkeit ist mehr als ausreichend. Das man dabei nur reines BASIC verwenden kann, ist ja völlig egal. Hauptsache, dass Programm macht was es soll. Nämlich den Bildschirmspeicher reorganisieren.


    Bei genauerer Betrachtung habe ich den Eindruck, dass dein Programm genau das macht, was ich brauche.


    Ich frage mich, ob das Kompilat klein genug ist, um es an eine geeignete Stelle in TSB reinzuladen. Und ob das überhaupt geht mit dem Aufruf aus TSB- und dem Rücksprung zu TSB und so. Da habe ich leider keine Ahnung von.


    Und dann stellt sich noch die Frage, was ogd inzwischen ausgetüftelt hat.