Scene.hu

Sziasztok,

A felkérésnek [zargatás Discordon – a szerk.] eleget téve írnék egy kicsit demojoe 4kbyte intrók kulisszatitkairól.
Ha esetleg nincs meg hirtelen a legutóbbi demojoe prod, akkor innen letölthető:

Kezdjük is a legelején: az alapkoncepció az volt, hogy próbáljak egy vicces/rajzfilmszerű történetmesélést 4kbyte-ban összehozni, lehetőleg úgy hogy több epizódra is kitartson a dolog, valamint természetesen a történetek legyenek kapcsolatban a demoscene-nel. Mint általában a 4kbyte intrók többségében, el kell gondolkodni, hogy milyen trükköket/cseleket vessek be, és hogy hogyan tudnék belepasszírozni minél több tartalmat a produktumba.
Tovább…

Kezdjük azzal, hogy soha nem gondoltam volna, hogy 17 év húsvéti partizás után az otthonülős verzió lesz a legstresszesebb. Pedig minden az ellenkezőjére utalt: nincs 12 óra autóút, nincs kocsibérlés, nincs szervezés, nincs hidegzuhany reggelente, minden abszolút zen, erre egy elejtett kósza felmondat után vasárnapra virradó hajnali kettőkor azzal végződik az este, hogy a livecoding főszervezője, a világ legjobb shaderkodere, és a címvédő közös megegyezéssel szeretne kihívni egy meccsre másnap este, mert nyilván az jó ötlet.

Nem aludtam sokat aznap.

A rövid in medias res után foglaljuk is gyorsan össze, hogy miről is van szó azok szamara, akik nincsenek képben: az idei (online) Revision során is megrendezésre került a Shader Showdown, az éves live-coding versenyek csúcspontja, de a party során előkerült a közismert shader-legenda IQ is, a szervezők pedig rábeszélték arra, hogy játsszon egy “nem hivatalos” meccset az aktuális bajnok Flopine ellen, én meg valahogy belekeveredtem a kereszttűzbe, annak ellenére, hogy semmi tapasztalatom nincs a dologban, de mivel visszavonulót fújni sokkal cikibb mint leégni, bevállaltam, és alapvetően nem sikerült rosszul a dolog. Pár napja kiraktam egy hosszabb angol nyelvű cikket arról, hogy pontosan hogyan is készültem neki a dolognak az alatt a rövidke ~12 óra alatt ami rendelkezésemre állt, de mivel többen jelezték, hogy nem látták, itt a scene.hu hasábjain is gyorsan összefoglalnám a dolgot, hogy pontosan mi is volt a kreatív folyamat.
Tovább…

Egy demó kiadása után megírt rövid cikk arról, hogy hogyan is készült maga a termék több szerepet is szolgálhat: Egyrészt nagyon hasznos tudásbázis lehet azoknak, akik valami hasonlót szeretnének csinálni, másrészt a furcsább platformkora készült demóknál nagyon gyakran csak maga a platform történelme is tud olyan szórakoztató lenni, mint maga a demó.

Az utóbbira kiváló példa az AONDEMO nemrég kiposztolt története: A tavaly augusztusban kiadott demó már első pillantásra több kérdést vet fel, mint amennyit megválaszol – szerencsére Shiru posztja részletesen belemegy a 80-as évek végén elterjedt “AON” telefonok történelmébe, és fejti ki, hogy pontosan hogyan és miért lettek az akkori Szovjetunióban népszerűek ezek a Z80-alapú standard 7-szegmenses LCD-vel rendelkező vonalas telefonok, miket is tudtak, és hogy mi minden szenvedés árán lehetett rájuk demót írni, bár vonalas telefonhoz képest az írás tanúsága szerint meglepően sok kraft volt a vasban (Z80, 8K SRAM); mint az írásból kiderül, Shiru sikeresen pontot tett annak a városi legendának a végére is, miszerint a ROM-ban alapból szerepelt több olyan automatikus hangposta-kifejezés is, ami a nem kívánt hívót kevéssé választékos nyelvezettel küldte el melegebb éghajlatra.

