Hello Guest

Replacing FMOD and DevIL

  • 42 Replies
  • 62503 Views
*

Offline princec

  • *****
  • 1933
    • Puppygames
Re: Replacing FMOD and DevIL
« Reply #30 on: October 31, 2007, 11:03:44 »
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 :)

*

Offline elias

  • *****
  • 899
    • http://oddlabs.com
Re: Replacing FMOD and DevIL
« Reply #31 on: October 31, 2007, 12:29:42 »
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

*

Offline Matzon

  • *****
  • 2242
Re: Replacing FMOD and DevIL
« Reply #32 on: October 31, 2007, 13:43:03 »
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)

Re: Replacing FMOD and DevIL
« Reply #33 on: October 31, 2007, 13:50:01 »
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. ;D

*

Offline kappa

  • *****
  • 1319
Re: Replacing FMOD and DevIL
« Reply #34 on: October 31, 2007, 14:54:34 »
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.

Re: Replacing FMOD and DevIL
« Reply #35 on: October 31, 2007, 15:55:00 »
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 ;)

Re: Replacing FMOD and DevIL
« Reply #36 on: November 22, 2007, 12:06:34 »
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.

*

Offline elias

  • *****
  • 899
    • http://oddlabs.com
Re: Replacing FMOD and DevIL
« Reply #37 on: November 22, 2007, 12:21:38 »
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

*

Offline bobjob

  • ****
  • 394
  • LWJGL: WOW SO GOOD
Re: Replacing FMOD and DevIL
« Reply #38 on: December 09, 2007, 20:15:12 »
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.

Re: Replacing FMOD and DevIL
« Reply #39 on: December 13, 2007, 12:02:50 »
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.
Working on Ekapeli, a learning game for Finnish children.

*

Offline oNyx

  • ***
  • 177
  • 弾幕
Re: Replacing FMOD and DevIL
« Reply #40 on: December 15, 2007, 11:03:02 »
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? :)

Re: Replacing FMOD and DevIL
« Reply #41 on: December 17, 2007, 14:02:41 »
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.
Working on Ekapeli, a learning game for Finnish children.

*

Offline princec

  • *****
  • 1933
    • Puppygames
Re: Replacing FMOD and DevIL
« Reply #42 on: December 18, 2007, 11:32:43 »
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 :)