DMINATORs BLOG

Another photo

noreply@blogger.com (Dmitri Kuznetsov) — Tue, 05 Aug 2008 18:13:00 +0000

I haven't posted a photo update here for some time. So here it goes - a new photo taken atTallinn harbour in june.

Need super macro lens ? Make them yourself !

noreply@blogger.com (Dmitri Kuznetsov) — Sat, 02 Aug 2008 20:19:00 +0000

I am a big macro fan.

So when I see a bug or insect, I usually take a camera and shoot it. The problem is that my kit lens aren't good enough. So I needed something better.

Well I made a lens myself. A rather easy thing to do if you have some materials. The lens construction is very simple just one front element from an old soviet 'LOMO' camera and a tube.

Here is how it looks like:

Here is a front lens element:

And a comparison with other lenses (from left to right: kit 18-55mm, my custom super macro, 70-200 f2.8 IS):

I think the lens produces about 3-4 x magnification. It is pretty hard to use, because I have to hold it close to the camera, set exposure and aperture manually. Picture in a viewfinder is almost black so it is very hard to see anything. Still it is possible to make some interesting pictures:

Bubbles in the glass:

Bristles of a toothbrush:

And here is a small part of some flower:

I also added a slideshow from the picasa album with other pictures:

Listbox yeay !

noreply@blogger.com (Dmitri Kuznetsov) — Wed, 30 Jul 2008 22:22:00 +0000

Well.

I finally added the listbox to the GE2 GUI control list.

Initially I wanted to implement a container control that would allow scrolling of its child controls(contents). I took a pretty complicated task. As it turned out later, the idea had a major flow. The problem was that container control has a fixed size. Now when other controls are located inside it, their size changes depending on the distance between child and parent control bounds. But scrolling assumes that there are 2 areas: visible area and full size scrollable area. I couldn't figure out how to combine these two things together.

So my conclusion was that in order to implement scrolling properly each control should have different scrolling logic depending on the control functionality. And it is how the windows controls work, I think. Just look at the listbox or window scrollbars functionality.

Anyway the listbox is working, and as usual the final implementation was a fairly simple one, especially for the end user.

This is how it looks in the template file:

<overlay>
name = "list_box_item"
align = "left | top | right "

<objects>
<text>
name = "caption"
text = "list_box_item"
dock = "fill"
</text>
</objects>
</overlay>

<overlay>
name = "list_box"
minimumWidth = 0.1
minimumHeight = 0.1

width = 0.10
height = 0.20
<items>
<item>
value="1111"
</item>

<item>
value="2222"
</item>

<item>
value="3333"
</item>

<item>
value="4444"
</item>

</items>

<objects>

<container>
name = "container"
dock = "fill"
padding.right = 0.05
</container>

<v_scroll_bar>
name = "vscroll"
height = 0.20
left = 0.05
dock = "right"
scissor = "parent"
</v_scroll_bar>

//A background rectangle to show control bounds
<background>
name = "background"
dock = "fill"

<states>
normal = "check_normal"
disabled = "check_disabled"
</states>
</background>
</objects>
</overlay>

You can see the container and scrollbar here. The scrollbar is recognised when control is loaded and is linked to the container event system automatically. So when you scroll it, the container contents are scrolled also with it.

The background serves only a visual purpose by showing white grid on top of the listbox to make it look more distinct from other controls.

The other thing that listbox requires is the definition of how the listbox items would be displayed. This is where list_box_item overlay is used. It can be overloaded by specifing template = "list_box_item" clause manually inside the listbox overlay. User can also create their own class with advanced logic and show it instead of the default type.

Listbox items itself can be added very easily:

lbox1.items.InsertBack( "string1" );
lbox1.items.InsertBack( "string2" );

And changed :

lbox1.items[0] = "changed2";

Note that item_changed event is automatically triggered when any item gets changed via delegate. A tricky system but it works!

There are many events that get triggered when different things happen to the listbox. The most important event occurs when user clicks on different item. Video shows a really good example how it actually works. From programmers perspective:

lbox1.OnSelectedIndexChanged = MemberFunction( &GUITest::listBoxSelectedIndexChanged );

The new value is obtained via arguemnts passed with delegate:

void listBoxSelectedIndexChanged(GUIBase* sender, GUISelectedIndexChangedEventArgs* args)
{
if( args != NULL )
{
lblIndex.caption = args->newItemValue;
}
}

That is as easy as it can possible get.

Here is a video: (I have also added a new Youtube feature - annotations)

ADOgames forum opened!

noreply@blogger.com (Dmitri Kuznetsov) — Fri, 25 Apr 2008 19:22:00 +0000

Hi.

ADOgames forum is now operational.

We would try and keep the forum updated with information regarding our current projects. Forum is also permanent place for the discussion about Galactic Engine 2.

Go ahead and visit us:

GE2 GUI Prototype 1.5 TrackBars

noreply@blogger.com (Dmitri Kuznetsov) — Tue, 22 Apr 2008 22:00:00 +0000

Hi.

I would like to give another update regarding the new GUI I am working on.

The latest changes that were made:

1. Control position bounds:
Every control position now can be limited to certain bounds:

