OpenTK instead of Tao

* OpenTK has linear algebra types which integrate nicely with the OpenGL API (vector, matrix, quaternion)
* OpenTK allows usage of .NET Color (a minor thing but sweet anyway)
* OpenTK feels a lot more .NETish than Tao
* OpenTK has some enum-separation allowing easier-to-write code (via IntelliSense), compared to Tao's "one enum to rule them all". (last time I checked at least - which was two years ago but anyway ...)

Absolutely.

Since you are aiming for 2d, take a look at AgateLib. It uses OpenTK and is easier/simpler than raw OpenGL.

I'm using OpenTK for Scrolling Game Development Kit 2, converted from Managed DirectX, and it runs significantly faster. It can also handle more sprites faster than the original Scrolling Game development Kit based on DirectX 5, which I assume is partly due to the fact sprite behavior is based on compiled rather than interpreted code now, thanks to .NET's ability to compile code at runtime. I haven't tested under mono as much, but I have run games compiled by both Visual Studio in Windows and Mono in Linux, and the performance of the projects compiled by Mono seems about the same; I just don't know how hard I could push the Mono/Linux version before I start seeing performance degradation. With Visual Studio, I believe I got at least a hundred sprites before I noticed anything (it's been a while since I ran the test). And I've done multiple layers of parallax scrolling tiles without any problem, of course (tiles are easier on the CPU than sprites).

I have to disagree slightly. The mono run time consistently under performs the .NET run time in many areas. They have made improvements in mono 2.2 targeted at improving performance, but quite frankly, Microsoft has out spent them by orders of magnitude in optimizing the .NET run time.

Having said this, I feel that the mono run time's performance is without question good enough for many projects. I think the performance variation you will experience in the underlying hardware will have far more impact than the difference between the run times.

The .Net C# and jit tend to create better code than the ones used in Mono. From benchmarks posted to the Mono mailing lists, the Mono BCL is slower more often than not, which is understandable if you take the platform abstraction layers into account.

However, there are two things that make Mono equally (or more) suitable to .Net for games: faster pinvokes and Mono.Simd. Most games make heavy use of unmanaged APIs and numeric computations and (bugs aside) Mono shines on these.

k thx for support. Another question came up to me yesterday. I read the short guide on the site and i saw that because of compability time from .net/mono to c there shouldn't be more than 600 GL.X calls for every frame.
My game has a tile terrain which means i have about 600 quads (basically 44x44) building up just my terrain (i can upload a image if you want to tomorrow). I'm having serious problem with performance because the game seems to eat all power of the CPU. Is there a workaround that i use something like a vertex buffer or indexbuffer like in DirectX and not to call more than 600 times my render statement GL.Begin(BeginContex.Quads); .... GL.End() ?

thx rich

The 600 calls is not a hard limit, just a rule of thumb. You will get a nice speed boost if you switch to Vertex Buffer Objects, but I don't think the GL.Begin() - GL.End() is the cause of the high CPU usage here (each OpenGL call has an additional overhead in the order of 8-15ns compared to C code, so it's not that bad).

Are you using the debug or the release version of OpenTK? The debug version hits the cpu hard: it calls GL.GetError() automatically, which causes the OpenGL command-queue to flush.

It's also normal to see 100% CPU usage if you don't enable vsync, because then you are drawing as fast as possible. Enable vsync and CPU usage should drop significantly.

You'll have to use the index buffer to connect the 4 vertices so that they form two triangles. Assuming the vertices are like this:

34
12

You can connect them like this:

1, 2, 3
3, 2, 4

Make sure that you preserve the normal between the two triangles (123 and 324 have normals that face the same way. 123 and 342 have normals that face in opposite ways).

If performance is adequate, I wouldn't worry about using VBOs just yet. When building a 2d game, you'll probably want to keep hardware requirements as low as possible, which usually translates in an OpenGL 1.1 code path (i.e. immediate-mode and display lists). OpenGL 1.1 won't go away any time soon and even plain old immediate-mode can be fast enough for old-school 2d games with a little care.

