Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: VzEkC e. V.. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

Peter z80.eu

Z80 Anbeter

  • »Peter z80.eu« ist männlich
  • »Peter z80.eu« ist der Autor dieses Themas

Beiträge: 1 185

Wohnort: Mainz Umgebung

Lieblingscomputer: Kaypro 4

  • Nachricht senden

1

Donnerstag, 10. März 2016, 21:54

FAST.BAS : "Rasen mit 310 Km/h" in BASIC - sollte eigentlich ein 10-Zeiler werden, aber da es dann auch spielbar und mit Anreiz sein sollte, sind es 13 Zeilen geworden

Mit "Rasen" meine ich "Schnell fahren", nicht das grüne Zeugs ;-)

Wollte mich eigentlich am Wettbewerb beteiligen, aber dann habe ich die Einschränkung auf 8-Bitter gesehen.
Also sind es 13 Zeilen mit max. 80 Zeichen Länge geworden. Ziel war die Spielbarkeit, und die Portabilität auf mindestens jeden PC (keine CPU-Speed Abhängigkeit).

Gespielt wird es (nach Start mit "RUN" im Interpreter) mit den Tasten "n" und "m" (ja, und nur mit den Kleinbuchstaben!). Abbruch mit "q" möglich.

Hier der Source-Code, frei kopierbar und abänderbar wie ihr wollt, solange ihr die ursprüngliche Quelle (mich) angibt:

10 DEFINT A-Z:RANDOMIZE TIMER:D!=TIMER:S=RND*40!+20:C=S+4:O=C:CLS
20 LOCATE 11,1:FOR I=1 TO 12:PRINT SPC(S);"|";SPC(10);"|":NEXT I:Z=0:V!=.3
30 R=RND*7:IF R<3 THEN M=-1 ELSE IF R=3 THEN M=0 ELSE M=1
40 LOCATE 2,1:PRINT "KM:";Z;" Vmax:";310-CINT(V!*1000!):S=S+M
50 LOCATE 23,1:IF S>58 THEN S=58 ELSE IF S<1 THEN S=1
60 PRINT SPC(S%);"|";SPC(10);"|";" ":PRINT:Z=Z+10:T=SCREEN(10,C):LOCATE 10,C
70 PRINT "*";:LOCATE 9,O:PRINT " ";:IF T<>32 THEN LOCATE 3,1:PRINT "CRASH!"
80 IF T<>32 THEN SOUND 37,5:LOCATE 23,1:END ELSE O=C:IF TIMER<D!+1 THEN 110
90 IF V!>.1 THEN V!=V!-.01 ELSE IF V!>.05 THEN V!=V!-.005 ELSE V!=V!-.001
100 D!=TIMER:SOUND Z/10+100,2:IF V!<0 THEN V!=0
110 K$=INKEY$:T!=TIMER+V!:WHILE TIMER<T!:WEND
120 IF K$="" THEN 30 ELSE IF K$="n" THEN C=C-1 ELSE IF K$="m" THEN C=C+1
130 IF K$="q" THEN LOCATE 23,1:END ELSE 30:REM (C) P.DASSOW

Hier auch mal ein Screenshot mit einem real erspielten Highscore (Uff!), DOSBOX als Emulator, BASICA 3.30 als Basic-Variante (GWBASIC geht natürlich auch):

P.S.: Jetzt auch als kompilierte EXE (im ZIP) anbei.
»Peter z80.eu« hat folgendes Bild angehängt:
  • fast.jpg
»Peter z80.eu« hat folgende Datei angehängt:
  • FAST.zip (21,1 kB - 33 mal heruntergeladen - zuletzt: 17. März 2017, 13:28)
"Wäre das Pferd eine Katze gewesen, dann wäre es den Baum hochgeritten" --- Und schaut auch mal bei meinem Blog vorbei ...

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Peter z80.eu« (10. März 2016, 22:17)


Microprofessor

NOP NOP NOP

  • »Microprofessor« ist männlich

Beiträge: 3 525

Wohnort: Berlin

Lieblingscomputer: Antikythera

  • Nachricht senden

2

Freitag, 11. März 2016, 07:32

Sehr schön! Gratuliere!

Wenn du magst, kann ich den Code auf unserer Zusatz-Webseite für den demnächst erscheinenden Katalog zum OCM posten. Den sollen die Museumsbesucher eingeben, um ein wenig über die Systeme dort zu lernen.
»Retrocomputing ist kein Heimatfilm der Computerkultur.« (Wolfgang Ernst)
»Die Geschichte des Computers ist zu wichtig, um sie den Historikern zu überlassen.« (Raúl Rojas)

Computerarchäologie | About me | Blog | Sammlung | Job

Peter z80.eu

Z80 Anbeter

  • »Peter z80.eu« ist männlich
  • »Peter z80.eu« ist der Autor dieses Themas

Beiträge: 1 185

Wohnort: Mainz Umgebung

Lieblingscomputer: Kaypro 4

  • Nachricht senden

3

Freitag, 11. März 2016, 12:00

Klar, gerne.

Auf Rechnern ab 286 läuft es ganz manierlich, bei einem PC/XT oder auch bei einem Schneider PC 1512 ist es in der "Endstufe" etwas langsamer als gewollt.

Werde ich also noch so abändern, dass es auch auf den ganz langsamen PCs am Schluss schwierig wird ;-)

Gruss Peter