2. DragBox grid snap:
It is possible to define how the drag control item position would be rounded when it is dragged.

3. DragBox axis filter:
For DragBox the programmer can define in which direction the drag control would move. Either X , Y or both

Using all these features it is possible to define TrackBar.

The trackBar is a simple control that has a small control usually called "Thumb" or "Slider".
Every windows user is familar with display control window with resolution trackbar:

In Galactic engine there are 2 trackbar controls: vertical and horizontal. Each control has a "thumb" which itself is a DragBox control. The DragBox was defined with position bounds so it wouldn't pass through the trackbar parent size rectangle. Also it has a specific axis defined so it would drag controls only in one direction. When dragging is occured the control finds new thumb position and recalculates current trackbar value based on relative percentage between minimum and maximum values.

Trackbars can have also the maximum and minimum values set, so the thumb would only move within these limits.

Here is a video that demonstrates new trackbar in action:

For more information visit Galactic Engine 2 forum

Stack walker added

noreply@blogger.com (Dmitri Kuznetsov) — Wed, 16 Apr 2008 18:01:00 +0000

Another little update.

I have added stack walker for the engine created by Jochen Kalambach. It is helpful tool that shows how the functions were called. With a little utility dbghelp.dll it is possible.

Here is a screenshot that shows error report:

By default any error in debug mode produces stack trace automatically. In release mode however it needs to be manually specified through config file.

GUI progress - drag box fun

noreply@blogger.com (Dmitri Kuznetsov) — Fri, 11 Apr 2008 18:34:00 +0000

Another update.

Finally I added scissor functionality. It should cut any controls that move out of parent container bounds. You can clearly see this in action.

Another thing I wanted to show is drag box. It is possible to make drag box move almost any control including window close button.

GE2 GUI Prototype 1.3

noreply@blogger.com (Dmitri Kuznetsov) — Thu, 03 Apr 2008 17:10:00 +0000

Hi.

Another little update regaring new GUI system.

A few things that I managed to add:

1. Custom cursors for any type of control (You can see that in a video, how cursor style changes on hover event)
2. Focus - Control that was used recently recieves input from keyboard.
3. Switching between controls with TAB key. Kinda basic function that everyone uses in windows but a little harder to implement than it may look.

Here is another video that shows the recently added features:

SunAge new RTS

noreply@blogger.com (Dmitri Kuznetsov) — Tue, 01 Apr 2008 21:26:00 +0000

Here is an interesting project that guys were making for 11 years!

SunAge

The best part is that it is finally finished and it looks really awesome. Although I haven't tried it yet, I am looking forward to it in the future.

Definetelly check the video teaser:

GE2 GUI progress 1.2

noreply@blogger.com (Dmitri Kuznetsov) — Sun, 30 Mar 2008 20:28:00 +0000

Hi.

Another little update. Here are few things that I have recently added :

1. CheckBox - Simple control with .checked property just set it to true or false.
2. RoundBox - works completelly automatically. If one round box is checked then all the other check boxes within the same contianer would be unchecked.
3. Enable/Disable states. Another proprety for every control. Works by setting .enabled to true or false.

Here is a video that demonstrates all of this in action:

GE2 GUI work in progress 1.1

noreply@blogger.com (Dmitri Kuznetsov) — Wed, 26 Mar 2008 20:43:00 +0000

Hi.

Just wanted to show a little progress with the new GUI system. Check this video:

It shows basic GUI system in action. One of the key features displayed in this video are:

1. Working event system. Mouse Click,Hover,Move
2. Working controls : button , drag_box, resize_box
3. Text Alignment - shows that any text in any control can be aligned either to one edge or stretched between different edges.
4. Anchor and dock in action. Inspired by .NET and quite similar to it.
5. Ability to manually override close_button on a window. Look how one window doesn't has close button.
6. Minimum and maximum sizes for the control. When the control is resized these values are applied.

A few things still needs a little work:

1. Scissor - The problem is that some controls break away from their parent container edges.
2. Add Enabled/Disabled states.
2. Add other controls...

Galatic Engine 2 GUI development continues

noreply@blogger.com (Dmitri Kuznetsov) — Mon, 24 Mar 2008 18:28:00 +0000

I haven't updated the engine version for some time now. This is because I have been really busy with new GUI development. I don't want to go into details about the new features because some of them are still in testing. Anyway here is one little widget I made it with Flex Builder. It shows how long I have been developing new GUI.

The reflection skin has been taken from here

I still can't believe it has taken it so long !

Wild Boar TV Online

noreply@blogger.com (Dmitri Kuznetsov) — Thu, 20 Mar 2008 17:18:00 +0000

Here is an awesome new service that has taken Estonian homes and offices by storm:

WildBoar TV!

It was created by some enthusiast from nature calender. It is a live stream from a place in the woods used for feeding wild boars. Check this page for archives Here

Or you can see what is going on there live here.

Picture © looduskalender.ee 2006

Dolar drops below 10 EEK

noreply@blogger.com (Dmitri Kuznetsov) — Mon, 17 Mar 2008 18:02:00 +0000

It is the first time ever that dollar has dropped as low as 10 EEK.

