I whipped up a class to look after general application configuration data in similar fashion to the logger... It contains a static map to house all our config data that we now read in from a config.ini file...
We started with reading in all the data with a parse function, and rewriting the entire file with a save function... I wasn't happy with this, so we started looking into the possibility of writing only the values we wanted to change...
Tim and I spent ages looking up reference material and different forums to see if it was possible... Everything I tried ended up rewriting the entire config file with chinese characters... We eventually agreed with everyone else out there that what we want to do just is not possible...
So I added another static variable, a bool to tell the save function if anything has changed... When writing a value to the map, it flips to true... When saving the file, which is again a complete rewrite of the file, it flips to false... So its a little better than rewriting the file everytime the program is run...
I also started messing around with the OpenGL calls, setting some things up for when we start moving the camera around... Also to remember what the hell everything does in OpenGL, as it has been quite a while since I touched it last... Its all coming back slowly though...
Progress, and Roadblocks...
Tim has whipped up a nice quick OpenGL renderer that is working on both his and my laptops...
I put together a logger class to take card of all log file and debug console outputs... It uses a static File stream that it opens at the beginning of the application and then closes just before the end... It has the ability to print to file, console, or both, timestamps all entries, and lets you print to the same line multiple times if you want to...
I have run into an issue though... It appears that the application, when doing pretty much nothing, is constantly adding 4k memory to what it is using... In Windows Task Manager, every time it updates the amount, its 4k or 8k higher....
I put together a logger class to take card of all log file and debug console outputs... It uses a static File stream that it opens at the beginning of the application and then closes just before the end... It has the ability to print to file, console, or both, timestamps all entries, and lets you print to the same line multiple times if you want to...
I have run into an issue though... It appears that the application, when doing pretty much nothing, is constantly adding 4k memory to what it is using... In Windows Task Manager, every time it updates the amount, its 4k or 8k higher....
Initial Considerations and Coding...
We are making a 3D game...
So we need to decide if we use one of the many existing 3D engines out there, like Ogre3D, or the Irrlicht Engine... Both are open source, and I have already used Ogre... Alternative is to create our own engine... Tim has done this in the past, and I could use the expreience...
We decide on making our own... We will know the workings, and can put in exactly what we need, nothing more... And, one of the more important considerations, make sure we build it cross platform...
Physics is the next consideration...
Havok looks awesome, and is free to use these days... The main issue Tim has with Havok is that it is not Mac compatible, and his laptop is an old Mac...
So we look at alternatives...
We consider the Newton engine, which a friend of ours used with Ogre and didnt like much... We thought it sounded ok, being compatible with various platforms... ODE was another though, but I guess I have a prejudice against it, as I used it in Ogre and took it out quickly...
The Bullet Physics Engine is what we ended up with... Written by a former Havok employee, it is compatible with various systems, including the latest PS3 and XBox 360... We have hopes of getting into XBox Live, so this cross platform aspect was important... Also, it was recommended by a friend of ours...
After delving through the physics demos and looking at the various pieces of code, we started planning our renderer... We have already discounted the need for a Scene Graph, and have found a lot of the necessary Data Structures in the physics engine...
We have begun abstracting interface classes for display, rendering, and input, and have successfully set up 2 development environments : Visual Studio on my Windows machine, and Tim is trying out NetBeans on his Mac...
We currently have a resizable window that Draws nothing, and event calls are printing lots of useful information to the console... The information is incorrect, but at least it is there... It is my job to get this sorted out...
So we need to decide if we use one of the many existing 3D engines out there, like Ogre3D, or the Irrlicht Engine... Both are open source, and I have already used Ogre... Alternative is to create our own engine... Tim has done this in the past, and I could use the expreience...
We decide on making our own... We will know the workings, and can put in exactly what we need, nothing more... And, one of the more important considerations, make sure we build it cross platform...
Physics is the next consideration...
Havok looks awesome, and is free to use these days... The main issue Tim has with Havok is that it is not Mac compatible, and his laptop is an old Mac...
So we look at alternatives...
We consider the Newton engine, which a friend of ours used with Ogre and didnt like much... We thought it sounded ok, being compatible with various platforms... ODE was another though, but I guess I have a prejudice against it, as I used it in Ogre and took it out quickly...
The Bullet Physics Engine is what we ended up with... Written by a former Havok employee, it is compatible with various systems, including the latest PS3 and XBox 360... We have hopes of getting into XBox Live, so this cross platform aspect was important... Also, it was recommended by a friend of ours...
After delving through the physics demos and looking at the various pieces of code, we started planning our renderer... We have already discounted the need for a Scene Graph, and have found a lot of the necessary Data Structures in the physics engine...
We have begun abstracting interface classes for display, rendering, and input, and have successfully set up 2 development environments : Visual Studio on my Windows machine, and Tim is trying out NetBeans on his Mac...
We currently have a resizable window that Draws nothing, and event calls are printing lots of useful information to the console... The information is incorrect, but at least it is there... It is my job to get this sorted out...
In the Beginning...
As with all Blog posts, this is a bit of a history lesson... All about me and what the hell I am wasting this space on...
Basically, I am fresh out of uni, studied the art of making games, and decided to make one all on my own...
Gameplay and designs came flowing forth, and I decided that all my art will be made in 3D...
And since I was going to be doing all that hard work anyway, why not go all the way and make it a 3D game...
For now, all the details on exactly WHAT I will be creating are to be withheld...
But anyway, I decided as I was doing the same as my mate Tim, I'd ask him if he wanted to work together...
So my 'On My Own' project has become a 2 man team...
I created this waste of space to record what we do, decided to do, scrap, and thought about, in the hopes that I remember to keep it updated, and it may come in handy at a later date...
Anyway...
Thats enough of an intro... On to the engine building...
Basically, I am fresh out of uni, studied the art of making games, and decided to make one all on my own...
Gameplay and designs came flowing forth, and I decided that all my art will be made in 3D...
And since I was going to be doing all that hard work anyway, why not go all the way and make it a 3D game...
For now, all the details on exactly WHAT I will be creating are to be withheld...
But anyway, I decided as I was doing the same as my mate Tim, I'd ask him if he wanted to work together...
So my 'On My Own' project has become a 2 man team...
I created this waste of space to record what we do, decided to do, scrap, and thought about, in the hopes that I remember to keep it updated, and it may come in handy at a later date...
Anyway...
Thats enough of an intro... On to the engine building...
Subscribe to:
Posts (Atom)