Categories

First (render)steps

Reaching my next objective proved remarkably easy in XNA. First and foremost, a big thanks to Catalin Zima. I started from his deferred shading tutorial to build my own pipeline. I liked a lot of aspects of the deferred pipeline back at 10tacle, so I want to start with a deferred pipeline for my own engine as well. I’ve implemented Catalin Zima’s tutorial, but refactored it into a system of clean, separated steps. A RenderContext in Hyperion now contains a set of Cameras and a set of RenderSteps. I’ve designed a clean IRenderStep interface, which will hopefully allow me to add about any effect/rendering technique to my pipeline easily without the need for a lot of refactoring. Implementing the deferred pipeline that way was straightforward, so now I have a basic deferred renderer, with a lighting pass allowing for dynamic directional, point & spotlights.

I’ve put some thought into the interaction of these RenderSteps with the game objects, and have found an elegant solution for that. Game entities ( which are just components, just like almost anything in the engine ) register to any render context they want to be rendered in, and specify their renderable type (e.g. DeferredModel, or PointLight). Within each render context, this instance is passed to each Render Step. The render step can decide to render or not this particular entity. So now I have e.g. very simple game entities for lighting entities, and they’ll integrate into my editor automatically with the rest of the entities. I plan to add the possible extensions to the deferred rendering pipeline Catalin Zima suggests soon, but I had something else in mind first.

Since one of my goals is the easy experimentation with graphic effects, I wanted to put some effort into automatic graphical debugging capabilities of the rendering pipeline. I really dislike ingame debugging with an extensive set of keyboard shortcuts or console commands. It typically is obscure, cumbersome and hard to maintain. So I’m going about it the other way. I’m creating a basic .NET WinForms application that will serve as both editor & debugger for games running on the Hyperion engine – working title ‘playground’. In this editor, I’m running an instance of the game itself, and editing or debugging game elements will happen through panels automatically generated based on information extracted from the game via reflection. Similar to 3d modeling packages, you can have any number of different viewports into the game, showing any information you want to. And hey, that worked out just fine!

totemslogo

So, what’s going on behind the screens? (pun not intended)

  • There’s an actual game instance running in a custom control. At the moment, this game is just updated like a normal game, so it’s just running, but it will be trivial to add pause & slow motion controls in the editor when I need them
  • I’ve added DebugRenderSteps into my rendering pipeline that will output anything to the main render target, and exit from the pipeline. For instance, in one kind of DebugRenderStep, any color render target is just output, the same kind of DebugRenderStep is used for normal render targets but with a different shader, etc.
  • In my editor, I use .NET’s reflection to list the registered DebugRenderStep’s in the viewport’s context menu. So activating any debug view takes just 2 mouse clicks.
  • There are several, predefined viewport layouts possible: one big viewport, two viewports vertical, four viewports, …
  • Any viewport’s camera is controllable by just doubleclicking the viewport, at which point input control is given to the game until the user presses Escape.
  • A separate camera is created per viewport, but it is equally possible to show the same camera in several viewports, as shown in this screenshot:

totemslogo

None of this is all that special, and has been done tons of times before. But the speed at which this is possible in C#/XNA is motivating to say the least. Next stop: Rayleigh/Mie scattering, aka Crysis-style dynamic skybox. Stay tuned.

The Basics

Well, I had to start somewhere, so I decided to start with the basics as first goal: have a running XNA application, displaying a grid, and featuring a camera controllable in whichever way I want it to. First screenshot!

totemslogo

