New splitscreen approach.

As posted here, I implemented a splitscreen mode for the engine.
The implementation is sort of dirty as all graphics are getting recreated per camera.

For instance: you want to draw a graphic with 4 player split screen.The graphic will then get created 3 times (1 graphic for each camera). That ensures that every camera has its own graphic with which it can do what ever it wants (like zoom, rotation, etc.)

As you can imagine, that is quite expensive and for many graphics on screen pretty memory consuming.
That seemed like a wasteful but working implementation until now.

It's just theoretical, but I'm pretty sure it is possible to reimplement it so that every graphic will only get drawn only for one camera per tick. If there's more than one camera, the graphic will get drawn for the next camera the next frame.

It'll go like this (C style pseudocode):

 void draw(IGraphic graphics*[]){  
      if(CURRENT_CAMERA < AMOUNT_CAMERA){   
           CURRENT_CAMERA = 1;               // Start from first camera  
      }  
      for(int i = 0;i < AMOUNT_GRAPHICS;i++){ //go through all graphics.  
           m_cameras[CURRENT_CAMERA]->draw(graphics[i]); //draw graphics into buffer of the current camera  
      }  
      CURRENT_CAMERA++; //Increment to camera counter and leave the draw function.  
 }  

So if the game uses 3 cameras it'll look like this:

Frame 1 : Draw graphics for camera 1
Frame 2 : Draw graphics for camera 2
Frame 3 : Draw graphics for camera 3

Frame 4 : Draw graphics for camera 1
Frame 5 : Draw graphics for camera 2
Frame 6 : Draw graphics for camera 3
....

I don't know if this implementation will cause a big delay, but I guess it's for me to find out ;)

Edit:
This approach will obviously split the FPS in half.
e.g. 60FPS / 2 Cameras = 30 FPS per camera.

That means that the game needs to run with ~120 FPS to look smooth with 4 cameras....
Shouldn't be a problem with a 2D game.

Splitscreen

Wohoo!
10 lines of code changed = splitscreen :) (Up to 4 cameras will be supported by the engine)

New arrivals!

Today the new books I ordered got delivered!
Including:

• Mathematics for 3D Game Programming and Computer Graphics
• Best of Game Programming Gems
• Der C++ Programmierer (a very up to date german book about professional c++ programming)

Unfortunately my exams are starting tomorrow. I guess I'll have to wait until my exams are over until I can start reading these books, altough I couldn't stop me to take a quick glance at the C++ book ;).

In addition, I hope the math book is good. I'm slightly starting to get to the boundries of my mathematical knowledge :-/.

Generic 2D collision system.

Today I want to explain the system I use in my engine for collision detection.
I tried to keep the collision system as generic as possible.

My engine provides a class called "CollisionComponent". You can add one or more components to a game objects to make them collidable. (Collision detection is done via collision rectangles).

