What?

fantastic...!!

all I can say is.. stay tuned

dot product, yo

Just try to aim for simplicity. I say just start off getting your classic game-loop going

Code:

while(true)
{
handleInput();
update();
render();
}

And then try to build your engine on that basic structure.

I agree with Gregg that if you are going OOP approach, just try to keep things as flat as possible. You may even actually want to invest time in binding a scripting language, like Lua, into your engine as it will help immensely with your iteration timing.

you can create skeleton animations in maya. The process of animation begins with rigging the model and attaching bone weights to vertices. In your shader, you pass in your bone transform matrices and you do "vertex skinning". There are tons of articles online that show how to do this..

sunday evening speed coding. made in two hours using html5 canvas and javascript

http://illogictree.com/games/obsidian/

Good to hear. Whats your development environment? Framework, SDK?

Visual Studio 2008 is my IDE of choice. My game uses an engine that I've developed from scratch, but uses SDL for window management. Gamemonkey script is used for, well, scripting. Fmod for sound...

Hi folks!

The game is still under development. For me, work has just been extremely intense the past few weeks as I had almost no free time to do proper development. But rest assured that this game's progress will pick up once things free up a little...

As an example, Super Time Force is all software blits.

Do you have a citation or reference for that? I am curious since it seems quite weird that they would use software blits on Xbox 360 when Xbox 360's ATI is a decent GPU. Why would they not use hardware?

Well, when using straight OpenGL on Windows, Mac, and Linux, the window creation and initialization must be done in the native APIs, which each have their own way of doing things. Once you get beyond that initial setup, your are absolutely right; it is beautifully standardized across all 3 platforms(but then you have to deal with things like input,  threading, file i/o, etc. which all differ per platform)

Using SDL with OpenGL ES subset, cross platform ports were super easy. I assume you are writing it from scratch.

I think the hardest thing about using straight OpenGL is the setup and configuration for each platform.

Why are you doing so much OpenGL per platform? The API is quite standardized between PC, MAC and Linux. And if you are coding with the OpenGL ES subset it mind, it is super easy to port. Of course, if you are using specific vendor extensions, it becomes a pain.

Here is my setup code for reference:

Code:

int result = SDL_Init( SDL_INIT_VIDEO );
assert( result == 0 );
SDL_WM_SetCaption( reader.GetCStr("Window","Title"), 0 );

// monitor info
char buffer[64];
const SDL_VideoInfo* info = SDL_GetVideoInfo();
assert(info);
m_dimen.x = info->current_w;
m_dimen.y = info->current_h;
SDL_VideoDriverName( buffer, sizeof(buffer));

printf( "%dx%d @ %d hz. Driver: %s\n", m_dimen.x, m_dimen.y, fps, buffer );

// Window surface format
Uint32 flags = SDL_OPENGL | SDL_DOUBLEBUF | SDL_HWSURFACE ;
if ( fullScreen ) flags |= SDL_FULLSCREEN;
result = SDL_GL_SetAttribute( SDL_GL_DEPTH_SIZE, 16 );
assert( result == 0 );

m_screen = SDL_SetVideoMode( m_dimen.x, m_dimen.y, 0, flags );
glViewport( 0, 0, m_dimen.x, m_dimen.y );

Have you checked if your computer has a GPU? Maybe it is old enough that it might not. If that is the case, perhaps your computer is resorting to software rasterizing to simulate compatibility with OpenGL behaviors.

If you are using OpenGL, and you want to mirror a texture, you can just flip the texture coordinates during the draw call. It is trivial, and does not require any more processing or memory, and flipping you get basically for free on the GPU.

For example, if you want to mirror horizontally, you would just flip your X uv coordinates:

Code:

(0,0)                  (1,0)
  ----------------------
  |                    |
  |                    |
  |                    |
  |                    |
  |                    |
  ----------------------
(0,1)                  (1,1)

to:

Code:

(1,0)                  (0,0)
  ----------------------
  |                    |
  |                    |
  |                    |
  |                    |
  |                    |
  ----------------------
(1,1)                  (0,1)

your code would look like this (pseudocode):

Code:

// normally
if ( normal )
{
glBegin(GL_QUADS);

glVertex( topLeft );
glTexCoord(topLeft);

glVertex( topRight );
glTexCoord( topRight );

glVertex( bottomRight );
glTexCoord( bottomRight );

glVertex( bottomLeft );
glTexCoord( bottomLeft );

glEnd();
}

else // flipped horizontally
{
glBegin(GL_QUADS);

glVertex( topLeft );
glTexCoord(topRight);

glVertex( topRight );
glTexCoord( topLeft );

glVertex( bottomRight );
glTexCoord( bottomLeft );

glVertex( bottomLeft );
glTexCoord( bottomRight );

glEnd();
}

of course, you can abstract that code a bit so you don't have to write so many lines of code  each time you want a flip.


If you are using SDL, you are out of luck. Don't use it

musicForProgramming();

I refuse to continue in this debate.

That's the spirit!


But seriously, I just hope the op has more info now to make an informed decision and  to not do something silly like vote for Mitt Romney or use software rasterizers in future engines.

That is not to say that software rasterization is completely useless. You can use software rasterization for 3d occlusion culling. Games such as Killzone 3 have used such techniques successfully to cull objects in the scene. You can check their presentation online.

Cheers