Ennek a fajta írásnak majdhogynem szöges ellentéte az elmúlt év egyértelműen legjobb demójának, az EON-nak a készüléséről írt cikksorozat; itt ugyanis a TBL-es srácok egy olyan szintű nyers technikaiságot vezetnek le a kilenc cikkből álló sorozatban, ami szerintem még a combosabb Amigás kódereket is meglepi: sorra kerül a cikkekben a komplett build-system (melynek során gyakorlatilag lábjegyzetként említik meg, hogy első lépésként széthekkelték a VASM-et, mert nem volt elég jó, aztán írtak egy saját preprocesszort, mert abból sem volt elég jó, aztán írtak egy saját linkert, mert abból sem volt elég jó, aztán hekkeltek Amigára saját C fordítót, mert ami volt az nem volt elég jó, és a végén hekkeltek saját emulátort is az FS-UAE-ből, mert.. igen – és ez csak az első cikk, a többiben pedig olyan szintre lemegy a komplexitás, hogy a végefele színes zajos képekkel illusztrálja az aktuális szerző, hogy a DMA éppen mikor mit csinál a demóban. A demó komplexitásáról amúgy sokat elárul, hogy még a zenéjéről – amire talán a laikus azt hinné, hogy azt legalább relatív egyszerű volt megvalósítani – is külön cikk van.

(Ja meg én is írtam a PILEDRIVER-ről, de az ennyire nem izgi.)

Ferris / Logicoma már nagyjából két éve csobbant bele abba a manapság népszerű live-streaming / YouTube témába ahol az emberek nem csak különféle játékokkal játszanak, hanem pl. a Twitch “Creative” szekciójában játékokat készítenek, vagy általaban csak alkotnak – a legismertebb példák erre talán a Handmade Hero, vagy a William Chyr által készített Manifold Garden.

Demoscenerként nyilván a streamen keresztüli demókészítés abba a furcsa hézagba esik ahol az ember szereti mutogatni amit csinál, viszont mégis szeretné titokban tartani, hogy mivel készül – ennek a kompromisszuma talán a “post-mortem” streamelés, ahol is a party után az alkotónak lehetősége nyílik kibelezni az alkotást és belemenni adott megoldások technikai részleteibe, Ferris pedig erre kihegyezett streamjeivel ennek eleget is tesz.

Pár hónapja ezekhez a streamekhez újabb érdekességet adott: megkereste az elmúlt időszak pár ismertebb 64k intro készítőit is, és megkérte őket, hogy mutassák be a saját eszköztárukat; a Monad és a Poo-Brain után most a Conspiracy került sorra: egy kellemes 2.5 órás streamben BoyC kommentárjával megtekinthető, hogy hogyan, miben, mivel készült pl. az Offscreen Colonies.

A streamben természetesen szemlére került a tool általános felépítése, a különböző magas- és alacsony-szintű trükkök, valamint egy-két művészeti trükk is, pl. hogy hogyan lehet scifi-ablakokat csinálni a szöveg-generátorral, vagy hogy hogyan kell 64k-ban banánt csinálni.

Sziasztok,

Úgy látom, nem hemzsegnek itt az Atari 8-bit-es posztok. Ezen kívánok segíteni a következő kis videóval.

A ’90-es évek közepe óta nem láttam 6502-es kódot, de annyira elkapott a nosztalgia az elmúlt évben, hogy kénytelen voltam készíteni egy új demót. Érdekessége, hogy egy 1950 samples/sec-es basszus soft-synth-et készítettem hozzá, hogy ne a tipikus Atari (POKEY) basszust kelljen használnom. Valamint egy új grafikus üzemmódot is felvonultatok, de ehhez már Atari XL/XE grafikában megfáradt szemmel kell rendelkezni, hogy az ember észrevegye :)

