Game Development

Some stuff

Yeah, so it’s been quite a while since I put anything on this blog. I’ve been spending a lot of time elsewhere and doing other things.

I’ve still been programming on my own engine and such in the background and working generally on experimentation and thinking (thinking long and hard) about things I could be doing differently and things that I’m doing that maybe I don’t need to and so forth. It’s extremely careful consideration work going on…

Other than that I’ve written an extension for my 2D engine project, formerly called “Junebug”. It’s now called “SpiderTank” instead. The details to this name change are irrelevant… but spidertanks are sort of cooler than junebugs. Less cute… but cooler.
But the idea is still the same… Simple and fast 2D engine. I’m right now working on ways on rendering a virtual screen resolution, to support more low-resolution games that don’t necessarily try to squeeze your fantastic full HD desktop into a sorry 320×240.
More on that later when I get it to work on a satisfactory level.

Yeah… What else… I’m working loosely on a bunch of concept projects, not going to name any of them since I can’t at all commit to them at this point, they’re way to fresh.

But mostly I just want to make games at this point, and that’s what I’m trying to do. 🙂


Yeah. I’m sorta involved in a project now with some other people so there’s a pretty big chance that I won’t upload anything on this blog for a while.
Unless I want to write about something else than just engines and stuff, but most of my “programming power” will be directed towards the mentioned project.
Oh- I’m also busy with school right now so that makes for even less time to “waste” on my usual stuff.



It’s that time again. Time for some random updates and such.

Been kinda hard at work the past few days trying to implement the stuff I need and want to have in my engine so that I can continue working on my game (Nope, still not saying what it is.). And it’s going pretty great actually.

Right now I’m working on the final steps of support for my model format and the shading pipeline for the engine.
The shading pipeline will be based on forward rendering, I’m not too invested in putting in deferred rendering again (even if that stays on the future vision for the engine), and it will be pretty restricted. But I’m confident that when I get this to work completely, I can easily extend it to support whatever I want. I’m trying to be focused on making a robust system before putting anything too fancy in.

So anyway. This morning I put in the initial code for bone animation and it’s working. So now I need to implement a means of animating it. I’ve got a pretty good idea of how to make a system that supports animation layering with an arbitrary number of layers and I’m going to get to work on that soon. Morph targets will have to wait a little while.

What else? Oh. Yes. I’m going to start putting static shadowing in, so that I can generate shadow and ambient occlusion maps for entire levels. I think it’s going to look cool enough. I’m going to base this on the Ambient Occlusion code I posed about a while ago.

Anyway. I’m going to get back to it. The next post I make will be about shading mostly. I think.
Bye. 🙂

Edit: Forgot to mention.
I know I talked a little about a 64 bit vertex structure that I was using that was running out of space for other stuff.
I should never have stored binormal information in the vertex structure, and I stopped doing that. I recreate the binormal in the vertex shader instead. So now I have some more space to toy around with.
Well not really. Animation support still takes up a large chunk. I mean- 4 floats for bone weights and 4 indices for bones. That’s a damn lot still. I think I could do with 2 weights per vertex however. It wouldn’t be that bad.

Mesh Opt. Update


Just dropping off a quick update here for my mesh routines and what not.

So right now, it is working as intended with VBO support just put in this minute. I’m super happy that this is working right now after SO many hours of planning and thinking.
I still have this gut-feeling that something is waiting around the corner ready to smack me in the face with a hard case of failure and I’m slowly and easily trying to find out parts that might start acting up strange in the near future.

And even though this is working it is only working with the standard information like vertex-coordinates(obviously), uv-coordinates and normals. I still need tangents for normalmapping and just thinking about it, it shouldn’t be that tough to implement, but still. It could take some doing.

So anyway right now the only processing I have for my meshes is this one routine that duplicates vertices as it sees necessary to accommodate to the VBO’s restriction of just using one UV-coordinate and normal per vertex so the meshes are able to draw correctly using VBOs.
This was not a trivial task, and the code I’ve written to produce this result is very, very, very ugly. So I’m fixing on making it an offline process as soon as possible.
I’m actually thinking of making it an automated process linked to the exporter script from Blender so I get optimized meshes straight out of the modeling tool instead of having it be an intermediary step. We’ll see.

