About this blog

Entries in this blog

It's been a slow week for working on my engine. I've loads on at work so I've not managed to do much. I did get my GUI ported to immediate mode (all three widgets) and implemented a trie structure. This is used to store all the configuration settings and allows me to type into the console and get out a list of commands which match the entered prefix. Basically, like the source engine does.

Sadly, my trie implementation has a few bugs I need to iron out, but it's almost there.

Also, I can load in Q3 BSP files - but there's no scene graph as yet so I can't even render the entire tree without culling.

Well, here's a mock-up of what my space invaders game will look like. I've done this mainly to make sure all my measurements are correct and as a way of dumping the image I had in my head onto a reference image. This is also to scale, 640x480.

Not a great deal to look at, what with all that amazing programmer art (original though, I'll have you know [smile]), but as long as I finish it I won't mind. I'm planning on working on it consistently this weekend but if I come back to it after work each night next week then it's no big deal.

So, I'm writing a 3D engine for which I hope to make some demos and maybe even a simple game. This is all in the hope that I can score a job in the games industry. Currently, I'm a Business Applications Developer at Kuju Entertainment in Surrey, England. It's a foot in the door and plays up to my previous experience but I'm hoping to make the transition to games development in future.

There's a screen shot attached of the current state of my engine, the console doesn't actually have an edit box as yet - I'm porting my GUI to immediate mode this weekend.

In the coming weeks I hope to inform those who care about my progress. I've been programming for many years now and I'm currently on an industrial placement for my third and penultimate year of university. I'm studying Software Engineering and I'm employed as a .net developer in Newcastle, England.

I'm trying to make that giant leap across the programming chasm towards game development. I've attempted this on a small-scale in the past, mainly with OpenGL and random demos that I wouldn't grace with the term 'game'.

I've been lurking on GDNet forums for some time now with the usual illusions of grandeur that accompany aspiring game programmers. However, it's time to get serious and start from the beginning.

So, after years of starting projects and never getting the time to finish them, I have broken in to the games industry.

I'm currently a programmer on the logic team at Beautiful Game Studios / Eidos in London. It combines my two favourite things - football and programming. I dunno how I've managed to get where I am, but I have and it is awesome.

Finally, I've got something to show for my Quake 3 BSP renderer. This is in no way optimised (I'm simply throwing the entire face list at the gfx card), but it is definitely progress.

As you can see, although it is textured, the sky box isn't. Also, the gaps are due to not rendering bezier splines yet - I haven't written any tessellation code yet. It looks quite a bit too bright and I'm assuming this is because I'm not using the lightmaps as yet. So, overall, it's rough but it's a decent start.

I have a lot of refactoring to do before I start adding more touches but it's going pretty well.

Thanks go to paradoxnj and others in the forum who helped me try to figure out some rendering issues that, as ever, turned out to be due to my own stupid idiocy!

Work has eaten my time this past week. I found some old code from a past (failed, shock horror) game project. It was in C and I thought I could thieve/reuse most of it as a base for Space Invaders (after porting it to C# of course [smile]).

I had a look through and I remembered doing something pretty interesting that helped me with a problem that I don't think is mentioned much: Switching what is rendered and what inputs are taken in a game. For example: your main game menu looks entirely different to the 'main' part of your game and it takes different inputs. How do you manage these different situations?

What I had done is implement a RenderMode table which linked a number of callbacks to the bits in an __int64. This allowed me to toggle drawing things to the screen by simply bitwise XOR-ing the relevant bit in the current RenderMode. I could then bitwise AND each RenderMode in the lookup table with the current RenderMode and if it came out true I would call the relevant callback which would draw something to the screen.

This then extended to my input functions where I would associate each key (mouse or keyboard) with a callback and a RenderMode- ensuring that some keys could be painlessly reused for a menu or in the game proper.

I'm currently porting this code over to C# (using ulong so I get the possibility of 128 unique RenderModes) hopefully it will be as much of a success as it was in C.

I'll post the C code if anyone wants, I can't be bothered to upload it if it ain't gonna be used [grin]