Forráskód: https://bitbucket.org/sandor-hard/

Hi! Megismételtem egy régi történetet, írtam egy klienst a Rocket Editor-hoz Rust-ban. Windows, Linux és Mac-en is megy (elvileg!).  (Gyors linkek, akiknek ez már ismerős terület: leírás, client és sync crate, példa kód).

Ez egy viszonylag egyszerű dolog, de kódolás közben eszembe jutott, ahogy korábban mások, csendben magukban egy nagy CRT monitor előtt, vagy egy parti közepén együtt valakivel, Rocket klienst írtak.

Hamarosan Function lesz! Demót nem tudok küldeni, de ti majd remélem, mert várom látni a beadott prod-okat.

Demók Rust nyelven

Hagyományosan a demó írás a C/C++ nyelveken történik, mert a végeredmény mindenképp egy darab futtatható bináris fájl kell legyen, és a művészi szabadsághoz (értsd: wild hacking) kell, hogy szabadon lehessen irányítani, mi történik alacsony szinten a kódban. Illetve, a 4k – 64k kategóriákhoz ennek a méretét is erősen optimalizálni kell.

A Rust nyelv hasonlóan binárisra fordul. Újnak nevezhető, de azért már 2015-ben volt az 1.0 kiadása, és azóta már két év eltelt. Növekszik az olyan elvárt library-k száma, mint a smallvec (growable array on the stack), notify (file asset figyelés) vagy a serde (serialization to- and from structs).

Rust-ban dolgozva többet segít a compiler abban, hogy segfault mentes legyen a programunk. Minden változót végigellenőriz, és nem engedi meg például azt a helyzetet, hogy olyan változó címre írjunk ami már felszabadult, vagy valami éppen máshol is módosítja azt.

Alacsony szintű hozzáférés? Művészi szabadság? Van. Egy unsafe { ... } blokkon belül a compiler elengedi a kezünket, és vagdalkozhatunk mindenféle unsafe csatabárddal mint amilyen a mem::transmute. Idézem a Rust nomicon-t:

“Újra fogjuk értelmezni ezeket a biteket ha bele is pusztulunk!”

A compiler remek hibaüzenetekkel szolgál, gyakorlatilag a compiler üzeneteiből meg lehet tanulni használni a nyelvet.

Például jellemző az, hogy változtattam valamit egy struct-ban. Most akkor emlékezzek minden helyre ahol ez releváns? Hagyjuk rá a compiler-re. Minden helyet megtalál, ahol ki kell bővítenem a kódot, és a szerkesztőben egyik helyről a következőre ugrok amíg el nem fogynak a hibák. Ha lefordul, jó is lesz.

Rust-ban dolgozik például Ferris és Phaazon. Látta valaki az Elysian (64k!) demót vagy az Outline 2017 invite-ot? Remek demók, Rust-ban. Ferris tartott egy három órás előadást arról, hogyan működik a demotool-juk.

Logicoma – Elysian (Final version)

Outline 2017 Invitation – DESiRE & The Undead Sceners

Rocket Editor

A GNU Rocket Editor az animált változó értékek ütemezését segíti. Ad egy felületet, ahol szerkeszthetjük, hogy például épp ekkor legyen a magasság 0.5, és ez menjen felfelé 1.5-ig. Közben a fényerősség változzon 2.1-től 4.0-ig. És lássuk közben, hogy az jól néz ki vagy sem. Ezt kézzel tetűkoppasztó szenvedés összebabrálni, ebben az ütemezésben segít a Rocket.

Több változata van. Az eredeti a rocket/rocket repóban él. Én magam az emoon/rocket változatot használom Linux-on.

A kliens egy futó Rocket alkalmazáshoz kapcsolódik localhost:1338 porton, és kommunikálja ezeket a változtatásokat a demónak.

Például itt, a felső ablakban fut egy kis példa projekt, ez csatlakozik az alsó ablakban a Rocket szerkesztőhöz, ott futnak az időre ütemezett változó értékek.

