search

MovingBlocks / Terasology

Terasology - open source voxel world
http://terasology.org
Apache License 2.0
3.68k stars 1.34k forks source link

Support for JPG textures #809

Closed msteiger closed 8 years ago

msteiger commented 10 years ago

I was quite surprised to find that .jpg was not yet supported. In particular for larger textures such as background images (the current one has 4,1MB) , it might be quite valueable.

Currently, TS uses Slick2D or more precisely, Slick-Util. It uses an internal PNGDecoder for png files and awt.ImageIO for all other formats. Is there a reason for not using AWT directly?

Cervator commented 10 years ago

I don't know for sure if there is a reason, had figured PNG was a more "open" format somehow than JPG (although really I think GIF is the big legal issue one - or MP3). But yeah if there are no obstacles it would be nice to support JPG too

Another issue is simply having too large images at times. I recently shrunk the main menu image down and it is much smaller now. The "loading" variant is still 4 megs tho. Might be from taking super screenies then not shrinking before use.

immortius commented 10 years ago

There are no legal issues with the major image formats anymore. There's no real reason to use gif over PNG-256 though, except animation support.

Apparently Slick2D's PNGDecoder is much more performant than the awt handling, at the cost of not supporting more exotic options.

As for supporting JPG... JPG is lossy, and size isn't that expensive? You wouldn't be saving any runtime size either since that would all have to be uncompressed/decoded into bitmap data. For distribution the entire distribution can be compressed. Or the jars can be compressed.

That said we can add support for whatever additional formats of image we like. I would just argue it is in no way surprising that jpg is not supported, and it isn't clear that its support is potentially valuable.

OvermindDL1 commented 10 years ago

Once in memory to send to the video card it has to either be decompressed anyway or compressed in to a video-card specific format, such as DXT or so. JPEG also adds highly unacceptable alteration to the image, especially normal maps and other such things. Storing things on disc should be in a simple format capable of all the image needs, PNG is a good baseline, DXT would be better, but once loaded I imagine it is stored in to an atlas map, which involves uncompressing, combining (and recompressing if sent to the card as DXT) prior to sending to the card. PNG is lossless so it is the safest base format really. I personally do not think jpeg or gif (neither of which have patent issues anymore, those elapsed years ago) are worth adding, sure it would be convenient in a few ways but people would inevitably start storing something in them that they should not like a mapping of some sort or so. Supporting them might only save storage space, it will not save runtime memory regardless. I propose closing this, or if anything opening a new one for DXT textures as DXT has all of lossless, lossy, mipmapping, cubemaps, etc.... and much more support, as well is already in a native card format so it can be sent to video memory without needing to decompress it first on all cards even roughly modern.

Cervator commented 10 years ago

Maybe jpg isn't a good candidate for in-game textures, but perhaps large images for display like the menu background still hold potential?

msteiger commented 10 years ago

I agree with all of you.The orginal idea behind this was and still is smaller jar file size (for download).

The value I see is mostly for background images and other very large images. I suggest to add a log-warning (or even throw an exception) if used inappropriately (e.g. image size < 512x512).

In any case, the first step would be to separate the actual image decoding from the .texinfo file parsing which is currently part of PNGTextureLoader.

immortius commented 10 years ago

I will keep that in mind for gestalt-asset work.