Not Skeletal Animation

The set of points from last week were the raw data of the "skeleton" of a Hellknight from Doom 3 - I'd intended to have skeletal animation at least somewhat working by today. No such luck, though I did fix the final issues of native library loading - it can now manage its own native code entirely, after adapting to some updates to JOGL, with a patch to skip over the part that my code already handles.

On the 3D printer, I added the Y-endstops (both home and end), and calibrated and tidied the wiring almost completely. All that remains before actually printing parts now is the X-axis belt and endstop setup (and using a spirit level to re-level the machine). A heated bed might be necessary to get the best-quality prints, though I'll see how it performs without first.

The motor for my moped arrived, too...

Finally, if you haven't already got it, there's possibly still time to pick up a copy of the Humble Indie Bundle (4) - pay what you want for some pretty awesome games (probably most notably, Super Meat Boy and Shank, both of which are gore-intense but brilliant games).

Charlie

Big steps

So, I've made some pretty big leaps forward in the game programming: 

First half of edge detection

For the anti-aliasing, I decided to use a method pretty much exactly as used in STALKER - so far, it's only detecting edges via the surface normals, but soon it'll also use the depth buffer, to ensure that all the edges are "caught" (look at the pot on the left - its edge hasn't been detected because the change in surface direction between the two surfaces isn't great enough. Once all the edges have been detected, it's a simple and quick step to blur them and so cheaply "fix" aliasing.

This step is a post-processing step, as is SSAO. I've also started to implement SSAO, though it needs configuring for the scene, and the blurring step is still not yet complete - it has to take into account depth, or the shadows will "bleed" onto bits they shouldn't. The final steps are exposure and colour correction - colour correction I've already done, but in lower-quality versions, and exposure is still in the works (fixed exposure only works at the moment).

I also wrote most of the intersection tests, which are going to form a fairly important part of the physics system, level layout and rendering optimisations. The overall plan is that every object in the world will be given a "bounding box", and quickly checked against the feature in question (for example, for checking if an object is visible, it's checked against the viewing frustrum, or for physics, a ray representing the motion of an object can be checked against anything it's likely to collide with). This can be optimised by including all objects in a "tree" of bounding boxes, where each bounding box node completely contains all of its children, so if the parent is outside the area in question,all of its children can be quickly eliminated.

The framework for a download and resource manager have been started - allowing files to be queued and made to download or update, and for resources no longer visible to be unloaded completely to save graphics memory.

I also tidied up the controller code somewhat for Windows - it can now get the proper analog values, and detect the type of controller and battery level (and interestingly, also the type of battery in the controller) of Xbox controllers. Almost completely pointless but cool nonetheless.

Finally, a teaser, most likely for next time:

No clues as to what this is for yet, but it should be interesting...

14500+ lines of code now, 333 TODOs listed.
Charlie

XInput

 So, I spent far too long working on getting the Xbox controller working - instead of using their standard input libraries, Microsoft in their infinite wisdom chose to make a separate API for the sole purpose of interfacing with their controllers. As a result, I ended up downloading a C++ IDE, and using Java's native code to work with those APIs. On the plus side, it means that the vibrate and separate polling of the triggers can be done (using the previous method, only Trigger (R-L) can be read not R and L separately) , but under Windows only.

Other than that, I tidied up the native code loading further - it now "cleanly" loads nearly all of the dlls or modules needed to run independent of platform and architecture (I still have to fix nativewindow though). Lights are now configurable in the engine rather than hard-coded into the shader (simple change but an important step), and I've started to write the basic game code/world itself.

Stuff I still need to do:

• Intersection tests/resolver for physics, area scripting for levels
• Scene optimisation
• Decent gameplay code
• Improve the importer (bring lighting, more material properties in)
• Finish lighting optimisation - actually do the stencilling - additionally, light clip volumes
• Antialiasing
• Shadowing
• Audio

Charlie

Small Steps

So, I finally sat down and spent a couple of hours coding the engine. I've started to tidy up my code layout and sort out decent input and gameplay - and in part of that, I bought a USB Xbox gamepad and played around with using it as an input. Unfortunately, the rumble feature is broken in the library I was using but otherwise, the controller works nicely and gives a nicer feel to motion - it's much smoother than a keyboard, and seems a fairly natural way of controlling a platformer-style game. I also added some very basic mechanics - nothing more than the basic laws of motion at the moment, and nothing visual either. 

Still planning to have something "playable" (i.e. vaguely resembling a game or game engine) by the end of the year if all goes well...

Charlie

Super-Secret Project

Another terribly-short-and-limited blog post to follow, so I don't blame you if you skip this one. Work, parents' evening, and the super-secret-project have been taking up most of my time. In no particular order, I have managed to:

• Sort the 3D printer bed out - glass cut and bored successfully (or nearly finished, need to tidy and finish the holes)
• Nearly-finish the lighting optimisations - stencils are now working, and now just need to fiddle around with how the information about lighting is stored (radius, colour, position, shadow-casting)
• Finish most of the programming on the super-secret project for the time being. Hint: it involves multiple virtual servers, a simple database, plenty of permissions, various types of buckets, and voxels. 
• Buy far too many games - RAGE, Amnesia, L4D2, FEAR series, and a couple of indie titles. I might do a mini-review when I get around to playing them.

I leave you with an incredible video - worth watching in HD.

Charlie

Bugfixes

This weekend, I got to see a legitimate Robot Wars battle at the NEC - two flipper-armed robots throwing each other (and themselves) around. I also saw and spoke to a couple of engineers on the Bloodhound SSC project and saw the vehicle itself.

On the game, instead of coding anything new, I went through some of the very worst bits of my code and carefully removed a few of the worst-offending bugs.

• The first one was that resizing the window would not resize the stencil buffer, resulting in some fairly unusual artifacts appearing. It took me a fair while to notice that I was actually allocating the buffer twice, and corrected it. Now I have stencils, which makes culling pixels for lighting very easy now.
• The second one was a silly mistake in how I handled texture path names. I'd been doing it in a silly way (hard-coded slashes, which is death for cross-platform compatibility) - I went through and replaced most of them with the appropriate platform-independent solution. 
• The final one was a complete pain to find and kill - I found that when changing camera angle with bright lights in the scene, the lights would flicker in a fairly irritating manner. I checked and double-checked my entire lighting code several times, as well as the matrix transformation, before realising that everything was (surprisingly) perfect. The actual issue was that my normal buffer was at too low a precision to make the lights adjust properly over a wide range of viewing angles. Unfortunately, a side effect of increasing the precision is that the lights now take longer to process - now, 800MP would seem to take (very approximately) half a second to run, giving me 16MP to use for lights, not 32MP (which is fair, given that I doubled the bits). It remains to be seen whether changing some of the other calculations (inverse of the matrices, reprojection, etc), lowering precision (8-bit floating not 16-bit floating buffers) and/or constraining the areas will be enough - though there's no reason it shouldn't. 

I also managed to fix George's PS3 for the second time and started work on a super-secret project, which is going to be revealed fairly soon (on or before next week).

In Motion

The printer is finally moving of its own accord - I discovered a work-around for the firmware issue. Connecting the Arduino via USB, connecting in RepStrapper, and then finally applying power to the shield allows the board to connect. The thermistor readings work fine and I'm pretty sure the heater MOSFETS do too, but the stepper boards get too warm to work effectively - I should have some thermal epoxy and old aluminium heatsinks spare to sort that out, though I dislike making any permanent changes to hardware (and that glue is just about as permanent as it gets). At the same time I should also be able to heatsink my 1W laser driver too, and get some pretty pictures of the beam at full power, without it cutting out as the thermal limiter kicks in. The only other option is to buy a new and higher-power circuit instead (torches have higher-power boards but with much less tight regulation, which should be OK for a tough laser diode, though it may shorten the life-span somewhat).

I've also played with the lighting shader code, and worked out that changing the data types (the "quick fix" solution to the lighting speed) is simply not enough to bring the time down to reasonable lengths - it saves a about 2 ms for 800 million pixels - not nearly enough. The only reasonable solution now is to apply the lighting calculation to less pixels - using an estimate of 0.75ms/4MP, that means that lighting can "afford" to light about 32MP and still leave enough processing time for pretty effects like depth of field, ambient light, SSAO and another lighting or material pass for skin, particles, and other effects. To restrict 100 lights to 32MP, the average visible light radius can be around 300 on-screen pixels, which is pretty reasonable - in a cluttered scene many of the lit pixels will be occluded anyway, so drawing the light with a depth comparison might save even more processing time. Shadows are also relatively cheap with this method but will still need careful planning. All of these estimates are based on a fast card at high resolution though, so others' mileage may vary.

Charlie

Thermistor Trouble

In the last week, I've added multi-lights, tidied up my current lighting method and planned/written the beginnings of a skeleton-loader - the Doom 3 format is particularly nice for my purposes. Lights are currently too inefficient - 100 simultaneous non-shadowcasting lights run at about 7fps at 2560x1600. Admittedly, I've taken some horrific shortcuts in the pursuit of simplicity (right now, for every pixel on the screen, for every light in view, it generates the inverse of a 4x4 matrix - not exactly a speedy process).. When I fix that particular source of inefficiency, I'll re-time everything, add shadows, and see if it still needs more work. After that is skeletons and game logic itself.

As for the 3D printer, I (badly) drilled the holes through the glass bed - it's still usable, but has some irritating cracks. The firmware is unfortunately proving to be a bit of a pain - I haven't managed to get everything working reliably. I remember having a similar issue previously, which I think ended up tracing back to the thermistor board, of all places. The board currently sends back a "start" signal, but doesn't do anything useful afterwards, and drops the connection. With a bit of luck that issue shouldn't take much more time to trace down and I'll be all but ready to print!

 Charlie

Normal Mapping

I took a bit of time off from working on the 3D printer to get back into the coding for the game. I designed and added a basic model format (one which requires nearly no interpretation before it can be sent to the graphics card, which cut load time in half), and implemented normal mapping:

Left-hand side: No normal mapping. Right-hand side: Normal mapped.
You will need to see the full-size image - note the detail on the lion's face and roughness of stone.

Normal mapping takes a flat face (for example, the pillar on the right) and adds small peturbations to the direction in which the surface is facing, based on a texture. These changes can add virtual roughness or smoothness to a surface without increasing the geometric complexity, which can make the surface lighting look more realistic, at a minimal performance hit.

The TODO list before something playable is ready:

• Skeletal Animation
• Audio
• Streaming System
• Game Logic
• Mechanics
• Shadows/Specular Power/MultiLights/Graphical Tweaks
• Basic AI
• A world/level to experiment with.

I'm aiming to tick on average one of these off per week, and have something completely playable by the end of the year. It's odd to think that I first played around with this code around New Year's time, and have now been working on this, on and (mostly) off, for almost a year!

Charlie

Ready to Print

The printer is now physically all but ready to go - all that remains is to finish the print-bed and belt, wire up everything and sort the electronics. This post will be edited when I finish.

It Extrudes!

After a weekend of heavy tinkering, I finally got the printer to spool a fair amount of plastic through the nozzle. The only bit I have left to finish now is the print bed, endstops, and the final bits of wiring/calibration - and then all of the optional bits, like insulation and taping the motor to reduce slip.

The very first stages of the extruder assembly - the clamp on the right grips the  plastic filament tightly. The grub screws (in theory - not on my first run!) hold the hot end in.

Later stage of the extruder construction - the big cog is driving the bolt, which in turn drags the filament through.

The near-finished extruder, now with motor.

No photos of the rest of it yet, I simply didn't have time - the SAQ isn't exactly the quickest form to fill out...
Charlie

3D Printer

Prusa Mendel so far

So, I spent a fairly long time over the weekend assembling my 3D printer. I'm still waiting for some bearings for the extruder, the print bed. and the final motor but otherwise it's all ready to go. Not much else to say, really, except check back soon to see it printing!

Charlie

I've made little progress with the game - what I have done has been mainly aesthetic, no physics yet. Normal mapping is almost finished - just need to compute the tangents and it'll be ready. On the plus side, I've made decent progress with the moped - it's in a decent condition given that it's been stored for several years with no maintenance. The brakes are even functional, though the front cable had seized. The gearbox (well, belt box) is also functional, but there's still plenty to do on it - for example, the engine has to be removed, lights sorted, legal bits checked, and it has to be weighed and measured fairly carefully, so that I can revise my estimates and get some real-world numbers to work with. I'll also have to buy the replacement bodywork. Motors are to be ordered shortly, it seems pointless to wait for delivery from China. Charlie

Scooter Mechanics

I spent the last few hours working out the mechanics for my electronic moped project - it should turn out to be fairly practical if I've got my estimations right. The range on about £450 worth of batteries is the limiting factor - about 20-35 miles depending on speed and mechanical efficiency. The problem comes in when you factor in hills - even a mere 5% incline is enough to significantly eat into battery life. Combined with a 1 hour charge time, it should be pretty useful as a commuter or student vehicle though. I still need to wait to hear about sponsorship, funding, and the legal status of my "donor" moped, and look into the process and costs of registering the vehicle for on-road use after it's been rebuilt, but it looks like the project is, at least in theory, possible. Even if it isn't entirely road-legal, 6kW (8hp) in something that weighs around 45kg will be pretty fun for off-road use.

The 3D printer project is not entirely forgotten either - expect to see more on that soon...

I'm also just going to leave this here regarding the quadrotor:

Yours textually
Charlie

Personal statement: Complete!

Since the deadline for submitting my UCAS application is tomorrow, so I hope you can excuse a terrible post. Just to say that I haven't yet got shadow mapping done, but it's not too far off now. The quadrotor theoretically now has spinning blades (fun fact: the tip of the blades move at over 80ms-1), which will be tested fully later today.

Charlie

Speculars: Sorted

Specular lighting is now sorted and working perfectly. I'm also now able to re-build shaders virtually instantly, which means no load-up time for minor changes - which should make shadows much easier to create and debug - more on this next time. The next big hurdle is getting some real game logic running. SSAO and anti-aliasing can wait until there's something playable, with good scene management, and at least vaguely optimised.

Charlie

Kind of Proper Lighting

Back to school tomorrow, already up too late. Ah well. Progress has been made on lighting - apart from shadowing and specular reflection, it's now fully usable. There are a number of speed improvements which still need to be done, but those changes will have no real effect on the image. Rendering speed is still acceptable as-is with the single light I've been using to test, but it can easily be pushed up far faster than it is currently - I'm using the simple but time-consuming approaches for now.

Charlie

Lighting

So, if you can read this I'm on holiday without reliable internet access - so this post will have to suffice. It shows the progress I've made up to the time I started to pack. The light is unfortunately quite glitchy, and doesn't feature shadows, bump mapping or specular highlights.

Very basic multiplicative light.

Gen1:3
Charlie

Sponza Atrium

Here's a simple first-look at the engine. Currently it's showing the base texture and tangent-space surface normals of Sponza, a model used for tests (mainly lighting). The next step is to shift the normals into viewing space (using the transpose of the inverse of the transformation matrix, for reasons I neither understand nor need to), and use them to light the scene. This now works on GL2 (DX9-level) hardware, with ideas to extend to GL3.X (DX10) or GL4 (DX11) and add new features (re-building a high polygon count from a set of smaller points and a map - geometry shader).

Base texture

Tangent-space normals - the light blue colour represents (0.5,0.5,1) as a colour, which works out to (0,0,1) as a vector - the
"up" direction with respect to the surface. I have since fixed the out-of-place stone texture - a bug in the model, not in my code for once!

Still a fair way off actually lighting it - I need a way of quickly working out the distances between points amongst other things. At my current rate that might be done in a few days. Skeletal animation, a game engine, net code and sound system are a while off.

Come next Sunday, I'll be camping and so may not have internet access. If that is the case I'll have a scheduled post prepared. With any luck it'll feature working lighting.
Fuck wasps.
Charlie

Fixed glitches, Minecraft

First things first, I fixed the graphical glitches which were occurring in my last screenshot - the depth buffer hadn't been set up correctly. The renderer can now project and transform objects, and essentially also supports textures. Still to add are normals, displacements, scene manager, skeletal animation, blend shader and lighting - but the heart of the deferred pipeline is now fully functional, which is always nice. In a couple of days I might be able to get a copy running in a web-browser, this post will be edited if I manage.

Redness represents X axis, Green Y-ness, and Blue Z-ness. It's also possible to "fly" around the cube.

Secondly, I started playing Minecraft Classic for a bit, then fell a little in love with the game. I purchased the Beta at about midnight, and have been playing it solidly since. It's absurdly addictive, but also brilliantly simple, and the DRM-free, play-wherever, indie quality of the game makes it all the better. It's also written by one man, in Java and using OpenGL (exactly the same as that ^^).

Minecraft? More like mindcrack?
Charlie

Back in the UK

The timelapse and images promised are in the process of being uploaded, and I'm suffering from a fairly bad headache, so this will become a fully-fledged post tomorrow. Return in 18 hours. That's an order, soldier.

Edit: OK, so the above might have been an exaggeration. I have made the timelapse but it's suffered from compression or rendering glitches. I shall re-render in something other than AE in the near future and post back. This edit is mainly to show what little progress I've actually made on the game:

If you look carefully at the full-size image you might be able to see the cube-ness of it (the lack of more than one colour deprives it of any real "shape" as such). It might not seem like much but it is perspective-ly correct (only the most technical of terms for you dedicated readers), and so means that there are no maths-related errors, anywhere in my code. It's also the beginning of a completely deferred pipeline (which means that lighting complexity is independent of geometric complexity, which is a huge benefit for complex scenes with lots of lights).

Edit 2:
So I added some colour, and it turns out my maths might not be so perfect after all:

I appear to be missing a face.

Bugs shall be fixed and a basic engine shall be running by next post. If I stop being lazy.

That one picture warranted staying up until 5:43AM? YES!
Charlie

Menorca

I'm in Menorca right now, so I have little choice but to post this from my phone (and hence spend a medium-sized fortune doing so). The weather is beautiful, and the sky's incredibly clear so I'm going to upload some pictures and a time lapse of the night sky when data isn't costing me £1.50 per megabyte. This post shall duly be edited with large pictures when I have my home broadband connection.

In other news I've got a new graphics card (Radeon HD 6950, aiming to unlock to 6970 with a bios mod if possible). That gives me DirectX 11 and a fair amount of graphics power and memory. Useful for video editing and game. I've written a fair amount more, but still got a huge amount of work before anything is playable.

How long will a week's worth of YouTube subscriptions take to get through?!

Edit: Here are a few photos I took - the third actually features in the timelapse.

Because having a horizontal horizon is optional, right?

Charlie

Evenings are dark again!

Here's one more short post, and a warning that I'm on holiday for one week beginning Friday, so my next post may end up being scheduled and therefore old news.

I shall be here in a week. Expect numerous photographs, of nowhere near this artistic quality.

I've actually made decent progress with the game - I'm now at 6.5K lines of Java code, which to be fair doesn't sound like much, but does represent significant progress. By comparison, Unreal Engine + Editor is reportedly over 1.4M lines, Source SDK at 780K, Quake 3 at 310K, and the Crysis SDK at 280K lines. In any case, judging a program by the number of lines of code is like judging an aircraft by its weight [quote shamelessly paraphrased from Bill Gates]. I'm aiming to have a working renderer with terrain, water, models and UI working in "real" space within the week - which should be achievable. One significant annoyance for me is that OpenGL intentionally doesn't have any native way of handling fonts - which is going to add a significant amount of code (unless I cheat, and just bake every bit of text into images, which isn't possible for stuff like resource count).

