Clouds R Pretty

Bit o'the old update fer you fine folken. I been workin' on PP:AFAA and, by extension, Melba Toast pretty good the past couple days, and boy oh boy is she startin to come 'round. I s'pose it's been a long while since muh last post, so I reckon I start at the beginnin.

Separating your timestep from your framerate!
I found a good post on gaffers blog about physics and fixing the timestep to ensure stable and consistant physics. Previously I had thought that using a delta time variable would ensure correct integration of physical movement in my physics simulation, but not only is that not enough but I was using the most horrible integration algorithm possible as well as allowing for wild fluctuations in the delta time variable. Gaffer has a two parter, here's the second part, on physics simulation.

The first part is all about using RK4 integration to figure out f=ma, I didn't take the time to really understand the algorithm because apparently I'm a bloody idiot and think Euler is fine enough for PP:AFAA. Also integration scares me. The second part details a simple method to ensure the delta time variable used in your physics simulation is the same regardless of the actual framerate. Put simply, you wait until a minimum amount of time has passed, for me its 10ms, until ticking the simulation. If more than 10ms passes during one frame, then tick the physics simulation as many times as you have to in order to "catch up". Its bloody simple and increased the consistency of the prof's movements considerably. And no need for scary integration. I'm still using Euler mostly because its faster than RK4, and when I have more time I'll implement both and see if the increased accuracy is really worth the performance hit.

Vector Art All Around!
Yeah, there was some discussion about using raster or vector art for the assets in Flash, I was thinking that bitmaps would be faster than vector arts and after doing some simple tests trying to display about 3000 PP:AFAA boats in vector or bitmap of multiple sizes and small bitmaps did prove to render faster than vector stuff. It was a difference of about 10 fps, and in return we got boats and a professor which look like dogshit when rotated. In short I've decided to go vector for everything which is gonna work out great for scaling, rotating all all that fun stuff. I was even thinking today about dynamic zooming and got all excited. Not sure how that'll fit in with the tile management system, but damn it would be cool.

Sweet Console Command Stuff
Spent a bit of time today with my console, trying to figure out how to do console variables for in game tweaking. The end result? Now I not only have the "fps" command, but you can set the prof's accleration variable with the command "porpAccl=X". Also I fit in a command history thing so you can cycle through all the commands you did throughout the current game.

I was trying to find a good way to register console variables and the best I could come up with was to create a new child class of Console, PorpConsole specifically for PP:AFAA which has a reference to the prof object and then I hardcoded the parsing for the "porpAccl" command and the variable it changes on the prof. This isn't so cool, what I originally wanted was to give the base Console object a dynamic list of handles and function calls which could be registered at run time, this way each object which needed a console variable or some other kind of console functionality could just register it remotely and this could be turned on or off from each object individually. The way I have it now, all the commands and their functions are controlled set right in the parse function of the PorpConsole class, its all centralized and crappy.

Also Splashing
He splashes when he gets in the water. Neat.
And I drew some clouds. they are pretty.

-mike out