P.S.: Da ich ein fauler Mensch bin, habe ich erstmal jede Menge BASIC-Compiler ausprobiert, um auch auf dem XT oder Schneider PC es schnell genug laufen lassen zu können.
Anbei also das Kompilat, was auch auf den langsamen PCs schnell genug läuft, dass es am Schluss eine echte Herausforderung wird...
»Peter z80.eu« hat folgende Datei angehängt:
  • FAST-TB.zip (24,84 kB - 24 mal heruntergeladen - zuletzt: 17. März 2017, 07:34)
"Wäre das Pferd eine Katze gewesen, dann wäre es den Baum hochgeritten" --- Und schaut auch mal bei meinem Blog vorbei ...

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Peter z80.eu« (11. März 2016, 12:37)


Microprofessor

NOP NOP NOP

  • »Microprofessor« ist männlich

Beiträge: 3 525

Wohnort: Berlin

Lieblingscomputer: Antikythera

  • Nachricht senden

4

Freitag, 11. März 2016, 12:40

Das kann dann im Museum auf einem 386 programmiert werden.
»Retrocomputing ist kein Heimatfilm der Computerkultur.« (Wolfgang Ernst)
»Die Geschichte des Computers ist zu wichtig, um sie den Historikern zu überlassen.« (Raúl Rojas)

Computerarchäologie | About me | Blog | Sammlung | Job

ThoralfAsmussen

Fortgeschrittener

Beiträge: 382

Wohnort: Dresden (nahebei)

Lieblingscomputer: Archimedes

  • Nachricht senden

5

Freitag, 11. März 2016, 14:26

P.S.: Da ich ein fauler Mensch bin, habe ich erstmal jede Menge BASIC-Compiler ausprobiert, um auch auf dem XT oder Schneider PC es schnell genug laufen lassen zu können.
Anbei also das Kompilat, was auch auf den langsamen PCs schnell genug läuft, dass es am Schluss eine echte Herausforderung wird...


Das Zusammensetzen der Printzeile (60) dürfte wesentlich flotter sein, wenn man das einmal als fixen String printed und nicht in jedem Durchlauf neu zusammenbastelt.

Die Abfrage aud T<>32 in (70) und (80) kosten ohne Ende Zeit und können prima durch einen einzigen Sprung ans echte Ende auf ein IF verkürzt werden. Der ELSE Teil in (80) ist prinzipiell unnötig, weil es beim Crash auch egal ist, ob da nochmal eine Variable gerettet wird, sonst aber kostet das bei jeder Runde viel Zeit.


Die KeyAbfrage wird auch flotter, wenn die Keys einzeln behandelt werden und dann direkt gejumped wird. Also nicht so ein SchachtelELSE, sondern eher
120 IF K$="" THEN 30
125 IF K$="n" THEN C=C-1 : GOTO 30
126 IF K$="m" THEN C=C+1 : GOTO 30

Zumindest, wenn das IF dann noch bis zum Zeilenende gilt.
Außerdem dürfte Abfragen der CHR$ Codes schneller sein als "Tastenkappenbezeichnungen" auszuwerten. Vermutlich mit INKEY ?

Noch schneller sollte dort so eine Konstruktion sein, wie
C=C+1 : IF K$="n" C=C-2 : GOTO 30
unter Verzicht auf den Abbruch mit q, was auch OK ist, da man ja definiert abbrechen kann, indem man in die Bande rast.

Ansonsten funktioniert das wirklich schon ganz nett (DOSBOX) und lange bleibt man da nicht unterwegs ... öhem, nun ja ... muß wohl mal die Hand-Keyboard-Koordination wieder ein wenig üben.

spunkt

Profi

  • »spunkt« ist männlich

Beiträge: 1 489

Wohnort: Brühl

Lieblingscomputer: iMac Bondiblue

  • Nachricht senden

6

Freitag, 11. März 2016, 15:07

Leicht beeindruckt lausche ich den Ausführungen der Programmierer :huh: :thumbsup:
Retroraum: Apple II+, IIe, IIc, II + IIe Clone, MacPlus, Mac SE, SE30, iMac, eMac, Performa 5200, G4 PCI, G4 Quicksilver, MacBook, Commodore CBM 4016, CBM 4031, PET 2001, VC20, C64, SX64, C128D, Amiga 500, Amiga 600, Atari 800 XL, 260 ST, 1040 ST, PC 3, VC 2600, Spectrum ZX, Toshiba 3100/20, TRS-80 I, TRS-80 II, TI-99/4A, Micro-Professor MPF-I, Seiko RC-1000, RC-4500, Data-2000, UC-2000

Peter z80.eu

Z80 Anbeter

  • »Peter z80.eu« ist männlich
  • »Peter z80.eu« ist der Autor dieses Themas

Beiträge: 1 185

Wohnort: Mainz Umgebung

Lieblingscomputer: Kaypro 4

  • Nachricht senden

7

Freitag, 11. März 2016, 15:13

P.S.: Da ich ein fauler Mensch bin, habe ich erstmal jede Menge BASIC-Compiler ausprobiert, um auch auf dem XT oder Schneider PC es schnell genug laufen lassen zu können.
Anbei also das Kompilat, was auch auf den langsamen PCs schnell genug läuft, dass es am Schluss eine echte Herausforderung wird...


Das Zusammensetzen der Printzeile (60) dürfte wesentlich flotter sein, wenn man das einmal als fixen String printed und nicht in jedem Durchlauf neu zusammenbastelt.

Die Abfrage aud T<>32 in (70) und (80) kosten ohne Ende Zeit und können prima durch einen einzigen Sprung ans echte Ende auf ein IF verkürzt werden. Der ELSE Teil in (80) ist prinzipiell unnötig, weil es beim Crash auch egal ist, ob da nochmal eine Variable gerettet wird, sonst aber kostet das bei jeder Runde viel Zeit.


