Přibylo nám nové video, a protože se nehodí do Videocastu, stává se nám ze 3-5minutových videí malý seriál.
To, že Sinclair QL je velmi inteligentní počítač, a dokáže odpovědět i na velmi složité otázky, víme.
Pokud ne, zkuste si následující:
Sinclair QL ale umí ještě něco.
Na minulém 3-5minutovém videu jsme viděli, jak PP-01 (jehož grafické možnosti po hardwarové stránce odpovídají lo-res režimu na Sinclairu QL) počítá Mandelbrotův fraktál.
Na YouTube najdete populární videa průletů fraktály. Jsou mnohobarevné, dlouhé (třeba i 12 nebo 20 minut) a jdou vpravdě do hloubky (2 na 270).
Pravda, moderním postupům, kdy jsou fraktály generované ve FPGA nebo GPU, či se na nich podílí 8 jader procesoru, lze těžko konkurovat, zvláště, pokud se nechceme pouštět do vod assembleru či C a chceme si na QL vystačit jen s Basicem.
Přesto i na stroji, na kterém prakticky neexistuje demoscéna, a který byl primárně určen na kancelářskou práci, jako psaní textů, počítání tabulek, kreslení grafů a hledání v databázi, je možné kouzlit a nechat se ohromovat výsledkem.
Ukázkou toho, že i na QL to jde, je demo s točící se hlavou: http://www.youtube.com/watch?v=40ByKsPB9vc
Nebo demoverze 3D hry Elite s vyplňovanými vektory: http://www.youtube.com/watch?v=eYoTSGvWf78
No a teď i nové krátké video, kterým se můžete kochat.
To dela program, ktery je videt na zacatku na obrazovce?
Ano i ne.
To, co je na obrazovce (mimochodem, ve videu s PP-01 je vidět stejný program), dělá jen část toho kouzla, ale tu nejdůležitější – počítá fraktály.
Až budu doma, vyexportuju oba programy z QL a zveřejním.
Je to totiž, vzhledem k rychlosti Basicu, "fucking pre-calc", na videu je v podstatě jen nahrávání předpočítaných obrazovek z RAMdisku.
QL tuhle sekvenci chroupalo skoro celý den. (To je ale tím, že jako hodně drsný frajer dávám 256 iterací na pixel, i když má QL jen 8 hardwarových barev – redukcí na 8 iterací by se to výrazně zrychlilo).
Mám už připravený i assemblerový program na počítání fraktálů pro Atari ST a chci ho nějak pro QL upravit, ale s assemblerem na 68000 a QL nemám zatím zkušenosti. Mohlo by to být ale o dost rychlejší a snad by to pak při optimalizaci zvládlo i realtime.
Mám sice i překladač Lattice C pro QL, ale to asi zvládnu dřív ten assembler než C.
Listing zde.
Nejprve program, který to celé generuje (donekonečna ukládá obrazovky na disk, dokud ho nezaplní nebo to nezastavíte CTRL+SPACE).
Krok je a%, já použil 10, ale ten je hrozně malý (zas je ale animace plynulá).
10 sizex%=366:sizey%=256
20 maxiter%=256
30 MODE 8:WINDOW #1,sizey%*2,sizey%,0,0
40 SCALE sizey%,0,0
45 a%=10
50 FOR x%=0 TO sizex%
60 xi=x%/a%-2
70 FOR y%=0 TO sizey%/2
80 yi=y%/a%
90 x=0:y=0
100 FOR i%=1 TO maxiter%
110 IF x*x+y*y>4 THEN EXIT i%
120 xt=xi+x*x-y*y
130 y=yi+2*x*y
140 x=xt
150 END FOR i%
160 IF i%>maxiter% THEN LET i%=0
170 INK i% MOD 256: POINT x%,y%+sizey%/2,x%,sizey%/2-y%
180 NEXT y%
190 NEXT x%
195 SBYTES "flp1_"&(a%/10),$20000,$8000
200 a%=a%+10:GO TO 50
A teď přehrávač.
Šlo by sice přehrávat rovnou z diskety, ale škube tom, když hlava po několika obrazovkách najíždí na další stopu.
Proto kopíruju do RAMdisku (v level 2 ovladačích není dynamický RAMdisk potřeba inicializovat, velikost se přizpůsobuje počtu souborů. Pokud nemáte level2 ovladače, musíte použit nějaký statický RAMdisk a naformátovat ho na správnou velikost).
Do mých 4 MB RAM se vejde v pohodě i celá ED disketa (2.8 MB).
max% je počet screenshotů na disketě.
50 max%=86
60 FOR a%=1 TO max%
70 AT 10,15:PRINT a%
80 COPY "flp1_"&a% TO "ram1_"&a%
90 NEXT a%
95 REMark — zkopirovano, a ted prehravat
100 max%=86
110 FOR a%=1 TO max%
120 LBYTES "ram1_"&a%,$20000
130 PAUSE 5
140 NEXT a%
150 GO TO 110
Ja jsem si chvili myslel, ze to bezi "realtime". Tim nechci rict, ze by me to zklamalo, i tak je to par radku basicu, ktere delaji zajimavou vec. Ten den to bezelo na QLku na te turbokarte?
Použil jsem to nejrychlejší, co jsem měl ověřeno – asi bych na to měl natočit ještě video, ale základ tohohle programu jsem měl už na Foreveru, a tam se ukázalo, že na QDOSu s turbokartou sice dochází k urychlení oproti QDOSu bez turbokarty (který mám tak jako tak urychlen, protože Minerva ROM má Basic rychlejší než starší ROM), ale při při použití SMSQ/E (které na "holém" QL nebootuje) dojde k dalšímu a dost výraznému urychlení (QDOS je psán s optimalizací na velikost, SMSQ/E na rychlost).
Takže moje kombinace bylo SMSQ/E s turbínou.
V nativním (žádná Java) emulátoru (např.QPC2) na dostatečně rychlém PC by to ale možná realtime jelo.
Uvidíme ještě, co to udělá při přepsání do assembleru.