So WOO! Back to work!



Haven’t really been programming that much because I’m focusing on art again but since the last time I posted I’ve been working on animations, and it’s working right now. But it’s a tad uglier than I expected so I’ll have to introduce a new way of interpolating frames or use more keyframes in my animations.
It’s not horrible-gouge-out-my-eyeballs ugly animation but it’s just jerky enough to be a bit jarring to look at.
It’s especially noticeable during slowed down animations where the keyframes interpolate really slowly. It sort of ends up with like a pop-and-lock type movement.

Aside from this I’ve got some other features in mind to integrate. One of them being animation blending, where I just layer a bunch of animations onto a model with variable weight so you can blend a bunch of animations that affect the model with their own amount. This is especially useful in situations where you want to add a little more complexity to an animation depending on a situation the model is in, such as hunching a model over depending on how it’s hurt, but allow it to continue animating like it usually does. It’s also useful when blending from one animation to another, like walk -> run -> jump and so on.

After all that it’s time to optimize the crap out of it, or at least optimize it as well as I know how, which doesn’t say that much IMHO, but anyway.
I’m trying to make it as fast and resource efficient as possible. That’s the goal.

… I’m also performing all this on the CPU… And in immediate mode OpenGL- *ducks for cover*.
*Phew* That was close. But here me out, this is just temporary.
I’m working right now on my model pipeline and moving it over to use VBOs. I’ve been having some problems with the current state of my model format that didn’t get along with VBOs that easily, so I’ll have to rewrite the exporter and parser to make that easier.
And at that point I will also have integrated a substantial shader pipeline so performing skinning on the GPU should work fine.

Now. In different news I’m rewriting part of the scene manager for the engine, for like the third time. And I’m doing this to support better error checking and features like that. I really don’t like having problems and not understanding it, especially when it’s something I’ve created myself. So that’s why I’m prioritizing engine -> user communication. Not only for me, but also if I ever decide to release the engine (which is very unlikely at this point.).
I’m also working on abstracting and wrapping the hardware API even more and trying to generalize it as much as possible and make it as “slim” as possible. I want my engine to run on a lot of different computers with as little problems as possible.

Another thing I’m working on (It’s really piling up now, isn’t it?) is integrating a better filesystem for handling all sorts of external scripting and stuff for materials, sounds and all that. But I’m at the same time aiming at keeping it to a minimum, because using an engine with a big file overhead, the need to have hundreds of files just to run the damn thing, is not in any way desirable.
Most external scripts and definitions will be in XML… Because it’s easy to read and write.

So lastly the thing I want to delve deeper into is, as I’ve mentioned before, physics with the Bullet physics library.
I’m excited to see how well it’ll work, and I’m excited to implement cool stuff like slow-motion and different sound effects that play when materials rub together or impact each other.
For the record: I’ve been interested in implementing the physics sound stuff ever since I saw it in the Frictional Games’ Penumbra tech demo 2006. 🙂
And I have some good ideas I can implement with that to create some immerse physics.

So I’ll just go back now and make something.


Hello again. About time I updated this thing. 🙂

Yes, well. This past time hasn’t been too exciting development-wise. Mainly because I’ve been spending a great deal of time reading up on theory, rather than indulge in the practical side of things. And I’ve been going through all sorts of things, and my main goal right now is to visualize them inside my engine.

As far as my engine goes, I’ve got plans mostly at this point. The code base I had I decided to scrap entirely. I saw that it wasn’t going anywhere nice so I’m going to rewrite it with some new designs in mind.

There are two major things (that are worth mentioning) I’m changing with the structure of the engine. The first is my switch from CG shader language to GL shader language (GLSL). I’ll explain in short why I made this choice.

Back when I started looking at shaders seriously I was still in a state where I couldn’t decide whether I’d use OpenGL or DirectX. Today however, I am sure that I’m OpenGL exclusive.