Once I've got the renderer up and running, the rest of the engine is actually much less complex in terms of the maths, and doesn't have to be nearly as efficient or fast. Keeping everything in sync across a network isn't too bad as long as you aren't doing any prediction (for those who are interested, there's a very impressive explanation of how games like Counter-Strike predict movement over in the Valve wiki or for the older Quake here) From there all I need to know in terms of engine is skeletal animation (I could probably implement it now, but don't fully understand it - there's some maths we simply haven't covered - Quaternions - from what I understand, essentially multi-dimensional imaginary numbers - the extension of an Argand diagram into 3 or 4 dimensional space - too many hyphens - I think not!). After that the client needs sound, encryption and streaming of textures/file manager, and then is finished.  Server-side requires a file server, gameplay logic, account manager and AI (PvP would of course solve this, but it's worth having very basic AI to help the game start and get people acquainted with controls and basic gameplay). From there, my job is level design tools. supporting the artists and gameplay, and the website/backend.

Ambitious? Yes. Achievable? Let's find out, shall we?
Charlie

Apartment and Connections

Much of my last week has been spent on filming - if you haven't yet seen it, check out the Facebook page for the film here, and see the "Finding an Apartment" videos. We still have a fair amount to shoot, likely around September, but we've got a fair amount complete, and the rest planned and written. There's also a fair amount of processing to do - shots taken when walking backwards aren't exactly prime candidates for the "smoothest shot of the year" award, and masking out any wires and misplaced boom poles will take a while (more due to my lack of experience than the amount of processing required though).

I also fixed a website of mine - and started using a reverse proxy to look at traffic. One thing which surprised me is that over 90 unique threatening machines are blocked attempting to connect to the site every week. The proxy also cut response times, stopped over 14,000 requests, and saved the best part of a gigabyte of bandwidth, which is always nice. Thanks to Cloudflare for an excellent service, at an unbeatable price (free, paid service for better statistics and more control).

Pageviews are down because the domain was stuck on a landing page for over a week in transfer delays. That's one way to wreak search rankings. 

Savings are awesome.

I'd never miss a chance to show off my (quite frankly pathetic) site statistics...

Charlie

A collection of semi-related ideas

Today, I thought I'd just set down most of the projects and thoughts that are floating around inside my head, in the hope that it'll help me think more clearly about them. Most of these should be accomplish-able over the summer.

Quadrotor: Parts are on the way. Not much that can be done before they arrive, really. The only real priority is ensuring we can work in the Mills Centre (or failing that, finding a place to work).We do still need to find a good set of 4 blades (and a set of spares too).

Game: I'm getting there. Perhaps too slowly. The aim is to have a completely deterministic client-server system, running at 5-10hz for gameplay (variable depending on latency?), 60hz+ for graphics/rendering/motion. Whilst that's entirely possible, my knowledge currently doesn't cover skeletal animation or some of the newer OpenGL techniqies, and I need to work out a good model for handling gameplay on server, and resources and data on the client. My audio plan is also limited, and requires OpenAL to be installed manually, which is a pain.

DT: Check money for parts - need to go to bank.

3D printer: Ditto.

BlackBerry: Why do I have to boot up an XP VM just to sync or back up my phone? Ridiculous as a solution. RIM, I expected more. I can't really solve this though. Plus, waiting on my network to enable BBM and push email.

Sites: img - not viable? VW - in progress/ Scopegames - waiting on domain.

Fixing crap: iPhone needs doing. iPod Touch is awaiting parts. The DVD drive is being very odd indeed. Laptop is a lost cause?

Anything else I've mentioned on here (plasma balls, vlog) - suspended indefinitely either for practical reasons or apathy. So sue me. Or slap me. But bear in mind that you haven't posted this week...

Tidying up: The less said the better. I know there's a floor around here somewhere....
Lists: the procrastinator's alternative to actually producing something.
Charlie

Reaction Times and Gaming

With just 3 days left at school, it surprisingly feels like teachers have increased our workload rather than lightened it. The holidays are definitely going to leave me with a lot of time to have fun study hard and prepare for the future. 

In lieu of a working game engine, I'm instead going to present some of the stats from my reaction tester (horrifically coded with JavaScript, with absolutely no security whatsoever - check it out at http://reactions.haveibeenraptured.com/). I said that this data has a weak negative correlation. Equally, and probably far more significantly, it shows that people are inclined to round their numbers (or play games for exactly 15 or 20 hours a week but not for any time in between the two).

Most amusing name: "Charlie I'm Horny"
Most amusing hypothetical attack: "i was tempted to leave it on overnight for a super retarded time and put 'single mathematician'" - Jamie Go
Longest time: 14,283ms - Josh P
Runner-Up: 10,744ms - Benjamin S
Worst DDoS: You know who you are...
Best-known participant: “Andy Murray”

Thank you for participating in this enrichment centre activity

Charlie

Filler posts? Who, me?

I've been out all weekend filming (more over the next month - and no spoilers I'm afraid) so I haven't had much time to work on the engine or any other projects - though I have ordered the motor, charger and batteries for the quadrotor. The work I have done towards the game is mostly non-visual (i.e. importing 3D models, materials, user input, and animating colour transitions). I'll be finishing the model and material importer, and designing the renderer properly over the next couple of weeks.

