játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5441
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2519

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2186
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Korábbi postok
> 1 < [2] [3] [4] [5]
Kredisoft - Tag | 194 hsz       Online status #70448   2007.09.24 10:07 GMT+1 óra  
A feladat nem olyan bonyolult, viszont ha jobban belegondolok akkor egy gráffal ugyan kicsit többet kell tervezni és átgondolni, viszont később sok időt takaríthatok meg.

Köszönöm szépen az ötletet, ezen is elmorfondírozok.

   
nagyy - Törzstag | 248 hsz       Online status #70415   2007.09.24 05:38 GMT+1 óra  
A legszebb megoldás szerintem, ha van egy színtérgráfod (ami valójában egy fa), és az egyes csomópontjaiban el vannak tárolva a megfelelő transzformációs mátrixok. Megjelenítéskor mindegyik csomópontra alkalmazni kell a saját transzformációs mátrixát., és a szülő objektumtól kapott transzformációkat, és mindezt rekurzívan.
Így könnyen lehet komplexebb rendszereket is animálni, ahol fontos, hogy az egyes részek hierarchikusan, egymáshoz visznyítva mozogjanak. Pl.: egy ember animálása esetében lehetne a szülő objektum a törzse, annak a gyerekei a végtagok, és így tovább. Ekkor a test mozgatásával az egész ember mozgatható lenne, tehát a keze/lába nem fog az eredeti helyzetében ottmaradni, hanem a testtel együtt mozog majd.
Valójában egy színtérgráf ennél sokkal komplexebb is lehet, de egy ilyen egyszerűsített rendszer is hasznos lehet a transzformációk tárolására. Persze minden attól függ mi a feladat. Ha esetleg egyszerűbb felépítésű a világ, akkor elég lehet ha az objektumokat egy listában eltárolod, ahogy Kuzanth mondta.
   
Kredisoft - Tag | 194 hsz       Online status #70414   2007.09.24 05:33 GMT+1 óra  
Jól hangzik amit írsz, nekem a scene-em van hasonlóképpen leírva egy összefoglaló interface-ben és minden scene-hez csak azt kell implementálnom, "örökölnöm", így azt már elértem, hogy kb 5 perc egy új jelenet létrehozása. És gondolom a mozgatásos függvénynek is override-olhatónak kell lennie?

Köszi a segítséget, elmegyek suliba, órán morfondírozok a lentieken, úgyvélem nagyon jó felépités...

   
Kuz - Törzstag | 4455 hsz       Online status #70412   2007.09.24 05:04 GMT+1 óra  
Ne belőlem indulj ki, nem én vagyok itt a legjobb. Ha érdekel, én általános modell-osztályt szoktam létrehozni, és ebből származtatom a specifikusabb osztályokat. Amit csak lehet összefoglalok az ősben (ez sokszor abstract), és kifejtem őket vagy már az ősben, vagy a származtatott osztályban. A render fgv pl csak abstract, mert modelltípusonként más benne a kód (pl a vízhez totál más render kell, mint pl egy sziklához). Ez főleg akkor jön ki, amikor már effecteket is használsz, mert azokat általában máshogy paraméterezed.
Amikor megvannak az osztályok, mindig a megfelelőből példányosítok, majd egy fő render fgv-ben csak végigmegyek ciklussal az összes kirajzolandó objektumon, és meghívom 1x a render fgv-üket. Nem tudom ez mennyire elegáns, de egyelőre bevált...
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Kredisoft - Tag | 194 hsz       Online status #70411   2007.09.24 04:58 GMT+1 óra  
Két különböző mozgást is szeretnék, de ez csak amolyan tesztprogi. Tudok-e forgatni és eltolni, elhelyezni.
Igazad van. Elég elvetemült kellene legyek 100X ezt leírni, és még minden mozgásnál külön... ez így nem szupi.
Tudnál esetleg támpontot adni, hogy hogyan szokás az objektumok mozgatását megoldani 100 modellnél?

Köszi szépen.

   
Kuz - Törzstag | 4455 hsz       Online status #70410   2007.09.24 04:45 GMT+1 óra  
Azt remélem látod, hogy ez két különböző mozgatás. Az első bizonyos szögben elfordítja a modelledet mindhárom tengely körül, de ha a yaw-pitch és roll értékeket konstansként használod (értsd : értékük nem változik), akkor maga a modell nem fog mozogni, csak statikusan egy bizonyos pozícióban lesz.
A második változat az y tengely körül forgatja folyamatosan a modellt.
Egyébként próbáld ki, és meglátod .
Mellesleg már most gondolkodj el azon, hogy mi lesz, ha mondjuk 100 különböző modellt kell majd mozgatnod . Sztem nem fogod így hard-kódolni...Egyébként igen, mozgatáshoz minden modellnél meg kell adni, hogy mi a world mátrix.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Kredisoft - Tag | 194 hsz       Online status #70405   2007.09.24 02:32 GMT+1 óra  
A segítségeteket szeretném kérni.
Van két objektumom az egyik _MeshFohos a másik _MeshBG. Ezt a két objektumot szeretném két különböző irányba mozgatni és forgatni. C#-ot és DirectX-et használok amelyben én a következő megoldást találtam:

