Valaki említette, hogy a

eljárással kettõ darab tetszõleges pont egymástól való távolságát megszerezhetem.
De most valamiért nem müxik rendesen.
Van egy ilyen függvényem:


Ha ezt a függvényt meghívom ezekkel a paraméterekkel:

akkor visszaadja a helyes távolságot, a 99-et.

A gond akkor van ha ezekkel a paraméterekkel hívom meg:


Ilyenkor 94-et kellene visszaadnia, de 0-t ad vissza. Mi miatt akadhat ki?

Amúgy nem hinném, hogylenne limit a scriptben..

Idézet

---

Orphy :
Nálam most per pill a 2 legnagyobb ilyen elméleti kérdés a dinamikus betöltés (értsd: nem hardcode), és a scriptelés...

Elõbbit úgy képzelem el, hogy van 2 "világom", ebbõl az egyiket renderelem, ezen lenne kép + progressbar, a másikba script vagy valami alapján hozzáadogatnám a tagokat, és ha megvan, akkor csere...

A Script az bonyolultabbnak tûnik:
Én úgy képzelem el, hogy a játékobjektumoknak az a függvénye, amelyik a többiekre való reagálását határozza meg hardcode helyett(?) script végrehajtás lenne, és ugyanígy esetleg a játékszabályokat betartató függvény is...
A játékobjektumaimat egyébként is névvel azonosítom, a világ objektumom így vissza tudja adni, szóval elvileg script-hez is jó így...

A fõ dilemma az, hogy tartok tõle, elég durván belassítana...

---

Szerintem ha scriptelés kell akkor ott a Lua + toLua++. Ezzel a kombóval simán tudod használni a C++ alatt megírt osztályaidat és függvényeidet Lua alatt. A motorba pedig az init részbe pakolsz egy függvényt ami betölti a Lua fájlt és végrehajtja, vagy ha folyamatosan többször kell Render elõtt végrehajtani az initben lefordítód a Lua kódot és utána a Render-ek elõtt végrehajtod. A dinamikus betöltés meg mit takar?

Igen, pont mondani akartam, hogy elég a nevét odaírni akinek a válasz szól, vagy esetleg a téma nevét pl.: gtConsoleClass probléma

Idézet

---

Csaba42 :

Idézet

---

flugi :

Idézet

---

Csaba42 :

Idézet

---

flugi :

Idézet

---

Csaba42 :
Esetleg, ha segít: a gtConsoleClass absztrakt osztály, egy .dll fájlból töltöm be. természetesen a program simán leforul, az ESC lenyomásakor végrehajtódik a gombnyomás leellenõrzése, s talán a doneTheProcess értékét is true-ra állítja a program (debug-ban nem vagyok otthon, ezt hol tudom ellenõrizni?), de a fõprogram valahogy "nem látja", hogy a változó értéke már nem false, hanem true .

Természetesen (vagy inkább függvénnyel kéne?) a doneTheProcess a fõprogramnak protected elérésû.

---

Ha a gtConsoleClass absztrakt osztály, akkor a console = new gtConsoleClass; nem fordulhat le, ugyanis absztrakt osztályt nem lehet példányosítani.

Ha az osztályodban a donetheprocess mezõ protected, akkor a fõprogramban az elágazás nem fordulhat le, amiben azt olvasni akarod.

Valami itt nagyon randa

---

Ööö, bocsi, rosszul mondtam: a fõprogram NEM a gtConsoleClass-t ismeri, hanem azt az "osztályt", mely a gtConsoleClass absztrakt osztálya (gondolom érted, mire célzok). A lényeg az én szegényes magyarázatom ellenére , hogy minden ok az absztrakt osztályok körül, a kód lefordul, stb, csak a viszonyt én mondtam rosszul (bocsi). A probléma a jó fordítás ellenére fennáll.

---

Izé, tisztázzuk a kifejezéseket:

absztrakt osztály az, aminek van olyan metódusa, ami egyáltalán nincs megvalósítva. Az ilyen osztály csak arra jó, hogy öröklõdjenek belõle.

Te valószínûleg õsosztályra gondolsz, a gtConsoleClass õsére.

De a helyzet így sem tiszta, ha így értem, amit mondasz még mindig nem fordulhat le (a fõprogram nem tudhat az õsosztály óta bevezetett új mezõkrõl, amik még mindig protected-ek!)

Tedd fel a kódot valahová, és adj linket, könnyebb lesz úgy megmondani.

---

Semmi gond, már megoldódott a probléma . Áttettem private-be, írtam hozzá egy lekérdezõ függvényt is (érdekes, tegnap még nem volt hajlandó így menni , ráadásul nem is egyszer csináltam meg ezt), és rögtön kilépett.

---

Egy még belefér

Na hány idézetet vagytok képesek megjeleníteni?

Idézet

---

flugi :

Idézet

---

Csaba42 :

Idézet

---

flugi :

Idézet

---

