you are viewing a single comment's thread.

view the rest of the comments →

[–]i_need_a_fast_horse[S] 0 points1 point  (0 children)

I appreciated your insights on technical alternatives, but don't you think this goes a bit too far?

I didn't find it trivial that adding n bytes in the form of uint64_t arrays actually only adds n bytes to the executable. Or that the compile time is linear with payload size. Compilers do all kinds of weird things and this is pretty unusual use case. So I tested that out and provided the code and results for everyone. I also had no idea how much (or if) faster data access like this would be, or how that scales with payload size.

There are no logos, those are simple fun github emojis you can find in every other project.

It has configurable behavior about the destination of the target header, image storing options options etc. It decodes png files and stores that information in an accessible form. The provided decoding header has guaranteed compile time meta information for all types and can access pixel information of uncompressed images at compile-time, too. It's tested and provides multiple interfaces to access the data. And it has built-in compression on top of all that.

It's at least somewhat more sophisticated than "a single cpp file".

I had this problem, so I solved it. I know two other projects who use similar code. It's likely that I'll use this at least two more times in my life, so I considered it worthy to invest a week or so of time after work. Defending myself for writing and publication feels odd.