News has arrived

We don't spend all the time at echo, but theres a few news from us:


ck works now on a collision-model, the first music track is created, new ship-types like a tender and frigates are currently at work and we have a basic-web interface for the online analytics.

We also rejected some concept ideas like real-time-models for this now. The solution is that every model becomes different light stage setups for each space sector setting.
Thats it folks, keep on reading!

making a concept...AI!

So, now i am constructing the AI for the game, so, what is to do? First, the AI can "see" the ships by calling someship->position();, and the own ships may be moved per "shipnumber command option", for exampe "001 N 000" to navigate the first ship to 0 degree. So the AI only has the same options as a human player, but it is faster!

So, how to make a strong AI? The AI-Ships have to kill the enemyships, hoho! What would I do? I would navigate the ships to several positions to attack the enemy by all sides, may be good, but the AI has to defend their own ships, too :S. Ah, it doesn't have to navigate _ALL_ ships to the enemy, if it has to defend something like a huge, heavy ship. So now it would be in the right position to attack, now should all ships attack one enemyship, or one enemyship for one AI-ship? Hm, I will have to invest more time in it..!

Ship physics

I implemented most of the ship's basic movement physics the other day. We have so-called definition files which specify the physical quantities of a given ship type, such as its mass, its size, its shape, the force of its engines and the torque the maneuvering jets apply for rotating a ship. Furthermore, we also specify the ship's maximum velocity and angular velocity. There is no physical law in classical mechanics which would limit the ships' velocity, but it we don't want them to travel too fast as a game element.

The goal now was to find a way to compute the ship's acceleration based on the forces without getting significantly faster than the specified maximum velocity. In other words, we need to modify Newton's law to take into account the maximum velocity of the ship. I spent some thought on how to modify this so that it has the properties we'd like, and this is what I came up with: In this formula, the minus sign is used if the dot product of F and v is positive, and the plus sign otherwise. In the case that the force goes into the same direction as the current velocity, the additional term will lower the total acceleration by a factor of v/vmax. Therefore, when v reached vmax, a will be zero and no additional acceleration is possible anymore. Also, when, for whatever reason, the ship gained a higher velocity than vmax, then the additional term slows it down again.

On the other side, if F points into the opposite direction of v, then we are actually deccelerating. The dot product is less than zero, so the plus sign is used. In this case, the original acceleration is increased by a factor of v/vmax. This makes decceleration from high velocities take shorter than accelerating to such a velocity. This might not be realistic, but it makes it easier to avoid collisions, so I think it's a good thing. If we didn't want this, then we could simply drop the additional term when deccelerating, and we would still have the velocity limit in place.

Another thing to note is that if the ship is travelling at maximum velocity, then changes its direction arout 90 degrees and accelerates into a direction which is perpendicular to the current one, then the dot product is zero and the second term vanishes. In that case, we allow the total velocity to become greater than vmax. This is not a problem though, because of three reasons:

1) As explained before, the ship will automatically slow down again when travelling faster than vmax.
2) To permanently travel faster than vmax, one would need to change the flight direction very often, taking a zigzag-like route. In that case however, one would be faster when travelling at vmax using the direct route anyway.
3) The effect is very small: If vmax is 20, and one turns at v=19.99, then the highest v will be v=20.05 before it gets smaller again.

For rotation, the same formula is used, with the force replaced by the torque (also specified in the definition file), the acceleration replaced by the angular acceleration, the mass replaced by the moment of inertia and the (maximum) velocity by the (maximum) angular velocity. As there is only one direction for rotation (namely around the Z axis) we don't even have the possibility of gaining more angular velocity than the maximum here.

SDL Bug wrt. mouse focus?

We have basically finished the GUI subsystem of the game. However, when writing the Code to handle the mouse pointer leaving the application window (for example, to remove the hovering state of a widget near the window border) I investigated a problem which I think is a bug in SDL.

When clicking into a different window, holding the mouse button pressed, moving the cursor into our SDL window and release the mouse button there, then we don't get an SDL_ACTIVEEVENT which reports gained mouse focus for the window. This is OK as long as the mouse button is pressed, since all mouse events are still delivered to the originating window then.

The problem with this is that when querying the application state via SDL_GetAppState, SDL still reports the window not having mouse focus until the mouse leaves and enters the window again. This confuses our code since there are some checks for the application having mouse focus before e.g. setting a button's state to be hovered by the mouse.

There is a quite easy workaround for the problem:

SDL_WM_GrabInput(SDL_GRAB_ON);
SDL_WM_GrabInput(SDL_GRAB_OFF);

This is executed whenever the mouse moves over our window or it is clicked and SDL reports that we don't have mouse focus. In this case we can be quite sure that the mouse actually is over our window, so the mouse grab does not warp the mouse cursor. However, this causes SDL to update the application's mouse focus state.

There is still a little issue with this: When the mouse button is released over a button, the the button is not shown hovered until the next mouse click or movement, since the application state is only rechecked on these two events. However, that's not a major problem, and we can live with it.

I am not yet sure whether there is the same problem on Windows, but I have tested it using GNOME with the Metacity window manager. Anyway, as a good net citizen I filed a proper bug report.

Composing images of multiple textures

For the curious: The game is developed with SDL using OpenGL for graphics output and will support all three major platforms: Windows, Linux and Mac OS X.

Yesterday, I wrote a class to load arbitrary-sized images into possibly multiple textures none of which is greater than 256*256. I don't know how restrictive modern graphics cards are in what texture sizes they accept, but this way I think we are safe to also support older cards. Everything went quite well, until I tried to render a rotated image composed of multiple textures. The result was something like what can be seen on the first screenshot. Somehow there were visible lines at the texture boundaries.

It took me a while to find out what happend here. The problem was that, when rendering a textured primitive with OpenGL, it repeats the same texture when specifying texture coordinates greater than one. Now, when drawing a rotated quad, OpenGL seems to have accessed such a texture coordinate for interpolation, even though I never gave a number greater than 1.0 to glTexCoord.

Once I understood the problem, it was easy to fix. Simply tell OpenGL not to repeat the texture, but clamp texture coordinates to the range [0,1]. This is done using glTexParameteri, by setting the GL_TEXTURE_WRAP_S and GL_TEXTURE_WRAP_T parameters to GL_CLAMP.

Another solution seems to be to set it to GL_CLAMP_TO_EDGE_EXT, but this requires the GL_EXT_texture_edge_clamp extension, and GL_CLAMP works well enough already.