Csaba42 :
Esetleg, ha segít: a gtConsoleClass absztrakt osztály, egy .dll fájlból töltöm be. természetesen a program simán leforul, az ESC lenyomásakor végrehajtódik a gombnyomás leellenõrzése, s talán a doneTheProcess értékét is true-ra állítja a program (debug-ban nem vagyok otthon, ezt hol tudom ellenõrizni?), de a fõprogram valahogy "nem látja", hogy a változó értéke már nem false, hanem true .

Természetesen (vagy inkább függvénnyel kéne?) a doneTheProcess a fõprogramnak protected elérésû.

---

Ha a gtConsoleClass absztrakt osztály, akkor a console = new gtConsoleClass; nem fordulhat le, ugyanis absztrakt osztályt nem lehet példányosítani.

Ha az osztályodban a donetheprocess mezõ protected, akkor a fõprogramban az elágazás nem fordulhat le, amiben azt olvasni akarod.

Valami itt nagyon randa

---

Ööö, bocsi, rosszul mondtam: a fõprogram NEM a gtConsoleClass-t ismeri, hanem azt az "osztályt", mely a gtConsoleClass absztrakt osztálya (gondolom érted, mire célzok). A lényeg az én szegényes magyarázatom ellenére , hogy minden ok az absztrakt osztályok körül, a kód lefordul, stb, csak a viszonyt én mondtam rosszul (bocsi). A probléma a jó fordítás ellenére fennáll.

---

Izé, tisztázzuk a kifejezéseket:

absztrakt osztály az, aminek van olyan metódusa, ami egyáltalán nincs megvalósítva. Az ilyen osztály csak arra jó, hogy öröklõdjenek belõle.

Te valószínûleg õsosztályra gondolsz, a gtConsoleClass õsére.

De a helyzet így sem tiszta, ha így értem, amit mondasz még mindig nem fordulhat le (a fõprogram nem tudhat az õsosztály óta bevezetett új mezõkrõl, amik még mindig protected-ek!)

Tedd fel a kódot valahová, és adj linket, könnyebb lesz úgy megmondani.

---

Semmi gond, már megoldódott a probléma . Áttettem private-be, írtam hozzá egy lekérdezõ függvényt is (érdekes, tegnap még nem volt hajlandó így menni , ráadásul nem is egyszer csináltam meg ezt), és rögtön kilépett.

Nálam most per pill a 2 legnagyobb ilyen elméleti kérdés a dinamikus betöltés (értsd: nem hardcode), és a scriptelés...

Elõbbit úgy képzelem el, hogy van 2 "világom", ebbõl az egyiket renderelem, ezen lenne kép + progressbar, a másikba script vagy valami alapján hozzáadogatnám a tagokat, és ha megvan, akkor csere...

A Script az bonyolultabbnak tûnik:
Én úgy képzelem el, hogy a játékobjektumoknak az a függvénye, amelyik a többiekre való reagálását határozza meg hardcode helyett(?) script végrehajtás lenne, és ugyanígy esetleg a játékszabályokat betartató függvény is...
A játékobjektumaimat egyébként is névvel azonosítom, a világ objektumom így vissza tudja adni, szóval elvileg script-hez is jó így...

A fõ dilemma az, hogy tartok tõle, elég durván belassítana...

Idézet

---

TheProGamer :
U.I: Az egész hsz az én privát véleményem amivel tuti hogy a többség nem fog egyetérteni. Lehet azt mondani hogy ilyen téren nem a földön járok, lehet hogy igaz is.

---

Lelkes fiatal koromban én is így álltam hozzá! Mindent én akartam megírni, csináltam saját ablakozós rendszert DOS alá, stb. Ma már kicsit másképp gondolom

Idézet

---

Csaba42 :

Idézet

---

flugi :

Idézet

---

Csaba42 :
Esetleg, ha segít: a gtConsoleClass absztrakt osztály, egy .dll fájlból töltöm be. természetesen a program simán leforul, az ESC lenyomásakor végrehajtódik a gombnyomás leellenõrzése, s talán a doneTheProcess értékét is true-ra állítja a program (debug-ban nem vagyok otthon, ezt hol tudom ellenõrizni?), de a fõprogram valahogy "nem látja", hogy a változó értéke már nem false, hanem true .

Természetesen (vagy inkább függvénnyel kéne?) a doneTheProcess a fõprogramnak protected elérésû.

---

Ha a gtConsoleClass absztrakt osztály, akkor a console = new gtConsoleClass; nem fordulhat le, ugyanis absztrakt osztályt nem lehet példányosítani.

Ha az osztályodban a donetheprocess mezõ protected, akkor a fõprogramban az elágazás nem fordulhat le, amiben azt olvasni akarod.

Valami itt nagyon randa

---

Ööö, bocsi, rosszul mondtam: a fõprogram NEM a gtConsoleClass-t ismeri, hanem azt az "osztályt", mely a gtConsoleClass absztrakt osztálya (gondolom érted, mire célzok). A lényeg az én szegényes magyarázatom ellenére , hogy minden ok az absztrakt osztályok körül, a kód lefordul, stb, csak a viszonyt én mondtam rosszul (bocsi). A probléma a jó fordítás ellenére fennáll.

---

Izé, tisztázzuk a kifejezéseket:

