lubos's picture

2D Graphics Engine

Hello, so I'm slowly progressing with my OpenTK, OpenGL and whole C# adventure. I'm taking opportunity to start development diary so here I am :) I have started writing a small engine with OpenTK, that handles ONLY 2D rendering, but completely removes need to use any OpenGL function, while cooperating with other parts of OpenTK. I haven't decided for the name yet but that's not important I think.

The goal is to build a small, easy to use engine capable of building small 2D games together with OpenTK.

Engine doesn't use any scene-graph, you must draw each image every frame manually. I think this way it's cleaner and faster when working with 2D graphics. However, Gui uses a GuiManager which will draw all widgets at once.
To use engine, engine code is linked directly with game code. If you don't need some parts of engine you just don't link them.

The colors are passed as unsigned bytes (0-255).
The positions and sizes are passed as integers, meaning the x and y position of pixel on screen, where 0,0 is in the top left part of the screen.

Features implemented:
- Images loading/drawing (rotating, scaling, blending, drawing part of image)
- Animations(Sprite) (frames rendered from one texture, same options as image)
- Particle systems (uses single VBO, Point sprites)
- Custom VBOs

Features planned:
- Basic Gui(first widgets done)
- Complete documentation/examples(some examples done)
- Shaders

Free Image Hosting at www.ImageShack.usFree Image Hosting at www.ImageShack.usFree Image Hosting at www.ImageShack.usFree Image Hosting at www.ImageShack.usFree Image Hosting at

Mines.zip464.13 KB
PointSprites.zip467.25 KB
Game.zip476.52 KB
Engine.zip23.6 KB


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Inertia's picture

While developing, functionality is much more important than speed optimizations. However it's always nice to keep the number of GL. calls as low as possible (around 300-500 calls per frame was said to be realistic in a whitepaper), so grouping all particles which share the same texture is a good idea. Or use a bigger texture which holds all 4 numbers (refering to your "letter" particle system here) so you can draw the whole particle system with the same texture bound, only changing uv coordinates.

The orange book takes a whole different approach, using a static array for the particle system and calculating the animation in GLSL.

I was just curious how you draw them, because it seems using point sprites or the geometry shader to create the quads for you is quite popular at, because it only requires 1 vertex per particle instead of 4. I've tried point sprites so far, but they seem to have the limitation that you cannot rotate the quad they create, and I was kinda hoping you figured out how to do that ;) (Geometry shaders require DX 10 hardware so couldn't toy around with that yet.)

lubos's picture

So I'm going to group particle systems into one array ;) I was also looking at VBOs, but since it needs openGL 1.5 I will implement them later as optional feature. Regarding "letter" particle system, it already uses one bigger texture, the particle just holds frame number, which is used to calculate texture coordinates.

I know nothing about shader programming, but will add it to roadmap. i will check point sprites also, looks like great idea!

lubos's picture

Just a small update. A more than week passed and I have done so little. Particle systems already uses vertex arrays, still some problems but I will hopefully fix them this weekend, as well have a look at point sprites :)

the Fiddler's picture

Love the flaming text, this must look awesome in movement! :)

objarni's picture

Are you using "classic vertex arrays" or VBOs?

The classic VAs of OpenGL is not recommended in OpenTK, if you are going to scale up and need more performance. Go for display lists or VBOs instead.

lubos's picture

I'm using "classic VAs". I read that VBOs need OpenGL 1.5 so I decided not to use it(or, not to use it as main method) as this is just 2D engine for 2D games which should run even on older machines. Yeah, the particle system with 20k paticles runs at only about 8 fps currently, but that much particles will never be used in game.
Why its not recommended in OpenTK? Its because of c#?
About display lists, how should I do that? The only way I see is to rebuild all lists everytime when particles get moved.
Thanks for suggestions :)

the Fiddler's picture

When using VAs, it is your responsibility to keep the data pointers intact for as long as you are using the VA. This is no simple task in an environment with a compacting GC like .Net - unless you are taking precautions, your app will start displaying garbage or crash after a variable period of time (it depends on the runtime, the number of cores in your machine and the memory pressure).

VBOs do not suffer from this issue. Geforce FX and higher have 1.5 compliant drivers, so you can just go ahead and use VBOs. You'll need to work a little more in order to support older cars: you could use the ARB VBO extensions in GL.Arb, and fall back to display lists / immediate mode if these features are not supported.

Edit: Check this pdf for VBO support on older cards:

It looks like VBOs are supported from Riva TNT 1 and up (should be old enough for ya!), in one form or another.

objarni's picture

Fiddler: maybe my "not recommended" is too weak? you also have to use "pinning" (or what it is called) to actually make the program semantically correct/stable to use VAs in OpenTK, right?

But when you do use VAs (with pinning), it is really slow, right?

It would be really nice if IntelliSense told users that DrawArrays etc. is not the recommended way ( unless it's via VBO's ). This will bite lots of beginners of OpenTK since VAs are immensely popular, since it's really fast and easy to use in C/C++.

the Fiddler's picture

Yeah, it's an understatement. VAs are pretty much forbidden in .Net, for the very reason you mentioned (they require long-term pinning which will kill GC performance).

I'm working on a system that will allow us to add comments to specific OpenGL functions. It requires some rather extensive modifications to the generator however, and I don't have the time for that right now. I'll add a comment by hand for the time being, warning users on the pitfalls.

lubos's picture

Update! I finally managed to sit down and code :) It's 1:13 AM and drawing is now done using VBOs :P As a next step I decided to clean code a bit before I start with point-sprites.