Kód:
_fw.Device.Transform.World =
Matrix.RotationYawPitchRoll(yawfohos, pitchfohos, rollfohos)
* Matrix.Translation(xfohos, yfohos, zfohos);
_MeshFohos.Render(_fw.Device);

_fw.Device.Transform.World =
Matrix.RotationY(Environment.TickCount / -1000.0f)
* Matrix.Translation(xBG, yBG, zBG);           
_MeshBG.Render(_fw.Device);


A kérdésem az, hogy helyes megoldás-e a fenti? Ha nem, akkor hogyan kellene ezt csinálnom? Jó az ha modelt szeretnék forgatni és közben a world-öt alakítom? Ha sok ilyen modellem van betöltve egy scenebe akkor mindegyiken sorrendben végig kell menni és be kell pozicionálni?

   
~Cre@tine~> - Tag | 702 hsz       Online status #65026   2007.07.31 06:08 GMT+1 óra  
Ez az általam belinkelt layer olyasmi mint a Tao az Open GL-hez. Szerintem egy próbát mindenképp megér, mivel jelenleg más módja nincs a DX 10 programozásnak C# alól és még jó ideig nem is lesz, mivel az MS még mindig az Xbox360-as kompatibilitással van elfoglalva az XNA-nál.
Fejlesztés szempontjából nem is tudom mi a jó megoldás. Itt hosszútávra talán nincs is értelme tervezni, mert úgy változnak a dolgok szinte hónapról hónapra, hogy egy nagyobb project közepén öszeomolhat az egész. Tán az XNA-nak van jövője, de az se betonbiztos, mivel az xbox360-hoz ragaszkodni fognak mindeképpen és mire kijön a DX10 változat már évek telnek el.

Ezt a linket egy MDX-es project egyik tagja adta meg aki már dolgozgat egy autós játékon jó ideje. Talán neki lesz igaza.

   
~Cre@tine~> - Tag | 702 hsz       Online status #65024   2007.07.31 06:00 GMT+1 óra  
MS részéről nincs managed DX 10 és nem is lesz soha. XNA-hoz meg majd még 2 év mire kijön a cucc.

   
TPG - Tag | 3402 hsz       Online status #65019   2007.07.31 05:32 GMT+1 óra  
Idézet
kuzanth :
Ez marha jó. A sima dx9-es mdx már nem támogatott ms oldalról. Nem soká jön a dx10.1, erre most jönnek a dx10 managed változatával...Most tényleg ennyire logikátlan az MS munkája???


Nem az MS csinálja a managed DX10-et.
Reality is almost always wrong. - House

   
Kuz - Törzstag | 4455 hsz       Online status #65017   2007.07.31 05:28 GMT+1 óra  
Ez marha jó. A sima dx9-es mdx már nem támogatott ms oldalról. Nem soká jön a dx10.1, erre most jönnek a dx10 managed változatával...Most tényleg ennyire logikátlan az MS munkája???
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
~Cre@tine~> - Tag | 702 hsz       Online status #65009   2007.07.31 04:31 GMT+1 óra  
TPG - Tag | 3402 hsz       Online status #49169   2007.03.27 07:59 GMT+1 óra  
Idézet
kuzanth :
Ezek szerint az Antialiasing egyfajta MultiSampling (avagy fordítva)?
Melyik mit csinál kicsit bővebben?
Egyszerre lehet/szabad/érdemes használni őket?

A hibáról most nem tudok képet küldeni, de majd otthon vadászok valamit, ha az nem szállt el a régi winyómmal együtt ...


Nem, pont fordítva: Antialiasing = élsimítás (csak egy elméleti összefoglaló fogalom, ami tartalmazza a gyakorlati megvalósításokat), a Multisampling csak egy konkrét megvalósítása.
A Multisampling-ról meg itt olvashatsz egy tömör kis írást. (Meg a supersamplingról is ha továbbmész a linken ami a szövegben van rá.)
Reality is almost always wrong. - House

   
Kuz - Törzstag | 4455 hsz       Online status #49162   2007.03.27 07:36 GMT+1 óra  
Ezek szerint az Antialiasing egyfajta MultiSampling (avagy fordítva)?
Melyik mit csinál kicsit bővebben?
Egyszerre lehet/szabad/érdemes használni őket?