Not much of a looker yet, is she? Modelers among you will recognise the color scheme, I like 3dsmax’s discreet-dark scheme, so I imitated it. Things worth mentioning on development so far:

  • I’ve integrated and refactored a camera component by dhpoware that works decently. It’s a monolithic camera supporting several movement modes (firstperson,spectator, flight, orbit). It will serve perfectly as debug camera.
  • The input system is designed to cater for all my needs in the near future. It’s based on a distributed control scheme rather than have one big input manager you poll for keystates. Any entity that needs input information on a certain control instantiates a control class, and can poll this instance for information regarding this control. Eg, you can instantiate a KeyboardButtonControl for a certain key, and then poll its Pressed, JustPressedThisFrame, etc. You can layer controls easily, for instance there’s a DirectionalControl interface that you can create based on four digital or analog controls, there’s adapters to transform digital controls into analog controls, there’s AggregateControls that allow you to bind multiple physical controls to one game control, etc.
  • On top of this control-based system I’ve added an extra layer of abstraction for use in games: any control used in a game’s final control set is registered via an input component that returns only AggregateControls. This gives me an ideal place to hook later on where I can add a user-defined game control to actual physical control mapping. In game code you just register a control by specifying which interface you need for this control (e.g. analog, digital, directional, pointer) and optionally specifying a default physical control you want to use if there’s no value in the user config yet.
  • The rendering system, albeit rudimentary, is already a bit more advanced than just a Render() call. I made the ‘entire’ rendering pipeline instantiateable, so I can create multiple different viewports (eg picture in picture) when I want to.
  • I’ve created my own component system. There’s several reasons for this: I like full control, I didn’t agree with XNAs component design too much, I don’t care about not being able to easily publish my components to other parties, and I want to facilitate porting to a non-XNA-based technology as much as possible
  • Oh, and as for the window title, ‘momentum’ is the working title of the first game I’d like to develop. Nothing is set in stone though, I have several concepts in mind, but this is the ‘easiest’ one to start with.

    That’s about it for now. Next up is the rendering pipeline & game/editor integration. Yay!

About Hyperion

Hyperion is the working title I gave to latest exhaust for my game development urges. With 10tacle dead & buried and Off Limits nearing completion ( and becoming more tedious than challenging in development ) I’ve started my own little sandbox project. Most people start with this phase and then become a professional game developer, I seem to be doing it the other way around. But I think the reverse approach can lead to some interesting results.

Basically, I will try to build a 3D engine with some specific goals from quasi-scratch. First and foremost, it should allow easy experimentation with advanced game & graphics engine features, and enable fast development of high quality game prototypes. I know that this in itself is pretty ambitious, especially since I want to keep this a one man project as much as possible and I don’t have that much time. But one-man development guarantees consistency in engine design and gives me the freedom I need, and as for the lack of time, I’ll try to compensate for that by not giving myself a deadline, by targeting platforms that haven’t been announced yet and by keeping the engine up to date with modern technologies from the get-go. I would also like to keep the option open to one day use this engine to release a game as independently as possible. This implies not using non-free licensed code or libraries, not using final resources I don’t own the intellectual property of, focusing on procedural and generated dynamic content where possible, and targeting digital distribution platforms.

With these constraints as input I’ve chosen XNA as the framework to design my engine on. I risk that its limitations will one day force me to port over to a more performant technology, but my most scarce resource by far is time, and the incredible development speed and ease of C# is undeniable. .NET’s inherent serialization & reflection mechanisms and XNA’s built-in class library take a huge chunk out of the budget needed to develop decent 3D games. XNA also implies easy multi-platform development – as long as you target Microsoft platforms, and I have no problem with that: the Xbox 360 is a great machine to develop on, so my hopes are high for its successor. And then there’s C#’s powerful IDE and its plugins that can harness the language’s features to really speed up the development process, with great support for things like one-click refactoring, unit testing and code completion & lookup. So at the very least, in the XNA framework, my engine’s design will be able to evolve and mature rapidly.

Ofcourse, to give both the engine and myself some direction, I’ll develop a game together with the engine. I’ll start out with generic engine features, and direct my efforts more and more in the direction of the game I have in mind as time goes on. I’ll use this site as development blog for Hyperion and anything running on it.

First Post!

Hi! Welcome to my site. If you’re here, you’re probably either lost or I wanted to show you the personal & professional projects I’m proud to work or have worked on. I’ll try to add some interesting content on my past, present and future projects, so consider this as a mixture of my personal programmer’s portfolio and my developer’s blog.

As for the title & subtitle of this .blog, they refer to actual algorithmic intelligence and shouldn’t be mistaken for ego – or delusion. One of the things that intrigues me most in life and that will definately be the subject of some of my future projects, is the algorithmic and mathematical beauty hidden in many things in nature, with conscious intelligence as the most intriguing and elusive one.

Quests for the Holy Grail aside though, initially, this site will talk about my game development projects. Game development has been a passion, a hobby and occasionally my profession for quite a while now, and if I don’t start logging certain things now, some of my achievements and lessons learnt will slip into oblivion – and it’s too soon for that.