I may have gotten a bit distracted by I have finally completed the key-value store component of the C++ Object database I'm building.

Another side project that I've been meaning to write for years. Given a set of rectangles what is the minimum area rectangle they can be packed into?

It's a marginally useful question for packing 2D images. Marginal because todays graphics hardware has enough memory that's it's not necessary; but stuffing everything in one texture does reduce state changes.

The screen shot below shows each of the Star Control ships (and some Star Control 2 ships) rendered out with 72 frames of rotation at a resolution of 512 by 512 and then packed into a single 17375 by 5929 texture.

Transparent borders are clipped which produces a huge saving as small images - the nuclear missile, Ur Quan figter etc... - are packed very tightly. You can see them squashed into all the empty nooks and crannies around the larger ships. Note the screen is zoomed to 50% in the screenshot.

Clipping transparent borders has reduced the total area from 1.7 terrapixels to 412 megapixels. Almost an 80% saving.

ps: For those who can't post on account of blogger giving an error about post time: Illegal post time (format is: hh:mm AM/PM). Change your language from English (South Africa) to English (United Kingdom). It's under settings.

I'm still working quite hard on this. I haven't had much meaningful to show which is why the dearth of updates. I've finally come full circle back to Space Crusade although I'm still working on Star Control as well - the two are merging closer and closer together.

An editor piccy of me editing the Space Crusade map with rips from the C64 version. Yatey has a general XML/CSV output so I can load it in and convert it too whatever form I want later; be that 2D tiles or actual 3D models.

And below is an import screenshot although it may not look like much. It represents the first time the engine has no known bugs. That's not to say it's feature complete (not by a long way) but every feature that is complete appears to work as intended. Given that I now have more than 9000 tests backing this up I can make that statement with some certainty.

And a happy new year to all,

Later!

Hey! It's an update. I've been off one of my fairly standard tangents(tm) and gone and written a general input library because I dislike every other input library I've ever used. You might have realised this by now, I've ranted about it enough.

The problem is that most windows (game related) input libraries are thin, pointless wrappers around DirectInput. Now DirectInput is pretty cool in many regards but it has 2 major failings. It only supports one keyboard and mouse and it doesn't support XBox 360 controllers properly. The lack of multiple mouse support has been a bug in DirectX in every Windows version after '95 - I'm not sure why it's never been fixed :(. The lack of XBox controller support is more insidious; Microsoft have deprecated support for DirectInput in favour of XInput. XInput is, unfortunately, a steaming pile of poo. It supports only the XBox controller; it's hard coded to 4 of them and it's also hard coded the inputs - there can be no support for any future game controllers without a new version and a recompile.

So XInput is technically deficient, looks like it was coded by a 3 year old, and doesn't support non-Microsoft certified devices. And there's my other big issue with it. It looks like a ploy by Microsoft to corner the hardware controller market; if developers stop supporting DirectInput then only XInput certified devices will work. Not cool but understandable from Microsoft's perspective - DirectInput doesn't generate revenue for them whereas I suspect XInput does at least enough to cover it's development.

I tried avoiding the DirectInput/XInput fiasco completely by using WinRaw and WinJoystick directly (they're lower level libraries but are curiously more usable) but that still didn't solve the XBox controller issue. I even tried querying the XBox Controller using it's mini-HID driver but still no joy. It's support is hidden behind even the HID driver and that is curious indeed. It means that someone has gone to an awful lot of effort to hide support for the XBox Controller from every input library other than XInput. It's not something that could have happened accidentally.

But that's enough ranting. What I've done is written a thick wrapper around all the different input libraries and consolidated their different types of output into one consistent event based stream. This means that pressing a button (or whatever) on any* joystick, keyboard, mouse etc... on the system is reported in the same way and the game built on top of the library doesn't need to know how the different input libraries function and interact (there's some nasty duplication and cross-talk between them).

Instead of having to write firing the primary weapon as If 'XBox Button A' or 'Joystick Button 0' or 'Keyboard Left Ctrl' or 'Mouse Button Left' then then Fire I just write a method called Fire and it will be activated by whatever button the players bound to it. This makes my life much, much simpler now although maybe not everyone is going to appreciate that I took five/six months to write this because if I'd hacked out the code for Star Control I'd have been done more than a year ago :).