A hibáról most nem tudok képet küldeni, de majd otthon vadászok valamit, ha az nem szállt el a régi winyómmal együtt ...
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
TPG - Tag | 3402 hsz       Online status #49159   2007.03.27 07:05 GMT+1 óra  
Idézet
kuzanth :
Idézet
kuzanth :
Felmerült egy kérdés, amikor Orphy kollégával az enginjeinket nézegettük. A kérdés pedig az, hogy mi a különbség az antialiasing és a multisampling között? Másik kérdés, hogy miért van az, hogy a hlsl-es progim első indításkor a 9600XT kártyáján szétesett, majd a gépén újra lefordítva a progit, sem a F5 után, sem pedig exe-ről való indítás után nem volt nagy baj (a "vizen" látszódott valami hiba, de a többi modell jól jelent meg). Valaki mondja már meg miért nem szeretik a progijaimat az Ati kártyák!? Tudom-tudom...GeForce rulez !


A napokban újra felmerült ez a két kérdés...Vélemények?


Antialiasing - élsímítás összefoglaló nevén
Multisampling - élsimítási technika, gyorsabb a supersampling-nél de nem ad olyan jó eredményt
A szétesett alatt meg mit kell konkrétan érteni?
Reality is almost always wrong. - House

   
Kuz - Törzstag | 4455 hsz       Online status #49103   2007.03.26 05:17 GMT+1 óra  
Idézet
kuzanth :
Felmerült egy kérdés, amikor Orphy kollégával az enginjeinket nézegettük. A kérdés pedig az, hogy mi a különbség az antialiasing és a multisampling között? Másik kérdés, hogy miért van az, hogy a hlsl-es progim első indításkor a 9600XT kártyáján szétesett, majd a gépén újra lefordítva a progit, sem a F5 után, sem pedig exe-ről való indítás után nem volt nagy baj (a "vizen" látszódott valami hiba, de a többi modell jól jelent meg). Valaki mondja már meg miért nem szeretik a progijaimat az Ati kártyák!? Tudom-tudom...GeForce rulez !


A napokban újra felmerült ez a két kérdés...Vélemények?
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Ati500 - Tag | 119 hsz       Online status #47774   2007.02.22 07:36 GMT+1 óra  
A következő problémában kérném segítségeteket:
C# alatt MDX-el csinálok olyan 2d-s grafikát, hogy létrehozok egy Sprite-ot, aztán a Draw2D() metódusával rajzolok textúrákat a konkrét 2d-s x és y koordinátákat megadva. Úgy tudom, ez egy bevett gyakorlat és sok 2d-s program készült már így.
Az egész alapja egy négyzetháló, amit úgy rajzolok ki, hogy van egy pl. grid.bmp nevű képem, ami szinte teljesen üres, csak a legfelső sorában van egy 1 pixel vastagságú horizontális és a bal szélén egy vertikális vonal. Ha ezt a mintát x és y tengely mentén is folyamatosan ismétlem, akkor ugye egy négyzetháló lesz az eredmény. Ezt le is programoztam, de az eredmény kissé érdekes lett... Itt egy kép róla:

Látszik, hogy a második sorban és alulról a harmadikban nincsen vízszintes vonal. Ez miért van? Mit kell tennem, hogy úgy rajzolja ki, ahogy én szeretném? Örülnék, ha valaki tudna segíteni, mert egyenlőre ez hátráltatja a projektemet...
Előre is köszönöm!

   
Orphy - Törzstag | 1893 hsz       Online status #45367   2007.01.22 00:10 GMT+1 óra  
Cre@tin:
Igazad van, csak diplomatikusan fogalmaztam

Shade:
Ez is igaz, bár egyelőre úgy tudom, a nem Windows alapú megoldások még nincsenek annyira kiforrva... Az megint más kérdés, hogy hiába fut a .net-es kód Linux alatt, ha ott nincsen DirectX
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #45238   2007.01.21 02:31 GMT+1 óra  
Igen, és van is benne lehetőség nem is kevés. Mert hogy hogy is működik ez az egész .Net-es cucc? Nagyvonalakban (ami nekünk fontos), amikor lefordítod a kódot akkor abból egy IL (intermediate language) kód lesz, ami egy fajta objektum orientált assembly nyelv. Méghozzá olyan assembly, ami utasításokat tartalmaz, de nem natív, tehát 1ik hardware architektúrához sem köthető (nem fordítható le/ indítható el). VIszont amikor rákattintasz az exe-re, akkor a CLR ebből az assembly-ből készíti el a futtatható kódot. Hogy ez miért jó? Mert így csak a CLR-nek kell megfelelnie a gépednek, a kódnak nem. Azaz ha megírják a CLR-t Linuxra és Windows-ra is, ugyan úgy fog működni a kód amit betolsz alá. De ha ezen kicsit tovább gondolkozunk, akkor rájöhetünk, hogy ebben ennél jóval több rejlik: mivel a kód nem fix, nem egy sima exe, a CLR-nek van lehetősége optimalizálni is a kódot! Azt pontosan nem tudom, hogy milyen mértékben, de pl. XNA faq-ban le is írják, hogy ezt csinálja, fordít egy optimalizált exe-t. Erre pl. sima C++ nem képes, és ez igen nagy előny a .Net mellett, mert ezen pl. tényleg lehet fejleszteni még, és egyre gyorsabb kódot lehet vele elérni.
   