CryTek know how to do lighting.

Once model importing is sorted (not too far off) the next big problem will be lighting. Lighting is easy in certain situations but next to impossible in others. Take the above image as an example (a model of Sponza Atrium, rendered in CryEngine 3). If you consider light as moving only in a straight line, then any covered areas would be completely dark. We know from experience that this is not the case, however - light is bounced off all surfaces, providing light to the covered areas. This is known as radiosity. Games like Half Life 2 pre-compute the radiosity but this method has limitations (most notably, the lighting is only valid when the sun is in one position) so increasingly games have started to handle more advanced lighting in real-time. There's still no "standard model" to speak of as yet - though there are some techniques in common between virtually all games. Advanced illumination like this won't be relevant in an RTS game, but I prefer to plan ahead and think about how features could be incorporated. 

Project size to date: 384mb

Charlie

Progress. Kind of.

I do Linux. It's a thing now.

This is going to be another short post, I'm afraid. Current progress towards the game is shown above - I've set it up to do real-time colour toning of scenes. It's currently just set to turn Red and Green down a lot, and Blue down slightly, and then switch the Red and Blue channels around (fixing the odd colouring issue I was having at the time of last week's post).  It's also rendering to an off-screen buffer at the same time - which means that the in-game content could all be treated in the same way, not just a raw image as shown here.

