Game Design, Programming and running a one-man games business…

Category: programming

Spot The New Feature

Posted on February 23, 2010

It’s very minor. But what have I changed in this screenshot below?

I’m supposed to be finalizing the new expansion. I’ll do more work on that tomorrow, but I’ve resigned myself to one more patch before I release it. I needed more weapon variety for them, and that meant code changes to the main game. Then I suddenly got a bit manic and obsessed about improving the graphics in all ways. Hence, 2 days were wasted trying to add shadows (I tried various methods but none of them look right, not without re-rendering every existing ship and a major re-write) and then a decent bloom effect. In the end, I junked all that code, because it didn’t get me anywhere.  I’ve made 3 tiny changes today to some stuff which make the game look very slightly better. Overall, it all adds up methinks….

Two new features for GSB

Posted on February 12, 2010

I was honestly trying to work on new DLC, but hey, I ended up adding and improving some stuff. One thing I ended up doing was mouse cursor changes, so it actually changes to the windows pointy finger thing now to show you that you can click something, which is quite nifty. I also added two features.

The first feature is the ‘fleet overlay’ at the left of the screen. It’s a scrollable column of icons for every ship in the fleet. The tooltips show your current damage percentage, and they fill red as the ships take damage. you can also click them to zoom to that ship. It’s a handy way to see at a glance in big battles which ships are taking hits. I also added a tiny arrow icon to toggle that new feature on or off, in case some people don’t like it. I have a tiny UV bleeding issue on that button I must fix…

gratuitous space battles fleet overlay UI

The second feature is rather cool for statistics-freaks. If you have played much GSB, and spent much time on the ship design screen, you will know the frustration of seeing “weight=122” and not really knowing how that compares to anything else. Obviously you can go through each module of the same ship class and compare, but wouldn’t it be better if the game makes that trivial to do?
Tada! It does. You can click any of those data entries at the bottom left now, and get a comparison window, ready sorted and scrolled to show where the current module fits in. I hope people find this useful.

gratuitous space battles ship design screen

Now I can get back to work designing fleets for the religious aliens in the next DLC…

Both these spangly new things will be in version 1.32, which will get released shortly before the new DLC. Yay!

Programming Gratuitous Rocket Trails

Posted on February 9, 2010

I was watching District 9 ( I liked it, except the more yucky violent bits), and there were some cool rapid rocket trail effects in it, and it suddenly reminded me that the rocket trails in Gratuitous Space Battles aren’t good enough at high speed. Take a look at this rocket trial, from a rocket cruiser missile at 4x speed:

Crap isn’t it :D. At normal speed it’s fine, but at super high speed, the missile actually moves too fast per frame of rendering for me to actually space out the particles. So I just knocked up some code that instead of doing this: (pseudocode)

HowFarHaveWeTravelled?
IsItTimeForAnotherParticle?
IfSoPlaceAParticleHere

does this:

for(distance_accounted_for = 0; distance_accounted_for < actual distance, distance += particle spacing)
{
  Position = LastMissilePosition
  Position += (distance_accounted for)
  Place a particle at Position;
}

Which is more work :D But it’s worth it, because even at 4x speed it now looks like this:

I know it’s a bit late to be worrying about all this months after the game came out and got reviews, but I am just completely drawn towards tweaking the game to look better. Also this means I can experiment with superfast rocket trails which will still look good. Also today I’ve done all of the debris and turret gfx for the new race in the new DLC/expansion pack thing. Now I have to actually design their ship configurations, and allocate their bonuses. Then I need to do their mission deployments, and then it’s pretty much done (and I then need to balance and playtest it). Yay!

Vertex Buffer Driver Hell

Posted on February 4, 2010

Some days as a programemr suck. Today is one such day.
All my old games use directx7, with my own engine,. Gratuitous Space Battles uses a new engine, directx9, and all is well.

In January this year, Kudos and Democracy stopped working for lots of people with the new nvidia drivers. They got crashes in the vertex buffer lock code. Obviously I hadn’t changed a thing. the games had worked fine on thousands of PC’s for years. Suddenly nvidia must have changed the way they handle vertex buffers under directx7. Thanks guys!

The old code was very old school and simple. I locked a vertex buffer, then copied in memory, then unlocked, and rendered from them. Big deal. I didn’t use any cleverness with the buffers gradually filling up and then discarding them. (I do that in GSB) I always locked the whole buffer and the lock flags always looked like this:

