Finally the cars situation is improving a bit, there's around 25 high quality rendered cars ingame now, i'm hoping to reach about at least 60.

Also big thanks to the few people that donated, your help is much appreciated!

Click the image for a hi-resolution picture.

Art has appeared to be a particularly problematic part of the game, every single car has to be modeled in 3d in high detail and rendered with very high quality render setup to a 2D texture to get a decently looking result, so low polygonal models which are a standard in most games today do not work in this case as the result looks like something from 1997.

This prevents me from using any free models availible online for the game, and most good useable car models on 3d model shops go from 20 to 50€ (30-70$) (on turbosquid, evermotion), which kills my reasonable cost indie budget for the game at like.. 3 cars, and there's also additional cost of paying someone who knows how to render models to create a good quality lighted render of the car that i can use.

This pretty much means it'll either take a year of saving money to get the car models needed to complete the game - unless there's kind people who donate towards completion of the game.
I'm setting up a paypal button here. Donate as much as you want, i cannot promise much but you'll definetly get a mention in credits and a free copy of the completed game when it's done.

Suddently i realised what the real reason for poor performance on ATI cards was, for some particle effects i used textures with dimensions which weren't "NPOT" (power of two), and apparently most of ATI cards of DX8 and even DX9 era don't really like this at all, it looks as if they implemented NPOT support so they could say they have it and that was all for them, in reality while npot supports works on their hardware, it's performance is somewhere between "TERRIBLE" and "IMPOSSIBLY SLOW", and by that i mean when comparing performance to NPOT support on Intel GMA 950, and that's a low performance netbook graphics chipset!! The GMA beats most DX8 class radeons in npot texture rendering speed.

So, for now i reworked all textures to power-of-two dimensions, which wasn't difficult, but it would be nice if they got their npot implementation right, i mean as in "do it properly or don't do it at all" kind of way.

With all this work on supporting older and weak graphics hardware properly i also added automatic degrading of graphics quality settings when underperforming hardware is detected, it simply calculates the number of frames drawn in 5 seconds and see if average is unacceptibly low, then it turns off sprite shadows, which are the biggest performance problem.

I also decided to actually name the game engine used for Top Down City. So far it didn't really have a name but now it's called the "Mayhem Engine".

I think it describes it very well.

Sprite packing is a very important thing, it not only enables you to save texture space (squeezing a 2048 * 2048 image of 128 * 128 px sprite grid into a single 1024 * 1024 texture means 4 times smaller texture on disk as file and in gpu memory).

But there's a another invisible enemy you beat at the same time in the rasterizer's "battlefield" which it's called alpha testing and can be a real speed issue on slow GPUs, it is basically a optimization step for the alpha blending, it discards fully transparent pixels before the alpha blending is performed (which is a even more expensive operation), but when you have a grid aligned texture of sprites of various sizes, in most cases because of some sprites that are larger but not neccesarily drawn most of time you have a lot of pixels that are blank but still occupy the graphics card pipeline.

So, packing these sprites tightly and only rendering the small area which is important saves a lot of pixels from wasting time in gpu pipeline, which gives older and weaker GPUs a lot more breathing space, see the picture on right as a comparison, the blue area was originally rendered althru a lot of pixels ended up being invisible, red is the new drawn rectangle which fits the actual actor sprite which is much smaller and optimal. So it's a double win for optimization this time. But there's always plenty of things left to optimize...

The car physics part of TDC so far was lacking any proper or useful formulas to perform a enjoyable arcade car driving simulation, but i have taken some time now, and developed something better. Now this isn't final and i already added more improvements after taking this video.

Also forgive me for slow video framerate, fraps appear to have issues recording at fixed framerate of 30fps with synced audio and i have no idea what causes it, if i dont record in sync the video is fine but audio goes wacko out of sync.