For anyone interested, the fragment shader code itself is shown. It really isn't that bad, actually. The code that goes with it (feeding it the data points, textures, etc) is horrific at first sight though. Finer-grain control over colours will be possible, when I write some code to handle one-dimensional textures (multiplying by 0.9, 0,7 and 0.6 were really just to test the concept).

The switch to Linux is an interesting one - I had previously done so on my laptop whilst "revising" - but now it's on my desktop, and it's permanent. On the whole I love the OS - everything is free, without any hassle - installing programs is as easy as typing its name, and pressing "Install". Programming is far easier than under Windows - the entire O/S feels more geared towards it. Even advanced changes only require a couple of lines of text. I'll only cave in and install Windows 7 when my craving to play Portal 2 gets too great, or when I discover that there's no fix for a bug I have with it. (The choice to use a Portal-related texture as my test image suggests I'm not going to last too long...) The only real barriers against wide adoption is the lack of apps like Photoshop, After Effects, and a large library of decent games, the perceived increase in complexity (no steeper than Windows - just not what people are used to), and maybe the self-imposed "free software" barriers (again, not a problem to me - technically formats like MP3 and DVD are licensed, and drivers without source code available throw up a "non-free" warning). That's how my experience of it as my "Main O/S" has been, anyway.

Linux is the one responsible for destroying the performance - it's not actually that slow.
Charlie

Shaders Aren't Easy

What I've done there is failed. 

I'm afraid there isn't going to be a substantial post today - I'm just going to show what little progress I've actually made on an "engine" (term used loosely) - my code can import a texture and show it on a slightly-mutated ex-square. Colours are a work in progress, and it's also using a complete hack to set the texture coordinates, but I think it shows that I'm not far off doing "useful" things in OpenGL. It's not going to win any awards for pretty code (once I have model importing, basic illumination and muti-texturing sorted, I can start writing pretty, fast and flexible stuff), but it's all practice and experience in the graphics language.

The texture on the right is the original, the two on the left are various attempts (guesses) at the right colour profile.

I've managed to keep the performance, at least...


"Failure is just delayed success". Is what failures say.
Charlie

5000 FPS. Like a boss.

(Yes, the Physics exam is in 10 hours.)

I didn't manage to hit 9001 FPS, and admittedly it's only 2 polygons, but pretty cool anyway...

I'm just going to leave that here as a little teaser of what's to come. That's actually a very basic shader program - which means it's running on my graphics card and not CPU. In non-technical terms, that means that you get much more speed on modern hardware, and a huge amount of flexibility, at the cost of a bit of complexity. Shaders in modern games control pretty much everything you see, in some way or another - from lighting to the position of objects.

This is only the start, but in the relatively near future, this will become a more full-featured game engine - is anyone interested in helping create a "complete" game, beyond who I've already spoken to? You don't have to be technically minded - there's a huge amount of non-technical work involved in actually creating a decent game - the more hands, the merrier. There may well be a Facebook group in the near future. I have some ideas, as do several other people. RTS/FPS/3PP are all possibilities - it depends on what people would like to do. In fact, some might be useful as miniature test projects, as the code/collaboration improves.

I'm clearly not Chuck Norris
Charlie

The Maths Behind Computer Games: Rendering

I wanted to do something a little different with this post - and it'll probably get fairly technical, but it'll hopefully be interesting nonetheless. I've been fascinated with the maths and engineering behind games for almost as long as I can remember, and thought it might be interesting to condense some of that into a post (with pretty pictures) - if it's interesting I might do some more of these in the future. For now I'm going to explain the process of projection, with maybe a dash of texturing and lighting - there are actually some short-cuts and tricks used to speed the process up, but I'm mostly ignoring them for simplicity.

How it Works
One of the fundamental and vital things about drawing a 3D scene, is that almost everything can be approximated as a load of small, flat pieces (polygons) each joined at the edges, with a visible material applied to them. Computers generally use triangles, but you can also use quads or any n-gons if you feel so inclined. Each of the points which define the triangles can be expressed as a vector - 3 numbers, representing its X, Y and Z coordinates in space.

Mostly triangles in there...

Using some pretty self-explanatory maths, you can take a set of several different models, each positioned at different points in the world, and express them as a set of points (vertices) in the scene. So you now have a set of points in space. So what? They are pretty much useless, without some kind of viewing-point. The position and location of a camera in the world can also be expressed as a set of coordinates and a rotation - by using these bits of information, every point in the world can be shifted into a nice, simple set of values which are now oriented with respect to the camera - that is, the axes are aligned to the view-point and not the world or the objects. If you're confused, don't worry too much - essentially, what you now have is the points, but shifted so that the numbers now represent X, Y and Depth rather than the position in the world.

Unfortunately, our view on the world isn't quite as simple as this - if you imagine a simple cube, as described above, as seen face-on, each corner would be directly in front or behind of the rear face. In reality as we experience it, things which are further away appear smaller, so we shift points towards the centre of the screen depending on how deep they are. This now gives a pretty nice view of where each point on the model corresponds to on the screen - you can say that each point has been projected onto the 2D screen.

The above diagrams represent perspective and orthographic space (perspective is on the left) - the space which is actually seen by the camera (the far end is the furthest object you can see - computer games limit how far you can look into the distance, sometimes with sneaky tricks)

The initial projection I described is what's known as orthographic projection, which is useful if you need to work to a specific scale - for example, when designing a product with CAD. The depth-adjusted version is perspective projection, and is used when something needs to be displayed as it would be seen.

Once you have your points as they would be positioned on the screen, you can then draw in the triangles themselves. The easiest way would be to stretch a texture onto each triangle - though even this can have some quirks, which fall way beyond the scope of this blog post. A much more interesting and mathematical thing you can do is break each triangle into pixels and work out the colour of each - this is known as shading and can be done incredibly fast on modern graphics hardware.

All credit to Wikipedia for the image.

The Phong model of lighting (named after the first person to describe it, Bui Tuong Phong) can be used to shade a variety of material types very effectively - it's typically used for plastics or non-transparent liquids - Gels in Portal 2 for example. The principle is that the overall light reflected from a surface can be thought of as the sum of several different components, each of which is seen above.

The ambient (emissive) light is a term considered to always exist, but is often excluded because it is not strictly necessary. The diffuse (scattered) light is reflected in all roughly all directions by the material and does not depend on the viewing direction, only on the lighting direction. The specular (highlight) light is the intense highlight reflection you may see off shiny surfaces. Together, they can be summed up to give a pretty good representation of a material as a whole.

Restrain yourself, Jamie!

The Ka, Kd, Ks and alpha are material constants - representing the material's ambient, diffuse, specular and "shininess" constants. Things with a hat on (^)  are normalised vectors representing light and viewing directions, and the surface's normal. Ip is the output - the colour of a single pixel. This process is repeated for every single pixel of a scene (well, technically fragment - transparency can cause two or more fragments to be drawn for a single pixel).

Not personally a fan of the cave missions, but they definitely looked good. 

Of course, there are a huge number of other things you can (and indeed need to) do to make a realistic-looking scene which still performs well. For example, textures can be sampled to give much finer detail on items, and other shaders can be custom-written to handle reflective, refractive or translucent materials, metals, goo, or even supposedly simple things such as bumpy surfaces, as seen above. The cave's surfaces are actually flat - the surface shader is given a bump-map - a texture representing the height of a material rather than its colour. This can be used with a light vector (such as the torch) to give gorgeous, realistic-looking lighting effects, at much faster speeds.

Confused? Now remember that the computer handles about 100,000 vertices, depending on the game, and 1,000,000 pixels, 50 times a second, just in graphics calculations for a modern game.

Things I Haven't Mentioned
What about the other side of objects?
Sneaky trick with how you choose the triangles - you number the vertices in an anti-clockwise order around each polygon. When you're about to draw it, check if the order is still anticlockwise. If it is, you know it's facing you  and should be drawn. If not, you're either looking at it sideways-on or from behind - which probably means you shouldn't be drawing it.


What about things behind you?
In the part where you move things with respect to the camera, things behind you end up getting a different sign on the depth to everything in front of you. You can just throw out any vertices with depth values below zero.


Anything else?
There's probably a solution or an explanation, but I'm really not going to pre-empt anything and everything you could ask. Ask in the comments, or wait for future installments, if this was actually interesting.


Yours geekily,
Charlie

What's eating your time?

Despite having disassembled my main desktop, I've found that I still have ample distraction even on a Linux laptop - so I decided to present, in list form, the top 5 web-apps I use to distract myself:

5. Webmasters Tools/Analytics/AWS Control Panel
All are just small apps you can use to check the status of a site or sites and how they are performing - useful tools for analysing your sites. Not so useful to check every half-hour though, since the data is updated daily.

4. Whatever tab is to the left of this one
This rule sadly also applies - instead of concentrating on the contents of one tab, if one starts to lose its appeal, the one to its left starts to look all the more tempting. If I happen to be on the left-most tab then.... yeah, right - like I'd ever make it over there. The tabs on the left haven't seen the light of day since the machine was last booted

3. Grooveshark
Finding new music is easy. Concentrating with said music playing is often harder.

2. YouTube:

With awesomeness like that throwing itself at you, what's not to like?

1. Facebook
This one doesn't need any explanation.

(Twitter, Reader, and a few other sites also feature but less prominently)

There's an entry on the XKCD blog that looks at the procrastination response, which is surprisingly interesting. Essentially, in the absence of a clear way forward in solving a problem, the brain will throw out the potential longer-term satisfaction of solving the problem, for the shorter-term reward gained by, for example, opening up a new tab and browsing Facebook. The new action, as long as it has some novelty value, will almost always be more appealing, because it provides an instant and always-available reward. Hence, over time, more challenging things are pushed aside by the short-term rewards of a quickly-changing social site such as Facebook, which never loses its novelty value because of its continually-current nature. Similarly, sites like Twitter and YouTube can also become ingrained responses when faced with the slightest of problems in your intended work.

As for solving the above? If I find a solution in time for my Chemistry exam, it'll both save me from an embarrassing and complete failure, and will be shared on here next time.

Number of times I alt-tabbed to another window whilst writing this: 6
Charlie

Pre-exam Jelly

If you hadn't noticed, exams are now altogether too close for comfort. For that reason, I should probably be asleep rather than blogging. This week is Maths, but Chemistry is still only a week and a half away. A week is long enough to learn most of the unit - at least, that's what I'm depending upon...

In lieu of a proper post, I leave you with these tidbits:

My desktop is now literally a desktop computer - it's lying in several pieces on my desk (intentionally so, it didn't explode or anything). If you want to contact me, I can no longer read MSN or Steam messages. Send messages via FB, email or text instead, please.

