ISAWHIM
20-10-2008, 06:39
WARNING: Long winded prelude to the actual content...
Scroll to the second post for the code segment.
What is a CWAD?
C = Compressed
WAD = "Where's All the Data" (Normally uncompressed RAW data used by a CORE program. Popularized by DOOM.)
Actually, a WAD is like a ZIP or RAR file. It is one file that contains many other files. With one small exception, the data is structured with an intent. Images are a block, sounds are a block, animation is a block, levels are a block, objects are a block, monsters are a block, weapons are a block, scripts are a block... etc...
This is stolen from an OLD OLD OLD concept that we normally call a "Database". (Part of the reason ZIP and RAR had a hard time getting patents for the "Stolen Concept". They were limited to "Specific format", and "Processing of data", in the patents.)
Any-who...
I have seen a lot of places where this TYPE/STYLE of structure could play a great role in overall development here with ThinBASIC. Much of the data we use, demands us to organize it, index it, and attempt to ensure it is all unique.
This has led me to come-up with this general structure and concept of the CWAD. (The compressed version, which has obvious gains in this power-of-two expanding world.)
I will use "Graphics" as the first example...
Games which once used only a hand-full of 256x256 graphics, now use thousands of 1024x1024+ graphics, each year was getting exponentially larger. However, we have reached what is called a "Creative edge". Millions of images can not be created by one entity, so now we work in reverse. We are heading back towards the 256x256 graphics, which allows the quantity to grow as we grow. EG, What would have been one large image creating the entire side of a ship. Is now hundreds of images, which we originally used to create the rendered image of the side of the ship. The painted metal, the rusty-holes, the rivet-lines, the stained drip-marks, the dirty scuff-marks of wear, the barnacle patches.
Why are we doing this? Because computers which were once limited to X surfaces (Triangles), are now able to handle 100 times more than they once could. Plus, new "Tricks" have been developed, which reduces the number of actual X surfaces (Triangles), we actually see. This gives us the advantage of using many smaller images to create larger images, as desired. (Like a mini-rendering tool inside of the game.)
For the second example I will use animation...
What was once a simple, push, pull, move, and slide, is now a complex chain of stacked events. When you type on the keyboard, your finger moves up and down and left and right. That is added to the motion of the other fingers, and your wrist. That is added to the motion of your arm as you reach for the far keys. That is added to your eye-motion as you look from screen to keys. That is added to your facial expressions as you squint your eyes, and raise your brow to insight. That is added to the pulsing vein that raises under your skin as you think. That is added to the chest rise and fall as you breath. That is added to the head-tilt which you do, as you contemplate how to finish your paragraph.
Imagine all that done as one long line of code... Now you have to do the next animation, where you get-up for coffee. That could take another day to program, and you never even finished the paragraph.
This is why we use editors. They "Script" animation, as independent blocks of data. That data can be compounded to form one split-second animation, which reacts to each other animations results. You program "Scratch nose", which is an animation of, "Bend finger", and "Raise arm", and "Bend wrist", and "Wiggle finger"... Followed by nothing (Which returns your arm/finger back to the last position, or leads it into a new animation.)
Those individual animations are saved as a script, and those script-animations are saved as a script. And so-on, and so-on... Script on script on script... That is a "Generic" form of manual compression, but the scripts are still long, and can gain from further program compression. One or two scripts is only a couple bytes, but compounded millions of scripts and motions can easily be into the MB reach.
Here is where it becomes an advantage for us.
The program doesn't care that "Bone45" is called, "Right index finger", nor does the viewer. You have to create all these long unique names, which is a task in a task. Or, you could just throw them away, and save hours of wasted time. Since that is what the game does after you wasted hours creating all of them. (Not to mention, you have to creatively craft many conflicts, which throws many standards out the door, or makes them a total non-advantage.)
Now picture this...
You don't code every door and window and wall by hand. You don't track "Floor_Tile_Green_Dirty_Chinese_01.bmp". You don't even know what that image is, until you look at it! (If you had four tiles, it would be possible, but most games have more than four floor styles, each with four floor tile variations, and possibly separate sizes of each.)
What you do, is this. You create "Ship", the name and object is irrelevant. That "Ship" has 45 images, (paint01, paint02, paint03, paint04, deck1, deck2, door1, door2, door3, door4, window1, window2, window3...)
Once you create it, it gets added to the the WAD as, ObjID#7 (I#432,I#434,I#120,I#435,I#436...)
You notice the third image... "paint03" was not a new image, but one that already exists in the WAD, and it was used, as opposed to creating another new image-block. When programming the game, if not using a script, you open the WAD, and see that ObjID#7 is the object you want, or you can actually associate a unique name with that. "Ship", which would return the ID# for use in the game, which is what the game code expects, a model ID#.
Here is where it can get real interesting.
ObjID#7 can be ObjID#2's Model, with ObjID#2's, ObjID#4's, ObjID#7's Images.
Ok, hard to visualize... Model 7 was the same model ship as Model 2, but you just changed images, some which belonged to the WAD model 2 and 4, plus some new images. So, you just created a "Variation" of Model 2, which is ObjectID#7 in the game.
EG, To change the tires on a car should not be a complex in-game task, but this still allows that. You just have to know how many modelID's there are in the WAD, and all your "Custom" styles would be that number + 1, 2, 3, 4. Instant "Unique" control, without funky stacked names, which the game doesn't care about anyways.
You need a crowd with 100 people, all doing separate animations, and having unique bodies, clothing styles, heads, motions... You could set them all up in the WAD, if you want instant random crowd creation. But you would be better using the code to manage those objects. Using the object-parts inside the WAD as your source.
Another advantage is... If you replace/update images or the object or the models... you instantly get notified of a name-conflict, (Which is still irrelevant if you don't use names), and all associated images, objects and models become updated. (Add animations, or user-data to that as well.)
Now... For simple control, and to keep this first release down to a minimum. I am only going to deal with the two item/sections that will possibly be used the most. Since there are only a few "Standard" formats involved, this should be rather easy to launch.
I do expect versions to change, but that should only impact the data-storage, and available output. I do not expect this to be used directly inside of code, as RAW control... Though, it can be, if you reduce it to only the parts you need for your program. (It is my hope, that this eventually turns into a MODULE. For now, it will operate as an INCLUDE or as a separate program.)
Scroll to the second post for the code segment.
What is a CWAD?
C = Compressed
WAD = "Where's All the Data" (Normally uncompressed RAW data used by a CORE program. Popularized by DOOM.)
Actually, a WAD is like a ZIP or RAR file. It is one file that contains many other files. With one small exception, the data is structured with an intent. Images are a block, sounds are a block, animation is a block, levels are a block, objects are a block, monsters are a block, weapons are a block, scripts are a block... etc...
This is stolen from an OLD OLD OLD concept that we normally call a "Database". (Part of the reason ZIP and RAR had a hard time getting patents for the "Stolen Concept". They were limited to "Specific format", and "Processing of data", in the patents.)
Any-who...
I have seen a lot of places where this TYPE/STYLE of structure could play a great role in overall development here with ThinBASIC. Much of the data we use, demands us to organize it, index it, and attempt to ensure it is all unique.
This has led me to come-up with this general structure and concept of the CWAD. (The compressed version, which has obvious gains in this power-of-two expanding world.)
I will use "Graphics" as the first example...
Games which once used only a hand-full of 256x256 graphics, now use thousands of 1024x1024+ graphics, each year was getting exponentially larger. However, we have reached what is called a "Creative edge". Millions of images can not be created by one entity, so now we work in reverse. We are heading back towards the 256x256 graphics, which allows the quantity to grow as we grow. EG, What would have been one large image creating the entire side of a ship. Is now hundreds of images, which we originally used to create the rendered image of the side of the ship. The painted metal, the rusty-holes, the rivet-lines, the stained drip-marks, the dirty scuff-marks of wear, the barnacle patches.
Why are we doing this? Because computers which were once limited to X surfaces (Triangles), are now able to handle 100 times more than they once could. Plus, new "Tricks" have been developed, which reduces the number of actual X surfaces (Triangles), we actually see. This gives us the advantage of using many smaller images to create larger images, as desired. (Like a mini-rendering tool inside of the game.)
For the second example I will use animation...
What was once a simple, push, pull, move, and slide, is now a complex chain of stacked events. When you type on the keyboard, your finger moves up and down and left and right. That is added to the motion of the other fingers, and your wrist. That is added to the motion of your arm as you reach for the far keys. That is added to your eye-motion as you look from screen to keys. That is added to your facial expressions as you squint your eyes, and raise your brow to insight. That is added to the pulsing vein that raises under your skin as you think. That is added to the chest rise and fall as you breath. That is added to the head-tilt which you do, as you contemplate how to finish your paragraph.
Imagine all that done as one long line of code... Now you have to do the next animation, where you get-up for coffee. That could take another day to program, and you never even finished the paragraph.
This is why we use editors. They "Script" animation, as independent blocks of data. That data can be compounded to form one split-second animation, which reacts to each other animations results. You program "Scratch nose", which is an animation of, "Bend finger", and "Raise arm", and "Bend wrist", and "Wiggle finger"... Followed by nothing (Which returns your arm/finger back to the last position, or leads it into a new animation.)
Those individual animations are saved as a script, and those script-animations are saved as a script. And so-on, and so-on... Script on script on script... That is a "Generic" form of manual compression, but the scripts are still long, and can gain from further program compression. One or two scripts is only a couple bytes, but compounded millions of scripts and motions can easily be into the MB reach.
Here is where it becomes an advantage for us.
The program doesn't care that "Bone45" is called, "Right index finger", nor does the viewer. You have to create all these long unique names, which is a task in a task. Or, you could just throw them away, and save hours of wasted time. Since that is what the game does after you wasted hours creating all of them. (Not to mention, you have to creatively craft many conflicts, which throws many standards out the door, or makes them a total non-advantage.)
Now picture this...
You don't code every door and window and wall by hand. You don't track "Floor_Tile_Green_Dirty_Chinese_01.bmp". You don't even know what that image is, until you look at it! (If you had four tiles, it would be possible, but most games have more than four floor styles, each with four floor tile variations, and possibly separate sizes of each.)
What you do, is this. You create "Ship", the name and object is irrelevant. That "Ship" has 45 images, (paint01, paint02, paint03, paint04, deck1, deck2, door1, door2, door3, door4, window1, window2, window3...)
Once you create it, it gets added to the the WAD as, ObjID#7 (I#432,I#434,I#120,I#435,I#436...)
You notice the third image... "paint03" was not a new image, but one that already exists in the WAD, and it was used, as opposed to creating another new image-block. When programming the game, if not using a script, you open the WAD, and see that ObjID#7 is the object you want, or you can actually associate a unique name with that. "Ship", which would return the ID# for use in the game, which is what the game code expects, a model ID#.
Here is where it can get real interesting.
ObjID#7 can be ObjID#2's Model, with ObjID#2's, ObjID#4's, ObjID#7's Images.
Ok, hard to visualize... Model 7 was the same model ship as Model 2, but you just changed images, some which belonged to the WAD model 2 and 4, plus some new images. So, you just created a "Variation" of Model 2, which is ObjectID#7 in the game.
EG, To change the tires on a car should not be a complex in-game task, but this still allows that. You just have to know how many modelID's there are in the WAD, and all your "Custom" styles would be that number + 1, 2, 3, 4. Instant "Unique" control, without funky stacked names, which the game doesn't care about anyways.
You need a crowd with 100 people, all doing separate animations, and having unique bodies, clothing styles, heads, motions... You could set them all up in the WAD, if you want instant random crowd creation. But you would be better using the code to manage those objects. Using the object-parts inside the WAD as your source.
Another advantage is... If you replace/update images or the object or the models... you instantly get notified of a name-conflict, (Which is still irrelevant if you don't use names), and all associated images, objects and models become updated. (Add animations, or user-data to that as well.)
Now... For simple control, and to keep this first release down to a minimum. I am only going to deal with the two item/sections that will possibly be used the most. Since there are only a few "Standard" formats involved, this should be rather easy to launch.
I do expect versions to change, but that should only impact the data-storage, and available output. I do not expect this to be used directly inside of code, as RAW control... Though, it can be, if you reduce it to only the parts you need for your program. (It is my hope, that this eventually turns into a MODULE. For now, it will operate as an INCLUDE or as a separate program.)