Monthly Archives: February 2014

Yay depth sorting (kinda!)

February 28, 2014 | Filed under: gsb2 | programming

So after a lot of mucking about with render states and blend modes and shaders and reading, and z buffers and other tedious things i think i now have the previously unattainable mixture of proper smoky effects, happening in 3D with my shadow casting and bright ‘burn’ laser and flame effects all working together. This means a ship exploding can look like this (click to enlarge)

screenshot_28-02-2014_11-37-41

Which I’m pretty happy with. Those particle effects are all a mess, placeholder stuff that I can fix easily once I’ve rebuilt my editor for them. Plus I need to add a lot more stuff, and also those ships are obviously just modified GSB 1 ships not designed to take new lighting capabilities into account fully. I also need to fix some boxy depth-of-field artifacts for the distant asteroids. Next on today’s agenda is likely to be getting ship hulks to cast shadows (easy!) and then work on letting hulks drift in pseudo 3D (towards or away from the camera, but always planar, as they are sprites after all :D).

So what was the solution? Well it was as I suspected (amazingly). I just needed to take the key scene objects, the hulks, the ships, the turrets (which are separate items) and the asteroids and draw them to my own depth buffer. I then set that depth buffer to be texture layer 2 when rendering the smoke & flames (so that I can reference it in a shader) and just set alpha to 0 for any pixels where the depth buffer is closer than the particles I’m drawing. Right now I’m using a manually created and rendered-to depth buffer, so it’s actually a render target. You can’t in Directx9 have a z buffer that is a render-target, so I might experiment later with toggling the z enable on and off and using a standard directx zbuffer. I’m guessing that internally the card drivers can simultaneously render to a dedicated Z buffer AND the current RT, whereas if you use a manually created RT it’s a separate call. It’s no big deal because I build up a ‘deferred’ list of depth buffer render objects in the engine anyway, but it would let me reduce my video memory usage.

To recap, I’m doing all this because I want the smoke effects to be rendered last, so I can do some clever-ass light compositing that excludes them, such as laser beams lighting up the ships they pass over.

Non-Programmer version: “Blah blah geeky geeky…Explosions!” :D

 

Sooo…consider the image below (click to enlarge) it’s from GSB 2. A ship has blown apart (no bright fire pixels yet, just clouds of smoke) and there are smoke plumes. So far so good right?

screenshot_27-02-2014_10-42-25

Sadly no. The problem is, that ship was in the distance, and behind all the other ships, but if you are really eagle eyed you will notice the smoke plumes get drawn above the ships next to it, and this is a HIDEOUS RENDERING ARTIFACT. For complex reasons to do with the way I build up lightmaps and composite them back, I can’t just draw the smoke cloud after I draw that far-off ship, and then let other stuff render over it. I do some nonsense with multiple render targets that means despite using a ton of transparency and ruling out a conventional Z-Buffer system, I have to render some things out of order. So those smoke plumes are actually rendered last, just before I do my (slight in this screenshot) bloom effect. This lets me have them work sensibly when it comes to obscuring lights behind them, and avoids other artifacts.

The problem is…I need a way when drawing them to prevent them appearing in front of far off objects. Thankfully I have z-positions for everything, so in theory this could be done, although reading up on it, it seems like a conventional z-buffer is not going to cut it, due to it being all translucent smoke particles. So… right now I’m considering the experiment or the day is for me to create my own z-buffer, fill it with the ships (and asteroids) and their z-positions, and then manually compare the z-positions in a special shader I can use for drawing the smoke plumes. In my head, I know that even if this works perfectly, it won’t work perfectly…because there is nothing to stop a smoke plume going ‘through’ a ship. But hey… we can live with that, as long as ones in the background don’t get obviously drawn on top of things in the foreground. Because GSB 2 uses a lot of parallax, it looks slightly 3D-ish, and I don’t want to ruin that effect.

This probably will all go wrong, it’s one of the many experiments you go through when you have an unusual game and your own graphics engine. In my head it seems easy. Create new offscreen render target (yikes…performance), render all of the items I want to sort to it (yikes…performance), using their z-position as the value written to it (it could be a simple and small 8bit format), then set that as a texture I can read from my smoke-plume shader, pass in the Z value to the shader and compare the two, setting alpha to be 0 if the pixel should be obscured. Job done right?

Place yer bets!

Capitalizing on the portal effect

February 23, 2014 | Filed under: business

My website looks more like a games portal than many indie developer sites. the reason for this is simple, I have more games. Depending on your screen resolution, you currently see images of GSB, GTB, Democracy 3, Redshirt and Kudos 2 on the front page. This is a huge advantage for an indie. It basically means I have five times the chances to capture a gamers interest if I can get them to my site. If you have ONE game, and you run an ad, or have some PR that drives traffic, you need to be 100% sure that visitor is interested. Sometimes they don’t like the look of your game, and they leave. In my case, if they see that big GSB image and think ‘meh’, they might be attracted to Redshirt, or to Democracy 3. That makes the site less leaky, and that’s awesome.

