Dune Smasher!

EDIT: Updated 1/15

New version! There´s a bunch of new features in this update!
Changes:

• Hopefully most bugs were fixed.

• 5 New secondary weapons, homing missile, flamethrower, zap gun, laser gun, and finally, the nuclear attack(you´re lucky if you get it).

• Added crates that fall to the stage in random positions periodically. The content of these crates is hidden until you grab them, so you should better check them out. There might be a health pack.

• Randomized enemies, with different coloring, size, and health.

• Difficulty increases the more time you play.

• Widescreen support. It increases the play size, which IMO, is better.

Use your high-tech heavy armored tank to blast the enemy jeeps! Shoot 'em, blast 'em, crash 'em, zap'em, burn'em, pierce'em, pursuit'em, and finally... nuke'em! Nothing is enough for this great tank.

I've decided to start fresh this year with a new framework(mostly inspired by Mark's one ) that would solve all my problems of laziness and C/C++ mixture of my old one. So I coded today this little game to test my actual framework's capabilities with most computers. Obviously it isn't finished yet, but its base might be enough to show what I'm aiming towards with this new framework. I'm trying to bring back most of the features that OpenLayer had(Garbage Collection is a must ), but using A5, as well as adding new features I like. The source code is available, waiting for one of the pros to come and tear it to shreds, and tell me how should I code

Screenshot

{"name":"600293","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/f\/7f6bdbeb3e61877b0d9c61289ee2a066.jpg","w":1024,"h":768,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/f\/7f6bdbeb3e61877b0d9c61289ee2a066"}

Download

Source code and Windows binaries Updated Version

Watch out, this new version is defaulted to 1280 x 768, so if you don´t have that resolution, edit the settings.ini file.

(If you know A5 games don't run well on your system, don't download it :P This one won't be the exception surely.) Wait, this is A4.9.16, which has some bugs corrected regarding font drawing. Maybe you should give it a try.

Questions

1) Does it even run? Smooth? No stutters?
2) Average FPS and your specs?
3) Did you find the game too hard or too easy? Post your score! (F12 to save the Score in a screen)
4) Is this game worth of any additions like powerups or new enemies?

1) Smooth, however I think it crashed when I hit Escape in the middle of the game...

2) 60 FPS on AMD Athlon 64 Dual Core 4400+ at 2.44 GHz with an NVidia GeForce 9600 GT

3) Just right, score: 998573856

4) More variety would be nice

Cool game

1. It runs without a hitch.
2. 60 FPS on Intel Core 2 Duo T6500 @ 2.1 GHz with ATI Mobility Radeon HD 4500 series
3. I find it a bit hard, and I only got 13550. But maybe it's because I'm not much of a gamer.
4. Powerups will be a nice addition. And health packs.

Oh, and I like the creepy background music.

1) Runs smooth
2) 59 FPS, Althon XP 2000+ NVidia GeForce 6600GT
3) Alright, but a bit confusing: 22963
4) More missiles! And health packs, at least.

Yea, baby.

What does K in KGF stand for? I'm assuming is GF "Game Framework".

You should add a check for the window's close button.

Other than that everything works for me. I was playing and ran into an enemy and was like "enemies blow up? hell yea!" To which I proceeded to plow through all my enemies.

Also, you should turn on the anisotropic or linear filter to smooth out the jaggies. It's available in the allegro.cfg somewhere.

I'm pretty sure anisotropic filtering does not work in A5, but linear does.

I'll try this game later, probably.

{"name":"600288","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/a\/4aae6dbc37980b173f10bfc71583b8ed.png","w":600,"h":300,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/a\/4aae6dbc37980b173f10bfc71583b8ed"}

Windows 7 x64, Geforce 8600M GT. Run smooth at my lcd's refresh rate: 60 hz.

It's okay but why doesn't it support my 3D monitor?

I hate those post-closing crashes. Something is not deleting well as it should.

Screenshot or it didn´t happen

That song is part of one the best games ever made. Let´s see who´s the first one who recognises it.

You knew your lazy coding style would inspire people.

It´s a secret!

Thanks! I was wondering why rotation in A5 looked like software-accelerated

@Shravan: I´m happy to see you took the time to press F12

Maybe I can code an exclusive version for you with 3D jeeps and explosions

So far, it seems no one ran into problems. Til Paul or Felix come in to crash the party. Maybe they should test it anyway, since I´m using A4.9.16 now.

May be its a recursive acronym for KGF Game Framework.

It sounds very familiar but I can't quite place it...

You should rename it to Poon Smasher.

New version Uploaded! Check the first post for details. There´s a lot of new gameplay elements now. Need testing!

Is that like a _cunt punt?

A side note abou this. My framework caches rendered text to a bitmap which is subsequently used instead of direct font drawing. As I recall, there were still problems with framerate playback despite this, so it may not be font drawing that's causing the speed issues that some people have noticed.

It's a little different, like, "The other night I met this hot chick and we went back to her place and I smashed that poon!"

The fancy new deferred rendering stuff in the latest WIP has reduced the font rendering overhead significantly. Allegro 4.9 also did cached font rendering, and it was still slow, the slow part was sending all those drawing commands in spurts. Or so it seems. Batching them all up at once in a single go seems to have sped it up a lot.

Here's an obvious clue:

So you cached a cache? This should be documented, so people can avoid this mistake in the future.

Give me 3 good reasons and I'll do it.

FTFY.

There are 3 different caches. The first is caching the glyph bitmaps loaded from the font file, this the only thing Allegro used to do (it still does it). The second is caching the drawing operations (instead of many al_draw_bitmaps using in effect one), this is the new feature in 4.9.16, courtesy of the deferred rendering. The third is caching the output of those draw bitmap calls, this is what Mark does, but Allegro does not.

Using the third cache (in addition to using the previous two) should be still a little faster than than using only the first two, although the difference should be much smaller now than before (when only the first cache was used). We could add a third cache of our own, caching the kerning values, but that will have to wait until someone starts complaining of the slowness of TTF font drawing again

Hopefully that made sense

EDIT: I suppose the second cache is more properly called a batch... w/e not rewriting my post

Indeed. That's how every allegro dev named it. I don´t know, and ain´t interested either in the exact terminology, but I always assumed cache goes for storing something and avoid loading or processing the same data again, and batch goes stacking up piles of commands for a single call later. I also hope this made sense.