C# MS SQL Connection

For a project I was working on I needed to connect to a MS SQL database.  I didn't need to do anything fancy, just connect and submit a bunch of queries.  Still though, this is the sort of thing I felt I should write down as I'm sure I'll need to do this again.

Bouncing Polygons!

Finally!  I've got stuff moving on the screen.  It seems that I was over-thinking things with my previous attempts at getting the cube to move around.  All I really needed to do was pass the data into the vertex shader and let it handle the rest.  Whatever, It's all working now.

With this we wrap up two topics.  Textures will be done; well more done, my texture code was done after the UV coordinates.  As well as transformations and animation.  Or at least the basics of animation are done, this just shows how to move and distort meshes, actually making it look like real movement takes a bit more planning and effort.

Matrix math and OpenGL

I'm still working out how to apply these transforms in my model class.  I think it'd be best if I found a way to pack the necessary information into a uniform buffer when rendering an object, this would allow the shaders to perform the necessary transformations.  The trick of course is to pack the data in such a way that everyone can make sense of it, and that's where I'm stuck at the moment.

Regardless, of my inability to copy data legibly I can still explain the core of what needs done.  OpenGL uses matrix math to perform transformations on your models.  These transformations are what allows in to move around on the screen.  So let's talk about matrix math.

Loading Textures in GL

I've got colored polygons on the screen.  Flat colors like that really aren't all that visually appealing.  I'm sure you could arrange enough of them to make an interesting picture, but it seems like a lot of work.  What would be a lot easier is if we could just take some image data and stretch that across the polygons.

My Model Class

Next thing to clean up is the code for managing models.  What it needs to accomplish:

• Load all necessary information from OBJ files
• Remember the buffer objects to store the data needed for rendering
• Track the changes to the model data and only update buffers when changes happen
• Perform all the work needed to render the model

Once again this class will likely be kept in a large array, one element for each model I have a need of drawing.  Eventually this class will need extended to be able to manipulate the object, or at least track transformations that it'll need when rendered.  I haven't dealt much with movements yet, but that's going to have to happen soon.

My Shader Class

In an effort to start organizing the code needed in an OpenGL program I began building a few classes to manage some of the work.  The first one I put together was the GLShader class.  It's job is the following:

• Remember which files hold the source code for a particular shader
• Be able to load the source code from file then compile and link the program
• Remember a list of all Uniform and Attribute variables that this shader will use
• Assign specific ID's for those variables when the shader is compiled

I envisioned an array of this class being created when the application loads.  Each element will be given the source files and variable list from some configuration file which it will then maintain.  Then as needed switching between the various compiled shaders at run time to render my scene with different effects.  Also I'd like to be able to reload shaders without restarting the program, to make it easier when debugging shader code.

Loading Models

I've gotten really annoyed with the large blocks in my OpenGL programs that fill arrays with vertex information.  What I need is a way to load this sort of data from a file, then I'll be free to use more interesting models without gumming up my code with hundreds of lines of vertex coordinates.  Perhaps a file that's easy to read, like say plain text.  It ought to provide all the details I want too; vertex coordinates, UV mapping for when I get around to textures, and maybe normals should I ever play with lighting.  Fortunately just such a thing exists.

C# and XML

I really didn't expect this one to be much of a challenge.  I've dealt with parsing XML in PHP, Javascript, and VBScript already and they weren't too bad to do.  I suppose it doesn't help that C# has like five different methods for parsing XML, so when you do any sort of search you get results for all the different methods that you need to sort through.

This is the method that I picked out to use.  Mostly because it's the one I figured out the quickest, but partly because it also works in Mono.  The XDocument class looked like the easiest one to use, but it's not normally available outside of the Microsoft .Net framework.  The XmlDocument class is available everywhere, and isn't too hard to work with, so that's the one I'm supplying these notes for.

Versioning Assemblies in C#

While working on an ASPX page there was some process that was supposed to copy over new DLL's for the page.  It was handy since it did all the registration and whatnot needed to make them work.  Until the page stopped working correctly, inexplicably new code wasn't being pushed to the site.

The errors make sense looking back at it, but when the pages are being updated but not the libraries the run time exceptions can seem pretty vague.  It didn't help that my compiler and debugger were on my laptop while the server hosting the page was in another building.  I could tell that the pages were updated since any old text editor would show it, but the libraries didn't have any useful markers beyond file size.

To finally prove that the libraries were being dropped somewhere I needed to give them version numbers so there was something more concrete to test with.

Shader Attributes

We've passed data to our shaders, but it's one size fits all data.  There's going to be situations where we need different information for each vertex, and pushing all this in uniform blocks just isn't going to work.  It's time to try shader attributes.

