The 4K comp is gathering pace which is great ( Actually finished my game last night / this morning. I had some ideas the other night on how to improve it and it was quite nasty going from being "well" under the limit at around 4070 bytes and then going over with the new code. I was on 4099 bytes for quite a while last night until I cracked it. 4093 bytes and done, which is cool. I was going to be a clever sod and round that up to 4096 exactly, then realised that someone will do something in 2.5k that'll crap on my game and I'll just look silly for having used the max available and making something which isn't as good )
Rich over at photonStorm has posted some great tips for those of you giving the comp a bash in as3.
I opted for F8 / as2, although it's written like as1 with datatyping ( No Delegate or classes here ). Publishing as F7 would have saved a few bytes, but I wanted some of the filter effects.
I'm not sure what I can pass on that may be some use, but here goes ( Remember it applies to F8 / as2, the rules could be totally different for say F5 / as1, the size report is your friend with this comp ).
Chaining vars is actually longer, eg
is a bit bigger than
Loops seem shorter this way,
Although to be honest I didn't try for loops ( I always use while, just habit )
It's common knowledge that pre-as3 var names have an effect on size and speed in terms of their length ( i is "better" then myTempLoopCounterVar ) but linkage names have an impact too, so "bb" is smaller than "baddieBullet". Common sense I know, but if you're not used to thinking it terms of making code as tight as possible it's easy to miss ( It was for me anyway ).
More general things I did was to re-use values as much as I could, for example when the player dies I have to move it out of the way so the collision checks don't get triggered again, so I set player._x=2000; because I use a setInterval afterwards to wait for the gameOver ( id=setInterval(gameOver,player._x); )
Another thing, which is so dirty, was to drop an enterFrame on to everything. Originally I did the usual looping through an array calling the objects mainloop, but by adding the code to the sprite itself you remove all the loop overhead and make each sprite self sufficient.
It's weird tearing up the rule book for this comp, it's like going back to as1 and doing all those nasty things we used to do just to get things working.
If you've not done anything yet I can really recommend giving it a bash. The deadline is ages away yet, it should only take you a couple of hours for a couple of evenings and it's really good fun, it gets you back in touch with coding again rather than just dropping huge bitmaps into your fla and using a tweening package.
So I have rencently finished a bigger update on a client's website, dealing with all the nasty and ugly shit one would rather like to avoid (to name just one: css - what was wrong with the good old table layout? OK, I know what was wrong, but dealing with all the browser's shitty problems to make it look nearly the same is just ... well, shit)
Meanwhile Squize was hammering out post after post so I didn't felt too bad being quiet.
Now today I actually have something to post, so here we go ...
This is a single frame from the X menu/background animation I've been doing. It'll take a while to render so I have to set up the network renderer on Monday to get the 30 seconds movie out to an flv file (which then will be played in the X menu) ...
If you're a fan of that game already, why not use that image as wallpaper? You can grab the 1024x768 version here.
Bigger Versions are rendered tonight and will be posted later this week - and maybe (if rendertimes for hi-res vids aren't that high there might (really just might) be a screensaver ... we'll have to see).