If possible, just try to decouple the data structures for your map (tiles, layers, regions) from their rendering method. This way you'll be able to add a VBO render path later on, if you decide it's necessary.

I finally gave VBOs a try and the performance is much more adequat.

But still some questions :) :
I have about 600 "maptiles" every frame.... (see picture above from previous post).
Now with the VBO i have to bind for every tile a the texture id.
Isn't there faster way? Can't i just store the texture ids for each quad in GL and
destroy this loop with mean about ~1200 GL calls?

for (int i=0;i < 600;i++)
{
  Textures.BindTexture(todraw[i]); //todraw[i] is the texture id i want to bind
  GL.DrawArrays(BeginMode.Quads,i*4,4); //here i draw one of the 600 quads
}

EDIT:
Another question came up to me. I read about the PBO (Pixel Buffer Object). I didn't
really understand why to use it. I can use it to store texture via the DMA (Direct Memory Access).
This procedure relieves the CPU usage.
But when i bind my texture the bytes are already stored in GL? why should i use the PBO?

thx rich

Hey there,

I'm still having some problems with performance (or i think i can code it much faster).
First look at picture in attachments pls!

What about if i make for each 8x8 block on the map a drawing list and move arround with GL.Translate(x,y,z); ? would that be faster?
what you think

thx rich

Yes, display lists should be faster in this case. The best ways to improve performance are to:

1. Draw more stuff with less calls. Modern hardware performs best when you draw at least (IIRC) 4096 vertices per draw call - anything less and it starts to stall.
2. Minimize state changes. Sorting everything by shader / texture will be much faster than binding a different shader / texture every time you issue a draw call.

Display lists help in both regards: you draw more stuff in one call and they driver may be able to minimize state changes.

However, before you go in and make any large changes, make sure you are benchmarking a release build (this includes OpenTK) ran outside of the IDE. It is a good idea to try a profiler, too - you wouldn't want to optimize something that isn't a bottleneck!

If you keep a different texture per tile, you can improve performance a lot by drawing all grass tiles first, all water tiles next, etc.

Instead of this (pseudo-code):

for (int y = 0; y < map.Height; y++)
{
    for (int x = 0; x < map.Width; x++)
    {
        // Bind texture
        // Draw tile map[x, y]
    }
}

you can do this:

// When you load your map, sort the tiles by texture:
Dictionary<Texture, List<Point>> sorted_tiles = new Dictionary<Texture, List<Point>>();
for (int y = 0; y < map.Height; y++)
{
    for (int x = 0; x < map.Width; x++)
    {
        if (!sorted_tiles.Contains(map[x, y].Texture))
            sorted_tiles.Add(map[x, y].Texture, new List<Point>());
 
       sorted_tiles[map[x, y].Texture].Add(new Point(x, y));
    }
}
 
// In your draw function
foreach (var texture in sorted_tiles.Keys)
{
    // Bind texture, then
    foreach (var point in sorted_tiles[texture])
    {
        // Draw tile map[point.X, point.Y]
    }
}

This way you reduce the number of times you need to call GL.BindTexture, which can give a nice performance boost. How nice? Try commenting out your BindTexture calls and see if your fps improve.

This shouldn't happen. Are you, by any chance, drawing to the front buffer? (This is no longer supported in OpenGL).

As long as you don't call GL.DrawBuffer(DrawBufferMode.Front) and call SwapBuffers at the end of the RenderFrame event, there shouldn't be any flickering at all.

What does the flickering look like? Does the whole screen flash between black and color? Only the tiles? Can you capture it in a screenshot?

Finally i found the error:

I do not update the mapdata every frame. So if i set the todraw[i] = -1; -> the nextframe do not do anything and just clears the map...

This works fine:

List<int> list = new List<int>();
foreach (int i in todraw)
{
	if (!list.Contains(i))
	list.Add(i);
}
 
foreach (int i in list)
{
	Textures.BindTexture(i);
	for (int j=0;j < 600;j++)
	{
		if (i == todraw[j])
		{	
			GL.DrawArrays(BeginMode.Quads,j*4,4);
		}
	}
}