EEK is Estonia's currency.

Here is a little graph to show the tendency of changes:

I have been following the changes within US economy for sometime and it keeps getting more and more worser. The disturbing factor is that US Federal bank keeps making the same steps and they doesn't seem to be working.
Another problem is that Oil prices are rising and well it impacts everyone in the world. I can only hope it would end soon.

Stage6 shutdown

noreply@blogger.com (Dmitri Kuznetsov) — Sun, 09 Mar 2008 21:02:00 +0000

Unfortunatelly the popular video service at stage6.divx.com was shutdown. Here is the official explanation from the site team:

Stage6.com has been shut down. Thank you for supporting the service.

We created Stage6 with the mission of empowering content creators and viewers to discover a new kind of video experience. Ultimately, the continued operation of Stage6 was a very expensive enterprise that required an enormous amount of attention and resources that we at DivX are not in a position to continue to provide. There are a lot of other details involved, but at the end of the day it's really as simple as that.

The DivX experience will continue, of course. Every day new DivX Certified devices arrive on the market making it easy to move video beyond the PC. Products powered by DivX Connected, our new initiative that lets users stream video, photos, music and Internet services from the PC to the TV, are hitting retail outlets. We remain committed to empowering content creators to deliver high quality video to a wide audience, and we'll continue to offer services that will make it easy to find videos online in the DivX format.

It's been a wild ride, and none of it would have been possible without the support of our users. Thank you for making Stage6 everything that it was.

There is another service that has the same and even more features - veoh.com

One of the key features is the Pro version. It allows synchronization of videos with different video services. For example you upload a video and veoh does all the uploading for you for other services like google video or youtube.

There is also a video browser program that can be downloaded for Mac or windows. It searches and plays back all the videos that can be found on google video or youtube.

Here is blazetris with veoh:

Online Videos by Veoh.com

Line cap calculation

noreply@blogger.com (Dmitri Kuznetsov) — Mon, 19 Nov 2007 20:14:00 +0000

To continue my previous post, I would like to explain a little more about how the line cap is calculated.

Here is the order at which the line is rendered:

1. Line Start Cap calculation
2. Join vertex calculation n1
3. ...
4. Join vertex calculation n1 + joinNum
5. Line End Cap calculation

As you can see the cap starts the line and ends it. Because I am using GL_QUAD_STRIP then it is important to properly connect all the vertices together, and espcially make their total number base power of 4, because each quad consists of 4 points.

There are usually 3 different cap styles:

1. None (the cap vertexes are created at origin of the start/end point) [2 vertexes]

2. Square (the cap vertexes are created at the same origin but with an offset equal the the line width)[2 vertexes]

3. Round (the cap vertexes form half-arc at the origin of the start/end point)[2 + 2*iterations vertexes]

So The first thing that is required - the general cap function:

//Calculates cap for the line
void CalculateCap( LineVertex v0,
                                   LineVertex v1,
                                   bool start ) //decides is this cap starts the line = true or ends = false
{

     float len = CalculateDistance( v0 , v1 );

     float dx1 = (v1.posY - v0.posY) / len;
     float dy1 = (v1.posX - v0.posX) / len;
     float dx2 = 0;
     float dy2 = 0;

     dx1 *= _size;
     dy1 *= _size;

    if( _capStyle != CapStyle_Round)
   {
        if( _capStyle == CapStyle_Square)
       {
            dx2 = dy1 ;
            dy2 = dx1 ;
       }

       if( start )
      {
           AddVertex( v0.posX + dx1 - dx2, v0.posY - dy1 - dy2);
           AddVertex( v0.posX - dx1 - dx2, v0.posY + dy1 - dy2);
      }
      else
     {
          //end of path
         AddVertex( v0.posX - dx1 - dx2, v0.posY + dy1 - dy2);
         AddVertex( v0.posX + dx1 - dx2, v0.posY - dy1 - dy2);
     }
  }
  else
  {

      //Converts radian result of atan2 to Deg we need for comaring later
       float subAngle = -(TRIG_RAD2DEG( atan2( dx1 , dy1 ) ) - 180);

     //simple but does check the direction of the line edge
      if( (subAngle > 90 )&&( subAngle <= 270 ) )
      {
             if( start )
            {
                    CalculateRound(   v0 ,
                                                   dx1, -dy1 ,
                                                  -dx1, dy1 ,
                                                   v0.posX + dx1 ,
                                                   v0.posY - dy1 ,
                                                   true );
           }
          else
               {
                   CalculateRound( v0 ,
                                                  dx1, -dy1 ,
                                                 -dx1, dy1 ,
                                                 v0.posX - dx1 ,
                                                 v0.posY + dy1 ,
                                                  true );
               }
      }
     else
          {
                    if( start )
                    {
                                 CalculateRound( v0 ,
                                                             -dx1, dy1 ,
                                                              dx1, -dy1 ,
                                                              v0.posX - dx1 ,
                                                              v0.posY + dy1 ,
                                                              false );
                     }
                     else
                          {
                                  CalculateRound( v0 ,
                                                              -dx1, dy1 ,
                                                               dx1, -dy1 ,
                                                               v0.posX + dx1 ,
                                                              v0.posY - dy1 ,
                                                               false );
                          }
             }
      }
}

