An Update on the CD Player script posted in my ,plan

#1 Yeah I'm still working on it, though I don't understand why it's not returning to me the correct total album length... though there's still a few different things i could try

I will keep SDL out of the Windows build!

-noh

#2 There isn't much point in replacing winRedbook.cc's mci calls with SDL, since SDL just wraps those very same calls. Not sure if this is what you're doing.

#3 Yeah that's what he did... However, it's a lot easier to use SDL (which is, of course, the point).. For example, using MCI directly I'm having issues where the album length that gets returned to me is a few seconds less than what the CDDB database thinks it should be. This causes the disc ID to be a little bit off and I can't get an exact match (there's some decent fuzzy searching that would work but that shouldn't be necessary)..

Appearantly, this isn't a problem for SDL so LabRat beat me to CDDB support ;p


----------------------------------------

As a side note, I looked at the Mac platform code and it doesn't appear to have support for CD Audio (redbook). If anyone has access to a Mac that can run torque and wants to fix it, it shouldn't be too hard... Linux uses SDL for it's CD Audio, and I'm sure it'd be more or less a copy and paste job for adding Mac support

-noh

#4 This came up in another post, but we should be careful about using SDL in the non unix platforms. Linux is a special case because it already has LGPL constraints (due to glibc, openal, and probably some of the other libs). The other platforms do not have LGPL dependencies and its probably not a good idea to introduce them without a good reason.

#5 I am only using the library. I am not integrating the SDL source into the GG source so it shouldn't be a problem.

Also sound in Torque for the Windows platform is tied to OpenAL just as it is in the Unix Build.

#6 If you "#include " and link torque with SDL either dynamically or statically, then your program falls into the category of a "work that uses the library" and is subject to the terms of the LGPL if you distribute it.

As for OpenAL, the OpenAL _specification_ is not distributed under any license, but the _implementations_ are. There are two implementations of OpenAL, the Creative implementation and the sample (Loki) implementation. The Creative implementation (used with Torque Win/Mac) is not covered by the LGPL. The sample implementation, however, is covered by the LGPL.

So, while it is true that Torque is tied to OpenAL, it is not true that it is tied to the LGPL on windows and mac.

You might find it useful to read the LGPL, it isn't too difficult to read, unlike other legal documents.

www.gnu.org/licenses/lgpl.html

#7 I've read it and I've read the FAQ for SDL at www.libsdl.org. Have you?

SDL on windows is a DLL, a dynamic link library.

The only provisions of the LGPL that must be followed is that a notification must be included showing that SDL is being used. And provide the source to the SDL library.

If I was statically linking the library into the Torque Engine I could see there being a problem. But the worry of possible contamination of the Torque source by using SDL on the windows build is a moot point if it is already being used on the linux build.

Once one platform's source has been contaminated / corrupted / infected, whatever you want to call it, by GPL or LGPL code, the entire Source tree is contaminated.

#8 Just dynamically link it and you'll be OK.

#9 I've read all that...I guess I haven't actually made my point clear. My point is this: if you want to use SDL in the non unix ports, and contribute that code back to the engine, you should clear it first with the GG guys (in particular Tim Gift). After some convincing, they did let me use it in the unix port, but I don't know what they will think about using it on windows/mac.

#10 yeah well, Ive got it working with MCI now on Windows... mailed it to LabRat to get the CDDB working in script...