I guess I can't entirely say this week was productive as far as lines of code produced, but in terms of how much I have designed and learned, this week was one of the most productive in my life. Aside from starting college courses last week (18 credits) I also did a lot of homework over the weekend, and definitely learned a lot there. Oh, by the way, anyone who does not already know: One of the best ways to manage everyday activities, homework included, is something called Remember the Milk. I absolutely love this website and highly recommend it to anyone who is currently living and not scared of computers.
Well, that aside, I would like to update anyone reading this on my progress. This week, I didn't do a whole lot of coding for the Supersonic engine, but I did quite a bit of reading. I have read about quite a few different game frameworks both specifically for OGRE, and unrelated to OGRE at all. Obviously I found those ones related to OGRE quite a bit more interesting and helpful, but I picked up some basic concepts (Singletons and threading) from other articles.
One of the most interesting articles I read was the Advanced OGRE Framework tutorial on OGRE's wiki. It is basically a code listing for a nice framework for OGRE applications, and appears to be quite useful to me. What little coding I have done this week was porting that framework to Python so I could use it myself. That framework includes with it a state manager, but I opted to write my code based off (not copying word for word) a different state manager also found on OGREs wiki. With that, I now have working input!
One thing that will inevitably be essential to the creation of a game engine is a Singleton. For that matter, it has definitely been a little challenging trying to figure out how to make a singleton in Python, because it's not a built in language feature. Luckily, this was made easy by another article I found: (link found on python-ogre wiki) Singleton Metaclass. Okay, I will admit I have not taken the time to look that over and figure it out (and considering it's simplicity, it seems like it might be pretty easy; don't forget: I only started programming with Python a few weeks ago). It sure looks promising though.
My plans from this point forward are still to get some kind of simple game in the works, featuring input, terrain, movement, animation, collision, game states (menu/pause menu) and a level manager. I have never ever used shaders before, and I barely even know what they are, but if I'm up to the challenge in the coming weeks I might even check out shaders and make some kind of weird metallic guy, or I could simply add a body of water; it would be cool to have a shiny rainbow tree though! For this week I'll simply work on animation.
I sure hope I can manage when it comes to the point of creating my own content. Anyone that would like to help me with that is welcome to comment and let me know.
Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts
Friday, January 28, 2011
Friday, January 21, 2011
Supersonic Game Engine Week 2!
Supersonic! That's just what I have temporarily titled my game engine. In other news: I broke everything - then fixed it, it's fine. Also, Calc-based Physics 1, Chemistry II and Calculus III, but that shouldn't be a problem. Also, in case you weren't aware, "45% Of Students Don't Learn Much In College" and that is quite a problem. Don't worry about me though, I'll be one of the students that learns a lot.
Anyways, as far as my game engine goes, I feel like it's been a good week. I haven't put in a ridiculous amount of hours into this project, but I did come up with a name, and I consider that to be a pretty significant amount of work. The name, by the way, if you didn't get it already, is Supersonic. One of the games I kind of wanted to model was the Sonic games of late, as they are platformers obviously. Another game I am looking at is Super Mario Galaxy (great game, haven't played the sequel yet but I hear it's even better).
Oh, don't worry, I did a lot more than just come up with a name. I also broke my python-ogre build by doing something.. not sure what. Well to cut the story short I reinstalled it and it's all good. And then Andy Miller (who apparently does most of the work on the OGRE Python wrapper) updated the SVN trunk with the latest version, 1.7.2 which probably supports Python 2.7, but I'll stick with 1.7.1 and Python 2.6 for now.
Anyways, on to the real details of my Supersonic 3D game engine project. Last week I vaguely talked about what my plans were for this project, now I will vaguely talk about what my plans are. For the most part, my number one goal for this semester is to get something that works and that I can show off. In order to do this, I am probably going to use a mix of different libraries. First and foremost, and most obviously will be OGRE, but along with that I'll be using OIS, and I would like to use CEGUI but that depends on whether or not I figure out how to make it work again (because I also broke it? or it just refuses to reinstall; I needed to change the install options so I was reinstalling it, and suddenly it absolutely refused to install claiming some version discrepancy of libtool, of which the script was written in 2.2.6b and supposedly I have 2.2.6... but in truth I actually have 2.2.6b so I don't know what's going on there). Anyways, I am planning on using some kind of physics engine to start with; a couple of possibilities are ODE and Bullet, both of which integrate well into OGRE which is nice.
In the near future I might be adding an AI library, and I'll have to do something about sound, but I haven't looked into possibilities for either of those. I certainly have the resources to test and therefore develop networking capabilities as well which I might also find some library to handle for me. As I get further into the development process, I would overall like the project to have it's own physics engine and AI library and such, but I wouldn't bet on that just yet. One thing that will definitely help in the long run is to make the project extensible by plugins, in case one of the libraries I use by default is discontinued.
Well as for what I'll be working on this week: I would like to make my own working InputManager (which relies on OIS for the moment), and I'd like to be able to create a scene with a controllable, animated character. For the most part I'll simply be using the resources that come with OGRE like the robot mesh and animation, and the terrain, etc. If anyone reading this would like to check out what I have, and help me make models and other art, that would be greatly appreciated. The art would mostly be used to demonstrate the capabilities, and for testing purposes, obviously. I can survive with the resources OGRE comes with by default though, so this isn't urgent.
Well, have a good week, and tune in next week for another exciting and epic tale of Supersonic Game Engine development!
Anyways, as far as my game engine goes, I feel like it's been a good week. I haven't put in a ridiculous amount of hours into this project, but I did come up with a name, and I consider that to be a pretty significant amount of work. The name, by the way, if you didn't get it already, is Supersonic. One of the games I kind of wanted to model was the Sonic games of late, as they are platformers obviously. Another game I am looking at is Super Mario Galaxy (great game, haven't played the sequel yet but I hear it's even better).
Oh, don't worry, I did a lot more than just come up with a name. I also broke my python-ogre build by doing something.. not sure what. Well to cut the story short I reinstalled it and it's all good. And then Andy Miller (who apparently does most of the work on the OGRE Python wrapper) updated the SVN trunk with the latest version, 1.7.2 which probably supports Python 2.7, but I'll stick with 1.7.1 and Python 2.6 for now.
Anyways, on to the real details of my Supersonic 3D game engine project. Last week I vaguely talked about what my plans were for this project, now I will vaguely talk about what my plans are. For the most part, my number one goal for this semester is to get something that works and that I can show off. In order to do this, I am probably going to use a mix of different libraries. First and foremost, and most obviously will be OGRE, but along with that I'll be using OIS, and I would like to use CEGUI but that depends on whether or not I figure out how to make it work again (because I also broke it? or it just refuses to reinstall; I needed to change the install options so I was reinstalling it, and suddenly it absolutely refused to install claiming some version discrepancy of libtool, of which the script was written in 2.2.6b and supposedly I have 2.2.6... but in truth I actually have 2.2.6b so I don't know what's going on there). Anyways, I am planning on using some kind of physics engine to start with; a couple of possibilities are ODE and Bullet, both of which integrate well into OGRE which is nice.
In the near future I might be adding an AI library, and I'll have to do something about sound, but I haven't looked into possibilities for either of those. I certainly have the resources to test and therefore develop networking capabilities as well which I might also find some library to handle for me. As I get further into the development process, I would overall like the project to have it's own physics engine and AI library and such, but I wouldn't bet on that just yet. One thing that will definitely help in the long run is to make the project extensible by plugins, in case one of the libraries I use by default is discontinued.
Well as for what I'll be working on this week: I would like to make my own working InputManager (which relies on OIS for the moment), and I'd like to be able to create a scene with a controllable, animated character. For the most part I'll simply be using the resources that come with OGRE like the robot mesh and animation, and the terrain, etc. If anyone reading this would like to check out what I have, and help me make models and other art, that would be greatly appreciated. The art would mostly be used to demonstrate the capabilities, and for testing purposes, obviously. I can survive with the resources OGRE comes with by default though, so this isn't urgent.
Well, have a good week, and tune in next week for another exciting and epic tale of Supersonic Game Engine development!
Saturday, February 20, 2010
C++: Forgotten Syntax
Well I do realized this post is later than my usual time (I usually have a post done Thursday or Friday, and schedule to post it at 3:00PM on Saturday.. In case you weren't aware, that's what I do) But I will still post nonetheless. This week I'll be giving a couple tips on C++, although you can't really depend on MY tips unless you yourself are more of a beginner than me. Personally, I've been with C++ for almost a year now, I took a class at a junior college, and I've been going through C++ Primer in my spare time. You can at least trust my opinions because I have more experience than about 50% of the other C++ newbies who learn how to write a hello world program and call it genius.
I want to call attention to a few things in C++ that personally annoy me, the things you and I, and millions of other C++ programmers commonly forget, resulting in a million compile-time errors. First of all, the ever-so-beloved semi-colon. Who would have thought that one small semi-colon has the power to completely change the output of a program? Secondly, brackets. It is common to forget the ending bracket, but how many times have you forgotten both the beginning AND ending brackets? Also, what are the unseen consequences of forgetting a "delete" command?
Well, the most common problem is probably forgetting semi-colons. This is usually quite easy to do, especially after typing out a long statement, but with practice, it'll begin to be similar to a second nature. There's really not much I can say about semi-colons.
In my opinion, the most annoying problem, and second most common (to semi-colons) problem is forgetting brackets. Every once in a while, I think, "You know, I don't need brackets here, it's just one line." But later I go back to that for loop or if statement or whatever, and I add a couple extra lines for some reason, but I forget those damn brackets!
The above picture is a good example of being able to write an if..else statement without the use of brackets. Now notice the difference the number of lines makes:
This code looks right doesn't it? Wrong, it is tricky to tell because of the indention (which I had to add myself, the editor wouldn't for me). A lot of times, if you are sure you are going to be typing in more than one line, and probably most of the time no matter what, you are in a habit of adding brackets, but when you go back to add a line or two, you totally forget about the brackets. Again, with practice, most people get better at remembering these things.
The third, and most important, and least noticeable problem is forgetting to deallocate memory, which is why you really shouldn't allocate pointers and that crap in the first place unless you absolutely have to. Has anyone here every ran a program, and then ran it again later without restarting... and then ran it again later, and again, without restarting? Well after doing so, did you notice your computer was extremely slow? So you open up task manager and kill every last process you can think of, and then you are down to 25 processes yet your memory usage is still at 93%. What's happened is called a memory leak, and in short... using new without using delete causes this. And even larger, using a million news without deletes causes this in a large scale.
Let's suppose you do remember your delete statements, you allocate memory for a bunch of arrays, array1, array2, array3, etc. and then you make absolutely sure you remember to delete them, so you have delete array1; delete array2; delete array3;. Well sorry to break it to you, but that's not gonna cut it. That's going to delete the starting pointer (the pointer pointing to array1[0], and array2[0], and the rest) but it won't delete the entire array. To fix this you must use delete [] array1;
So there you have it, now you will be extra careful to remember those semi-colons and brackets. And hopefully you don't have to think about deallocating too many memory slots.. Besides, allocating them in the first place is already some fairly advanced stuff that you really don't need to be fooling with unless you know what you are doing. Typically I don't even think of allocating memory except for as a last resort... which means I haven't ever actually done it in my own project where I'm not following a guide that tells me to use new and delete!
Have fun!
I want to call attention to a few things in C++ that personally annoy me, the things you and I, and millions of other C++ programmers commonly forget, resulting in a million compile-time errors. First of all, the ever-so-beloved semi-colon. Who would have thought that one small semi-colon has the power to completely change the output of a program? Secondly, brackets. It is common to forget the ending bracket, but how many times have you forgotten both the beginning AND ending brackets? Also, what are the unseen consequences of forgetting a "delete" command?
Well, the most common problem is probably forgetting semi-colons. This is usually quite easy to do, especially after typing out a long statement, but with practice, it'll begin to be similar to a second nature. There's really not much I can say about semi-colons.
In my opinion, the most annoying problem, and second most common (to semi-colons) problem is forgetting brackets. Every once in a while, I think, "You know, I don't need brackets here, it's just one line." But later I go back to that for loop or if statement or whatever, and I add a couple extra lines for some reason, but I forget those damn brackets!
The above picture is a good example of being able to write an if..else statement without the use of brackets. Now notice the difference the number of lines makes:
This code looks right doesn't it? Wrong, it is tricky to tell because of the indention (which I had to add myself, the editor wouldn't for me). A lot of times, if you are sure you are going to be typing in more than one line, and probably most of the time no matter what, you are in a habit of adding brackets, but when you go back to add a line or two, you totally forget about the brackets. Again, with practice, most people get better at remembering these things.The third, and most important, and least noticeable problem is forgetting to deallocate memory, which is why you really shouldn't allocate pointers and that crap in the first place unless you absolutely have to. Has anyone here every ran a program, and then ran it again later without restarting... and then ran it again later, and again, without restarting? Well after doing so, did you notice your computer was extremely slow? So you open up task manager and kill every last process you can think of, and then you are down to 25 processes yet your memory usage is still at 93%. What's happened is called a memory leak, and in short... using new without using delete causes this. And even larger, using a million news without deletes causes this in a large scale.
Let's suppose you do remember your delete statements, you allocate memory for a bunch of arrays, array1, array2, array3, etc. and then you make absolutely sure you remember to delete them, so you have delete array1; delete array2; delete array3;. Well sorry to break it to you, but that's not gonna cut it. That's going to delete the starting pointer (the pointer pointing to array1[0], and array2[0], and the rest) but it won't delete the entire array. To fix this you must use delete [] array1;
So there you have it, now you will be extra careful to remember those semi-colons and brackets. And hopefully you don't have to think about deallocating too many memory slots.. Besides, allocating them in the first place is already some fairly advanced stuff that you really don't need to be fooling with unless you know what you are doing. Typically I don't even think of allocating memory except for as a last resort... which means I haven't ever actually done it in my own project where I'm not following a guide that tells me to use new and delete!
Have fun!
Subscribe to:
Posts (Atom)