~Cre@tine~> - Tag | 702 hsz       Online status #45209   2007.01.20 12:50 GMT+1 óra  
Ja még elfelejtettem, hogy a sebesség szerintem nem a nyelven múlik elsősorban. Vannak jó engine-ek amiket 100% ban c#-ban írtak, nem hibridek, amik natív dll-eket hivogatnak és némelyik igencsak veri a c++ os népszerű engine-eket sebességre. Később ez még úgyis fejlődni fog a c# javára. A jó öreg c++ meg már nem igen fog fejlődni sehova sem.

   
~Cre@tine~> - Tag | 702 hsz       Online status #45207   2007.01.20 12:41 GMT+1 óra  
Idézet
Orphy :
Alapvetően a használt programozási nyelvtől...


Még azért nem másztam bele a dolgokba, de azért ettől jóval nagyobb a különbség szerintem. Kb olyan, a c++ os sima DX fejlesztés a c# managed-hez képest, mintha assemblyben kellene DOS-ra írni egy engine-t. Szóval elég meredek.

   
Joga - Törzstag | 1791 hsz       Online status #45129   2007.01.19 15:08 GMT+1 óra  
Akkor maradok a simánál, mert úgyis c++-ozok
Idézet
Orphy :
. Cserébe kis odafigyeléssel a játékod XBox360-on is futtatható.


nincs xbox-om
(ಠ ›ಠ) Stewie!

   
Orphy - Törzstag | 1893 hsz       Online status #45128   2007.01.19 15:02 GMT+1 óra  
Alapvetően a használt programozási nyelvtől...

A sima DirectX-et C++ alól tudod programozni, a Managed DirectX-et pedig bármilyen .NET-es nyelvvel. Utóbbiak már magasabb szintű nyelvek a C++nál, jóval gyorsabban lehet velük ugyanazt a feladatot megoldani, és ezt a szemléletet valamelyest átültették a Managed DirectX-re is: egy csomó dolog már alapból be van wrappel-ve, szóval könnyebb használni valamelyest... A filozófiája egyébként mindkettőnek ugyanaz.

A C++os megoldások mellett továbbra is a sebességet szokták felhozni fő érvként, és valószínűleg igazuk is van... Ennek ellenére nekünk eddig nem sikerült annyira jelentős teljesítménycsökkenést észlelni a .NET-es megoldásoknál, sőt, voltak helyek, ahol a .NET-es kód gyorsabban futott.

A .NET-es DirectX-hez még annyit: per pillanat elég erősen az XNA felé halad, amit az MS a Managed DirectX-ek utódjának szán. Ennél az új API-nál viszont követelmény (na jó, erősen ajánlott) a minimum shader 1.1-es támogatás, gyakorlatilag majdnem mindenhez használ shader-t... Cserébe kis odafigyeléssel a játékod XBox360-on is futtatható.
   
Joga - Törzstag | 1791 hsz       Online status #45114   2007.01.19 13:48 GMT+1 óra  
Miben különbözik a sima, és a netes directX?
(ಠ ›ಠ) Stewie!

   
Orphy - Törzstag | 1893 hsz       Online status #45063   2007.01.19 04:01 GMT+1 óra  
Idézet
~Cre@tine~> :
Találtam egy érdekes munkát "Grafikus motor belső terekre" MDX-es.
http://i.aut.bme.hu/onlab/AgocsAlbert/dipl/
Egyébként mi a helyzet az MDX-el? mdx2-nél ott a time bomb. Az mdx-et nem fejlesztik már tovább és helyette XNA lesz, vagy hogy van ez?



Jól látod a helyzetet...
Az XNA kb az mdx3, az MS a jövőben várhatóan azt fogja nagy erőkkel nyomni, míg a többiek szép lassan elenyésznek az időben...
   
