@3 Getting the most out of your disk space - By Andy Smith ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @2 Not for beginners ~~~~~~~~~~~~~~~~~@1 To begin with I'll get one thing straight. This tutorial is not for beginners as it assumes that you know how to open screens, load IFF pictures, and pack images. If you don't know how to do this, then stop reading now and learn how to do it from your AMOS manual. Alternatively, you could get the Absolute Beginners guide to AMOS, see the F1 Products article for more details. @3 I've started so I won't finish ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~@1 Being a games programmer isn't easy, as many have found out. Most projects are started but never finished. People get bored very easily and get bogged down. I'm sure most budding games programmers would agree that it is the games graphics that have made them give up. As you all know, graphics just eat up memory and disk space so I'll show you how to overcome these problems. @3 The most amazing intro ever! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @1 Okay then, imagine a scenario where you've just finished the most amazing title sequence ever produced. The graphics are absolutely amazing and the music makes people get up and dance. You combine your game and title sequence together. Then you copy the result of all your sweat and hard work onto a floppy disk. Then disaster strikes! 'Sorry, there is not enough disk space left on that disk, ha ha ha!'. You feel as if that requester is laughing at you. At this time, you are probably feeling a little annoyed, so what do you do? Do you complain at how crap Amigas are and say something along the lines of 'that doesn't happen on a PC'? If you do then you are very sad to even think of using a PC, otherwise, read on and you might just learn something. @3 How do they do that? ~~~~~~~~~~~~~~~~~~~~ @1 Turrican 2, on the Amiga, is one of the best games around in my opinion. The graphics are excellent, the music is extremely atmospheric, the levels are absolutely huge and it's a dream to play, and it all fits on one disk, how do they do that? They cheat!Seriously though, commercial games programmers kick out the operating system so their games run quicker (and become incompatible with other Amigas if they're not careful). Do they use standard AmigaDOS formatted disks.Do they heck! There's two reasons for doing this. Firstly, they can fit a lot more on a disk if they do this and it also helps to stop people making copies of original games (which is illegal) although cracking groups take out the copy protection and distribute the unprotected versions. These pirate copies usually find their way into kids' games collections, robbing software houses of their income. As we're only AMOS programmers, it is very doubtful that we could write our own disk format, so that's that idea out the window. @3 Getting a bit more ~~~~~~~~~~~~~~~~~~ @1 When most users want to format a disk, they shove a disk into the internal drive, click on the disk's icon, and select 'format' from the Workbench menus. But do you know what file- system your disk is getting formatted under? If you are formatting your disks using the method I mentioned, then your disk is getting formatted under something called OFS. This stands for Old File System. This allows your disks to hold around 836k of data, and is horribly slow as well. It was invented when Noah's Ark was being built so it really ought to be phased out.If you're using Workbench 1.3 or higher, then you can use FFS, which stands for Fast File System. It's great on Workbench 2.0 machines but still horribly slow on anything less. This filing system allows you to store around 879k of data. Although this might not seem like much more, this 43k can be the difference between that brill intro fitting and not fitting on your disk. So how do you use this excellent filing system, for a start, you will need to open the CLI or Shell. Stick a blank disk into the internal drive (make sure it's blank) and type the following: format drive df0: name AMOSZine noicons ffs | | Make sure that you don't miss this off.If you do, then your disk will be formatted under OFS. Hopefully, that command should work on most Amigas. If it doesn't, try removing the 'noicons' parameter. What the noicons parameter does is tell AmigaDOS NOT to put a trashcan onto the disk. That should save a few bytes at the very least. @3 Getting a lot more ~~~~~~~~~~~~~~~~~~ @1 That last technique should save you a bit of space, but if your files are made smaller, then you can fit even more onto a disk. There are several different ways of saving out your pictures and different file formats can make a big difference to the size of the file. I took a lo-res (320x256) EHB (64 colour) image and saved it out using DPaint. I then converted it into 4 different file formats. My results are recorded in the table which follows: @3 Format and program used | Size of File | Size after PP ---------------------------------------------------------------- DPaint IFF | 40744| 30368 AMOS IFF compressed | 40572| 30376 AMOS IFF uncompressed | 61626| 28992 ABK picture | 30660| 22896 Squashed ABK picture * | 26808| Can't crunch! * This file was created by using my squashing program.It is called Squash.AMOS and is fully commented. See 'What, no Powerpacker!' section for use on Squash and Unsquash commands. @1 I think this table needs a little explanation.The column that reads 'Size after PP' means the size of the file after it has been compressed with PowerPacker. Let us ignore the bottom format for the time being and concentrate more on the IFF files. The AMOS IFF files were created by loading the picture that I saved from DPaint into AMOS using the following line: Load Iff "nameofpicture.iff" Then to save it back out from AMOS as a compressed IFF image, I used the following line: Save Iff "nameofpicture.iff",1 To save out the uncompressed image, place a zero at the end of line instead of the 1.I'm not sure what the point is of saving an image out as an uncompressed IFF, but they seem to compress better than the other IFFs when PowerPacker is used. As you may have noticed, the image saved out as an AMOS IFF compressed image, is actually smaller than the one saved out with DPaint. Even so, this compressed image loads fine into DPaint which is pretty weird. Last but not least, we come to the ABK image. As you can see from the table, it is half the size of the uncompressed IFF image, and a considerable amount less than the other formats. Although when it's PowerPacked it doesn't gain a lot of bytes, it is still the smallest file out of all the formats. @3 Using your new knowledge ~~~~~~~~~~~~~~~~~~~~~~~~ @1 If you're going to write a game, then the ABK image format is the best one to use, for obvious reasons. But what was the point in showing the size of the files after they had been compressed with Powerpacker. You can't load powerpacked files into a memory bank in AMOS Classic can you? No you can't, but a small program was given away on Amoszine Issue #0 called Powerpacker Patcher. Every time a file is opened in any program, PowerPacker Patcher will intercept this file, check if it is powerpacked, and decrunch it. This means that AMOS Classic can now load crunched images, which is very helpful. Now would-be games programmers can fit more flash graphics onto one disk. If you're an AMOS Pro user, and you also have the Professional Compiler, then you can use two new commands called 'Ppload' and 'Ppsave'. These commands allow you to crunch and decrunch ABK files, and this will rid the need for Powerpacker Patcher. @3 Professionals only! ~~~~~~~~~~~~~~~~~~~ @1 What I'm going to show you, is how to compress and decompress a file within AMOS Professional using the new Compiler extension commands. Obviously, you'll need to be an AMOSPro user. Also, you'll need the file 'powerpacker.library' in the libs directory of your boot disk. Right then, first I'll show you how to compress an ABK picture file using these wonderful new commands. · Load AMOS Professional if it is not already loaded and go into direct mode. · Load a picture onto the current screen. It can either be an IFF image, or an ABK picture, it doesn't really matter. · If you've loaded an IFF image, then pack it into bank 15 using the Spack command. If you've followed all those steps then you are now ready to do some crunching. The Ppsave command is used to do this. The command looks like this: Ppsave "filename",bank,efficiency The bank parameter, is the memory bank you want compressing, so you would replace that with 15 (if you followed the steps above). The efficiency parameter can take one of five values which are listed below: 0 Fast 1 Mediocre 2 Good 3 Very Good 4 Best If you use 0 for the efficiency parameter, then the compression would be quite poor, but it would compress extremely quickly. If you used 4 however, then the best compression would be used but it could take a long while to compress. You would have to decide for yourself which compression rate you want to use in your games. You may want to make more space for your game on a disk, so you would probably use the best compression rate, but then people may complain that it takes too long to load. You will have to achieve a balance between speed and compression rate, and you will only do that by experimenting. · Type the following (make sure you have a disk in the internal drive) : Ppsave "df0:piccy.pp",15,4 Depending on the size of the image i.e. a greater number of colours and resolution, the files will take longer to compress. When the file has been compressed, it will be saved off to disk. Compressing the file is all well and good, but you need to decompress the file as well. The Ppload command achieves this. Ppload "df0:piccy.pp",15 If you type that line in direct mode, the file that you compressed, piccy.pp, will be loaded into memory bank 15 and decompressed. You can now unpack the image as normal using the Unpack command. Load the file 'Powerpacker.AMOS' for an instant demonstration on these powerful commands. @3 What, no Powerpacker? ~~~~~~~~~~~~~~~~~~~~~ @1 What! You don't own the Powerpacker library, where have you been the past few years? It's no problem if you don't own this wonderful library, the AMOSPro Compiler offers yet more compression commands. They are actually functions, which means they return a value. These two new commands are called 'Squash' and 'Unsquash' and are used to compress areas of memory, but with a bit of peeking and poking around in memory, we can get it to do very much the same as the Ppload and Ppsave commands. The thought of messing around in memory probably sends shivers down peoples spines, but it really is dead easy (by the way, I lied about peeking and poking, we won't touch the Peek and Poke commands). The Squash command is used as follows: L=Squash(Address,Length,Flag,Ahead,Colour) Address contains the start address of the data to be compressed. So if you wanted to compress bank 15, you would use Start(15) which returns the start address of bank 15. Length would be the size of the data to squash, so you could use Length(15) to return the size of the whole bank, effectively telling the squasher to squash the entire bank. If Flag is set to 0, then the compression is set to SLOW mode. Anything else will engage FAST mode. You can only use FAST mode if you have enough memory. If you don't, then SLOW mode will automatically be used. The higher the value in 'Ahead', the better compression. The highest value you can use is 4095 (NOT 4096 as it states in the manual. 4096 throws up an error!). The lowest value is 256, a useless compression ratio but very fast. Colour is the colour index number you wish to flash while it is squashing the data. Completely pointless to be honest. If the squash command is successful, then the L variable will contain the size of the squashed data. The command to unsquash data is (cue drumroll): L=Unsquash(Address,Length) Address is the start address of the data to be decompressed. Length is the number of bytes to be decompressed. As with the Squash command, the L variable will contain the size of the data after it has been decompressed. Of course, you don't have to use L as a variable, it can be anything you want. For an instant demonstration of these commands, load the file 'Squash.AMOS' into AMOSPro now. The program is fully commented. Please feel free to use the techniques in your own programs. @3 Writing your own routines ~~~~~~~~~~~~~~~~~~~~~~~~~ @1 The compression commands I've covered are extremely useful, but wouldn't it be nice if you could write your own routines. These commands are written using very complex compression algorithms so I doubt whether most AMOS programmers could actually write them into their programs. There's a very simple method however, although it doesn't offer great compression it DOES work. The theory is based around pictures, but it works on any file. Say you have written your own routines to save pictures. Your program scans each pixel and writes the colour value into a file. By colour value I don't mean the RGB value, just the index number of the colour in the palette. This means the actual colour palette is not saved with the file. If the picture has the dimension of 320x256 then the file will be exactly 81922 bytes long. I know this because I have tried it. This is rather big for a picture so the best thing is to employ compression as it saves out the picture. What you do is the following: If there is a row of 4 or more pixels the SAME colour then you write a control code into the file e.g. 255 or $FF in hex. Next, you write the actual colour index value.So if the colour was 6, then 06 as a byte would get written into the file. Next, the amount of pixels would get written. So if there was a row of 8 pixels with a colour index value of 6, then the length would be written into the file, which is 8. The file would now contain the following bytes: (In denary) 255 6 8 (In hex) FF 06 08 | | | Control Code Colour number Length What happens if there is less than 4 pixels which have the same colour? Then no control code and length are written into the file. All that is written is the colour index values.So if there were 3 pixels with a colour of 9, then the following would get written into the file: (In denary) 9 9 9 (In hex) 09 09 09 | | | Colour numberColour numberColour number Time for an example. The following are the hex values of an example file. The first example is without compression, the second with. @3 Without compression ~~~~~~~~~~~~~~~~~~~ @1 09 07 05 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0A 01 04 06 06 06 06 02 Size of file (in bytes) : 21 @3 With compression ~~~~~~~~~~~~~~~~ @1 *1 *2 *3 *1 *2 *3 09 07 05 FF 0B 10 0A 01 04 FF 06 04 02 Size of file (in bytes) : 13 *1 = Control code *2 = Colour value *3 = Length in bytes What you must remember if you use this system is that only bytes can be written into the file. This means that values over 255 can't be used. Also, this system counts on the fact that a colour index value can never reach 255, due to the limitations of AMOS and pre-AGA Amigas. As the maximum number of colours we can use is 64, there is no chance of reaching 255. Even if AMOS could access the AGA palette, 255 is used as the control code, so that colour index value couldn't be used. @3 A few last words ~~~~~~~~~~~~~~~~@1 I've covered a lot in this article and I hope you all find it useful. If you have any problems at all then don't hesitate in writing into the letters page.If your problem is a bit more complex, then send in your source code with comments, and an explanation of what the program does and what the error is into the 'Code Clinic Geezer', who is now Lee Bamber. His address is in the code clinic article.