Home › Forums › Platformok › PC › SEGITSEG!
- This topic has 63 replies, 21 voices, and was last updated 12 years, 6 months ago by
Murphy.
-
AuthorPosts
-
2011-12-13 at 19:05 #3963
pacshuMemberHát fogalmam nincs mekkora overheadje lehet a window forms-nak, ellenben az XNA ilyen kísérletezgetésekre is egész jó lehet, és az is C#-al programozható, sokkban valószínű nem fog eltérni az algoritmusod, csak ott majd Texture2D-t kell készítened dinamikusan amit kirajzolsz, de talán akkor már abban biztos lehetsz, hogy valószínűleg az algoritmusodon kell gyorsítani valamit, ha épp lassú lesz. Vagyis úgy is mondhatnám, ha abban lassú akkor valószínűleg még várnod kell pár évet amíg elkészítik alá a vasat, vagy esetleg a Direct2D segíthet, mert elvileg HW gyorsított 2D-s rajzolásra tervezték, de csak windows7-től elérhető.
2011-12-13 at 20:09 #3964
BeryMemberA Direct2D-t lánykori nevén hívhatjuk DirectDraw-nak is, és akkor már egészen régóta elérhető, mondjuk Win98 (Win95?) óta :) Ugyan DirectX8 vagy 9 óta elméletileg nem annyira van, de mivel a DirectX-ek visszafelé kompatibilisek, így ez nem probléma.
De persze akkor már miért nem D3D? És akkor akár direktben lehet írni egy memória surface-t, ha az kényelmes, aztán azt kitenni Direct3D window-ra, vagy akár full-screenbe. A DirectX SDK tutorial C++-ban van, szerintem azt C#-ra simán át lehet ültetni minimális módosítással. Ha Delphi Object Pascal-ra ment, a C# nem lehet nagyobb akadály :)
2011-12-13 at 20:41 #3965pacshuMemberVégre egy hozzá értő, segíts nekem!
DirectDraw és Direct2D között API szinten van különbség? Vagy miért kapott új nevet? (Hol van a qtya elásva?)
Én szeretnék Direct2D-t, (windows xp-n is akár, bár fontolom, hogy ha kijön a w8 akkor megpróbálkozom azzal) de, ha más API-ja van akkor lehet nem tanulnám már meg a régebbit.
2011-12-13 at 20:47 #3966pacshuMemberJaah már nagyjából tudom, csak googlizni kellet volna:
http://en.wikipedia.org/wiki/Direct2D
http://en.wikipedia.org/wiki/DirectDraw2011-12-14 at 14:08 #3967
rawbitsMemberNa ez érdekes kérdés, mert itt ahol most dolgozok, meg akiknek programokat írok általában elég rossz a gépparkjuk. Mondjuk, hogy az XP éppen eldöcögtől a Win7 is vígan szaladig mindenük van és össze-visza használják őket. Ez felvet némi problémát, mert általában bonyolult számításokat is kell végezni online adatgyűjtés közben és még meg is kell jeleníteni még hozzá úgy, hogy a GUI is teljesen reaktív legyen.
Azon gondolkoztam, hogy a Win úgy is DirectX-et használ alapból, miért ne használjam azt egy hegynyi saját gyártású control-lal. De mennyire kompatibilis ez XP, Vista és Win7 között iletve kell-e DLL-eket csomagolni a program mellé és egyáltalán szabad-e jogilag ilyet csinálni?
Persze én mindig mindent túlbonyolítok… :)
2011-12-14 at 21:03 #3968BeryMemberpacshu: D3D alatt van 2D Sprite (forgatással tetszőleges szögben, Z-orderrel), vonal rajzolás (akár antialiasolt is!), direkt surface elérés, 3D objektumok kirajzolása, akár 2D-re vetítve, point-spriteok (lásd: részecske rendszerek), post-process shaderekkel. Mi kell még? :) Mindezt használhatod úgy, hogy RenderTargetnek egy texturát adsz meg, amit aztán ráfeszítesz egy PolygonQuadra (2 háromszög által lefedett, képernyő arányú négyszög) és már kész is a 2D grafika D3D alatt. :) És csak elsőre körülményes, igazából kb. 2 tucat programsor és csak egyszer kell megírni :) Na meg ez a Microsoft ajánlás is.
Ehhez képest persze nem értem ezt a Direct2D-t, hogy most honnan, meg minek, de gondolom ez valami wrapper erre a témára, hogy könnyebb legyen a Win7-es képernyő effekteket megírni.
RawBits: mivel a gépeken különböző DirectX-ek lehetnek, így akár kellhet is, hogy a legkisebb közös többszörös, ja nem :) DLL ott legyen a kód mellett. Bár C / C++ / C#-ban talán ez megoldható enélkül is, de ebben nem vagyok biztos. Viszont ekkor még mindig fennáll, hogy kompatibilitás miatt olyan engine-t írsz, ami a gépen található DirectX verziónak megfelelő D3D objektumot hoz létre. Ez a megoldás kicsit elcsúfíthatja a kódot. Vagy azt mondod, hogy követelmény a DX7, 8 vagy 9, az legyen minden gépen egyformán fent, és akkor arra lehet építeni a projektet.
Egyébként DirectX DLL-t szerintem simán adhatsz a programodhoz, hiszen azok az ingyen letölthető és telepíthető DirectX részei.
Aztán a JEDI projektnek van egy visual lib-je DX-re, ami a szokványos Win kontrolokat valósítja meg. Ha ezt nem is használod fel, ellesni talán lehet dolgokat a forrásból.
2011-12-15 at 15:51 #3969rawbitsMemberBery: Köszi! Sajnos nem tudok olyat mondani, hogy ez meg az a követelménye, mert ha itt az egyetemen még meg is tehetem, hogy azt mondom ez a laptop elbírja és onnantól csak arra használják, de az én programjaim alapvetően az ipar számára készülnek és ott ha már 2 gombot kell megnyomni, akkor rossz programozó vagy még ha nem is lehetne eggyel megoldani… Szóval igyekezni kell mindent úgy megírni, hogy mindenhol működjön. Persze én tudom, hogy ennek vannak korlátai, de nem akarok rossz programozó lenni! XD Inkább csak mérsékelt vizuális orgazmussal operálok.
2011-12-15 at 17:13 #3970
-SP-MemberBery: thx, lehet, hogy inkább én is D3D-ben próbálkozom. Főleg ha rögtön a memóriába lehet tologatni a pixeleket :)
2011-12-20 at 09:46 #3971-SP-MemberOké, új kérdésem van :) azokhoz szólok, akik nyomultak már FMODdal, biztos vagytok egy páran.
Egy egyszerű audio-vis sync -et akarok megvalósítani, egyelőre beat detection nélkül, csak annyi kell, hogy a spektrum szerint mocorogjanak a dolgok. Eddig így sikerült:
– megy egy adott (egyelőre mono) channelen a sample, getSpectrum() betolja az adatokat egy float[] -ba (64,128,256 v 512 elem)
– a spektrumtömböt három részre szedem átlagolva, hogy meglegyen a low-mid-high részÉs itt olyan problémám van, hogy valamiért a mély frekvenciák sokkal erősebbek, mint a többi. Ha 0.0f és 1.0f között vesszük, akkor a mély olyan 0.11f, míg a többi a leghangosabb esetben is 0.004 körüli. Azt hittem, a sample-lel van a baj, de kirendereltem egy wavot, ami egymás után tartalmaz 1mp hosszú szinuszokat 20Hz-től 16000Hz-ig, és végig ilyen eredményeket dobott. Próbáltam többféleképp felbontani a spektrumot (3 egyenlő rész, logaritmikus felosztás stb), de nem segített. Mi lehet a gond?
2011-12-20 at 10:25 #39722011-12-20 at 10:59 #3973-SP-MemberKösz, kívülről fújom a FM elvet :D de arra gondoltam, hogy lehet-e ellene tenni valamit? Vagy csak szorozzam fel a felső cuccot? :) Meg ebből továbbra sem derül ki, hogy a 16khz-es szinuszra miért keletkezik 0.1f -es jelszint a legalsó frekvenciákon.
2011-12-20 at 11:14 #3974
GargajKeymasterSiman szorozd fel, a 0.1f pedig vagy azert van mert aliasol a szinusz, vagy azert mert gany az FFT.
(Egyebkent BASS.dll > FMOD)2011-12-20 at 21:02 #3975MurphyMemberKicsit pontosítanék Bery-írásán. D3D 9 előttinek semmi értelme, és valójában a 9-esnek is csak azért van, mert az újabb D3D-knek más Driver modellje van, ami nincs XP alá. Mondjuk ez épp elég, hogy szinte mindenki D3D9-re programozzon. Ha lemondasz az XP-ről akkor 11-est érdemes nézegetni. A D3D ugye a nagy verziószámokon belül is fejlesztődik folyamatosan, viszont a core D3D nem változik, csak a helper libraryk (d3dx9_xx.dll). Viszont ennek a dll-nek a meglétére hisztizni szoktak a demók (ez a shader fordító miatt megkerülhetetlen). Szokás info file-ba beleírni, hogy milyen verziót igényel a demód, van aki oda is rakja a zip-be. Amúgy induláskor a D3D úgyis kiírja, ha nincs fent, szóval nem feltétlenül kell sokat foglalkozni a kérdéssel…
2012-02-25 at 09:19 #3976-SP-MemberHello megint én. Megint demó :)
D3D a kérdés (de elvi, szóval OpenGL-esek számára is releváns).
1. Hogyan lehet “végtelen” terepeket generálni a legkönnyebben? Gondolok itt valami egyszerű flyby jelenetre, ahol mondjuk kockaváros vagy hegylánc-szerűség van a kamera alatt. A legputtóbb megoldásnak az tűnt, hogy generálok egy olyan rohadt nagy színt, ahol nem veszed észre a horizont közeledését, amíg a jelenet tart, de ez szétszedi a gépet, és a generálás is túl sokáig tart. A másik ötlet az volt, hogy a kamerát X frame-enként visszaugrasztom egy korábbi pozícióba, ahonnan ugyanaz lesz a viewport, így végtelenített hatás jön létre, de ez meg már nem működik olyan környezetben, ahol minden véletlenszerűen mozog/forog/nő… szóval itt elakadtam.
2. Hogyan lehet megoldani azt, hogy több (értsd: sok!) fényforrás működjön egyidőben, de ne zabálja fel a gépet? Sima D3D Light osztályra gondolok (Opengl-ben glLight vagy mi a neve), pontfény három paraméterrel (range, att, intensity). Amíg egy darab van, addig teljesen jól megy a cucc, de ha bepakolok 8-10 -et, akkor átmegy képregénybe. Oké, hogy egy ATI x1200 van a laptopban, de hát egy Quake2-ben is több, mint 20 fényforrás működik egy helyszínen, mégsem hal bele a gép :P
Help? :)
2012-02-25 at 10:34 #3977GargajKeymasterAz elso pontra pl. megoldas az hogy a scenet mozgatod es nem a kamerat, es ami mar latotavon kivul van azt nem rendereled le.
2012-02-25 at 11:07 #3978MurphyMember1. Erre nincs általános megoldás, scene specifikusan lehet csak megoldani. LOD, bilboardok, ügyes skybox trükkök, kamera range-ében ki-be kapcsolod az objecteket…
2. A per pixel (vagy esetedben per vertex) fények számát célszerű alacsonyan tartani, sok nagy range-ű, mindig meg fogja enni a hardvert. Általában valamilyen félig, vagy teljesen előre leszámolt fényezési megoldás segít ilyenkor. Quake2-ben emlékeim szerint csak a rocket gun-nak van pontfénye (az is fake, hogy per pixel legyen), a bevilágítás előre leszámolt lightmapekkel történik.
2012-02-25 at 11:38 #3979
blueghostMember1. Nem tudom, de ha pl. fákat rajzolsz ki, arra van egy olyan trükk hogy amik távol vannak a kamerától, azokat az adott szögből nézve textúrába rendereled egyszer, és utána csak egy quad-ot raksz ki helyette, pl. Far Cry-ban használták ezt a módszert.
2012-02-25 at 13:15 #3980Caiwan
Member1) Én anno egy (beadandó) grafikánál ez foggal oldottam meg; illetve ma is valami hasonlót tennék, húznék rá fogot, vagy dof-et, hogy a távoli rélszleteket el lehessen “‘csalni”. Illeve, amit Blueghost mond. 2) Fényekkel én is most szórakozom, valós időbe/dinamikusan egynél többet én sem merek betenni, illetve agyalok azon amit Murphy mondott, hogy előre legyártott lightmapet húznék fel én is. Ellenben, nekem olyan problémám lenne (opengl) ha FBO-n keresztül renderelek, akkor nincs alpha blending, ha anélkül akkor meg van. Erre van valamilyen megoldás?
2012-02-25 at 13:34 #3981-SP-MemberTextúrába renderelés az még nem megy :) ködösítést se próbáltam, de lehet az lesz.
A lightmapes módszernek utánaolvasok, ezek szerint az lehet a járható út.
THX! :)
2012-02-25 at 16:41 #3982Travis
ModeratorA “végtelen útra” alkalmazhatod a kamera visszaugratását, ha a véletlen paraméterek nem véletlenek, hanem periodikusak. Hogy mégis véletlen hatást kapj, a különböző paraméterek ne legyenek azonos periódusúak.
Caiwan: A probléma nem teljesen világos. Mit tapasztalsz? Belerakod a két képet és mindkettő azonos intenzitással jelenik meg, vagy csak egy kép jelenik meg?
2012-02-25 at 21:28 #20524MemberTravis: úgy van, hogy sprtieokat glColor4f-fel színez ki / rak rá alphát. A textúrák alpha csatornája működik, egymásra is lehet őket pozícionálni rendesen. Az egész scene mrt-vel FBO-ba kerül a posteffektek miatt. Előbb szétszedtem, mert valahogy úgy rémlett, hogy FBO-val is ment, szóval valahol az FBO körül lesz a gond. Arra jutottam hogy sima FBO-ba renderelés esetén működik az alpha, multi FBO-val is, tehát kizárásos alapon a shaderig jutottam, ami a több targetra kipakolja a képpont adatokat. http://pastebin.com/3RCRTsx0
2012-02-25 at 23:13 #20569ModeratorTehát, ha jól értem, akkor a sprite-k között nincs blending. Az általad linkelt shader kódban nincs lekezelve a több sprite átfedésének az esete. A színt úgy állítod be a gl_FragData[0]-ban, hogy fogsz egy sprite színt és egy fény színt. De ha azon a pozíción lesz még egy sprite, akkor annak a színével felülírod az előzőleg beállított értéket. Ha shadert használsz, akkor neked kell leprogramozni a blendinget is.
2012-02-26 at 00:04 #20571MemberTehát akkor a kérdés adott: hogyan?
2012-02-26 at 04:07 #20575GargajKeymasterHa shadert használsz, akkor neked kell leprogramozni a blendinget is.
Ez igy ebben a formaban nem igaz, a blendop a shader utan jon a pipeban.
2012-02-26 at 10:38 #20579MemberÉn is valahogy így emlékszem; tény, akkor jó, ha lekapcsolom a shadert onnan.
2012-02-26 at 13:29 #20590ModeratorTényleg, bocsánat hibás infóért.
2012-02-26 at 14:25 #20618MemberMég kísérletezek vele egy keveset, hogy mitől nem jó, vagy valami, de van valami ötlet, hogyan lehetne megcsinálni?
2012-02-26 at 14:53 #20621Member[jah, hogy nem tudom utólag átírni a posztomat] Nem lehet, hogy a gl_FragColor.a akar lenni az alpha, ami tovább megy a blending felé?
2012-03-03 at 22:10 #20764GargajKeymasterDe, miert?
2012-06-01 at 17:28 #22034-SP-MemberNa hello megint :)
Lassan megyeget a cucc; most épp áttértem Linuxra, mert a laptopomban levő Radeon x1200 konkrétan semmilyen shadert nem tudott megmoccantani :P Most az OpenGL 2.0-val (glut/glew, c++) küzdök, kezdem átlátni a dolgot. Egy apró kérdésem lenne.Írtam egy minimál vertex + fragment shadert, ami futásidőben belefordítódik a programba. A kódot nem copyzom, annyi az egész, hogy gl_FragColor = gl_Color; (tehát még konkrétan nem változtat semmit). A scene abból áll, hogy pár kocka pörög a térben, és egy pontfény köröz körülötte. A gépben valami nVidia kártya van (asszem geforce 8xxxGT), és vajsimán megy a cucc. Viszont onnantól, hogy bekapcsolom a shadereket, átmegy képregénybe. 15-16FPS maximum. Ez mitől lehet? Ha egy kicsit is bonyolítok rajta (pl. hogy egy vertex attribute alapján különféleképp színezzen), akkor mégjobban lelassul. Nem akarok realisztikus játékengine-t írni, de szerintem ennyitől nem kéne lepusztulnia a gépnek. 2ghz cpu, 2gb ram.
-
AuthorPosts
- You must be logged in to reply to this topic.