Die KeyAbfrage wird auch flotter, wenn die Keys einzeln behandelt werden und dann direkt gejumped wird. Also nicht so ein SchachtelELSE, sondern eher
120 IF K$="" THEN 30
125 IF K$="n" THEN C=C-1 : GOTO 30
126 IF K$="m" THEN C=C+1 : GOTO 30

Zumindest, wenn das IF dann noch bis zum Zeilenende gilt.
Außerdem dürfte Abfragen der CHR$ Codes schneller sein als "Tastenkappenbezeichnungen" auszuwerten. Vermutlich mit INKEY ?

Noch schneller sollte dort so eine Konstruktion sein, wie
C=C+1 : IF K$="n" C=C-2 : GOTO 30
unter Verzicht auf den Abbruch mit q, was auch OK ist, da man ja definiert abbrechen kann, indem man in die Bande rast.

Ansonsten funktioniert das wirklich schon ganz nett (DOSBOX) und lange bleibt man da nicht unterwegs ... öhem, nun ja ... muß wohl mal die Hand-Keyboard-Koordination wieder ein wenig üben.


Hallo,

es ging um die Größe des gesamten Listings bzw. die Anzahl der Zeilen, und nicht um Eleganz - Du hast da was VÖLLIG MISSVERSTANDEN.

Sicherlich kannst Du Dir vorstellen, dass ich vor dem "Verkleinern" mehr Programmzeilen hatte, und das Ganze auch effizienter gestaltet war (ich kenne natürlich BASIC, und sicherlich kann man z.B. zwei gleiche "IF" Abfragen auch zusammenfassen - nur dadurch wäre die Zeile zu lang geworden, also mehr als 80 Zeichen). Ich hätte für den Wettbewerb sowie eine andere Art der Beschränkung ausgewählt, keine Zeilenanzahl, sondern die Größe von 1KB wäre meine Grenze gewesen. Dann hätte ich auch viele Dinge einfacher gestalten können, auch wenn die Zeile dadurch länger als 80 Zeichen wird. Und zur Zeile 60 - nein, da kannst Du nichts zu einem fixen String zusammenfassen, weil ja jedesmal die Position der "Strasse" neu bestimmt wird.

Ich kann auch gerne eine geschwindigkeitsoptimierte Version noch posten, aber die wird dann definitiv mehr Zeilen haben - das war aber vorrangig nicht mein Ziel gewesen.

Gruss Peter

P.S.: Diese Version ist geschwindigkeitsoptimiert, aber das macht derart wenig aus, dass es die Mühe nicht lohnt:

10 DEFINT A-Z:RANDOMIZE TIMER:D!=TIMER:S=RND*40!+20:C=S+4:O=C:CLS
20 LOCATE 11,1:FOR I=1 TO 12:PRINT SPC(S);"|";SPC(10);"|":NEXT I:Z=0:V!=.3
30 R=RND*7:IF R<3 THEN M=-1 ELSE IF R=3 THEN M=0 ELSE M=1
40 LOCATE 2,1:PRINT "KM:";Z;" Vmax:";310-CINT(V!*1000!):S=S+M
50 LOCATE 23,1:IF S>58 THEN S=58 ELSE IF S<1 THEN S=1
60 PRINT SPC(S%);"| |";" ":PRINT:Z=Z+10:T=SCREEN(10,C):LOCATE 10,C
70 PRINT "*";:LOCATE 9,O:PRINT " ";:IF T=32 THEN O=C:IF TIMER<D!+1 THEN 110 ELSE 90
80 LOCATE 3,1:PRINT "CRASH!":SOUND 37,5:LOCATE 23,1:END
90 IF V!>.1 THEN V!=V!-.01 ELSE IF V!>.05 THEN V!=V!-.005 ELSE V!=V!-.001
100 D!=TIMER:SOUND Z/10+100,2:IF V!<0 THEN V!=0
110 K$=INKEY$:T!=TIMER+V!:WHILE TIMER<T!:WEND
120 IF K$="" THEN 30
130 IF K$="n" THEN C=C-1:GOTO 30
140 IF K$="m" THEN C=C+1:GOTO 30
150 IF K$="q" THEN LOCATE 23,1:END
"Wäre das Pferd eine Katze gewesen, dann wäre es den Baum hochgeritten" --- Und schaut auch mal bei meinem Blog vorbei ...

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Peter z80.eu« (11. März 2016, 15:42)


ThoralfAsmussen

Fortgeschrittener

Beiträge: 382

Wohnort: Dresden (nahebei)

Lieblingscomputer: Archimedes

  • Nachricht senden

8

Freitag, 11. März 2016, 15:58