This general function finds the result vertexes this way:

1. Finds relative position of the initial vertexes. Exactly the same way as it was made with "None" line join.

2.Now depending on the Cap style:

  None    - Just use these calculated vertexes and add them to the render buffer.
  Square - Apply line width multiplier and add them to the render buffer.
   Round - This is more complicated:

For round join the renderer needs to calculate arc:

void CalculateRound(
                                         LineVertex v0,        //center of the line join
                                         float dx1, float dy1, //the start point
                                         float dx2, float dy2, //the end point
                                         float middleX ,
                                         float middleY ,   //The middle point for creating correct GL_QUAD vertex                             bool reverse) //use reverse incase of inner join

{

          float a1 = TRIG_RAD2DEG( atan2( dy1 , dx1 ));
          float a2 = TRIG_RAD2DEG( atan2( dy2 , dx2 ));

          float angleStep = (a1 - a2) ;            //number of iterations
          angleStep = angleStep / (iterations + 1) ;            //starting angle
          float cangle = 0;

           if( reverse )
          {
                     //INNER JOIN
                     AddVertex( middleX , middleY );
                     AddVertex( v0.posX - dx2 , v0.posY - dy2);

                      a2 += 180;
                      cangle = a2 ;

                    for(int i = 0; i < iterations ; i++)
                   {
                            cangle += angleStep;                   //Also put the middle point for the GL to correctly link other GL_QUAD later
                          AddVertex( middleX , middleY );                   //find the rotated point                           AddVertex(
                                             _size * trig.Cos(cangle) + v0.posX ,
                                             _size * trig.Sin(cangle) + v0.posY );
                   }

                         AddVertex( middleX , middleY );
                         AddVertex( v0.posX - dx1, v0.posY - dy1);
          }
          else
               {
                       //OUTER JOIN
                      AddVertex( v0.posX + dx1 , v0.posY + dy1);
                      AddVertex( middleX , middleY );             //change the direction of angle iteration
                      angleStep *= -1;
                      cangle = a1 ;

                      for(int i = 0; i < iterations ; i++)
                     {
                            cangle += angleStep;                 //find the rotated point

                            AddVertex(
                                              _size * trig.Cos(cangle) + v0.posX ,
                                             _size * trig.Sin(cangle) + v0.posY );               //Also put the middle point for the GL to correctly link other GL_QUAD later

                           AddVertex( middleX , middleY );
                   }

                            AddVertex( v0.posX + dx2, v0.posY + dy2);
                            AddVertex( middleX , middleY );
           }
}

The arc calculation is not that hard. For this we need to have the center point, the start and end point. The middleX and middleY are used as an additional point to connect quad with.

We also need to find the start angle from where to start iteration and the end angle when to end.

Each iterations adds additional 2 vertexes. If you look closely for the iteration code, you would see that it generates minimum 4 vertexes. The first 2 vertexes are actually at the same point, they start the cap, then there are iteration vertexes and at the end 2 more for opening the next 2 vertexes

The order of drawing for 3 iterations is shown next. This is for the start cap with values:

CalculateRound( v0 ,
                              dx1, -dy1 ,
                              -dx1, dy1 ,
                              v0.posX + dx1 ,
                              v0.posY - dy1 ,
                              true );

Initial state:

1. First 2 vertexes and iteration 0

2. Iteration 1

3. Iteration 2

4. And now the end 2 vertexes are calculated

This is probably all that is required for rendering line cap styles.

Line rendering Join calculation

noreply@blogger.com (Dmitri Kuznetsov) — Wed, 07 Nov 2007 19:31:00 +0000

For the past few weeks, I have been working on the new line join rendering system.

This was required for the GUI system, because right now it is using only the most basic method, with huge noticeable cracks between line. I was also always wondering how it would be possible to make this line rendering happen. I haven't found allot of sources. There is only one source I used mainly for this. It is AntiGrain project. This is really awesome rendering library that features vast number of different shapes. I used the join rendering system from there:

Math Stroke.H
VCGen stroke.cpp
VCgen stroke.H
Agg Math.h

It is GPL project so source code learning is a must.

I haven't figured out exactly how the rendering in the AGG works, but I managed to get a few pointers and a few handy functions, that I am using in my own implementation right now.

Ok, first let's take the simple path of lines that are connected with each other:

There are 9 lines each connected with different angle. Let's imagine the line size is increased. How the line would look like.

The current approach I am using right now, would produce something like that:

This is what I call "None" join style, because the vertices aren't connected to each other.

How it was calculated ?

Well it is done in specific order:

1. Line Start Cap calculation
2. Join vertex calculation n1
3. ...
4. Join vertex calculation n1 + joinNum
5. Line End Cap calculation

There is also different cap styles, for now I would only use the default none. Which creates 2 vertices for the start and end cap.

For this specific line example the vertices would be calculated in this order:
1. Cap (2) - none cap
2. A+B (4)
3. B+C (4)
4. C+D (4)
5. D+E (4)
6. E+F (4)
7. F+G (4)
8. G+H (4)
9. H+I (4)
10. Cap (2) - none cap

There is total of 36 vertices required.

Here is how the code would look for this:

//calculate the data
void Calculate()
{
     //fully clear the rendering array
     _renderVertex.Cleanup();

     //START THE CAP

    //atleast 2 points required
    if( _vertexes.GetLength() < 2 )
   {
       return;
    }

   //GENERATE START CAP
   CalculateCap( _vertexes[0] , _vertexes[1] , true );

   for(int i = 1; i < _vertexes.GetLength() - 1; i++)
  {
        //CALCULATE JOINS
        CalculateJoin( _vertexes[ i - 1] ,
                                  _vertexes[ i + 0] ,
                                  _vertexes[ i + 1] );
  }

//GENERATE END CAP
CalculateCap( _vertexes[ _vertexes.GetLength() - 1] , _vertexes[ _vertexes.GetLength() - 2] , false );

}

The Join calculation itself, only needs to do few things. Calculate the distance between points is the first thing to do:

float len1 = CalculateDistance( v0 , v1 );
float len2 = CalculateDistance( v1 , v2 );

Now if we have the distance we can calculate the rotated angle, like this:

float dx1 = _size * (v1.posY - v0.posY) / len1;
float dy1 = _size * (v1.posX - v0.posX) / len1;
float dx2 = _size * (v2.posY - v1.posY) / len2;
float dy2 = _size * (v2.posX - v1.posX) / len2;

Note the _size here is the width of the line.

After that we need to calculate only the line points relation. They are either inner or outer join:

This can be done by calculate something like cross product. I have taken this from AGG:

float cp = CrossProduct2D( v0.posX, v0.posY, v1.posX, v1.posY, v2.posX, v2.posY );

float CrossProduct2D(
                                       const float& ax, const float& ay, //1 LINE
                                       const float& bx, const float& by, //2 LINE
                                       const float& cx, const float& cy ) //3 LINE
{
return (cx - bx) * (by - ay) - (cy - by) * (bx - ax);
}

And now we can calculate the vertices itself, depending on the join style:

if(cp != 0 && (cp > 0) == (_size > 0))
{

     // INNER JOIN
     //just 2 vertices for end
     AddVertex( v1.posX + dx1, v1.posY - dy1); //1
     AddVertex( v1.posX - dx1, v1.posY + dy1); //2

     //and 2 vertices for start of another line
     AddVertex( v1.posX + dx2, v1.posY - dy2); //3
     AddVertex( v1.posX - dx2, v1.posY + dy2); //4
}
else
{
     // OUTER JOIN
     //just 2 vertices for the end of first line
     AddVertex( v1.posX + dx1, v1.posY - dy1); //1
     AddVertex( v1.posX - dx1, v1.posY + dy1); //2

     //and 2 vertices for start of another line
     AddVertex( v1.posX + dx2, v1.posY - dy2); //3
     AddVertex( v1.posX - dx2, v1.posY + dy2); //4
}

The first 2 vertices close to the previous quad and the next 2 opens the new one.

This would continue this way untill the end cap is reached, which closes the quad. It is important to properly close the quads. Atleast with my video drivers it caused some really dangerous issues, when the computer screen started to flicker or it crashed and restarted. So additional caution is required.

And here is how it looks when it is done:

So far for the most simple way :). I think I would also explain later how the more advanced ways of rendering line joins can be done.

Game States in GE2

noreply@blogger.com (Dmitri Kuznetsov) — Fri, 21 Sep 2007 18:07:00 +0000

This time I would like to explain a little about the game state system used in Galactic Engine 2. It is working well right now, however wasn't been tested in fairly complicated states so it may contain some bugs.

Game states are used by the game developer to write the logic for the engine to use.
There can be many game states  however only one is active. The user can decide which state he
wants to use and when. The game states system for the GE2 was inspired by the OGRE implementation and has similar logic behind it.

In the GE2 GameState is base abstract class. It receives the events from the engine or input system. The user can the decide what he wants to do with the received data.

Here are some functions that base abstract GameState class has:

void OnConstruct();
void OnDeConstruct();

//called when entering this state or leaving it
void OnEntry();
void OnExit();

//draws opengl stuff
void OnDraw();

//updates game logic
void OnUpdate();

//Keyboard
void OnKeyDown ( const GE2_Key &key );
void OnKeyUp ( const GE2_Key &key);

//Mouse
void OnMoseMove (float &x, float &y, float &deltax, float &deltay);
void OnMoseDown (float &x, float &y, Uint8& mouseButton);
void OnMoseUp (float &x, float &y, Uint8& mouseButton);

void OnQuit();

When user wants to use GameState he needs to inherit the base GameState class
and make his own, like this:

class MyGameState : public GameState

and override the function that he wants to use. For example if I want to draw a simple OpenGL drawing. I need to do this:

void MyGameState::OnDraw()
{
   //Drawing Code here
}

and if I want to get a keyboard event then something like this:

void MyGameState::OnKeyDown( const GE2_Key &key )
{
    if( key == input.keys.F1 )
    {
           //Change to Full Screen
           video.SetFullScreen( !video.IsFullScreen() );
    }
}

