GTA-style drive module - need help!!

[Rocco]

i started to work on this module a few months ago, as the idea comes up in the coding competition thread,
but after the competiton was closed i left it alone.
now i want bring it to an acceptable state for release, but i have some problems,
cause i didnt have the mathe and physic knowledge to bring it to an good level.

the main problem is, that the choosen picture for the driving direction, dont fits 100%.
what makes the drive feeling a bit strange and unprecise.

here is the code for the pictureselection:

Code: ags

      // right picture in relation to angel calculated
      carview_winkel = (FloatToInt(winkel)%360);
      carview = FloatToInt( IntToFloat(carview_winkel)/rotate_value);
      if(carview < 0)	carview = carview + max_pics; 

rotate_value is this -> rotate_value = 360.0/IntToFloat(max_pics);

the second problem is the collision-handling.
in my dreams there is a handling code, which works good in every circumstance (corner, straight barriers)

the actual collision code (crap) is this:

Code: ags

  

// COLLISION
      if (Region.GetAtRoomXY(player.x, player.y) == region[2])  // kollision
      {

      posY = (posY * (-1.0));
      tempo = tempo/2.0;
        
      } 
      
      if (Region.GetAtRoomXY(player.x, player.y) == region[3])  // kollision
      {
      posX = (posX * (-1.0));
      tempo = tempo/2.0;
        
      } 

 

posX and posY is:

nWinkel = winkel*Maths.Pi/180.0;
       
posX = tempo*Maths.Cos(nWinkel);
posY = tempo*Maths.Sin(nWinkel);



here is the demo so far.
DOWNLOAD -> http://www.virtual-illusion.com/rocco/Drive_demo_alpha.zip

would be great if someone can help me out with this things 

[R4L]

This is fantastic!

The only help I can offer is some things I saw:

1) Sometimes when driving and turning into a collision detection zone, the car goes through it.

2) No reverse. Maybe this was intensional?

3) Sometimes when driving at an angle, the car seems to go in a slightly different direction. (You already addressed this but just letting you know. )

Im sorry I can't help you coding-wise. Its all maths to me and I don't quite understand it yet.

Good luck!

[Khris]

I had a go at this myself.
Here's the zip: DOWNLOAD (Esc to quit)

I'll polish it further and publish the source when I'm done.

[Rocco]

hey khrismuc wahnsinn, für was poste ich überhaupt Im hauptforum wenn ich nur dich fragen müsste. 

looks great, works perfect in all ways where my version is half-baked.
so I'm looking impatiently forward to the release.

[Rocco]

so i have also a new version here.
i fixed the mistake with the unprecise driving-angle, and implement an reverse gear.
and i use here the method from khrismuc,
to rotate and save the different carpics in the module only from one carpic,
instead of making 32 pics of the car and import this pics in the spritemanager.
with this method the user only have to import 1 pic.
but the problem then is the collision detection.

cause i attach the player to the car, and the problem is that the spot seems
to be in unpredictable positions, so i cant get the middlepoint of the pic,
and cant calculate the right length to the obstacles. (its very good to see, in the example)
EDIT: I found that bug, it was my fault, will be fixed in the next version


here is the demo new experiment so far.
DOWNLOAD -> http://www.virtual-illusion.com/rocco/Drive_module_a1.zip

[Shane 'ProgZmax' Stevens]

One way to handle the collisions would to be to use the pixel perfect collision module and turn the different collision items into separate maps (or just one) and import as an object or group of objects.  Then in the room repeatedly_execute script you could check once per loop to see if the player and opponents hit a stop barrier and act accordingly.  Unless the maps are impossibly large I don't foresee any slowdown, so it's one easy way to get it done if you're struggling.

Another way would be to use regions or hotspots for the collision areas and use the getregionat/gethotspotat functions (factoring in the car velocity) and act accordingly.  I'm guessing that Khrismuc's version already uses one of these methods. 

[Khris]

Yeah, I'm using regions.

To prevent the game from too much slowdown I check some reference points along the sprites border (the front bumper, to be specific).

A problem I wasn't able to solve yet is perfecting the collision detection. I looks convincing enough, but in theory, the car shouldn't be able to penetrate the region at all.
This requires the game to not move the car s pixels per frame but 1 pixel every t frames.

My car is 40 pixels long, so 1m = 10px.
A normal speed like 16m/s (~ 58km/h) = 160px/s = 160px/40f = 4px/f.
So even at a "slow" speed like that, I'd need four times the current frame rate.
Setting the game speed to 160 didn't help at all, the game ran even slower.

** half an hour later:
I played around some more.
Regardless of the game speed setting, the fps count won't go above 100.
So instead of putting a Wait() in rep_ex, I've implemented the delay using a while loop.
The speed is split up in its x and y components, both of them get reduced so the bigger one is 1.0 (to ensure the CD working properly), the factor is then used to slow the game down to keep the car's speed constant.

While this works fine, the slowdown is considerable.

In essence: Perfect CD -> sprite can't move more than 1.0 pixels / frame -> top speed = 100px/s
Bah.

[GarageGothic]

What if you handle all the collision detection one frame early? Since you already know the position, the speed and direction it should be perfectly possible to calculate for the following frame (of course the player may change these, but I doubt that one frame's difference will make the steering feel sluggish).

[Khris]

Well, imagine the car going at 10px per frame. It would look weird if the car crashed into a wall while still being 7 or 8 pixels away from it.

I managed to work around this, though. Rep_ex is called once per frame, so I changed the functions name, put a call to it inside an endless while loop and call Wait(1); every 4 iterations to update the screen. This works fine although the scrolling isn't as smooth as before.

Btw, I've replaced the original sprite with one that has borders that put the rear axle in the sprite's center. Turning the car looks a lot more realistic now.

[GarageGothic]

Well, imagine the car going at 10px per frame. It would look weird if the car crashed into a wall while still being 7 or 8 pixels away from it.

No, what I meant was that you handle the collision detection the frame before before, and the next frame, instead of moving the car into the wall you can stop it at the edge. But I miscalculated thinking that collision detection was handled purely geometrically and that the car was RawDrawn - I can now see from the previous posts that you're using a character for the car and regions for the collision areas. Still, it should be perfectly possible to bump the car out of the collision area within the same frame that it enters it, so the player never sees what's going on. Just add a while loop moving it backwards one pixel at a time until it no longer collides with the area.

I would be very careful with setting the game speed to 100 as a workaround - a lot of machines won't be able to handle framerates like this and the game will run horribly slow for them (like the original GTA on my 66MHz 486 machine).

[Rocco]

i guess the best solution would be to calculate the vector of the obstacles impact point, and bounce the car off in the right angle, instead of stopping it.
but i dont know, how to get an vector from a regionborder.