And here's a picture of my desk. Lot's and lots of lovely input devices (there are more keyboards and mouses on the shelf under it. For testing I've added two 4 port usb hubs inside the case - the wires and dongles behind the chair - but was still unable to plug in everything.


*Wii-motes not included yet although I can read from them. Parallel- and game-port joystick also don't work and it's unlikely I'll ever bother. MIDI devices are also not included yet so you won't be able to play Star Control on your piano keyboard. You'll deal.

I haven't had a chance to work on this since before my May (office) deadline - which has become a bit fluid. None-the-less I'm still here.

Time for a short update. Deadlines at the office and being buried deep in the world of code have made this a boring place of late. To liven things up a bit I did a small mock-up of the SC title screen.


It's amazing what even a spherical environment map can do. Hope you enjoy it.

Later!

I'm still alive (making a note here: huge success ;) ) and still working on Star Control. The screen shot below is *not* a mock up of a Vux Intruder vs an Earthling Cruiser. The two ships fly and are moving correctly - albeit in the wrong language (C++, not SmallTalk).


Not much else to add other than that things are still progressing. Here's a pair of screenies of the slightly updated ships. I doubt they'll change much in the future so these are probably final.


Later!

I may have gone completely off my rocker as I'm considering implementing Smalltalk and then using it as my scripting language. I'll let you know how that went after they let me out of the loony bin.

Laters!

I've been working on the gameplay side of the engine which doesn't lend itself to pretty pictures. However it is coming along quite nicely and should be usable before Christmas.

Things are somewhat uncertain as too whether or not I'll meet the Remakes Compo deadline. I might just manage it or I might not... time will tell.

Here's a screen shot of the title screen. The explosions been edited in and the glows on the words and the atmosphere are cheated but real. The starry background was generated by Zeracles of The Pages of Now and Forever.


That's all for now,
Later!

The engine is practically usable now so I've switched it's status to beta. It's been a long road and it's profoundly relieving to actually have it in this state.

This is a short post because I'm still cleaning up a few odds and ends but nonetheless this is a major milestone.

Hopefully you'll see something prettier in the near future!

Till then,
Later!

RetroRemakes 2008 Big Competition. StarControl.



'nuff said - I'm busy ;)

Later!

After a bit longer than initially anticipated I'm finally done with my image routines rewrite. Yup, there's an entry from June 2007 where I mentioned I was doing a bit of a refactoring... Well now it's done - somewhat more than a year later ;)

The image below is the fruit of my labour. Appreciate it. Appreciate it with great appreciation! The left-hand side is the RGB channels and the right hand side is the opacity channel. The images are from libpng and are in various formats (1bit per pixel to 16bits per pixel). The red gap in the center is the palettised images which I've decided not to support as sharing a common palette between them broke my project structure quite badly.


This rewrite was necessary as I can now export much more complicated textures. I can now support normal maps, specular maps, oppacity-only maps and whole bunch more. You may have noticed that there hasn't been a screenshot with a texture in it for a very long time... well there was a reason for that ;)

A good part of why this rewrite took so long was because an image can be composed of an arbitrary collection of channels of arbitrary types. For instance: the RGB channels are generally |Byte|Byte|Byte| but add a UV displacement map into that and you could get |Byte|Byte|Byte|Float|Float|. That was a really bad example but it illustrates the problem, particularly as the ordering of the channels can also be arbitarty; eg: ABGR or what-have-you.

Expect to see more colourful screenshots from now on.

Later!

After a bit of a hiatus I've managed to get some work done. Sadly it's still of the coding only variety so instead of posting what I've done I'm posting a few more screen shots from Alpha Strike.

Here's the insanely hard fourth stage cumulating in a fight with a massive... ah well you'll never get there so it doesn't matter.


The third stage: a desert full of rolling thunder, stationary turrets, bunkers and warehouses for the sovereign war machine.


The demo stage is also the second stage and is probably the most balanced difficulty wise. Remember to stock up on ammo before facing off against the end boss.


The first stage takes place over the ocean amidst rolling clouds. Although in all honesty; it's sodding boring but does guide the player into Alpha Strikes mechanics gently.


Well enjoy, perhaps it'll even be released some day. Provided Garage Games fix the awful physics slow down.

Later!

Again I've got an awful lot stuff done but have very little too show for it. So instead here's a peak into my disturbing and deranged development process. Below is snapshot of my schedule (as provided by Justin :) ). Note that there are still 400 hours outstanding. And that doesn't actually include writing the game. Urk.


Also as I've just finished a major milestone (I'm done with the database) here is some of my test output. It looks a lot more interesting when things fail but I don't want failures so... buggerit.


Now I'm moving back to cleaning up my "language" as I've thrown out Ruby. It's quoted because it's not a complete language. It doesn't have a parser or even any sort of textual representation - the entire thing is written programmatically (in C++) but that's good enough for the time being. After completing The Abandon Wars I'll clean up my tokeniser and preprocessor.

