Der unique selling point für einen neuen Retro-artigen Lern- und Spielcomputer wäre für mich:
"Du kannst mit dem Teil einfache 2D Retro-Spiele recht einfach selbst coden."
"Wir nehmen Dich bei der Hand und geben dir genau das eine Toolset, womit das hier gemacht werden kann."
"Wir verstecken keine Komplexität, sondern erklären schrittweise die ganze Kiste von oben bis unten".
"Wenn Du die Kiste irgendwann super beherrschst, kann Du vielleicht so coole Sachen damit machen, wie wir es nicht erwartet hatten."
Alles ist offen und nachvollziebar: Tools, Sprache, OS/ROM, Systemarchitektur, Prozessor, Grafik- und SoundchipDanke fuer die Zusammenfassung dessen, um was fuer einen Rechner es hier im Thread aktuell geht
Also für mich liest sich das wie eine Beschereibung des C64. (-;
Foristen gibt, die sich unter einem modernen Retrorechner immer noch gerne ein 8 Bit-System vorstellen wie den Mega65 in der Erwartung, daß so ein Rechner dann so leicht bedienbar sei wie der C64. Das ist nach allem, was ich bisher sehen konnte, allerdings weder beim Mega65 noch beim C256 Foenix noch beim Commander X16 der Fall.
Ich bin ja von der C64-Fraktion, aber die Bedienung sollte doch auf den neuen Rechnern schon leichter sein? Modernerer Editor, bequemere Sprache?
ZeHas Pseudocode inspirierte mich, mal zu sehen, wie sich auf dem C64 die Bequemlichkeit beim Programmieren steigern lässt, also habe ich mir das auch mal vorgenommen und in C64-BASIC umgesetzt, mit dem Ziel, dabei den neuen Befehlen nahe zu kommen.
Dazu habe ich zu Beginn des Programms einige intuitiv benannte "Konstanten" definiert, dazu eine Byte-Tabelle und Arrays zur Sprite-Positionierung und -Datenzuordnung.
Die "Befehle", um aus numerischen Daten oder einer String-Matrix Sprites zu erzeugen, sind nun Unterprogramm-Aufrufe, nachdem Sprite-Nummer, -Position und Formdefinition im Hauptprogramm angegeben wurden.
Das eine Unterprogramm erzeugt aus den numerischen Daten 8x8-Sprites (der restliche Sprite-Datenbereich wird mit Nullen aufgefüllt), das andere erzeugt aus einer String-Matrix ein vollständiges Sprite. Das Programm ist also quasi auch ein spartanischer Sprite-Editor.
Für gesetzte Bildpunkte bot sich dabei das PETSCII-Zeichen "ausgefülllter Kreis" an, damit ist die Form schon im Code recht gut erkennbar (es lässt sich aber auch jedes andere Zeichen verwenden, alles außer einem Punkt gilt als gesetzt):
Screenshot während des Programmablaufs, bevor Sprite 1 diagonal über den Bildschirm fliegt:
Ich hatte gehofft, ZeHas 8x8-Daten ergeben was Schönes, aber war wohl aus dem Zufallsgenerator. (-; Wobei Sprite 1 (links, rot) mit etwas Fantasie kniend einen Bogen spannt. (-:
Fazit: Ist das Gerüst (Definitionen am Anfang und Unterprogramme) mal gebastelt, ist die Sprite-Handhabung recht ähnlich einfach wie mit den ausgedachten Befehlen im Pseudocode. Freilich ist dann da der Gerüst-Ballast, und das Einlesen der String-Matrix ist BASIC-typisch gemächlich (ginge vielleicht etwas schneller, bin nicht so der Code-Optimierer). Vielleicht krame ich mal einen Compiler raus.
Der Code (umgewandelt mit PETCAT):
- 100 rem sprite-demo
- 102 rem ===========
- 110 :
- 120 rem sprechende konstanten
- 122 rem ---------------------
- 130 cs$="{clr}":bo=53280:bg=53281:co=646:v=53248
- 140 :
- 150 rem spritepos-regs in spr. arrays
- 152 rem -----------------------------
- 160 for i=0to7
- 170 x(i)=v+i*2
- 180 y(i)=v+1+i*2
- 190 next
- 200 :
- 210 rem byte-tabelle (revers)
- 212 rem ---------------------
- 220 j=7:for i=0to7:by(i)=2^j:j=j-1:next
- 230 :
- 240 rem sprite-data-zuordnung
- 242 rem ---------------------
- 260 data 2040,11,704,2041,13,832,2042,14,896,2043,15,960
- 280 for i=0to3
- 290 :for j=0to2
- 300 :read sd(i,j)
- 310 :next
- 320 next
- 330 :
- 340 rem hauptprogramm
- 342 rem =============
- 350 :
- 360 print cs$
- 370 poke bo,0:poke bg,0:poke co,5
- 380 print"this is an example{down}"
- 390 :
- 400 for i=1to5
- 410 poke co,i
- 420 print"gemuese":rem plausibler als bunte wurst
- 430 next
- 440 :
- 450 sp=1:x=50:y=150:gosub 900
- 460 rem 8x8num sprite
- 470 data 32,64,73,254, 77, 80,24,57
- 480 :
- 490 sp=2:x=100:y=150:gosub 900
- 510 data 70,50,20, 30,128,144,27, 0
- 520 :
- 530 sp=3:x=150:y=150:gosub 1000
- 540 rem string sprite
- 550 data"........................
- 560 data"......QQQQ..............
- 570 data".....Q....Q.............
- 580 data".....Q....Q.............
- 590 data"......Q..Q..............
- 600 data".....Q....Q.............
- 610 data"....Q......Q............
- 620 data"...Q.QQ..QQ.Q...........
- 630 data"..Q.Q.Q..Q.Q.Q..........
- 640 data"...Q..Q..Q..Q...........
- 650 data"......Q..Q..............
- 660 data".....Q.QQ.Q.............
- 670 data"....Q.Q..Q.Q............
- 680 data"....Q.Q..Q.Q............
- 690 data"...QQQQ..QQQQ...........
- 700 data"........................
- 710 data"........................
- 720 data"........................
- 730 data"........................
- 740 data"........................
- 750 data"........................
- 760 :
- 770 x=64:y=48:rem sprite 1 position:
- 780 poke x(1),x:poke y(1),y
- 790 x=x+2
- 800 y=y+1
- 810 if x>240 or y>216 then end
- 820 goto780
- 830 :
- 890 rem unterprogramme
- 892 rem ==============
- 893 :
- 894 rem 8x8num sprite
- 895 rem -------------
- 900 poke sd(sp,0),sd(sp,1)
- 910 dc=sd(sp,2):rem init data counter
- 920 for i=0to7
- 930 read ds:poke dc,ds
- 940 poke dc+1,0:rem auffuellen
- 950 poke dc+2,0
- 960 dc=dc+3
- 962 next
- 964 for i=1to39:rem auffuellen
- 966 poke dc+i,0
- 968 next
- 972 poke v+21,peek(v+21) or 2^sp
- 974 poke x(sp),x:poke y(sp),y
- 976 :
- 978 return
- 980 :
- 990 rem string sprite
- 992 rem -------------
- 1000 poke sd(sp,0),sd(sp,1)
- 1070 dc=sd(sp,2):rem init data counter
- 1080 for i=1to21
- 1090 :read ds$
- 1100 :for j=0to2
- 1110 : for k=8to1 step-1
- 1120 : bi$=mid$(ds$,k+j*8,1)
- 1130 : if bi$="."then bi=0:goto1150
- 1140 : bi=1
- 1150 : by%=by%+bi*by(k-1)
- 1160 : next
- 1170 : poke dc+j,by%:by%=0
- 1180 :next:dc=dc+3
- 1190 next
- 1200 poke v+21,peek(v+21)or 2^sp
- 1210 poke x(sp),x:poke y(sp),y
- 1220 return
PRG-Datei: