It is DAMN hot today, so Tim and I sat around and talked about the design of the engine... We spent some time separating the files for the engine into a folder, and the game into another...
Basically nothing code-wise was done...
But we figured out a way of setting up our GUI for menus, and how we are going to change between scenes, and keyboard mappings...
Funny story...
As it turns out, if you allocate an array a size of 0, then proceed to fill it with 139 values, it will corrupt memory and kill your application...! Who would have thought..? Anyway, now that Tim has located and repaired the issue, we have a working build again...
I have set up a few maps in the code that contain displays lists and store GameMesh objects... Our code will now parse the file once, and store the mesh under the filename in the map, and when drawing it, does the same thing with the display list...
I dont know if it will stay this way, especially the display lists, but for now it works...
Tim is still working out some kinks in the parser too... but its slowly getting refined to the point of perfection... or close enough...
I started looking into threads today as well, hoping to get some idea of what is involved in implementing them... It kind of worked...
I have set up a few maps in the code that contain displays lists and store GameMesh objects... Our code will now parse the file once, and store the mesh under the filename in the map, and when drawing it, does the same thing with the display list...
I dont know if it will stay this way, especially the display lists, but for now it works...
Tim is still working out some kinks in the parser too... but its slowly getting refined to the point of perfection... or close enough...
I started looking into threads today as well, hoping to get some idea of what is involved in implementing them... It kind of worked...
Corruption...
Tim modified the parser, and now it dies, complaining about bad memory allocations...
All the logic looks fine, the variables are assigned correct values, and the new keyword now hates us...
All the logic looks fine, the variables are assigned correct values, and the new keyword now hates us...
Clean up...
We now have a parser that runs about as fast as Tim can manage... parses 86500 lines, which was over half a million tokens, in just under a second... It spits out the mesh and normals that we need, and handles string enclosed in "'s... which is how the texture is stored...
I put some quick display list tests in the OpenGLRenderer, and got it right first time... Am now planning on how to implement this for all objects in the game... We plan on reusing a lot of models, and also want to put different textures on different enemies with the same mesh, so that is pulled out and kept separate from the display lists...
I set up some simple controls for the movement of the player character... We have a cube that is read form ASE, draw with a display list, and moved with the arrow keys... I also set the camera to scrolling, and the cube to match...
We did a bunch of physics tests as well... I created a second physics world without gravity... I put the cube in this world, and switched it to the gravity world with the space bar... It started off floating, then fell to the ground plane... So simple... I also discovered that we can set gravity per object, so we can use this to shoot down planes... When the HP reaches 0, switch on gravity, watch it crash and burn...
We have moved slightly into game implementations, rather than engine implementations, but thats fine with us for the moment...
I put some quick display list tests in the OpenGLRenderer, and got it right first time... Am now planning on how to implement this for all objects in the game... We plan on reusing a lot of models, and also want to put different textures on different enemies with the same mesh, so that is pulled out and kept separate from the display lists...
I set up some simple controls for the movement of the player character... We have a cube that is read form ASE, draw with a display list, and moved with the arrow keys... I also set the camera to scrolling, and the cube to match...
We did a bunch of physics tests as well... I created a second physics world without gravity... I put the cube in this world, and switched it to the gravity world with the space bar... It started off floating, then fell to the ground plane... So simple... I also discovered that we can set gravity per object, so we can use this to shoot down planes... When the HP reaches 0, switch on gravity, watch it crash and burn...
We have moved slightly into game implementations, rather than engine implementations, but thats fine with us for the moment...
Parser Intergration and Fail...
Tims Parser for ASE files, while not complete, was very simple to integrate with my code... This is always a good sign... Tim finished off some more of his parser to cater for unknown opening tags and sub-materials...
We then spent hours trying to make my code actually draw from the physics object information that was created... I eventually managed to get the loop that sent the verts to OpenGL to run all the way through instead of crashing on the 3 iteration... Only to have it crash at the end of the function, complaining about damaged memory...
So we decided to scrap this idea, and put our mesh information separate to our physics mesh information... I already had the data structure in place for this, so beginning the task was simple...
When pulled out a pen and paper and did some design work on how our objects would look code-wise... Game objects will now contain mesh objects and physics objects separately, and we will do some calculations at read-in time to deal with the size of the bounding boxes...
I started on ripping out the mesh information, and Tim will be adjusting his parser to match...
We then spent hours trying to make my code actually draw from the physics object information that was created... I eventually managed to get the loop that sent the verts to OpenGL to run all the way through instead of crashing on the 3 iteration... Only to have it crash at the end of the function, complaining about damaged memory...
So we decided to scrap this idea, and put our mesh information separate to our physics mesh information... I already had the data structure in place for this, so beginning the task was simple...
When pulled out a pen and paper and did some design work on how our objects would look code-wise... Game objects will now contain mesh objects and physics objects separately, and we will do some calculations at read-in time to deal with the size of the bounding boxes...
I started on ripping out the mesh information, and Tim will be adjusting his parser to match...
Physical Motion...
Our OpenGL testing produced some more interface functions for lighting and camera controls... We can now implement movement of the camera and light, and can toggle on/off lights at will... It should be simple to create an implementation for DirectX, as Tim looked up the OpenGL lighting, I looked up the DirectX, and we found many similarities...
I hacked up a cube to test our movement and lights, and after a lot of implementations, found out that some of my faces were described backwards, and not visible...After sorting this out, we started looking at physics...
We made some good progress with the physics integration... Basically we jumped on the Bullet wiki and looked at how to set up some basic things to start with... We ended up with an invisible sphere falling onto an invisible plane and bouncing...
We checked the positions with the Logger, so yeah, its definitely there...
We rigged up a transform call to use the position of the sphere and placed the call before the Cube is drawn... And then our cube fell onto an invisible plane...
The simplicity of the physics was quite amazing, and so damn simple...
I also put in a plane so we have something for the cube to visibly strike...
Next on our list was how to get our own meshes into the engine...
We decided to go for ASE format files, as they contain pretty much everything required for the renderer: Vertex information, Face/Vertex relations, texture coords, and texture file names...
Tim started working on the parser, while I started looking at how we can use the physics data as mesh information...
Turns out there is a TriangleMesh we can use... ASE stores all objects in triangles, so this should work out nicely...
I hacked up a cube to test our movement and lights, and after a lot of implementations, found out that some of my faces were described backwards, and not visible...After sorting this out, we started looking at physics...
We made some good progress with the physics integration... Basically we jumped on the Bullet wiki and looked at how to set up some basic things to start with... We ended up with an invisible sphere falling onto an invisible plane and bouncing...
We checked the positions with the Logger, so yeah, its definitely there...
We rigged up a transform call to use the position of the sphere and placed the call before the Cube is drawn... And then our cube fell onto an invisible plane...
The simplicity of the physics was quite amazing, and so damn simple...
I also put in a plane so we have something for the cube to visibly strike...
Next on our list was how to get our own meshes into the engine...
We decided to go for ASE format files, as they contain pretty much everything required for the renderer: Vertex information, Face/Vertex relations, texture coords, and texture file names...
Tim started working on the parser, while I started looking at how we can use the physics data as mesh information...
Turns out there is a TriangleMesh we can use... ASE stores all objects in triangles, so this should work out nicely...
Configurations...
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...
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)