es ging um die Größe des gesamten Listings bzw. die Anzahl der Zeilen ... Sicherlich kannst Du Dir vorstellen, dass ich vor dem "Verkleinern" mehr Programmzeilen hatte, und das Ganze auch effizienter gestaltet war (ich kenne natürlich BASIC ...


Tja, und ich hatte angenommen, daß es jetzt - nachdem das Ganze in der Form gar nicht eingereicht worden ist - noch darum ginge, da ein wenig mehr Speed herauzukitzeln. Zumal das ja oben auch mal so angedeutet worden ist:

Auf Rechnern ab 286 läuft es ganz manierlich, bei einem PC/XT oder auch bei einem Schneider PC 1512 ist es in der "Endstufe" etwas langsamer als gewollt.


... hätte für den Wettbewerb sowie eine andere Art der Beschränkung ausgewählt, keine Zeilenanzahl, sondern die Größe von 1KB wäre meine Grenze gewesen. Dann hätte ich auch viele Dinge einfacher gestalten können, auch wenn die Zeile dadurch länger als 80 Zeichen wird.

Die Größengrenzen sind halt einfach üblicher. 80 Zeichen finde ich ja schon deshalb interessant, weil es mal was Neues für solche Wettbewerbe ist (kannte ich zumindest noch nicht als Vorgabe) und man kann dann die Listing schön lesen und gut ausrucken - auch wenn das auf Retina und 4K Displays relativiert wird

Und zur Zeile 60 - nein, da kannst Du nichts zu einem fixen String zusammenfassen, weil ja jedesmal die Position der "Strasse" neu bestimmt wird.

Na, wenn Du meinst.

Ich kann auch gerne eine geschwindigkeitsoptimierte Version noch posten, aber die wird dann definitiv mehr Zeilen haben - das war aber vorrangig nicht mein Ziel gewesen.

Würde ich gut finden. Gucke ich mir gerne an und vielleicht ja der ein oder andere auch. Sowas ist meist ganz spannend, insbesondere im Vergleich vorher / nachher und in Relation zum dadurch erreichten Effekt.

Peter z80.eu

Z80 Anbeter

  • »Peter z80.eu« ist männlich
  • »Peter z80.eu« ist der Autor dieses Themas

Beiträge: 1 185

Wohnort: Mainz Umgebung

Lieblingscomputer: Kaypro 4

  • Nachricht senden

9

Freitag, 11. März 2016, 17:53


[...]
Ich kann auch gerne eine geschwindigkeitsoptimierte Version noch posten, aber die wird dann definitiv mehr Zeilen haben - das war aber vorrangig nicht mein Ziel gewesen.

Würde ich gut finden. Gucke ich mir gerne an und vielleicht ja der ein oder andere auch. Sowas ist meist ganz spannend, insbesondere im Vergleich vorher / nachher und in Relation zum dadurch erreichten Effekt.


Na dann schau mal in mein vorheriges Posting. Ansonsten, wenn das hier in Stress ausartet, mache ich so was lieber in meinem Blog publik.
Dann schreibe doch einfach mal selbst ein Spiel mit derart wenig Zeilen und zeig' mir dann damit, wie es besser geht...
"Wäre das Pferd eine Katze gewesen, dann wäre es den Baum hochgeritten" --- Und schaut auch mal bei meinem Blog vorbei ...

helixrider

machine addict

Beiträge: 247

Wohnort: 64653 Lorsch

Lieblingscomputer: VC-20

  • Nachricht senden

10

Samstag, 12. März 2016, 11:53

Hallo Peter,

ich finde es klasse, dass Du uns daran teilhaben lässt. Bitte gerne weiter hier posten! ;-)

VG Michael

Peter z80.eu

Z80 Anbeter

  • »Peter z80.eu« ist männlich
  • »Peter z80.eu« ist der Autor dieses Themas

Beiträge: 1 185

Wohnort: Mainz Umgebung

Lieblingscomputer: Kaypro 4

  • Nachricht senden

11

Samstag, 12. März 2016, 12:30

Nachtrag: Beim Kopieren der letzten Zeile der "geschwindigkeitsoptimierten" Version ist etwas verloren gegangen. Die letzte Zeile soll heissen: 150 IF K$="q" THEN LOCATE 23,1:END ELSE 30
"Wäre das Pferd eine Katze gewesen, dann wäre es den Baum hochgeritten" --- Und schaut auch mal bei meinem Blog vorbei ...

Toast_r

2. stellvertr. Vorsitzender

  • »Toast_r« ist männlich

Beiträge: 3 655

Wohnort: 51.32,6.48544

Lieblingscomputer: CBM 720

  • Nachricht senden

12

Samstag, 12. März 2016, 14:57

Ich hätte Lust, das ganze mal in das puristischere Commodore Basic zu übersetzen, um es mal auf meinem Lieblingsrechner auszuprobieren.
Daher ein paar Fragen zum hier verwendeten Basic:
Was hat es mit DEFINT A-Z auf sich?
Was beduten die Variblennamen mit Ausrufezeichen?
Wie funktioniert TIMER?

Gruß
Christian

Microprofessor

NOP NOP NOP

  • »Microprofessor« ist männlich

Beiträge: 3 525

Wohnort: Berlin

Lieblingscomputer: Antikythera

  • Nachricht senden

13

Samstag, 12. März 2016, 15:26

Was hat es mit DEFINT A-Z auf sich?
Was beduten die Variblennamen mit Ausrufezeichen?

Mit DEFINT werden alle danach aufgeführten Variablen als Integer definiert.
Das Ausrufezeichen macht im Prinzip dasselbe für diejenige Variable, hinter der es steht.
»Retrocomputing ist kein Heimatfilm der Computerkultur.« (Wolfgang Ernst)
»Die Geschichte des Computers ist zu wichtig, um sie den Historikern zu überlassen.« (Raúl Rojas)

Computerarchäologie | About me | Blog | Sammlung | Job

Peter z80.eu

Z80 Anbeter

  • »Peter z80.eu« ist männlich
  • »Peter z80.eu« ist der Autor dieses Themas

Beiträge: 1 185

Wohnort: Mainz Umgebung

Lieblingscomputer: Kaypro 4

  • Nachricht senden

14

Samstag, 12. März 2016, 16:28

