recursive zip files (and timelineFX)
BlitzMax Forums/BlitzMax Programming/recursive zip files (and timelineFX)
| ||
| I'd like to recursively extract zip-files into memory but I'm not too successful yet, probably because the TStream-concept is a bit new to me. The root of the problem is that I'd like to embed a timelineFX effect library that also uses gmans zip-engine into another zip for the asset. Problem is due to both timelineFX and gman zip expects a filename rather than a memory stream to load from. I suspect I have to modify the zip-engine and timeline FX to be able to load from tstreams? ....and furthermore I am just realizing that I don't have the skill to change the zip-engine to cope with this =) |
| ||
| did you hear about koriolis.zipstream? I do not know, whether this helps you... With this module it is possible to combine includes files and zip in streams: Picture=Loadimage("Incbin::Zip:://image.png"). |
| ||
| you would have to modify gmains module or the general zip module behavior to support streams isntead of pure filenames |
| ||
| I've lookad at koriolis thanx - but still similar issue for me. The problem for me in gman is that it's using all fancy stuff with byte pointers and weird streams so I'll probably just have to keep my assets outside instead. If anyone with mad skills out there can help out with a modification I'd be very thankful =) |
| ||
| That could be quite tricky :) You could extract the file to disk to a temp folder first, and then load from there, cleaning up after. But I guess that is a bit messy... |
| ||
| If anyone with mad skills out there can help out with a modification I'd be very thankful =) why not go to the source? :) not saying i have mad skills, but ill take a look tonight in regards to loading from a memory stream in ZipEngine. the issue is really the underlying library used to work with zips. its current interface is based on opening a file from a path. as Pete pointed out you could extract to temp files to do the recursion so if all else fails i may be able to make a clean version based on that concept. would definitely take less memory. still, i think there is hope in the underlying library. there is really only one part that deals with opening a file and from that point on it reads bytes from a byte stream. there is also a way to provide a different file open function to provide that stream. bottom line there are options making this concept feasable... and this may be a neat feature to have added :) |
   |