TWiki > Team2 > ProjectTwo > IndividualLogs2 > JonProj2Logs (r1.10)	TWiki webs: Main | TWiki
	Team2 . { Changes | Index | Search | Go }

-- JonathanSamples - 26 Feb 2004

I implemented all of the classes. These include Triangle, Room, Ball, and Path. At this point I havent been able to run it because of compiler errors. I submitted it anyway so that the guys could have something to work with.

-- JonathanSamples - 28 Feb 2004

Today got all of the compiler errors out so now we have something that runs. I also, go the interface running today. At this point it uses the idle method of glut and that should be satisfactory for the initial prototype however it will probably not be very good once we get into the game design a little deeper. Also, at this point the ball does not change velocity. Since we are not required (at this point) to have it do so I didnt implement this yet.

-- JonathanSamples - 29 Feb 2004

I changed the interface so that it now has some reference lines so that you can actually get a 3D feel. I also changed the perspective so that it is not right on so you can actaully see the contour lines. Also, in room now instead of calling the collideVertices function once and having it figure it out for all three I just call it three times passing a vert each time. I think I will do the same for edges probably.

-- JonathanSamples - 01 Mar 2004

I had hacked the glut include and just had the libraries in a local folder so now I changed it so that the libraries are in their correct places and the dlls are in theirs. I did this so that our code will work on the lab machines.

-- JonathanSamples - 01 Mar 2004

I was able to make the view point to spin and really give the viewer a 3D point of view. Also, implemented most of the collide edge function but dont have the solveQuad function working for me yet.

-- JonathanSamples - 01 Mar 2004

Adam and I worked the bugs out of both the collide edge and collide vertex functions. As well as fixing the solveQuad function. So now we have working tests for both of these cases. For the edge collision we have the ball start on the positive x-z plane and move -z toward the edge on the x axis. For the vertex we have the ball start on the neg x axis and move in the pos x direction to hit the vertex at the origin. We are still waiting for joe to put his function in. We do have a test for his function but as of now it doesnt pass it because he has not implemented the collide face function. As of now we just have the ball stop whenever it detects a collision. We do not give it a new velocity except the (0,0,0) vector.

-- JonathanSamples - 01 Mar 2004

This morning checked on the code to make sure joe had implemented his function and he had but he was unable to compile or debug on the lab machines because of the weird error with the glut.h file and how it redefined exit. So I had to compile and tell him what the results were so it was sorta the worst and most indirect method of debugging I have ever been a part of. I had to fix the fact that the test we had, had the ball colliding with a triangle in the x-y plane to one that collided with a triangle in the x-z plane. Then the verts were in the wrong order so I fixed that. Finally, it still wasnt detecting collisions and I was able to narrow it down to one particular peice of the function that was returning prematurely so I just commented it out and then we were able to detect face collisions. This is just a hack though and joe will need to get it rectified as soon as possible. I also compiled the release version and posted it on the wiki. Although it is doing something strange. Before when we posted executables they just would promt you for download or open immidiately but now it tries to run the program in IE. So you have to right click on the link and "Save as" to download it.

-- JonathanSamples - 02 Mar 2004

Tonight I started on the second prototype. I got the new files necessary for normalization and for matrix operations on Tuples. I added them to CVS. I had to taylor some things in them however. I implemented [] indexing for trinagles so now we can use that syntax instead of getV1 and the like. The reason I did this was because the new code uses such syntax and I didnt want to mess with Z's code too much. I also changed the interface so that now we can input ball posiiton and velocity while the program is running. Oh ya I also changed the getRed... functions to just a singe setColor function. The other way is just stupid.

-- JonathanSamples - 06 Mar 2004

I implemented a test program for edges. I did it as she recomended. Implemented random ball and edge generation. It is edge generation on the x axis so it is not that radom of an edge. We ran it a lot of times and it only failed about one out of 20 and we think that is due to numerical inacuracies because on the first step every time it gives a theta of 1 which will not collide but then on the next step in returns a theta of -.00008 or something like that when it should be 0. So we need to implement a fudge factor in order to compensate for that. We also found a bug in edge detection while implementing the test. It looks like we forgot some parenthsis so that the factor of two in the linear term of the quadratic only had half of it being mulitplied by two instead of both of the terms.

-- JonathanSamples - 08 Mar 2004

Today I went in to get help from Z. For some reason, even though all of the tests we ran passed, or pretty much all passed. When I actually run it using the interface it stops the ball permaturely for edges. So we found the bugs, yes there were two. First when calling collideEdges we were passing the wrong vertex as the end vertex of the edge so when computing if the collision occured on the edge and not just on the x axis it would return a wrong value! The second bug was in the final if statment--it didnt have an else so when that test failed, it didnt do anything and then when it jumped out of the above nested if it would skip over the else and so would just return 0 every time. I though the compiler would complain about not returning anything but it looks like VC has a default. That is anoying. But now its all working correctly.

