Replacing FMOD and DevIL

[Jon]

As a first slab i think the slick stuff is pretty good, does all the major image formats, it does use imageIO, but theres already a custom tga loader in there(pretty damn fast), also theres a nice png loader (which is faster than ImageIO) somewhere on JGO as well as a DXTn library floating around also on JGO, the rest of the formats can be replaced over time to become ImageIO free.

As for sound lwjgl_util package already has a wav file loader(could do with some streaming support), add with jorbis for ogg, and ibxm lbrary for .mod and .it support.

just a matter of collecting the stuff and wrapping it.

We've been looking at doing that, and if you're interested in helping out with that effort, please post about it on the Slick forums. I was responsible for the initially working on this (the TGA, DXTn stuff), but I didn't get around to all the file formats. I also don't think my DXTn stuff ever went in (don't know why), but I'll ask Kev again about it.

http://slick.javaunlimited.net/viewtopic.php?t=438

I also remember the PNG code being thrown around, but I don't have it anymore, nor would I want to make that from scratch.

- Jon

Edit: Now I remember why. The JSquish library dependency. Not big, but still yet another dependency. It'll work for LWJGL though.

[Jon]

I use .it files for music, since they're the format my sound guy prefers. I will try and find out why and what advantages it has (although I have no idea how technically hard it would be to write something to play it back).

They are sequenced music files like MIDI, except that the samples are stored in the file rather than looked up in a wavetable or soundbank. This means that they sound the same (perfect) on every computer. They were used all over in video game consoles up until this current generation.

You can play back such files using this library.

http://www.geocities.com/sunet2000/

- Jon

[oNyx]

>And the only formats we need were TGA, BMP, PCX, DXTn.

TGA, BMP and PCX are all raw formats. TGA is the most feature complete one... so, only that one is needed. RLE shouldn't be supported, because it's far worse than deflate (jar) or any other compression scheme you might be using (eg lzma).

To cover the usual game cases 3 formats are required:

1. TGA - simple hassle free raw format
2. DDS - covers different raw formats, DXTn flavors and other game specific stuff
3. JPG - lossy format which is easy to create (no CMYK, but gray scale and progressive should be eventually supported)

TGA is a pretty simple format. Implementing a loader for that shouldn't be much of an issue. For the most part it will be a matter of C&P, I guess.

DDS is quite complex, but fortunately it's sort of modular. "Sub formats" can be implemented as needed. Eg it would be a good idea to start with DXTn, then the vector stuff, then all raw modes, then cube maps etc.

As annoying as JPG is, it's widely used for games - especially in the downloadable game sector. Supporting it is crucial for adoption.

[Orangy Tang]

Surely png should be supported too? A bunch of pngs should be smaller than the zipped raw equivilents (although I have no data to back this up, so I really should try a quick test to see).

[elias4444]

I know I use PNGs. They're easy to implement via ImageIO too.

[princec]

So basically, the four essential formats are:
1. PNG, because it's ubiquitous
2. TGA, because it's simple
3. JPEG, because it's lossy and therefore very compressible
4. DXTn, because it's graphics card native
and what's more we don't really need to be able to write these formats, just read them.

As for music... well, I don't use FMOD, but I would really like something that reliably streams OGGs. Jorbis seems reliable enough as a decoder, the problem is really OpenAL being unreliable. Perhaps we could ask the AL devs why it's such a problem. Otherwise all that's needed are some really simple functions to wrap all the complexity and then add more later to mimic FMOD functionality.

Cas

[Orangy Tang]

and what's more we don't really need to be able to write these formats, just read them.

Although if anyone does want to write to png files, they can pinch this handy bit of code.

[mot]

Hello, here's my take:

• Need to read PNG and write PNG or JPG.
  Preferrably without using ImageIO to allow trimming down the Windows JRE.
• Currently using DevIL to load PNG & JPG files, convert between pixel formats, upload to OpenGL, write PNG or JPG files (screenshots).
• Would probably do fine with TGA only - as long as it's fast enough.
• Not using FMod - shareware license is too restrictive.
• Don't care about modules.
• Need to load OGG and WAV and stream OGG music from disk
  (with varying degrees of success  [ hey Cas ] ). I'm also using Jorbis for that now.

It would be very, very nice to see a small Java-only library that loads a few audio formats, can stream stuff from disk and takes care of basic channel management. Easy to write custom audio effect and loader plugins for it. Main requirement - 100% stable on all platforms. To achieve that it would probably need to bypass OpenAL channel ("Source") management and do it's own mixing. Can't imagine it taking up too much CPU on today's machines.

[bobjob]

yoyo,
Cant really help with the texture stuff. I would really love to have a way of loading jpgs, for online downloading of a package.

I could spend some time on the audio side of things. Currently i load my music using jogg/jorbis (streaming). only my sound fx end up working with openAL. I can spend some time to tweek the music code and make streaming audio package(using alSourceQueueBuffers). Or did you want the sound to be independant of outside packages? waiting for a thumbs up.

[oNyx]

I didn't mention PNG in my list, because it uses Deflate - the same algorithm ZIP/JAR is using. The only difference is that it may use filters, which may improve the compression ratio. However, lzma usually performs better... yes, even with images which benefit a lot from filtering. (One of the few exceptions is the "extreme and unrealistic case" from the libpng page.)

Those filters don't help with pixel art. They help with photo-based textures, but PNG isn't a good choice for that kind of image data anyways. JPG and DXTn will usually yield way smaller files at acceptable quality.

A useful feature of PNG, which isn't covered by TGA are the indexed modes with one or several tRNS entries (that's bitmasked and RGBA palette respectively).

