Hallo Besucher, der Thread wurde 2,7k mal aufgerufen und enthält 15 Antworten

letzter Beitrag von Flexman am

Basic 7.0 Spiel: Top Down Racing

  • Ich habe hier mit Basic ein simples Top Down Racing programmiert. Das ganze ist mal in einer Pre-Alpha Version und vorab ein "Proof of Concept", was mit Basic 7.0 theoretisch möglich ist.


    Die Sprite- und Joystick-Optionen sind ja im Vergleich zum C64 recht gut, in der Praxis stellt sich allerdings die Frage, wozu sie wirklich zu gebrauchen sind. Für ein Spiel wie Pong ist die Kollissionsabfrage zu langsam, daher die Idee eines Top-Down Rennens, wo es nur einen "Crash" abzufragen gilt. Nachempfunden ist dabei das Altbaukriterium, wo mit Fahrrädern durch Wohnungen gefahren wird. Das Areal stellt also den Grundriss einer Wohnung dar, der Pfeil ist das Fahrrad. In 2 Minuten sollen möglichst viele Runden erreicht werden - das ist noch nicht eingebaut, sollte aber kein Hindernis darstellen.


    Dabei wäre natürlich langfristig die Hilfe eines Grafikers gut, Wertung usw. bekomme ich selber zusammen, aber die große Frage ist natürlich, in wie weit die Steuerung taugt.


    Generell ist die Routine eigentlich ganz ok, aber die Steuerung teilweise etwas unpräzise (was man merkt, wenn man den Pfeil im Stand dreht). Ich werde bei Gelegenheit mal sehen, ob sich da noch etwas verbessern lässt, oder das Basic doch nicht mehr zulässt - es ist natürlich jeder eingeladen im Source "herumzupfuschen". ;)


    Ansonsten gibt es schwarze Linien als "unsichtbare" Checkpoints. Gibt es eine Kollission, dann geht's zum vorigen Checkpoint zurück.


    Soviel also zu einer Idee mit erster Umsetzung - vielleicht mag ja wer seinen Senf dazugeben. :)

  • Like! Hab mal ein paar Runden mit dem Pfeil in der Wohnung gedreht. :) Auf die schnelle im VICE. Beim 1. Start hat sich der Pfeil in den XXén verhakt. Run/Stop und Neustart war nötig.


    Die Steuerung ist etwas träge und ein wenig hakelig. Könnte " smoother" sein. Mit etwas Übung, geht´s aber schon. Ist Basic7 dafür schnell genug? Vielleicht kann man da ja noch etwas Tempo mit dem 2Mhz-Trick im 40 Z-Modus rauskitzeln.


    Aber echt nicht schlecht, was in Basic7 so alles geht.


    :respect:

  • Mit dem 128er lassen sich schon nette Sachen mit Sprites basteln, ich hatte mal nen Racer ganz ohne Poke/Peek mit Basic7 gebastelt. Basic7 ist eigentlich halbwegs flink genug... wenn man dessen Stärken (sprmov) nutzt und die Schwächen umschifft

  • Cool gemacht. Ich habe da mal paar Optimierungen vorgenommen. Läuft nun etwas schneller. Zeilen von 250 bis 340 löschen und dafür folgenden Code einfügen:


    Code
    1. 250 do:j=joy(2):ifj>127thensp=sp+(1/(sp+1)):j=j-128:elsesp=sp-1:ifsp<0thensp=0
    2. 260 wi=wi+30*((j=7)or-(j=3)):ifwi<0thenwi=330:elseifwi>330thenwi=0
    3. 270 ifsp>5thensp=5
    4. 280 sprsavn$(wi/30+1),7:movspr7,wi#sp
    5. 290 lb=bump(1):on-(bump(2)=80)gosub1100:on-(lb>0)gosub1000:loop


    Zeilen 400 und 500 bitte löschen. Scheinen überflüssig zu sein. Wenn noch mehr Bedarf an Optimierung sein soll, einfach bescheid geben.
    Unterprogramme (Sprung via GOSUB zu 1000 und 1100) sollten, da sie häufig verwendet werden, oben im Programm oder zumindest sehr nah bei der Hauptschleife sein. Auch in den Unterprogrammen kann man viel optimieren. Der 128er kann 120 Zeilenlänge verkraften! :)


    Kleiner Tipp: SPRSAV ist leider langsam. Lad Zeichensatz (für später) und Sprites in den Grafikmodus (GRAPHIC 1,1 vorher machen) rein und hol dir die Sprites aus diesem Bereich. Ist viel schneller. Als kleines Beispiel kannst du dir gern mein 128er Spiel (auch für +4 erhältlich) Magic Blocks anschauen. Hab das dort so gehandhabt. ;)

  • Cool gemacht. Ich habe da mal paar Optimierungen vorgenommen. Läuft nun etwas schneller.


    Danke, werde ich mal anschauen!


    Zitat


    Kleiner Tipp: SPRSAV ist leider langsam. Lad Zeichensatz (für später) und Sprites in den Grafikmodus (GRAPHIC 1,1 vorher machen) rein und hol dir die Sprites aus diesem Bereich. Ist viel schneller. Als kleines Beispiel kannst du dir gern mein 128er Spiel (auch für +4 erhältlich) Magic Blocks anschauen. Hab das dort so gehandhabt. ;)


    Ok, muss ich mal schauen. Generell habe ich das ja eben gebraucht um das Fahrzeug zu drehen, da muss das Sprite dann während der Laufzeit getauscht werden.


    Was die Grafik angeht: Ich frage mich sowieso ob ich da nicht einfach ein gezeichnetes Bild reinladen kann. Der Hintergrund bekommt die Farbe des Bodens, der ist dann für die Sprite-Kollission irrelevant. Dann funktioniert das gleiche Prinzip und die Grafik kann dann auch etwas hergeben.

  • Du kannst natürlich auch eine Bitmap reinladen und dann dies als Level nutzen. Ich würde aber lieber mit einem eigenen Zeichensatz arbeiten und den Grafikbereich für eben den Zeichensatz und für die Sprites missbrauchen. Vorteil ist dann dabei, daß du die Level im Programm selber reinpacken kannst und brauchst sie nicht immer nachladen. Aber das muss jeder für sich selber sehen. Dennoch ein schönen kleines Spielchen, wirklich. Hat noch viel Potential nach oben offen.

  • "träge" oder "hakelig" finde ich die Steuerung nicht, das geht schon. Allerdings ist für meinen Geschmack das Gefährt zu schnell - die engen Kurven sind kaum absichtlich zu meistern, finde ich.


    Das Sprite sollte oberhalb aller Spielfeldelemente angezeigt werden - derzeit fährt es unter den unsichtbaren Checkpoints durch.


    Bei einem Spiel mit so wenig Bewegung auf dem Schirm würde ich mal durchrechnen, ob sich das auch irgendwie mit reiner Zeichensatzgrafik (also komplett ohne Sprites) realisieren lässt - das würde VDC-Darstellung und immerhin doppelte Taktgeschwindigkeit erlauben. Im 40-Zeichen-Modus dürfte es m.E. irgendwann knapp werden, wenn auch noch ein Timer heruntergezählt und die Runden angezeigt werden sollen.

  • Mit Bitmaps könnte man das halt grafisch recht ansprechend gestalten. Aber am Wichtigsten ist natürlich, dass die Steuerung einigermaßen rund ist, da wird sich dann zeigen, wie viel Potential nach oben geht. ;)


    Aber das mit dem Grafikmodus habe ich noch nicht ganz verstanden. Ich kann da die Sprites reinladen und dann klappt das mit dem ersetzen schneller als mit Sprsav? Ich werde mir das mal bei deinem Spiel anschauen.

  • Mit Bitmaps könnte man das halt grafisch recht ansprechend gestalten. Aber am Wichtigsten ist natürlich, dass die Steuerung einigermaßen rund ist, da wird sich dann zeigen, wie viel Potential nach oben geht. ;)


    Aber das mit dem Grafikmodus habe ich noch nicht ganz verstanden. Ich kann da die Sprites reinladen und dann klappt das mit dem ersetzen schneller als mit Sprsav? Ich werde mir das mal bei deinem Spiel anschauen.


    Oben sieht man den neuen Zeichensatz. Die verwursteten Striche darunter sind die Spritedaten, normal mit READ,POKE,DATA. Du kannst natürlich auch deine Sprites via SPRSAV reinpacken und später während der Laufzeit wieder herausholen, aber wie oben schon erwähnt: SPRSAV ist laaaaangsam.,


    Vor dem Laden hab ich GRAPHIC1,1 gemacht, dann BLOAD"GFX" (GFX ist die Datei, in der der Zeichensatz und die Sprites sind). Man kann dann einfach mit

    Code
    1. poke53272,24


    auf diesen Zeichensatz umschalten und für die Sprites einfach (hier Beispiel für Sprite 1)

    Code
    1. poke2040,x

    wobei x dann einen Wert bei etwa 160 hat. Dein BASIC Programm wird ja durch den GRAPHIC Befehl eh nach hinten verschoben. Bei jedem Programmstart kannst du ja via PEEK auslesen, ob der Zeichensatz vorhanden ist. Falls nicht, siehe mein Beispiel anhand Magic Blocks:

    Code
    1. 2000 fast:ifpeek(8192)<>126thengraphic1,1:graphic0:bload"gfx",b0,p8192
    2. 2001 poke216,255:poke53270,24:poke53272,24:color0,1:color4,1:sprite1,1,11,0,0,0,1:sprcolor1,2


    Zeile 1: in den Turbo Modus wechseln und Abfragen, ob an Adresse $2000 bzw 8192 der Wert 126 steht. Falls nicht, Grafikmodus einschalten, löschen und via BLOAD die Datei GFX laden
    Zeile 2: Kernel VIC Änderungs-IRQ deaktivieren: Multicolormodus einschalten: Zeichensatz an Adresse $2000 einschalten: Farben für Bildschirm und Sprites setzen


    Den VIC Änderungs-IRQ deaktiviere ich nur, damit ich den Multicolormodus einschalten kann. Vorteil ist, man kann wie gewohnt vom C64 Änderungen bzw. Adressierungen am VIC vornehmen. Allerdings funktionieren dann so Dinge wie der CHAR Befehl nicht mehr. Wenn du den MC nicht brauchst, ignorier einfach POKE216,255.

  • Da mir Logiker einen PETSCII-Raum gebastelt hat, habe ich mal am Quelltext weitergenudelt. (Das muss man wohl so bezeichnen, aber ich habe das wirklich am Originalgerät getippt und getestet).


    Sieht schon mal ganz nett aus. Mal sehen ob sich das mit der Steuerung noch hinbekommen lässt. Und den Bump-Befehl muss ich mir nochmal genauer anschauen, der liefert jetzt nach jedem Start ganz andere Werte. Theoretisch lassen sich die Kollissionen aber weiterhin damit erkennen.


    RKSoft: Deine Änderungen von Posting #5 habe ich bei "test3b" eingefügt, die ergeben aber einen "Division by Zero error". Irgeneine Kleinigkeit muss da noch sein.

  • Und den Bump-Befehl muss ich mir nochmal genauer anschauen, der liefert jetzt nach jedem Start ganz andere Werte.

    Denk daran, dass die Beschreibung im Handbuch falsch ist: BUMP() gibt keine Spritenummer, sondern ein Bitmuster zurück.

  • Denk daran, dass die Beschreibung im Handbuch falsch ist: BUMP() gibt keine Spritenummer, sondern ein Bitmuster zurück.

    Danke, die seltsame Beschreibung hat mich auch schon gewundert, auch wenn mir das trotzdem ein Rätsel ist.

    Aber mittlerweile habe ich den Tipp bekommen in Zeile 333 mit "If Bump(2)and64 then..." abzufragen damit klappt's!