Windows 7 woes, defeat, change of the war plans..

Windows 7 I've been using Ubuntu Linux 90% of the time, and Windows XP 10% of the time, for about a year and half now. I've been keeping an eye out for Windows 7, though, as it seemed like a good Windows after the disappointing Vista.

So when I saw that Windows 7 RTM was already available at MSDN AA, I decided to give it a shot, having never seen it in action. I was expecting problems, since this PC is based on components made in 2004, so it is quite old. I was pleasantly surprised to see that it worked quite well, even before installing any drivers manually. Networking worked, sound worked, the spiffy Aero desktop compositioning worked. (My tv-tuner, Terratec Cinergy C PCI, didn't work, but that's no biggie — it works in Ubuntu.) Then I tried some OpenGL — oops, no hardware acceleration. No problem, I thought and went to install the latest drivers for my Geforce 7600 GS (AGP).

After the driver update I tried Tomatoes, worked just fine. Great! I went on installing Eclipse and setting up my workspace for the game project going on. And what did I find out: it was running very slowly, barely making 40-50 fps and fluctuating a lot! 🙁 What the hell, it works solid 60 fps even in Linux (it's capped to 60 fps, so in reality it would run even faster), not mention Windows XP! 😛

Then I thought, ah, the Aero effects, obviously they would affect the performance on machine this old. Disabled Aero, tried again: same results. I tried plenty of older drivers, plus a new set of drivers released a couple of days ago. Nothing changed. It would sometimes reach 60 fps when there was not much to render, but especially the water shader was killing the performance. This was not acceptable, I mean it does not really motivate me to develop something running too slowly, when I know it works much better on this very piece of hardware I've got.. Of course I understand that it will run slower than in XP (on this old PC), since W7 requires more resources to run, but it should not make this big a difference in fps.

After asking about the problem on Windows 7 forums and getting nothing, I decided to admit my defeat.. I guess either the OpenGL drivers just are not what they were before, or this PC is plainly too old for W7. I suspect the first. Of course, OpenGL has always been the ugly step child in Windows world while Direct 3D is receiving the love, so.. 😛 Too bad, really, I was starting to like W7.

I went and dropped back XP, and boom, everything runs fast again. 😄 Ubuntu dual-boot comes a bit later.

However, I might try W7 on the laptop of mine, that is currently running Vista. Vista seems too bulky for that cheap laptop, starting up very slowly etc., so I suspect W7 might help a bit. Indeed, I will probably see how the install goes on the laptop. Stay tuned for my report! 😉

UPDATE: Writing this from the laptop running W7. 🙂 Seems to be working fine, except the smart card reader. Better than Vista, that's for sure.

Marriage news!

Just wanted to report this: Annemari and myself finally got married a couple of days back, 7th of August to be exact. 🙂 Phew, lot's of preparation for a single day, but it was all worth it. Everything went well and I'm happy. Seemed like our guests enjoyed as well. ^^

In other news..

I haven't progressed on the game project, but I have played games. I finished Saints Row 2, it was a blast. Currently I'm playing InFAMOUS, which I bought recently. Great game! Thinking of buying Red Faction: Guerrilla next. So many great games, so little time.. 😛

This brand new site goes live!

See anything different? 😉

Ok, so I finally got around getting a proper hosting and a domain for my MHGames site, and here we are, at the sparkling new! Yay! 😄 I actually wanted .net-domain, but alas it was already taken (like was .com, .org was my third choice).. 🙁 Oh well. 😛

So what's new? Here is a list of things I've been doing the past 1,5 weeks:

  • I chose to use WordPress, with the intention of combining my existing site with my separate blog. This worked out nicely, I was able to import all my blog postings from Blogger without too much hassle! Great work WP-team. 🙂 I can highly recommend WP for any blogging purposes, and even beyond that.
  • I did a custom theme for this site, basically from scratch. Had some difficulties making it scalable, but it works. I've tested it in Firefox 3.5, Chrome, IE 7 & 8, Safari, Konqueror and the latest Opera. All of those worked fine, phew. 🙂 The theme is valid XHTML and CSS, so I can always blame the browser if something doesn't work! 😉 Needless to say, I'm happy with the results on how this theme turned out.
  • Finally I crafted the old MHGames-content over to this new site.

Now that this site contains both my development blog and my games, direct all your gaming needs to this address, so to speak. I will eventually get rid of the old site, so remember to update your bookmarks, if any!

That is all this time, enjoy the new site and do drop a comment on what you like or don't like. 🙂 I hope to resume developing my game project now that this site is alive, stay tuned.

Geez, it's been a while…

Time for an update, I reckon.

Although PolyAnim is generally on hold due to the game project, I made a few optimizations (reducing garbage generation mostly, still quite high though) to it. As for the game, I'm still working on the engine side — BUT — I've written down some things on the game plot and other design! I have a vision of the game beginning, but the actual plot still needs to be thought up. Sooo yes, I don't have much at all, but it's a start. 😄 Luckily I don't have too much pressures on the story side, as even if it ends up sucking donkey balls (excuse my language), it's still infinitely better than the "stories" of my previous games combined! 😉

Meanwhile, in the programming land…

It's been so long since my last update, I've worked on so many things I don't even remember them all. Instead of trying to remember the details, I'll just list the things I do remember:

  • First of all, I started using revision control for the source code (+ related resources). Instead of using the familiar Subversion, I decided to try something new and thus chose Git. All in all, this helps me keeping track of the things I do and also serves as a backup in case my computer decides to blow up. Git is nice since you can use it locally, on any directory without a server.
  • VBO (Vertex Buffer Object) support. This means storing geometry to the GPU and rendering it in one batch. Basically it means better performance. Using VBOs I could optimize the text rendering by buffering the rendered glyphs into a batch, up until the buffer fills up (or the texture changes). The buffered glyphs are rendered in one go, and the process starts again.
  • Particle systems! I started doing a "particle engine" a while back, got it done except for the different emitters. I still need to finish this up: complete the basic point emitter, add more emitters and add the ability to load particle systems from resources (perhaps a YAML or XML file). VBOs are used to render the systems, when supported by the GPU.
  • Lighting system improvements. Lights can now have different effects on them, like flickering, fading and pulsating. The effects are defined in a YAML file of properties.
  • Player character designs. I'm not sure if this guy ends up being the final character, but might be. I did a quick idle animation for him (need to adjust that a bit, though), I should add a walk cycle next as it's quite boring to watch now. (The previous animation, test from PolyAnim, did walk!)
  • And now for something completely different: Water effects. Yes. This is mostly eye candy (as Box2D doesn't support buoyancy yet, I think the water is only going to be used for restricting player movements as in the player can't swim..) so it made no sense to do it at this phase of development. But I did it anyway, I'm childish like that.. 😛 The water reflects the scenery above (provided the GPU supports Render-to-texture) and I even wrote a fragment shader to make it all wavy and twirling..

I have noticed a problem during the development of this game, which was not apparent on my previous game projects (since they were much shorter): I have this annoying tendency to start working on different (sub)projects even when the previous stuff is still not finished. That means I have heaps of unfinished subsystems in this engine, like the particles, scripting, triggers, etc. And I'm already thinking of doing the sprite system and other things as well! I mean, what the hell, it should be bloody obvious I should concentrate on the unfinished things and finish them.. 😛 Argh, hopefully I can sort this mess out. Speaking of which, I guess I should start coding the particle system to an usable state.

And of course, to all aspiring game developers: design the game first, damnit! Figure out the plot, setting, characters and whatnot BEFORE getting sucked in the bottomless fathoms of Teh Engine(tm)! Yes, I really should take my own advice some day! 😛

More progress: Quad trees

Today's subject: quad trees. Here is a nice little tutorial on the subject.

Until now I was using a naive method of rendering the level shapes (polygons and circles): I looped through them all, did a bounding box check* to see if they're visible in camera, and rendered if they were. This works fine for small levels (and indeed for the current test level, although I keep adding more and more stuff to it — nevertheless it's still quite modest in size), but for larger levels it can become a problem, especially on slower machines.