Therefore the thought of CG seemed a bit redundant, as part of it’s design enables cross graphics API (OpenGL, DirectX). I used to think that “Oh, I can write the shaders once and use them cross graphics context whenever!” and I thought it was neat as all hell. But this is, again, redundant as I have no problems converting between HLSL (DirectX’s shading language) and GLSL should the need ever arise.
I like CG in many ways but I don’t see a need for it right now right here. This may change though, who knows.

The second change worth mentioning is the change of collision and dynamics to Bullet instead of Newton and PhysX (which I used interchangeably. I had two wrappers.)
The reason is pretty much that I’ve been looking at it for quite some time (about as long as Blender has had it as the physics layer! Omigosh!) but never got into it or gave it a fair chance. That’s about to change! 😀

There it is! My first sphere simulated by Bullet! Wow! Amazing isn’t it?
And you’ll just have to sit there and look at it, wondering whether it really is simulated or if I just staged it to look incredibly boring, Mu-ha-ha-haa!
OK, I’ll stop. It’s actually simulated and rendered using the earliest graphics shape class in my engine. About as pretty as that gets.

So I’ll just get back to making my plans get closer to their goal. You’ll be able to see on this here blog what those plans are a bit later.

Bye! 😀

Building stuff


I’m back with some stuff I have to vent somewhere. This blog is unfortunately caught in my line of fire this time.

So for a while I’ve been thinking a lot on how I would best go about to create actual game assets to use in my engine. Like: levels, models, sprites whatever might exist in a game. But the main thing that vexes my mind is the actual levels. I can easily load a single model into my engine and have it display with a shader effect, have it run through different animations and all that.

But a level is so much more and so much bigger than a single model. Sure, I *could* theoretically cram an entire level into a big model file and run around in it. But that would combat the very thought of component based, reusable level building, which is a must in many cases, and neutralize the very idea of performance. Having such a large model in any memory is simply a waste.

And because a level is so big. It therefore needs some guarantee of consistency between textures so everything looks to be about the same size referenced to each other. The models we put in, however, are going to be of the right scale no matter what. As long as you adhere to the unit scales in the 3d program.

The reason why this texture resolution problem exists in the first place is because of the way you’d have to unwrap 3d models in the 3d program. It’s a very free process so the final result UV unwrapping can take on any weird scale or angle, making it a pain to see in the game.

So I’m not so sure how I’d go about to solve this little “problem”. Not only do the levels have to be consistent in scale and texture resolution so they look correct, one has to be able to make them in reasonable time.

Other games I play from time to time are from the mid to late 90s, early 2000. So most of their level architecture is built out of “block” type structures, as seen in… Uh… Any game that has a majority of architecture that looks like it’s carved from blocks. This stuff is called CSG by name. I think this applies to any game that has this “blocky” type level structure. I’m not sure.

This, of course, inspires me and I’m from time to time thinking if I should go about to use something similar to make level editing more consistent and robust. I’m not sure if it would prove that beneficial in the end anyway. It would pretty much solve any texture problems though. The scale and everything else would be really consistent.

I’ve spent a good deal looking at the engine for the Penumbra games and Frictional Games‘ current engine for inspiration. And it looks as if they are onto something really great. And I’m just guessing most of my projects could benefit from a similar work-flow like the one they’ve set up. I’m mostly thinking about their way of handling levels in their current engine which makes for a good deal of designer freedom and supplies a good level of consistency.

But somehow I feel that it wouldn’t work that great for outdoor environments and that I would need to incorporate some special-case stuff for larger, outdoor areas.

Well in the end I guess it’s the best type of experience to actually try to work with it and see whether I raise myself a living hell or if I’m able to get away with it without gaining any new body-cavities.

I’m also just guessing that this kind of stuff has to be connected closely to what type of game I’m building. Because building an engine in complete disconnection to whatever game it’s running in, is something that I feel won’t be the least bit beneficial in the larger scope.

Whatever. I’ll try some stuff out and see what of it.