Demokészítés – alapok, tippek, trükkök

[-SP-]

Hello mindenki!Viszonylag új vagyok itt, bár a demoscene fogalmát már csaknem tíz éve ismerem, sőt azelőtt C64-en is imádtam a cracktrokat nézegetni, és immár öt éve rendszeresen követtem a külföldi események egy részét.[az persze akkor még eszembe se jutott, hogy még itthon is vannak partyk, ehhe] :DSzóval az elmúlt időben egyre inkább átvette az ámuldozás/áll-leesés helyét a cselekvési vágy; szeretnék én is hasonló dolgokat művelni.Mivel itt van pár régi róka, az lenne a kérdésem, hogy tudnátok-e valami támpontot/irányt adni a sok n00bnak, aki ezzel akar foglalkozni? Van pár ismerősöm, akiket szintén vonz a téma.Leszűkítem a kört PC-re, azon belül is OpenGL/D3D windows alatt… szóval az “inkább térj át Plus/4-re” kommenteket hagyjátok ki, köszi :)Elsősorban C++ / C# környezetben vagyok kompetens, bár csak alapfokon. Szóval ha tudnátok adni valami ehhez kapcsolódó segítséget, azt megköszönném (NeHe cuccok már megvannak, de abból szerintem elég nehéz saját ötlettel elindulni). A másik a hangkezelés, milyen módon lehet megvalósítani a kép-hang szinkront, stb. Aztán hogyan működnek az introk, milyen elven generálódik 4/64k-ból ez meg az… persze nem akarok egyből 64k-kkal kezdeni :) Csak érdekel.Tutorialok is jöhetnek, csak használhatók legyenek, ne egy bizonyos példa, amit úgysem tud sehol hasznosítani az ember.Kösz mindenkinek előre is!-SP-

[Murphy]

Igazából D3D esetén szerintem a help és a samplek, tutorialok teljesen jók az induláshoz, vagy inkább konkrétabb látványeffektek érdekelnek? A kép-hang szinkron legegyszerűbb módja, hogyha a zenelejátszótól kéred le az időt, és ahhoz igazítod a képet. 64k intróknál a textúra generálást nagyjából úgy a legegyszerűbb elképzelni, mintha photoshop-ban csak filterek használatával állítanál elő képet. Ebből adódik, hogy ha van leprogramozva x filtered, akkor ezekkel a bemenő paramétereikből bármikor elő tudod állítani a képet. A zene generálásról inkább beszéljen olyan aki ért is hozzá ;)

[-SP-]

Ahha. Kösz :)Szóval pl. egy directX SDK és pár gugli elég ahhoz, hogy az ember nekifogjon? Vagy feltétlenül kell valami más is?

[MaNiAc]

SP.gmflc wrote …
Ahha. Kösz :)Szóval pl. egy directX SDK és pár gugli elég ahhoz, hogy az ember nekifogjon? Vagy feltétlenül kell valami más is?

Siman, bar en OpenGL-lel alltam neki, de nekem se volt ezzel gondom. Jelen pillanatban en is pont olyanokkal szivok, mint az idozites… Ha mar itt tartunk, nekem is lenne egy kerdesem:Sok libet lattam mar, amit demoknal zenehez hasznalnak, pl. FMOD, BASS, etc, de ezt a lekert ido dolgot egyikkel se lattam sehol megvalositva streaming audional, helyette max a legtobb tutorial ott merult ki, hogy van egy sample wav es azt lejatssza valami uber-hi-level fuggvennyel (gy.k.: playWavFile(fileName) ). Megvalositottam viszont nagy hekkelesek es karomkodasok kozepette ogg/vorbis es openal hasznalataval valami hasonlot, de szerintem nem lett egy hu-de-intelligens dolog, raadasul ez nem streaming… Ezt azert mondom, mert streaming eseteben nem ment, helyette feltoltottem a zenet a memoriaba ugy, hogy toltes kozben PCM audionak kicsomagoltam es utana OpenAL-lel chained sample-kent jatszottam le. Ez szep es jo es pl. egy 6 perces demo eseten az a 60-70 mega PCM adat a memoriaban annyira nem is veszes (ennyi lesz egy 128 kbps/stereo ogg dekodolva) csak epp jol megnott tole a betoltesi ido…Tud valaki olyan peldat mondani, ahol streaming audiohoz van syncelve animacio, akarmi, vagy csak egyszeruen le van irva, hogy lehet kiszamolni, idoben hol tart a lejatszas? Sajnos az a megoldas, hogy a start() elott inditok egy countert, nekem ugy tunt, neha tud hibazni, szoval pofasabb lenne, ha maga a decoder lib tudna ezt megtenni, akar egy callback-en keresztul…

[Georgy]

Én a position = BASS_ChannelBytes2Seconds(stream, BASS_ChannelGetPosition(stream));használom (bass alatt:P).

