Quote Originally Posted by savage
I think OpenGL works well with JEDI-SDL, but then I am probably biased about that. For sound you could use OpenAL, though SDL_Mixer ( also part of JEDI-SDL ) is another alternative.
For graphics and input I would recommend SDL for crossplatform, maybe even with OpenGL support... For audio however I would stay far far away from SDL_Mixer... We used SDL_Mixer in the very first version of the Audio part of the Basilisk Engine and we ran into a lot of problems, especially considering the music playback, the SoundFX itself (as far as I can remember) was quite okay. After trying out a lot of libraries we ended up with OpenAL and I must admit we are very happy with it.

OpenAL works with (as far as there are sound drivers present) all soundcards as far as I am aware of. You can see OpenAL more or less as a wrapper library than a library itself, it wraps different sound libraries for different platforms into one standardized library. In Windows you have the choice between the default windows sound drivers (WinMM) or the DirectSound drivers and I noticed on the OpenAL website that there are even a few more drivers in Windows that are supported, in Linux you have the choice between a lot of the more popular sound drivers like ALSA and OSS and it supports many more platforms, for a list of platforms go to:

http://www.openal.org/platforms.html

for the OpenAL website visit:
http://www.openal.org/

There is one thing however I should mention about OpenAL, it's an SoundFX library only, so it doesn't come with any music support which you will have to write yourself for example by using streaming and the OGG Vorbis libraries. On Linux I think OpenAL supports MP3 if the right extension is installed, they are working on a Vorbis extension for Windows/Linux and MacOS but that is still in the beta stage... On Windows however EAX is supported...

Quote Originally Posted by Lightning
Quote Originally Posted by Sly
Ahh. Don't use messages. Handle the TApplication.OnIdle event, set the Done parameter to False and do updates and draws in there. Now you have no speed difference between a VCL app and a Win32 API app that do the same thing.
NO, the time it takes to paint is the same but CPU power is wasted wich reduces it's overall performance because of the high temperature, i used messages with good performance and a low CPU power, this might not be usual for games but if you can't detect movement you could put a timer message and get the same CPU hungry behaviour like the IDLE event.
Though i'm pretty sure you can always detect movement and paint only when necessary this will ensure that you don't use 100% CPU all the time and lower it's temperature. The 100% CPU philosophy is a DOS feature and i don't agree with it
I had to go into this, you talk about a timer event to detect movement, you are aware that the Timer event is the worst timer out there? I once tried to get a timer event to return ever 3 ms it returned ever 10 ms and the accuracy is different for each machine and the amount of workload running in the back, for collision detection this can be a disaster! In Windows it's more or less impossible to get 100% CPU time since there is no true multi-tasking, with the OnIdle you just request as much time-slices as you can when your application does not get any messages... If you want to handle messages just call Sleep(0) or Sleep(1) at the end of your OnIdle and it will make sure other applications in the waiting queue will get their time slices, I have written applications this way and the Task Manager mostly shows 0 - 1% CPU usage this way (depending on how much you do in the loop)... However if you don't make a fast-paced game there is no reason not to use the timer event and of course it will always be your own choice, but if you want to make a fast-paced game I would strongely advice against it ...