absztrakt osztály az, aminek van olyan metódusa, ami egyáltalán nincs megvalósítva. Az ilyen osztály csak arra jó, hogy öröklõdjenek belõle.

Te valószínûleg õsosztályra gondolsz, a gtConsoleClass õsére.

De a helyzet így sem tiszta, ha így értem, amit mondasz még mindig nem fordulhat le (a fõprogram nem tudhat az õsosztály óta bevezetett új mezõkrõl, amik még mindig protected-ek!)

Tedd fel a kódot valahová, és adj linket, könnyebb lesz úgy megmondani.

Idézet

---

Orphy :
Háát, a pascal-t, azt személy szerint én sem...

Apropó, TPG, hozzád hasonlóan én is elkezdtem egy saját motor fejlesztését, fõleg tapasztalatszerzés és tudásgyarapítás céljából.
Az alapvetõ dolgokkal még elleszek egy darabig, viszont utána jó lenne valami útmutatásszerû, hogy hogyan tovább... Húú, de hülyén fogalmaztam... Szóval ilyen "hogyan szokták ezt meg ezt csinálni a tapasztaltak" típusú dologra gondolok
Továbbá múltkor a grafikus topicban hallottam elõször a normalMapping-rõl, meg hogy az milyen jó dolog, szóval ha eljutok odáig tervbe lesz az is...
A másik kérdés pont innen jön: Van valahol egy ilyen lista pl, hogy mit érdemes egy motornak támogatnia? Ahonnét pl rájöhetnék, hogy nem csak a normal mapping-rõl nem tudtam, hanem 5 másikról sem

Hülye kérdések hülyén megfogalmazva, de remélem érted

---

Ha valami igazán ütõset akarsz csinálni akkor a shadertámogatás alap. Ha egyszer már ez megvan onnan csak a képzelet és a célhardver szab határt annak hogy milyen durva effekteket hozol össze. Az egész dolog attól függ hogy milyen motort akarsz csinálni.
Ha egy egyszerû 3D-s motort ami fut mindenhol és nem kell sok munka hozzá akkor elég a Fixed Function pipeline-al foglalkozni, de ilyen esetben is azért dot3 bump map és environment mapping azért nem árt meg esetleg egy shadow volume-os árnyék modul is dobni tud a hangulaton.
Ha egy kicsit komplikáltabbat akarsz csinálni akkor alap shadertámogatás már kell, D3D-vel pillanatok alatt meg lehet csinálni. SM1.1-es effektekkel már igen jól grafikát lehet összedobni, és nem is bonyolult. Shadow mapping, per-pixel lighting, water effect stb.
Ha viszont valami nagyon ütõset akkor SM2.0/SM3.0-s effectek kellenek. Soft shadows, normal mapping, parallax/relief mapping, HDR (ettõl nem kell megijedni, egész könnyen meg lehet csinálni), clipping plane-es reflection+refraction normal mapping-el megtámogatva, esetleg még PRT/LDPRT. Ehhez hozzáfûzném hogy ilyen motort nem érdemes úgy írni hogy elõtte abszolút nem foglalkoztál még a témával.
Ezeken kívül az összesnek kell támogatnia az animált modelleket, valamilyen népszerû 3D-s modellformátumot, zenelejátsztást, egyszerû 3D-s hangzást (DirectSound-al viszonylag könnyen meg lehet oldani), DirectInput-os irányítás, skálázhatóság, valamilyen szintü fizika, pálya betöltés, egyszerû GUI, esetleg még AI (konzol és társai annyira alap dolgok hogy meg sem említem õket, ezek nélkül bonyolultabb motornál nem nagyon lehet dolgozni). Remélem nem hagytam ki semmit. A fizikára visszatérve szerintem nem érdemes azt sajátkezüleg megírni, vannak jó könyvtárak hozzá ingyen a neten. Ha teljesen ingyeneset akarsz akkor ott az ODE ha pedig nagyon profi cuccot akkor ott az AGEIA Physx.

U.I: Az egész hsz az én privát véleményem amivel tuti hogy a többség nem fog egyetérteni. Lehet azt mondani hogy ilyen téren nem a földön járok, lehet hogy igaz is.

Ja, igen, ha így csinálod, figyelj oda, hogy a tankra alkalmazott transzformációk érvényesek legyenek a befoglaló testekre is, különben furcsa eredményeket fogsz látni játék közben

Idézet

---

gaborlabor :
Aha, szóval te is igy fogod megoldani.
Ezekrõl olvastam énis, és most is ezt használom, de egyenlõre nem teljesen így csak az alapja ez.
De valahol ugy csinálják hogy elõször a befoglaló testre végzik el az ütközésvizsgálatot utána pedig poliéderenként. De az csak olyan objektumoknál érdemes amit nehéz befoglaló testbe rakni ugy hogy pontos legyen az ütközésdetektálás.
Akkor ha pl van egy tank, akkor annál úgy érdemes megcsinálni, hogy a jármûhöz egy befoglaló téglatestet használok, és a kiálló csõhöz meg egy másikat?

---

