Because my game loads many (300+ ATM, more to come) pictures of 1 to 4 KB each loading times have increased muchly.
If I search for PhysicsFS or physfs the latest threads are from Jan 2014. It makes me think I missed something like maybe store (under Files: https://www.allegro.cc/resource/Libraries/Files).
Is PhysicsFS the way to go? Does that speed up loading resources? is it a heavy weight library? (eg. I don't need its write access to archives).

One problem is that the depicted people cam stand still (20 by 46 pixels) but also crawl (46 by 12) (and run, walk, etc) so in a spritesheet all pics must be the maximum 46 by 46 and I need to calculate new offsets for every one.

( I was typing the above and realize I never thought about spritesheets containing differently sized pics. Like deviding a big bmp into 46 by 46 squares and outline every pic to the topleft. I'd still have to do this for the picture bmp and the transparency info bmp, then covert to png)

There's no way of loading from an archive like a tar? Retaining my pics/hero1 etc structure? The tar (like in WinRar choose 'store' for compression method, i.e. none) will be read fast if files a simply head-to-toe inside it.

Technically you could have a spritesheet with variable sized/positioned images, but you'll need to store an "index" of them somewhere and you'll likely have waste in the image unless you get lucky, engineer it perfectly, or fragment your sprites within it. You can either store the index in the spritesheet itself as garbage data at a predictable position, or probably more easily in a separate custom file. Maintaining the file will likely be a pain though unless you can find a software tool that already meets you requirements. Or you take the time to develop one. Anything is possible. It's just a question of what's the better pay off.

I recently read an older book that said you could store sprite information... inside the bitmap itself. (That may be what Bam is suggesting.) It blew my mind. Basically, you use known colors (pure red, pure cyan, etc) to mark pixel points as "top left of sprite" / "bottom right of sprite", and other necessary features as needed. Then, your sprite parser checks for pixels instead of reading a metadata file. (I use an INI file with other object metadata. But it's quite laborious if you're talking hundreds or thousands of objects!) This method allows the artist to know exactly What-You-See-Is-What-You-Get. No reading position numbers and then writing them into an INI (or worse, source code!).

It's not the best solution for every case. I think if your sprites are ALWAYS a set size, like 32x32, then there's no point in hardcoding every size as if they could be different. And if an artist is copying or moving tiles around, they may forget to move the right "metadata pixels".

But the point is, there's another possible solution I hadn't ever considered.

The only problem there is, then you gotta figure out how to translate a user's actions like dropping pixels, into characters. Otherwise, I think some/many/most graphics formats already contain a metadata table for things like comments, ISO settings, etc.

My example simply had certain pixels mean concrete things. Like, start here, end here. Encoding actual variable data could be tricky.. but it might be possible to do elegantly..

Aaannnnddd... We have a volunteer, everyone! Congratulations to Edgar for stepping up to the plate!

First we should elect a leadership committee and schedule a mandatory brainstorming session.

Start with making a good interface and crappy implementation.

Then someone will be irritated enough to make a better implementation.

I was being sarcastic. This is clearly a Monday project that will go nowhere. Software projects do not materialize out of forum threads. Software projects materialize out of some guy's basement because he needs to do something and couldn't find an existing solution.

Edgar is already committed to Eagle so it's unlikely he has time to spare on this unless it becomes a part of Eagle or he really needs this for a project he's already working on.

The same goes for everybody else. It would be neat to have it, but unless you have a real need to build it right now it's all just smoke and dreams. And it won't be collaborative project until somebody starts something, gets something working, and somebody else finds it easy or necessary to improve it.

Enough planning. Somebody GTFO and build something.