Die Erklärung von Microprofessor sind absolut korrekt, wenn Du hinter den Variablennamen ein % anhängst, sind diese vom Typ INTEGER, wenn Du ein ! anhängst, sind diese vom Typ FLOAT/DOUBLE.
Das macht man, um genau an den Stellen die Variablentypen zu nutzen, die tatsächlich nur benötigt werden. INTEGER Variablen sind normalerweise wesentlich schneller vom BASIC Interpreter abgearbeitet.
Das $ hinter String-Variablen kennst Du ja sicherlich bereits.

Du kannst prinzipiell alle TYP-Definitionen in BASIC weglassen, dann wird die Abarbeitung der Operationen mit den Variablen langsamer, und vielleicht das eine oder andere Mal auch nicht so, wie man es will (z.B. bei INTEGER = keine Nachkommastellen).

TIMER beinhaltet prinzipiell die Uhrzeit in einer bestimmten Einheit (wesentlich kleiner als 1 Sek). Das kannst Du ausprobieren, indem Du einfach in einem BASIC-Interpreter auf dem PC schnell hintereinander PRINT TIMER und dann erneut PRINT TIMER eingibst.
Genau gesagt ist TIMER die Anzahl der Sekunden seit Mitternacht/System-Reset, aber nicht als 16-Bit INTEGER, sondern als FLOAT. Daher kommen dann auch Kommazahlenwerte bei der Ausgabe heraus.

TIMER wird in BASIC Programmen genutzt, um CPU-Speed unabhängig Zeiten abmessen zu können.
Wenn Du also z.B. ZEIT!=TIMER eingibst, dann eine Sekunde wartest, und dann PRINT TIMER-ZEIT! eingibst, kriegst Du die Differenz von 1 Sek. als FLOAT Zahl ausgegeben.
"Wäre das Pferd eine Katze gewesen, dann wäre es den Baum hochgeritten" --- Und schaut auch mal bei meinem Blog vorbei ...

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Peter z80.eu« (12. März 2016, 16:36)


Toast_r

2. stellvertr. Vorsitzender

  • »Toast_r« ist männlich

Beiträge: 3 655

Wohnort: 51.32,6.48544

Lieblingscomputer: CBM 720

  • Nachricht senden

15

Samstag, 12. März 2016, 16:57

Danke für die Erklärungen.
Das bedeutet für die Umsetzung, daß ich mit den ganz normalen Gleitkomma-Variablen arbeiten werde, da bei Commodore Basic meines wissens Integer langsamer verarbeitet werden.
Die Kennzeichnung für Integer ist dabei übrigens auch %.
Bei Commodore Basic gibt es zwei Variablen für den Timer.
TI startet beim Rechnerstart mit 0 und wird 60 mal in der Sekunde um 1 erhöht, bei CBM-II Maschinen 10 mal in der Sekunde.
TI$ enthält die aktuelle Uhrzeit im Format HHMMSS. Da keine Echtzeituhr vorhanden ist, steht sie beim Rechnerstart auf 000000.
Gestellt wird die Uhr einfach durch eine entsprechende Wertzuweisung der Variable.

Ich denke, da werde ich mich heute abend mal dransetzen. :)

ThoralfAsmussen

Fortgeschrittener

Beiträge: 382

Wohnort: Dresden (nahebei)

Lieblingscomputer: Archimedes

  • Nachricht senden

16

Samstag, 12. März 2016, 19:44

Die fertige Commodore Routine wird dann hier vorgestellt ? Wäre sicher nett, so als Vergleich.

Ich hatte auch ein paar Sachen nachgucken müssen bezüglich dem M$ Basic (u.a. auch dieses DEFINT) und dabei haben sich diese Seiten als besonders brauchbar erwiesen
http://www.antonis.de/qbebooks/gwbasman/
http://www.petesqbsite.com/sections/tuto…tutorials.shtml

Das erste ist schön clean und sehr brauchbar (fast wie ein echtes Handbuch) zum schnellen Nachsehen, das zweite eine absonderliche Anhäufung von irgendwie allem rund um das Thema QBasic etc., gut für einge Stunden "einlesen".

Toast_r

2. stellvertr. Vorsitzender

  • »Toast_r« ist männlich

Beiträge: 3 655

Wohnort: 51.32,6.48544

Lieblingscomputer: CBM 720

  • Nachricht senden

17

Samstag, 12. März 2016, 19:53

Kann ich gerne nacher hier einstellen.
Bin gerade noch am probespielen, sieht schon ganz brauchbar aus. :)

Toast_r

2. stellvertr. Vorsitzender

  • »Toast_r« ist männlich

Beiträge: 3 655

Wohnort: 51.32,6.48544

Lieblingscomputer: CBM 720

  • Nachricht senden

18

Samstag, 12. März 2016, 20:59

