Archived File endings
- Thread starter metouto
- Start date
I assume you mean for assets? These are the supported file endings/types:
.prefab - Prefab files (json)
.ogg - Sounds and Music (or streaming and instant sounds)
.shape - Block Shape (specialised json mesh format)
.obj - Wavefront Mesh format
.png - Textures
.texinfo - Additional Texture info (json)
.glsl - Shaders
.info - Additional Shader info (json)
.mat - Material definition, combines shaders and their settings (json)
.block - Block definition (json)
.md5mesh - MD5 format skeletal mesh
.md5anim - MD5 format mesh animation
.fnt - BMFont font definition
.atlas - Texture Atlas definition
And for NUI:.skin - UI Skin (appearance)
.ui - UI Element definition
I was quite surprised to find that .jpg was not 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. Is there a reason for *not* using AWT which comes for free with the JRE?
Anyway, I volunteer for implementing JPG support using AWT or Slick2D, if you guys agree with me (that it would be useful).
Currently, TS uses Slick2D or more precisely, Slick-Util. Is there a reason for *not* using AWT which comes for free with the JRE?
Anyway, I volunteer for implementing JPG support using AWT or Slick2D, if you guys agree with me (that it would be useful).
Please don't cross post to the forum and git issues.
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 particularly valuable.
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 particularly valuable.