This is why it makes sense for indie like me to fund a game like Redshirt. I’m also hoping to fund another game. It basically doubles my output, and means each year Ideally I get two new games up there. This means halving my leakiness, and potentially doubling the return-per-click on any marketing efforts. My stats show me a lot of people bought redshirt after visiting my site direct from the main menu of Democracy 3. And vice versa. This is awesome. It’s also another reason why Steam is a billion-dollar success.

I tried to do a free thing for indies to get the same effect. It’s here. it didn’t take off. Indies are very interested in ‘someone else’ doing stuff like this, but by definition, we are indies, we like to work alone. This is a pity, but it means it’s even more important for me to continue building my own mini-portal of positech-published games. I reckon I need a game a year to stay even, as older games will eventually lose their appeal.

The maths of this are very interesting. Even assuming the ‘I was here for X but bought Y’ effect only works in 25% of cases, then previously me bidding $0.30 for a click means I can suddenly bid $0.37 instead, if I have one extra game. If I have 4 games, then I can double my bid. That’s a huge bonus. It also explains why, if you have a single niche indie game, and advertising isn’t making an ROI for you, that you may lose faith in it. Each year my PR budget goes up and up, and each year the stock of games it’s selling goes up. they are clearly related.

So I’ve just dusted off the trusty old Google adwords campaign for my site which I experimented with years ago, and will try again. Not for any specific game, but for GSB,D3 and Redshirt combined. I suspect it will do well.

positech_lb1

Sooo… I’ve been experimenting with lighting of spaceships for GSB 2. If you played the original game you might be aware that although it often looked pretty l33t, it also had a tendency to look a little ‘flat’. The lighting was always the same (apart from the odd ‘global’ shader effect, and it could certainly have had more depth. This is one of the things I wanted to address when re-doing the game. The original game just had simple sprites for ship hulls, and the new version is tons more complex and lets me do lots of magic. Basically, I combine sprites for the ships with normal maps, and specular maps and lightmaps, and use a shedload of different shaders and render targets to do all kinds of compositing voodoo. So here I present some early screenshots showing me monkeying around with the options I now have. It’s a GSB 1 ship (as a test) and it looks like ti has another one stuck to the front of it. This is a test of something else (secret!) but it shows how one ship can now cast a shadow on another (Not correctly positioned yet, but easily fixed…)

So here is a screenshot showing the bloom effect everywhere: (click to enlarge)

1

Here is one with the bloom effect turned down but the 3D bumpiness up a bit:

2

Here I turned down the exterior lighting, and may have moved the lighting direction too:

3

Now I’ve gone full-on moody lighting and likely moved the light again:

4

Now I’m in real ‘dark-battle lit only by the light of our warp engines mood:

5

You really need to see it all big screen (and moving!) to see the full effect of it all. And you also need to compare it to the original flat looking default-shaded sprites in GSB 1 to imagine the final effect with all the battle raging around it. I’m quite pleased with it so far, although there are loads of things that need improving and tweaking, and no doubt needs more optimizing. It’s a start though!

 

Build Management Hell

February 17, 2014 | Filed under: business | democracy3

This is part of indie life nobody warns you about. In your mind, you create a game, test it, upload it, then sit in front of windows showing the sales figures and the bug reports. That’s what happens right?

Not quite. The modern indie game, even one that is a pure-desktop (not mobile/tablet) experience can end up with a scary amount of build-management. If you are really organized and clever (clearly I’m not) you can manage it without too much stress. If you don’t plan ahead, you end up like me.

Democracy 3 has, primarily it’s ‘direct sales’ build on PC. This is the ‘master build’. It then has a separate build for steam, which is uploaded through valves tools. That’s 2 builds. Then there is a build for GoG without steams API in it. Then there is the build for the humble store. And also there is the secure copy uploaded for reviewers. That’s five builds. That’s no problem. Then each of those has a mac and a linux build. Ouch, that’s 15 builds now. This is a pain, but doable. Then it gets translated into French and German. Ok, that means 45 builds now. Yeah, 45 builds.

No big deal right? But don’t forget each one is about 40-50MB in size. That’s 2 gigabytes. No big deal? Try uploading that with 45k/s upload speed out here amongst the sheep. You can see why I don’t get to play any online games around ‘democracy 3 patch days’. Also, you can see just how infuriating it is when you find a bug that needs patching. 20 minutes debugging,  an hour fixing and checking, 12 hours uploading.

And because I’m so dumb, all of those builds are entirely separate, even though 95% of the files are shared across them all. Learn from my mistakes, get your build process sorted out beforehand!