Cecconoid's Camera Setup

Cecconoid’s an old school game, with an old school aesthetic, which means big fat chunky pixels on super high-resolution displays. Uh Oh.

I’ve ranted at length (on my personal blog) about some simple sins against the pixel that I see again and again in modern indie games:

  • Use of different “sizes” for pixels, across different assets
  • Rotated, or “diamond” pixels…

Both of these occur, generally, because, although the sprites’ texture is pixel-art, the sprite is then rendered to a high-res display, with no other cares in the world. As assets are scaled, rotated, or, you know, otherwise moved about in a “gamey” fashion, those poor little pixels get munged into unnatural shapes. Or worse, all that lovely filtering that’s applied to textures to make them look good, gets applied to our sprites, and before you know it, there’s sub-pixel stuff going on, bi-linear filtering, and stuff’s a mess.

I know, I know. I shouldn’t care, I should just leave it be, but honestly, I’ve walked away from games that do this. It annoys me so much.

So yeah, Cecconoid wasn’t going to be doing any of that guff.

My chosen display resolution is as close to ancient as I could reasonably get: 384x216px (1920x1080 / 5), or, at the Unity default of 100 pixels per unit, 3.84 by 2.16. To put that into perspective, the original ZX Speccy was 256x192px, so given the aspect ratio, we’re not too far out. This also works well with Box2D, as it’s expecting to be given objects with sensible kilo ranges. Our movement speeds are also going to be pretty sane and easy to conceptualise. The only problem is that the Unity editor isn’t really built for doing stuff at this scale, so your snap settings are going to be at 0.01 if you want per-pixel, or 0.16/0.08, depending on the size of your tiles. Prefab views will open a billion miles out, and most of your initial particle stuff will be the size of a small moon. It gets filddly, quickly and ugh, whatever, I give up…

Anyway. The trick to respecting the pixel, once you’ve got this far, is simple: render to an off-screen Render Target (texture), and then display that on a full screen quad. Bingo. No more diamonds. No more rotated, or sheered pixels. You can get on with your business. You don’t have any stupid clamping to do, you move on with life, and ship, looking like this:

Image 1

This is cool. This is enough to ensure grouchy old people like me will play your game and not moan about your pixels. Job done.

Here’s the game camera, that renders to the off-screen render target:

Image 5

Here’s the fullscreen quad:

Images 3

The fullscreen quad is wrapped up in a UI canvas, that’s a screen overlay on Cam_FinalRenderOutput:

Image 2

This is the layout of all that in the inspector:

Image 4

All the hip-kids try and get close to the old CRT look, and given I’m of a certain vintage, I’m obviously going to have a pop as well. The ‘best’ way to do this is to add post processing to the full-screen quad:


Stuff was low res, and things were slow. The beam in CRTs rasterscaned the computer’s output, line by line, and depending on the type of TV / Monitor you were using, you’d see darker areas between these scaned lines. If you got your nose up really close, the RGB pattern of the phosphorescent screen that the beam would illuminate, would also be visible.

We have 4k screens, so surely that’s enough pixels to make little RGB triads a thing again?


Those illuminated phosphors popped. The glowed. They bled into each other. They created final colours that weren’t in the original image. And white things used to leave a trail, like a scar across your eyeball…

Well, as much as I’d like to, adding trails to a B&W game would actually make it a little too hard to read, so I’m going to skip that. But white is going to glow. And colours (red, in my case) should bleed. Oh yes.


TVs were shit back in the day, and even your fav monitor wasn’t pin-sharp. And, I’m a fully paid-up member of the “grain makes all computer graphics look better” club. Unlucky.

Fish Eye.

CRTs were curved. It adds nothing, and tbh normally ends up making stuff look worse, but a tiny smidge here and there won’t hurt.

So lets break that down one by one. First up the scanlines. What you don’t is dirty black horizontal lines going across your pixels. Old CRTs had RGB triads, so pick your poison from the available patterns that were used. I’ve gone for:


This gives you the following, which is quite subtle:


It’s important to set this up before you do much work on the art side, because it seriously changes the gamut. You’ll notice the range of hues becomes a little muddier, and overall brightness is lowered, although I was alright, because I was mainly using white. You can compensate in the actual texture, if you want, but you can also bring it up a little with the glow, which is what I opted for.

Glow, on its own, gives you some nice bleed across the pixels. I’ve tried to set mine up so that white pixels affect quite a large area around themselves, which is kinda similar to what you get on CRT monitors, but dialled up to 11.


For the noise I’ve tried to focus it on the black areas. Just enough to create some movement, like a bit of bad reception, but not enough that you’d really notice it if you looked at any lit areas. If I was doing a game with more than two colours, I’d ramp this waaaay up. Anyway, this image has the brightness turned up a little so you can see how the noise interacts with what we have in the post-chain:


Fish eye, does what it says on the tin. I’ve also opted to add some very small amount of Vignette. I’ve not gone for the RGB separation in the corners, because I’m going to use that in the sequel to Eugatron as a gameplay effect. Keeping my powder dry for a while.

Anyway, all together, we get the final image:


That’s a lot of effort for my dodgy pixel art, but on a 4k Oled, it’s well worth every cycle. And no dodgy pixels in sight.

We ended up stripping all of this from the mobile version as there’s very little value in adding scanlines to such a tiny screen, but for desktop or console, sweating the details, even for stuff like this, gives you a pretty good final image. In my old-man opinion, anyway.

Dev Vlog: 010

