I have merged my OpenGL branch with my mainline work and I'm beginning to work on level creation, based on simple python scripts.
Current work basically loads the python script and gives a custom environment to access needed carcode functionality, which roughly includes adding entities to Arena, basic prebuild entities and OpenGL functions to create your own entities.
Next steps to improve general usability of level loading should be documenting rendering API, which functions needs to be implemented by and object to implement drawing, collision detection and event handling.
I'm currently using Sphinx to generate documentation from RST files, this system is used for the official python documentation.
sábado, 17 de mayo de 2008
lunes, 12 de mayo de 2008
Collision Detection
Collision can be done in several ways, the most usual being by the use of Bounding Boxes, in this case, a rectangle that more or less covers the area of our object, this can be done in several ways and it is very easy to implement, however, for carcode I stepped this up to something more generic with a given set of vectors, which should be very similar to 3D Bounding Box collision detection, but 2D, I had to workout my rusty math skills but I came up with a nice and general way.
At first I tough of making assumptions such as that the box was actually a rectangle, however this isn't generic enough, I could want to have a non rectangle quadrilateral or even define an area with more than 4 vectors, the answer was "triangles", you can basically divide any "regular" polygon defined by n vectors in triangles, and thus began my quest for collision detection inside a triangle.
By using a vector as the basic unit for collision detection (a vector inside a given area) it should be generic enough for "collisioning" two different polygons, the basics of this is to pick 3 vectors for the triangle, noted by v1, v2, v3, translate the figure to Origin by using v1 as base, now we calculate the angle between v1 and v3, and rotate so V3y will be exactly 0 (on the X axis), we do the same to the vector we want to collision test (Vc), now with Vcy we calculate the distances in the X axis of a pair of vectors that delimits the triangle on Y - Vcy, this is basically done by using the angle alpha1 (angle of V1) and alpha2 (angle of V3).
X1 = tan(90 - alpha1) * Vcy
X2 = tan(90 - alpha2) * Vcy
We do a substraction, X2 - X1, if the result is negative basically means that Vc is outside the triangle (in Y), you could also check this by using V2y, now we test if: (V3x - X2) > Vcx > X1, in case of being true it means that the vector is inside the V1,V2,V3 delimited area (in X).
Doing all this for every frame could be time consuming, but we can pre-calculate a lot of things such as dX and dY from the translations and rotations, then tan(90-alpha), which will basically reduce the whole algorithm to a pair of additions, two multiplications and tree comparisons, in the optimal case (the area is not moving, and we use V2y for Y test).
That is the basics, but even then I'm making some assumptions, I will try to prototype some code and do the necessary refinements. Hopefully I will have some time next week after the Pharmacology (this Friday) exam and the Physiology exam (next Tuesday), which obviously pharmacology is way way bigger than physiology.
At first I tough of making assumptions such as that the box was actually a rectangle, however this isn't generic enough, I could want to have a non rectangle quadrilateral or even define an area with more than 4 vectors, the answer was "triangles", you can basically divide any "regular" polygon defined by n vectors in triangles, and thus began my quest for collision detection inside a triangle.
By using a vector as the basic unit for collision detection (a vector inside a given area) it should be generic enough for "collisioning" two different polygons, the basics of this is to pick 3 vectors for the triangle, noted by v1, v2, v3, translate the figure to Origin by using v1 as base, now we calculate the angle between v1 and v3, and rotate so V3y will be exactly 0 (on the X axis), we do the same to the vector we want to collision test (Vc), now with Vcy we calculate the distances in the X axis of a pair of vectors that delimits the triangle on Y - Vcy, this is basically done by using the angle alpha1 (angle of V1) and alpha2 (angle of V3).
X1 = tan(90 - alpha1) * Vcy
X2 = tan(90 - alpha2) * Vcy
We do a substraction, X2 - X1, if the result is negative basically means that Vc is outside the triangle (in Y), you could also check this by using V2y, now we test if: (V3x - X2) > Vcx > X1, in case of being true it means that the vector is inside the V1,V2,V3 delimited area (in X).
Doing all this for every frame could be time consuming, but we can pre-calculate a lot of things such as dX and dY from the translations and rotations, then tan(90-alpha), which will basically reduce the whole algorithm to a pair of additions, two multiplications and tree comparisons, in the optimal case (the area is not moving, and we use V2y for Y test).
That is the basics, but even then I'm making some assumptions, I will try to prototype some code and do the necessary refinements. Hopefully I will have some time next week after the Pharmacology (this Friday) exam and the Physiology exam (next Tuesday), which obviously pharmacology is way way bigger than physiology.
viernes, 9 de mayo de 2008
Prototyping
I have been very busy with school this last days, but this weekend I have some free time to keep working on Carcode, today I'm working on my OpenGL branch, currently I have the old car ported to new rendering (using glRecti), I tried with textures but admittedly I'm not very good at graphics so we'll keep the plain rectangle for now.
Added some framerate controlling code which yields a pretty and smooth animation, with current code we can have a world as big as we want, I already added a new object, the Road class which draws a simple road, which is currently just for test purposes.
The next thing on the list is to document the API for creating drawable objects, which mostly comprise of implementing the update and draw function, then layout the specs for collision detection and scripting.
Talking about scripting, I'm looking at two approaches to it, one would be have a function on the scripted object which may modify its behavior or internal data like "update", this could be nicely integrated with the current mainloop, however, it could be limiting for the car scripts, for example, for loops would not be very useful for things like moving the car, as updating and drawing of the car will only occur after execution, which means that in order to move the car to a desired place you cannot just loop and wait, however, given the nature of the car control (by acceleration and direction angle) I don't think this could be a problem, we should however stop comparing carcode with LOGO, as dynamics of carcode are very different.
The other approach to scripting could be threading, with this we could have non-blocking loops inside scripts, however, this could cause a nightmare of possible synchronization issues if not done right, it is possible that it would be more work implementing it than is worth, we could probably use yield and have some code checking if the script returns an iterator and keep executing the iterator each frame.
A snapshot of my opengl branch is available at http://cdrv.centralnogales.com/carcode-opengl.zip
Added some framerate controlling code which yields a pretty and smooth animation, with current code we can have a world as big as we want, I already added a new object, the Road class which draws a simple road, which is currently just for test purposes.
The next thing on the list is to document the API for creating drawable objects, which mostly comprise of implementing the update and draw function, then layout the specs for collision detection and scripting.
Talking about scripting, I'm looking at two approaches to it, one would be have a function on the scripted object which may modify its behavior or internal data like "update", this could be nicely integrated with the current mainloop, however, it could be limiting for the car scripts, for example, for loops would not be very useful for things like moving the car, as updating and drawing of the car will only occur after execution, which means that in order to move the car to a desired place you cannot just loop and wait, however, given the nature of the car control (by acceleration and direction angle) I don't think this could be a problem, we should however stop comparing carcode with LOGO, as dynamics of carcode are very different.
The other approach to scripting could be threading, with this we could have non-blocking loops inside scripts, however, this could cause a nightmare of possible synchronization issues if not done right, it is possible that it would be more work implementing it than is worth, we could probably use yield and have some code checking if the script returns an iterator and keep executing the iterator each frame.
A snapshot of my opengl branch is available at http://cdrv.centralnogales.com/carcode-opengl.zip
Suscribirse a:
Entradas (Atom)