Thinking about integrating, questions

[ggcrunchy]

Hi. Apologies if this isn't properly an issue; I'm not 100% sure what to remove from your posted e-mail, if that would have been better.

I've been using stb_image / stb_image_write for a while now (as well as some FreeImagePlus stuff, now on hold) and recently discovered this project, which looks like it would enhance and streamline what I've already done, once I work out a decent Lua signature over it. (Ditto for bundle. You've got lots of interesting repositories. :smile: )

Anyhow, some questions:

• Any surprises on mobile? In particular, I'm stuck with libstdc++ on iPhone at the moment, which has been a world of hurt lately trying to use C++11, so I'm curious if you've run afoul of anything there.

• How are GIFs handled, or do we only get the first frame? (I see a d but figured it was for mipmaps.) I've been using this and this--each slightly modified to also work on memory buffers--for reading and writing respectively and am wondering if I should just leave those intact. In regard to reading, I suppose I'd also need to rebuild the amalgamation to expose a few things.

• If you know, are any of the underlying libraries modifying their globals? In my own case I threw some thread-local macros around some of the stb stuff just in case I wanted to mess around with them, so I'm wondering.

Any input appreciated, and sorry for the hassle!

[r-lyeh-archived]

Hello there

Thanks for the kind words :)

• It has been used in commercial Android games with success. It depends on the image encoders/decoders you are going to use though, as they come from diverse/different sources.

• GIF support in stb_image is very basic. I have a version somewhere that would load a 200x100 26-framed GIF as a vertical 200x2600 static image (26 frames on top of each other). Dunno if that would be enough for your case.

• Ah, that is controversial. The libraries got globals for sure, and I havent checked about custom malloc/free scenarios either. Additionally, the embedded libraries are mostly designed for single thread scenarios (it is ok if you mutex the spot library in a wrapper tough).

Hope it helps.

PS: tip: use spot in a tool to convert your assets to a native format of your own, then use your own custom loader in a game/engine :)

[ggcrunchy]

Great, thanks!

No need to go hunting for the GIF stuff. I do use stb_image loading by default, so it sounds like my current setup is fine, though it might take some work to make everything consistent.

On the threading thing, I don't imagine super-high contention, but rather occasional streaming situations with a couple parallel loads. Anyhow, I'm not above tinkering. :smiley: I've been exploring the code a bit and it looks like I should be able to make any adjustments if the need arises.

This should be going into a (Corona SDK) plugin, so I hope it does turn into tools!

[r-lyeh-archived]

Great, let me know if you have any issues :)

[ggcrunchy]

Okay, I've got it sort of integrated, though it's likely to be a while before everything's nice and smooth. Docs are mostly here and here, along with a few factory functions like this one. Let me know if anything seems in need of change. I elided some of the commentary that seemed irrelevant on the Lua end of things.

For the most part it's gone well, but iOS was indeed a pain. :frowning: I used Boost and an in-between namespace to bring most things into conformity, but am still experiencing some weird interactions with threads / futures / unique_ptrs / move semantics that mean I don't have ETC and FLIF up yet. In one case this is with the m_work section, where an iOS-specific libdispatch implementation would probably be a quick fix. I'm not sure how important the unique_ptr semantics are in the rest. (By the looks of it, some of it is just for easy cleanup, while others seem to be changing hands a lot.)

Let me know if you want to see any of the changes. It's all pretty mechanical.

I'm curious about a few things that diverge from stb_image and stb_image_write, since at the moment the plugin now has two ways to do saving and loading, with considerable implementation overlap.

• Is there any reason HDR isn't available in Spot to encode / save?
• Along the same lines, a few formats can be saved but not encoded. Any reason?
• Do you have any code to rewrite stb_info() or stb_info_from_memory() using the info() call from Spot? I can probably work this one out.

Anyhow, if those are just oversights rather than implementation hurdles I might add the other formats in, then swap Spot into the parts currently using stock stb.

No rush on answers. I need to take a coding break for a few days, between this and other things. :smile:

[r-lyeh-archived]

1. Aha nice effort you put there. How does it feel controlling the library from Lua? Any code samples?

2. ETC and FLIF are tricky indeed. Current ETCpak library relies on threading/C++11 a lot and FLIF canonical source decoder is someway dirty and error prone. Maybe upgrading both libraries to latest could help a little before putting the hands in, as I have not followed their development lately.

3. Sure why not. However, I do not like to diverge too much from main repositories to avoid maintaining a completely different parallel world. But it is true that many times you just send PRs that are never accepted or commented at all. So in the end you have to maintain those changes for ages. Pity.

4. I add things on demand so maybe I have missed a few things :)

• HDR: It is in the TODO list. Never had time for it. PRs are welcome of course! O:)
• Probably because the native library works only with FILE* and/or I missed that one O:) I think you mean DDS/TGA/BMP right? All of them should be doable AFAIK. PRs are welcome too! :)
• Nope, what's the use for it? Any example?

5. I wont be touching the library for the next few weeks. So feel free to tweak and fix things until satisfied then submit as many PRs as needed. Even if I have the philosophy of merging PRs as they come, we can discuss each PR separately.

Merry xmas :) :christmas_tree: :santa: :gift:

[ggcrunchy]

Merry Christmas to you as well! :smile: (And thanks to my delay, happy new year.)

On #1. So far it feels nice. I've been doing some other things with vector so it's been pretty natural. I have some other things aimed at multithreaded memory blobs with this same representation, where it feels like a natural fit.

It might take me a while (maybe even a few weeks), but I'll try to get back to you on all of this. (So no worries on the delay on #5, as it's mutual!)

#2 Okay, great. ETC I think should be a fairly easy fix. As for FLIF, we'll see. :smile:

On #3, I don't think you should worry too much. I'm stuck with the iOS dependencies for now, but I'm not sure how long they'll stay. I'm all set to abandon this "old" iOS stuff as fast as I can (Apple claims it's deprecated as of a recent XCode; I don't know what that will amount to in practice), but of course even lingering in a pull request it might be useful to somebody.

On #4, it sounds, then, like stuff you just didn't get to. As for info(), I'm not even sure how much of a win it might be (would have to time it). The only case I have in mind is where one has a list of files that got enumerated in a list, and by clicking on one you get told some details about them. Hardly urgent.