Ha meg tudod csinálni úgy, akkor érdemes...
Én egyelõre még nem tartok ott, egyelõre a "világot" csinálom

Egyébként a játékban, amit miniGame-re csináltam (bár az 2d volt), úgy vizsgáltam, hogy megnéztem, koordináták alapján ütközhet-e egyáltalán a 2 objektum, és csak utána néztem a többit... Aztán pont itt véreztem el, mert elsõ körben úgy gondoltam, ha ütközés esetén kiszámítom a közös területet, és azon belül nézem pixel-re pontosan, h ütköznek-e, akkor sebességre ki lehet majd bírni... Tévedtem Úgyhogy újra kellett írni befoglaló körrel, meg téglalappal, és kifutottam az idõbõl...

Idézet

---

flugi :

Idézet

---

Csaba42 :
Esetleg, ha segít: a gtConsoleClass absztrakt osztály, egy .dll fájlból töltöm be. természetesen a program simán leforul, az ESC lenyomásakor végrehajtódik a gombnyomás leellenõrzése, s talán a doneTheProcess értékét is true-ra állítja a program (debug-ban nem vagyok otthon, ezt hol tudom ellenõrizni?), de a fõprogram valahogy "nem látja", hogy a változó értéke már nem false, hanem true .

Természetesen (vagy inkább függvénnyel kéne?) a doneTheProcess a fõprogramnak protected elérésû.

---

Ha a gtConsoleClass absztrakt osztály, akkor a console = new gtConsoleClass; nem fordulhat le, ugyanis absztrakt osztályt nem lehet példányosítani.

Ha az osztályodban a donetheprocess mezõ protected, akkor a fõprogramban az elágazás nem fordulhat le, amiben azt olvasni akarod.

Valami itt nagyon randa

---

Ööö, bocsi, rosszul mondtam: a fõprogram NEM a gtConsoleClass-t ismeri, hanem azt az "osztályt", mely a gtConsoleClass absztrakt osztálya (gondolom érted, mire célzok). A lényeg az én szegényes magyarázatom ellenére , hogy minden ok az absztrakt osztályok körül, a kód lefordul, stb, csak a viszonyt én mondtam rosszul (bocsi). A probléma a jó fordítás ellenére fennáll.

Idézet

---

gaborlabor :
Aha, szóval te is igy fogod megoldani.
Ezekrõl olvastam énis, és most is ezt használom, de egyenlõre nem teljesen így csak az alapja ez.
De valahol ugy csinálják hogy elõször a befoglaló testre végzik el az ütközésvizsgálatot utána pedig poliéderenként. De az csak olyan objektumoknál érdemes amit nehéz befoglaló testbe rakni ugy hogy pontos legyen az ütközésdetektálás.
Akkor ha pl van egy tank, akkor annál úgy érdemes megcsinálni, hogy a jármûhöz egy befoglaló téglatestet használok, és a kiálló csõhöz meg egy másikat?

---

Ilyenkor nagyon jó az OOP, és egy virtuális befoglalótest visszaadó függvény, ami tudja, hogy a csõ éppen merre áll, stb.

Idézet

---

Orphy :
c64 BASIC->c64 Assembly -> Turbo Pascal -> Visual Basic -> Java -> C#, C++

---

C64 Basic - Turbo Pascal - Modula 2 (ELTE) - Qt/C++ - ANSI C++

Aha, szóval te is igy fogod megoldani.
Ezekrõl olvastam énis, és most is ezt használom, de egyenlõre nem teljesen így csak az alapja ez.
De valahol ugy csinálják hogy elõször a befoglaló testre végzik el az ütközésvizsgálatot utána pedig poliéderenként. De az csak olyan objektumoknál érdemes amit nehéz befoglaló testbe rakni ugy hogy pontos legyen az ütközésdetektálás.
Akkor ha pl van egy tank, akkor annál úgy érdemes megcsinálni, hogy a jármûhöz egy befoglaló téglatestet használok, és a kiálló csõhöz meg egy másikat?

Ja, és elvileg lehetséges sztem az is, hogy bonyolultabb testeket részekre bontasz, és a különbözõ részeket különbözõ befoglaló geometriával közelíted, pl embernél a fejet gömb-bel, a többit téglatestekkel, és akkor külön testrészekre is lehet ütközést vizsgálni...

HEADSHOT!!!

Na, ez az, amit még nem csináltam

Idézet

---

Csaba42 :
Esetleg, ha segít: a gtConsoleClass absztrakt osztály, egy .dll fájlból töltöm be. természetesen a program simán leforul, az ESC lenyomásakor végrehajtódik a gombnyomás leellenõrzése, s talán a doneTheProcess értékét is true-ra állítja a program (debug-ban nem vagyok otthon, ezt hol tudom ellenõrizni?), de a fõprogram valahogy "nem látja", hogy a változó értéke már nem false, hanem true .

Természetesen (vagy inkább függvénnyel kéne?) a doneTheProcess a fõprogramnak protected elérésû.

---

Ha a gtConsoleClass absztrakt osztály, akkor a console = new gtConsoleClass; nem fordulhat le, ugyanis absztrakt osztályt nem lehet példányosítani.