~Cre@tine~> - Tag | 702 hsz       Online status #45039   2007.01.18 14:23 GMT+1 óra  
Találtam egy érdekes munkát "Grafikus motor belső terekre" MDX-es.
http://i.aut.bme.hu/onlab/AgocsAlbert/dipl/
Egyébként mi a helyzet az MDX-el? mdx2-nél ott a time bomb. Az mdx-et nem fejlesztik már tovább és helyette XNA lesz, vagy hogy van ez?

   
Kuz - Törzstag | 4455 hsz       Online status #40144   2006.12.09 10:19 GMT+1 óra  
Felmerült egy kérdés, amikor Orphy kollégával az enginjeinket nézegettük. A kérdés pedig az, hogy mi a különbség az antialiasing és a multisampling között? Másik kérdés, hogy miért van az, hogy a hlsl-es progim első indításkor a 9600XT kártyáján szétesett, majd a gépén újra lefordítva a progit, sem a F5 után, sem pedig exe-ről való indítás után nem volt nagy baj (a "vizen" látszódott valami hiba, de a többi modell jól jelent meg). Valaki mondja már meg miért nem szeretik a progijaimat az Ati kártyák!? Tudom-tudom...GeForce rulez !
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Orphy - Törzstag | 1893 hsz       Online status #38650   2006.11.28 04:42 GMT+1 óra  
Lehet, hülye kérdés, de...

Miért használsz erre 2 form-ot?
Ezt a feladatot asszem gameState-ekkel szokták megcsinálni.

Esetleg, ha a videós lenne alapból látható, és nem csuknád be azt, hanem fölényitnád a másikat?

Bocs, ha hülye ötletek, még nem csináltam ilyet, de a topic legalább fent marad
   
Kuz - Törzstag | 4455 hsz       Online status #38449   2006.11.26 08:18 GMT+1 óra  
Hogy lehet megoldani azt, hogy ha több formon is dolgozok (egyik a videolejátszás, utánna pedig a renderelés), akkor a két form váltása közben ne lehessen látni, ahogy az első eltűnik és feljön a második, hanem "folyamatos" legyen az átmenet (azaz ne lehessen látni semmit, ami arra utal, hogy most váltás volt)?
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Ati500 - Tag | 119 hsz       Online status #37439   2006.11.19 08:14 GMT+1 óra  
Hogy mondják szépen magyarul az alpha blendet??
Alfa keverés? Alfa érték keverés?
Írok egy MDX tutorialt és nemtom hogy fordítsam...

   
Jedi - Tag | 175 hsz       Online status #35972   2006.11.09 09:51 GMT+1 óra  
Idézet
TheProGamer :
Ez a lustán frissíti dolog azt jelenti hogy pl Reset után csak az első rendernél húzza át sysmem-ből a cuccokat viszont onnantól kezdve viszont már ott vannak a VGA által elérhető memóriarészben?



Pontosan. Általában azt szokták csinálni, h minden textúrával renderelnek egy háromszöget a legelső frame-re (ezt nem jelenítik meg) és ez berántja a textúrákat a video mem-be.
Szintén ez a szokás a managelt vertex/index bufferekkel.

   
TPG - Tag | 3402 hsz       Online status #35966   2006.11.09 09:08 GMT+1 óra  
Idézet
Jedi :
Hmm, épp az a helyzet, h nem gyors néhány esetben. Pl. a managed erőforrásokat elég lustán frissíti az agp és video memóriában és csak akkor tolja át a sysmemből, amikor ténylegesen használná a renderhez őket. Plusz még néhány más esetben sem célszerű managed-et használni (pl néha dinamikus vertex/index buffereknél, vagy ha vmiért olvasni akarunk egy bufferből) , de az tény, h 1000x kényelmesebb, így a kezdetekben mindenképp a managed-et érdemes használni.


Mindennap tanulok valami újat. Egyébként Dynamic usage-nél nem is lehet Managed pool-t használni, inkompatibilisek egymással. Ez a lustán frissíti dolog azt jelenti hogy pl Reset után csak az első rendernél húzza át sysmem-ből a cuccokat viszont onnantól kezdve viszont már ott vannak a VGA által elérhető memóriarészben?
Reality is almost always wrong. - House

   
Orphy - Törzstag | 1893 hsz       Online status #35952   2006.11.09 07:18 GMT+1 óra  
Oks, most már tiszta
Köszi
   
Jedi - Tag | 175 hsz       Online status #35951   2006.11.09 07:10 GMT+1 óra  
Idézet
Orphy :
A Managed lenne az AGP-s? Erről annyit tudok, hogy olyasmi, mint a system-mem, akkor használjuk, ha olvasni is akarunk belőle.
...
De akkor hol van az AGP?
Valaki homályosítson fel plz



A managed az nem egyenlő az agp-vel.

Memóriák:
- local video mem: a gpu-n levő memória, a gpu gyorsan írja/olvassa, de a cpu-val elérni halál lassú
- sytem mem: a rendszermemória (ezt a gpu nem tudja elérni)
- agp mem: a rendszermemória egy része, ami el van különítve a gpu számára, ezt tudja írni/olvasni a gpu és cpu is. (a gpu-nak ez lassabb mint a local, és a cpu-nak lassabb mint a system)