These are arrays of data, each element of the array should correspond to one of the vertexes.  When the shader executes it will only read the element that corresponds to the current vertex.  This is handy for things like locations, colors, normals and so forth which need applied individually to each vertex.

Talking to shaders

I've finished create the most basic of shaders, and they work in the sense that they get polygons onto the screen.  Let's step them up a bit.  To do that we'll need to pass data to the shaders, perhaps a color and maybe the model projection matrix to start moving away from those deprecated attributes.

I'd like to move up to a newer version of OpenGL, but I'm limited to version 3.0 (GLSL 1.3) since that's the highest version I can reach with all the machines I work on.  I'll make an effort not to use any features that are removed in later versions, I can't make any promises since it's not always easy to know what features those are.

The most basic shaders

So our program doesn't draw always draw triangles because we're missing shaders.  The code was updated so that it can load and use shaders, there just aren't any for it to load.  Let's fix that.

I'm not going to create anything fancy, just the most simple shaders to demonstrate the absolute basics.  I should mention that I just started learning about shaders a week and a half ago, so you can't really expect digital magic quite yet.

Adding shaders to your program

We've got some code that draws a pair of triangles using vertex buffer objects (VBOs).  They can only be seen on some video cards, and if you do see them they are plain white.  Adding a shader will get them drawn everywhere and let us apply some colors.

The first step will be adding some code so that our program can load shaders and get them to be applied when drawing polygons.  So lets start there.

Triangles drawn by VBO's

It took me a while to figure out Vertex Buffer Objects, they get pretty involved and throw you into some complicated stuff.  I'm not sure I fully understand all the stuff I had to do to make them work, but the program does what I want it to do and that has to count as some kind of success.

There's a lot of stuff to cover on this one, and with the hopes of keeping the posts at reasonable sizes I'm going to break them up into a few posts.  In this one I'm going to cover how to use VBO's to get your polygons on the screen.

Shapes and colors in GL

Previously I went through how to create a Windows form with an GLControl in it.  Nothing was drawn in that control, and really whats the point of having OpenGL accessible in your program if you don't actually draw anything?

There are several ways you can tell OpenGL to draw polygons.

• Immediate mode is the oldest and probably the slowest method of drawing.  They are not included in OpenGL ES, which is what Android and iOS devices use.
• Vertex Arrays was introduced in version 1.1.  This allows you to pass chunks of data to OpenGL in a single function.  All the data is stored in program memory which means that it needs passed through to video memory in order to render anything, this hampers performance quite a bit.
• Vertex Buffer Objects were released with version 1.5.  This moved the information needed for rendering into video memory which boosted performance.  I believe this is the preferred method of rendering objects currently.

When I was first working with OpenGL my machine had an integrated Intel video card in it.  The drivers only provided OpenGL version 1.4 which blocked all of my efforts to figure out vertex buffer objects.  Fortunately, that video card has been replaced with something better and I can play with modern methods.  I'm still going to take some time and go over the old methods just for completeness.

Tinkering in GL again

A long while ago I had puttered with drawing in OpenGL via .Net.  It was an interesting diversion for a while, but I ended up quitting that since I couldn't envision it really being viable.  Since .Net is an interpreted language you've got the run time environment causing some delays in executing your code.  For games you need to be rendering the screen 30 times a second, I had a hard time believing that this would be possible within the .Net environment.

I should have known better since this has been done in Java, which is essentially the same sort of setup.  Sure enough I was proved wrong.  I got into the Hex: Shards of Fate alpha from being a Kickstarter backer and soon discovered not only was this game written in .Net but it used the Mono framework as well.  The graphics appear to be going through the Unity graphics library as well.  All of the .Net parts they are using can be used on mobile devices as well, presumably this is how Hex will be getting onto those platforms as well.  From a technical standpoint I'm very curious how this game will end up.

From a more personal standpoint its rekindled my interest in using OpenGL within a .Net application.  With that in mind let me dust off that old code and see if I can't figure out how to make it work again.

C# and COM Interop

I recently came to a situation where I needed to perform some task in a VBScript that exceeded what the language permitted.  I could add a new DLL that includes the needed functionality which the script could make use of.  Ideally you'd probably want to use some form of Visual Basic to create the DLL, since at would allow all your data types to match what the script was using.  I didn't really want to use Visual Basic, so decided that if it was possible in C# then that's how I'll create my library.

Sorting out Makefiles

Currently I’m playing around in C#, which involves creating a collection of files holding source code and feeding all of this code into the compiler.  The concept is pretty standard, where it gets wonky is that I bounce between the Microsoft and the Mono .Net frameworks.  It quickly became clear I needed something to help me sort out which commands to use when I bounce between environments.  Make has been working brilliantly for this.