For the Emperor!

Since I haven't posted anything in a while, I decided to put up a picture of my Ultramarines. They all look different because I was experimenting with colour combinations and painting techniques. I'm thinking of going for either Crimson Fists or Iron Hands instead of Ultramarines, or creating my own chapter (who I'm thinking of calling the Bleeding Hearts, for reasons I won't go into right now).

Brave new chicken

I've not really done any programming recently, which does not make me happy. The last thing I completed was some edge-polygon intersection code for the mesh splitting system. While I was testing this I ran into some issues that I had faced before in my previous mesh splitting system. The thing is, the last time I chickened out due to time constraints and went with a simpler version. This time, however, I shall try to keep hacking away at it and see if I can't implement the full system that I failed to complete last time. But I'll be doing it bit at a time while I work on the other parts of the engine, which of course I'm barely working on since I'm hella-busy with work and since I've just taken up painting Warhammer 40K miniatures, which I'm almost stunningly slow at. Seriously, I'm still working on my space-marines starter pack. Hopefully someday I'll get around to those Grey Knight Terminators that I just couldn't resist buying.

Killing time

Right now I'm putting off starting any major jobs on my engine, mainly because I need to spend more time with Blender but don't want to because I'm currently trying to learn 3D studio Max (and other softwares) for my job. Until I can start working on the animation system, I've been spending a little time integrating my old mesh splitting system using the new mesh format I'm using. This has given me a chance to experiment with a pattern of code organisation I thought up. Basically, there are some functions that I may use often in areas that aren't speed-critical, but will also need on rare occasion in very speed-critical areas. This may seem obvious to most people, but I've never seen it in use and so I'm kind of happy with the idea, but basically what I do is write the function as an inlined function, but also have a non-inlined version that just calls the inlined version. For example:

int calculateThing(int i1, int i2);
int calculateThingFast(int i1, int i2);

inline int calculateThingFast(int i1, int i2)
{ ***blahblahblah*** }

int calculateThing(int i1, int i2)
{ return calculateThingFast(i1, i2); }


Now, assuming that the compiler actually inlines the function properly (not sure how to check on that, if anyone knows how to make sure it does actually inline the function please let me know), I will be able to inline the function where needed and call it normally where needed. By the way, if anyone knows a better way to do this, by all means let me know.

Anyway, I've written an infinite plane cut class using inlined line-test functions, which curently tests edges against a plane (it is also capable of figuring out if the ends of the edges are exactly on the plane, which I will need later). Here's some sample images. The plane is represented by a square with a red dot representing the center (or a point on the plane) and a fading line representing the normal. Since the plane is of infinite size, the size of the square is not relevant.
The red dots signify that the plane is intersecting the exact ends of the edge. While it isn't obvious, the bottom edge, which is parallel to the plane and therefore fails normal line tests, is correctly being handled, and the two ends of the edge are being marked as exactly on the line.

Now a normal line test against the two upright edges.
The top of the edges are being detected as exactly on the edge.

So some progress is happening, next I want to work on a finite, circle-shaped cut, then a convex polygon cut. Once that is done, the next step is to start handling the different possible cuts, then triangle sorting, new face generation, handling transforms etc. Of course in the long run it has to be integrated with the model format rather than the current simple mesh, as well as needing to work properly with the animation system (a problem I never solved in the past) which doesn't even exist yet... basically it's going to take a while, and I'm busier than ever now. Still, I shall try to keep at it. Wish me luck.

Finally back to square one.

So the new mesh system is almost fully integrated (as much as the old one at least), including the new LOD system. As I said this new system is easier to use, in fact today I exported a simple model from Blender with two LOD levels:


I only ever tested the old LOD system with simple hand-made meshes, it would have taken a lot more work to get a mesh into it from a modeling program, so I'm happy with this. I'm still considering how (and whether) to implement smooth blending between the LODs (which was already working to a decent degree in the old system), but I think I'll leave that until later. On the plus side, this new system should be more efficient, is more modular, now supports binary files, and is much faster to load.

One step forwards, three steps back

I've not been making much progress on my engine for a while. This was partly because I was cleaning up various bits of code, and partly because I was looking into programming for the PSP, and making early steps to prepare my engine to work on it. I found it would be necessary to change my mesh class, which I had previously put a lot of work into in order to support the cutting system and smooth LODing system.