memory pool-ok:
- system pool: ez egyszerűen a rendszermemóriát jelenti
- default pool: ez azt jelenti, h minden erőforrás oda kerül, ahol az adott api és driver szerint a legjobb neki. pl. statikus textúrák a video mem-be, vagy ha az betelt, akkor az agp mem-be.
- managed pool: az erőforrások itt is ugyanoda kerülnek, mint a default-nál (vagy az agp-be vagy a video-ba), de van róluk egy másolat a system mem-ben (így lost device-nál nem kell resetelni és szenvedni velük)

Vannak olyan tipikus erőforrások, amiket jó eséllyel az agp mem-be pakol a rendszer (pl egy dinamikus, writeonly-s vertex buffert berakunk a default pool-ba, akkor az az agp mem-be fog kerülni). Vagy pl index bufferek szintén kerülhetnek vagy az agp mem-be vagy a video-membe ha a default poolba raktuk (ezért nem szabad pl a system pool-ba pakolni index buffert, hagyni kell h a driver döntse el, h hova kerüljön).

   
Orphy - Törzstag | 1893 hsz       Online status #35920   2006.11.09 01:40 GMT+1 óra  
Idézet
kuzanth :
Ő lenne az



Nah, pill, most már nem tiszta valami...
Arról most hallok először, hogy AGP memóriával is lehet bűvészkedni...

Megnéztem az MSDN-es linket is, de nem találtam olyat, ahol írná, hogy ez most az AGP mem-be megy. Az eddigi forrásaimnál is csak system mem, és video mem volt említve célként.

A Managed lenne az AGP-s? Erről annyit tudok, hogy olyasmi, mint a system-mem, akkor használjuk, ha olvasni is akarunk belőle.

MSDN:
Resources are copied automatically to device-accessible memory as needed. Managed resources are backed by system memory and do not need to be re-created when a device is lost.

Ebből nekem az jön le, hogy az adatok a system mem-ben, és bemásolja a video mem-be, ha szükség van rá. ---> Ergó lassabb, mint a Pool.Default, de cserébe olvasható + nem kell foglalkozni a DeviceLost-tal.

De akkor hol van az AGP?

Valaki homályosítson fel plz
   
Jedi - Tag | 175 hsz       Online status #35912   2006.11.08 16:44 GMT+1 óra  
Idézet
TheProGamer :
Ez a mit-mikor-hova egy viszonylag egyszerű kérdés hármas: mindent amit tudsz managed pool-al kell csinálni mert kényelmes és gyors.



Hmm, épp az a helyzet, h nem gyors néhány esetben. Pl. a managed erőforrásokat elég lustán frissíti az agp és video memóriában és csak akkor tolja át a sysmemből, amikor ténylegesen használná a renderhez őket. Plusz még néhány más esetben sem célszerű managed-et használni (pl néha dinamikus vertex/index buffereknél, vagy ha vmiért olvasni akarunk egy bufferből) , de az tény, h 1000x kényelmesebb, így a kezdetekben mindenképp a managed-et érdemes használni.

   
TPG - Tag | 3402 hsz       Online status #35906   2006.11.08 14:45 GMT+1 óra  
Idézet
kuzanth :
Csak hogy az ifjoncok is okuljanak :

"Resources are placed in the memory pool most appropriate for the set of usages requested for the given resource. This is usually video memory, including both local video memory and accelerated graphics port memory. The Default pool is separate from Managed and SystemMemory, and it specifies that the resource be placed in the preferred memory for device access. Note that Default never indicates that either Managed or SystemMemory should be chosen as the memory pool type for this resource." - itt van hozzá a link, akit érdekel
Egyébként olvastam egy érdekes cikket arról, hogy mit-mikor-hova érdemes pakolni (CPU és GPU viszonylatban). Ha jól tudom az MDXInfo oldalon, de majd utánnanézek!


Ez a mit-mikor-hova egy viszonylag egyszerű kérdés hármas: mindent amit tudsz managed pool-al kell csinálni mert kényelmes és gyors.
Reality is almost always wrong. - House

   
Kuz - Törzstag | 4455 hsz       Online status #35903   2006.11.08 14:30 GMT+1 óra  
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Kuz - Törzstag | 4455 hsz       Online status #35902   2006.11.08 14:27 GMT+1 óra  
Csak hogy az ifjoncok is okuljanak :

"Resources are placed in the memory pool most appropriate for the set of usages requested for the given resource. This is usually video memory, including both local video memory and accelerated graphics port memory. The Default pool is separate from Managed and SystemMemory, and it specifies that the resource be placed in the preferred memory for device access. Note that Default never indicates that either Managed or SystemMemory should be chosen as the memory pool type for this resource." - itt van hozzá a link, akit érdekel
Egyébként olvastam egy érdekes cikket arról, hogy mit-mikor-hova érdemes pakolni (CPU és GPU viszonylatban). Ha jól tudom az MDXInfo oldalon, de majd utánnanézek!
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Orphy - Törzstag | 1893 hsz       Online status #35901   2006.11.08 14:16 GMT+1 óra  
A Pool.Default a vidókártya. a Pool.Managed és a Pool.SystemMem a rendszermemória.

