|
|
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:
Kód: m_Sprite.End();
Surface sfc = m_D3DDevice.GetBackBuffer(0, 0, BackBufferType.Mono);
Rectangle spriteRec = new Rectangle(
(int)position.X, (int)position.Y,
(int)destinationSize.Width, (int)destinationSize.Height);
GraphicsStream gs = SurfaceLoader.SaveToStream(
ImageFileFormat.Png, sfc, spriteRec);
Bitmap map = (Bitmap)Image.FromStream(gs);
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.
No [img] !
Programozz ne háborúzz!!!!
|
|
|
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:
Kód: device.SetTextureStageState(0, TextureStageStates.AlphaArgument1, (int)TextureArgument.Current);
device.SetTextureStageState(0, TextureStageStates.AlphaOperation, (int)TextureOperation.SelectArg1);
É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
Kód: device.SetRenderState(RenderStates.SourceBlend, (int)Blend.SourceAlpha);
device.SetRenderState(RenderStates.DestinationBlend, (int)Blend.InvSourceAlpha);
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:
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;
}
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 Kód: device.RenderState.Lighting = false; -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:
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.
|
|
|
|
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...
Kód: device.RenderState.Ambient = System.Drawing.Color.FromArgb(255, 255, 255, 255);
device.RenderState.Lighting = false;
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.

Kompromisszumok nélkül csak remete vagy halott lehetsz...
|
|
|
|
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?
Kompromisszumok nélkül csak remete vagy halott lehetsz...
|
|
|
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!
Kompromisszumok nélkül csak remete vagy halott lehetsz...
|
|
|
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.
Reality is almost always wrong. - House
|
|
|
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.
Reality is almost always wrong. - House
|
|
|
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
_T_
|
|
|
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.
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???
|
|
|
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
_T_
|
|
|
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.
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???
|
|
|
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?
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???
|
|
|
Legújabb project:
Szókirakó 3
Legutóbb frissített project:
Szókirakó 3
Friss kép a galériából:
|