Also still on the cards is fixing my UI Framework (see some of my earlier posts) as it is now quite broken but was always geared to be used from a scripting language (ie: anything other than C++).

But that's enough of that. So...
Later!

Things are still ticking over, I just don't have anything pretty to show. I have optimised the graphics routines in Harrier Attack quite a lot. I now no longer draw transparent borders (ie: I clip them off). This has decreased the frame-time under linux from ~21ms to 16ms. Which is significant as it means the game runs at 60 frames a second with all detail.

Mostly I've been working on the Abandon Wars front. Again, nothing to show but lots of refactoring and bug fixing. I now have a project plan for it too.

Laters!

I've been 'briefly' side-tracked yet again ;). So instead of Space Crusading I've been working on... well... Harrier Attack. Now renamed to Harrier: The Second Sortie. Enjoy the screenies below.


The frametime shouldn't ever climb above 16ms but as I haven't optimised the collision detection yet the shot below has made it all the way to 20ms. Also when running under linux it's significantly slower (by about 3ms a frame). I'm not sure why yet.


I've also got a project manager now, thanks to Justin and his 'self correcting schedule'. Sadly the self correcting just refers to the estimate. It doesn't self correct by doing work I should have :p. Maybe in version 2 ;)

Later!

Finally done with the art. The green alien took alot longer to setup than I'd expected :(. I didn't mean to post this but he now gets his own thank-god-I'm-finally-done post in celebration.


And that is that!

Later!

I'm done with most of the rigging, which brings me to a close on the art front (Yay!). All that's left to rig is the green alien and the white alien. When that's done - tomorrow? - I can get back into programmy world.

Below are two mock-ups of the rigged models. What's happening in them I can't say. Why are they throwing their comrade into the cracks of doom? Was it a tragic skipping accident - all but avoidable if they'd just taken the proper precautions? We'll probably never know.


This next screenie is going to be the briefing/mission select room. Hopefully with less lounging around next time ;)


I've also done a bit of works on my object database. Durable file writing in transactions actually work now. Not nearly as interesting as the above but ...

Anyway, that's enough of that.

Later!

I'm declaring myself done with the modelling now. The last three enemies are in. In Space Crusade terms they are:

Red Alien: Soulsucker
Green Armour Alien: Chaos Marine
Red Armour Alien: Chaos Marine Commander
Android: Android (duh!)
Big Mech: Dreadnought

The other two aliens not in the screen shot are the Gretchin and the Orc (The purple eyed green thing is the Gretchin).


Now all I have to do is rig everything. *sigh* there's no rest for the wicked. Having said that I'm off to do some coding instead. I've almost fixed my database transactions (again).

Later!

All the level blocks are in now: ceilings, floors, walls and doors. I quite liked how the brass lockers turned out; much better than I expected and it breaks the boring monotonous grey.


The whole level is shown below. The wall 'caps' and 'replacers' are in. The caps are the yellowy things on top of the walls and the replacers replace the walls which would otherwise hide the characters.


The characters are still faked and I'm not sure I like the transition between real walls and replaced walls. Anyway...

Later!

Today I've found myself in a rather strange situation. I've got to much stuffs too post! I've been tearing through the art assests and an end is actually in sight.

I've redone all the ceiling caps (the bits on top of the walls) they look *much* better than the previous set. I've modelled and rigged a funky little crab alien beastie - probably not going to go into Abandon Wars because it's to flat to see.

I've added another fourteen wall pieces. And the first major prop - the generator in the screenshot below.


To get that look I'm using all eight lights - the maximum I currently allow - and I still had to fudge the contrast a bit. For those who care the original reference looks as below. (Somehow I was shooting and hit print screen at the same time - special).


See, it's Space Gun which is providing all the graphical inspiration (for those who didn't realise that from my last post).

I've also modelled all the marinettes weapons though I don't particularly like how any of them look. And lastly I've started modelling the other mechanical unit (the android equivalent).

Later!

A quick update I've put in four of the enemies. I'm still missing the Soul-sucker equivalent and the Chaos Marine equivalent. I'm going to add the Chaos Marine as some sort of mechnical unit but I can't be bothered to put another humanoid enemy in.

Next up I'm going to model a sort of face hugger style unit and an egg. Rivetting stuff this ;)


And if this isn't just screaming Space Gun at you well... then you probably never played it :).

Later!

So here's the deal with Space Crusade: as I mentioned in my previous post it ... well ... isn't anymore :(.

There're a number of reasons for this the foremost being that it's someone else's IP - with the release of the new Warhammer game (2009) the Warhammer universe is a pretty toxic place to be at the moment. Also with Dave completely addicted to online gaming now; it seems unlikely any models will be forthcoming this year (and it's been more than a year since he first agreed draw the Space Crusade models).

