DENTHOR/ASPHYXIA'S VGA TRAINERS FILE PACKING
This trainer is about reading PCX files, file packing, and putting everything into one executable file.
DENTHOR, coder for ... _____ _____ ____ __ __ ___ ___ ___ ___ __ _____ / _ \ / ___> | _ \ | |_| | \ \/ / \ \/ / | | / _ \ | _ | \___ \ | __/ | _ | \ / > < | | | _ | \_/ \_/ <_____/ |__| |__| |__| |__| /__/\__\ |__| \_/ \_/ firstname.lastname@example.org The great South African Demo Team! Contact us for info/code exchange!
Grant Smith, alias Denthor of Asphyxia, wrote up several articles on the creation of demo effects in the 90s. I reproduce them here, as they offer so much insight into the demo scene of the time.
These articles apply some formatting to Denthor's original ASCII files, plus a few typo fixes.
Loading a PCX file
This is actually quite easy. The PCX file is divided into three sections, namely a 128 byte header, a data section, and a 768 byte palette.
You can usually ignore the 128 byte header, but here it is:
That makes 128 bytes.
The palette file, which is 768 bytes, is situated at the very end of the PCX file. The 769’th byte back should be the decimal 12, which indicates that a VGA color palette is to follow.
There is one thing that we have to do to get the palette correct in VGA… the PCX palette values for R,G,B are 0 to 255 respectively. To convert this to our standard (VGA) palette, we must divide the R,G,B values by 4, to get them into a range of 0 to 63.
Actually decoding the image is very simple. Starting after the 128 byte header, we read a byte.
If the top two bits of this byte are not set, we dump the value to the screen.
We check bits as follows:
C0 in hex = 11000000 in binary = 192 in decimal
Let’s look at that more closely…
That means, when represented in bit format, both corresponding bits have to be set to one for the result to be one.
In the above case then, both of the top two bits of temp have to be set for the result to equal
11000000b. If it does not equal that, the top two bits are not both set, and we can put the pixel.
If the top two bits are set, things change. The bottom six bits become a loop counter, which the next byte is repeated.
There is our PCX loader. You will note that by and’ing
$3f; I am and’ing it by
00111111b… in other words, clearing the top two bits.
The sample program has the above in assembler, but it is the same procedure… and you can read the next tutorial for more info on how to code in assembler.
In the sample I assume that the pic is 320x200, with a maximum size of 66,432 bytes.
The question is simple: how do I get all my files into one executable? Having many small data files can start to look unprofessional.
An easy way to have one .exe and one .dat file when dealing with many cels etc. is easy… you would alter your load procedure, which looks as follows:
For one compile you would do this:
From then on, you would do:
This means that instead of five data files, you now have one! You have also stripped the 800 byte cel header too. Note that this will work for any form of data, not just cel files.
The next logical step is to include this data in the .exe file, but the question is how? In an earlier tutorial, I converted my data file to constants and placed it inside my main program. This is not good mainly because of space restrictions … you can only have so many constants, and what if your data file is two megs big?
Attached with this tutorial is a solution. I have written a program that combines your data files with your executable file, no matter how big the data is. The only thing you have to worry about is a small change in your data loading methods. Let’s find out what.
Using the file packer
Normally you would load your data as follows:
Easy, hey? Now, using the file packer, you would change this to:
Not too difficult? Now, this is still using the normal data files on your hard drive. You would then run PACK.EXE, select the program’s .exe as the base, then select “bob.bob”, “den.pcx” and “data.dat”, in order (1, 2, 3). Hit “c” to contine, and it will combine the files. Your programs .exe file will be able to run independently of the separate data files on disk, because the data files are imbedded with the .exe.
Let us take a closer look at the load procedures. Normally a load procedure would look as follows:
In FPack.pas, we do the following:
As you can see, we just have two special cases depending on whether or not the .exe file has been packed yet.
NOTE: After you have packed the file, you CAN NOT pklite it. You can however pklite the .exe_before you run pack.exe … in other words, you cannot use pklite to try pack your data files.
PACK.EXE does have a limitation … you can only pack 24 data files together. If you would like it to do more, mail me … It should be easy to increase the number.
In the sample program, FINAL.EXE is the same as temp.pas, except it has its PCX embedded inside it. I ran pack2.exe, selected final.exe and eye.pcx, hit “C”, and there it was. You will notice that eye.pcx is not included in the directory … it is now part of the exe!
Well, that’s about it for this trainer… next one (as I have mentioned twice already ;) will be on assembler, with a flame routine thrown in.
This tut has been a bit of a departure from normal tuts … aside from the PCX loading routines, the rest has been “non programming” oriented … don’t worry, next week’s one will be back to normal.