1 - Frequent Application - Frame Manipulation, Resolution and Graphics Mode

In all honesty, you don't necessarily NEED to prune filesize unless your demo alone is over or right at 5mb. If that's the case you should do some weighty trimming. More than a few of the problems lie with multiple frames. It's not having a thousand and one frames (200 Frames by themselves take up around 532kb, not that you'd be using 200 frames in a single application) that add to the size. The frames accompanied with graphics, and making each frame unique and distinguishable is what does. In the end, you're at 3mb for two frames alone without even knowing it. Extra frame options like grab desktop at start and Keep display from previous frame all take memory and can add around 6-9kb to the application as well as damage FPS on some computers. There's also another option for level designing frames. Instead of eight individual level frames, one COULD store them all in a single 32000x32000 and just give it some funky level transitions which could, just make it all look better, instead of having your character jump from level-to-level without any explanation of how he got there. But you'd then face a lot of background problems, You'd probably be forced to result to some sort of background parallax or you could map the entire 32000x32000 and place the backgrounds ahead of time -Which sounds more logical. Graphics Mode being another problem, 16 million-colors are a common standard in nearly every application these days. The regular 256-Colors may have its doubts and I'm not going to recommend washing away high-quality graphics for a loss of size because I'm too cheap to get DSL or Cable. The other one being 32768-Colors isn't so bad, takes away at least 50kb, but might also ruin the graphics. The estimated filesize deductions assume you had 16 million-colors as a standard. Unless you plan on being a filesize junkie don't even bother with this, just keep it at 16-million colors. Either that or do some extensive research and redraft on the graphics you're using. As for resolution go with whatever you want, as long as it isn't ANYWHERE above 520x340. RPGs don't really need such a huge screensize, I'd make one with 320x240 (Since it scrolls and moves the fastest). All resolution sizes virtually take up the same size, but it's better for the FPS that it remain as low as possible. Another point to bring up is the Resize to fill current window which generally makes the application slower without the author even knowing about it being so. Consider it to hurt the game more than it would make the game.


2 - Value Keepers - Counters, Alterables, and Extensions.

This is where our beloved counters become slightly inferior to Alterable values. This is because Counters can take up a wide-ranging quantity of size. Infact, I wouldn't recommend using counters AT ALL, unless it were for those horizontal / vertical bars and to basically SEE the values while they're in effect. And as you know, Alterable VALUES are just that. Values and no more, so it’s comprehensible why they’d take up less filespace than a counter. The reason why counters are responsible for such towering file size is due to them being newly created objects. It's not so much of it being another pace towards the general object limit, it's when we make the counter invisible and give it properties as if it were an active or background is when it starts to turn into a size-nuisance. Keep in mind, there's no such thing as a game that just uses one counter, we commonly find ourselves having 20-30 in the long run. There are, on occasions you'll need more than the given 25 alterables and times where you'll be tempted to use counters but if you actually plan on keeping the file size down, use what I call an Alterable Whore, they're basically 1x1 pixel-ed objects whose only purpose are their 26 alterable values. Not the best method of value keeping but they could surely get the job done. Counters aren't in any way bad; just don’t plan on getting any arcane filesize cut-off using around 10-20 of them. Alterable Values aren't perfect either; they’ve got their downsides. Any object with them (and every active object has 25 default alterables) HAS to carry out the weight of EVERY SINGLE property a normal active object would have. You know stuff like; movement, scrolling, display, etc. In turn you won't even use any of that unwanted stuff. So having 20 'Alterable Whores' can, - in turn become a bad thing if not used properly. Granted, Alterable Values can pretty much do everything counters can do with the exception of the bars and visible values, however if you really really wanted to cut down filesize you'd get one of those Value-Only extensions and use THAT instead of creating various new counters and active objects for value keepers. And from what I've seen, using an extension to keep track of values seems to hammer both Alterable Values-<From Actives> and Counters. The only downside I've seen are the runtime/extension sizes, they could get pretty massive.


3 - Active Objects - Drawing, Creating and Ink Effects