Ich habe erstmal eine 40-Zeichen Veriante für PET/CBM gemacht.
Mit der Geschwindigkeit bin ich noch nicht so recht zufrieden, da ist aber noch einiges rauszuholen.
Die Umsetzung ist bisher noch sehr stark an das Original angelehnt.
Ich möchte das noch an die CBM-Eigenheiten anpasen.
Die Fahrbahn ist nur 5 Zeichen breit, damit ist das ganze trotz der eher niedrigen Geschwindigkeit noch etwas fordernd ist.
Die ganzen {irgendwas} Ausdrücke sind die Commodore-üblichen Cursor-Steuerzeichen.

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
    1 p=32768+40*11:rem start screen-ram+cols per line*lines
   10 d=ti:s=rnd(ti)*20+10:c=s+2:o=c:print"{clr}";
   20 print"{down}{down}{down}{down}{down}{down}{down}{down}{down}":fori=1to14:printtab(s)"!     !":next:z=0:v=.3
   30 c=int(c):r=int(rnd(ti)*7):m=0:ifr<3thenm=-1:goto40
   31 ifr>3thenm=1
   40 print"{home}{down}km:"z" vmax:"310-int(v*1000):s=s+m
   50 ifs>32thens=32:goto60
   51 ifs<1thens=1
   60 print"{home}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}"tab(s)"!     !":t=peek(p+c):z=z+10
   70 print"{home}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}"tab(c)"*{up}{up}":printtab(o)" ":ift=32theno=c:goto88
   80 print"{home}{down}{down}{rvon}crash!{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}":end
   88 ifti<d+60goto110
   90 ifv>.1thenv=v-.01:goto100
   91 ifv>.05thenv=v-.005:goto100
   92 v=v-.001
  100 d=ti:ifv<0thenv=0
  110 getk$:t=ti+v*60
  111 ifti<tgoto111
  130 ifk$="n"thenc=c-1
  140 ifk$="m"thenc=c+1
  150 ifk$="q"goto200
  160 goto30
  200 print"{home}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}":end

Peter z80.eu

Z80 Anbeter

  • »Peter z80.eu« ist männlich
  • »Peter z80.eu« ist der Autor dieses Themas

Beiträge: 1 185

Wohnort: Mainz Umgebung

Lieblingscomputer: Kaypro 4

  • Nachricht senden

19

Samstag, 12. März 2016, 21:51

Wow. Wusste gar nicht das der Commodore auch so was wie TIMER hat...
Die Ausgabe der vielen Zeichen zur Bildschirmsteuerung bremsen das wirklich aus. Kann man beim CBM nicht auch direkt auf die jeweilige Bildschirmposition per POKE schreiben ? Das passende PEEK hast Du ja auch schon genutzt....
"Wäre das Pferd eine Katze gewesen, dann wäre es den Baum hochgeritten" --- Und schaut auch mal bei meinem Blog vorbei ...

Toast_r

2. stellvertr. Vorsitzender

  • »Toast_r« ist männlich

Beiträge: 3 655

Wohnort: 51.32,6.48544

Lieblingscomputer: CBM 720

  • Nachricht senden

20

Samstag, 12. März 2016, 22:07

Genau das ist auch mein Ansatz, das ganze zu beschleunigen.
Die richtige Position im Bildschirmspeicher zu errechnen ist sicher um einiges schneller, als die ganze Cursor-Hampelei.

Toast_r

2. stellvertr. Vorsitzender

  • »Toast_r« ist männlich

Beiträge: 3 655

Wohnort: 51.32,6.48544

Lieblingscomputer: CBM 720

  • Nachricht senden

21

Sonntag, 13. März 2016, 17:05

Hier mal eine Geschwindigkeitsoptimierte Version für PET/CBM,
geeignet für Rechner mit 40 und 80 Zeichen pro Zeile.
Nebenbei past das ganze jetzt in 10 Zeilen mit jeweils maximal 80 Zeichen.
Das Programm ist 531 Bytes klein und würde somit auch auf einer Maschine mit 1 kB Ram laufen. :)

Was ich verändert habe:

Die Initialisierung ist ans Programmende verschoben.
Das hat den Vorteil, daß die erste Zeile der Hauptschleife direkt die zweite Programmzeile ist.
Damit wird diese beim GOTO, das vom Ende der Hauptschleife wieder dorthin zurückspringt, schneller gefunden.
Beim Commodore Basic wird bei jedem GOTO oder GOSUB die angeforderte Programmzeile vom Anfang des Programms an gesucht.

Die aufwendigen Cursorpositionierungen sind aus der Hauptschleife fast vollständig rausgeflogen.
In der Hauptschleife wird über PRINT nur noch die Statuszeile ausgegeben (und vor dem Scrollen wieder gelöscht), und der Cursor einmal eine Zeile nach oben gesetzt.
Die Statuszeile ist in die unterste Bildschirmzeile gewandert, das Spielfeld endet eine Zeile darüber.
Dadurch bleibt der Cursor immer in den untersten Zeilen, und muß nicht über den ganzen Bildschirm wandern.
Nur noch beim initialen Bildaufbau und beim Programmende nach einer Kollision gibt es umfangreichere Cursorpositionierungen.

Die meisten IF-THEN Verzweigungen bezogen sich auf Berechnungen.
Das bietet Einsparungspotential: Die Vergleichsoperationen kann man direkt in die Berechnungen einbauen.
Eine unwahre Bedingung (1>1) hat den Wert 0, eine wahre (1=1) den Wert -1.
Da muß dann garnicht nicht mehr verzweigt werden.

Im Originalprogramm wurde die Beschleunigung geschwindigkeitsabhängig mit mehreren IF-THEN Verzweigungen verändert.
Ich habe stattdessen eine einzelne Formel verwendet, die ebenfalls Geschwindigkeitsabhängig beschleunigt.

Und schließlich habe ich noch die Abfrage auf die Taste 'Q' zum Beenden entfernt.
Wenn man vorzeitig beenden will, kann man stattdessen, wie weiter oben schonmal vorgeschlagen, in die Bande fahren.

Möglicherweise gibt es noch ein minimales Einsparungspotential:
Ich nehme an, daß der Zugriff auf (numerische) Variablen schneller ist, als auf entsprechende Konstanten im Programmtext, da die Konstanten aus dem Programmtext, bevor sie verwendet werden können, erst in Gleitkommazahlen umgewandelt werden müssen. Somit gäbe es also noch ein paar Prozessortakte rauszukitzeln. :)