I’m long overdue a video update. Apologies. Cecconoid was taking over for a while. Speaking of which, if you’ve not added it to your wish list, please do! It’ll be in all the winter sales ;)

Saving Project Lumo...

Cecconoid has been out for just over a week and people seem to be pretty happy with it. If you’ve not had a look, yet, please head over to:

There’s been a (minor) flurry of emails in the air regarding Apple’s introduction of notarisation for apps that are distributed outside of the Mac App Store. This affects everything on Steam, including Lumo. As it happens, I’ve been working on Lumo since Cecconoid was released, with an eye on adjusting the difficulty balance so it isn’t murderously tricky on a phone. The timing couldn’t be better.

To be honest, I’ve wanted to go back to Lumo for a long time. I’ve never been happy with the end sections of the game because they were put together as I was running out of cash. A bit more art, here and there, would go a long way. But the main problem with Lumo has always been the way it was built. Part of that is my fault; I took a lot of shortcuts, I bought in Asset Store packages where I thought there would save me time, and I chose to use Unity over UE4 because it was easier to get going, and slightly better documented. I’ve regretted that ever since.

The path from Unity 4.x to 5.x was horrendous, with every core system of the engine being re-written or broken in some way. The entire 5.x range of Unity was a shit-show, stability-wise (see my personal blog for rants about that). So Lumo needs a specific, hot-fix version of Unity, for every sku that exists, because there are show-stopping bugs on that platform if you use the wrong version of Unity to build it. Because of this, the console versions diverged from the PC versions, and the PC versions ended up being frozen.

What I’ve wanted to do for the longest time is try and get a consolidated build, a “director’s cut” of the game, on a new version of Unity, with most of these problems fixed. Now seems like a reasonable time to do it.

Thalamus have made good progress. The iOS version of the game is basically a port of the Switch version, on 2019.2.x, that’s running well. We’ll be able to ship that, no problem. But it’s not the version I want, as we’ll be lowering shader quality and turning off a lot of post. Not to mention it’ll have a balance tailored for touch-screen. It’s a compromise.

No, for me, the PC version has always been the canonical build, so I’ve been looking into what it would take to get that tidied up, get all the niggly, platform-specific bugs fixed, and the whole thing moved onto a new, “stable” version of Unity, and made somewhat future proof.

After a cursory look:

  • Scene management needs a re-write, as I’m on the deprecated API
  • All the use of GUI layers (all the HUDs in-game) need to be re-built, using the current UI, as they’re deprecated
  • The FMOD I’m using has been deprecated, meaning everything in-editor is broken. All audio needs to be moved over to a new version of FMOD
  • All the FMOD uses in code needs to be moved over to the new API
  • All the shaders built in Shader Forge (ie: 50% of the materials in the game) need to be re-writen as they no longer compile (Everything transparent is purple atm)
  • Post on all cameras needs to be re-done (simple) but the way I colour correct doesn’t exist any more, so most of the textures and all the lighting will need to be checked, or re-built.
  • InControl needs bouncing up to latest, meaning I’ll have to re-write the re-definable controls (I’ve hacked InControl to do what I need)
  • Steam API needs bouncing up to latest
  • The package I use for ropes doesn’t work on any new version of Unity
  • Reflections are broken (no idea why)
  • Fireworks and all particles with sub-emitters are broken (I’ve no idea why)

A few of these will have to be fixed for iOS/Android, but we’re going to ship with all the deprecated stuff, which is less than ideal.

As for the “main” version, well, it’s sold less than 300 copies on the Mac. There’s no way I’m going to do that work just to get Lumo on an updated Unity, so that I can properly notarise. The existing version of Lumo on the Mac will die when it dies, and that’ll be that.

Assuming the iOS/Android version turn out nicely (and they’re looking very good atm) then it’ll be possible to notarise a Mac build from that, and get it on a couple of the stores, which I’ll definitely consider, but it depends how much work it is to revert the balance changes. Even then, it won’t be the “PC” version, and my hopes of getting to a consolidated, official, “Director’s Cut” of the game are basically dashed. There’s no way it’s worth the effort to re-engineer that much of the game.

I’m genuinely sad about this. I was getting a bit excited about going in and polishing up the areas that I’ve always had a problem with, but it’s not to be.

I did, at least, learn my lesson with Cecconoid. I used the minimum of 3rd Party stuff, I wrote everything as simply as possible, and I didn’t use any of the Unity stuff that’s a moving target, because hey, it’s a stupid little 2D game!

So, Lumo is what it is. It will “die” at some point.

But I’ve got some other ideas.

Cecconoid Gameplay

I’ve just got the leaderboards and achievements to integrate into Steam and then we’re good to go! While you’re waiting, here’s a little gameplay taster vid:

25 Waves of Cecconoid

For some reason I’m always busier in the summer. It’s been a pattern since the last year of Lumo and 2019 has been no different. I’ve picked up some great contract work – so the rent is paid – but it’s not left a lot of time for me to work on my own stuff. 1st World Problems… But it’s worked out really well, having the opportunity to look back at Cecconoid and Eugatron with fresh eyes has been fantastic. I’ve been able to pull them apart, spot issues and tweak stuff to get them much closer to what I was envisaging at the start.

This week I did the “final” balance pass on Eugatron. It’s hard. It’ll punish you. But it’s easier than Robotron, which is my concession to modern gamers. I recorded 25 waves so you can have a look, and then I went back in and made them more difficult. You can thank me later :)

Check out the video on my You Tube Channel