játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5504
FZoli:    4894
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2528

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [85] [90] [95] [100] [105] [110] [115] > 120 < [125] [130] [135] [140] [143]
Csaba42 - Törzstag | 946 hsz       Online status #24301   2006.08.06 10:16 GMT+1 óra  
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.

   
Orphy - Törzstag | 1893 hsz       Online status #24300   2006.08.06 10:16 GMT+1 óra  
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...
   
flugi - Tag | 111 hsz       Online status #24298   2006.08.06 09:48 GMT+1 óra  
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

   
flugi - Tag | 111 hsz       Online status #24297   2006.08.06 09:45 GMT+1 óra  
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.

   
TPG - Tag | 3402 hsz       Online status #24296   2006.08.06 09:45 GMT+1 óra  
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.
Reality is almost always wrong. - House

   
Orphy - Törzstag | 1893 hsz       Online status #24294   2006.08.06 09:38 GMT+1 óra  
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
   
Orphy - Törzstag | 1893 hsz       Online status #24293   2006.08.06 09:36 GMT+1 óra  
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...
   
Csaba42 - Törzstag | 946 hsz       Online status #24292   2006.08.06 09:35 GMT+1 óra  
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.

   
flugi - Tag | 111 hsz       Online status #24291   2006.08.06 09:32 GMT+1 óra  
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.

   
flugi - Tag | 111 hsz       Online status #24290   2006.08.06 09:30 GMT+1 óra  
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++

   
gaborlabor - Moderátor | 4449 hsz       Online status #24289   2006.08.06 09:28 GMT+1 óra  
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?

   
Orphy - Törzstag | 1893 hsz       Online status #24288   2006.08.06 09:28 GMT+1 óra  
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
   
flugi - Tag | 111 hsz       Online status #24287   2006.08.06 09:26 GMT+1 óra  
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

   
Orphy - Törzstag | 1893 hsz       Online status #24286   2006.08.06 09:22 GMT+1 óra  
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.
   
gaborlabor - Moderátor | 4449 hsz       Online status #24280   2006.08.06 09:01 GMT+1 óra  
Ú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.

   
Orphy - Törzstag | 1893 hsz       Online status #24277   2006.08.06 08:41 GMT+1 óra  
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
   
BerbeckU - Tag | 506 hsz       Online status #24274   2006.08.06 08:23 GMT+1 óra  
ok, ezt nem tudtam...

___________
A lelkesedés az, ami a tudásnak ízt ad...


   
Csaba42 - Törzstag | 946 hsz       Online status #24272   2006.08.06 08:19 GMT+1 óra  
Ez így, ha jól értelmezem, nem lenne megfelelő, mivel a gtConsoleClass befejezését a főprogramban figyelem a
Kód:
if(console->doneTheProcess == true)
{
    display->Ready = true;
    break;
}

feltétellel, és a
Kód:
if((KEYDOWN(ip.keys,DIK_ESCAPE)) && (handled[36]==true))
{
    handled[36] = false;
    doneTheProcess = true;
}

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 .

   
BerbeckU - Tag | 506 hsz       Online status #24266   2006.08.06 07:45 GMT+1 óra  
Nem tudom, hogy jóra gondolok-e, de én biztos, hogy így csinálnám:
Kód:
while(console->doneTheProcess == false)
{
   //  valami
   if((KEYDOWN(ip.keys,DIK_ESCAPE)) && (handled[36]==true))
   {
       handled[36] = false;
       doneTheProcess = true;
   }
}

___________
A lelkesedés az, ami a tudásnak ízt ad...


   
TPG - Tag | 3402 hsz       Online status #24260   2006.08.06 06:14 GMT+1 óra  
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.
Reality is almost always wrong. - House

   
Csaba42 - Törzstag | 946 hsz       Online status #24259   2006.08.06 06:11 GMT+1 óra  
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ű.

   
Csaba42 - Törzstag | 946 hsz       Online status #24258   2006.08.06 06:01 GMT+1 óra  
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
Kód:
gtConsoleClass* console
// [...] egyéb kódok
console = new gtConsoleClass;

és a gtConsoleClass konstruktorában értéket adok a doneTheProcess változómnak
Kód:
doneTheProcess = false;

valamint az ESC billentyű leütésekor meghívódik az a függvény, melyben ez a kódrészlet szerepel:
Kód:
if((KEYDOWN(ip.keys,DIK_ESCAPE)) && (handled[36]==true))
{
    handled[36] = false;
    doneTheProcess = true;
}

akkor ez az ellenőrzés miért nem fut le a főprogramban:
Kód:
if(console->doneTheProcess == true)
{
    display->Ready = true;
    break;
}

Ötlete van valakinek?

   
Csaba42 - Törzstag | 946 hsz       Online status #24257   2006.08.06 05:50 GMT+1 óra  
A tiéd hosszabb, mint az enyém, Orphy

   
Orphy - Törzstag | 1893 hsz       Online status #24256   2006.08.06 05:45 GMT+1 óra  
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++
   