So I decided to add quad trees to speed up the level rendering process. The level shapes are stored in three different quad trees (one for collidables, one for background and one for foreground shapes). The trees are queried for visible objects, which then get rendered. Works nice and smooth, and the performance goes through the roof, right? Well… not quite.

Since the level shapes can have various opacities, it is important to render them exactly in the order that is specified during level creation (in the Inkscape SVG file). In the triangulation & convex decomposition process the original shapes get split up. It was not a problem during the naive approach — the shape parts were in a list and the original order was preserved. Quad tree on the other hand doesn't necessarily preserve that order, to my great disappointment. It makes sense of course, I just hadn't thought about it until I saw the effect: a few of the level shapes were rendered out of order.

At first I tried to come up with a way to partition the quad tree so that the order would stay correct, but that didn't work too well. In the end I ended up just sorting the queried objects before rendering. That works perfectly, but introduces a new speed hit; the sort. So in all, the supposedly great speed increases of the mighty quad tree turned out to be only a modest gain, since I now need to sort the visible pieces.. Still, I'm confident that the quad trees were worth it, as the levels keep getting bigger and more complex it will surely show more greater effect. 🙂 And at least I found that enormous bug in the bounding box culling! 😉

Check out a few debug screens below, quad trees are the white lines.

*) I actually found one of the most stupid bugs I've ever done in the bounding box check code. It was actually checking bounds from the world origin (0,0) to the object lower right corner, instead of from the object upper left to lower right! That means that the bounding boxes got very big and only the objects to right and down from the camera view were culled properly.. Ouch.