Without a desktop, I've been on my laptop for far too long, and am far too used to Linux as a result. Expect to see some cool stuff over the summer as a result (if by "cool" you read "slightly more geeky than a conference of WoW enthusiasts"). I now know my "top" from my "tee", and "-X" from "-x" - the latter was the source of much confusion...

Chell in the Rain (now my background image)

A light distraction:

Contenders for the comparison included "geekier than a Maths set with their own Facebook group" and "geekier than someone fluent in both JavaScript and Klingon"
Charlie

Procrastination and Examination

I'm about to sit 9 exams, spread from the 18th of this month to the 23rd of June. Despite that, I still haven't written a blog post, or completed any of the practice papers due in under 8 hours. I've managed to get a load of little tasks done, but nothing significant or important. Ze Frank had an excellent video on procrastination, but I'm sure I've already linked far too many people to it. 


"Psychologists often cite such behavior as a mechanism for coping with the anxiety associated with starting or completing any task or decision" [wikipedia]


Interestingly, the above quote fails to mention the anxiety brought on by not completing the tasks required of you, hence discrediting the whole statement and making procrastination entirely acceptable and healthy from a psychological perspective. As if that stopped any of us anyway...

Just one of many ways in which you, too, can successfully procrastinate...

Side note - I'm interested to hear from anyone who's been affected by the PlayStation Network being down over the last couple of weeks. What does it actually stop people from doing? I know if it stopped me playing Portal 2 co-op I'd be pretty annoyed...