Csaba42 - Törzstag | 946 hsz       Online status #24245   2006.08.06 05:02 GMT+1 óra  
De a színek nincsenek

   
Csaba42 - Törzstag | 946 hsz       Online status #24243   2006.08.06 05:00 GMT+1 óra  
Nah, megvan a gond

   
Csaba42 - Törzstag | 946 hsz       Online status #24242   2006.08.06 04:50 GMT+1 óra  
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!!!

   
BerbeckU - Tag | 506 hsz       Online status #24239   2006.08.06 04:28 GMT+1 óra  
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++.

___________
A lelkesedés az, ami a tudásnak ízt ad...


   
beast - Törzstag | 1241 hsz       Online status #24235   2006.08.06 03:16 GMT+1 óra  
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...

   
bloodknife - Törzstag | 469 hsz       Online status #24233   2006.08.06 03:01 GMT+1 óra  
PYTHON->PHP+mySQL->C/C++
   
gaborlabor - Moderátor | 4449 hsz       Online status #24232   2006.08.06 02:50 GMT+1 óra  
Pont erre gondoltam, amit Csaba42 irt, valahogy nálam is igy volt, bár nálam valamivel rövidebb a sor:
Pascal -> C, C++

   
Csaba42 - Törzstag | 946 hsz       Online status #24230   2006.08.06 02:22 GMT+1 óra  
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.

   
Csaba42 - Törzstag | 946 hsz       Online status #24229   2006.08.06 02:19 GMT+1 óra  
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

   
gaborlabor - Moderátor | 4449 hsz       Online status #24228   2006.08.06 02:07 GMT+1 óra  
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.

   
TPG - Tag | 3402 hsz       Online status #24224   2006.08.05 17:35 GMT+1 óra  
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.
Reality is almost always wrong. - House

   
flugi - Tag | 111 hsz       Online status #24222   2006.08.05 15:05 GMT+1 óra  
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.

   
flugi - Tag | 111 hsz       Online status #24221   2006.08.05 14:59 GMT+1 óra  
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.

   
Orphy - Törzstag | 1893 hsz       Online status #24220   2006.08.05 13:24 GMT+1 óra  
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?
   
TPG - Tag | 3402 hsz       Online status #24214   2006.08.05 12:08 GMT+1 óra  
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.
Reality is almost always wrong. - House

   
Csaba42 - Törzstag | 946 hsz       Online status #24210   2006.08.05 12:02 GMT+1 óra  
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.

   
BerbeckU - Tag | 506 hsz       Online status #24205   2006.08.05 11:51 GMT+1 óra  
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!

___________
A lelkesedés az, ami a tudásnak ízt ad...


   
gaborlabor - Moderátor | 4449 hsz       Online status #24204   2006.08.05 11:35 GMT+1 óra  
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.

   
Csaba42 - Törzstag | 946 hsz       Online status #24203   2006.08.05 11:35 GMT+1 óra  
Már összefolynak előttem a betűk, túlcsordulási hiba...

   
BerbeckU - Tag | 506 hsz       Online status #24198   2006.08.05 11:00 GMT+1 óra  
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.

___________
A lelkesedés az, ami a tudásnak ízt ad...


   
flugi - Tag | 111 hsz       Online status #24197   2006.08.05 10:45 GMT+1 óra  
Idézet
Orphy :
Optimalizálás ki volt kapcsolva, debug módban néztem mindkettőt, azonos fordítási paraméterekkel.

A WinProc függvényem mindkét esetben ugyanolyan eseményeket kezel, nincsen különbség.
A pont, ahol x ms-re megáll, csak deviceLost-nál van, ráadásul ott a gyorsabb áll több ideig. Mondjuk ez nem számít, deviceLost a mérés során nem volt.

Sebesség szempontjából az még számíthat, hogy a gyorsabbik full static,
míg a másik "rendes", objektumos megoldású?

Ja, és csak a teljesség kedvéért, meg hogy fair legyen, a C#-os progit is debug módban néztem.



A metódushívás folyamata:
Az objektum első 4 bájtja egy mutató az osztályhoz tartozó függvénytáblázatra mutat. Az első művelet tehát ezt a mutatót elővenni. Az metódustáblában való kutakodás attól függ, hogy mennyire virtuális a metódus, és milyen messze van a megvalósítás a meghívástól, bár ez utóbbi fordítóprogramfüggő. (Van olyan fordítóprogram, ami láncolt listát alkot, mások vektorban tartják)

