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...
Subscribe to:
Posts (Atom)