Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 107 Roadmap
- 358 Game & application design
- 316 Plugins
- 70 User experience
- 75 Marketplace
- 291 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 668 Bugs and issues
- 195 Introduce yourself
- 239 Announcements
- 106 Forum talk
- 404 Relax cafe
PNG & textures in non-RGBA8888 format
I remember a discussion about, but haven't been able to find it, so pardon me for reposting the argument: at the moment, only full-color PNG & textures are supported, but sometimes this can be an overkill. For a recent project, I've had the need to have texture that were large (to look good on Retina), but basically monochrome, so a grayscale format would have been enough. In fact, running the images through ImageOptim gave significant savings (well over 80%), but the resulting files were rejected by Gideros. Thus, the app shipped with assets that appear pretty large, and it would be nice to get some saving if possible (actually, it's Android users that complain most, with their weird distinction between built-in memory and SD card, iPhone's ones don't seem to care).
In that earlier discussion, PVR format was dismissed by Atilim as low quality (still, that would have probably been enough in my case), but other formats (RGBA4444, if I remember correctly) were seen as a possibility.
However, I don't see anything about in the roadmap: am I missing it, or has it such a low priority?
BTW, as we're at it, aren't Bug #95 & Feature #81 the same?
In that earlier discussion, PVR format was dismissed by Atilim as low quality (still, that would have probably been enough in my case), but other formats (RGBA4444, if I remember correctly) were seen as a possibility.
However, I don't see anything about in the roadmap: am I missing it, or has it such a low priority?
BTW, as we're at it, aren't Bug #95 & Feature #81 the same?
Likes: osa
+1 -1 (+1 / -0 )Share on Facebook
Comments
I've already finished the implementation of loading grayscale and palette-based PNGs before this post. It'll be available with the next version. (The new implementation loads all the PNGs here http://www.schaik.com/pngsuite/ without problem)
On the other hand, non-RGBA8888 images will continue to consume memory as if they are RGBA8888. I hope this won't make any trouble on your side.
And let me add 24-bit (RGB888) and 16-bit formats (RGB565, RGBA4444, RGBA5551) to the roadmap (to decrease the texture memory usage)
(Yes #95 and #81 were same, I've deleted #81)
Likes: gorkem, techdojo, phongtt
Yes, I'm aware that reading PNG is not the same than having different texture formats: the "visible" problem, from the user POV, is that, with so many different resolutions, apps look bloated for no particular reason, especially if you're on an old device. Just having the binary more compact could mean something, the user wouldn't suffer much the presence of images he's not able to visualize in the first place!
Likes: atilim