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)

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.

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.