Ha az osztályodban a donetheprocess mezõ protected, akkor a fõprogramban az elágazás nem fordulhat le, amiben azt olvasni akarod.

Valami itt nagyon randa

Hát, elméletileg több lehetõség is van.

3d-ben gondolkodva:

- megnézheted vertexenként, hogy van-e ütközés: 100% pontos, de iszonyat lassú

- befoglaló geometriát használsz:
Pl a 3d-s testeid köré kiszámítod a befoglaló gömböt, és onnantól az ütközést visszavezeted gömb-gömb ütközésre. Ez azért jó, mert csak a sugarakat tartod nyilván, és ha a 2 sugár összege <= a testek középpontjainak távolságánál, akkor ütközés van.

- többféle befoglaló geometriát használsz, a gömbön kívül téglatest, kocka, stb, amivel jobban körül lehet írni úgy, hogy a lehetõ legjobban lefedje a testedet. Itt már több esetre is számolni kell az ütközést (téglatest-gömb, kocka-gömb, téglatest-kocka), így bonyolódik a dolog.

Általában ezeknél bonyolultabbakat nem szoktak használni, ha jól tudom.

Úgy tûnik mostanában ez a divat, mindenki motort ír ami persze nem baj, sõt nagyon jó.
Én nem vagyok olyan szinten hogy érdemes legyen nekiállnom, csak egy 3D-s progin munkálkodok.
Orphy ha megoldottad az ütközésdetektálást és kezelést, akkor szólhatnál, és elmondhatnád az elméleti alapjait. Én már megcsináltam a padlóval és a pálya széleivel, de más objektumokkalmég nem próbáltam, és érdekel mindenféle lehetséges megoldás. Köszi.

Idézet

---

TheProGamer :

Idézet

---

Orphy :
c64 BASIC->c64 Assembly -> Turbo Pascal -> Visual Basic -> Java -> C#, C++

---

C -> C++ Ezenkívül még tudok egy kicsit C#-ozni, PHP-zni meg Pascal-ozni bár a Pascal-t kifejezetten nem szeretem.

---

Háát, a pascal-t, azt személy szerint én sem...

Apropó, TPG, hozzád hasonlóan én is elkezdtem egy saját motor fejlesztését, fõleg tapasztalatszerzés és tudásgyarapítás céljából.
Az alapvetõ dolgokkal még elleszek egy darabig, viszont utána jó lenne valami útmutatásszerû, hogy hogyan tovább... Húú, de hülyén fogalmaztam... Szóval ilyen "hogyan szokták ezt meg ezt csinálni a tapasztaltak" típusú dologra gondolok
Továbbá múltkor a grafikus topicban hallottam elõször a normalMapping-rõl, meg hogy az milyen jó dolog, szóval ha eljutok odáig tervbe lesz az is...
A másik kérdés pont innen jön: Van valahol egy ilyen lista pl, hogy mit érdemes egy motornak támogatnia? Ahonnét pl rájöhetnék, hogy nem csak a normal mapping-rõl nem tudtam, hanem 5 másikról sem

Hülye kérdések hülyén megfogalmazva, de remélem érted

ok, ezt nem tudtam...

Ez így, ha jól értelmezem, nem lenne megfelelõ, mivel a gtConsoleClass befejezését a fõprogramban figyelem a

feltétellel, és a

pedig magában a gtConsoleClass osztályban van! Az az igazi gondom, hogy a fõprogram láthatóan nem tudja lekérdezni a doneTheProcess értékét, ennek következtében nem tud kilépni a program az ESC lenyomása után, pedig erre nagy szükségem lenne .

Nem tudom, hogy jóra gondolok-e, de én biztos, hogy így csinálnám:

Idézet

---

Orphy :
c64 BASIC->c64 Assembly -> Turbo Pascal -> Visual Basic -> Java -> C#, C++

---

C -> C++ Ezenkívül még tudok egy kicsit C#-ozni, PHP-zni meg Pascal-ozni bár a Pascal-t kifejezetten nem szeretem.

Esetleg, ha segít: a gtConsoleClass absztrakt osztály, egy .dll fájlból töltöm be. természetesen a program simán leforul, az ESC lenyomásakor végrehajtódik a gombnyomás leellenõrzése, s talán a doneTheProcess értékét is true-ra állítja a program (debug-ban nem vagyok otthon, ezt hol tudom ellenõrizni?), de a fõprogram valahogy "nem látja", hogy a változó értéke már nem false, hanem true .

Természetesen (vagy inkább függvénnyel kéne?) a doneTheProcess a fõprogramnak protected elérésû.

Emberek, kéne egy kis segítség! Nem értek annyira az OOP-hez, de valamennyi rálátásom van a témára. Ha a fõprogram "ismeri" a gtConsoleClass osztályom

és a gtConsoleClass konstruktorában értéket adok a doneTheProcess változómnak

valamint az ESC billentyû leütésekor meghívódik az a függvény, melyben ez a kódrészlet szerepel:

akkor ez az ellenõrzés miért nem fut le a fõprogramban:

Ötlete van valakinek?

