viper - next steps

So I've made some decent progress on viper. I think now would be a great time to justify yet another game development library, seeing as there is already xna, openTK, Tao.NET, Unity, SFML, and several others.

Maybe the biggest one is that they aren't all that friendly to use. I'm not saying that they are difficult. DirectX is difficult, OpenGL + Extensions under win32 is difficult. I'm just saying that they aren't friendly. 

OpenTK and XNA both require that the gut class of your program inherit from a class in their assembly. I'm not saying that inheritance is a bad thing, it's actually quite useful, but it forces you to adopt their way of thinking, and at least in the case of XNA, for a beginner, it's not always clear what to override.

Viper provides a more explicit interface. In viper, you create the window, not inherit from an abstract window or game class. You explicitly define it.

Another thing that viper provides is thread safety. Most of the time, you aren't going to want your rendering code in a secondary thread anyways, but you might want your resource loading to happen in the background. With OpenGL, and much of Direct3D, all the calls are required to be made on the same thread in which the context was created.

When the pitviper window is initialized, the first thing it does is create it's own UI Thread. That thread creates the output window and does message processing from two message queues; the windows system message queue, and an internal message queue.

The internal message queue is a queue of Action<> delegates. When you call a method like myGameWindow.Clear(255,255,255) what it's really doing is queuing up a new action delegate containing the command, and placing it into the private queue. The UI Thread will then dequeue the call, and execute it. This is how thread safety is achieved.

This also has the unintended side effect of potentially making your code faster. If you are in the habit of doing a lot of calculations in your rendering code, on the same thread, you are doing that math, then the rendering, then more logic, then more rendering. By offloading the rendering to a dedicated thread you can go from this

logic  |  render   |   logic   | render  |

to this

logic 1 |   logic 2  | logic 3  | logic 4  |  logic 5  |

        |  render 1  | render 2 | render 3 |  render 4 | render 5

Granted, you do have the overhead of a context switch, and you won't see a huge boost on hardware with only a single thread, but the goal here is not ultimate performance, but rather simplicity. If we can get a small performance boost out of it at the same time in some scenarios, then awesome!

***

Another thing that sets viper apart is that it's primarily 2D, and I don't see that changing. There are constraints with what you can realistically do in a 2D environment. When you go 3D, you can either do far too little, or far too much. The first thing that comes to mind is vertex formats. Position? Position + color? Position + color + texture + normal? Position + color + texture + normal + extra info for the shader? I feel that by going 3d, it would break away from the concept of simplicity that I'm aiming for.

***

Currently, I'm relying on OpenGL 1.2, and I don't know if that will ever change. Having support for shaders would definitely be nifty but GLSL is far from being simplistic, and at this point I'm not sure the benefits out weigh the obstacles. If somebody wanted to help me enable them in a sane fashion, that would be amazing.

*** 

I suppose the next big huge step is going to be finishing up the input sub system. Keyboard and mouse should be fairly straight forward. Right now, the keyboard uses get async key state to poll the keyboard directly, but I'm going to investigate using raw input instead.

***

I'm working on tutorials and documentation for the time being in hopes of attracting more attention to the project, and oh yeah, I should probably host it somewhere. A game showing it off would be nice too.