Hello !
Trace: • Racing game • Challenges of Autonomous Cars • projectinformation • Buzzer module • Architektur • Indoor Mobile Robot • Course title: A Comprehensive Course for Drone Operators • Hardware and Sensing Technologies • Microcontroladores e Robótica • high_level_communication

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
en:projects:racing_game [2010/06/13 21:03] – mikk.leinien:projects:racing_game [2020/07/20 09:00] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== Racing game ====== ====== Racing game ======
 +
 +Platform: ARM-CAN kit
  
 [{{  :images:projects:racing_game:userinterface_module.jpg?220|}}] [{{  :images:projects:racing_game:userinterface_module.jpg?220|}}]
Line 105: Line 107:
  
 But there are problems - these rectangles are not connected like a racing track might be. Too understand it, take a look at the blue and green rectangle on the picture. Firstly, there is a gap on the outer side of corner, secondly the rectangles intersect in the inner corner. Intersection point of two rectangles is solved in //GetLinesIntersectionPoint// function. To speed up drawing the track, it is converted from sections to two polygons which define inner and outer edges of the track. So the intersection point replaces corner points of intersecting rectangles and gap is filled by simply drawing a line between two consecutive edges. But there are problems - these rectangles are not connected like a racing track might be. Too understand it, take a look at the blue and green rectangle on the picture. Firstly, there is a gap on the outer side of corner, secondly the rectangles intersect in the inner corner. Intersection point of two rectangles is solved in //GetLinesIntersectionPoint// function. To speed up drawing the track, it is converted from sections to two polygons which define inner and outer edges of the track. So the intersection point replaces corner points of intersecting rectangles and gap is filled by simply drawing a line between two consecutive edges.
 +
 +The rendering of the track in //TrackRender// function is rather trivial. As the track is defined by inner and outer edge, polygon drawing functions are used to first fill the area inside the outer edge and then inside the inner edge.
 +
 +Because it is not an offroad racing game, some collision detection is needed to check if the car is on the road or not. This check is achieved with the help of //PointInPolygon// function which contains an clever algorithm proposed by Bob Stein. The collision detection function //TrackPointOnTrack// returns true when the point is in the outer edges polygon but not in the inner edges polygon.
  
 <code c> <code c>
Line 119: Line 125:
 ===== Rendering car ===== ===== Rendering car =====
  
-===== Main program =====+The car in the game is also made up of polygons. It has a rectangular body and roof polygon, plus two circles as headlights. As the viewpoint do not rotate, the car has to rotate to give the right visual effect. Rotating means trigometric functions and it is most easily achieved by converting polar coordinates to Cartesian coordinates. That is why the points of the car are defined by radius and angle as seen below.
  
-The main function resides in "racing_game.c". +<code c> 
 +    tPolarPoint pBodyPoints[4]; 
 + 
 +    pBodyPoints[0].sRadius = 200; 
 +    pBodyPoints[0].ulAngle = DEGREES_TO_FIX32(330); 
 + 
 +    pBodyPoints[1].sRadius = 200; 
 +    pBodyPoints[1].ulAngle = DEGREES_TO_FIX32(30); 
 + 
 +    pBodyPoints[2].sRadius = 200; 
 +    pBodyPoints[2].ulAngle = DEGREES_TO_FIX32(150); 
 + 
 +    pBodyPoints[3].sRadius = 200; 
 +    pBodyPoints[3].ulAngle = DEGREES_TO_FIX32(210); 
 +</code> 
 + 
 +All the points of the body parts are converted to x, y coordinates in //CalculateScreenPoint// function. Both the coordinate system conversion and world to screen point conversion take place there. Rendering is done in //CarRender// function by polygon filling routines. 
 + 
 +<code c> 
 +void CalculateScreenPoint(tPoint *pScreenPoint, tPolarPoint *pLocalPoint, 
 +                         tPoint *pPosition, unsigned long ulAngle); 
 +void CarRender(tContext *pContext, tCar *pCar); 
 +</code> 
 + 
 +===== Main program =====
  
 [{{  :images:projects:racing_game:screenshot.jpg?220|Screenshot from game}}] [{{  :images:projects:racing_game:screenshot.jpg?220|Screenshot from game}}]
 +
 +The main function resides in "racing_game.c". That is the function which initializes all the peripheral devices, calls preparation functions and starts the main loop. The loop contains only few lines of code: joystick handling, car dynamics calculation and rendering. Joystick handling is very easy because of the joystick driver - it just gives x and y coordinate. The joystick x coordinate is used to steer the car and y coordinate to apply driving power. Actually the formulas of simulating the movement of the car are quite tawdry, because they do not take any of the physical laws into account. All the movement is done in a similar manner to as converting polar coordinates to Cartesian ones with different limitations of maximum speed on the road and off the road.
  
 <code c> <code c>
Line 129: Line 161:
 void DoCarDriving(tCar *pCar); void DoCarDriving(tCar *pCar);
 void PrepareCar(void); void PrepareCar(void);
-</code> 
- 
-<code c> 
-void GrPolyDraw(const tContext *pContext, const tPoint *pPoints,  
-           unsigned long ulNumPoints, unsigned char ucClosedLoop); 
-void GrPolyFill(const tContext *pContext, const tPoint *pPoints,  
-           unsigned long ulNumPoints); 
 </code> </code>
  
en/projects/racing_game.1276462989.txt.gz · Last modified: 2020/07/20 09:00 (external edit)
CC Attribution-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0