 |
| jak-tvorit |
Jak na 256b intra |
Autor : carlos
|
“…Být kreativní znamená přemýšlet, jak mohu vylepšit sám sebe…” neznámý autor
Byl jsem nedávno požádán raistem, abych vzplodil článek o tom, jak vzniká intro, v tomto případě intro té nejmenší běžné kategorie, tedy 256 bajtů. Mno, nevím, jestli jsem na to ten nejpovolanější; nejsem žádný ostře inteligentní, nadaný, žádoucí, skvoucí coder; ale pokusím se vyhovět.
Nevím, do jaké míry má být tento článek odborný, tak snad jenom dodám, že se zde bavíme o neinteraktivních multimediálních prezentacích (záměrně omezených svou velikostí), které mají za účel co zaujmout a třeba i ukázat, co vše lze do takto stísněné velikosti možné nakódovat. Chtěl bych taky ukázat, že napsat takové intro není zas až tak těžké, jak by se na první pohled mohlo zdát.
Zatímco ostatní dema (ale i intra větších velikostí) mohou být psány v lecjakých jazycích (některé dokonce i v Javě nebo právě se rozmáhajícímu .NET Frameworku), pro tuto kategorii prakticky výlučně platí, že budeme psát v assembleru na platformě DOS2. Samotný jazyk symbolických instrukcí (tedy assembler) samozřejmě není všelék a většinou nestačí nakonec pouze přepsat problém do assembleru a tím považovat problém za vyřešený (to bychom to rovnou mohli kompilovat z Céčka a hlavně by se tím ztratila motivace coderů ve formě výzvy napsat v tomto nízkoúrovňovém jazyku něco, co může napadnout jenom člověka). Spíš bych řekl, že mnohem důležitější je rozumět filosofii tohoto jazyka a mít ten správný přístup k vymýšlení třeba i těch nejbláznivějších ale přesto dosud nepoužitých ale efektivních konstrukcí, které nicméně ve výsledku nakonec splní svůj účel. Vím, že to zní jako pitomá agitace, ale podívejte – všechna nejlepší 256bajtová intra mají ve svém kódu něco invenčního až geniálního. Tento přístup se nedá naučit na jedno posezení, určitě v tom ale pomůže trochu se touto tématikou zabývat – zkoumat kódy lepších inter, ptát se na určité problémy jiných coderů, kteří již mají něco za sebou (nejlepší časoprostor pro to je volná chvilka na nějaké demoparty, kde je koncentrace takovýchto jedinců nejvyšší). Mě se třeba ještě nestalo, že by mě někdo zkušenější s takovou otázkou odbyl, že to je tajemství nebo tak něco (vždy jenom nakládačka) – takže jediné, na čem to závisí, je vaše vlastní snaha. Ale dost agitky, pojďme na konkrétní příklad…
Možná jsou zajímavější intra, které by stálo za to rozebrat, ale ty jsem zase neměl to potěšení psát, takže vyberu něco z Broncsu: třeba na intru Transmission:Cosmic Brothers se dá pár věcí z procesu tvorby ukázat. Na začátku je – jako téměř u každého díla – vidina pěkně tučného honoráře. Ee.. pardon: nápad. Nenechte se mýlit – výběr originálního tématu pro malé intro je dost velká výzva a je mnohem těžší než implementace konvenčního intra, aneb – jinak řečeno – konvenčních inter mohou být stovky, těch revolučních je jenom pár. Cosmic Brothers se do té druhé kategorie nepočítá, ale výběr tématu dobře ilustruje, co znamená mám na mysli tou výzvou (předělat 4KB intro s AdLibovskou hudbou do šestnáctkrát menšího prostoru je samo o sobě dost opovážlivé). Rozhodně si ale vyberte něco, co nebude nad vaše síly. Jak to poznat? Bohužel, tady opět platí, že na to je potřeba zkušenost. Tu ale získáte jedině tak, že se do toho pustíte – ať už se vám to povede nebo ne, takže směle do toho. Není přece velkých a malých inter, ale velkých a malých nápadů! :-)
Mohlo by se zdát, že ta asi stovka instrukcí, jež se do 256 bajtů vejde, je natolik málo, že je zbytečné zabývat se s nějakou metodikou a od začátku vše psát v assembleru. Inu, to jsem si myslel taky a několik inter jsem začal rovnou bastlit v jazyku symbolických instrukcí. Jak to dopadlo? Nikdy jsem je nedokončil. Místo toho doporučuju zamyslet se, jak budu téma, které jsem si zvolil, řešit a pak ho přepsat buď do nějakého logicky strukturovaného pseudojazyka nebo – a to spíš – do vašeho oblíbeného vyššího programovacího jazyka. Ano, přesně tak – začněte psát čtvrtkilové intro v Céčku nebo Pascalu! On i programátor má omezenou paměť, takže se nestyďte si takto pomoct. Pěkně a pohodově v jeho útulném integrovaném prostředí, s velkorysými možnostmi ladění po jednotlivých krocích a prohlížení obsahu registrů, lokálních proměnných nebo obrazovky v tom či onom stádiu vykreslování (pokud má tedy vaše intro něco kreslit na obrazovku jako že tomu tak většinou je). Co nejvíce se připravte, než přesedláte na onen takzvaně nízkoúrovňový jazyk a jeho kompilátor – pokud je předmětem intra vykreslit nějaký obrazec nebo geometrické tvary, klidně si vše nejdřív načrtněte ve nějakém grafickém programu, rozprostřete jednotlivé prvky po obrazovce tak, aby co nejlépe lahodily vašemu oku, nespoléhejte se na vložení nějakého anonymního čísla do kódu na poslední chvíli. Napiště si i tooly pro různé převody a/nebo export do zdrojového kódu. Nakonec uvidíte, že 256bajtové intro nemůže než řešit ne příliš rozvláčný problém.
Například v případě Cosmic Brothers tento „vyšší“ kód vypadal zhruba takto:
nastav mód 13h
time:=0;
opakuj{
for barva:=0 to 63 do nastavRGB(barva,fn1(barva),fn2(barva),fn3(barva));
for x:=0 to 127 do
for y:=0 to 79 do{
color:=(abs(sin((sin(x*x/512+time/8)*32+(y-40)*3)*6.28/(250-x))*64))*(127-x)/127;
nakresliPixel(x*2,y*2+20,color);
}
čekej 1 tick
time:=time+1;
}dokud není stisknuta klávesa;
Ještě jsem chtěl dodat, že bychom měli přizpůsobit. Vidíte, že i složitě vypadající věci mohou být napsány vcelku jednoduše. V tomto případě je to skutečně primitivní cyklus, který periodicky umisťuje na určité místo na obrazovce pixel určité barvy. Její výpočet je jediná komplikovanější věc v tomto intru. Dost komplikovaná na to, aby se v ní i zkušenější assemblerista ztratil, pokud by ji měl psát „spatra“. Takže, proč bychom si nemohli pomoci tím, že si to rozepíšeme.
Tento obrázek tu není kvůli tomu, že bych Vás učil, jak napsat toto konkrétní intro, ale jako jakýsi zástupce různých pomocných obrázků, grafů, náčrtků, výpočtů atp. s důrazem na to, že je fakt výhodné si je dělat. Můžu to ukázat na konkrétním příkladu. V prvních fázích našeho intra (dělal jsem ho já s D.Mentem) byl tento výraz ještě o znatelnou část složitější a používal několik dalších konstant a celé intro zabíralo přes 200 bajtů, což byl vzhledem k našemu úmyslu použít v něm AdLib hudbu problém. Kondenzovaný blok assemblerovských instrukcí v této fázi ještě nepůsobil impresívně, působil pouze zcela nečitelně, a tedy hostilně vůči tomu, kdo do něj chtěl proniknout. Museli jsme si ho přepsat do této podoby, abychom následně viděli, že při zanedbatelné ztrátě přesnosti můžeme některé jeho části vynásobit a některé vydělit stejným číslem tak, aby se výsledek nezměnil a my přitom zopakovali stejné části výrazu jakožto do paměti uložené mezivýsledky a tím ušetřili cenné bajty strojového kódu. Bez srozumitelného a přehledného grafu bychom se v tom plácali ještě hodně dlouho. Zároveň, přepsání do koprocesorových instrukcí (vyžadující infixovou notaci do jeho zásobníku) bylo i přes složitost výrazu naprosto bez problémů. Tímhle chci říct, že Váš výsledný spustitelný 256bajtový drobeček sice je tím kýženým výsledkem, který v ideálním případě bez ztráty nervů doladíte a odevzdáte, ale takovýto a podobné pomůcky jsou taky nezbytné, a to v procesu jeho tvorby. Pro codera, mít program bez této pomocné dokumentace je asi jako pro grafika dělat výtvarný návrh pouze v jedné vrstvě: absolutně neflexibilní.
V souvislosti s tím mě teď napadla jedna věc, kterou jsem bral jako samozřejmost, ale pro jiné to samozřejmost nemusí být, takže ji připomenu: čistota kódu. To, že píšu krátký (a přiznejme si – ne zas tak užitečný, ba vpodstatě neužitečný) prográmek, ještě neznamená, že jeho zdrojový kód nemusí mít štábovou kulturu nebo že nemusí být vhodně okomentovaný či často zálohovaný! Za rok Vás napadne udělat nové intro postavené na tom, co jste dělali před rokem, podíváte se do jeho zdrojáku a zjistíte, že se v tom zaboha nevyznáte, přestože (nebo právě proto, že) kód je od Vás. Prostě se nevyplácí to odfláknout, jasný? Další kapitolkou jsou pro jazyk symbolických instrukcí typické direktivy a podmíněný překlad na základě platnosti direktiv. Pokud v určitém okamžiku vývoje dospějete do fáze, kdy máte před sebou dvě alternativy a nevíte, pro kterou se rozhodnout, neváhejte a podmiňte každou z nich podmíněným překladem – symbol, na základě kterém se přeloží ta nebo ta část intra, definujte na začátku jako jakýsi „přepínač“ kompilace. Zas tak moc práce Vám to nedá a ve finiši si budete moci velmi pohodlně zjistit, která konfigurace Vašeho právě vzniknuvšího výtvoru je ta nejlepší. Podmíněným překladem většinou zároveň logicky oddělíte určitou logickou část Vašeho intra.
Následující fáze ladění může být v nejnepříznivějším případě skoro tak dlouhá jako samotná implementace, ale já vlastně nevím, co bych k tomu mohl říci: každý na to máte svůj systém, svůj oblíbený debugger, na který jste zvyklí, a zbytek už záleží pouze na Vaší trpělivosti. Ale, mějte na paměti: nesnažíme se intro psát ale dopsat, nesnažíme se primárně rochňat ve strojovém kódu, děláme to pouze proto, abychom si čím dříve tím lépe poté mohli vychutnat výsledek.
Stovky instrukcí a žádné dogma, které by stanovovalo limit pro nejmenší možnou velikost kódu, který „dělá to a to“, musí zajisté být pro každého demoscenera-assembleristu výzvou, kterou může přijímat kolikrát se mu zlíbí. Není to otrava, je to hra, je to zkušenost, je to test sebe sama. Tak se tužte, cvičte a testuje svoje schopnosti. Nenechte se znechutit těmi, kteří říkají, že nad DOSem – domovskou platformou 256bajtových inter se zavřela hladina propadliště dějin. Chcete snad, aby vaše intra žila věčně?! (odpusťte jistou paralelu s Hvězdnou Pěchotou :) Ale, vážně…) Tímhle přece zdokonalujete sami sebe (a nepochybujte o tom, že byste vzorce myšlení, které si tímto vytvoříte, využili pouze v programování…) – tímto dokazujete svoji kreativitu – a ta je přece základní esencí demoscény.
|
|
| |
|
