[DarkBasilisk]

Cursory scan looks like Gentoo and Arch have it in their repositories, yum has it as well.

It's lacking from either Ubuntu or Debian's repos, but there's a provided .deb file from the devs that will work on Debian-based systems.

[Goober5000]

Wait, so people will need to download DLLs or something in addition to the FSO binary?  I thought we were going to build the library into the program so that we wouldn't need any external dependencies?

[DarkBasilisk]

Wait, so people will need to download DLLs or something in addition to the FSO binary?  I thought we were going to build the library into the program so that we wouldn't need any external dependencies?

This is for the linux side, I think it's all packaged into the binary for windows. Right now for most of the external libraries, linux FSO compiles link against a system's installed libraries. I set things up to further that trend. I don't know for sure, but I'm pretty sure Zacam said, the external libraries for windows are all wrapped up into the FSO binary.

[chief1983]

Yeah, Goober, whatever's been discussed so far, nothing would really change at all for any platform but Linux, aside from possibly having a different library including in SVN, but even changing Windows to libjpeg-turbo doesn't sound necessary for this to work.  It would throw the warning that -turbo isn't being used though, but we could fix that simply by changing the library in SVN, or only throwing the warning on Linux.

[chief1983]

As an update, it looks like we would want to switch all platforms to -turbo after all.  Windows was confirmed yesterday to be exhibiting some form of bug with jpegs, and it's probably the same cause.  So, the legwork has already been done for Linux in DarkBasilisk's post, now we just need to do the MSVC and Xcode projects.

[Goober5000]

So... then I repeat my previous question.

[Zacam]

Windows would compile -turbo just like it currently compiles libjpeg. No external DLL required for FSO at all.

Building on Linux would have the dependency of needing to have -turbo installed, or some method to defaulting to the SVN provided iteration if a system library is not found.
But most linux users are more savvy than windows users and can probably figure that out pretty easily, or they wouldn't be using linux.

No clue on Mac, but I'm sure Chief, Echelon9 and jg18 can figure it out and I can haul my mac out as well. Worst case scenario, it builds into the app what is in SVN.

[MatthTheGeek]

Building on Linux would have the dependency of needing to have -turbo installed, or some method to defaulting to the SVN provided iteration if a system library is not found.
But most linux users are more savvy than windows users and can probably figure that out pretty easily, or they wouldn't be using linux.

As someone who has compiled on linux in the past, I can tell than the number of dependencies required is already large. One more or one less is absolutely no trouble.

[chief1983]

Goob, the end result wouldn't be any different for the user.  We'd just be switching out libjpeg for libjpeg-turbo in SVN, and compiling it in the same way we always have.

[pecenipicek]

Building on Linux would have the dependency of needing to have -turbo installed, or some method to defaulting to the SVN provided iteration if a system library is not found.
But most linux users are more savvy than windows users and can probably figure that out pretty easily, or they wouldn't be using linux.

As someone who has compiled on linux in the past, I can tell than the number of dependencies required is already large. One more or one less is absolutely no trouble.

Agreed here.

[Goober5000]

Goob, the end result wouldn't be any different for the user.  We'd just be switching out libjpeg for libjpeg-turbo in SVN, and compiling it in the same way we always have.

That's what I thought, but I wanted to make sure.  Cool.

[niffiwan]

Just an update on the status of this...

There's been some problems getting the libjpeg-turbo library to work on all platforms so in the interim I've committed a patch to trunk (r7891) which does a colour byte swap in the FSO jpeg routines.  I've tested this successfully with the WoD jpeg loading screens, when the nightlies are updated could some more people test this out, e.g. Nighteyes with the CBanims?

I'm going to continue to see if I can get libjpeg-turbo sorted out, but it may take some time and we don't want to delay a fix for this issue too much longer

[chief1983]

We sure don't, this is definitely good enough to get 3.6.14 out the door, as people don't really use jpeg much these days anyway, but we don't want a regression.

[Goober5000]

That loop could be made more efficient.  Instead of counting by ones and dividing by three each time, it should count by threes.  Use k += 3 instead of k++.

[niffiwan]

The efficiency suggestion has been committed in trunk r7898 - thanks Goober5000 & Iss Mneur (apologies to Zacam who now has to backport to antipodes & 3.6.14 again! )