[MaNiAc]

Hehe, valahogy sejtettem, h te leszel az elso, aki valaszol! :) Ezert mar tuti kaptok greetet :))) Valami ilyesmire gondoltam, pont! Mentsegemre legyen, h bass-hez nem sok kozom volt eddig :-\

Na asszem amint lesz idom, kiprobalom!

[Gargaj]

szimpla BASS hasznalat: http://umlaut.intro.hu/~gargaj/temp/udsSound.cpp – hatha segit vkinek :)

[Murphy]

Nem szorosan, de ide tartozik, dosbox alatt megnéztem a régi intróinkat, amik simán timerhez igazodtak, (nem a playerhez), és teljesen szét van csúszva az időzítésük :( Nem apró szinkron hiba, hanem 2x olyan gyorsan végigmegy az intro, mint ahogy a zene. Szerintetek ez mitől lehet?

[-SP-]

Én DosBox-os introknál lehúzom a cycle-t 1000 körülre, akkor elég lassú lesz az intro ahhoz, hogy ne “előzze le” a hangot.Gargaj: Kösz a cpp-t!

[MaNiAc]

Gargaj wrote …
szimpla BASS hasznalat: http://umlaut.intro.hu/~gargaj/temp/udsSound.cpp – hatha segit vkinek :)

The page cannot be foundwtf?

[MaNiAc]

Hehe, megvan… ~gargaj után volt egy space is, ami nem kell oda. Thx a filét! :)

[iONic]

Skacok, a modern világban hogyan illik megoldani a 3D megjelenítés szervezési részét? A OGL/DX gondoskodik ugye magáról a kirajzolásról, de az objektumsorrendekrről (pl. ha szövegekrőll is beszélünk) , sőt egyáltalán a textúrák vidmembe feltöltéséről, stb-ről nekem kell gondoksodni (legalábbis jelenlegi ismereteim szerint). Tehát a folyamatok fájlbetöltés és kirajzolás közötti részére gondolok. Nem tudom van-e külön neve ennek a résznek. És nyilván nincs szükségem egy játékhoz kellő 3D engine-re, elég lenne egy egyszerűbb is, tehát ilyen értelemben kérdezem. Pl. jelenleg azt sem tudom, van-e mód legalább az animációk “kihelyezésére” mondjuk kész, nyílt forráskódú, 3rd party cuccba. Avagy lehet-e valahogy egyszerűen menedzselni olyan fájl-formátumokat, amelyek már a mozgásokat, torzításokat is tartalmazza, és egyszerűen rábízni valamire? Van-e valami, aminek megmondhatom hogy a 0-20 mp ismételt world a 5.6 mp-en aktuális állapotának megfelelő helyzetben add vissza az objektumokat? (Kameráról, esetleg fényekről, plusz effektekről mondjuk gondoskodok én.) Vagy ezt a részt is mindig kódból intézzük manapság is, és mindenki maga csinálja? Ha igen, hogyan célszerű ezt mondjuk C#-ban implementálni? Nem szeretnék felesleges köröket futkosni.

[Gargaj]

demotoolra gondolsz?

[iONic]

nem, semmiképp sem
arra vagyok kiváncsi, hogy hogyan célszerű ezt manapság megcsinálni, hogy ne 70%-nál derüljön ki, hogy teljesen másképp kéne csinálni, és esetleg van-e valami ezt segítő library vagy valami

[Murphy]

Ha C/C++, akkor a D3D részeként adott D3DX ilyen, sok szolgáltatás, és rá tudod akasztani saját enginere. A használhatósága azért lehetne jobb, különössen debuggolás terén.

Ha C#, akkor pedig XNA, de ebben gyakorlati tapasztalatom nincs.

[Geri]

iONic wrote …
Tehát a folyamatok fájlbetöltés és kirajzolás közötti részére gondolok. Nem tudom van-e külön neve ennek a résznek.

Van neve, és enginenek hívják. Ha szűkséged van enginere, ha nincs, ehhez az kell. Vagy megírod ezeket a részeket, vagy pedig írsz egy saját generikus enginet, vagy enginerészletet, ami ezeket a képes neked lekezelni. Nyilván ezeket elég egyszer megírni, és onnéttól évekig jók lesznek, egész addig amíg valami teljesen más technológia be nem jön – tehát egész sokáig.A Murphy által ajánlott d3dx-et semmi esetre sem ajánlanám, lassú, bugos, és csak a microsoft fejlesztőeszközökhöz csapják hozzá, tehát a gcc-ben nincs.

[Gargaj]

D3DX es XNA tkepp majdnem ugyanaz, es teljesen javasolhato, sebessegevel nincs semmi baj es az egyetlen hiba amibe belefutottam eddig az az h a D3DXCreateTextureFromFile* fuggenyek DXT-tomoritett kepeknel hajlamosak voltak lemenni 4x4es mipmapok ala (amit DXT-vel nem lehet) es olyankor kifagyott, de ez rohadt regi verzioknal fordult csak elo.

