For a while i noticed some strange bug, which happenes when i try to port soething SDL + SDL_Mixer related. For example, that piece of code:
Quote:
int audio_rate = 44100; Uint16 audio_format = AUDIO_S16; int audio_channels = 2; int audio_buffers = 4096;
In the game give me noise and annoing sound. And over that noise i can sometime heard original (but noised too) sounds and music.
If i change AUDIO_S16 on AUDIO_S8 : everything works fine. Sound ok, and all is ok. So the question: why it happenes , and where is problem, and because of what is happenes: because of bad SDL, or because of bad SDL_Mixer or because of other ported libs ?
And the second question, its about sound in OpenAL. Today i tryed to port some nasty RPG game, and that game have that piece of code:
if(vorbisInfo->channels == 1) { format = AL_FORMAT_MONO16; } else { format = AL_FORMAT_STEREO16; }
loopInterval = -1;
And, after compiling, i have the same Noise sound as sometime happenes with the plain SDL_Mixer. I tryed to change it on all possible 4 sound openal formats, but still, noise always here (sometime big, sometime not).
Have someone any idea why it happenes, and maybe its because of old SDL_Mixer or old Vorbis or kind ?
Hmm OK. Have a chat to IamSONIC, he might be able to help you out.
I might see about compiling a new SDL_mixer too... but I want to compile a clib2 version of SDL myself, so I can get a clib2 SDL_image, ttf, mixer, etc and stick them on OS4Depot.
Edit: I'm doing a clib2 compile of SDL now, then i'll compile SDL_image, and if i'm able to, SDL_mixer for both newlib and clib2. They'll be static libs (but that's all they ever were on OS4Depot)... Someone else can do shared libs :)
// This function loads a .ogg file into a memory buffer and returns
// the format and frequency.
void LoadOGG(char *fileName, vector<char> &buffer, ALenum &format, ALsizei &freq)
{
int endian = 0; // 0 for Little-Endian, 1 for Big-Endian
int bitStream;
long bytes;
char array[BUFFER_SIZE]; // Local fixed size array
FILE *f;
// Open for binary reading
f = fopen(fileName, "rb");
if (f == NULL)
{
cerr << "Cannot open " << fileName << " for reading..." << endl;
exit(-1);
}
// end if
vorbis_info *pInfo;
OggVorbis_File oggFile;
// Try opening the given file
if (ov_open(f, &oggFile, NULL, 0) != 0)
{
cerr << "Error opening " << fileName << " for decoding..." << endl;
exit(-1);
}
// end if
// Get some information about the OGG file
pInfo = ov_info(&oggFile, -1);
// Check the number of channels... always use 16-bit samples
if (pInfo->channels == 1)
format = AL_FORMAT_MONO16;
else
format = AL_FORMAT_STEREO16;
// end if
// The frequency of the sampling rate
freq = pInfo->rate;
// Keep reading until all is read
do
{
// Read up to a buffer's worth of decoded sound data
bytes = ov_read(&oggFile, array, BUFFER_SIZE, endian, 2, 1, &bitStream);
if (bytes < 0)
{
ov_clear(&oggFile);
cerr << "Error decoding " << fileName << "..." << endl;
exit(-1);
}
// end if
// Append to end of buffer
buffer.insert(buffer.end(), array, array + bytes);
}
while (bytes > 0);
// Clean up!
ov_clear(&oggFile);
}
// end of LoadOGG
int main(int argc, char *argv[])
{
ALint state; // The state of the sound source
ALuint bufferID; // The OpenAL sound buffer ID
ALuint sourceID; // The OpenAL sound source
ALenum format; // The sound data format
ALsizei freq; // The frequency of the sound data
vector<char> bufferData; // The sound buffer data from file
// Make sure there is a file name
if (argc < 2)
{
cerr << "Syntax: " << argv[0] << " OGGFile" << endl;
return -1;
}
// end if
// Initialize the OpenAL library
alutInit(&argc, argv);
// Create sound buffer and source
alGenBuffers(1, &bufferID);
alGenSources(1, &sourceID);
// Set the source and listener to the same location
alListener3f(AL_POSITION, 0.0f, 0.0f, 0.0f);
alSource3f(sourceID, AL_POSITION, 0.0f, 0.0f, 0.0f);
// Load the OGG file into memory
LoadOGG(argv[1], bufferData, format, freq);
// Upload sound data to buffer
alBufferData(bufferID, format, &bufferData[0], static_cast<ALsizei>(bufferData.size()), freq);
// Attach sound buffer to source
alSourcei(sourceID, AL_BUFFER, bufferID);
// Finally, play the sound!!!
alSourcePlay(sourceID);
// This is a busy wait loop but should be good enough for example purpose
do
{
// Query the state of the souce
alGetSourcei(sourceID, AL_SOURCE_STATE, &state);
}
while (state != AL_STOPPED);
// Clean up sound buffer and source
alDeleteBuffers(1, &bufferID);
alDeleteSources(1, &sourceID);
And you will heard that annoing noise (well, i have). Try it please with all your latest ported libs. Will it the same noise, or will it ok. If will be noise, then, we need to check out OpenAL. If not, then some of my libs outdated or compiling line are wrong ..
@afxgroup Yep, you are right. Vorbis for us mean SDL_Mixer, which mean SDL, etc.
@all I found where is bug, it was in the ov_read() fucntion , which also want to know Endian. So for now all works fine, and problem was because of endianes, not because of Libs.
If someone in interest, all of this was because of porting of nice opensource RPG game called DccNiTghtmare. With help of author we changed sources a bit, for make all of this works on aos4 (and now it works for me in window mode also, thanks to new features of SDL, if someone in interest can upload screenshot somethere), but the main problems which avoid me to release it right now: madness slow framerate. With everything related to video in FALSE , with only 640x480 in window mode (but on 32bit WB), without music, it give only 4 fps _maximum_ on my peg2 / 1ghz with radeon9250.
As author say, radeon9250 pretty slow for such thinks, but, it of course possible to optimize it, but he do not have radeon9250, and he do not know what can cause such bottleneck. If some one can help me , to speed up that game (for example to make it at least working on 15-20 fps), then it will be pretty nice, because game pretty modern and interesing (you can check vids on site of game).
I also tested win32 version of that game on my win32 (dual core pentium 1.8 with some nvidia gfx card which was modern 2 years ago), and even on that computer it give me 30fps only (1024x768)
All in all, next release will be with aos4 support, even if it madness slow. Its just a start, and maybe later i will speedup it, and new hardware on horizont too )
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