A tiéd hosszabb, mint az enyém, Orphy

Idézet

---

BerbeckU :

Idézet

---

Csaba42 :
Én vagyok rá az élõ példa: QBasic->Pascal->C(->C++ ). Ahogy haladtam elõre a programnyelvek megtanulásával, úgy volt egyre könnyebb a dolgom, hisz az alapokat elsajátítottam Basicban, majd kissé keményebb nyelv következett (Pascal). Miután azzal is jól boldogultam (értsd: játékokat írtam ), jött a C, ami már tényleg nem okozott túlzott nehézségeket, végül a C-bõl C++ lett.

---

QBasic -> PHP+MySQL-> C++.

---

c64 BASIC->c64 Assembly -> Turbo Pascal -> Visual Basic -> Java -> C#, C++

De a színek nincsenek

Nah, megvan a gond

Grrrr, tegnap még minden rendben volt, most meg, hogy nuku változtatás mellett újrafordítottam a kódot, semmi sem jön be a programomban, csak egy fekete képernyõ Grrrrrrrrrrrrrrrrrr!!!

Idézet

---

Csaba42 :
Én vagyok rá az élõ példa: QBasic->Pascal->C(->C++ ). Ahogy haladtam elõre a programnyelvek megtanulásával, úgy volt egyre könnyebb a dolgom, hisz az alapokat elsajátítottam Basicban, majd kissé keményebb nyelv következett (Pascal). Miután azzal is jól boldogultam (értsd: játékokat írtam ), jött a C, ami már tényleg nem okozott túlzott nehézségeket, végül a C-bõl C++ lett.

---

QBasic -> PHP+MySQL-> C++.

Hiába emlegeted a DDrawot lépcsõfokként, elavult. Programoztam benne elég sokat (DX7) c++ és vbasic-ben is. Hidd el nem könnyebb megtanulni, mint a sprite-os d3d-t, sõt. DDrawban még egy nyamvadt bmp betöltõ függvény sincs, ellenben d3d-ben jpg, bmp meg még jó pár formátumot egy fv-nyel be tudsz tölteni. Szóval inkább a sprite-os d3d felé indulj el, mint a rég elavult ddraw féle. Tudom, "dolgoztam" mind2vel...

PYTHON->PHP+mySQL->C/C++

Pont erre gondoltam, amit Csaba42 irt, valahogy nálam is igy volt, bár nálam valamivel rövidebb a sor:
Pascal -> C, C++

Idézet

---

gaborlabor :
Azért a kukába nem mindig repül
Mondok egy példát most konkrétan nem a grafikai programozásra hanem általánosságban. Valaki elhatározza, hogy programozni akar, és pascallal kezdi, nem c-vel, az lehet hogy a pascal után hamarabb megtanulja a c-t, mintha azzal kezdett volna, mert miközben a pascalt tanulta megtanult olyan alapvetõ programozási dolgokat, elméleteket, eljárásokat, amiket ugyanúgy hasznosíthat a c nyelv megtanulása során is.[...]

---

Én vagyok rá az élõ példa: QBasic->Pascal->C(->C++ ). Ahogy haladtam elõre a programnyelvek megtanulásával, úgy volt egyre könnyebb a dolgom, hisz az alapokat elsajátítottam Basicban, majd kissé keményebb nyelv következett (Pascal). Miután azzal is jól boldogultam (értsd: játékokat írtam ), jött a C, ami már tényleg nem okozott túlzott nehézségeket, végül a C-bõl C++ lett.

Idézet

---

TheProGamer :
[...] Feltételezem hogy aki DDraw-val vagy bármi ilyesmivel foglalkozni akar az már keni-vágja a programnyelvet amit ehhez használni akar magasabb szinten ismeri a Windows vagy egyéb event-driven rendszerek mûködését. [...]

---

Én sajnos még nem ismerem eléggé a Windows programozásának minden csínját-bínját, néha meglepõdöm egy-egy forráskód áttanulmányozása közben, de így is eléggé elboldogulok. Igaz, most már kéne valami jó kis Windows programozásával foglalkozó könyv, persze magyarul, és kézbe vehetõ legyen . Bocsi, ha esetleg rosszul értelmeztem a fenti mondatod, de nekem az jött le belõle, hogy aki DX/OGL-lel akar foglalkozni, elõbb merüljön bele a Windows programozásába.

Másrészt abban igazat adok, hogy elég egy könyvtárt ismerni, de azt alaposan. Én is erre szeretném magam sarkallni. Igaz, hogy a DirectX mellett néha foglalkozok OpenGL-lel is, de ez nem jelent hátrányt, hisz ha egyszer majd át kell térnem (pl.: munkahely miatt), akkor nem kell minden alap dolgot bevasalnom, hisz lesz rálátásom már az alapjaira. Egyébként a DirectX 10 alapjaiban változott, így valószínûsíthetõ (illetve akik már tudják, azoknak biztosan), hogy bizonyos tekintetekben máshogy kell eljárni a programunk írása során. Én spec. csak egy képet találtam a Dx10 mûködésérõl, és ahogy elnéztem, nincs vége még a tanulásnak . Csak nehogy bonyolultabb legyen az új könyvtár mûködése, mert akkor én is átérek az OpenGLre .