Viszont ez asszem csak arra vonatkozik, hogy a textúra képi adatait hová pakolja - ha a videokártyára, akkor gyorsabb lesz használni, de figyelni kell a deviceLost-ra is.

Szerintem a tex-ed objektuma ilyenkor a system mem-ben, a tex-edbe töltött kép pedig a videokari memóriájában jön létre. Viszont ebben nem vagyok 100%-ig biztos...

Ha nagy hülyeséget mondtam, kéretik kijavítani
   
Kuz - Törzstag | 4455 hsz       Online status #35899   2006.11.08 14:07 GMT+1 óra  
"A vga memória, és a system memória két külön dolog" - jéééé...mik vannak..
Kód:
Texture rendertargettexure = new Texture(dev, dev.DisplayMode.Width, dev.DisplayMode.Height, 1, Usage.RenderTarget, Format.X8R8G8B8, Pool.Default);

Akkor ez most hova pakolja a textúrát? A rendertarget miatt kell a Pool.Default, de az ebben az esetben a vga memória, nem?
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Orphy - Törzstag | 1893 hsz       Online status #35896   2006.11.08 13:55 GMT+1 óra  
A vga memória, és a system memória két külön dolog

A textúrád a Dispose hívásakor a vga memóriában tárolt cuccait felszabadította, de maga a textúra, mint object a rendszermemóriában valószínűleg egy darabig még megmaradt.

A GC elvileg "üresjáratban" fut, a GC.Collect-tel tudod kényszeríteni a szemétgyűjtést.
A GC továbbá lefut a progid bezárásakor is, természetesen.

Érdemes egyébként egy profiler-rel nézelődni, tanulságos élőben látni, miket művel a GC...
Én anno ezzel próbálkoztam (sajna csak 2 hétig free, de addig nagyon jól jött):

Red Gate's ANTS Profiler
   
Kuz - Törzstag | 4455 hsz       Online status #35872   2006.11.08 12:04 GMT+1 óra  
Orphy : "Igaz, ott van az IDisposable, meg a GC.Collect()...
Előbbi a tévhiedelmekkel ellentétben NEM takarítja el az objektumot, hanem csak meghívja a Dispose() metódusát, ami arra hivatott, hogy az objektum által lefoglalt erőforrásokat felszabadítsa. Ettől maga az objektum továbbra is ott fog figyelni a memóriában, amíg nem találkozik a GC-vel... A GC.Collect() sem garancia arra, hogy tényleg törlődik az objektum, mert ha van rá máshol ref, akkor ugye semmit nem ér"

Nos, mint mondottam vala (mármint azt hiszem mondtam), a Textúra, amit használtam ugye 3,5mb (1024x768-as bmp) volt, és a felszabadítás hiánya miatt a 37. framenél szállt el a progi. Ha jól sejtem elfogyott a vga memória (3,5mb*37 > 128mb). Miután a render függvény végén dispose-oltam a textúrát, minden megjavult. Namost 37 frame igen gyorsan lezajlik, amikor átlag 120-130 fps-sel fut a progi. Ezek szerint a GC volt ennyire gyors, hiszen ahogy még1x ismétellek : "Ettől maga az objektum továbbra is ott fog figyelni a memóriában, amíg nem találkozik a GC-vel"? Referencia nincs a textúrára, így ezzel nem lehet baj. De azért érdekelne, hogy milyen gyorsan...mármint, hogy milyen időközönként dolgozik a GC?

Ja, és köszi hogy (idézem) : "Megvédeném Kuzanth-ot. "
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
nagyy - Törzstag | 248 hsz       Online status #35845   2006.11.08 09:44 GMT+1 óra  
Hmm. Ezt eddig nem is ismertem. Mindíg tanul az ember.
   
Kredisoft - Tag | 194 hsz       Online status #35825   2006.11.08 07:12 GMT+1 óra  

Igen ez az, én is ugyan így oldottam meg...

A másik lehetőség az hogy használod a System.Windows.Forms.Control.MousePosition propertie-t. Ez ténylegesen ScreenCoot ad neked vissza, és amikor a képernyő sarkához érsz megáll, és nem is számol tovább

Ha gondolod próbáld ki ezt is....