Statikusnál:
Mivel az osztályhoz tartozó statikus metódusból összesen csak egy van, megkerülhető az objektumból való kiolvasás (nincs lehetőség a statikus és dinamikus típus különbségéből adódó utánanézéskényszerre) Tehát minimum egy dereferencia megspórolható. Ha ilyenből tényleg nagyon sok van (de tényleg sok ) akkor észrevehető sebességváltozás is lehet belőle.

A többi különbség abból adódik, hogy a statikus metódusok általában globális változókat használnak, amikhez szintén nem kell az objektum címét tudni, stb.

Arra akarok kilyukadni, hogy az objektumorientáltság előnyét a virtuálistábla-kutakodás miatt nem használni kicsit túlzott hatékonysághajszolás. Ilyen erővel az összes ciklusodat, ami konstans iterációt végez, bontsd ki külön értékadásokra, cikluslefutásonként megspórolsz egy memóriaolvasást, növelést és memóriaírást

   
Orphy - Törzstag | 1893 hsz       Online status #24195   2006.08.05 10:31 GMT+1 óra  
Optimalizálás ki volt kapcsolva, debug módban néztem mindkettőt, azonos fordítási paraméterekkel.

A WinProc függvényem mindkét esetben ugyanolyan eseményeket kezel, nincsen különbség.
A pont, ahol x ms-re megáll, csak deviceLost-nál van, ráadásul ott a gyorsabb áll több ideig. Mondjuk ez nem számít, deviceLost a mérés során nem volt.

Sebesség szempontjából az még számíthat, hogy a gyorsabbik full static,
míg a másik "rendes", objektumos megoldású?

Ja, és csak a teljesség kedvéért, meg hogy fair legyen, a C#-os progit is debug módban néztem.
   
flugi - Tag | 111 hsz       Online status #24193   2006.08.05 10:10 GMT+1 óra  
Idézet
Orphy :
A főbb különbség a 2 között, hogy míg a gyorsabb az "eseménykezelőket" function pointer-en keresztül hívogatta, a framework-ös virtual függvényeken keresztül...



1: optimalizálás hová volt kapcsolva?
2: ha csak az eseménykezelés meg fp-vel, az biztosan nem magyaráz ekkora különbséget.
3: rendes grafikus program kötelességtudóan átadja a vezérlést néha, lehet hogy olyan frameworkod van, ami ezt megteszi anélkül hogy tudnád, és minden másodpercben x ms azzal telik, hogy a rendszer elvan a háttérben.
4: C++ nyelven, osztályokkal is lehet baromi hatékony kódot csinálni. Ennek külön irodalma van

Nem szabad ám három program futási sebességéből nyelvek közti különbségekre következteni

   
Orphy - Törzstag | 1893 hsz       Online status #24191   2006.08.05 09:20 GMT+1 óra  
A főbb különbség a 2 között, hogy míg a gyorsabb az "eseménykezelőket" function pointer-en keresztül hívogatta, a framework-ös virtual függvényeken keresztül...

Az eredmény érdekes... Ennyit számítana a virtual függvények használata???

Sebességek FPS-ben:
(Mindkét C++os üres, feket képernyő, C# üres képen egy db forgó 3szög)

C# max 700,
C++ framWork max 850,
C++ function pointer max 1050

Elgondolkoztató

Mindezt egy 1700+ AMD, 512MB, ATI Radeon 9600XT 128MB gépen mértem.
Gyengébb kártyán lehet, nagyobb különbségek is vannak.
   
Orphy - Törzstag | 1893 hsz       Online status #24190   2006.08.05 09:10 GMT+1 óra  
Ööööööö, bocsi, ID Software...

Basszus, gyerekek, addig OK, hogy a szépségért szenvedni kell, de nem gondoltam volna, hogy ez a programozásra is igaz...

A full ugyanazt csináló kód, a "régi" és az új, framework-ös gondolkodásra épülő "motorom" alapsebessége közötti különbségről beszélek...

A "szépség" ára jelen esetben 250. Fps-ben kifejezve...

ÁÁÁ, ez azért durva...
   
balogh9 - Törzstag | 801 hsz       Online status #24183   2006.08.05 08:31 GMT+1 óra  
Idézet
samu :
egy c++ programozót keresek, aki segítene c++ ban átírni egy kis progit.
egy szövegszerkesztőről van szó, annyit kellene átírni, hogy mondjuk egy
ideiglenes fileból olvassa ki hogy meg kell - e nyitnia vmit, ha igen akkor mit, vagy új fájlt létrehozni. egy dbpro- ban készülő, nem játék jellegü proojecthez kell.(mert dbproban ha jól tudom, csak inputtal lehetszöveget bekérni, magyarul normális szerkestőt nem lehet benne írni.
előre is kösz!!



hi,
ha nem olyan nagy a forráskód akkor dobd ki ide, vagy a linket rakd ki, sztem aki tud segíteni fog...
_____________________
C++ && OGL
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [85] [90] [95] [100] [105] [110] [115] > 120 < [125] [130] [135] [140] [143]