The new system is simpler and slightly more memory efficient, and allows me to use vertex lists making it more efficient to render than my old system. However I will have to redesign my old cutting system if it is to work, that may add some overhead and may end up being less efficient than the old one. Also, the old smooth LODing system is out the window. The new LODing system I am writing (which simply uses different index lists with the same vertex list, far less innovative than my old one) will require a greater memory overhead (though still less than using seperate models) and in it's current form will not support smooth blending between the LODs - however, this is not because it can't, but because the old LOD system I designed was harder to model for and would require a lot of work writing tools to support, while this version will be much easier to model for and should not require any special tools. In the future I might expand the new system to support working the same way that the old one did, but right now I'll just keep it simple.

So it's going to be a little longer before I'm functionally back to where I was several weeks ago. The time has not been wasted, but the benefits aren't yet visible. That's the way it goes, right?

Ghostwalker: First Screens

After several months and a little work, I have the start of a game engine and the start of an idea. The basic concept of Ghostwalker is a generic first-person-shooter with a bit of "Legacy of Kain: Soulreaver" or "Dark Dominion" thrown in. Allow me to elaborate.

The as yet unnameds main character in Ghostwalker will have a limited ability to see into the spirit realm (if anyone has read Dark Dominion by Defiant Comics, they'll get the basic idea). However, normally he can only do this as he himself approaches death. In the same way that most FPS games these days communicate the player's health using on screen filters, usually a reddening of the screen, in Ghostwalker the player will be able to see into the spirit realm as his health gets lower. This will actually have the opposite effect to typical FPS games in that the player will have an advantage - there are no walls in the spirit world, so the player will be able to see enemies through obstacles etc.

Since health will not regenerate automatically (no Wolverine here, folks), the player will be able to play with low health to take advantage of this ability, at greater risk of dying in a firefight. Enemies may have souls that differ dramatically from their physical appearance, eg. werewolves will look human but have wolfman-like souls. Some enemies may be invisible, thus the player will not see them until he loses enough health to see their souls. Others may not have souls, such as zombies. The player may gain spells to allow him to temporarily see the spirit world even at full health.

I realize that the idea is not so different from the special vision modes, such as thermal vision, present in other games like Syphon Filter, however I'm hoping it will be better integrated, allowing the player to play without needing to stop constantly to activate his thermal vision goggles for a moment, only to switch back to normal vision. I'm also hoping it will be more visually interesting. Like I said, nothing groundbreaking. To be honest, I'm mainly doing this as a hobby to improve my own skills, if I someday have a halfway decent playable demo I'll be ecstatic. If any of my friends (you know who you are) are interested in helping, let me know. Truth is, I'd love some artistic help, I have a few character ideas that I'm too crap to draw myself.


The engine currently has a few features planned or in place:
-Efficient smooth LODing of meshes (more details to come).
-Real-time mesh splitting (haven't started to integrate it yet, but the engine is designed around the neccessary data structures).
-Multiple models per object for the two-stage rendering needed (physical and spirit models).

I have made some progress, with the framework of a game engine in place, some asset management code working nicely, and the basic smooth LODing system working in-engine. It's still nothing but a very basic rendering engine, with no physics or animation and only very basic rendering abilities. Still, it's enough to show a few early screenshots of the basic concept. These are using free models I nicked off the net:

Normal view:

Player at around half health, starts to see spirit world:

Player almost dead, visions is almost completely in spirit world:
Well, that's all for now. Soul Samurai out.

GhostWalker: Announcement

Since Geocities is closing, I decided to start a blog instead of a website, for now at least. I'll start by copy the entire contents of my old site in this post (previously on geocities.com/solesamurai/):



Soul Samurai presents: Ghostwalker

Ghostwalker is the tentative title of a game I am currently working on. At the current rate of progress, it will probably be ready to demo some time next millenium, so don't hold your breath. If you do start holding your breath, and you are still holding it next millenium, please contact the guiness book of world records. Don't try to contact me, I'll be dead.

Sorry, back to Ghostwalker. The game will be a first person shooter of modest proportions, but hopefully will have enough decent bits to be worth a quick look. I am currently working on the engine, which I am calling "Soul engine", because I am not very original. It is being written in C++ with OpenGL.

That's all for now, more details to come.