Link lista:

• Bővebb leírás: Let’s try 0.5 to 1.5
• Rust nyelv
• Rocket Editor: emoon/rocket
• rocket_client és egy no_std rocket_sync crate
• rocket_example a fenti kis példa kódja

Ennyi.

Mint ahogy azt már többször hangoztattam, a Pouëtes “Work in progress”-thread igazi aranybánya, mert nemritkán látható benne egy-egy ismertebb csapattól valami érdekesség.

Ezúttal se volt másképp: most a Cocoon grafikusa, NTSC, ragadott screengrabbert és rakott össze egy kis tízperces videót arról, hogy hogyan dob össze a Cocoon demótoolban egy viszonylag egyszerű de látványos scenet:

A videó nem sokat, de mégis rengeteget mutat: Először 3dsmax-ban dob össze egy primitív scenet, azt behúzza a toolba, majd rádob néhány effektet – ez eddig nyilván egyszerűen hangzik. A trükk a részletekben rejlik:

• Ugyan pl. az object és a kameramozgatás 3dsmax-ban készül, utólag a toolban is tud kamerát beállítani – ezzel nagyon gyorsan tud több szögből megnézni egy jelenetet.
• Bár ezt csak tippelem, de ha jól látom minden kiexportált adat utánszerkeszthető a toolban is.
• Az effekteknek rengeteg paramétere ki van vezetve, így a kóder bármikor a grafikusra bízhatja, hogy mivel játszogat.
• Ugyan aki használt már modern grafikai programot (3dsmax, After Effects, stb.) az ismeri, de mégis kiemelném mennyire fontos az a fajta numerikus input, amit használnak: minden számszerű érték klikkeléssel húzogatható fel-alá, de duplaklikk után manuálisan is beírható neki pontos érték. Ezzel nagyon könnyű mind “szemre” belőni valamit, de elkerülhető a klasszikus designeri frusztráció is ha valaminek egzakt érték kell lennie.
• Szinte minden textúrából mappelhető: így nagyon könnyen tudja pl. a tüskés effekt formáit és színeit egyszerre úgy állítani, hogy tetszetős legyen.
• Minden textúra helyére betölhető videó(!) is
• Egészen elképesztő overlay- / textúra- / layer-gyűjtemény látható a vinyóján, ránézésre minden effektre azonnal ki tud próbálni 15-20 változatot. Ez a legjobban a colorgrading és a lensflare overlay állítgatásánál látszik, ahol gyakorlatilag másodpercek alatt kipróbál 5-6 variációt; mindezt azért teheti meg, mert az évek alatt összegyűjtögette tulajdonképp presetnek a rengeteg LUT-ot.
• Érdemes összevetni a scenet a postprocessing előtt és után: az alapvetően egyszerű jelenetnek hirtelen mélysége lesz a hozzáadott (szintén egyszerű) effektektől. Rengeteget számít itt is, hogy pillanatok alatt tudja összedobálni a végleges comp-ot, és azonnal látja, hogy mit csinál. Nyilván ez nem azt jelenti, hogy minden effekt azonnal jól kezd el kinézni mihelyst belefojtjuk megfelelő mennyiségű postprocessingbe, de pl. a végén rárakott kis noise layer egyszerű, olcsó, és mégis sokat ad a végeredményhez.
• Szintén apróságnak tűnhet, de csak a használat során derül ki az, hogy mennyire fontos az átrendezhető GUI: függően attól, hogy min dolgozik éppen, folyamatosan rendezi át a tool GUIját, hogy többet lásson abból amit épp csinál, amit meg már nem használ, azt bezárja. Ezzel rengeteg fejfájástól menti meg magát.