All is far from over though: I am now doing all the modelling myself and am no longer playing in the Warhammer universe. To that end I have learned to model - somewhat ;) - and I have modelled the first team of Space Marinettes. I am retaining most of the gameplay but without the dice and the Warhammer rules.


This is the first character I've ever modelled (and practically the first character I've ever attempted). Actually the red girl was the first modelled and the purple girl was the last.


There are a quite a lot of mistakes; due mostly to my lack of knowledge of the human form. Seriously - it's bloody complicated ;). But also a couple technical stuff ups which I just can't be arsed to fix.

So that's the team - they have names and designations and everything. Variously: Opal (purple) is the leader. Ione (red) is the medic. Adelle (green) is heavy weapons. Saffron (yellow) is demolitions. And lastly Page (blue) is communications. It's a bit of break from the Space Crusade gameplay but I think having specific roles should make things more interesting.

And I need to sleep now.

Later!

Just a quick post as I posted yesterday. I've finished modelling all the walls and floors from the first stage of SpaceGun. This means I can begin with the actual characters tomorrow! I'm having quite a lot of fun actually :)

Below is the end of stage lift from space gun.


On a slightly more Space Crusady note; I've also built the entire first stage (Search and Destroy). The first screenshot is the c64's isometric view and the screenshot below that is the same view from my map.


I haven't modelled in the ceilings because the original didn't have ceilings. The marine is standing in the room marked by the cursor looking southish.


The bad news is: I'm not actually remaking Space Crusade anymore. I've since deleted that map. It was just a proof of concept anyway. It did conclusively prove that I need a real modeller/editor to actualy build the stages - there a *lot* of floating point stuff ups which why the lights are so dark.

Don't despair: I'm still writing a Space Crusade like game (see 2 posts ago) but it will be more like a cut down version of Silent Storm or XCom.

Later!

I've taken some time out of serious hating at BMW (10 weeks without a car and counting) to get a bit of Crusading done. I've finally reallised that if I ever want anything done I must do it myself. To this end I decided I'd better learn to model.

I've modelled about half of the walls so far and should begin with the alien characters next weekend. The picture below is a quick mock-up of my first attempt. It's a bit bland and textureless but I thought it had promise.


Fortunately my second attempt is quite a lot prettier. Whilst there are still no textures, Nebula RCW49 gives it just enough colour to make it interesting. The ceiling and floor are place holders - I still have to model them aswell.


If you're very observant you may recognise that the walls and crates are from SpaceGun; my all time favourite 'Gun game. I fully intend to nick the aliens from it too :)

Which brings me to a close as I must get some sleep now. So...

Later!

Well I've done very little work this year because I've spent the last 8 weeks without a car and every day has been a fight with the insurance company. Anyway, now that that is almost over I have the energy to get some Space Crusade'ing done again.