Now when the game state is defined all is needed is to pass it to the engine. This
is required for any application of GE2. For example:

void gameStart()
{
     //create my own game state
     MyGameState myState;

     stateManager.Start( &myState );
}

int main( int argc, char* argv[] )
{
    //initiate engine through this function
    global.startEngine( gameStart );

    return 0;
}

The gameStart() is required as separate function so the engine can check for memory leaks after the gameState ends, and also catch any exception automatically.

Another thing game states are used for is the switching between states. Unfortunately I haven't tried this feature thoroughly , so it may cause some problems later, but the logic behind is really similar with OGRE. To switch to another state the user needs to call:

//pushes new state on the stack and activates it
stateManager.PushState( &myState );

//removes the last state from the stack and deactivates it
MyGameState *myState = stateManager.PopStat();

When the state is put on the stack the first time then OnConstruct() is called when it is removed then OnDeConstruct() is used. These functions are called only once so it is safe here to initialise all the variables or destruct them.

The OnEntry() and OnExit() are used when the states are switched between.

That's probably all there is.

Gradient calculation explained

noreply@blogger.com (Dmitri Kuznetsov) — Mon, 03 Sep 2007 21:35:00 +0000

In my previous post I have described how the gradient helped to solve few issues when creating skins for the GUI system. This time I would like to explain how the gradient is calculated.

Previous generation GUI system was really primitive when it comes to drawing shapes. The biggest problem was probably calculating the color gradients. Because the shapes were created by raw GL_POLYGON data, each point parameters should be specified. This means for each point I had to write its UV coordinates, color value and position. Calculating the color was one of the most problematical parts of this process.

Let’s for example say I have a simple rectangle with 4 points.

Now If I wanted to make a good looking gradient color, I had to manually calculate each point. For such simple rectangle this is not hard.

For example let's pick the gradient top color RED=RGBA{1.0,0.0,0.0,1.0} and bottom with 0.0 alpha RED={1.0,0.0,0.0,0.0}

I can easily calculate the 4 points of the shape:

Point1 = RGBA{1.0,0.0,0.0,1.0}

Point2 = RGBA{1.0,0.0,0.0,1.0}

Point3 = RGBA{1.0,0.0,0.0,0.0}

Point4 = RGBA{1.0,0.0,0.0,0.0}

The result is something like this:

Usually however more complex shapes are used to define appearance of the GUI widgets. Take a simple rectangle with an arc on one of the edges. This makes calculation difficult especially when some day you would like to change the vertical gradient color to horizontal or even to linear gradient with angular rotation. Calculating colors now is really the job you would want to do the least.

The new GUI system tries to solve this problem, by calculating the colors automatically. Because the drawing of shapes is abstracted (user is using lines, circles, rectangles not the GL_POLYGON points directly) it is possible for the GUI system to calculate the points.

The only thing that user needs to define is the initial 2 gradient colors (start, end) and gradient type or angular rotation. The GUI system would do everything else.

I would like to describe this in more detail, how the vertex colors are calculated.

I am using 2 basic points for this. These points hold the initial color values and also the position relative to each other. This makes it possible to create different gradient widths and heights.

The downside is that because we are dealing with vertex points we loose some color values, depending on the number of total vertexes. To better illustrate this imagine the circular gradient that is applied to simple 4 vertex rectangle. Because there are only 4 points it is not possible to describe the transition between them the same way as per pixel calculated image. The only way to improve this is to increase vertex size on the sides and with the shape itself. Another way is to apply texture . In the new GUI system however I decided not to use spherical gradient calculation because of these issues.

So right now I have only 3 gradient types – vertical , horizontal and angular.

The Vertical gradient type is one of the most simplest.

Each shape is created from line. Each line has 2 points. Basically the function loops and calculates color for each point.

Before starting to calculate, we need to get 2 base gradient points – the most top left and bottom right points of the shape.
The position of these points is relative to the maximum size of the shape so I use the shape left,top,width,height values for this.

//here are positions of the gradient points
RenderVertex gradientPos1 = GetVertexPosition( left , top , width , height , gradientPoint1 );
RenderVertex gradientPos2 = GetVertexPosition( left , top , width , height , gradientPoint2 );

As a result I get absolute position x,y on the screen of each point

When I have these 2 points I can find the distance between them in absolute coordinates:

//total horizontal distance between gradient points
distv = (gradientPos2.Y - gradientPos1.Y) ;

//ignore the sign value just incase
distv = fabs( distv );

And when I got this, I can calculate the relative distance between the first top left points and the current point I am calculating:

//now find the position of the point between them
if( distv == 0.0f )
{
posv = 0.0f;
}
else
{
posv = (guiPoint.Y - gradientPos1.Y ) / distv;
}

Now when I have this posv I can apply it and find the result color interpolation:

//calculate the color value now with simple interpolation
result.R = gradColor1.R * (1.0f - posv) + gradColor2.R * posv;
result.G = gradColor1.G * (1.0f - posv) + gradColor2.G * posv;
result.B = gradColor1.B * (1.0f - posv) + gradColor2.B * posv;
result.A = gradColor1.A * (1.0f - posv) + gradColor2.A * posv;