Für weiter Optimierungsideen bin ich durchaus offen. :)

Quellcode

1
2
3
4
5
6
7
8
9
10
    0 b=32768:goto7:rem beginn bildschirmspeicher
    1 pokeg+c,160:t=peek(j+c):print"km:"z" v:"int(310-v/.1)"{up}":z=z+10
    2 r=int(rnd(ti)*7):s=s+(r<3)-(r>3):s=s+(s>a)-(s<1):pokek+s,102:pokek+s+f,102
    3 getk$:o=c:ift<>32thenprint"{rvon}{home}{down}{down}{down}{down}{down}{down}  * crash *  {rvof}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}":end
    4 ifnoththenv=v-(v/25):l=(ti+v):v=-v*(v>.05):h=(v=0)
    5 ifti<lgoto5
    6 c=int(c+(k$="n")-(k$="m")):pokeg+o,32:print"                      ":goto1
    7 print"{clr}{down}.":e=80+40*(peek(b+40)=46):print"{clr}{down}{down}{down}{down}{down}{down}{down}{down}{down}":g=b+e*10:j=g+e
    8 v=31:f=e/8+1:k=b+e*23:d=ti:s=int(rnd(ti)*e/4+e/8):c=s+f/2+1:a=e-f-3
    9 fori=1to13:printtab(s)"{CBM-+}"spc(f-1)"{CBM-+}":next:print:o=c:goto1

22

Sonntag, 13. März 2016, 18:47

Wow. Wusste gar nicht das der Commodore auch so was wie TIMER hat.....


Doch, doch :-)

Aber ich glaube mich zu erinnern, dass der schicke Timer von E/A-Operationen (mindetstens) auf externe Geräte gebremst wird.
Damit würde er (TI und TI$) sich nicht für Zeitmessungen eignen.

Toast_r

2. stellvertr. Vorsitzender

  • »Toast_r« ist männlich

Beiträge: 3 655

Wohnort: 51.32,6.48544

Lieblingscomputer: CBM 720

  • Nachricht senden

23

Sonntag, 13. März 2016, 18:59

Zumindest bei den PET/CBM Rechnern laufen TI und TI$ auch bei Disk-Operationen unbeeindruckt weiter.
Die laufen genauso, wie die z.B. Tastaturabfrage auch, im Interrupt.
Daher kann man auch während man ein Programm lädt, schonmal blind 'run' in den Tastaturpuffer eingeben.
Bei den Homecomputern mag das anders sein, das weiß ich nicht.

Peter z80.eu

Z80 Anbeter

  • »Peter z80.eu« ist männlich
  • »Peter z80.eu« ist der Autor dieses Themas

Beiträge: 1 185

Wohnort: Mainz Umgebung

Lieblingscomputer: Kaypro 4

  • Nachricht senden

24

Sonntag, 13. März 2016, 19:37

Hut ab.... mach' mal ein Screenshot vom laufenden Spiel auf dem Commodore....

Davon abgesehen habe ich auch mal was dran geschraubt, aber jetzt war nur der Ausbau der Funktionalität entscheidend, nicht die "Kleinheit" des Programms.
Bitte ausprobieren....

Ich habe endlich die Zufälligkeit der Kurven korrekt in den Griff bekommen, und kann dadurch eine echten Schwierigkeitsgrad-Änderung herbeiführen (kurviger oder weniger kurviger).
Habe auch noch etwas Farbe und Wiese mit Gras hinzugefügt, einen Programmtitel, eine Auswahl am Schluß, und ausserdem die Punktezählung (Score) dem Schwierigkeitsgrad angepasst, den man auswählt ;-)
»Peter z80.eu« hat folgende Bilder angehängt:
  • fast4a.jpg
  • fast4b.jpg
  • fast4c.jpg
»Peter z80.eu« hat folgende Datei angehängt:
  • FAST4.zip (20,02 kB - 28 mal heruntergeladen - zuletzt: 16. März 2017, 10:37)
"Wäre das Pferd eine Katze gewesen, dann wäre es den Baum hochgeritten" --- Und schaut auch mal bei meinem Blog vorbei ...

ThoralfAsmussen

Fortgeschrittener

Beiträge: 382

Wohnort: Dresden (nahebei)

Lieblingscomputer: Archimedes

  • Nachricht senden

25

Sonntag, 13. März 2016, 21:20

... Die meisten IF-THEN Verzweigungen bezogen sich auf Berechnungen.
Das bietet Einsparungspotential: Die Vergleichsoperationen kann man direkt in die Berechnungen einbauen.
Eine unwahre Bedingung (1>1) hat den Wert 0, eine wahre (1=1) den Wert -1.
Da muß dann garnicht nicht mehr verzweigt werden.

Im Originalprogramm wurde die Beschleunigung geschwindigkeitsabhängig mit mehreren IF-THEN Verzweigungen verändert.
Ich habe stattdessen eine einzelne Formel verwendet, die ebenfalls Geschwindigkeitsabhängig beschleunigt.
...

Für weitere Optimierungsideen bin ich durchaus offen. :)

Das mit den TRUE/FALSE Werten ist eine witzige Variante. Habe ich auch schonmal wo gesehen, aber insbesondere die Seitenbegrenzungen damit festzulegen ist schon sehr nett (ich war da auch ein bißchen am Rumbasteln mit s=ABS(s+r) und dann irgendwelchem AND Zeugs zur Begrenzung auf z.B. 63 max. - das da ist aber schon eleganter).

