alutLoadWAVFile() give me an unresolved external error on my BC5.02 after I''ve coff2omf''ed the respective lib(s)? Both of the supplied dll''s (OpenAL32.dll and EaxAc3.dll (which I don''t think I''m using currently) are where they should be - in the root dir of the app).
To be more precise - that''s not what''s bothering me. What''s more annoying is that alBufferData() crashes hard when I feed it custom-loaded sound data. I have the sound loading routine nicely set up to load 16bit short-length samples from 16bit wave files, so this data is what I am passing to alBufferData(), but I don''t think that could cause the function to crash - at the worst I would simply hear jibberish, right?
Does anyone have any experience with this? The Net is not very friendly on this subject when it comes to obtaining info on my own...
Any help is appreciated,
Crispy
openAL
Author
hi,
Why does
If you think the problem actually lies in the library conversion, try rebuilding it on your own from the CVS source (I''ve never used OpenAL in Borland, and I''ve never used the ALUT wave loading functions, so I don''t really have information on this 
). Make sure you aren''t passing too little data to alBufferData, that''s the only thing I could think of off hand...
). Make sure you aren''t passing too little data to alBufferData, that''s the only thing I could think of off hand...
Author
i''m using a 600kB wav file - perfectly healthy. Moreover, Null and Void, could you please define ''too little data''?
Crispy
Crispy
What I mean is that if you say you''re passing 1000 bytes, but you only pass a pointer to a buffer of 50 bytes, you could potentially get a crash (but, then again, you might not; this may be OS dependent too). Sorry that I''m not much help.
Never used OpenAL before, but Googling for "alutLoadWAVFile unresolved external error" came up with this, which probably will solve your first problem:
As for the crashing, could it be a symptom of the external error .. ?
quote:
The alutLoadWavFile() (and all the other alut* functions) are present in a
seperate library file called alut.lib that will need to be linked to your
application in addition to the openal32.lib. A while ago we added an extra
parameter to the alutLoad... functions - a boolean variable that would be
set to TRUE if the wave file contained looping information. It maybe that
your alut.h file is not in sync with the alut.lib file and this is causing
problems ?
As for the crashing, could it be a symptom of the external error .. ?
Author
Thaks Colin 
- I read that, but that isn''t the case. This goes to prove - always triplecheck your code before you post. The reason things didn''t work was because I''d put
Thanks for the feedback, though,
Crispy
- I read that, but that isn''t the case. This goes to prove - always triplecheck your code before you post. The reason things didn''t work was because I''d put DialogBox() function for the main app dialog before the initialization code for OpenAL - it appears OpenAL is stupid enough not to check if it''s been initialized before it crashes. Lol, I''m used to window-calls taking up several pages of code - now that I pasted the whole OpenAL stuff into WinMain() I totally missed the one single line Thanks for the feedback, though,
Crispy
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