HRESULT hr = VertexBuffer->Lock(DDLOCK_WRITEONLY | DDLOCK_DISCARDCONTENTS | DDLOCK_SURFACEMEMORYPTR,
(VOID**)&BufferMem,&bufsize);

For every VB lock. I did a few of these each frame, mainly for rendering text. This may not be optimum, but it worked fine, all return codes checked ok on all cards and all drivers.

Suddenly, on my nvidia 8800 GTS, and for everyone else with new drivers (except the 9800 GT), this crashed, and would only work if changed to this:

HRESULT hr = VertexBuffer->Lock(DDLOCK_WAIT | DDLOCK_SURFACEMEMORYPTR,
(VOID**)&BufferMem,&bufsize);

In theory this is less efficient. But suddenly it works. Hurrah. Except not for 9088GT owners. I tried this:

HRESULT hr = VertexBuffer->Lock(DDLOCK_WAIT | DDLOCK_WRITEONLY | DDLOCK_SURFACEMEMORYPTR,
(VOID**)&BufferMem,&bufsize);

This also works on my 8800GTS, but even this does not work on the 9800GT. I can’t get a reply from nvidia, and the developer forums there hurl abuse and sarcasm at anyone who dares to ask about why a directx7 program won’t run (I’ve read a fair few threads there). Apparently we should all just STFU and re-code everything in DX10. Err right….
Anyway, I have nothing to say on this topic other than it depresses me. I don’t want to be fixing games I finished a few years ago, I want to work on new stuff…but obviously I need to support all my customers. I just wish someone at nvidia would tell me what they changed, and how to work around it for all their video cards. I emailed them a few days ago but got no reply…

If you work an nvidia, or know everything about directx7 VB usage with modern drivers, please shower me with your wisdom. And if you have an nvidia card, feel free to try the demo to Kudos 2 or Democracy 2. Both should now work, but I’d love to know if they don’t, what video card and driver you have…

bah :(

The fallacy of features. New and not improved.

Posted on January 30, 2010

I put up a new article, in more detail on how GSB was made and what was involved. You can read it here.

Recently, in between working on patch 1.31 and the mysterious second add-on for Gratuitous Space Battles, I’ve been looking at some technical issues people are suddenly having with Kudos 2, Democracy 2 and Some of my other games. Suddenly, without me patching or changing anything, people started complaining about vertex buffer crashes. At first, it seemed to be Windows 7, or Windows 64 related, at which point one naturally assumed that the geniuses at Microsoft have ballsed up yet another operating system, but then the odd vista or even XP user had similar issues. Then it suddenly clicks that new nvidia drivers were released, and everyone having crash problems had an nvidia card.

I use vertex buffers differently in GSB than I do in my other games. I was using them in a slightly unusual way before. A way that is perfectly legit, that directx says is fine, where the video card returns no error message and says its all fine, and working great. Everything is good in the world.

And then suddenly, a few weeks ago, with their new drivers, some brainiac at nvidia has obviously thought ‘sod it, who cares. If they don’t use a VB in the way WE at nvidia like to use it, who cares it it breaks?’. And thus bug-ridden drivers are released. I have absolutely no doubt that the latest trilinear bump-depth-shadow-pixelling demos in directx11 look just superl33t at GDC with the amazing nvidia code. Just a pity that they couldn’t be assed to check if all the older applications still run isn’t it? Especially given that the entire modular COM design of directx is specifically designed to ensure 100% backwards compatibility.

Nvidia are still in a cold-war mentality arms race where they think all people want are features. It’s the same as Microsoft. “Give them new features!” “Shiny things!”. When Vista came out it was promoetd on the basis of the new flip-view. Have you ever used it? Me neither. Fuck features. I don’t want features. My mobile phone doesn’t even have a camera on it. My home phone doesn’t have an answering machine on it. Features do not get my money. Reliability and Performance gets my money.

If Windows 7 was advertised purely as “Vista, but more reliable, and quicker”, I’d buy it today. When I buy a video card I only care about how compatible it is. The performance difference these days between equal priced cards is so small they even need to blow up screenshots and use arrows pointing at pixels which show the difference. Who cares?

Worst of all, this obsession with tomorrows new feature rather than yesterdays compatibility is putting two pressures on pc game developers like me:

#1 take time away from making new PC games to actually go back and re-code old ones to work around nvidias latest ideas.

#2 Seriously think long term about doing browser games or console games, where this isn’t such a problem.

I’d hate to have to do either :(