A 100*100-as jobb fölsõ sarka belelóg a 64*64-es bal alsó sarkába az X tengelyen,
nem lehet hogy ez a probléma?

Na, megint itt vagyok

Hétvégén klántalálkozón voltam, nem tudtam túl sokat szöszölni a projekttel...
A rossz bitmap leképezés probléma közben megoldódott (kösz GyMisi!), és minden szuper is lenne, ha

Valami nem teljesen okés... Feltettem 2 sprite-ot, egyelõre csak arra vizsgálok, hogy a 2 négyzet területe összeér-e, ha igen, akkor ütközés. És jól is megy. Elvileg...

2 ugyanolyan méretû sprite esetén
Ha az egyik sprite kisebb, akkor furcsán viselkedik...

Pontosan így:
http://www.kepfeltoltes.hu/060710/sw_utkozes_www.kepfeltoltes.hu_.jpg

Szerinte ez így ütközés... Ami azért furcsa, mert debug módban megnéztem a koordinátákat, és azok alapján viszont tényleg ütköznek

A 100x100-as kép koordinátái: 500,500, ebbõl számolva a jobb alsó 600,600
A 64x64-esé pedig 600,440, ebbõl a jobb alsó: 664,504

Ütközés elvileg a 100x100as jobb felsõ sarkánál (600,500)
És a 64x64-es bal alsó sarkánál: 600,504 van. És ez így ok is.

De akkor miért úgy jelenik meg, ahogy?
A megjelenítés, és a koordináták nincsenek szinkronban... Pedig mégis, merthogy mindenki az X,Y koordinátájára van kirajzolva...

Öööö, ez mi lehet ?

Egyébként is türelmetlen vagyok...

Tegnapelõtt kezdtem, akkor meglett 0-ról az alap "motor", a sprite megjelenítés, a zene lejátszás, fullScreen, fps... És billentyûkezelés a .NET-es módszerrel, amit majd át kell alakítani directInput-ra, mert egyszerre több billentyû lenyomásánál... Khmmm... Butuska...

Ehhez képest tegnap végig szívtam az ütközéskezeléssel, és nem haladtam igazából semmit

És a legfõbb probléma: még nincs kész

Jaaa,

kerestem, nem csak google-n...
De vagy nem találtam, vagy találtam, de nem sprite-ra, és közelítõ gömb, vagy téglalap módszerrel mindenhol.

Tekintve azt, hogy amit az elõbb leírtam, már a c64 is így tudta (igaz, alapból, hardveresen), nem hinném, h a gépemen ilyen siralmas eredményt kellene hogy produkáljon ez a néhány sprite... Végülis talán mondhatjuk, hogy "kicsit" jobb a teljesítménye, mint 1 c64-nek...

Bízom benne, h ez az utolsó nagy szívásom a miniGame-mel...
A többi tech dolog már nagyjából megvan... Kivéve a gui-t...

De ha ezzel nem jutok dûlõre, nem fogok tudni indulni

Eredetileg úgy képzeltem, h ha megvan az éppen élõ bitmap-em, akkor:

megnézem, h a 2 vizsgált sprite-nak vannak-e egymásba lógó részei, ha nincs, nem ütköznek
Ha vannak, akkor veszem a közös részt, és megnézem, hogy a kettõt egy koordinátarendszerben viszgálva van-e olyan nem átlátszó pontjuk, aminek a koordinátája közös - ha igen, ütközés, egyébként nem...

Az elmélet szerintem tökjó , csak a koncepció indulópontjánál, az éppen aktuális bitmap-nél vannak a gondok... Mert a d3d sprite-ból nem tudom kiszedni...
Ha normál .Net rajzolással elõállítom az eredeti frame-kép alapján, 1000-> 80 fps
Ha backbuffer surface->Bitmap -> 1000 ->2 fps

Fent van 3 különbözõ méretû animált cucc, meg 1 nem animált, de mozgatható sprite.

A sebességteszt eredménye enyhén szólva siralmas, 1700+ Athlon Xp proci, 512 MB ram, ATI Radeon 9600 XT videokari... És 4 sprite...

Persze a sprite-ok mérete jelentõsen befolyásolja a sebességet, legalábbis a .Net-es bitmap elõállításnál tuti...

