Offer to save small images in the code

[FellippeHeitor]

Using Dav's BIN2BAS, small images can be stored in the .frm file allowing for more portability.

[FellippeHeitor]

Increase in file size may be a deal breaker here. Still under analysis.

[FellippeHeitor]

Nah.

[callowaysutton]

What about saving images in base 64 or something? I know a lot of websites are starting to do this

[FellippeHeitor]

That was kind of the plan... It's been postponed for so long now that it may become a project in itself eventually, like an extension to InForm. One day.

[callowaysutton]

That was kind of the plan... It's been postponed for so long now that it may become a project in itself eventually, like an extension to InForm. One day.

A modding/extensions api sounds cool, would it be something like changing the theme file?

[FellippeHeitor]

Eventually. More like the way I currently have animated GIFs as an extension.. The editor has to know about it, but the final user project can simply remove the $include line and all traces are gone.

[FellippeHeitor]

Turns out that with _INFLATE$() and _DEFLATE$() in the upcoming version of QB64, this could eventually become a thing again.

[callowaysutton]

Would the deflated files be stored in code and then put into a temporary directory when inflated?

[FellippeHeitor]

I'm thinking the new compression features will be useful just to make the stored data smaller really, but the intention is to store a memory dump, as I currently do with InForm. All the image data in xp.uitheme was generated from the decoded version in memory after _LOADIMAGE, so that I don't need to dump it to disk and reload, but instead just inject it into memory again at startup. The difference is that data will occupy much less space.

Currently, it's basically like this: load an image, grab its raw data with _MEMIMAGE, convert to a "readable form" (right now using Dav's BIN2BAS utility) and store that in the BAS file. Then, at runtime, the stored data gets "binarized" again and injected into memory.

The idea is to: load an image, grab raw data with _MEMIMAGE, _DEFLATE$() it, convert to "readable form" (with BASE64 this time - much more efficient as local tests have proven) and store that in the BAS file. Then, at runtime, the stored data gets again "binarized", _INFLATED$() and injected into memory.

Sounds like more steps, but the drop in storage will sure make up for it.

[FellippeHeitor]

Turns out compressing a binary format will provide very little compression, so we go back to the initial deal breaker.