Talk:FPC and SDL
Is the section "Tips and tricks" really relevant ? On Debian system, smpeg isn't hard to get (just install package `libsmpeg0'). Moreover, Debian `libsdl-mixer1.2' package already depends on smpeg anyway. Moreover, reading SDL_Mixer home page, the fact that SDL_Mixer requires smpeg (for mp3 support) is perfectly normal. So I would say that probably every modern Linux distro
- makes smpeg library easily available
- packages SDL_Mixer library in such way that it depends on smpeg library, to be able to play mp3
So the fact that SDL_Mixer unit uses smpeg unit is perfectly normal and there's no need to make a fuss about it. So the section "Tips and tricks" may be removed. Any comments ? Michalis 01:31, 9 Jan 2006 (CET)
You are thinking in limited terms.
Linux is only SO small. Smpeg dll is hard to get on windows for example. Why you ask? well because you have no C compiler which can compile it, and because smpeg is not readily available as .dll.
There are a few of them for windows but not all work. Same story for SDL_gfx v2.0 ofcourse that lib is optional so no problem to solve. Another point is you have one less library to distribute with your game even on *nix. SDL and friends are common but not all distroes and unices have them and most don't include them by default. It's always a good idea to have them distributed. (most non-distro-packed games do this btw)
- Well, you're right, I was thinking about Unixes, not about Windows. All modern Linux distros and FreeBSD include smpeg so I just figured out that the sentence "This can be a setback since this isn't a standard library and is hard to get (CVS only afaik)." is simply wrong for Unixes. But you're right -- it may a problem on Windows (although smpeg.dll is included inside SDL_sound for Visual C sources, also gearhead includes it -- but I didn't test it). And it may be indeed troublesome to distribute smpeg.dll/so with your product when you don't use it at all and you have SDL_mixer compiled to not link to smpeg. So I'll keep the notice about smpeg, I'll just reword it. Michalis 04:09, 7 Feb 2006 (CET)
unitpath in fpc.cfg
the fpc.cfg understands wildcards, so instead of addin all unit dirs, one can try:
-Fu<jedi-sdl-path>/JEDI-SDLv1.0/*/Pas
--Marc 15:29, 9 Feb 2006 (CET)
- Unfortunately, this is not so good idea, because this will include path
-Fu<jedi-sdl-path>/JEDI-SDLv1.0/OpenGL/Pas/
- that includes gl.pas and glu.pas units that have the same names as the OpenGL units included in FPC.
- The full story goes like that : OpenGL units currently included in FPC were taken from Tom Nuydens (see http://www.delphi3d.net/) and then modified, adapted etc. so that everything works perfectly with FPC (on the other hand, FPC devels obviously didn't have to care about keeping them working with Delphi/Kylix). OpenGL units included in jedi-sdl were taken from http://www.delphi3d.net/, and then modified by jedi-sdl people. But jedi-sdl people didn't care about FPC when working on these OpenGL units. In effect, while gl and glu units from jedi-sdl will compile with FPC, they have a couple of small problems. These small problems can be nasty, e.g. FPC and Delphi sometimes pass parameters differently which means that functions have to declared a little differently (you can compare gl and glu units between FPC and jedi-sdl to see the many differencies).
- So the bottom line is: if you use FPC, then do not use gl.pas and glu.pas provided by jedi-sdl. You should use gl.pp and glu.pp provided by FPC installation. So including line like
-Fu<jedi-sdl-path>/JEDI-SDLv1.0/*/Pas
- is very dangerous, because it adds these unwanted units to your search path. Then it depends on the order in which FPC will search directories --- if FPC will find and use jedi-sdl gl/glu units, your OpenGL programs may compile but mysteriously fail at runtime.
- -- Michalis 22:31, 13 Mar 2006 (CET)
