I have a guest arriving a day earlier than expected and they will be here for the duration of my programming time, so this week will be very short. What I can achieve tonight and tomorrow morning, probably two hours tops. I’m going to see if I can get SDL installed and use it’s mouse ops to get mouse control in the program. The short term objective is to be able to use the mouse to control the camera direction.
So far the main objective has been installing SDL. Of course it didn’t work first time, so now I’m working out what to do. I can build the library but it wants to be a console app; not sure if OpenGL will play nice with that so I’m continuing to try to get it to work under Windows.
Resolved – thanks this person. The problem was that SDL defines its own main at some point, and I already have a main method. So the compiler reasonably was confused about which one to go with. I’ve disabled the command that specified SDL main as the preferred main and now we can compile and execute. Time to see if the libraries linked properly.
They didn’t. Ok. Of course. I didn’t want to have to use up my precious little time debugging linking issues but that’s what happening.
I was able to finally get it using pre-compiled binaries from the SDL website. I managed to break the linker somehow and had to reinstall my project, fortunately I’ve been making backups of my workspace so this was a fairly trivial issue.
Today I have unexpectedly got a day off work. Due to the intracacies of Japanese work culture, because a child saw me wearing a face mask yesterday and knowing that I had influenza last week, that child told her parents I currently had influenza. Her parents then called other parents, who decided I must still be sick, and the parent body told the school that they would not be sending their children to school while I was still under quarantine. Never mind that my student was unable to distinguish between ‘has’ influenza and ‘had’ influenza, or that my quarantine had expired two days ago, or that the reason I was wearing a facemask was because it was -3 degrees and all the staff were wearing them, the net result was work told me to stay home so students would come to the school.
Sadly it is not paid time away but I’ll put it to good use.
I had originally intended just to pick and choose the parts of SDL that I wanted, e.g. mouse/joystick/keys/sound/file IO but it seems that SDL requires you to initialize it and let it create its own graphics context. After then you can enable OpenGL within SDL, not the other way around (SDL within OpenGL) as I had intended. This will require some effort and some knowledge of SDL, which may be beyond my current skill set of zero knowledge of SDL. I will investigate it further. My current suspicion is that I will need to create a new, SDL focused project, and incrementally add my OpenGL classes in to it.
I will put mouse controls aside for now, and instead clear out the SDL tutorials; knowledge of SDL appears to be required.
I did have a look at improving the texture quality of my textures; for the stars at least I can improve the texture by using GL_NEAREST instead of GL_LINEAR. The stars still appear quite large, but at least they are not anti-aliased now. For best results I should build some point sprites, or just scatter some quads with a texture on them for planets and so on. I also noticed that the inside of my skybox is not apparently a true sphere, so I’ll have to adjust that.
Therefore for now I am working on the SDL tutorials as the main part of the programming task. Fortunately there are a lot less of them than the Blender ones, and these are inherently less time consuming.
1/9 complete. Tutorial 1 is nothing interesting to show; just intro to SDL and rendering contexts. One minor fun thing was that it gives fullscreen control and has better windows UI support than OpenGL.
Tutorial 2 in progress: Hey this looks a lot like a sprite sheet…
Now we’re getting somewhere.
I’ve done some basic animation of the sprite sheet, so we now have the appearance of a small plane doing circles in the same spot. It’s ridiculously easy. Of course I can’t show it off since it’s just that plane in a different orientation, but it won’t be long before I’m uploading .exe for you all to play with.
That’s probably all I’ll get done tonight, and since my guest is arriving, probably all I’ll get done this week. It’s significant progress. I’m confident I’ll be able to wrangle OpenGL into it and then get back on to the main task before the end of February. Also I should be able to, once I’ve finished these tutorials, sit down and knock out a prototype every week or so.
Tutorial 2 is done. A quick note on the SDL tutorials –
I’m using SDL Game Development, from Packt Publishing. Whereas each of the Blender tutorials started from scratch, the SDL tutorials build-on from the previous tutorial.
This tutorial was about how to animate a sprite sheet – tutorial 1 was ‘Setting up SDL’ and introducing the tools to load a single frame. I animated the sprite sheet just for fun, then found that was tutorial 2. There was some useful C++ programming skills along the way, in particular, a quick introduction to maps (the next container class after vectors, which I have been using for my vertices in OpenGL) and how to include objects as class variables in C++. I have been unable to do this until now and have been using references, so this represents two fairly major capabilities which I am overjoyed to play with.
Chapter 3; polymorphism and inheritance. Oh, what glee. I had planned on learning how to do this in C++ for the Actor class I talked about, and now here is a tutorial on exactly that.
Halfway through tutorial 3. Next is abstract base classes. I’m so surprised to find a quality lesson on polymorphism and object oriented programming in the middle of graphics tutorials.
Well I nearly made it to the end of tutorial 3 before things got messy. The tutorials have an over-reliance on the Singleton design pattern, and attempts to re-use many of the header files currently used. This requires significant modification of the existing files and resulted in a big mess of spaghetti code. I’m able to follow reasonably well what is going on, but the program design isn’t elegant, and right now, it’s not even compiling. When I attempted to access the source code for the lesson I found that only the source code for the last few chapters is available. That’s okay, I was able to learn a great deal from the first part of the book already. I can perhaps reverse engineer the final code to get back to this chapter; or press on and see if I can clean this mess up.
All in all, for a week where I didn’t expect to get anything done, I had a lot of progress. I may get some more time this weekend but I’m not counting on it; if I do, I think I’ll sort out the header files and undo the Singleton stuff.
End of tutorial 3. We have some cats running about on the screen. Behind the screens, I made some fairly major changes to the tutorial code structure.
The main thing is the design decision to change Game.h from a singleton class to a regular class. The tutorial did it this way so that they could access the rendering context from any part of the program. However, by changing the renderer to be a variable of Texture Manager (itself a singleton already) we can piggy back the feature into existing code.
I will probably want to remove the TextureManager singleton also as there’s no overwhelming reason I can see to support the need for this.
I also tidied up the header file and file arrangement.
The next tutorial section is on joystick and mouse input, which is the reason I was doing the tutorials in the first place.
Chapter 4 starts up with “What is a vector” bwahahahaha 2D maths? I THINK WE CAN DO THIS. It seems like we’re going to define our own 2D vector class. It has some useful examples of operator overloading but I might just replace it with GLM’s 2D vector in practice.
OK Vector2D done. Now on to the fun stuff: Input handling. I have a joystick, keybboard and a mouse so I’ll set up input handling for those. I’d like to set up handling for a gamepad but I don’t own one, so I can’t test it. Maybe I can buy one for myself later.
Tutorial starts off with:
static InputHandler* Instance()
OH NO ANOTHER SINGLETON. Yeah I’m not going to implement another singleton class.
Ah, I see why the author is using so many singletons. The software often has to make cross-references between classes, eg:
class car
{
Wheel wheel;
};
class wheel;
{
Car mycar;
};
This is a problem in C++ because the compiler doesn’t know how to build a car without first building a wheel, and it doesn’t know how to build a wheel without first building a car. So crash and burn.
The solution is forward declaration, whereby we give the compiler a sneak peak at the appropriate class.
//In car.h
class Wheel;
class car
{
Wheel wheel;
};
//In Wheel.h
class Car;
class Wheel
{
Car mycar;
};
I don’t approve of the authors direction at this stage; they have made a mess of the program design and used a lot of header files, but I haven’t seen the finished product nor looked in detail at the final code, so there may be good design decisions for this. I believe they used the Singleton design pattern because it meant they could skip a lesson on classes and C++ quirks in a book that already has many such lessons.
I want this to be the basis of a framework for me to throw out prototypes, and for that reason, I am ignoring the singletons and forward declaring the classes where I need to.
That’s where I have to leave it for tonight.
I’m able to identify input from the main stick, throttle and rudder.
To complete this step, I still need to:
1 – Complete the loop from event to updating the sprite position.
2 – Implement mouse events.
3 – Implement keyboard events.
I got a lot done for a week where I didn’t expect to get anything done.
Next week, I want to:
Finish tutorial 4.
Start the Unity tutorials.
Complete Auchindoun dungeon review on my other blog.
Stretch goal: Implement SDL in the OpenGL planet engine, so that I can look around with the mouse.
Stretch goal 2: Start/complete SDL tutorial 5.
Adventures in programming, et al. 