Egy ilyen demotool elkészítése persze nyilván évekbe telhet, folyamatos iteráció mellett, és mindenkinek gusztusa válogatja, hogy egyáltalán szüksége van rá (vagy van-e valaki aki használni is fogja), mert nyilván demót írni jobb, mint tool-t írni. Ettől függetlenül viszont nagyon fontos lecke tanulható meg pl. abból, hogy mennyire hasznos, ha az ember egy effektre azonnal rá tud dobni 3-4 textúrát is, mert sose lehet tudni, hogy melyik lesz jó, vagy melyiktől jön meg a következő ötlet.

Ez pedig nyilván így uszkve 3 hónappal Function előtt nem haszontalan.

Az RGBA és a TBC koprodukciójából született Elevated c. intrót biztosan nem kell senkinek bemutatni; a 2009-es Breakpoint 4k compójának győztese azon kevés intrók egyike lett ami messze túlhaladt a scene határain. Mától ez valószínűleg még tovább fog terjedni, mert tegnap publikusan is elérhető lett az intró forrása is, melynek köszönhetően végre betekintést nyerhetünk a kulisszák mögé.

Első átfutásra a következő dolgok derülnek ki a forrásból:

• Az intró full-ASM – erről korábban ment vita is – bár érdekesmódon kétféleképp van megközelítve a dolog, a “debug” könyvtárban megtalálható az intró C verziója is, a “release” könyvtárban pedig a végleges optimalizált ASM forrás.
• A zenét szolgáltató szintiből nincs C verzió, és egészen minimalista.
• A kód egyik legviccesebb / legzseniálisabb része a “src\constants.h” elején található kis kódrészlet, ami segítségével ugyanaz a forrás C és ASM fordítóval is lefordítható – öröm nézni, akkora hekk.
• Szintén gyakran hallható elmélet volt az, hogy az intró a szokásos 2D polygonra raymarcholt egy-nagy-shader. Ez nem igaz: a talaj maga egy tesszellált 3D mesh, aminek csak a poszt-processzingje történik shaderből.
• Maga a shader természetesen olvashatatlan, ennek megértéséhez valószínűleg célszerű ha párosítjuk IQ Function 2009-es előadását is.
• Az időzítések a GNU Rocket egy korai verziójával készültek, kivéve az égben villogó csíkokat, amik simán a zeneadatból vannak áthúzva. Ami engem elsőre meglepett, hogy sokkal több dolog van animálva, mint amire gondoltam, pl. a kontraszt, napsütés beeső szöge, de akár a domborzat mérete is.
• Külön vicces, hogy a mostani Crinkler egy jó 30 byte helyet talál még a régihez képest.

A tavalyelőtti Astroidea 4k, a Discovery legalapvetőbb eleme a realtime sphere subdiv, vagyis egy gömb részletességének nézőponttól függő, folyamatos változtatása. Az alap algoritmust írom le most.

1. Egy ikozaéderből indulunk ki. Ez egy olyan ojjektum, ami 20 háromszögből áll, teljesen mindegy, hogy generálod, csak a vertexek körüljárási sorrendje stimmeljen. Praktikusan a vertexek pozíciója normalizált, vagyis egy egység-gömb felületén ülnek.
   
2. Húsz háromszöggel indulunk, ez majd a folyamat során változni fog, ez nem befolyásol semmit. A háromszögeken egyesével haladunk, nem teszünk köztük SEMMILYEN különbséget, vagyis az algoritmus nem függ a szomszédos háromszögektől, ami nagyon előnyös tud lenni. Cserébe sajnos indexelést sem nagyon praktikus használni vele, de ez nem egy akkora katasztrófa. Nevezzük el az aktuális háromszög vertexeit 0-1-2-nek.
   
3. Fogjuk a háromszög három élét, és generáljunk új vertexeket a felezőpontokra, nevezzük el őket 3-4-5-nek. A poziciókat normalizáljuk, vagyis pld 3=normalize(0+1)
   