Idézet

---

TheProGamer :
[...] Viszont egy témakörön belül egy könyvtárra specializálódok (Pl.: Graf: D3D; fizika: Ageia Physx stb.), [...]

---

Nah, a fizika és az MI az, amit még sosem csináltam, illeteve az elõbbi max. annyiból állt, hogy egy labda pattogott egy ablakban (persze DDrawban írtam). Sajnos kevés, számomra használható tutor-t találtam, amiknek a többsége csak és kizárólag elméleti síkon vázolta a lehetõségeket. Az utóbbi pedig számomra kissé érthetetlen nyelvezetû, pedig vannak jó magyar könyvek a témáról, valamint érdekes angol weboldalak (Pl.).

Nah, de még korán reggel van, az elõbb ébredtem fel, így ha zagyvaságokat írtam, elõre is elnézést kérek... :ban

Azért a kukába nem mindig repül
Mondok egy példát most konkrétan nem a grafikai programozásra hanem általánosságban. Valaki elhatározza, hogy programozni akar, és pascallal kezdi, nem c-vel, az lehet hogy a pascal után hamarabb megtanulja a c-t, mintha azzal kezdett volna, mert miközben a pascalt tanulta megtanult olyan alapvetõ programozási dolgokat, elméleteket, eljárásokat, amiket ugyanúgy hasznosíthat a c nyelv megtanulása során is. Ugyhogy azért nem feltétlenül megy a kukába, valamennyit profitálsz belõle még ha nem is veszed észre. Ha a ddrawot meg tudja tanulni hamar, akkor miért ne kezdené azzal? Utána ha átáll a d3d-re akkor annyival is könnyebb lesz, hogy valamicskét ért a 2d-s grafikai programozáshoz.
Neki kell eldöntenie hogy megéri-e átugrani egy "elavult" lépcsõfokot, amivel azért ha nem is sokat de fejlõdhetne.

Idézet

---

flugi :
Nem jogos amit mondasz, a DirectX nem az ultimate eszköz, az is fog egy csomót változni. Komoly hiba azt hinni, hogy egy könyvtárat elég megtanulni, minden egyéb felesleges. A D3D pár év múlva ugyanúgy elavult lesz, mint most a DD, akkor vajon mihez kezdesz azzal, amit a D3D alatt megtanultál? Megmondom: láttál egy összerakott rendszert, és megtanultál eligazodni benne. Mármost minél több ilyen rendszert ismer valaki, annál jobb, nincs felesleges tudás.

Egy kezdõ kezdhet DD-vel, bár én inkább az OpenGL-t vagy az SDL-t ajánlanám, azok nem windows specifikusak. Pontosabban ezeket IS ajánlanám, meg minél többet

Nehogymár bármelyiktek azzal foglalkozik, hogy bebiflázza a függvényneveket Doksit kell tudni olvasni, és kódot megérteni.

---

Ebben is van valami de én az egész témakört nem innen közelítem meg. Feltételezem hogy aki DDraw-val vagy bármi ilyesmivel foglalkozni akar az már keni-vágja a programnyelvet amit ehhez használni akar magasabb szinten ismeri a Windows vagy egyéb event-driven rendszerek mûködését. Ha ez nincs meg akkor nem érdemes DX/OGL-el foglalkozni mert sok szenvedés árán lehet ugyanazt így elérni amit fokozatos léptekkel is elérne. Viszont ha megvan akkor milyen hasznos plusz tudást tud nyujtani egy elavult eszköz ismerete? A használatával max programozói tapasztalatot lehet szerezni de azt ugyanúgy megszerzi ha egy friss eszközt használ. Ezen elvek alapján miért kezdjen az ember DDraw-val foglalkozni amikor ott a D3D ami jelenleg az aktuális könyvtár 2D/3D grafhoz Windows alatt, jobb hozzá a támogatás, a driverek is hozzá vannak kitalálva. És a DDraw nem ad semmi olyan nélkülözhetetlen dolgot ami miatt érdemes lenne vele még mindig foglalkozni, fõleg úgy hogy azt a lépcsõfokot amit képviselt volna a tanulási folyamat során a D3D is tartalmazza. Nálam sem úgy mûködik hogy bevágtam a D3D-t és minden más le van tojva viszont nálam alapkövetelmény bármilyen eszközzel kapcsolatban az hogy aktuális, friss és támogatott legyen, ha ezek a feltételek nem teljesülnek akkor nem foglalkozom az adott dologgal. Viszont egy témakörön belül egy könyvtárra specializálódok (Pl.: Graf: D3D; fizika: Ageia Physx stb.), mert minek kettõt ismerni ha attól nekem úgysem lesz jobb. Inkább ismerek egyet az adott témakörben viszont azt alaposan. És ha az elavul akkor repül a kukában és jöhet az aktuális friss verzió megismerése.

Idézet

---

