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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2196
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] [142]
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
   
Orphy - Törzstag | 1893 hsz       Online status #24181   2006.08.05 08:24 GMT+1 óra  
Idézet
BerbeckU :
Nem tudna valaki egy jó linket adni ehhez a direckt draw-hoz? Mert ez a Crusaderféle nem nagyon jön be. Eljutottat odaáig ahol már mondtam, de nem tudok továbblépni...
A directX sdk-ban meg csak directShow van c++ -ban (vb.net-hez és c#-hez van directDraw is...) és az meg nem tudom mi, szóval elakadtam.. help me.



Berbeck:
DirectX9, és Direct3d...
Felejtsd el a DirectDrawt, annak leáldozott.

Nyisztor kari könyvében van erre egy külön rész (Sprite-ok), hogy azt hogyan kell.
Annyira nem bonyolult, hidd el.

A Direct3D-t igazából csak a megjelenítő eszközig kell kezelned, ha nem akarsz, nem számolsz a 3-ik koordinátával.

Nem utolsó szempont, hogy - mivel itt a legtöbben már ezt használják, akik directX-el foglalkoznak - könnyebben kapsz hozzá segítséget is...

Vegyél fel msn-re, küldök példaprogit!
   
samu - Tag | 65 hsz       Online status #24177   2006.08.05 07:49 GMT+1 óra  
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!!

   
MaximumViolence - Törzstag | 1020 hsz       Online status #24174   2006.08.05 07:26 GMT+1 óra  
msdn.microsoft.com
legjobb DDraw link.

magyar nyelven xerintem Crusader viszi a pálmát.Tutort legalábbis;
Ez egy reszeg post...

   
BerbeckU - Tag | 506 hsz       Online status #24171   2006.08.05 07:12 GMT+1 óra  
Nem tudna valaki egy jó linket adni ehhez a direckt draw-hoz? Mert ez a Crusaderféle nem nagyon jön be. Eljutottat odaáig ahol már mondtam, de nem tudok továbblépni...
A directX sdk-ban meg csak directShow van c++ -ban (vb.net-hez és c#-hez van directDraw is...) és az meg nem tudom mi, szóval elakadtam.. help me.

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


   
Orphy - Törzstag | 1893 hsz       Online status #24163   2006.08.05 05:59 GMT+1 óra  
Hát, az enyém DirectX-es lesz speciel, szóval a DirectMusic kb egyértelmű...
Csak annyit emlegették itt mostanában az FMOD-ot, hogy gondoltam belenézek

   
flugi - Tag | 111 hsz       Online status #24162   2006.08.05 05:54 GMT+1 óra  
Idézet
flugi :
A reverzsimhez csináltam vele hangot és zenét, negyedórámba telt onnantól, hogy letöltöttem a csomagot (.lib +.dll + .h)



Hogy egyértelmű legyen: doksiolvasással+tanulással együtt volt negyedóra

   
flugi - Tag | 111 hsz       Online status #24160   2006.08.05 05:52 GMT+1 óra  
Idézet
Orphy :

Belenéztem kicsit ebbe az FMOD-os világba, és hát az első tapasztalataim nem túl jók...
Az FMODex nevű csodát töltöttem le, merthogy az az újabb, több formátumot támogat, stb.

Elolvastam szépen, milyen lib-et kell linkelni vc-hez, belinkeltem, ugyanez a .h-kkal.
A projekt fordulásig sem jutott, "unresolved external symbol" linkerhibával leállt.
Tekintve, hogy megnéztem a könyvtárait manuálisan, és tényleg mindent jól csináltam, azt hiszem kijelenthetem, hogy ez gáz.

És az is gáz, ha neked az Init szétszáll, merthogy visszatérési értékkel kellene jeleznie, sikerült-e neki...

Mindezek után azt hiszem, nem fogok FMod-ozni, tökéletesen meg fog feleni a DirectSound, vagy az OpenAl.

Daani, neked azt tudom tanácsolni, hogy tedd be az init-et egy try-catch blokkba, akkor legalább szétszállni nem fog... Csak sajnos ettől még menni sem



Én ugyan nem használtam még FMOD dolgokat, a PortAudio-t és az SDL_mixer-t próbáltam ki, amik szépen működnek. Ez utóbbi egyébként iszonyú kényelmes, és csont nélkül megy. A reverzsimhez csináltam vele hangot és zenét, negyedórámba telt onnantól, hogy letöltöttem a csomagot (.lib +.dll + .h) Tudom ajánlani, már ha SDL-hez van köze a programodhoz

Lehet hogy a VC nem elég bőbeszédű a linkelésnél. Fontos, hogy legyél abban biztos, hogy a .lib fájl tényleg elérhető, akár a nevével, akár az elérési útjával lehet baj. Code::Blocks alatt ez nekem aránylag következetesen működött.

   
flugi - Tag | 111 hsz       Online status #24159   2006.08.05 05:44 GMT+1 óra  
Idézet
bloodknife :
Nem akarok közbeszólni de dev-c++ nem támogatja a lib fájlokat tudtommal viszont a static library-kat (.a) fájlokat igen..és azok szolgálnak lib fájlokként



A Dev-C++ és a Code::Blocks is a Gnu C fordítóját hívja meg, ami kezeli a .lib fájlokat is. Lehet, hogy nem lehet az egerészős felületen könnyen megadni a dolgokat, de ha beírod a linkelési paraméterekhez, hogy -L\a\lib\fajl\helye -lbigyo akkor a bigyo.lib és a libbigyo.a fájlokat is megtalálja és megeszi jól.

   
flugi - Tag | 111 hsz       Online status #24158   2006.08.05 05:41 GMT+1 óra  
Idézet
Orphy :
Ja, nagyon úgy tűnik, ilyeneket explicit típuskényszerrel kell hívni...

a

Kód:
függvény( (baseApp*)CGameApp );


megoldás műxik.
Nekem azért volt furcsa, mert főállásban C# alatt nyomom, ott pedig ilyenkor elég az ősosztályt megjelölni. Pl ha "object"-et adsz át, abban gyakorlatilag minden benne lehet.
Igaz, ott utólag kell típuskényszeríteni, ha használni akarod.

Ezt egyébként C++ alatt is elvileg meg kell tennem, ha nem virtual metódusokat akarok hívogatni...

Sebaj, a szigorú típusosság, ugye.
Most már ezt is tudjuk



Azért nem ennyire durva a helyzet. Alapértelmezésben ennek úgy kellett volna működnie, mint a kisangyal. Vagy a fordítóprogram, vagy a könyvtár szerzői akarhatták ezt másképp.

   
balogh9 - Törzstag | 801 hsz       Online status #24157   2006.08.05 05:32 GMT+1 óra  
Idézet
Daani :
Sajnos nem történt változás.



//music pointer deklarálása
FSOUND_SAMPLE* music = NULL;
ez a sor is jobb így, de nem hinném, hogy pont ez lenne a hiba. és esetleg ezt is kipróbálhatod: FSOUND_Init(22000,16,0);
_____________________
C++ && OGL
   
Daani - Tag | 92 hsz       Online status #24156   2006.08.05 05:23 GMT+1 óra  
Sajnos nem történt változás.
Practice makes perfect.
   
balogh9 - Törzstag | 801 hsz       Online status #24155   2006.08.05 05:04 GMT+1 óra  
FSOUND_Init (44100, 32, 0);
-> ha az initnél száll el akkor vmi bibi lesz a csatornával sztem (32), vagy akár a Hz-el. de persze vszínűbb a software-es hiba.

sztem ez a sor jobb lesz a music-nak:
music=FSOUND_Sample_Load (1,"pacman2.wav",FSOUND_2D, 0, 0);
_____________________
C++ && OGL
   
Orphy - Törzstag | 1893 hsz       Online status #24153   2006.08.05 04:52 GMT+1 óra  
Idézet
Daani :
Nos a progi véleményem szerint itt FSOUND_Init(44100,32,0); száll el ugyanis még kiírja azt, hogy
Initializing....



Belenéztem kicsit ebbe az FMOD-os világba, és hát az első tapasztalataim nem túl jók...
Az FMODex nevű csodát töltöttem le, merthogy az az újabb, több formátumot támogat, stb.

Elolvastam szépen, milyen lib-et kell linkelni vc-hez, belinkeltem, ugyanez a .h-kkal.
A projekt fordulásig sem jutott, "unresolved external symbol" linkerhibával leállt.
Tekintve, hogy megnéztem a könyvtárait manuálisan, és tényleg mindent jól csináltam, azt hiszem kijelenthetem, hogy ez gáz.

És az is gáz, ha neked az Init szétszáll, merthogy visszatérési értékkel kellene jeleznie, sikerült-e neki...

Mindezek után azt hiszem, nem fogok FMod-ozni, tökéletesen meg fog feleni a DirectSound, vagy az OpenAl.

Daani, neked azt tudom tanácsolni, hogy tedd be az init-et egy try-catch blokkba, akkor legalább szétszállni nem fog... Csak sajnos ettől még menni sem
   
balogh9 - Törzstag | 801 hsz       Online status #24149   2006.08.05 04:31 GMT+1 óra  
kukkants bele az írásomba, hátha segít....
http://x100.dataglobe.hu/jatekfejlesztes/page.php?&id=170
_____________________
C++ && OGL
   
Daani - Tag | 92 hsz       Online status #24148   2006.08.05 04:19 GMT+1 óra  
Nos a progi véleményem szerint itt FSOUND_Init(44100,32,0); száll el ugyanis még kiírja azt, hogy
Initializing....
Practice makes perfect.
   
Daani - Tag | 92 hsz       Online status #24135   2006.08.05 03:43 GMT+1 óra  
libfmod.a-t használok és azt linkelem be azért müxik dev alatt
Practice makes perfect.
   
bloodknife - Törzstag | 469 hsz       Online status #24134   2006.08.05 03:42 GMT+1 óra  
Ja bocsi most olvastam vissza h VC gond ezer bocs!
   
bloodknife - Törzstag | 469 hsz       Online status #24131   2006.08.05 03:41 GMT+1 óra  
Nem akarok közbeszólni de dev-c++ nem támogatja a lib fájlokat tudtommal viszont a static library-kat (.a) fájlokat igen..és azok szolgálnak lib fájlokként
   
gaborlabor - Moderátor | 4449 hsz       Online status #24126   2006.08.05 03:08 GMT+1 óra  
Idézet
Orphy :
Hmm, na az meg pláne furcsa...
Jó lib-eket használ? Mármint rémlik, hogy volt itt nem is olyan régen egy másik FMOD-os gond, és ott felvetődött, h van különbség...



Ugyanezt mondtam neki énis. Azt mondta hogy ugyanaz a verzió amit a dev-c++hoz töltött le. Meg azt is letisztáztuk hogy egyben töltötte le a fájlokat, ugyhogy verziószámban 100% hogy passzolnak. Nem is biztos hogy a kódban lesz a bibi mert dev alatt ugyanaz a kód. Én inkább valami project settings-re gyanakodok de nem vágom annyira az ms vc-t hogy ebben biztos legyek.

   
Orphy - Törzstag | 1893 hsz       Online status #24123   2006.08.05 02:56 GMT+1 óra  
Hmm, na az meg pláne furcsa...
Jó lib-eket használ? Mármint rémlik, hogy volt itt nem is olyan régen egy másik FMOD-os gond, és ott felvetődött, h van különbség...

Mindenesetre kicsit belekukkoltam az FMOD cikkbe, és láttam, hogy rá lehet vizsgálni, sikeredett-e az init, ez Daani-éból hiányzott.
A lenti kód kiegészítése:

Kód:
if( FSOUND_Init(44100,32,0) == false )
        // az fmod inicializálása 44100 Hz-en, 32 csatornával
        // ha nem sikerül akkor kilép a program
    {
         //nem sikerült inicializálni az FMOD-ot
        cout << "Az inicializálás nem sikerült... :( " << endl;
        return 0;
    }


Vagy lehet debugolni is...
Mindenesetre elsőkörben be kellene lőni, melyik sornál esik szét.
   
gaborlabor - Moderátor | 4449 hsz       Online status #24120   2006.08.05 02:48 GMT+1 óra  
Ja, és azt is meg kell említeni hogy Daani programja DevC++szal lefordítva működik, csak MS_VC6.0-val nem. Ugyhogy az is közrejátszik ott valamit, szerintem.

   
Orphy - Törzstag | 1893 hsz       Online status #24115   2006.08.05 02:44 GMT+1 óra  
Az nagyon furcsa...
Próbáld meg így, legalább látod, meddig jut el:

Kód:
#include "stdafx.h"
#include <iostream>
#include "fmod.h"

using namespace std;

int main ()
{
//music pointer deklarálása
FSOUND_SAMPLE* music;

cout << "Initializing..." << endl;
FSOUND_Init (44100, 32, 0);

cout << "Loading music... ";
music=FSOUND_Sample_Load (0,"pacman2.wav",0, 0, 0);

if( music )
{
cout << "Succeeded!" << endl;
FSOUND_PlaySound (0,music);
FSOUND_SetVolume(0,200);
}
else
{
cout << "Failed!" << endl;
}

getchar();

if( music )
{
FSOUND_StopSound (0);
FSOUND_Sample_Free (music);
}

cout << "Closing FSound" << endl;
FSOUND_Close();

return 0;
}
   
Daani - Tag | 92 hsz       Online status #24112   2006.08.05 02:33 GMT+1 óra  
Orphy: A pacman2.wav ott volt vele egy mappában és jól is volt írva a neve. Viszont megcsináltam az ellenőrzést az inicializálással, de a program le sem fut. Elindítom és azonnal kiírja a hibaüzenetet.
Practice makes perfect.
   
Orphy - Törzstag | 1893 hsz       Online status #24098   2006.08.05 00:44 GMT+1 óra  
Ja, nagyon úgy tűnik, ilyeneket explicit típuskényszerrel kell hívni...

a

Kód:
függvény( (baseApp*)CGameApp );


megoldás műxik.
Nekem azért volt furcsa, mert főállásban C# alatt nyomom, ott pedig ilyenkor elég az ősosztályt megjelölni. Pl ha "object"-et adsz át, abban gyakorlatilag minden benne lehet.
Igaz, ott utólag kell típuskényszeríteni, ha használni akarod.

Ezt egyébként C++ alatt is elvileg meg kell tennem, ha nem virtual metódusokat akarok hívogatni...

Sebaj, a szigorú típusosság, ugye.
Most már ezt is tudjuk
   
gaborlabor - Moderátor | 4449 hsz       Online status #24094   2006.08.04 16:29 GMT+1 óra  
gymisi, flugi: Köszi! winmm.a -m van, azt linkelem aztán ha nem müxik akkor töltök le valahonnét egy másikat...
----
szerk.:
müködik, probléma elhárítva, köszi mégegyszer!

   
flugi - Tag | 111 hsz       Online status #24092   2006.08.04 16:13 GMT+1 óra  
Idézet
Orphy :
Kód:
void függvény( baseApp* app )
{
...
}

CGameApp* app = new CGameApp();

függvény( app );


Error 1 error C2243: 'type cast' : conversion from 'CGameApp *' to 'baseApp *' exists, but is inaccessible

Erre a gondra valaki?



Explicit típuskényszerítéssel próbáltad már? És ha a statikus típus baseApp* ?

Előfordulhat, hogy a CGameApp-hoz megírták azt az operátort, ami baseApp-ra konverziónál meghívódik, és betették privátba ... Ha az örökösödés olyan, ahogy írtad, akkor natúrba a kódrészletednek mennie kéne.

   
flugi - Tag | 111 hsz       Online status #24091   2006.08.04 16:11 GMT+1 óra  
Idézet
gaborlabor :
Hali. CodeBlocks-ban kapok egy ilyen hibaüzenetet fordításnál:
Kód:
undefined reference to `timeGetTime@0'


Ha a timeGetTime() -t tartalmazó sort megjegyzésbe teszem, lefordul. Tudomásom szerint a timeGetTime az MMSystem.h-ban van definiálva, az MMSystem.h pedig a windows.h-ba van inkludálva. A programban benne van a #include <windows.h>, mégsem müködik ez az egy funkció.
Valakinek van valami ötlete?



a winmm.lib fájlt kell betenni a linkelni való .lib-ek és .a -k közé. Ha nincs ilyened, küldök. (VisualC++ tartalom, sajnos, én is Code::Blocks alól használgatom)

   
gymisi - Törzstag | 212 hsz       Online status #24090   2006.08.04 15:45 GMT+1 óra  
Idézet
gaborlabor :
Hali. CodeBlocks-ban kapok egy ilyen hibaüzenetet fordításnál:
Kód:
undefined reference to `timeGetTime@0'


Ha a timeGetTime() -t tartalmazó sort megjegyzésbe teszem, lefordul. Tudomásom szerint a timeGetTime az MMSystem.h-ban van definiálva, az MMSystem.h pedig a windows.h-ba van inkludálva. A programban benne van a #include <windows.h>, mégsem müködik ez az egy funkció.
Valakinek van valami ötlete?



Linker error -> msdn.com, de megnéztem már: Library: Use Winmm.lib.!

   
gaborlabor - Moderátor | 4449 hsz       Online status #24089   2006.08.04 15:34 GMT+1 óra  
Hali. CodeBlocks-ban kapok egy ilyen hibaüzenetet fordításnál:
Kód:
undefined reference to `timeGetTime@0'


Ha a timeGetTime() -t tartalmazó sort megjegyzésbe teszem, lefordul. Tudomásom szerint a timeGetTime az MMSystem.h-ban van definiálva, az MMSystem.h pedig a windows.h-ba van inkludálva. A programban benne van a #include <windows.h>, mégsem müködik ez az egy funkció.
Valakinek van valami ötlete?

   
Orphy - Törzstag | 1893 hsz       Online status #24078   2006.08.04 13:30 GMT+1 óra  
Személy szerint nem FMOD-oztam,

így ránézésre elsőnek azt nézném meg, tényleg megvan-e a "pacman2.wav"
(file-név elírás, nem máshonnan indítja-e a fejlesztőkörnyezet az exe-t, mint gondolod, ilyenek)

valószínűleg, ha nem találja a file-t, akkor a

Kód:
music=FSOUND_Sample_Load (0,"pacman2.wav",0, 0, 0);


sor után a music értéke NULL lesz bevett szokás szerint, erre megpróbálhatsz vizsgálni.
   
Daani - Tag | 92 hsz       Online status #24077   2006.08.04 12:57 GMT+1 óra  
#include "stdafx.h"
#include <iostream>
#include "fmod.h"

using namespace std;

FSOUND_SAMPLE* music;

int main ()
{
FSOUND_Init (44100, 32, 0);

music=FSOUND_Sample_Load (0,"pacman2.wav",0, 0, 0);
FSOUND_PlaySound (0,music);
FSOUND_SetVolume(0,200);

getchar();

FSOUND_StopSound (0);
FSOUND_Sample_Free (music);
FSOUND_Close();

return 0;
}
Practice makes perfect.
   
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] [142]