Ez is csak egy ötlet, mert ilyet meg még kevesebbet csináltam:
írsz egy progit, ami direkt arra van, h elkészítse a bitmap alapján a körvonalat, vagyis annak a pontjait, és letárolja egy külön file-ba. Ez nagyon sokat kéne h dobjon a sebességen. Ja és itt még tudsz olyan trükköket is, hogy (nemtom milyen pontos kell) mondjuk nem minden pixelt tárolsz le, csak minden 3.-at, és köztük egyenest húzol ("képzeletben", így azért elég pontos lesz a számítás, mégis 1/3-mad annyi pontot kell kezelned.

Tudom, hogy nem egyszerû, dehát ez van, ha ilyen dolgot akarsz csinálni, azért meg kell szenvedni De azért ezt se vedd készpénznek, sztem érdemes lenne szétnézned google-ön, hátha van vmi.

Találtam még 1 ilyet is:



Ez egészen jó ötletnek tûnt, de még lassabb lett, mint az elõzõ...
Jaaa, és valamiért nem teljesen jó, mert a sprite-om jobb alsó negyede került a bitmap bal felsõ negyedébe, de ez most részletkérdés a sebesség szempontjából

Kezdek kifogyni az ötletekbõl...

Viszont az tényleg nem szeretném, h mondjuk sprite közepén 1 valami, széle átlátszó, a másiknak szintén, de ha a két átlátszó rész összeér, már akkor ütközés...
Merthogy valójában kilóméterekre mennek el egymástól, legalábbis úgy rajzoljuk ki

Hmmm... Ti ezt hogyan szoktátok?

Hmmm, amilyen jól haladtam tegnap, olyan rosszul ma...

Kis probléma az ütközésgenerálással:
ha lehet, nem szeretnék közelítõ megoldást, így ismernem kell a bitmap-et, amit éppen kirajzol a sprite-hoz... Ez eddig ok...

Csak aztán jöttek a bajok... Nem találtam semmit, amivel ezt ki is tudtam volna tenni szépen Bitmap-be... Illetve találtam egy megoldást, bitmap másolgatás gdi-vel... Tetû lassú... a 800-1000 fps-embõl egybõl leugrott 100 alá

Asszem, mára most adom fel a keresgélést...
Textúrából adott téglalapot megfelelõ transzformációkkal (scale, rotate), gyorsan Bitmap-be kimásolni...

Tudtok erre valami jó módszert?
Tuti van rá vmi...

Ez nagyon egyszerû. Annyi, h amikor ugyebár nyomsz egy update-et, akkor már a következõ poziciót számolod ki. Ha ez testen belül van, akkor a szerint cselexel, állítod a változókat stb. és csak update UTÁN jön a Draw, amire már mindent kiszámoltál. Azaz, ha még kint van, akkor update csak azt számolja, hol lesz a golyó, ha viszont ütközés is volt, akkor azt is kikalkulálod, és csak ez után jeleníted meg.
Ez egy golyónál mindenképpen mûködik, bonyolultabbat még nem csináltam, de sejtem, ott sem lehet gond.

Ahhhhaaaa, valahogyan sejtettem, nem találtam a doksiba collosion detection címszó alatt...
Gondoltam, hátha csak én vagyok vak

Egyes rendereknél meg is van az ötletem
Viszont mi van, ha a lövedék esetleg olyan gyors, hogy két render között át is megy az objektumon, az elsõ rendernél még elõtte, a másodiknál pedig már utána jár?

Erre szoktak azt hiszem sugárkövetéses módszert alkalmazni, csak sajna arról még alig tudok valamit

Öööö, eltárolom a lövedék utolsó render-nél levõ koordinátáit, és a köv rendernél megnézem, h az aktuális, és a tárolt koordinátákat összekötõ szakasz metszi-e az objektumot?

Az objektum esetleges animációjával itt mennyire érdemes törõdni? Normál esetben elvileg nem esik le annyira az fps, hogy jelentõs lehessen. Szerintem...

Én saját magam írtam rá ütközésdetektálást nem volt túlságosan nehéz. Én úgy tudom nincsen ilyesmi beépítve az API-ba.

Uhhhh

Lassú töltés visszavonva...
Nem gondoltam volna, hogy ENNYIT számít, h stúdióból futtatom, vagy nem...
A 40 sec-bõl lett 2,5... Fps meg megugrott vagy 200al felfelé

Collosion detection kérdés még mindig áll...
A fõ probléma ugyi, h nem kockákkal játszunk

Bááár, ha nem marad idõm a grafikára...

Hell megint,

kis 1xü kérdésem lenne...

Van-e vmi egyszerû, gyors, csodálatos, stb módszer D3D-ben sprite-ok ütközésdetektálására, vagy nekem kell kiokoskodnom rá vmit?

A másik, h az elsõ teszt alatt jelentõsen lassú volt a Sprite-init-em az animot tartalmazó 640x384-es gif miatt...

Ha 1 sprite használja -> 15 mp, ha 3 -> 40 mp
Azért ez nem teccik... A gif-et 1x töltöm be, textúrát viszont minden sprite csinál magának belõle, gondolom, ott ilyen tetvesül csiga...

Ok-ok, majd kirakhatok loading képernyõt, de...
Ez nekem akkor is túúúúúúúúúl lassúnak tûnik...

Ja, 1700+ Athlon Xp, 512 mb RAM, release fordítás...
C# managed DX

Valaki vmi ötlet?
Lassan már csak 2 hetem van

Jaaa, majdnem elfelejtettem: fps szám rendben van, ezen a gépen 150 körül az alja, 800 körül a teteje

Van egy Utility toolkit a DirectX Managed változatához. Ti használjátok ezt a toolkitet? Ha igen akkor hogy boldogultok vele?

Na, most jutottam el odáig, h tudok postolni, de látom, megoldottad
És 1xübbnek is tûnik, mint amit én találtam

Nekem is minden jó lett, színes, és pörög
Köszi mindenkinek, tanulságos volt

ferchild: 2 napja próbálok minél több emberrel beszélni, de senki sem tudta, hát megoldottam Igazából a lényegi dolog csak ennyi:

És persze ehhez legalább PositionColorTextured kell, ahol a color tag tartalmazza opacity-t (átlátszógásot, v alpha-t) Ehhez persze még kell a szokásos blend is



de ennyi, és így mûködik is...

sziasztok!

Majd igyekszem mindenki kérdésére válaszolni, de asszem nem ma lesz ennek a napja
Itt vagyok a munkahelyemen és nem igazán néz ki úgy a dolog, hogy még ma hazamegyek
Ergo => ShadeVampire: holnap talán lesz idõm. Remélem.
Bocs mindenkinek. Ez van .

Shade,

bár még csak most kezdtem, lehet, hülyeséget mondok, de szerintem próbáld ki, hogy az alpha a részecskéknél külön, kevergetés nélkül mûxik-e...
Valamiért nekem van 1 olyan sejtésem, hogy a keverésnél lesz a gubanc, rémlik, valahol olvastam, h az átlátszó részecskék rákeverése a mögötte levõ képre nem is olyan 1xü...
Igaz, az opengl volt...

Ha hazaértem, és lesz kis idõm, megkeresem, hogy csinálta.

ferchild: az én problémámra nincs vmi ötleted?

Idézet

---

ShAdeVampirE :
Áhh, már megint szívok ezzel. Vhogy még nem tudtam átállni DX gondolkodásmódjára

Szal azt szeretném megcsinálni, hogy: betöltök egy textúrát, aminek fekete pixeleit alpha 0-ra állítja azaz full átlátszóra, ezután pedig a részecske színét is hozzákeveri. Ez eddig mûködött is, ezzel:

Kód:

            device.SetRenderState(RenderStates.AlphaBlendEnable, true);
            device.SetRenderState(RenderStates.SourceBlend, (int)Blend.SourceAlpha);
            device.SetRenderState(RenderStates.DestinationBlend, (int)Blend.One);

Viszont most még azt is megkéne oldanom, h idõvel szép lassan elhalványuljon a részecske, egészen a haláláig. Ezt viszont hiába próbáltam, nem jött össze.

A színét egy color_panel-rõl kapja, viszont úgy, hogy
Color color = Color.FromArgb(100, panel_particle_color.BackColor);
ami mûködik is, de valamiért a 100-as Alpha-val is teljesen látható, nincs semmi áttetszõsége...

Pls. vki segítsen, mert ez már nagyon idegesít.

---

Köszi, fogok

nem egészen:

amit bekapcsolsz (vagy ki) az addig míg meg nem változtatod érvényben marad.
Pl: ha bekapcsolsz egy fényforrást akkor az addig világít míg ki nem kapcsolod. Ergo nem kell a fényeket külön-külön kapcsolgatni az objektekre, csak ha indokolt. Mellesleg ez is csak fixed function-nél van. Shader-eknél egy csöppet más a helyzet.

Ez minden state change-re igaz (cull mode, alpha blending, stb...) ergó olyan mindegy hogy mikor hívod meg õket, a lényeg hogy meghívd Szerintem a Reset nem futott le és ezért nem volt state change. Szerintem, nem oda kellene rakni ezeket. Írj egy külön fgv-t mondjuk egy initastatedefault-ot, amit szépen meghívsz device létrehozása után és a resetbe is ezt tedd. Az obj-ok state change-ét meg úgy tudod megoldani hogy szépen kapcsolgatod ami kell a render elõtt. erre azért vannak szép megoldások ( StateBlock, HLSL )

asszem mindenre válaszoltam de nem biztos

ha van kérdés szólj!

uhhh, bocs, rossz gomb...

Idézet

---

Orphy :
Nem lehet, h inkább az a baj, h ezek a state állítások nem a Tringle-ban, hanem az Engine-ben voltak eredetileg deviceReset-kor? Végülis a Triangle-höz tartoznak. Az ambient állítást már a Trianlge-ba raktam, úgy ment.

Eredetileg ez a reset (a GameEngine osztályban):

Kód:

static void s_D3DDevice_DeviceReset(object sender, EventArgs e)
        {
            Device dev = (Device)sender;
            // Turn off culling, so we see the front and back of the triangle
            dev.RenderState.CullMode = Cull.None;
            // Turn off D3D lighting, since we are providing our own vertex colors
            dev.RenderState.Lighting = false;
        }

Szóval itt volt a dev.RenderState.CullMode = Cull.None; csak nem vette be akkor.

Fényeket nem használtam, amit lent írtál, teljesen logikus. Végülis miért törõdjön fényforrás színekkel, ha nem is használ fényeket?
Viszont ha használok, akkor ezek szerint minden objekt-re külön kell majd kapcsolgatni...
Sõõt, akkor nem csak a fényeket, hanem úgy általában a state állításokat minden megjelenítendõ objektum esetében külön-külön el kell végezni...
Ha jól gondolom...

---

Nem lehet, h inkább az a baj, h ezek a state állítások nem a Tringle-ban, hanem az Engine-ben voltak eredetileg deviceReset-kor? Az ambient állítást már a Trianlge-ba raktam, úgy ment.

Eredetileg ez a reset:


Fényeket nem használtam, ergó amit lent írtál, teljesen logikus.
Viszont ha használok, akkor ezek szerint minden objekt-re külön kell majd kapcsolgatni...
Ha jól gondolom...

elsõ kérédésre a válasz szerintem:

ha a -ra állítod mindegy hogy elõtte az ambiens fényforrásnak a színét mire állítod, mert nagyívben lesz*rja a rendszer

ezért nem láttad ott a tutorban. felesleges state change csak.

mellesleg azért van mert amit úgysem látsz azt minek megjeleníteni vagy számolni vele

ez pusztán a culling miatt van (mármint az hogy a háromszög backface-e nem látszik.

device.RenderState.CullMode = Cull.None -ra állítod akkor látszania kell
CounterClockWise-nál nem látszik a backface, ClockWise-nál meg a frontface fog eltünni.


Backface culling (hátsólap eldobás magyarul) a neve. A cull mode állítja melyiket dobja el a rendszer. None esetén egyiket se. Ezért fog látszódni majd, viszont itt megjegyezném, hogy nem ideális None-ra állítani, mert komolyabb testeknél igencsak belassít. Egy Háromszögnél nem, de egy mesh-nél már igazán érezhetõ a sebességcsökkenés None esetben.

Idézet

---

gymisi :

Kód:

device.RenderState.Ambient = System.Drawing.Color.FromArgb(255, 255, 255, 255);
            device.RenderState.Lighting = false;

ez kell talán..

---

Köszi, mûxött, elõkerültek a színeim
2 dolog van még, amit nem értek:

Megnéztem újra a 3as tutort, de ott az Ambient-et nem állította sehol, a Lightning=false szerepelt csak, de az ott volt nálam is. Ott ment rendesen, nálam meg ugye nem... De miért?

A másik, ami nem tiszta, hogy a forgó 3szögembõl így már biztos vagyok benne, hogy csak 180 fokig látszik a mozgás, utána a 2. 180 fok erejéig maga a 3szög sem jelenik meg, holott a forgató kód megint csak 1 az 1ben egyezik...

Idézet

---

ShAdeVampirE :
A színét egy color_panel-rõl kapja, viszont úgy, hogy
Color color = Color.FromArgb(100, panel_particle_color.BackColor);
ami mûködik is, de valamiért a 100-as Alpha-val is teljesen látható, nincs semmi áttetszõsége...

---

Ezzel én is küzdtem, de aztán hagytam, nem értem....

Áhh, már megint szívok ezzel. Vhogy még nem tudtam átállni DX gondolkodásmódjára

Szal azt szeretném megcsinálni, hogy: betöltök egy textúrát, aminek fekete pixeleit alpha 0-ra állítja azaz full átlátszóra, ezután pedig a részecske színét is hozzákeveri. Ez eddig mûködött is, ezzel:


Viszont most még azt is megkéne oldanom, h idõvel szép lassan elhalványuljon a részecske, egészen a haláláig. Ezt viszont hiába próbáltam, nem jött össze.

A színét egy color_panel-rõl kapja, viszont úgy, hogy
Color color = Color.FromArgb(100, panel_particle_color.BackColor);
ami mûködik is, de valamiért a 100-as Alpha-val is teljesen látható, nincs semmi áttetszõsége...

Pls. vki segítsen, mert ez már nagyon idegesít.

Köszi, este megnézem.

Idézet

---

Orphy :
Jaaa, kis részlet:

GameEngine.Render():
---------------------------------
public static void Render()
{
if (s_D3DDevice == null) return;

s_D3DDevice.Clear(ClearFlags.Target, System.Drawing.Color.Wheat, 1.0f, 0);

s_D3DDevice.BeginScene();

foreach (roots.IGameMember gameMember in s_GameMembers)
{
gameMember.Draw(s_D3DDevice);
}

s_D3DDevice.EndScene();

s_D3DDevice.Present();
}


Triangle.Draw():
----------------------
public void Draw(Device device)
{
int primitiveCount = 1;

SetupMatrices(device);

device.SetStreamSource(0, m_VB, 0);
device.VertexFormat = CustomVertex.PositionColored.Format;
device.DrawPrimitives(PrimitiveType.TriangleList, 0, primitiveCount);
}

A Triangle osztály fontosabb dolgai, mint pl a vertexbuffer létrehozása, illetve a forgásért felelõs SetupMatrices 1 az 1ben a dx sdk tutorial 3...

---

ez kell talán..

Jaaa, kis részlet:

GameEngine.Render():
---------------------------------
public static void Render()
{
if (s_D3DDevice == null) return;

s_D3DDevice.Clear(ClearFlags.Target, System.Drawing.Color.Wheat, 1.0f, 0);

s_D3DDevice.BeginScene();

foreach (roots.IGameMember gameMember in s_GameMembers)
{
gameMember.Draw(s_D3DDevice);
}

s_D3DDevice.EndScene();

s_D3DDevice.Present();
}


Triangle.Draw():
----------------------
public void Draw(Device device)
{
int primitiveCount = 1;

SetupMatrices(device);

device.SetStreamSource(0, m_VB, 0);
device.VertexFormat = CustomVertex.PositionColored.Format;
device.DrawPrimitives(PrimitiveType.TriangleList, 0, primitiveCount);
}

A Triangle osztály fontosabb dolgai, mint pl a vertexbuffer létrehozása, illetve a forgásért felelõs SetupMatrices 1 az 1ben a dx sdk tutorial 3...

Sziasztok,

most kezdtem el a managed dx-et, lenne 1 kérdésem...

Csináltam 1 kezdetleges kis motort, ami annyit tud, h játékobjektumokat lehet bele felvenni, és akkor azokat lerendereli.

Felvettem hozzá egy forgó 3szöget, és ugyanazt csináltam vele, mint a managed dx 3as tutorban, és sikerült is elérni a forgó 3szöget...

De valahol útközben eltûntek a vertexek színei, és így egy teljesen fekete háromszög forog, holott a CustomVertex.PositionedColored van használva, és a vertexbuffer init-ben is meg vannak adva a színek rendesen...

Nem tudja valaki, ezt mi okozhatja?

Köffi,

Uff! Ezt már csak holnap töltöm le.

erre felé

Merthogy VB.NET -es vagyok ,de még életemben nem használtam sem opengl-t , sem directX-et. Így meg még a máshonnan letöltött példaprogrikat sem tudom futtatni.
Vagy álljak át C/C++ -ra?

Tudnátok mondani egy konkrét linket a legújabb Managed Dx sdk-hoz? A microsoft dugig van letölthetõ SDK-kal , de nem tom ,hogy melyik kell. Lécci egy linket!

Ja és ha valaki bevállalja, hogy koordinál, elmondja épp mit kéne csinálnom, akkor bevállalhatok részeket is, sztem Birmacher már csak nem öl meg érte, fõleg, hogy akkor a map editorral is haladok, ami a következõ nagy lépcsõ lenne a projectünkben

C# tudásom és DX tudásom sem kiemelkedõ, viszont már viszonylag régebb óta "küzdök" Cpp-vel és OGL-lel, és C# DX kombóval is írtam már programot (ala Particle Editor). EZ kb. azt jelenti, h néha ha megakadnék lehet kérdeznék egy nálam tapasztaltabbtól -> aktív msn/mail kapcs.

Én jelenleg épp egy C#-os Particle Editor-on dolgozom, aminek a megjelenítési része már kész, ha kell, oda tudom adni. De láttam amit gymisi írt, az is nagyon jó. Az enyém most timer-rel frissíti a panle-t, amin megjeleníti a DX-es képet, mert így 50 fps-ig pontosan belõhetõ, hogy akkor milyen gyorsan is fusson. Gymisi panel-ja nálam 600 fps-t teljesített

Idézet

---

TheProGamer :
A segítségeteket szeretném kérni. Konkrétan pár vállalkozó szellemü C#-ben és MDX-ben jártasabb embert keresek egy "univerzális", könnyen bõvíthetõ mapper tool megírásához. Én irnám C++ alatt az egészhez a segédeszközöket (PRTSimulator,LightMapCalculator stb) a jelentkezõknek pedig maga a wines felület megírása lenne a feladata. Tudom hogy nem egyszerû feladat, de aki szereti a kihívásokat és érdeki a dolog az keressen meg MSN-en (címem a profilban). Ha a dolog összejön és sikerül megcsinálni a toolt akkor azt ingyenesen elérhetõvé tennénk bárki számára, dokumentációval, és betöltõ könyvtárral együtt. Tehát akit érdekel a dolog az jelentkezzen. Elõre is kösz.

---

Kiegészítés: Az ingyenesen elérhetõvé tétel az jelenti hogy magát a fordított progit (nem a source-ot), lehetne felhasználni, a dokumentáció meg pl tartalmazná hogy hogyan töltsük fel a cuccot triggerekkel, hogy néz ki a map format stb. A betöltõ könyvtár meg DX alá betöltené a cuccal készült mapot.

Egy alap komponens megfogok osztani full forráskóddal...

A segítségeteket szeretném kérni. Konkrétan pár vállalkozó szellemü C#-ben és MDX-ben jártasabb embert keresek egy "univerzális", könnyen bõvíthetõ mapper tool megírásához. Én irnám C++ alatt az egészhez a segédeszközöket (PRTSimulator,LightMapCalculator stb) a jelentkezõknek pedig maga a wines felület megírása lenne a feladata. Tudom hogy nem egyszerû feladat, de aki szereti a kihívásokat és érdeki a dolog az keressen meg MSN-en (címem a profilban). Ha a dolog összejön és sikerül megcsinálni a toolt akkor azt ingyenesen elérhetõvé tennénk bárki számára, dokumentációval, és betöltõ könyvtárral együtt. Tehát akit érdekel a dolog az jelentkezzen. Elõre is kösz.

Idézet

---

kuzanth :
Relatív hivatkozásra úgy gondolsz, mint amikor csinálsz egy linket az .exe-re? Mert ha jól tudom (és a gyakorlat ezt igazolja), a linktõl függetlenül az .exe elérési útját adja vissza a StartupPath (legalábbis megnéztem, és direkt egy tök más helyre csináltam egy linket az .exe-re, és mûködött (ott van pléldának az asztalon lévõ ikon, arról szépen megy)). Tény, hogy ilyen kimenet átirányításokat még nem csináltam, de majd megnézem azt is.

---

Van egy kis képzavar itt szerintem. Minden alkalmazásnak van egy futási környezete ami az exe-re relatív, és kisebb trükkökel átírányítható, illetve van az opr relatív környezett, ezt nem igazán lehet sem elérni sem piszkálni.

A link egy közvetlen hivatkozás az exe-re ami át állítja az aktuális dir-t az exe elérési útvonalára, tehát végrehajt egy cd d:\akarmi\.... Innentõl kezdve minden könyvtár a futás során az exe-re relatív. Egy alkalmazáson belül nem érdemes absolut elérést használni, mert egyrészt nem kényelmes más részt relatívan mindent el lehet érni.

A proj output megadása:
project/... properties/configuration properties/build/Output path

Relatív hivatkozásra úgy gondolsz, mint amikor csinálsz egy linket az .exe-re? Mert ha jól tudom (és a gyakorlat ezt igazolja), a linktõl függetlenül az .exe elérési útját adja vissza a StartupPath (legalábbis megnéztem, és direkt egy tök más helyre csináltam egy linket az .exe-re, és mûködött (ott van pléldának az asztalon lévõ ikon, arról szépen megy)). Tény, hogy ilyen kimenet átirányításokat még nem csináltam, de majd megnézem azt is.

kuzanth: A hivatkozás mehet az exe-re relatívan is ugye, de ehhez nem ilyen könyvtár szerkezet kell, hanem:

.- prog root
|
-- bin
-- media
|
-- audio
-- mesh
-- tex
-- ...
--src
|
--Ai ...
--Flight
-- ...
--...

Az egyes projoknak a kimeneteit át kell íránytani a bin könyvtárra a studioban, a debug résznél pedig a solution bin-t megadni work dirnek, onnan pedig a media könyvtár elérése már triviális visszafelé hivatkozással, sztem így jobb lenne a dolog.

ui.: képtelen vagyok fa szerkezetbe rendezni, az editorban mindig jól nézki a forumon viszont soha

Azért ha hazaértél majd nézd meg amiket mondtam

Öö valamit plz csinálj akkor vele, nekem nincs C meghajtóm

A GetCurrentDirectory már csak azért sem jó (próbáltam...), mert ha filekezelés van, vagy zenebetöltés, onnantól kezdve az lesz a CurrentDirectory, és nem az, ahonnan az .exe elindult!!!!!! Az Application.StartupPath az .exe indítási útvonalát adja vissza (ha emlékeim nem csalnak), szóval ez egy ilyen relatív viszonyítási pont.

Sajna, csak otthon tudom megnézni. Addig is feltöltöttem az eddigi progit (persze kivettem belõle mindent, ami nem kell), és betömörítettem (majdnem 8 mb). Itt a link
http://artofgaming.hu/~flight/a.zip
Remélem semmi olyat nem töröltem belõle, ami a futáshoz kell . Egy dologra kell vigyázni, hogy az elérési út a : 'C:\C# Programok\...' legyen, szóval a C meghajtó gyökerébe kell kitömöríteni. A betömörített dolog kicsit összekuszálódott , de azért sztem érthetõ. Szóval megköszönném, ha valaki meg tudná nézni (ez legalább elõre vetíti, hogy milyen is lesz a gáma). Remélem nem baj, hogy ebben nem a kommentezett .cs file van....

A két paraméterrõl annyit, h nem tudom, h ezt esetleg nem az okozza, hogy nekem 2003-as .Netem van, neked pedig nem?