Köszi

   
nagyy - Törzstag | 248 hsz       Online status #35820   2006.11.08 06:32 GMT+1 óra  
Én ezt úgy oldottam meg, hogy van egy statikus osztály, ami az egeret kezeli. Ebben van egy Point típusú CursorPos nevű tulajdonság. Ezt az osztály inicializálásakor az aktuális kurzorpozícióra állítom, majd később a Device.CurrentMouseState-ben lévő X,Y értékeket a CursorPos megfelelő X, Y tulajdonságaihoz adom. (fontos hogy ezt folyamatosan el kell végezni, mondjuk framenként).
Így később a CursorPos-ban mindíg a megfelelő koordináták lesznek.
Annyi problémája van ennek a módszernek, hogy figyelni kell, hogy a koordináta ne kerüljön a "képernyő kívülre", mert ha mondjuk a kurzor a már képernyő legszélén van, és a user vadul húzza az egeret a képernyő széle felé, akkor a CurrentMouseState-be ugyanúgy belekerülnek a relatív elmozdulási értékek, és a CursorPos a képernyőn kívülre kerülhet.

De ha valaki tud egyszerűbbet, akkor az érdekelne.
   
Kredisoft - Tag | 194 hsz       Online status #35811   2006.11.08 05:12 GMT+1 óra  
Idézet
kuzanth :
Idézet
Kredisoft :
Milyen módszerrel szoktatok DirectInput-ban a mouse koordinátáit ScreenKoordinátákra átszámolni? Simán csak egy váltózóban eltároljátok a kezdőértékeket, és aztán kiszámoljátok?


Most valami ilyesmire gondolsz : mouse.CurrentMouseState.X (ill. Y, vagy Z); ?



Igen ilyen lett volna, csak nekem screencordinates-ben kellett volna. Tehát gyakorlatilag azt adja vissza hogy 1024*768-as felbontásban hanyadik pixelre mutat éppen az egérke. Ez meg visszaad nekem itt ilyen 10Milla meg -42 Milla koot.

Winformoknál ezt tudtam csinálni:
System.Windows.Forms.Control.MousePosition.X stb.

Van ilyen DX inputban. Lehet ilyen állapotot beállítani a Mouse Devicének?

Kösz...

   
Orphy - Törzstag | 1893 hsz       Online status #35808   2006.11.08 05:05 GMT+1 óra  
Ja, az IDisposable-hez hozzátenném, hogy a legnagyobb előnye az, ha implementálod egy osztályba, akkor azt az osztályt használhatod using-gal...

Kód:
using( MyClass c )
{
// ...utasítások
}


A using záróblokkjával a MyClass objektumk megszűnik!
   
Orphy - Törzstag | 1893 hsz       Online status #35807   2006.11.08 05:03 GMT+1 óra  
Idézet
kuzanth :
Az oktatás hibája, mert elhitették velünk, hogy a C#-ban a GC mindent elintéz. Na de most már legalább tudom az igazságot! De azért rakhatnának több példát is az sdk-ba...



Megvédeném Kuzanth-ot.

A GC-t eddig, ahol találkoztam, tényleg mindenhol Istennek állították be.
Már bocs, de teljesen f*** hozzáállás, hogy bízz mindent a GC-re, a programozó ne nyúljon hozzá a memóriához... Igaz, ott van az IDisposable, meg a GC.Collect()...
Előbbi a tévhiedelmekkel ellentétben NEM takarítja el az objektumot, hanem csak meghívja a Dispose() metódusát, ami arra hivatott, hogy az objektum által lefoglalt erőforrásokat felszabadítsa. Ettől maga az objektum továbbra is ott fog figyelni a memóriában, amíg nem találkozik a GC-vel... A GC.Collect() sem garancia arra, hogy tényleg törlődik az objektum, mert ha van rá máshol ref, akkor ugye semmit nem ér, másrészt a GC-n belül több szint is lehet, amiből a GC ha jól emlékszem, csak a legalacsonyabbat rúgja seggbe, a többieknek csak a szintjét változtatja.

Vannak esetek, amikor ez a fajta deviáns viselkedés kifejezetten idegesítő...
Pl: Kaptam egy C++ban írt API-t, ami a C++ szabvány szerint az erőforrások felszabadítását a destruktorban végzi...

A GC hülye filozófiája miatt nincs lehetőség arra, hogy ezt meghívjam... Ebben az esetben a GC.Collect() nem segített ki, Dispose() ugye nincsen... Mivel külsős API, nem túl esélyes, hogy lesz benne Dispose...

Szidom itt rendesen, de azért sokszor jó a GC...
Viszont gondolhattak volna az ilyen, és hasonló esetekre is...
Vannak esetek, amikor tényleg arra lenne szükségem, hogy ott, és akkor szűnjön meg egy object, amikor én akarom...
   
Kuz - Törzstag | 4455 hsz       Online status #35805   2006.11.08 04:49 GMT+1 óra  
Idézet
Kredisoft :
Milyen módszerrel szoktatok DirectInput-ban a mouse koordinátáit ScreenKoordinátákra átszámolni? Simán csak egy váltózóban eltároljátok a kezdőértékeket, és aztán kiszámoljátok?


Most valami ilyesmire gondolsz : mouse.CurrentMouseState.X (ill. Y, vagy Z); ?
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Korábbi postok
> 1 < [2] [3] [4] [5]