☰ Menu

Scene.hu

Magyar demoscene portál – grafikusok, zenészek, programozók alkotói közössége

Archive for the ‘Programozás’ Category

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.

Atari-mágia

Posted by Sandor@HARD on december - 30 - 2017

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:

Ennyi.

A Cocoon Demo Editor rövid bemutatója

Posted by Gargaj on június - 15 - 2016

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.

Megjelent az Elevated forrása

Posted by Gargaj on június - 6 - 2016

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.

Gömbsubdiv, röviden

Posted by reptile on április - 24 - 2016

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.
    Icosahedron
  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.
    ico0
  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)
    ico1
  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)
    ico2
  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.
    ico3
  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:)).

AstroideA 4k source pack

Posted by Gargaj on január - 11 - 2016

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.

hg_sdf – a Mercury eszköztára

Posted by Gargaj on december - 16 - 2015

Igazán érdekes és módfelett hasznos dologgal rukkolt elő a Mercury: Nyílt forráskódúvá tették azon shader-libraryjük jelentős részét, amit nem csak a nagysikerű intróikban láthattunk dolgozni, hanem Cupe NVScene-s előadásában még közelebbről is bemutatta, hogy milyen gyorsan lehet vele dolgozni.

Miről is van tehát szó? A hg_sdf névre keresztelt függvény-gyűjtemény a manapság rendkívül népszerű signed distance field renderinget (előjeles távolságtér? Jézusom) hivatott megkönnyíteni: Aki ezt nem ismeri, röviden összefoglalva a módszer lényege annyi, hogy a kirenderelendő objektumokat felületekként kezeljük a kódban, és a tér minden pontjára meghatározzuk, hogy milyen távol van a térben legközelebb lévő felülettől. A technika népszerűsége természetesen IQ / RGBA-nak köszönhető, aki szintén rengeteg infót biztosított már róla – ez a mostani kezdeményezés a Mercury részéről igazolja is az erre való igényt.

hgsdf

Nyilván a technikának megvannak az előnyei és hátrányai, utóbbi például az, hogy mindent matematikailag kell leírni; ebben próbál segítséget nyújtani ez a hasznos kis fájl, amiben az alapvető geometriai formák mellett rengetegféle ismétlődési, vagy épp csatlakoztatási formula van leírva, aminek segítségével sokkal könnyebb magukat az egyszerű formákat kicsit részletesebbé tenni. Az oldalon a leírás és a kód mellett kis dokumentáció is található arról, hogy mit hogyan érdemes megközelíteni (pun not intended), és bár maga a kód maga GLSL-hez készült, semmi olyat nem tartalmaz, ami ne lehetne átültethető HLSL-re is, így gyakorlatilag bárkinek csak a hasznára válhat, aki ilyen jellegű intrót / demót szeretne csinálni, vagy akár csak Shadertoyon szeretne valamível virítani.

Apropó Shadertoy, azt tudtátok, hogy IQ valószínűleg nem erről a bolygóról származik?

Amíg Mau megírja a zárócikket a Functionös demózsemle-sorozatban, addigis itt az egyik előadásról készült videó a partyról. Az előadó az Indexet is megjárt, a scene-t állítása szerint régóta követő Zsolnai-Fehér Károly, a bécsi egyetem kutatómunkatársa.

Az előadás nyilván az ő szakterületének rövid (de közérthető) összefoglalója; ahogy a címből is kitalálható, a raytracing, global illumination, subsurface scattering és ezeknek az alkalmazása, teljesen közérthetően, mindenféle mély-technikai részlet nélkül. Mivel az egész alig fél óra, megtekintése mindenképp javasolt kódereknek kötelezően, mindenki másnak fakultatívan:

Csókolom! Stella lejöhet játszani? part move

Posted by RawBits on augusztus - 12 - 2015

Move your world!Az előző cikkben azt ígértem most a mozgatható elemek – alig meglepő módon – mozgatásáról lesz szó. Ez lesz az ami biztosítja nekünk, hogy a kicsit szegény és limitál grafikai tárházunkat meghökkentő trükkökkel, lélegzet elállító látványossággá alakítsuk. Legalább is értékelhetővé tegyük, hogy ne akadjon fel az elő-zsűrin. :) Aki persze játékgyáros ambíciókkal rendelkezik ezt a részt áhítattal kell olvassa! Hiszen félig ettől kelnek életre a kis – ám nagy gonddal megalkotott – játék elemek.

Vágjunk is bele!

Tovább…

Ugrás a lap tetejére Ugrás a lap aljára