To make the collision handling as generic as possible I decided to realize the handling "response" (the point where it'll get decided what to do with the collided objects) with function pointers.

You can "subscribe" gameobjects via typename (String) or a specific id (int) and with a pointer to a function that receives two pointer to game objects(first is the object that did "the impact" and the second is the object that got hit) and returns void.

Here's a little code snippet to make it more clear how that works:

 void collision_handler(GameObject *object1,GameObject *object2)  
 {  
    //...Do fancy stuff here  
 }  
 int main()  
 {  
    GameObject object1("Type1");  
    GameObject object2("Type2");  
    //...  
    //...  
    CollisionComponent *collComp = new CollisionComponent();  
    CollisionComponent *collComp2 = new CollisionComponent();  
    object1.addComponent(collComp);  
    object2.addComponent(collComp2);  
    //..  
    //subscription with type  
    CollisionManager::subscribe(object1.getType(),object2.getType(),collision_handler);  
    //..  
    //subscription with id  
    CollisionManager::subscribe(object1.getID(),object2.getID(),collision_handler);  
    //..  
 }  

The difference between subscription via type and id is that multiple game object can have the same type (for very generic collision handling like "bullet hits player" or "weapon hits enemy").If you want to make more specific collision handling you can use the subscribe function that uses ids because the ids of the objects are unique.

The only problem is that each tick each game object gets checked with every other game object.
That's not very performant, but I don't know how to do it better, yet.

Make your Engine more dynamic!

When I started to program my Engine, I wanted to create a somewhat portable Engine.
I wanted to support different libraries like OpenGL, OpenAL or DirectX to make my Engine run under Windows and other platforms.

My first attempt was to differentiate with the Preprocessor variables given by the OS
(For example _WIN32 under Windows).

That worked, but was somewhat ugly...

It was indeed so ugly that I decided to give it another try.
So I split everything into separate dynamic libraries.

At the end I had one library for every replaceable feature of my engine.
Here are some of them:

K15_GraphicModule.dll / K15_GraphicModule.so
K15_SoundModule.dll / K15_SoundModule.so
K15_InputQueueModule.dll / K15_InputQueueModule.so
They were implement as subsystems.

I'll try to explain the idea behind the subsystems by the example of the GraphicModule.

The GraphicModule is, for example, a subsystem of the Engine's GraphicManager.
The GraphicManager will try to find a "K15_GraphicModule.dll" or "K15_GraphicModule.so" (depends on the OS) in it's initialize function. When it finds the dynamic library, it loads it and tries to perform the function "createGraphicModule()" within the library.

The function createGraphicModule will return an implementation of a GraphicModule interface that is declared inside the Engine's library file.

Here's some code to clarify my example.

 GraphicManager::GraphicManager  
 {  
      typedef createGraphicModule IGraphicManagerModule* (*createGraphicModule)(void);  
      DynLib graphicLib("K15_GraphicModule") // load library (without extension...Determined by the current OS)  
      if(graphicLib.loadedSuccessful()){ //Check if library has been loaded.  
           createGraphicModule func = (createGraphicModule)graphiclib.getFuction("createGraphicModule");  
           if(func != NULL){ // function loaded?  
                this->m_subsystem = func(); //get Subsystem from dynamic library.  
           }  
      }  
 }  

This system allows me to switch between OpenGL and DirectX just by replacing the dynamic library files...Or to switch from Windows File Manager to some Unix File Manager just by replacing the library file.

I just implemented this system about a few days ago, so I don't know how well that will work in an actual game...But it's only a matter of time 'till I know it ;-)

Personal point of view (game engine).

(This post is absolutely IMHO so if you disagree with some points, that's just fine ;) )

Since I'm registered in the GameDev.net forum I noticed many people who were quite clueless wether they should make their own game engine or use a premade one.

I kept asking these questions myself back in the days I started game development and so I though it would be a good idea to make a little post about my personal point of view when it comes to game engines.

Before I start, I'll give you some examples of what I'd like to call good premade game engines:

• Ogre3D (which is open source)
• Unreal Development Kit (which is free for non commercial games (I was surpised when I heard about this))
• Unity3D
• RPG Maker (Which I made my first game with back in 2001...Man, that game was shitty!)

Check out the websites of these engines to learn more about them.

The first thing you should ask yourself when it comes to choose between selfmade and premade is why you want to make a game (engine).

Are you doing it for the sake of learning or just to, well..., make a game?
And, secondly, are you just doing it for fun or to make some sort of portfolio to get your foot into the industry (and if so,what kind of job do you wish to get? Developer, designer, etc.)?

Thats the points you should be certain about.

If you just want to make a game and don't care about the stuff going on in the background you should be fine with a premade engine. The learning curve should be much higher compared to a selfmade engine. (If you wish to work as a designer even a level editor like the Hammer editor from Valve (which you can get on Steam), or the Unreal ED (which is included in the above mentioned UDK and a part of nearly every installation of a Unreal related game (Unreal Tournament,Unreal)) should be enough to improve your portfolio).

I know that many people disagree with me on this point, but if you are interested in how things work (and especially as a developer) you should definitely start with your own engine. I learned tons of stuff since I started to work on my own 2D engine. Of course, programming your own engine shouldn't be your first project. I would recommend you to start with 2-3 simple games like Pong,Tetris or Pacman(especially Pacman is harder to realize then you might think at first) to get a feeling what components it takes to make a game.

If you are interested in starting your own engine, I can recommend the following books:

• Game Coding Complete (By Ultima Online developer Mr. Mike)
• Game Engine Architecture (By Naughty Dog employee Jason Gregory)

If you're stuck at one point and definitely have no idea what's wrong you should register in the above mentioned GameDev forum and search for your issue...Maybe some guy had the same issue before.

Thoughts about 2D animations.

I know that I shouldn't think of such things like animation systems (considering that I'll write my final exam tomorrow) but it's just something that got to my mind yesterday while I was falling asleep.

Actually I'm using a fairly simple approach for animations.
To create a animated graphic in my engine you got to use the following syntax (The parameters should be self explanatory):

  GraphicsFactory::createAnimatedGraphic(Uint32  animationStepTimeInMilliseconds,Uint8 animationSteps,bool autostart)

After you created the object you can add a graphic to it via:

 animatedGraphicObject.loadGraphic("graphic.png");

(I know its a strange way, but I'll stick with this for now)

When the graphic gets drawn, only the current animationframe will get drawn.

Example:




This System works great for a normal walkcycle like this, but if you have an animation like this:






The system isn't the best solution.

The reason for that is the bounding box (bounding boxes are used for collision detection and are almost always as big as the animation frame) of each animation frame. In the walkcycle example the size of each frame never changes (its always 24x32), but if you see at the second example, especially this frame:





you'll might notice that this frame (109x49) is way bigger than the other frames (62x44 and 80x44).

If the above mentioned system is used, the bounding box of each frame is equally to the bounding box of the biggest frame. (I hope you get what I'm trying to say)

This is a big disadvantage IMHO because if a bounding box collision is detected, the collision system goes into pixel perfect collision deteciton (at least in my engine), which is way more expensive than the bounding box collision.

To avoid this problem I thought of the following approach.

At the point where the user determines the amount of animation frames, the size of each animation frame is known. (Width of the graphic / amount of animation frames = size of the biggest animation frame).

The next step would be to check each pixel of each animation frame for its color value to determine the real bounding box of each animation frame by comparing the color value of the current pixel with the color value of the images color key (The color key is the color in the image that is invisible later in the actual game).

After that step, each animation frame can be packed into an array, so you get a nice animation with perfectly fitting bounding boxes for each frame :)

Graphic creation technique finished!

The content of this video is just me testing the AbstractAnimatedGraphic class.
The graphicfile used for this animation is the following:



The animation is just yoshi, turning around his own axis.
In the video you can see that it is possible to regulate the animationspeed by
key pressing (well you can't see the actual key press).
This feature could be used for fancy slow-motion effects ;)

I also just finished the graphic creation factory.
My engine will support 2 different graphic modes.

1. Pure SDL (DirectDraw under Windows)
2. OpenGL

When the function getNewGraphic() from the class "GraphicFactory" get's called,
the engine will check specific configuration flags (which you can change on runtime)
to determine the derived type of the returned AbstractGraphic object (AbstractGraphic is the class that SDLObject and OpenGLObject inherit from).All created graphicObjects are saved to an list to support easy conversion on the fly if the user wants to switch the graphics mode during gameplay.

It's time to sleep now.
I had to work the whole weekend and didn't got much sleep.

Character designer ready!

I've just finished the character designer I started 3 hours ago.

Now I can easily create new GameActors with specific actions/animations and states for my engine.

Rendering of levels complete!

I just finished the part of my engine where the levels that got created with the leveleditor gets rendered.
















The left window with the black background is ingame and right window is the leveleditor.

New video of the current state (finally!)

I finally managed it to create and upload a new video of the current state of the leveleditor. As you can see, I added several new features like the toolbar (on the left - with the ugly icons ;) ), multilayer drawing, event creation and several other things.



I once again recommend to watch it in fullscreen.