-- JonathanSamples - 11 Mar 2004

Ok, today I implemented the standardization. So now we use standardize in the constuctor of triangle to set the standard triangle pointer and the transformation matrix members of the triangle class. So the vertex and the face collisions work as far as I can tell. I havent done any extensive testing yet because we dont have any kind of collision response yet so the ball just stops whenever it hits something. I also implemented the edge standardization. I dont know why it was having linker problems but when the edge standardization was declared as a global function it didnt compile so I just made it a member function of trinagle. It doesnt affect anything but now it links. Go figure. I call the edgeCollision detection function once for every edge (so three times) before each time I set some variables that need be reset for each edge since there is a different standardization for each edge. So you have get a new transformation matrix and then transform the velocity and ball path each time. I have tested all vertices, the face and all three edges of one triangle but from only one angle each but i think it is working. Also, collision for faces only works for one side of the triangle, I believe that is how it is supposed to work. So we are kinda caught up.

-- JonathanSamples - 25 Mar 2004

Today, helped Adam debug the collision response. For some reason the new move function that he created to use vectors to move the ball instead of just an absolute position was screwing up somehow when the ball only had velocity in the Z direction. But we got that fixed. Also, tried to help Joe debug the file input. It worked for about five minutes then it didnt anymore? He said it was a problem with Visual Studio but... I integrated the timer so that it wont run ridiculously fast in the lab and normal on my machine so now it should run normally on both. I also implemented a camera of sorts that can be controlled by using the 'w', 'a', 's', 'd' keys to either circle around the ball (a,d) or to move closer or furthrer away from it(w,s). It works ok for now but I think we will want to be able to just move in any direction so I need to figure out how to do that. So it looks like we should be good to go for the demo on thursday. Oh ya, response is working but the ball still sinks into the triangle once it's velocity gets small enough.

-- JonathanSamples - 30 Mar 2004

Adam and I created a cool sort of map for the ball world last night. It was all by hand so it took a while but it was cool and it will look good. We created a parabola shape using only the textfile input that joe made. We didnt make it in milkshpae we actually figured out every vertex and triangle by hand. I am pretty proud of it though. Today, I messed with cameras again. I just cant figure out a style that I like. I tried Z's class but I dont think its right. I also tried this one that found online but it doesnt use mouse input and the control style is only on the keyboard and is not very intuitive. Amidst my struggles with cameras I giving the ball an impulse. Since I am the camera man I decided to keep the camera's direction in order to know which direction to move the ball and this seems to work very well. When I give the ball an impulse it gets only the x and z component of the camera's direction and as of right now has not different magnitudes it is just 20 * the unit vector of the direction of the camera--its not quite right but at least we can move the ball around now.

-- JonathanSamples - 04 Apr 2004

Today I made camera a class. I fooled around with lots of different types of cameras: Free roaming ones, ones that focased on the ball and controled by the mouse and not controlled by the mouse. In the end I decided to go with the camera that Z implemented. It works good for this type of game. Where you want to be able to see a lot of angles but still have the ball right in front of you. I changed it though so that the center point is not the origin but is the center of the ball. I spent way too much time going back and forth on this camera issue. Today I also imported Z's club class and used the demo of the power bar to draw it. I only got a little rectangle to appear and had to go see Z to figure out how to animate it. I also spoke to her about how to make the club rotate around the ball according to the mouse's movement. She really struggled with the geometry and I realized that the angle that we needed was already in the camera class so if we used a function to get the x,z rotation angle we could just rotate the club by that much(converted to degrees of course) and sure enough it worked. For some reason we had to negate that angle though, Im not sure why.

-- JonathanSamples - 05 Apr 2004

Today I turned Camera and Club into singletons. It really cleaned up our main program file(OpenGL?). So now instead of all the extra crap that was in there concerning the camera's update. It is all now in the camera class and is not junking things up. I was thinking about making Room and Ball singletons but in our program there are too many things that get set on the fly to just have the singleton() function set it when it is called first so I just left them as globals. I know its bad style but we are running out of time and I dont want to have to redo a bunch of Code. Things are working right now and I dont want to break anything accedentally. Also, we are having weird behavior with VS. If we try to compile a release version of the Golf Game we get nullReferenceExceptions and the program crashes but if compiled under debug then it runs fine. Strange.

-- JonathanSamples - 06 Apr 2004

Today added comments to a bunch of files that I had written particularly Ball, Camera, and OpenGL?(h's and cpp's). I wanted to add a skybox but joe is worried that the project is already past due so we shouldnt add anything else. Oh well maybe I will add it and not submit it.

-- JonathanSamples - 07 Apr 2004