Mégegyszer mondom, hogy NEM A KONSTRUKTOR FOGLALJA A MEMÓRIÁT!



Ebböl valami ilyesmi forditodik:



Mig dinamikus memoriakezeléssel:



Lesz ez:



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?

é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.

Idézet

---

Asylum :

Idézet

---

Pretender :
Nekem így működik
http://www.fredosaurus.com/notes-cpp/oop-condestructors/constructors.html

---

Már az elsö mondata baromság. A konstruktor nem foglal memóriát. És az is baromság hogy nem inicializál, mert a memberek default konstruktorai meg lesznek hivva.

---

a nem inicializálást nyilván arra értette, hogy memóriaszemét lesz benne.

Idézet

---

Pretender :
Nekem így működik
http://www.fredosaurus.com/notes-cpp/oop-condestructors/constructors.html

---

Már az elsö mondata baromság. A konstruktor nem foglal memóriát. És az is baromság hogy nem inicializál, mert a memberek default konstruktorai meg lesznek hivva.

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.

Nekem így működik
http://www.fredosaurus.com/notes-cpp/oop-condestructors/constructors.html

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.

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..

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

É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:

Ennyire futotta tőlem, sry, feladom..

É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..

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:

Bakker..

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..

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?

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...

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