Game Programming III – Dev. Post 5
|
I am absolutely terrible when it comes to updating this thing… the main reason is because I’ve just never felt like I made progress significant enough to warrant a blog post and so, I simply decided to wait “one more week” until I post something. But even so, the due date for the project is Sunday, I haven’t written the report, I’m not done with the web server and we just got drawing to work in the game. So, basically, I’m writing this thing to get everything down before I sit down with the report and write what went right, what went wrong and why.
Either way, let’s get started. The very first thing I did was to figure out to manage drawing. This ended up taking up a lot longer than expected due to surrounding issues such as game object management and a general lack of idea why the thing wasn’t working it should be. There were a lot of problems on the way and I’m going to go over them in a quick fashion just to remind myself about what they were, what caused them and how to solve them, as well as go through what I actually did during these weeks.
The first problem I encountered was when I was creating the game object management. The game objects where supposed to contain a scene node which would be holding all graphical information while the game object handled the in-game logic. Due to pointer problems there were issues with heap memory corruption. This was my first time encountering this type of problem and finding the source was rather annoying as I had to through most of the beginning code to find the point that made the entire thing crash. Eventually I found it and managed to patch it. I will have to look more into why they happen and how to prevent after this course.
After getting the game object management under control I started working on the drawing. This turned out to be far more challenging than expected as nobody on the team had any expertise on this subject. It fell on me to build and understand the structure. Fortunately, our teacher had provided us with a home-made engine that took care of the more complicated matters in creating shaders, textures, samplers, vertex buffers and similar. We also had premade shaders, vertex formats, samplers and such so all I had to was to put all the pieces together. It turns out this was something I wasn’t very good at. The first step was to load all resources into the project, this turned out to be simple enough as the engine came loaded with classes that were supposed to build these things from the files we already had. Some things, such as the vertex buffer (an object that would hold the data for the models of the game objects) were hard coded and created inside the program instead of loaded in, but the principle remained the same.
After finishing loading resources it was time to use them. To put the pieces together so to speak, but while there where little trouble assembling them, the game didn’t draw a cube no matter what settings were changed or adjusted. After some experimentation with another project I learned that the problem was that the matrix that was supposed to inform of the game object’s position didn’t work as intended.
At this time one of my team mates completed a script that would write the current speed of the player on the screen. The problem with this script was that it created shaders every update which greatly impacted the update speed and drawing. This problem was solved by a few quick fixes of the code so that the factory and the text shader weren’t created and destroyed in every frame but it turns out that it also stopped the player from being drawn somehow so we had to scrap it and find another way of showing the current speed.
At the moment that I’m writing this the writing works even if there is trouble with the transform matrix which is currently set to:
[1000]
[0100]
[0010]
[0001]
Permanently. But this disallows the object from changing position the way it is set up, so the to solve this problem I have to find a way to make sure that the matrix isn’t reset. But that’ll be my work tomorrow.
|