|
|
|
|
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.
Reality is almost always wrong. - House
|
|
|
|
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.
Reality is almost always wrong. - House
|
|
|
|
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!
___________
A lelkesedés az, ami a tudásnak ízt ad...
|
|
|
|
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.
___________
A lelkesedés az, ami a tudásnak ízt ad...
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
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 
|
|
|
|
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.
|
|
|
|
Ööööööö, 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... 
|
|
|
|
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
|
|
|
|
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!
|
|
|
|
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!!
|
|
|
|
msdn.microsoft.com
legjobb DDraw link.
magyar nyelven xerintem Crusader viszi a pálmát.Tutort legalábbis;
|
|
|
|
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...
|
|
|
|
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
|
|
|
|
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 
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
Sajnos nem történt változás.
Practice makes perfect.
|
|
|
|
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
|
|
|
|
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
|
|
|
|
_____________________
C++ && OGL
|
|
|
|
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.
|
|
|
|
libfmod.a-t használok és azt linkelem be azért müxik dev alatt
Practice makes perfect.
|
|
|
|
Ja bocsi most olvastam vissza h VC gond ezer bocs!
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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;
}
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
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!
|
|
|
|
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.
|
|
|
|
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)
|
|
|
|
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.!
|
|
|
|
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?
|
|
|
|
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.
|
|
|
|
#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.
|
|
|
Legújabb project:
Ludo Bluetooth
Legutóbb frissített
project:
steampunk engineer
Friss kép a galériából:
|
Frissebbek | Korábbi postok 