[Gargaj]

En mondjuk nem hivnam feltetlen engine-nek, bar nem all messze tole – en ugy voltam vele a mi 64k-librarynknal hogy ugye amikor az ember introt ir akkor csak kialakul hogy mi az amit celszeru tobbszor felhasznalhatova tenni… ergo az hogy neked mi a kenyelmes, az elobb-utobb kialakul :)

[Geri]

Én ezért is nem írok 64k-t valószínűleg soha, mert nálam az összes kód így egybe van hányva, ilyen szempontók alapján nincs különszedve. Ezt most elrettentő példának mondom.

[iONic]

igen, engine-nek én se nevezném, ezért is nem használtam a kifejezést, holott nyílván ismerem

[iONic]

más, skacok az NVIDIA FX Composer 2.5 teljes természetességgel nem mutat semmit egy ATI Radeon xPress 1250-en? Még a quick tutorial legelső material-létrehozására is csak egyszínű szürke felületeket mutat.. még a material thumbnails nézetében is… hm… pesdig a tutorial screenshotjai szeriint sem így kéne kinézzen.

[Gargaj]

gondolom mert ATI kartyad van es nem NVIDIA :)
javaslom az ATI Rendermonkeyt

[iONic]

azért ez durva, remélem a HLSL effektek legalább kompatibilisek

[Murphy]

iONic: nem kell aggódni, az NVIDIA szereti a saját OpenGL extensionjeit használni, csak azért, hogy ne fusson ATIn. A DirectX-es effektek mind mennek az FX Composerben is.

[blala]

gyarto-specifikus opengl extensionoket mar sok eve nem hasznal senki (legalabbis nagyon remelem; na jo, esetleg a gyartok maguk kivetelek), viszont a driverek (amikben a glsl forditok vannak) finoman szolva nem tokeletesek.

[Murphy]

Régen az NVIDIA demo programjai csak azért készültek driver specifikus opengl extensionokkel, hogy nehogy fusson ATI-n, időnként akár gyorsabban. :) Manapság nem néztem már ilyet gépen, és aki nem ellenérdekelt a kompatibilitásban az nem csinál ilyen hülyeséget.

Egyébként OpenGL alatt a GLSL vagy a CG az elterjedtebb?

[blala]

Hat a cg nincs tamogatva, csak kulso toollal ugye. Ugyhogy glsl-re tippelnek. Amugy fogalmam sincs, viszont azt gondolom hogy tokmindegy mert a 3 nyelv kozott gyakorlatilag nincs elteres par konvencion kivul.

[iONic]

bárcsak már ott tartanék hogy akármilyen sl lenne a fő problémám;-)

[abcug]

hat xna-val azert nem art vigyazni imho…
demoscene-felhasznalasra csak nagyon ovatosan ajanlanam!
ugyanis nagyon meg tudja fogni az ember kezet, valamint olyan kellemetlen meglepetesekbe sikerul rendszeresen belefutni amirol pl. d3d(x) es c++ utan azt hinned, hogy alap. aztan bazz kenytelen vagy az idod nagy reszet pl. contentprocessor bovitgetessel es extension libraryk keszitesevel tolteni. (ami azert nem annyira szorakoztato, sot k****ra nem az :)

ezzel szemben egy obj.lodert c-ben megirni vagy a d3dx-et hasznalni szazszor kenyelmesebb, plane, hogy az utobbi utan (bol ???) gyartott xna-s valtozat pl. fele annyira kezeli a hierarchyt (ertsd: semennyire:), egyszeruen elfelejt jopar propertyt (ertsd: az index es vbuffon kivul szinte mindent) etc… etc… tudom, irjak extensionokat, hat koszi szepen …) b*s*dm*g! :)

(mondjuk az mar erosen szubjektiv), de en pl. a pocsenel fogva logattam volna fel azt elso villanyoszlopra azt a barom Anders Hejlsberg-et is! koszi teso nagy voltal! :)))

ui: az viszont teny, ha eljutsz oda, hogy mindent sikeresen feltoltesz akkor mar a hlsl optimizeren meg a gpu-n mulik, hogy mennyire lesz gyors a stuffod –> atlagos mozog/forog objektum a kepernyon demonal tobb layeren sem lesz gond pl. egy mai 6×00-es geforceon :))) \o/
(az 5-os az r32f miatt erosen felejtos :) szoval hajra :)

[blala]

nana abcug, ennyi erovel Dennis Ritchie-t is logathatnank meg Bjarne Stroustrup bacsit is… Igazabol kurvara nem ertem miert programoznak meg emberek C/C++ -ban (na jo, nyilvan megvan a letjogosultsaga, de ez nem esik egybe a mai felhasznalasi terulettel)

[Author]

Posts