CWAD (AKA: Compressed, Where's All the Data)

[ISAWHIM]

Ok, I have the CWAD shell finished and the three primary sets of code which handle the creation of "New" CWAD files. It does not actually create the file yet, as I am still playing in memory.

I have sliced it up into two parts. The shell is as dumb as a rock, and it does whatever you tell it to do. It only checks to see that you are feeding it valid info, and if so, it uses it to create the indexes. (It has no idea what "You" are actually doing on your side of the code.)

For "Your" side, and by that, I mean "My side", for now...

You have to use the index commands to register your data, once you have formatted it to taste. These are the "Type codes" that go with the "Type names" which are used in the index files. Since it is impossible for the shell CWAD to guess how you handle data, it expects that you are giving it the correct data that you want indexed.

Sounds complex, but that is the job of the "Type" to use the data as it needs. It is the CWAD's job to tell the user where the data is located, and to extract it, and nothing more. The CWAD uses a generic extraction if there is no TYPE functions that exist for the TYPE NAME in the CWAD. This allows anyone to use any TYPE code they wish, or use none, and simply ignore that useless data in the CWAD. (The purpose of the index, is to stop the file from breaking if there is one missing TYPE function. This also allows ANY FUNCTION to pull that RAW DATA, for use in code.)

Point being... If you have a CWAD which was created with SOUND and IMAGES and MODELS, but you want to use that CWAD in another program, one without SOUND... The CWAD can still see past the SOUND, and if this is being edited, the SOUND sections can be removed, and the file shortened to only relevant data.

I have setup a "Manual" index... now I have to program the part which creates the matching data, that I told the index I had. These "Chunks" do get passed to the CWAD, as they match the index, and can be confirmed. But the CWAD has no idea if the chunk actually has SOUND or valid SOUND or an IMAGE... That is the "You" side. But it will push it and move it and delete it as desired, while you update the index with new info/settings.

Again, I am playing with the ImageThumb version, since that is simple to manage.

I will post the code tonight after work. (Though, it only contains the test creation, and little protection to invalid data input. It will just crash silently if incorrect data is used.)

Is there an image-control, or would I just draw on a window? I suppose I could load a TBGL screen and draw on squares.

[ISAWHIM]

Ok, here is the "Reduced comment" version... LOL, I had more comments than code.

We need a "Strip Comments" option.

Ok, I included the mini-manager, which doesn't do anything other than test the file. The file is an include, and will not run alone. All "Packs" will be includes also. The CWAD will check if all require "Pack" functions exist... otherwise it will just spit-out the data as RAW data. (It will also send a code to let you know if a "Pack" registration is missing.)

The "Test" is a "Fred" pack test. There is no "Fred" pack... but you can create one if you want!

This checks for "Fred"... Can't find it... So it gives you an alternative. "Use (GENERIC)?"

If you say yes... You now have a GENERIC pack setup in the CWAD. (Code stops there.)

If you say no... It indicates that no action will be taken, because no valid action was supplied. (You have to program a "Fred" pack control, or find the missing "Fred" pack controller, or live with a GENERIC pack setup.)

Forgive the sloppy code... I still have dead commands that I was testing, and variables that will not be used. But I will not have a replacement until I get one of the NON-GENERIC packs developed. (The GENERIC pack is almost complete.)

[ISAWHIM]

Just finished the ability to add raw data, with the file-name or other name for identification.

Technically, I just completed making a ZIP file format. (Almost a CWAD! I can smell it, it is so close!... Wait, that was my last brain-cell frying.)

I will post that code tonight, after I had time to humanize it, and reduce it a little more. It is SOOO not standard in any way. Except for the function-names. But now I know which variables I no longer need.

All comments and stupid warnings will be removed also. They will be replaced with some visual "Tree" structure to indicate what is being created. Once the file can be written, it will be time to write the READ code. (That should be a lot easier to handle, since it is all literal, and only reads data as it needs it.)

Seems that "MSGBOX" does not like to display raw compressed text. LOL... Thought my code was broken... Dumped it to a text-file and all is there. Even looks like a ZIP inside.

[ISAWHIM]

Ok, here is a slightly better example of it in action...

This has a folder with 8 (512x512) full-color BMP images. (About 6.5MB)
Reduces down to about 4.5MB... Using ZIP. (Standard ZIP output.)

Nothing special, but the 8 (2048x204 images went from 96MB down to about 45MB.

Again, same with a normal ZIP.

However... When I converted them to 90% quality JPG, then saved them... Turning them back into BMP after unzipping... The reduction with nearly no quality loss was closer to 60% compression.

Anywho... The program has two tests... one with the images, and one with simple text-strings. Feel free to add your own file-paths and names in the manager-setup code. You can compound the calls over and over. (Though the pop-up message-boxes might bug you a bit. The last button will output the final result of all the buttons you press.)

For a speed test... throw in a loop, and comment out all the message warnings. Works quite quick, but it is no speed daemon. (Would be faster if I removed all the checking code, and use more GLOBALS.)

[ErosOlmi]

Jason,

this is a very interesting project and seems perfect for a new thinBasic module where code would be compiled and speed would be 1000 times faster than pure thinBasic code.

Eros

[ISAWHIM]

Eventually, I hope... but not until the "Generic" part is finished. (The rest is all conditional after that.)

I am having trouble attempting to create PARENT/CHILD winows in windows... Like a paint-program would have. If I can't figure it out. I will reduce it to panel-views. (This is for the CWAD-Manager part, not the actual CWAD part.)

I am starting to think that a single window, with zones, may be the better alternative. There is sample code for that.