Difference between revisions of "SDL gfx"

From X-Moto
Jump to: navigation, search
m (added images to show the progress)
(news)
Line 74: Line 74:
  
 
== news ==
 
== news ==
 +
[[User:Keesj|Keesj]] 14:53, 22 December 2006 (CET)
 +
 +
It's currently possible to select the rendering engine as startup option. This is a bit of magic
 +
because when running like this some calls to the opengl api are made, apparently this doesn't cause the program to crash. I am very happy with the current rendering of the title screen. I hope The performance will stay oke:).
 +
 +
 
[[User:Keesj|Keesj]] 09:50, 21 December 2006 (CET)
 
[[User:Keesj|Keesj]] 09:50, 21 December 2006 (CET)
  

Revision as of 13:53, 22 December 2006

Català - Español

SDL_gfx Rationale

OpenGL is the default graphics rendering engine for xmoto. It provides a nice look to the game. The biggest problem we have with OpenGL is that it requires special hard- and software. We are Therefore currently writing a second graphical front-end to xmoto using the SDL_gfx[1] library

We expect the SDL_gfx front end to become a good alternative for the OpenGL frontend but not a replacement. In an ideal world we would like to be able to switch between the renderings engines at runtime.

Current rendering engines

xmoto in normal opengl mode
xmoto in ugly opengl mode

There are currently two rendering modes a normal mode and an ugly mode. Both are opengl based modes that require good working opengl hardware because software OpenGL is not fast enough for good gameplay. We think the SDL_gfx rendering frontend should look better then the ulgy OpenGL rendering engine. The two rendering modes currently can be switched at runtime and are implemented by having if/else statements in the code.

VDraw and the GUI framework

Vapp Inheritance diagram

The xmoto game contains a GUI framework and a 2d drawing library (VDraw) built on top op opengl. They provide some abstraction of the drawing. Drawlib is the main abstraction from opengl and both the xmoto applications being the editor and the game extends this drawlib. I am not sure why inheritance is used but it makes ik hard to make the DrawLib pluggable

The GUI framework also use the DrawLib for most functions. Currently not all the drawing functions are provided in the DrawLib an drawing is done in many parts of the application.

If we want to be able to provide an OpenGL less implementation of the game the OpenGL specific parts of the game need to be moved to the DrawLib or excluded with USE_OPENGL defines.

The good thing is that the DrawLib and the GUI framework provide enough abstraction so that it is possible to replace the OpenGL calls with different calls to the DrawLib. So if we don't want to throw away all the GUI code we need to solve the problem. currently we have chosen to replace opengl call with similar call to the drawlib

Sample of old code using opengl

  /**
   *old opengl mode
   **/
  void GameRenderer::_RenderCircle(int nSteps,Color CircleColor,const Vector2f &C,float fRadius) {
    glBegin(GL_LINE_LOOP);
    glColor3ub(GET_RED(CircleColor),GET_GREEN(CircleColor),GET_BLUE(CircleColor));
    for(int i=0;i<nSteps;i++) {
      float r = (3.14159f * 2.0f * (float)i)/ (float)nSteps;
      _Vertex( Vector2f(C.x + fRadius*sin(r),C.y + fRadius*cos(r)) );
    }
    glEnd();
  }

After adding a few functions to the DrawLib this code now looks like this.


  /**
   * new abstracted code
   **/
  void GameRenderer::_RenderCircle(int nSteps,Color CircleColor,const Vector2f &C,float fRadius) {
    getParent()->startDraw(DRAW_MODE_LINE_LOOP);
    getParent()->setColor(GET_RED(CircleColor),GET_GREEN(CircleColor),GET_BLUE(CircleColor),255);
    for(int i=0;i<nSteps;i++) {
      float r = (3.14159f * 2.0f * (float)i)/ (float)nSteps;
      getParent()->glVertex( Vector2f(C.x + fRadius*sin(r),C.y + fRadius*cos(r)) );
    }
    getParent()->endDraw();
  }

Project short term goals

  • xmoto_hack on the Nokia 770 (16bpp/800x480) to learn what the problems are
  • give information about the performance , lessons learned
  • document new code
  • find people to port to different platform

TODO

  • When xmoto is starting it loads all the levels, this is not nececary and should not happen.

news

Keesj 14:53, 22 December 2006 (CET)

It's currently possible to select the rendering engine as startup option. This is a bit of magic because when running like this some calls to the opengl api are made, apparently this doesn't cause the program to crash. I am very happy with the current rendering of the title screen. I hope The performance will stay oke:).


Keesj 09:50, 21 December 2006 (CET)

This week we have made quite some progress and are almoot back on track. We restarted the project from srcatch. This time we used the xmoto CVS and first started by refactoring the current code while keeping testing if the OpenGL version kept working. This went quite well. we can now build the opengl and the SDL_gfx version from the same source tree. We hope it will be possible to select the rendering engine at runtime.


Keesj 09:50, 19 December 2006 (CET)

Our patch to SDL_gfx was accepted and SDL_gfx version 2.0.14 now contains the texturedPolygon method required to draw nice textured polygons for the game http://www.ferzkopp.net/joomla/content/view/19/14/. Keesj 14:07, 17 December 2006 (CET)


Yesterday a branch was created to allow the code to be contributed the cvs branch is called SDL_GFX_INCLUSION

Project progress with images

18 11 2006. running on a real Nokia 770
22 11 2006 running the profiler with xmoto(on PC)
05 12 2006. texture are starting to appear (on PC)
10 12 2006. Making some progress,the black backgound look better and text drawing is faster
14 12 2006. Trees are now rendered
22 12 2006 title screen of Xmoto in SDL_gfx mode, almoost perfect !!!
22 12 2006 The moto itself is not rendered nicely, but look at the nice background
22 12 2006 Pause screen with alpha blending