BerbeckU :
Itt a fórumon mondták, hogy kezdjem directDraw-val mert hogy kezdésnek az kell...
Meg az a baj, hogy még nem tudom, hogy OGL vagy DX... Hiába olvastam el a topicot is attól nem lettem okosabb, csak még jobban elbizonytalanodtam

---

Én a következõt javaslom: próbáld ki mindegyiket! (OpenGL, DirectX, SDL ) Tölts le példaprogramokat, és próbáld meg lefordítani és futtatni õket, kicsit átírogatni. Ezzel egyrészt megtanulsz linkelni és fordítani (nem könnyû) másrészt kiderül, hogy mi az, ami a környezeteddel együt tud jól mûködni.

De legfõképpen így már nem a mi véleményünkre kell hagyatkoznod, ha a hozzád legközelebb álló könyvtárat keresed.

És ha rám hallgatsz, elõször konzolos programokat írj, alapdolgokat sokkal könnyebb követni konzolon.

Idézet

---

TheProGamer :
Szerintem meg felesleges a DDraw-val próbálkozni, már nagyon régen elavult. Ott a D3D ID3DXSprite osztálya amivel továbbra is lehet 2D-s cumókat csinálni D3D alatt. Használatához nem kell igazán az egész D3D-t bevágni, elég hogyha az ember tud csinálni egy Device-t aminek pár funkcióját használni is tudja. És késõbb még jól jön a D3D használatánál az a tudás amit itt felszed az ember, ugyanezt a DDraw-ról nem tudnám elmondani.

---

Nem jogos amit mondasz, a DirectX nem az ultimate eszköz, az is fog egy csomót változni. Komoly hiba azt hinni, hogy egy könyvtárat elég megtanulni, minden egyéb felesleges. A D3D pár év múlva ugyanúgy elavult lesz, mint most a DD, akkor vajon mihez kezdesz azzal, amit a D3D alatt megtanultál? Megmondom: láttál egy összerakott rendszert, és megtanultál eligazodni benne. Mármost minél több ilyen rendszert ismer valaki, annál jobb, nincs felesleges tudás.

Egy kezdõ kezdhet DD-vel, bár én inkább az OpenGL-t vagy az SDL-t ajánlanám, azok nem windows specifikusak. Pontosabban ezeket IS ajánlanám, meg minél többet

Nehogymár bármelyiktek azzal foglalkozik, hogy bebiflázza a függvényneveket Doksit kell tudni olvasni, és kódot megérteni.

Hell,

próbálkozott itt valaki 64bit-re fordítással?

A következõ érdekes szitu történt: projekt-et átállítottam 64bit-re, a lib könyvtárat is természetesen a 64bit-es directX lib könyvtárra, fordításnál pedig sír, hogy nincsen neki d3d9.h...

32 biten fordul és mûxik...

Ez mi lehet?

Szerintem meg felesleges a DDraw-val próbálkozni, már nagyon régen elavult. Ott a D3D ID3DXSprite osztálya amivel továbbra is lehet 2D-s cumókat csinálni D3D alatt. Használatához nem kell igazán az egész D3D-t bevágni, elég hogyha az ember tud csinálni egy Device-t aminek pár funkcióját használni is tudja. És késõbb még jól jön a D3D használatánál az a tudás amit itt felszed az ember, ugyanezt a DDraw-ról nem tudnám elmondani.

Osztom BerbeckU véleményét, a DDraw tanulása közben rengeteg olyan tapasztalatot szerez az ember, amit simán átültethet akár más platformba is. Én kimondottan sajnálom a DDraw eltûnését.

Azért szerintem nem elpazarolt idõ, mert kétségkívül, ha programot írok, akkor annak a dd csak egy része, a másik részében meg gyakorlom a nyelvet. Ez az optimista felfogás!

DirectDrawot énis javasoltam. Akkor viszont pontosítanom kell.
Ha ugy tervezted hogy kezdésnek hamar akarsz irni egyszerû játékot akkor még mindig a ddraw a jó választás. Ha azt veszed alapul, hogy a tudás nem vész kárba, és az a pár hét amég elég jól megtanulod a ddrawot nem számít kidobott idõnek akkor dönthetsz ddraw mellett, kezdésnek.
Viszont dönthetsz úgyis hogy valamennyivel (nem tudom mennyivel, nem tanultam directxet) több idõt szánsz a d3d-re, akkor nem "pazaroltad" az idõdet olyasvalaminek a megtanulására ami késõbb kárba vész mert nem fogod sokáig használni.
Tehát mérlegelni kell, hogy mi éri meg jobban. Az alapján hogy mennyi ideig szándékozol egyszerûbb játékokat irni már eldöntheted hogy megéri-e rászánni azt a pár hetet a ddraw megtanulására, amit egyébként a d3d-re is fordíthatnál.

Már összefolynak elõttem a betûk, túlcsordulási hiba...

Itt a fórumon mondták, hogy kezdjem directDraw-val mert hogy kezdésnek az kell...
Meg az a baj, hogy még nem tudom, hogy OGL vagy DX... Hiába olvastam el a topicot is attól nem lettem okosabb, csak még jobban elbizonytalanodtam

p.s.: MSN-en felvettelek.