Replacing FMOD and DevIL

[princec]

Sniffing doesn't cause any measurable performance overhead. Open the file, set a mark, read in enough signature until something's recognised, reset the mark, hand over the stream to the appropriate sub-loader.

Cas

[elias]

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)

Read a few bytes, and figure out the file format, like ImageIO does.

- elias

[Matzon]

I am not sure I like the fact that N loaders have to read K bytes, when the user basically knows anyway.
of course you could do a load(input) and a load(input, type)

[Orangy Tang]

If you do a quick guess based on the file extension, then it's very likely that the first loader will be the correct one anyway. However I suspect we're well into overengineering territory now.

[kappa]

i like the idea of load(input, type), since many times you want to rename your image files so average joe doesn't see the extension and realise that he can easily open it in any paint program and steal your game art.

[Evil-Devil]

I am not sure I like the fact that N loaders have to read K bytes, when the user basically knows anyway.
of course you could do a load(input) and a load(input, type)

Yea, lets do both ways. Some more work but in the end we all benefit from

[Orangy Tang]

All I want is to easily play and loop OGGs and stream them reliably. Jorbis does a good job of decoding OGGs but streaming them through OpenAL is woefully unreliable and I can't figure out why.

The API I put on top of OpenAL went some way to doing this stuff but because of the streaming problems I couldn't really recommend it to anyone

This seems to be a software implementation of OpenAL, (found via this post). If reliability of OpenAL is the main problem (it's certainly one of the main reasons I don't like it) perhaps LWJGL could use this instead? It does sound promising as it lists "Many other small and large bugs squashed" from the original OpenAL source.

[elias]

That's an interesting project. I'm also concerned about the stability of the official OpenAL library (and why on earth do they still have a completely different implementation for each platform?). I'd like to have it support mac os x too (and written in java!), but you can't have it all.

- elias

[bobjob]

i have an image loader, that uses the java api. or did you want it api indepedant. it has tga support (not compressed). as well as a flip command. it can also convert bgr to rgb + flip, in 1 pass. The code isnt clean because i understand it, but if your interested i could clean it up for the sake of other people who may use it.

[ville]

The reason we're using Devil instead of loading our texture on java side is performance. It's quite a bit slower loading large png files in java, then passing them through jni to the native functions. So if at all possible, I'd like the Devil replacer to be at least as fast as Devil ever was.

[oNyx]

The reason we're using Devil instead of loading our texture on java side is performance. It's quite a bit slower loading large png files in java, [...]

The only reason to use PNGs is convenience. Compared to the other options it actually looks pretty bad. It's rather slow to load for what it has to offer, compression isn't great, the compression scheme is Deflate (the same Jar/Zip uses... and usually you use that already or something better), and it also uses the full amount of VRAM.

Using PNGs and being overly worried about performance is a bit... how should I put it... weird?

[ville]

Well it's the same for any image type really, java actually reads the files pretty fast. The slow part is I think getting the image data from java to the c code, so that's why I'm thinking the loading should be done in native code.

[princec]

I find it dead fast, but that's because I use a custom format very similar to TGA which reads raw image data directly into native ByteBuffers and then passes it straight to OpenGL as a pointer. About as fast as you can get in Java in fact.

Cas