Active Objects are the basis and soul of every Klik Application. It's safe to say they're in every application / game -since you can't build a game with just backdrops. Actives can either be used as an advantage or disadvantage. They can cause tremendous filesize or plunder the FPS downhill to nothing at all. According to DerbiaN and Tigerworks, active objects can be classified as both Activate and Inactive. Depending on the mode, the active could either break or make the application's speed and FPS. An Active Object is considered Active when it's either moving or tainted graphically. It's Inactive when it's not doing anything. The reason it slows down the application when it's active is because every animation or direction change that is called into play has to redraw the active itself -Not to mention looped animations. There's also another factor to bear in mind, if the active is colossal with 60 or so frames and sizes of 320x240 it'll not only slowdown the application, but probably boost 200+ KB on the filesize. If you plan on using objects of the like, make sure it's deleted afterwards, you should probably consider resizing the thing while you’re at it. On a similar note, creating multiple objects or bringing multiple objects into play is another slowdown -Unless deleted immediately after usage. Say you have a bullet object that’s frequently created when fire1 is repeatidly held. It’s not only creating various “Active” bullet objects, it’s eating away at the runtime speeds, unless you have some sort of limiting factor and/or deletion planned. You could even paste an active into the background when you're done with it. (I don't generally recommend you do this for a bullet that just reaches the end of screen and just pastes itself there.) Point still stands though, things that are created in-game should be deleted at the launch of the application with a start of frame action. I'm sure you've all seen and used the pretty Ink effects that come standard with every active object presented to you. Ink effects aren't bad but overuse of them can be terrible for the exact same reason(s) I mentioned above as well as some new ones being, redrawing an active or anything is the slowest process or situation MMF can be put into. So just imagine how much of a pain flat out 'abusive ink effecting' would be. If you didn't notice already, this was a pretty straightforward fraction of my article, so I kinda ended up saying the same thing using different words. Lots of credit for this chapter in my article goes out to Tigerworks and DerbiaN for their previous articles and statements of filesize reducement and application slow downs.


4 - Byte-by-Byte

This doesn't really make a DRASTIC alterization, but if you're over the edge in filesize and you need every little byte to make a difference, each character in an object or group's name is one byte apiece. I'm not entirely sure on this but an object's icon might take off a good 5 bytes or so as well. Just color-code all the icons into 1x1 pixels you can distinguish later on. I don't really recommend this since you could get lost easily in the event editor with a complex engine of sorts. Another thing just happens to be the events. I'll start with event looping. The way the looping extensions handle continuous events more often than not -only takes up two-three events as a whole. Copying the events several times is another way of looping, but it's also a more fattening way to get the job done. And if you really want to be anal about filesize, just use Multimedia Fusion's built-in loopier. It seems to be the better choice. Granted, the extensions may present a more wider variety of looping selection and options, but the built-in one is pretty much all you'll need. Not to mention Extension size, they aren't exactly small. Now onto the underrated ‘Limiting Conditions’, - They're rarely used and the only one I actually HAVE seen used frequently is the Only one action when event loops condition. If it's an event that you're only going to use once, slip in the Run event once condition. It goes the same for the 'Repeat' condition. And also find some way to delete or deactivate the events or groups when drawn to a close. Qualifiers can save game speeds or cut sizes on their own. The Qualifier groups are as followed: Player, Good, Neutral, Bad, Enemies, Friends, Bullets, Arms, Bonus, Keys, Texts and other sorts of excess groups (Most labeled with a bin icon). With all of those groups you can obviously accomplish thousands of tasks such as bullet classification and switching characters in and out. Consider it one of those things that CAN and SHOULD be used to cut down on the events in the overall game. This last bit isn't exactly a filesize cutter but keeping your events organized helps, so you could possibly come back later and cut away at them.


5 - Miles per second - DirectX, VRam and Machine Independent Speeds

VRam and DirectX are both - in one word ‘outstanding’ in their own ways. Starting with DirectX, my personal choice of the two. It seems to have a tendency to handle large objects with rather decent looking and running ink effects in the long run. It can run massive objects pretty smooth - multiple objects are a different matter altogether and should be avoided with DirectX. If you DO use around 20-50 actives expect slowdowns somewhere during your application. On another note, Transitions with DirectX are pretty ’leveled-off’ - Which is a good thing. VRam, or VideoRam has pretty flat scrolling and moves relatively fast under the right conditions…there aren’t too many ‘right’ conditions for VRam just to point you in the right direction. Multiple and massive objects aren't exactly VRam's cup of tea either. Using VRam for transitions, ink effects or anything else along the lines of that. So in short, I'd only use VRam if you had a decent amount of RAM on your graphics card, even then it's probably best used when there's little to no active objects at all being used in the application. Machine independent speeds are an uncharted territory for most applications or games I've seen. Personally, I’ve never tried it, so I'm not much on giving a summary of what it does. But I WILL say what I heard and read that it does. On a slower computer, say my own for example, if the game reaches or hits a lag-point while Machine Independent Speed is on, the framework and game in general converts into a jerky mess running at a low FPS. In all honesty, no matter how far into the game I was, I'd just close the window. No one ever wants to go through that, especially with a super scrolling plat former. Major credits for inspiration and recognition on the runtime notes goes to AsparagusTrevor who posted an article on it back in March of 2003.


6 - Author's Notes

In every other filesize reducing article you usually get fed the basic mp3 and midi fued. I didn't go about mentioning that since it's pretty much covered in every other reducement article. As mentioned before, Tigerworks, AsparagusTrevor, Muz and DerbiaN get huge credit on inspiration on this article. -Which IS my first article by the way. This article took me around a month to work on (Can you tell?). It started as an off and on relationship and eventually, I was forced to finish it. So it's safe to say it was rushed. I wanted to chirm out about 9 chapters but ended up settling for less with five, not counting this one that is. Anyway, I appreciate the time you put into reading this. Expect a possible followup in the next year or so. =D!