However, those raw modes are covered by DDS as well. That's why I think that PNG isn't worth the trouble.

If someone is willing to write it - great, but it shouldn't be a top priority. The other formats are far more important, because they have distinctive characteristics.

[Matzon]

The reason for using png is that it is ubiquitous. The loader would probably allow any "loaders" to try and read it and fall back to ImageIO (pending any awt dependency issues). So in that case PNG would be supported too.

However, this replacement should be *fast*, and we therefor shouldn't even be sniffing filetypes and doing a pluing based architecture. A simple ImageData img = ImageLoader.load("/path/to/file", ImageLoader.FILETYPE_TGA); should suffice.

Of course, there might be a need for an ImageLoader.load(path, type, options). We just need to take a stab at it and see how it works out.
Any volunteers?

[elias]

The reason for using png is that it is ubiquitous. The loader would probably allow any "loaders" to try and read it and fall back to ImageIO (pending any awt dependency issues). So in that case PNG would be supported too.

However, this replacement should be *fast*, and we therefor shouldn't even be sniffing filetypes and doing a pluing based architecture. A simple ImageData img = ImageLoader.load("/path/to/file", ImageLoader.FILETYPE_TGA); should suffice.

Of course, there might be a need for an ImageLoader.load(path, type, options). We just need to take a stab at it and see how it works out.
Any volunteers?

I'd avoid FILETYPE_* and instead use the filename extension (".tga") to guess the filetype. Other than that, we'll need to support InputStreams too in case the data is loaded through ClassLoader.getResource().

- elias

[Matzon]

yes to inputstream, no to guessing file type.

I don't see the point in guessing the file type since the developer ought to know what file type is being used.
Alternatively we need to parse the path and then compare with a list of known lowercase or uppercase file types. By forcing a file type you are effectively removing some processor overhead and you also get an idea of what file types are supported.

[elias]

yes to inputstream, no to guessing file type.

I don't see the point in guessing the file type since the developer ought to know what file type is being used.
Alternatively we need to parse the path and then compare with a list of known lowercase or uppercase file types. By forcing a file type you are effectively removing some processor overhead and you also get an idea of what file types are supported.

Still yes to guessing file type . The processor overhead of looking up <lower case extension>->Plugin is negliable, and as for the developer knowing the file type, consider the case where the file name is configurable from e.g. an xml file. Then the developer need to do his own mapping from extension to type or the type needs to be in the configuration file. Besides, ImageIO doesn't use separate file type arguments in ImageIO.read().

- elias

[Matzon]

Still yes to guessing file type . The processor overhead of looking up <lower case extension>->Plugin is negliable, and as for the developer knowing the file type, consider the case where the file name is configurable from e.g. an xml file. Then the developer need to do his own mapping from extension to type or the type needs to be in the configuration file. Besides, ImageIO doesn't use separate file type arguments in ImageIO.read().

How do you guess the type from an input stream? - without sniffing (which causes performance overhead)