The same way it works with the horizontal gradient type. This time however instead of using Height we use Width of the shape, but the process itself is exactly the same.

A more complicated is the angular gradient calculation. For this we need additional parameter – angle in degrees. The user specifies the angle within range 0...360.

We start the same way when calculatin vertical or horizontal gradient, but calculate both distances:

//Find horizontal position first

//total horizontal distance between gradient points
disth = (gradientPos2.X - gradientPos1.X) ;

//ignore the sign value just incase
disth = fabs( disth );

//now find the position of the point between gradient points
if( disth == 0.0f )
{
posh = 0.0f;
}
else
{
posh = (guiPoint.X - gradientPos1.X ) / disth;
}

//Now find vertical position

//total vertical distance between gradient points
distv = (gradientPos2.Y - gradientPos1.Y) ;

//ignore the sign value just incase
distv = fabs( distv );

//now find the position of the point between gradient points
if( distv == 0.0f )
{
posv = 0.0f;
}
else
{
posv = (guiPoint.Y - gradientPos1.Y ) / distv;
}

The only thing left to do, is to calculate the rotated distances:

//make the angle within requested range
fangle = fabs(angle);

if( fangle > 360.0f)
{
fangle = 0.0f;
}

//the gltriangle size is 2Pi
fangle = angle * 2;

// 0 .. 90
if( (fangle >= 0)&&(fangle < 180)
//now rotate the point
posRot = posh * trig.GLTriangle( fangle + 180 ) + posv * trig.GLTriangle( fangle );
}
else
// 90 .. 180
if( (fangle >= 180)&&(fangle < 360)
//now rotate the point
posRot = (1.0f - posh) * trig.GLTriangle( fangle + 180 ) + posv * trig.GLTriangle( fangle );
}
else
// 180 .. 270
if( (fangle >= 360)&&(fangle < 540)
//now rotate the point
posRot = (1.0f - posh) * trig.GLTriangle( fangle + 180 ) + (1.0f - posv) * trig.GLTriangle( fangle );
}
else
// 270 .. 0
if( (fangle >= 540) )
{
//now rotate the point
posRot = posh * trig.GLTriangle( fangle + 180 ) + (1.0f - posv) * trig.GLTriangle( fangle );
}

The trig.GLTriangle is a precalculated table of cos and sin values. I also change the sign depending on what angle is currently selected.

With the posRot value I can get the required color value:

result.R = gradColor1.R * (1.0f - posRot) + gradColor2.R * posRot;
result.G = gradColor1.G * (1.0f - posRot) + gradColor2.G * posRot;
result.B = gradColor1.B * (1.0f - posRot) + gradColor2.B * posRot;
result.A = gradColor1.A * (1.0f - posRot) + gradColor2.A * posRot;

That's it.

This is only a small feature of the new GUI system, however it makes a big difference when creating GUI skins, because it takes significiant portion of the work from the designer.

Color themes and gradient power.

noreply@blogger.com (Dmitri Kuznetsov) — Mon, 20 Aug 2007 20:33:00 +0000

Hey!

This time I would like to talk how the shapes are getting drawn using the list of color themes.

The new GUI system includes a color theme support. Generally you define a unique color for each element of the widget shape. All the unique colors are stored in one list. By making another list with the same color names but with different color values, it is possible to apply new color values to the GUI widgets without making changes within the widget itself.

I made a separate file which is part of the skin. By default it is called themes.cfg .
It holds different themes and each of them can hold different color values. Like this:

<theme>
            name = "default"
            <colors>
                    window_fill                         = RGBA{ 0.4 , 0.4 , 0.4 , 1.0 }
                   button_fill                             = RGBA{ 0.5 , 0.5 , 0.5 , 1.0 }
                   button_hover_start_fill    = RGBA{ 0.0 , 1.0 , 0.0 , 0.1 }
                   button_hover_end_fill       = RGBA{ 0.0 , 1.0 , 0.0 , 0.0 }
      </colors>
</theme>

<theme>
      name = "blue"
      <colors>
                    window_fill                       = RGBA{ 0.0 , 0.0 , 0.4 , 1.0 }
                    button_fill                          = RGBA{ 0.2 , 0.2 , 0.5 , 1.0 }
                    button_hover_start_fill = RGBA{ 0.0 , 0.0 , 1.0 , 0.1 }
                    button_hover_end_fill    = RGBA{ 0.0 , 0.0 , 1.0 , 0.0 }
      </colors>
</theme>

It is really easy and straightforward to change these values or add another theme.

The gradient effect is created using only 2 colors from the theme table.

As you can see on this picture there are 2 points. Generally they are used for defining the gradient and texture coordinate values. They are referenced in the strokes.cfg file:

<frame>
          gradient = "vertical"
          <point>
                theme = "button_hover_start_fill"
                uv = UV{ 0.0 , 0.0 }
          </point>
          <point>
                theme = "button_hover_end_fill"
                uv = UV{ 1.0 , 1.0 }
          </point>
</frame>

As you can see the shape is defined here using vertical gradient type.
The color values for each vertex are interpolated depending on the initial point color values and the vertex position relative to the point1 and point2.