Allerdings, bei der Zufallsbestimmung der Kurvenrichtung würde wohl auch reichen

Quellcode

1
2 r=int(rnd(ti)*3)-1:s=s+r


und das Berechnen der aktuellen Geschwindigkeit muß nicht direkt im PRINT Befehl erfolgen (2) (

Quellcode

1
int(310-v/.1)
) sondern kann auch einmal beim Neufestlegen von v (4) geschehen und in einer Variablen landen.

Na ja, spart zusammen also 3 Zeichen und 0.2 µsec - ob man das dann Optimierungsidee nennen darf ... ?


Ach, und: Die grüne Wiese im QBasicEXE macht was her.
Prinzipiell hat aber noch der Abfragemechanismus (Testen auf Randsymbol bzw. NichtSPACE) das kleine Problem, daß man an bestimmten Stellen die Bahn verlassen kann. Dürfte auch für die CBM Version gelten. Das klappt immer dann, wenn man quasi diagonal durch zwei versetzt übereinanderstehende Striche "rutscht". Einfachste Abhilfe wäre eine doppelte Fahrbahnbegrenzung ( || ), da kann der Rest großenteils unverändert bleiben.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ThoralfAsmussen« (13. März 2016, 21:26)


Peter z80.eu

Z80 Anbeter

  • »Peter z80.eu« ist männlich
  • »Peter z80.eu« ist der Autor dieses Themas

Beiträge: 1 185

Wohnort: Mainz Umgebung

Lieblingscomputer: Kaypro 4

  • Nachricht senden

26

Sonntag, 13. März 2016, 22:39

Das mit den Kurven kann man dann so lösen, wenn einem das mit der Häufigkeit der Kurven völlig egal ist (also mit RND(TI)*3 oder so, trinäres Ergebnis).
Im Ungünstigsten Fall hat man dann ein ständiges Hin- und Hergezuckel der Strasse, ohne das wirklich eine grössere Kurve entsteht.

Da bin ich ganz stolz auf meine neue Lösung, die in meiner erweiterten Version jetzt zum Tragen kommt - da kann ich nämlich die Wahrscheinlichkeit einer Kurve bestimmen, indem ich die Anzahl der Decrements/Increments mitzähle, d.h. im Klartext man muss mehr als einmal nach rechts oder nach links (-1 oder +1) hintereinander wirken lassen, dann wird's auch was mit den Kurven.

Das mit den Ausbüchsen aus der Begrenzung kannst in meiner neuen Version mal ausprobieren, wird Dich nicht weit bringen, weil Du auf die Grasbüschel ('w') stossen wirst - die wirken nämlich wie die Begrenzung und erzeugen auch einen Unfall ;-)
"Wäre das Pferd eine Katze gewesen, dann wäre es den Baum hochgeritten" --- Und schaut auch mal bei meinem Blog vorbei ...

27

Montag, 14. März 2016, 17:11

Zitat

Das bedeutet für die Umsetzung, daß ich mit den ganz normalen Gleitkomma-Variablen arbeiten werde, da bei Commodore Basic meines wissens Integer langsamer verarbeitet werden.

Wieso das? Versuchshalber habe ich folgendes im VirtualC64 laufen lassen:

Quellcode

1
2
3
4
10 T=TI
20 FOR ABC=1 to 10000
30 NEXT
40 PRINT TI-T

Als Ergebnis wird 702 ausgegeben.

Zitat

Die Kennzeichnung für Integer ist dabei übrigens auch %.

Selber Versuch mit Integer-Zahlen indem ich Zeile 20 ändere in

Quellcode

1
20 FOR ABC%=1 to 10000

bekomme ich ein ?SYNTAX ERROR IN 20.

Quellcode

1
2
ABC%=123
PRINT ABC%

funkioniert aber.

Um Erleuchtung bittend,
Mr. AMS (der britische BASIC-Dialekte gewohnt ist)

ThoralfAsmussen

Fortgeschrittener

Beiträge: 382

Wohnort: Dresden (nahebei)

Lieblingscomputer: Archimedes

  • Nachricht senden

28

Montag, 14. März 2016, 18:10

Gute Frage. Im Handbuch hier steht, daß Integer für arithmetische und Vergleichsoperationen in Gleitkomma umgewandelt wird. Deshalb macht es wohl Sinn Integer nur zu verwenden, wenn logische Operationen damit gemacht werden oder Speicherstellen abgebildet werden.

Zur FOR-NEXT Problematik sagt das Handbuch nur
"NOTE: You cannot use an integer variable (1%) as the counter variable."

ThoralfAsmussen

Fortgeschrittener

Beiträge: 382

Wohnort: Dresden (nahebei)

Lieblingscomputer: Archimedes

  • Nachricht senden

29

Montag, 14. März 2016, 18:16

Die Kurven sind, zugegebenermaßen, deutlich schöner geworden.
Und jetzt für iPhone umbauen und Werbeklicker dazusetzen - und fertig ist vielleicht das neue FlappyBird. :)

30

Montag, 14. März 2016, 18:45

Zitat


FOR ABC%=1 to 10000
bekomme ich ein ?SYNTAX ERROR IN 20.

ABC%=123
PRINT ABC%
funkioniert aber.

Um Erleuchtung bittend,
Mr. AMS (der britische BASIC-Dialekte gewohnt ist)


Hm... Liegt es evtl. am Variablennamen? Beim C64 kann sowas passieren, wenn man reservierte "Worte" benutzt.
Oder geht es vielleicht mit Integern% allgemein nicht als Schleifenvariable?

Thema bewerten