Now to bury myself in exam papers. Fun times.
Charlie

The last 604,800 seconds

Give or take a few percent:

• In the last 200, I've probably pissed off 40% of the contents of the house by dropping heavy things great distances at 4AM. I hope they don't repay the favour.
• In the last 2,000, Osama Bin Laden is announced dead. Convenient that the announcement came around re-election time...
• In the last 20,000, I've written a good few hundred lines of code. Not much, but enough to not feel like an utter procrastinator either.
• In the last 200,000, I've watched Thor, but that's already been covered by Benji about ten times better than I ever could over here. I also finished a damn good book (more to follow).

And looking forward:

• In the next 200, I'll probably spend 100 of them staring at the screen proof-reading and feeling desperately inadequate, and guilty for not revising.
• In the next 2,000, I might even get some sleep.
• In the next 200,000 I need to do about 9 maths papers, give or take.
• In the next 2,000,000 we will begin sitting our exams, quite potentially altering our university options and deciding entire career paths.
• For the purposes of not going down a much darker, existential path, I'll gloss over the fact that 3 lines more is a lifespan, maybe 4 at maximum is everything we know of and can care about, and about 1.5 beyond that is the start of recorded history.

On a lighter note, I appear to have officially taken up reading again (having read 5 books in about 2-3 weeks). Yesterday, I read "Will Grayson, Will Grayson", a stunning collaboration between John Green (of whom I'm a massive fan) and David Levithan. 

It's all sparkly and pretty in real life. 

The book is an engaging read from start to finish, featuring a clever plot, genuine characters and relationships who change believably as the plot progresses. I personally loved its pace and twists, and pretty much everything about it. It isn't perfect by any stretch (what book is?), but it's definitely well worth picking up a copy and spending a few hours on, as is any John Green book (he's also a YouTuber, which is how I discovered his books - see here for more information).

Want to pick up a copy? If you know me, I'll lend you my copy, or pick one up from Amazon:

Forfeit vlog (would have been today except for an annoyance with the microphone) and 3D printer progress to follow in due time...

That is the reason why logarithmic scales could be considered depressing...

Charlie

Here be a vlog...?

The sun has kind-of risen, but I don't have anything much to say, and haven't been feeling too brilliant either, so I don't have a post prepared - I'm posting this as a place-holder for a vlog instead, to follow some time in the next few days. I hope that the prompt-ish provision of a vlog will compensate for my lack of an on-time post, and thus render my punishment null and void. Or something like that.

[Mother of all cop-out posts to be rectified in due course]

Charlie

One of these days, I'll post *before* the deadline

Speaking of deadlines, as I write this, the clock's counting down to Portal 2:

http://aperturescience.com/glados@home/

Yes, it's 2011 and I'm still using XP. My Linux machine's taking a nap, and I didn't want to wake it.

I thought that was a pretty clever way of supporting the indie games industry. Major credit to Valve for this.

Onto the main body of the post: Scream 4 (Scre4m).

I ended up seeing Scream 4 on Saturday along with a group of friends. The film is centred around a masked, robed attacker with a fondness for large, sharp knives and the illicit use thereof. Several threatening phone calls, gratuitous stabbings, murders, worryingly-open windows and chases later, the film reaches a clever-but-not-entirely-unexpected-and-somewhat-but-not-entirely-predictable conclusion of sorts.

My feelings about the film were mixed - it felt well-made and genuinely entertaining, with a decent storyline and pacing, and some fairly amusing moments. It was pretty gore-heavy, but not un-watchably so. On the negative side, there weren't any moments which stood out as particularly tense or suspenseful either, and at no moment was I truly scared (unlike how I felt playing Amnesia: The Dark Descent. The first bit with the water. Seriously.) .

I can't comment on how it compares to the originals, since I haven't seen them, but can certainly recommend the film, not as an amazing or deep one, but as an entertaining one.

That's all for now folks. Expect more terrible pseudo-reviews and Portal 2 raving soon...

What's your favourite scary movie?
Charlie

Nine Days of Freedom

That's right, it's been nine days since school finished. To make myself feel slightly better, I decided to work out what I've done with my time instead of revising:

• L'artista
• RC car on the Heath
• Plenty of coding and database work (now fairly comfortable with JavaScript and AJAX, if by "comfortable" you read "no longer feel gut-wrenching terror at seeing statements like $('#element').load("somefile.htm").fadeIn(1000, new function(alert("BOO!");));" - that is a valid and "sensible" line of code AND grammar, by the way.)
• Writing a haiku to express my undying hatred for IE6
• Portal!
• Mathematics (sadly, unrelated to anything in the exams, but happily, related to my game)
• Benji's
• Extracting dustballs from my brother's laptop. 

I think that justifies spending no time on revision?

Under the sub-heading "Portal!" I was messing around with some screen recording software, and was pretty happy with this run-through. (shameless segway into my "rich media" of the week):

Click me, you know you want to?

T minus 8 days,

Charlie

Happy Birthday!

... as of 4 hours ago, Benji is now 17. If you haven't checked out his blog yet, click here - it's quite simply awesome.

I'm afraid I'm a terrible person, and so this is going to be the mother of all cop-out posts.

Giant armed alien robots in New York? Standard

I'm going to put it simply - Crysis 2 is probably the best game of the year so far. Graphics are suitably epic - the game uses lighting and shading to an even greater extent, but also feels faster in terms of framerate - I've not checked the numbers yet though. Gameplay is much improved - the suit has been made simpler without losing any of its core functionality. My main complaint is that it feels more like a multiplayer game even in the campaign, with purchasable upgrades offering slight bonuses like reduced footstep sound or bullet traces. Useful but hardly game-changing, and all adding complexity. I'm currently in Grand Central station, struggling with a Pinger (which looks even better than in the pre-release picture above). More pictures will follow at some point later in the day. 

It still remains to be seen whether Portal 2 will steal the crown from Crysis 2 or not. Crysis will certainly take quite some beating... 

I'm feeling unoriginal...

... so I thought I'd introduce you to somebody else's originality instead. 5 years ago, a semi-famous internet personality known as Ze Frank decided to make a video every day for a year. The project ("the show") ran from March 2006 - 2007, and produced some pretty awesome and inspiring content. The best part of the show was not the show itself (although the show inspired the whole video-blogging genre as it stands today), or the layers of in-jokes, but the user-interaction, side projects, content creation and community he inspired. The only thing I regret is that I wasn't aware of it at the time.

For a taster of The Show, click here then check out the popular episodes.

In other news, I've decided on my next biggish project, provided I can get the glass bulbs and gas at a reasonable price:

Images from here

By adjusting the gases (mostly low-pressure noble gases) and pressures, some pretty awesome effects can be achieved. I've always been interested in HV and electronics in general, and have always thought that these were pretty much the coolest devices ever. The main issue with creating one is the glass bulb - having one implode on you wouldn't be much fun, and the wrong gas-mixture or pressure will create dim or invisible streamers. This won't be getting in the way of the 3D printer - that's for my end-of-term free time.

Yours hopefully-cutting-down-on-the-brain-crack,
Charlie