There are also other different gradient types that can be used for defining shape appearance:

Solid - only point1 color is used:

Horizontal:

Linear - this is where it is possible to define the gradient angle = 0..360 degrees:

This is probably all there is to know about the gradient and colors in the new GUI system.

Finally an update !

noreply@blogger.com (Dmitri Kuznetsov) — Thu, 02 Aug 2007 21:04:00 +0000

It has been a while since I have updated this blog. Well the primary reason is, that I was working on the new GUI system and at that time there wasn't anything that could be shown.

But it is progressing and I can show a few early screenshots.

The old GUI systems worked fairly well, but had a few flaws. I tried to avoid these problems and add more functionality this time.

One of the major problem in the old GUI was the rendering system. The GUI skin was one big file. It included description of how to render each widget and for each different state. There were generally 4 states: normal , disabled , hover , clicked. Each state is drawn by GL_POLYGON and all the points should be specified directly with (Color,Texture coordinate,position on the 2d screen and anchor).

The new GUI however tries to minimize the amount of data that needs to be written. This is achieved by creating one stroke object that would later be used to draw different parts of many widgets, but it only needs to be defined once.

The widget shape is created from the list of these strokes. The stroke itself is made from many 2d primitive shapes like: line , rectangle , round rectangle , circle , ellipse , arc and bezier. The amount of the data that needs to be written to define a stroke is minimum.

Here is an example of the stroke created from 2 bezier curves:

Each bezier curve is defined by 4 points. The GUI also allows to change the quality of shapes.

The previous shape was created from 16 iterations this is created from 8:

Each shape except line and rectangle can have different quality versions.

One of the most important additions to the GUI rendering system is the material system. The GUI uses the same material system that is used in any other engine part.
This makes it possible to create all sorts of animation effects. The texture coordinates , gradient and alpha values are generated automatically:

One of the most annoying issues when making GUI systems, especially with OpenGL is the lack of good line drawing functionality. The standard line drawing implementation is really limited. Not only it doesn't guarantee some line widths to be available, but the width itself is related directly to pixel width. Which makes it looks different on different resolutions. The other problem is antialiasing of the line. It is widely supported by most graphic cards this day, however their implementation depends on the graphic card manufacturer driver version, and can produce different results.

The line drawing system that I am using here is created by two 4 vertex quads. Original drawing with one 4 vertex quad produced really noticeable jagged lines. However by adding additional quad and using blending, made it look really well, without almost any performance impact. It would also work on any OpenGL implementation and on any resolution the same correct way:

I would probably make some more posts soon, if I manage to get something new working :)

FreeType2 support added

noreply@blogger.com (Dmitri Kuznetsov) — Sun, 27 May 2007 22:40:00 +0000

The new improvement, that I have just finished is the FreeType2 library fonts.

I can now say that figuring the API wasn't so easy. The hardest part for me was the metrics system. There are so many things like widths, advances , dpi and so on, so it took me quite some time to just get an overall picture. One of the best sources for figuring everything out was this post by Brian Lawson it is well written and easy enough to follow.

The new fonts with freetype2 are really looking great, not only it produces much higher quality glyphs, but generally it takes less space then usual bitmap textures I used before. It is also possible to change font resolution on the fly or with config option.

Here are some sample images at different DPI values:

These values can be easily altered in the config here:

dpih = 100
dpiv = 100
name = "arial.ttf"

One of the nasty problems I had with FreeType was the lack of choices for building dynamical dllVC6 and I couldn't find any way to build a dll. Changing ftbuild.h didn't help. I solved this by using VC2005. It has an option that allows to changing the output type really easily.

The freetype2 is now included as part of Galactic Engine 2.

Stage6 divx high quality videos"

noreply@blogger.com (Dmitri Kuznetsov) — Fri, 18 May 2007 17:56:00 +0000

The Stage6.divx.com offers new video service. The primary feature is that there is practically no limit to video length or size so it is possible to upload and watch the highest quality videos !

The primary requirement is availability of special divx plugin and video converted to divx format. I recommend as minimum 1 MB/s download speed for watching.

Here is blazetris game-play video in original quality, the video size is about 20 MB and it was converted from .wmv file.

Direct Link

Revolution Is here !

noreply@blogger.com (Dmitri Kuznetsov) — Wed, 09 May 2007 17:11:00 +0000

Finally after some waiting time , the Cellfactor: revoltion is released !

You can freely download the full game here:

Cellfactor: revolution

Trailer:

Galactic Engine 2 Materials with BSP

noreply@blogger.com (Dmitri Kuznetsov) — Sun, 29 Apr 2007 14:59:00 +0000

For the past few weeks I have been working on the version of BSP map class that would be added to the GE2. Some things are already working but some require the physical engine.

Currently it is mostly compatible with Quake 3 shader system it allows to animate texture coordinates , colors , vertex deformation. One of the latest additions to the engine itself was the AnimatedTexture. This is the special type of texture that points to multiple textures and selects only one of them depending on the frequency of animation and the elapsed time. This is used to animate the torches of the map.

Here is the video:

Direct Link