4. Az érdekes rész most jön: döntsük el az új vertexekről, hogy szükség van-e rájuk, kell-e ilyen szintű osztás. Fontos, hogy csak az adott él vertexeit használjuk a döntéshez. Pld csinálhatjuk úgy, hogy megnézzük a kamera távolságát az új vertextől, megszorozzuk egy konstanssal (subdiv factor), és az így kapott értéket összehasonlítjuk az eredeti két vertex, vagyis az aktuális él hosszával. Ezzel kapunk egy igen/nem választ, ez még fontos lesz később. Tegyük fel, hogy mindhárom él IGEN-el válaszolt az “osszalak-e tovább” kérdésre, ekkor létrehozhatjuk a négy új háromszöget, amit aztán továbblökünk feldolgozásra. Az eredeti háromszöget el is felejthetjük. (Az új háromszögek: A=0,3,5 B=1,4,3 C=2-5-4 D=3-4-5)
   
5. Tegyük fel, hogy az előző pontban nem minden él adta ugyanazt a választ. Mondjuk a 0-1 él (amin a vertex 3 ül) azt mondta, őt nem kell tovább osztani. Ebben az esetben az adott él felező vertexét (esetünkben a 3-as számút) az él első vertexének (esetünkben a 0-ás számúnak) a pozíciójára állítjuk. Erre nem feltétlenül lenne szükség, hiszen – ahogy majd az ábrán látszik – az egyik háromszög gyakorlatilag eltűnik, de pld hardware megvalósításnál jól jön, hogy MINDIG fix számú háromszöget hozunk létre, maximum némelyik nulla területű. Ha az élek nem értettek egyet, akkor ugyan az eredeti háromszöget elfelejtük, de az újonnan létrehozottak mehetnek azonnal renderelődni, további feldolgozásukra nincs szükség.
   
6. … és így tovább, haladunk a háromszögeken, daraboljuk őket, ha nem kell tovább, akkor rendereljük, ha kell tovább, akkor hozzáadjuk a feldolgozási listához. Előbb-utóbb, ha nem valami végtelen kritériummal dolgozunk, elfogynak a feldolgozandó háromszögek, ezzel kész is vagyunk.

Az élek osztása, illetve az, hogy csak és kizárólag az élek vertexeivel számolunk biztosítja, hogy sosem lesz törés, lyuk, vagy bármi ilyesmi anomália a mesh-en, hiszen két szomszédos háromszög élei matematikailag is ugyanazt a választ fogják adni mindig, bármelyik oldalról nézzük.

Lehetséges még minden háromszögre előszűrést, pld backface vagy frustum szűrést végezni, de óvatosan – egy nagy háromszög nem tökéletes mása a gömb-darabkának, amit reprezentál, pláne, ha később mondjuk displacement is kerül rá (márpedig fog, mert ki akar sima gömböt renderelni:)).

Kellemes karácsonyi meglepetéssel szolgált Reptile, amikor elérhetővé tette az elmúlt három 4k intrójának (Discovery, Re(s)tro, TheFa Definitive 15th Anniversary Edition) forrásait.

A lefordításukhoz Visual Studio 2013 (elvileg az ingyenes Express edition is megfelel a célra) és DirectX 9/11 SDK szükséges; a szintén felhasznált Crinkler és a Ctrl-Alt-Test Shader Minifier megtalálható a ZIP-ben is, ahogy a zenét szolgáltató 4klang és egyéb alkatrészek is.

Ami első rátekintésre a legérdekesebbnek tűnik mindhárom intró kódjában, az a CPU-kód szinte teljes hiánya – az ablaknyitást és mindenféle inicializálást leszámítva az intrók szinte teljességgel shaderben vannak megvalósítva. Ez alapvetően nem is lenne meglepetés, hiszen a rengeteg Shadertoy-based 4k ugyanezt teszi, viszont ez a három intró sokkal inkább geometria-alapú, így a tényleges effektkód eloszlik a vertex-, pixel-, illetve a DX11-es intrók esetén a geometry-shaderek között. További érdekesség a Discoveryben a shader alapú zenegenerátor, valamint az #ifdef-tengerben megbújó beszédszinti, ami nem jutott be a végleges verziókba.