If Dave ever gets over his COD4 addiction (and that's most definitely the right word) he's agreed to model some marines; or marinettes rather... Yup he's using the image below as one of his templates.



I don't think I'll be seeing any models until I get the engine up and running again but at least it provides a bit of incentive to get it going soonest.

On the programming side I've rewritten loading and saving and I'm quite chuffed with how well it works. I also briefly mucked around with 3D textures again (last time I tried was DirectX 6 I think) and I'm still not convinced...


Short and sweet...

Later!

Whoops, I went on a tangent and wrote a small Harrier Attack remake. What I was trying to prove is that Java is capable of high performance 2D games.


What I did prove (quite conclusively) is that it is not. The screenshots still look quite pretty though. In fact they should look quite familiar to anyone who's written, say, Chickens 3 :)



The problem is AWT seems to render very slowly (even when using hardware acceleration) and I really should be getting more than ten frames a second for this :(.

On the other hand my memory manager IS fast - I'm really quite impressed with myself *grin*.

Anyway I didn't actually mean to post this ;)

Later!

I thought I'd better post at least once more this year; and to liven things up a bit it's even Space Crusade related!

Well... not specifically Crusade related but building in the right direction. I'm still working on my reference counting memory manager though it is a little bit more now.

The short of it is that each object in the scene graph (provided by the memory manager) knows it's class and can query fields and methods on it. These can either be used directly from C++ or from a sort of scriptless language. C commands can be chained together to perform simple tasks without the task being written at compile time. I've only used this for image filtering but the possibilities are (as they say) endless.

Below is a screen shot of (a part of) a smart objects header. Notice that a smart object knows all the objects which reference it: pcFroms.


Most objects are rarely referenced by more than one or two objects and if this is the case then additional memory does NOT need to be allocated to track those references.

If more than four objects reference 'this' object then an array of pointers is allocated.

These reverse references are important because they can be used to calculate a path back to the root object. If a path cannot be found then the object is not forward referenced from any other object and it can be deleted.

Most importantly each object knows it's distance from the root node (as shown in the screen shot below) which makes finding a path to the root trivial.


In fact knowing the distance to the root enables whole object trees to be discared in better than O(log(n)) time - where n is the number of objects in the scene. This is - I think - faster than any garbage collector and because there is no garbage collection phase there are no nasty program pauses.

The thing I like most about this scheme of memory management is that when the last object referencing an object tree is deallocated then the entire tree can be deallocated. Importantly this means that the deallocating thread can deallocate the tree and the program can remain utterly single threaded!

Anyway, that's enough technical stuff... I've also posted a picture of my snazzy new UPS. Those still living in SA will know why a UPS is important now :(



Interestlingly it's only rated to 600 Watts but it's handling two 300W power supplies and two 100W monitors at half it's maximum rating. I was pleasantly surprised ;)

And that's enough of that.

Later!

I've found a few screenshots from some of the projects I worked on at I-Imagine on their old website. For my own nostalgic reasons (and too keep this blog ticking over) I've decided to post them here.

This first image was from Chase II, a project we began directly after Chase (if the brief and ill fated D.A. Dork GameCube project is ignored).



The next image is from a Champ car game which was actually quite fun and the AI was really, really difficult. I think Etienne may have written a paper on it.



The last image is from a demo we did for Code Masters and is easily the most detailed project I've worked on. It definitely gave the PS2 some trouble although I think the XBox handled it fine.



And that's that.
Later!

Still side-tracked but going strong ;)

Later!

Finally, I'm working on Space Crusade again! It's been a while since I last had a fling with C++ but it's good to be back in the realm of pointers and preprocessors ;)

The long delay in posting was variously because I was in mild crunch at the office (July), then learning Torque Game Builder and writing AlphaStrike for Dave but mostly just being lazy.

Incidentally I think AlphaStrike (Dave's name) turned out pretty well though I wouldn't touch TGB again, not even with a barge pole.

Here's a few screen shots...


Flame throwers rock the party!


Taking on a few helicopters... player one's a lazy git ;)


That's enough with the 2D.

I've had a sort of half language running around for a while now and it's proven really useful. Unfortunately the fact that I never fully finished it has come back to bite me. This means that the next few weeks are being dedicated to rewriting/refactoring it into something workable instead of doing Space Crusade specifics.

I'm mostly rewriting the object/struct/primitive/whatever representation as the current one is a bit limited. I strongly suspect I've left the beaten path but it's going to be fun.

Later!

Removed DRM rant as it wasn't Space Crusade related.

I've been to busy to get any real crusading done this month, what with the system at work going live and all. Expect the next major post sometime in August... :(

Later!

It's been some time since my last post. Not because I've stopped work on Space Crusade; I just haven't had anything to show.

Unfortunately I still don't have anything to show. I am deep in a rewrite of my image library (which used to be a nice simple 32bit ARGB format). Now an image is a set of channels which can be fairly arbitrarily assigned.

Notably my new image format allows me to easily handle images which have the usual red, green and blue channels but also opacity, specular intensity and normals all packed into one together.

Wether or not this was necessary is probably a question best left unanswered; however it has been an interesting programming exercise. Particularly with regards to keeping the performance of the old naive 4 byte implementation ;)

Heres a screen shot of some of the core library tests - which I've also been putting quite a lot of work into. Massive testing has been required because this rewrite is affecting so many other sub-libraries.


I haven't seen the need for a unit testing framework yet so for the time being each test is just a function call. No complicated setup or tearing down is done (these really are unit tests) so it is unlikely one test will affect another but in the case where it does I don't mind it causing tests beneath it too fail.

On a more game related note: At the top I've posted that I'm continuing work on Space Crusade - which is true - however I am toying with the idea of another much simpler remake.

Too this end you will see a picture from StarControl 2 below. I do not in anyway intend to rewrite the single player game(!) but I am giving some thought to rewriting the Super Melee.


This rewrite will also give me a chance to do some ship modeling - which I've been itching to do for some time. The ships are generally simple and well within my modeling/texturing abilities.

Lastly (and I almost forgot to mention this) I have some musical tracks for Space Crusade now. They've been composed by Jaco Pretorious who will hopefully get a chance to do some more (hint hint) :)

Later!