AutoHotkey Community

[Sarah]

[Joy2DWorld]

[majkinetor]

Yes, exactly.
I would go ahead and create file system structure if possible similar to ScriptMerge.

Acctually, the concept generaly doesn't have so much benefits unless something similar to RAM drives is used.

To clearify this: lets say you have several files each of differnet type, so you may have some pictures, some sounds, some arbitrary binary data, and in most of the time it will need to have location on the HD, i.e. path that it can be accessed. But then to use resource.ahk you would need to unpack it in temporrary folder (existing solution for bitmaps is clearly not enough) which defets the purpose great deal. I would like to use resource.ahk as a file system, without temporary files.

While this is possible to do with something similar to RAM drives, or maybe even virtual folders (maybe I say), I am not sure how it can be done nor how much complexity it involves.

Actually, this would be abstraction of ScriptMerge. It would let you include arbitrary files into your ahk file, and use the resources in memory. It would also be possible to unpack everything back if you want to speed up things.

Would be very valuable IMO.
_________________

[Sarah]

Trying to stay on topic here --- but can this actually be used to embed a .wav file, for instance in my AHK program, and play such file runtime? If so, how would I approach that code wise? Thank you so much for this thread Azerty, Majkinetor, to make me understand

I guess what I am asking is..... can a .WAV be referenced like a Image... without regenerating it to a file which would be useless to me but useful in the sense you would be sort of encapsulating all of the data before running final product. Best wishes, Sarah.

i.e.

IMAGES > PNG, GIF, JPG >>> Display directly from binary without creating File

.EXE, other assets must be regenerated to a file

.WAVE??? sounds??? can they be just played directly from binary or am I way off base?

[Laszlo]

I wonder… If you embed hex encoded data in your AHK script instead of ascii85, when you compile it, the data gets compressed. Will it result in similar code sizes? Ascii85 could still have an advantage: less temporary memory.

[Azerty]

sarah : using PlaySound() API through DllCall() should do the trick using SND_MEMORY flag. See here. As for JPeG, BMP & al, browsing through the forum should help you find the trick (look at samples like hardcopy scripts, for instance, to see how to manipulate images in memory).

Laszlo : it should be tested, since ASCII (charset of 85 chars) is also compressible (though might be slightly less than pure hexa). It probably depends on the complexity of the source binary data, and results might differ from one test to another.

[majkinetor]

[Azerty]

Majkinetor : yes, for now I'm not directly interested in this problem, since I've got my own, so I'm just trying to give useful clues to Sarah to help him (or perhaps her ?, sorry if I'm mistaken, you'll correct me in your next answer) find his way with the direct question he asks. As for most people here, I try to answer our direct needs and offer our solutions to the community

As for a general solution, I'm no expert in MM questions, but it looks to me like the only generic interface is MCI, which does not offer direct in-memory handling for now from what's I've rapidly browsed in MSDN.

Nonetheless, if you offer us a generic solution to handle in-memory MM data, we'll all be glad to use the library you might provide us if you've got a more profound interest in this precise topic.