|
Mégegyszer mondom, hogy NEM A KONSTRUKTOR FOGLALJA A MEMÓRIÁT!
Kód: myclass obj;
Ebböl valami ilyesmi forditodik:
Kód: sub ESP, sizeof(myclass) ; <--- ez a memóriafoglalás
call myclass()
Mig dinamikus memoriakezeléssel:
Kód: myclass* pobj = new myclass();
Lesz ez:
Kód: try{
myclass* pobj = (myclass*)operator new(sizeof(myclass));
pobj->myclass();
// ...
}
catch{ ... };
According to gsd.
|
|
|
Asylum abba kötött bele, ha az osztály egyik tagja is osztály, akkor a default konstruktor annak a tagnak meghívja a default konstruktorát
|
|
|
"If no constructor is defined, C++ invokes a default constructor, which allocates memory for the object, but doesn't initialize it."
Ha nincs konstruktor definiálva (a fordító nem talál definiált konstruktort), akkor a C++ egy default konstruktort hív meg, amely az objektum számára lefoglalja a memóriát, de nem inicializálja.
Szerintem helyes, mert a default konstruktor alapból nem állítja 0-ra a változókat, azt nekünk kell megcsinálni. A memória lefoglalása meg akkor történik meg, ha meghívódik a konstruktor, tehát a konstruktor foglalja le a memóriát. Persze bele lehet kötni, hogy nem a konstruktor végzi el, hanem a számítógép. Vagy rosszul tudom?
Ezt a hozzászólást Bálint módosította (2011.04.20 16:04 GMT+1 óra, ---)
|
|
|
én csak a kódot néztem :$
|
|
|
Idézet Asylum :
De arra nyilván ne értse, mert nem igaz!
Például ha van egy Vector2 tipusu member aminek van default konstruktora (és az mondjuk 0-ra állitja), akkor az garantáltan meghivodik.
POJO-kra igaz lehet, de ö általánosságban beszél a konsturktorrol.
de primitív típusokra nyilván igaz.
|
|
|
De arra nyilván ne értse, mert nem igaz!
Például ha van egy Vector2 tipusu member aminek van default konstruktora (és az mondjuk 0-ra állitja), akkor az garantáltan meghivodik.
POJO-kra igaz lehet, de ö általánosságban beszél a konsturktorrol.
|
|
|
|
|
Tegnap Asylum mesterrel megoldottuk (igazából megoldotta  ) a problémát. Meg ilyen totál alap dolgokat nem kérdezek meg, pláne miután átolvastam Asy tutorialját az osztályokról, .cpp/.h-ekről.
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???
|
|
|
|
Akkor mondjad, hogy hogyan próbálkozol, mi meg segítünk
|
|
|
Irigylem a problémáitokat. Én meg küszködhetek a konstruktor írással, mert úgy nem megy, ahogy a tutorialokban.
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???
|
|
|
Látom buli volt
|
|
|
Há' montuk mi a déinputot má' mikó'.. 
Meg mijaz hogy nem fejlődött a déiksz8 óta? Mé', van új déiksz? Na, én helyben vagyok.. 
Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
|
|
|
oké, nem fejlődik. De mi a baj vele? rendesen kezeli az egeret, a billentyűzetet. Az xinputot nem ismerem, de megnézem majd azt is, mindenesetre attól, hogy nem fejlődik, még működik.
|
|
|
Talán mert a dx8 óta semmit nem fejlödik?
Át fogok térni xinputra, csak jelenleg nincs idöm még ezzel is kisérletezni.
|
|
|
hát ez aztán egy érv...
nekem tökéletesen működik, eddig bárkinek küldtem a cuccomat, ott is tökéletesen működött. Nem értem, hogy igazából mit kell szopni a szarabb megoldással, ha már egy ideje van egy egyszerűbb és jobb?
|
|
|
Idézet Asylum :
Igen, directinput kéne, de enyhén szolva lejárt lemez már. Kell hogy legyen vmi értelmes megoldás winapihoz is. Pl. ugy helyezni a kurzort a képernyö közepére hogy a WM_MOUSEMOVE-ot ne hivja meg.
|
|
|
továbbra sem válaszolt senki, hogy miért is nem jó a dinput.
|
|
|
Van, 5 perc alatt integráltam a dinputot.
Igazábol most már jobb lenne az xinput...
|
|
|
Jobb ötlet?
|
|
|
Az ugyanaz mint a dinput...söt igazábol nem tudom h mennyire lesz ez jo megoldás mert szerintem a winapis egér fix idöközönként nézi az egeret, mig a dinputnál általában framenként szokás...persze azt is meg lehet oldani fixed timestep-el csakhát...
|
|
|
Olyasmire gondolok, hogy nem foglalkozol a message queue-vel, hanem te kéred le az egér aktuális állapotát a kód megfelelő részén...
|
|
|
Az alatt mit értesz? Azt nem tudom befolyásolni, hogy mi és milyen sorrendben kerül a message queue-be..szerintem azlesz a vége h mégis dinputttal csinálom meg...lehet h nálam müködik most, de máshol már nem biztos...
|
|
|
Ha jól értelmeztem, event alapon próbálod megoldani. Ha esetleg átírnád úgy a kódot, hogy poll-szerűen működjön?
|
|
|
Idézet TomX :
SetCursorPos után rögtön föl kéne dolgozni az üzeneteket.
Szerintem az van, hogy mikor kiadom a setcursorpos-t, akkor az üzenet bufferben már vannak elötte mousemove üzik (ezért nem jo a globális változo). Söt szerintem ez az extra infós megoldás is olyan mint egy globális változo (és tényleg, mert bizonyos helyzetkben ezzel is rosszul müxik).
|
|
|
Nem tudom, igazábol már elegem van a winapibol; még a legegyszerübb dolgokhoz is hackelni kell.
|
|
|
Nem lehet, hogy a message feldolgozással nem stimmel valami?
SetCursorPos után rögtön föl kéne dolgozni az üzeneteket.
Driver szintű programban is használtam már SetSursorPos-t 2 egérrel fölváltva és gond nélkül ment.
Annyira nem hülye a winapi  Amint meghívod a SetCursorPos-t azonnal megjelenik a message, csak föl kell dolgozni.
|
|
|
miért elavult a dinput?  én azt használok, és rohadtul nincsenek ilyen problémáim (sőt, semmilyenek)  Én nem bíznám magam a winapira, és tényleg nem értem, hogy miért lenne elavult, de biztos ti tudjátok
|
|
|
Találtam egy ilyet:
http://msdn.microsoft.com/en-us/library/ms646310%28v=vs.85%29.aspx
Most probálom h mit tud, igazábol müködik csak ööö....nem egészen jo igy se...
Hát persze, ez se jó...például ha az alábbi sorrend áll fent:
elmozdul 10-hez // lastx = 10
sendinput(50) // lastx = 50
elmozdul 30-hoz
Most képzeljük el, hogy az utolso üzi (elmozdul 30hoz) a setcursorpos és a setcursorpos::mousemove között fut le (megcseréli a két üzit). És pont ez történik...hát a jó életbe...
A MOUSEEVENTF_MOVE_NOCOALESCE flag segit rajta egy picit de még mindig nem százas..
ui.: postolom a gpmhez.
thx mindenkinek a helpet
Ezt a hozzászólást Asylum módosította (2011.04.18 01:02 GMT+1 óra, ---)
|
|
|
Értem.
Akkor marad HomeGnome első megoldása. Annál elvileg nincs ilyen gond.
Annyi hogy nem framenként hívod a CursorPos-t hanem minden MOUSE_MOVE-nál, és kivéded a rekurziót.
|
|
|
Vagy talán mert nem FPS-re lett kitalálva, sztem már a Wolfenstein3D előtt is így működhetett a winapi.. 
Na még egy utolsó  tipp:
Kód: "relatív elmozdulás számítása ÉS hozzáadása dX dY változókhoz";
// render()-ben:
dX=dY=0;
SetCursorPos("középre");
Ennyire futotta tőlem, sry, feladom..
Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
|
|
|
Értem hogy mit akarsz mondani, de az a helyzet, hogy a setcursorpos és a mousemove KÖZÖTT még mozdulhat az egér (és ráadásul ezután sem garantált a sorrend), ezzel elrontva a beállitott értékeket (vagy csak simán interferál a kettö). Egyébként ezen is kiütközik, hogy a winapi mennyire egy gányolt szar.
ui.: ugylátszik ez egy megoldhatatlan probléma, mivel a rendszert mindenképp értesiteni kell az egérpozicio megváltozásárol. Azon filozom h esetleg meg lehetne-e kerülni a mousemove üzenetet..
Ezt a hozzászólást Asylum módosította (2011.04.17 22:59 GMT+1 óra, ---)
|
|
|
Először én is erre gondoltam, de mondta, hogy a frameknél hívja a SetCursorPos-t.
|
|
|
Nekem is van egy újabb agyament ötletem: 
Kód: case WM_MOUSEMOVE:
if ("x és y középen van") break;
"relatív elmozdulás számítása";
SetCursorPos("középre");
break;
Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
|
|
|
Bakker..
Kód: function OnMouseMove(x,y)
{
vx += x - last_x;
vy += y - last_y;
}
function Frame()
{
last_x = 0;
last_y = 0;
SetCursorPos(0,0)
}
|
|
|
Sajnos nem 0 a relativ elmozdulás mert a message proc elöbb fut le mint a render.
És egyébként is ha 0 akkor nem tudom forgatni pl. a kamerát. Tehát az kéne, hogy a setcursorpos-ra ne hivodjon meg a mousemove, és ezt nem tudom h hogy lehet kideriteni.
A globális bool flag nyilván nem jo, mert honnan a rákbol tudom, hogy
1) mikor dolgozodik fel az üzenet (mert az tuti h nem a hiváskor)
2) mikor állitohatom vissza
|
|
|
Akkor lehet probléma, ha ezt a SetCursorPos()-t a WM_MOUSEMOVE eseménykor hívja a windproc()-ban - így végtelen ciklus lesz.
|
|
|
Nem értitek a lényeget. A WM_MOUSEMOVE eseményben számolom ki a relativ elmozdulást.
De a SetCursorPos() szintén meghivja ezt, tehát ha elmozditom az egeret, akkor azonnal vissza is ugrik (merthogy ezt framenként hivom).
És mi a probléma?
Akkor a relatív elmozdulás 0
|
|
|
Ki akarom irtani a Dinputot, úgyhogy rákerestem. Talán a legegyszerűbb az, ha GetCursorPos()-t és SetCurtorPos()-t használ az ember.
mint itt:
prog.hu
|
|
|
Lehet megint nagy hüleséget írok  , de ha nem jön be a WM_USER üzi, akkor én egy globális bool flaggel próbálnék jelezni..
Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
|
|
|
Nem értitek a lényeget. A WM_MOUSEMOVE eseményben számolom ki a relativ elmozdulást.
De a SetCursorPos() szintén meghivja ezt, tehát ha elmozditom az egeret, akkor azonnal vissza is ugrik (merthogy ezt framenként hivom).
Igen, directinput kéne, de enyhén szolva lejárt lemez már. Kell hogy legyen vmi értelmes megoldás winapihoz is. Pl. ugy helyezni a kurzort a képernyö közepére hogy a WM_MOUSEMOVE-ot ne hivja meg.
|
|
|
De mi a probléma? Ha beállítod az előző pozíciót 0-ba akkor 0 elmozdulás lesz nem?
Ezt a hozzászólást TomX módosította (2011.04.17 16:44 GMT+1 óra, ---)
|
|
|
Max abban tudnék segíteni, hogy én hogyan számolom át abszolútból relatívba, de szerintem ez Neked is megy..  A többihez meg nincs elég skillem..
szerk.: lehet tényleg dinputtal kéne csinálnod, mintha úgy rémlene, hogy ott eleve a relatív elmozdulást kapod...
Ezt a hozzászólást HomeGnome módosította (2011.04.17 16:39 GMT+1 óra, ---)
Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
|
|
|
Mert winapit használok nem dinputot
|
|
|
direct input miért nem jó?
|
|
|
Nekem is van egy kérdésem (huhh..).
Winapis egeret használok, tehát a relativ mozgást az abszolutbol számolom (WM_MOUSEMOVE).
Viszont egy fps játékban jolenne a kurzort elrejteni + a képernyö közepére rakni mindig. De ez a k****g SetCurosrPos() meghivja a WM_MOUSEMOVE-ot is -.- Probáltam megkerülni user message-el, de ez a sz*r nem sorrendben dolgozza fel az üziket, hanem ahogy éppen gondolja...
Valaki nem tud erre egy megoldást?
|
|
|
Ha majd tényleg túl lassú lesz, akkor megnézem, hogy melyik része a legrosszabb, és azon próbálok majd javítani. Egyelőre még csak kipróbálni sem tudom, elég csupasz egyelőre az egész. De valószínűleg ez a parser cpp (a maga 727 sorával) és h lesz a legcsúnyább kódú az egész endzsinben.
|
|
|
Hashtáblával bármin lehet gyorsitani.
Stringekre meg van lexikografikus rendezés.
|
|
|
stringre keresek. Igazából realtime itt nem számít, bár lassú volt a parseolás egy kicsit, de nem ezen múlt...  (ezen a néhány tízezred(?) másodpercen). Lassú volt a szöveges fájl szavakra bontása, és azt hiszem a skin infók vertexekhez csatolása. (most kerülnek vissza szépen a dolgok, és javítom ki sorba a hibákat  )
szerk.:
az utóbbi nem is lesz gyorsabb, ha jól sejtem
Kód: for (int i = 0; i != m_SkinInfos[s]->m_VertexIndices.size(); i++)
{
int pid = m_SkinInfos[s]->m_VertexIndices[i];
for (int v = 0; v != p_Mesh->VerticesBone.size(); v++)
{
if (p_Mesh->VerticesBone[v].Position == p_Mesh->Positions[pid])
SetVertexBoneValues(p_Mesh->VerticesBone[v], frame, m_SkinInfos[s]->m_VertexWeights[i]);
}
}
Ezt a hozzászólást Pretender módosította (2011.04.17 13:09 GMT+1 óra, ---)
|
|