Re: Sim racing and money.

For the most part this is very true. Alot can be gained from a very smooth and constant frame rates. One glaring exception to this is the DTR/DTRSC games. When playing online the slower computer you have the faster you will be. To put this to the test a friend of mine took DTR and ran it on a less than recommended spec system and he was beating Late Models with a pro stock with minimal setup tuning. I talked to one of the programmers involved with the game and he told me that the physics updates were keyed into the frame rate. He also thought that should help a faster machine be more controllable. I don't know if most games tie their physics updates to the frame rate or not, but if they do I can see why one system may "drive" totally different than another MadDAWG Richard S Beckett <[email hidden]> wrote in message news:9clrpt$[email hidden]... > x-no-archive: yes > > One of the annoying things about real racing is how well a person whothrows > lots of money at it does compared to a better driver with less money. > > Well, it looks like sim racing is even simulating that part of racing,too. > > Since my upgrade, I've only been playing GPL, for obvious reasons - butlast > night I decided to give some older games a blast. > > I couldn't belieeeeve the difference to CMR1. > > On the highest level, I was really struggling to win a rally with myK6-200

Quoted text (12 lines)

> and voodoo1 card. Now with my Duron 750 128Mb and GF2 MMX, I was suddenly > winning stages by 12 seconds. > > TWELVE seconds!!! > > T W E L V E seconds!!!! > > That was with me driving in light-relief-have-a-blast mode, without even > bothering to change the default setups!! > > The car seemed to handle much more naturally, and everything was > instinctive. I made very few mistakes, and was able to throw the car

around > like it was a part of me. I suddenly realised how badly it had beenrunning

Quoted text (8 lines)

> before, and that the game is actually much better than I realised when you > have the power to run it properly. > > Computing power is everything. > > This leads me to make a point, that maybe people who slag off certain sims > as crap have either not got the power to run it properly, or haven't > optimised the sim to their system, and are running it with too much

detail. > > R. > >

On Tue, 1 May 2001 12:12:56 -0400, "MadDAWG" <[email hidden]> wrote: ... >with minimal setup tuning. I talked to one of the programmers involved with >the game and he told me that the physics updates were keyed into the frame >rate. Ah! Heresy! (a hype term right now) I hope he was talking about controller updates. I won't accept physics updates tied to the framerate anymore. It's like getting slomo or fastmo when your machine is slow or fast. Unnecessary and not difficult to get done. > He also thought that should help a faster machine be more >controllable. I don't know if most games tie their physics updates to the >frame rate or not, but if they do I can see why one system may "drive" >totally different than another I think most games tie their physics to an internal frequency; GPL uses 288Hz for example. Controller updates are another issue. GPL ties that to the framerate (it seems). Don't know about other games. I do (but I'm not proud of that). Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

Quoted text (31 lines)

>Well, it looks like sim racing is even simulating that part of racing, too. > >Since my upgrade, I've only been playing GPL, for obvious reasons - but last >night I decided to give some older games a blast. > >I couldn't belieeeeve the difference to CMR1. > >On the highest level, I was really struggling to win a rally with my K6-200 >and voodoo1 card. Now with my Duron 750 128Mb and GF2 MMX, I was suddenly >winning stages by 12 seconds. > >TWELVE seconds!!! > >T W E L V E seconds!!!! > >That was with me driving in light-relief-have-a-blast mode, without even >bothering to change the default setups!! > >The car seemed to handle much more naturally, and everything was >instinctive. I made very few mistakes, and was able to throw the car around >like it was a part of me. I suddenly realised how badly it had been running >before, and that the game is actually much better than I realised when you >have the power to run it properly. > >Computing power is everything. > >This leads me to make a point, that maybe people who slag off certain sims >as crap have either not got the power to run it properly, or haven't >optimised the sim to their system, and are running it with too much detail. > >R.

I still think it's more skill/dedication/driver/whatever than computing power, even though more power does help. I got a 1:30.xx lap at Monza on this system using the default Lotus with a light fuel load: 60 Mhz Pentium 32 Mg Ram 320x200 resolution No 3-D card Running the least graphics possible, I got a frame rate of between 2 and 3. I'll admit, the time scale slowed down to 50% of normal, but still..... There are folks that can't get that running 20fps and saying others do it because of their awesome systems. BS :-) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

Maybe the fact that you have only been playing GPL has made you a better drive...when you first played GPL, Id bet you weren't very fast and had trouble controlling the car...but now it seems easy...so you go play a game that you played when your driving skills were at pre-GPL level, and compare the times...I doubt the speed of your computer gave you the 12 seconds...I think you have just become a better driver. JB "Richard S Beckett" <[email hidden]> wrote in message news:9clrpt$[email hidden]... > x-no-archive: yes > > One of the annoying things about real racing is how well a person whothrows > lots of money at it does compared to a better driver with less money. > > Well, it looks like sim racing is even simulating that part of racing,too. > > Since my upgrade, I've only been playing GPL, for obvious reasons - butlast > night I decided to give some older games a blast. > > I couldn't belieeeeve the difference to CMR1. > > On the highest level, I was really struggling to win a rally with myK6-200

Quoted text (12 lines)

> and voodoo1 card. Now with my Duron 750 128Mb and GF2 MMX, I was suddenly > winning stages by 12 seconds. > > TWELVE seconds!!! > > T W E L V E seconds!!!! > > That was with me driving in light-relief-have-a-blast mode, without even > bothering to change the default setups!! > > The car seemed to handle much more naturally, and everything was > instinctive. I made very few mistakes, and was able to throw the car

around > like it was a part of me. I suddenly realised how badly it had beenrunning

Quoted text (8 lines)

> before, and that the game is actually much better than I realised when you > have the power to run it properly. > > Computing power is everything. > > This leads me to make a point, that maybe people who slag off certain sims > as crap have either not got the power to run it properly, or haven't > optimised the sim to their system, and are running it with too much

detail. > > R. > >

On 01 May 2001 22:20:56 GMT, [email hidden] (J. Todd Wasson) wrote: ... >>Computing power is everything....

Quoted text (8 lines)

> I still think it's more skill/dedication/driver/whatever than computing >power, even though more power does help. I got a 1:30.xx lap at Monza on this >system using the default Lotus with a light fuel load: > > 60 Mhz Pentium > 32 Mg Ram > 320x200 resolution > No 3-D card

Lol, Todd, your next investment should really be a decent 3D card. Pick an old one, a 2nd hand one, all is better than nothing, but make sure it supports OpenGL so you can enjoy a bit of Racer. ;-) Really, it's the best gift you can give yourself; really inspires you to get some graphics going, the speed at which these things are running now. Painting the entire Carrera track in a bird's eye view runs at >100fps on my Geforce2MX/PII400. It's real fun. :) But congratulations on the 1:30 lap, might good under such poor circumstances. :) Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

"Ruud van Gaal" <[email hidden]> wrote in message news:[email hidden]... > On 01 May 2001 22:20:56 GMT, [email hidden] (J. Todd Wasson) wrote: > Lol, Todd, your next investment should really be a decent 3D card. > Pick an old one, a 2nd hand one, all is better than nothing, but make I have to say, back when I played a lot of Quakeworld Team Fortress, I played using a 16mb Cyrix 200 with 1mb S3 trio graphics and I was happy with the framerate (about 15fps I think). When I "upgraded" to an Orchid Righteous Voodoo card, I found that due to the minimum resolution being 512x386, rather than the 320x200 I had been playing on, the frame rate actually worsened. Even though it did look a bit prettier (<10fps). I've also experienced the DTR go faster "bug" online- I thought it was a glide/d3d issue at the time. I know the auto-combat game, Interstate 76 suffers from framrate related physics- the faster your framerate, the shorter your mortars fly (ouch). In GPL, I've found corners I'd be happy with offline, with a 25+ fps, turn into complete nightmares at <18fps. Probably due to fewer controller inputs than bizarre physics anomolies though. cheers John

>> 60 Mhz Pentium >> 32 Mg Ram >> 320x200 resolution >> No 3-D card > >Lol, Todd, your next investment should really be a decent 3D card. Actually, I've got a P-400 Laptop with a card, but can't plug my wheel into it. Sure looks a lot better than the P-60 though! Managed a 1:25.33 at Kyalami with the keyboard. Gotta really mess with the setup to do even half way decent. 30/30 rear end makes a big difference, then play with the shocks to get rid of any wobble, etc.. When I've got the cash laying around, I think I'll pick up a newer system out of the classifieds. There're some fantastic deals out there. I'm looking forward to playing Racer someday :-) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

"Ruud van Gaal" <[email hidden]> wrote in message news:[email hidden]... > On Tue, 1 May 2001 12:12:56 -0400, "MadDAWG" <[email hidden]> > wrote: > > ... > >with minimal setup tuning. I talked to one of the programmers involvedwith > >the game and he told me that the physics updates were keyed into theframe

Quoted text (18 lines)

> >rate. > > Ah! Heresy! (a hype term right now) > I hope he was talking about controller updates. I won't accept physics > updates tied to the framerate anymore. > It's like getting slomo or fastmo when your machine is slow or fast. > Unnecessary and not difficult to get done. > > > He also thought that should help a faster machine be more > >controllable. I don't know if most games tie their physics updates to the > >frame rate or not, but if they do I can see why one system may "drive" > >totally different than another > > I think most games tie their physics to an internal frequency; GPL > uses 288Hz for example. Controller updates are another issue. GPL ties > that to the framerate (it seems). Don't know about other games. I do > (but I'm not proud of that). >

I think GPL tries to go with 288Hz, but since it is run on a Microsoft OS it's possible for the system to be busy and not get back to GPL in time to maintain a constant 288Hz. Enough skipped cycles and you've got a clock smash.

On 02 May 2001 21:15:29 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (9 lines)

>>> 60 Mhz Pentium >>> 32 Mg Ram >>> 320x200 resolution >>> No 3-D card >> >>Lol, Todd, your next investment should really be a decent 3D card. > > Actually, I've got a P-400 Laptop with a card, but can't plug my wheel into >it.

Ouch, a shame. > Sure looks a lot better than the P-60 though! Managed a 1:25.33 at >Kyalami with the keyboard. Gotta really mess with the setup to do even half >way decent. 30/30 rear end makes a big difference, then play with the shocks >to get rid of any wobble, etc.. Geez, I'm not a good setupper. But that helps me avoid complaints about my physics system I guess. > When I've got the cash laying around, I think I'll pick up a newer system out >of the classifieds. There're some fantastic deals out there. > > I'm looking forward to playing Racer someday :-) Make sure you get FF and a good (nVidia) card; I've now got 2 cars on the track but it's slowing down on the SGIs, damn. :( If those maniacs get off my back having me work overtime I'd be able to finish up a new version (but yikes, the braking twitchyness is back now that differential code is in)... :) Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

>I think GPL tries to go with 288Hz, but since it is run on a Microsoft OS >it's possible for the system to be busy and not get back to GPL in time to >maintain a constant 288Hz. Enough skipped cycles and you've got a clock >smash. > I think it might really be constant at 288Hz, or at least in simulation time it appears to remain this way. When running GPL on my old Pentium 60Mhz, the frame rate was down around 2 or 3 fps, and the "sim time" was perhaps 1/2 real time. Plus, I could make a lot of steering and throttle adjustments in between frames and it seemed to "read" them all and react about the same way. I could be wrong though... Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

Quoted text (13 lines)

>Make sure you get FF and a good (nVidia) card; I've now got 2 cars on >the track but it's slowing down on the SGIs, damn. :( >If those maniacs get off my back having me work overtime I'd be able >to finish up a new version (but yikes, the braking twitchyness is back >now that differential code is in)... :) > > >Ruud van Gaal, GPL Rank +53.25 >Pencil art : http://www.marketgraph.nl/gallery/ >Free car sim : http://www.marketgraph.nl/gallery/racer/ > > >

Isolate the tire rotation frequency from the rest of the system and step it up about 10 times. It'll fix it :-) I've got a SuperSport (?) 2 wheel, I think, no FF. I think I just need a USB converter (is that it?) to go from the old Soundblaster joystick port into the laptop port. Then I'd be able to race. Then I'd get no work done at all :-) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

On 03 May 2001 21:46:43 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (8 lines)

>>Make sure you get FF and a good (nVidia) card; I've now got 2 cars on >>the track but it's slowing down on the SGIs, damn. :( >>If those maniacs get off my back having me work overtime I'd be able >>to finish up a new version (but yikes, the braking twitchyness is back >>now that differential code is in)... :) > > Isolate the tire rotation frequency from the rest of the system and step it >up about 10 times. It'll fix it :-)

Hm, I doubt it somewhere; it worked nice before. When I brake 100%, it starts rotating slowly, as it did a long time before. But no worries, I haven't checked why my rotation halt doesn't work anymore, so it might be a little thing. Anything to avoid decadupling my frequencies! :) I had a thought the other day about the problem btw; what if: - You calculate a Fx=100N for example - The road reaction force is 10N, for example. - At a timestep of 0.01s you would get a certain rotation speed - Before moving on, calculate what the road reaction force will be when running at that new rotation speed - Magically 'combine' the current and future road reaction force to come up with a more accurate Fx=... The problem is in experimenting with the combine. You might find for example that the future rotation speed leads to a Fr=200N, which means the 100N Fx would never get it at that speed. So, for example, you'll just take half of the force if you notice you're going somewhere that will not be possible. Ok, very vague. The idea is to use steady state solutions (in the present and the future) to check whether your integration step will go out of line. It might as well be worthless. ;-) >I've got a SuperSport (?) 2 wheel, I think, no FF. I think I just need a USB >converter (is that it?) to go from the old Soundblaster joystick port into the >laptop port. Then I'd be able to race. Then I'd get no work done at all :-) Yes, I believe that's it; from joystick port to USB. But make sure you test it first. ;-) The MSFF wheel for example just sends digital bytes along at MIDI speed, instead of the old 'clear the pot; while(pot<magic)wait' joystick routines. In other words, gameports are not always *compatible* gameports. Cheers, Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

On 03 May 2001 21:42:21 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (10 lines)

>>I think GPL tries to go with 288Hz, but since it is run on a Microsoft OS >>it's possible for the system to be busy and not get back to GPL in time to >>maintain a constant 288Hz. Enough skipped cycles and you've got a clock >>smash. > > I think it might really be constant at 288Hz, or at least in simulation time >it appears to remain this way. When running GPL on my old Pentium 60Mhz, the >frame rate was down around 2 or 3 fps, and the "sim time" was perhaps 1/2 real >time. Plus, I could make a lot of steering and throttle adjustments in between >frames and it seemed to "read" them all and react about the same way.

Hm, could be yes, if at 2fps you still get some response. The question then is, at which frequency is the control update running in GPL? Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

Quoted text (20 lines)

>> I think it might really be constant at 288Hz, or at least in simulation >time >>it appears to remain this way. When running GPL on my old Pentium 60Mhz, >the >>frame rate was down around 2 or 3 fps, and the "sim time" was perhaps 1/2 >real >>time. Plus, I could make a lot of steering and throttle adjustments in >between >>frames and it seemed to "read" them all and react about the same way. > >Hm, could be yes, if at 2fps you still get some response. The question >then is, at which frequency is the control update running in GPL? > > >Ruud van Gaal, GPL Rank +53.25 >Pencil art : http://www.marketgraph.nl/gallery/ >Free car sim : http://www.marketgraph.nl/gallery/racer/ > > >

Who knows? :-) Do you run controls through %WM_TIMER? Or does DirectInput do things differently? Either way, I'd guess it's a set frequency in "sim time", but nothing goes faster than 288Hz real time. Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

Quoted text (9 lines)

>> Isolate the tire rotation frequency from the rest of the system and step >it >>up about 10 times. It'll fix it :-) > >Hm, I doubt it somewhere; it worked nice before. When I brake 100%, it >starts rotating slowly, as it did a long time before. But no worries, >I haven't checked why my rotation halt doesn't work anymore, so it >might be a little thing. Anything to avoid decadupling my frequencies! >:)

That's odd. Does it happen when the steering is perfectly straight or only when it's turned? I have a similar problem where the longitudinal force under max braking causes a yaw torque when the wheel is turned, even when the wheel locks, because the longitudinal force is in the tire plane. Probably a good argument there for Gregor's slip vector usage :-) Seems a "correct" Pacejka model would take care of this automatically though, since the combined lateral and longitudinal effects are included. Maybe your rotation halt stopped working when you switched to quarternions.

Quoted text (14 lines)

>I had a thought the other day about the problem btw; what if: >- You calculate a Fx=100N for example >- The road reaction force is 10N, for example. >- At a timestep of 0.01s you would get a certain rotation speed >- Before moving on, calculate what the road reaction force will be >when running at that new rotation speed >- Magically 'combine' the current and future road reaction force to >come up with a more accurate Fx=... > >The problem is in experimenting with the combine. You might find for >example that the future rotation speed leads to a Fr=200N, which means >the 100N Fx would never get it at that speed. >So, for example, you'll just take half of the force if you notice >you're going somewhere that will not be possible.

I tried something like this a few months ago. I forget exactly, but I think it worked pretty well actually, only it worked in reverse. I think the new slip ratio was the new calculated slip ratio averaged with the last five or six slip ratios, with the new slip ratio multiplied into the average a few times, or something like that. Seemed to smoothen it out a bit, but don't remember for sure. Actually, I think I dumped it once I split the frequencies. Something like: NewSlipRatio = ((OldSlipRatio1 * 10)+ OldSlipRatio2 + OldSlipRatio3 + OldSlipRatio4) / 14 I know you hate the idea of splitting the frequencies, but your example above is really what the split frequencies seem to accomplish by anticipating excessively large slip ratios and preventing them from effecting the car's movement. The car moves .003 seconds worth, then wheel rotation and new slip ratio for something like .00001 seconds advancement is calculated, then again and again, etc.. The slip ratio eventually overshoots where it should be, but by far less than it would if it was using the same frequency as the rest of the car, especially when there's a sudden, huge change in wheel torque. Besides, if there are enough cycles and a little damping (I don't use any, but calculating critical damping every .003 seconds as the tire load changes and applying it would be a good idea, probably letting one cut down the frequency a bit), slip ratio will swing back and forth, eventually settling at the "correct" slip ratio. If the wheel torque isn't big, it'll slowly climb to about the value the .003 timestep model would produce, so it doesn't mess anything up. Anyway, then I move the car with this final slip ratio->torque value. It really doesn't cost much in CPU power, but it is a pain to go through the code and try to cut it up like that, as you can imagine. I'm glad I did though :-) Even with a full size car, when I draw the longitudinal force vectors in realtime 3-D at the tires, they are a little bit jumpy at only 300Hz. This effects the handling. Crank it up to 3000Hz or more and they're so smooth you can't see a change. Just a thought, I know it would hurt to do though :-) I'm intrigued by your idea too, however. Will give it some thought and maybe come back to you on it. lol. This is the "Sim racing and money" thread!

Quoted text (13 lines)

>>I've got a SuperSport (?) 2 wheel, I think, no FF. I think I just need a >USB >>converter (is that it?) to go from the old Soundblaster joystick port into >the >>laptop port. Then I'd be able to race. Then I'd get no work done at all >:-) > >Yes, I believe that's it; from joystick port to USB. But make sure you >test it first. ;-) The MSFF wheel for example just sends digital bytes >along at MIDI speed, instead of the old 'clear the pot; >while(pot<magic)wait' joystick routines. >In other words, gameports are not always *compatible* gameports. >

Ok, I'll have to ask the salesperson. Thanks :-) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

"J. Todd Wasson" <[email hidden]> wrote in message news:[email hidden]... > >I think GPL tries to go with 288Hz, but since it is run on a Microsoft OS > >it's possible for the system to be busy and not get back to GPL in timeto > >maintain a constant 288Hz. Enough skipped cycles and you've got a clock > >smash. > > > > > I think it might really be constant at 288Hz, or at least in simulationtime > it appears to remain this way. When running GPL on my old Pentium 60Mhz,the > frame rate was down around 2 or 3 fps, and the "sim time" was perhaps 1/2real > time. Plus, I could make a lot of steering and throttle adjustments inbetween > frames and it seemed to "read" them all and react about the same way. > > I could be wrong though... > Todd Wasson > The physics rate is disconnected from the frame rate, but not locked at 288hz. Based on your 1/2 real time comment, it appears that on the system described was achieving approximately 144hz.

>The physics rate is disconnected from the frame rate, but not locked at >288hz. Based on your 1/2 real time comment, it appears that on the system >described was achieving approximately 144hz. > What I'm referring to is the integration time step the simulation is using for its motion calculations, i.e., simulated time, not "real measured time". The amount of time it actually takes to do the physics calculations is far, far less than 1/288th of a second per cycle, even on my P-60, which is about as fast as a stampede of turtles crawling through peanut butter, if you'll pardon the expression :-P Games will run through their physics code to cover movement for one graphics frame very quickly, then spend the majority of the rest of the time drawing graphics. If you ran GPL at 30 fps, which you'd probably agree is more than fast enough to run 288hz physics, the physics loop would move the car about .00347 "simulated" seconds at a time, recalculate, do it again, etc., about nine or ten times between graphics frames. If the frame rate changes to half this value, the .00347 "simulated" time step remains the same (1/.00347 = 288Hz) , while it now might loop through the physics code twice as many times as before in between graphics frames. In other words, the car is still moving .00347 seconds at a time according to the calculations, but you won't see it all unless your frame rate is 288 or better. If that's how GPL does it, I'd say the physics is "locked to 288Hz" as they claim (probably true). If you wanted to look at this in terms of real time frequency of the physics calculations, please note that the physics loop probably takes up less than 5% of this 30 frames per second. So to equate this to real time Hz, GPL's physics would run at 5760 Hz when the frame rate is 30. The rest of the time, it's drawing graphics or doing other things. Mine ran at half speed, so it might have really running at around 2880Hz, if you wanted to compare it that way. Either way, just because my frame rate was horrible, doesn't mean my P-60 wasn't running the physics at only 144Hz. My point is, the "simulated time step" is locked, even if it takes my ancient machinery a day to crank out one second worth of driving time. If the time step it was making during calculations was 1/288th of a second each (even though it took a few seconds to make the calculations for that 1/288th of a second), the physics system is still locked to 288Hz, in other words, the integration time step the motion equations were using was .00347 seconds. I ran a 1:30.xx at Monza, even though it took about 3 minutes "real time" to do it. Know what I mean? The physics time step (or frequency) was still the same, it just took twice as long to crunch through the numbers and draw the graphics. Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

"J. Todd Wasson" <[email hidden]> wrote in message news:[email hidden]... > >The physics rate is disconnected from the frame rate, but not locked at > >288hz. Based on your 1/2 real time comment, it appears that on thesystem > >described was achieving approximately 144hz. > > > > What I'm referring to is the integration time step the simulation isusing > for its motion calculations, i.e., simulated time, not "real measuredtime". > > The amount of time it actually takes to do the physics calculations isfar, > far less than 1/288th of a second per cycle, even on my P-60, which isabout as > fast as a stampede of turtles crawling through peanut butter, if you'llpardon > the expression :-P Games will run through their physics code to covermovement > for one graphics frame very quickly, then spend the majority of the restof the > time drawing graphics. > > If you ran GPL at 30 fps, which you'd probably agree is more than fastenough > to run 288hz physics, the physics loop would move the car about .00347 > "simulated" seconds at a time, recalculate, do it again, etc., about nineor > ten times between graphics frames. If the frame rate changes to half this > value, the .00347 "simulated" time step remains the same (1/.00347 =288Hz) , > while it now might loop through the physics code twice as many times asbefore > in between graphics frames. In other words, the car is still moving.00347 > seconds at a time according to the calculations, but you won't see it all > unless your frame rate is 288 or better. If that's how GPL does it, I'dsay > the physics is "locked to 288Hz" as they claim (probably true). > > If you wanted to look at this in terms of real time frequency of thephysics > calculations, please note that the physics loop probably takes up lessthan 5% > of this 30 frames per second. So to equate this to real time Hz, GPL'sphysics > would run at 5760 Hz when the frame rate is 30. The rest of the time,it's > drawing graphics or doing other things. Mine ran at half speed, so itmight > have really running at around 2880Hz, if you wanted to compare it thatway. > Either way, just because my frame rate was horrible, doesn't mean my P-60 > wasn't running the physics at only 144Hz. > > My point is, the "simulated time step" is locked, even if it takes myancient > machinery a day to crank out one second worth of driving time. If thetime > step it was making during calculations was 1/288th of a second each (even > though it took a few seconds to make the calculations for that 1/288th ofa > second), the physics system is still locked to 288Hz, in other words, the > integration time step the motion equations were using was .00347 seconds. > > I ran a 1:30.xx at Monza, even though it took about 3 minutes "realtime" to > do it. Know what I mean? The physics time step (or frequency) was stillthe > same, it just took twice as long to crunch through the numbers and drawthe > graphics. > Ok, I see we are talking apples and oranges. Yes I agree every physics computation always represents 1/288th of a second of race time. My point was that it's quite possible to have less than 288 physics computations per second of real time because of background operations on the computer. Things like virtual memory disk access can hog up the CPU and can cause the physics computations to fall behind. Just because you're getting lower frame rates doesn't mean you're getting lower physics rates. It depends on the cause for the lower frame rates. However if you are getting the maximum (36) fps, I can't see how it's possible to be getting less than 288 physics computations per second since the physics should have priority. With online racing, when the server's opinion of racetime, and your computer's opinion of racetime differs by enough a clock smash happens. It would make sense that in this "disagreement" the server is considered correct.

Quoted text (21 lines)

>Ok, I see we are talking apples and oranges. > >Yes I agree every physics computation always represents 1/288th of a second >of race time. My point was that it's quite possible to have less than 288 >physics computations per second of real time because of background >operations on the computer. Things like virtual memory disk access can hog >up the CPU and can cause the physics computations to fall behind. > >Just because you're getting lower frame rates doesn't mean you're getting >lower physics rates. It depends on the cause for the lower frame rates. >However if you are getting the maximum (36) fps, I can't see how it's >possible to be getting less than 288 physics computations per second since >the physics should have priority. > >With online racing, when the server's opinion of racetime, and your >computer's opinion of racetime differs by enough a clock smash happens. It >would make sense that in this "disagreement" the server is considered >correct. > > >

Ah, I see what you're talking about now :-) Yes, that must wreak havoc during online races. I haven't even begun online programming yet and don't know if I ever will with problems like these. Physics hurts my head enough as it is :-) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

On 04 May 2001 01:30:39 GMT, [email hidden] (J. Todd Wasson) wrote: ...

Quoted text (8 lines)

>>Hm, I doubt it somewhere; it worked nice before. When I brake 100%, it >>starts rotating slowly, as it did a long time before. But no worries, >>I haven't checked why my rotation halt doesn't work anymore, so it >>might be a little thing. Anything to avoid decadupling my frequencies! >>:) > > That's odd. Does it happen when the steering is perfectly straight or only >when it's turned?

It's just that I apply a braking torque (or force) and if this is large, it is normal that the wheel starts moving badly. However, I check somewhere that the brakes keep the wheel from moving, and then fix the rotation speed to 0. Haven't tested yet what the numbers are, but it must be in there. Not a big problem probably. > I have a similar problem where the longitudinal force under >max braking causes a yaw torque when the wheel is turned, even when the wheel >locks, because the longitudinal force is in the tire plane. Probably a good >argument there for Gregor's slip vector usage :-) His slip vector algorithm does do well I must say. ;-) I currently use a friction circle approach from Genta's book, where you downsize Fy (lateral) based on Fx and the maximum Fx. > Seems a "correct" Pacejka >model would take care of this automatically though, since the combined lateral >and longitudinal effects are included. I have some pages on a combined model, but gosh, it introduces even more coefficients, so no go for the moment! > Maybe your rotation halt stopped working when you switched to quarternions. Nope, that was just for the body rotation. Works perfectly. ... > I tried something like this a few months ago. I forget exactly, but I think >it worked pretty well actually, only it worked in reverse. I think the new >slip ratio was the new calculated slip ratio averaged with the last five or six >slip ratios, with the new slip ratio multiplied into the average a few times, >or something like that. Seemed to smoothen it out a bit, but don't remember >for sure. Actually, I think I dumped it once I split the frequencies. Sounds like a slipratio delay; like (I just read this 2 days ago) the flywheel does away with engine vibrations because of its inertia, keeping a smoother acceleration path. The concept could be introduced anywhere to get rid of vibrations actually, but it's hard not too touch realism.

Quoted text (8 lines)

> Something like: > NewSlipRatio = ((OldSlipRatio1 * 10)+ OldSlipRatio2 + OldSlipRatio3 + >OldSlipRatio4) / 14 > > I know you hate the idea of splitting the frequencies, but your example above >is really what the split frequencies seem to accomplish by anticipating >excessively large slip ratios and preventing them from effecting the car's >movement.

Yes, it does seem like that. Works a bit the same like averaging, since your effectively multisampling (like in the graphics dept). > lol. This is the "Sim racing and money" thread! Oops, we're getting offtopic. And I'm getting tangled in delayed work. Must zip! Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

... It's just that I apply a braking torque (or force) and if this is large, it is normal that the wheel starts moving badly. However, I check somewhere that the brakes keep the wheel from moving, and then fix the rotation speed to 0. Haven't tested yet what the numbers are, but it must be in there. Not a big problem probably. His slip vector algorithm does do well I must say. ;-) I currently use a friction circle approach from Genta's book, where you downsize Fy (lateral) based on Fx and the maximum Fx. I have some pages on a combined model, but gosh, it introduces even more coefficients, so no go for the moment! Nope, that was just for the body rotation. Works perfectly. ... Sounds like a slipratio delay; like (I just read this 2 days ago) the flywheel does away with engine vibrations because of its inertia, keeping a smoother acceleration path. The concept could be introduced anywhere to get rid of vibrations actually, but it's hard not too touch realism. Yes, it does seem like that. Works a bit the same like averaging, since your effectively multisampling (like in the graphics dept). Oops, we're getting offtopic. And I'm getting tangled in delayed work. Must zip! Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

Yeah ...keep it on topic or stick a Car Physics at the start..... how am I supposed to find these physics gems :) Ash (Lost in a world of "i'm sure that should work" atm)

Quoted text (10 lines)

| | > lol. This is the "Sim racing and money" thread! | | Oops, we're getting offtopic. And I'm getting tangled in delayed work. | Must zip! | | | Ruud van Gaal, GPL Rank +53.25 | Pencil art : http://www.marketgraph.nl/gallery/ | Free car sim : http://www.marketgraph.nl/gallery/racer/

On 04 May 2001 00:50:46 GMT, [email hidden] (J. Todd Wasson) wrote: > Who knows? :-) Do you run controls through %WM_TIMER? Or does DirectInput >do things differently? Either way, I'd guess it's a set frequency in "sim >time", but nothing goes faster than 288Hz real time. I update the controller per frame drawn. It still does nicely at 80fps, no FF speed problems (MSFF, serial) that I expected. But I haven't profiled where the time is spent, might still be in DInput. I just have an idlefunc() which calls OnGfxFrame() somewhere, which does a controller update. So the frequency varies. (ah, heresy!) Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

On Fri, 4 May 2001 12:40:26 +0100, "Ashley McConnell" <[email hidden]> wrote: >Yeah ...keep it on topic or stick a Car Physics at the start..... how am I >supposed to find these physics gems :) Well, gems, hm. ;-) It won't happen again! >Ash (Lost in a world of "i'm sure that should work" atm) Sometimes you need to go back and plug out as many things as possible until behavior is workable again. And then see where things go off. Anyway, hope you'll get the progress back again. Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

Yeah, I reckon i need to unplug some of the new stuff until it handles right again. Although I think my policy of "optimise when its finished" has caught up with me, I had a dt time of 0.046 last night when i was debugging just before i went to bed which would indicate 25Hz, will check it when I get home. I think its the OpenGL text that is to blame though, I have a mass of it, and a few guys on the OpenGL forum said their program spent 90% of its time in that code (eek!). So that could be a place to start. Keep up the good work Ruud. By the way you are working too hard....work on that GPL Rank :) Ash GPL Rank -10.8 :))

Quoted text (7 lines)

| | Anyway, hope you'll get the progress back again. | | | Ruud van Gaal, GPL Rank +53.25 | Pencil art : http://www.marketgraph.nl/gallery/ | Free car sim : http://www.marketgraph.nl/gallery/racer/

>Ah! Heresy! (a hype term right now) >I hope he was talking about controller updates. I won't accept physics >updates tied to the framerate anymore. >It's like getting slomo or fastmo when your machine is slow or fast. >Unnecessary and not difficult to get done. I agree Ruud... but i expect this is exactly where GP2/3 fails horribly, i think its physics engine runs at whatever the framerate is. Thats why the framerate is stored in the replay files, as when viewing replays, the physics model is recalculated (only driver inputs and start X-Y are stored), so varies between source and replay will produce replays that make no sense. It also explains the slomo, and the resulting problems (impossibilities) for online or networked racing (time synchronization). In other words, it sucks. But that was well known already. Martijn

"�artijn" <[email hidden]> wrote in message news:3af3ccb9$0$29273@reader4...

Quoted text (9 lines)

> >Ah! Heresy! (a hype term right now) > >I hope he was talking about controller updates. I won't accept physics > >updates tied to the framerate anymore. > >It's like getting slomo or fastmo when your machine is slow or fast. > >Unnecessary and not difficult to get done. > > > I agree Ruud... > but i expect this is exactly where GP2/3 fails horribly, i think its

physics > engine runs at whatever the framerate is. Thats why the framerate isstored > in the replay files, as when viewing replays, the physics model is > recalculated (only driver inputs and start X-Y are stored), so varies > between source and replay will produce replays that make no sense. > > It also explains the slomo, and the resulting problems (impossibilities)for > online or networked racing (time synchronization). In other words, itsucks. > But that was well known already. > > Martijn >Hi Martijn, Agree with you almost completely here, but you forget one thing: the method of recording input and recalculating the physics creates the possibility for a very thorough check for cheats. Any changes to the track or the car properties will produce what you call "replays that make no sense", thereby revealing the cheat. The input stream is also the hardest thing to reproduce artificially (which would be the biggest cheat of all), since the physics engine is more or less a one way algorithm, not easy to reverse. I figure that an artificial replay is a lot easier to make in a system that records position information along with some other things. So I hope that when they remove the connection between frame rate and physics engine to get rid of slomo and improve (or should I say make possible....) network play, the input recording bit will stay as a powerful check against cheaters. This could coexist in my view with a replay system based on position info. Bart Westra

Quoted text (8 lines)

>I update the controller per frame drawn. It still does nicely at >80fps, no FF speed problems (MSFF, serial) that I expected. >But I haven't profiled where the time is spent, might still be in >DInput. >I just have an idlefunc() which calls OnGfxFrame() somewhere, which >does a controller update. > >So the frequency varies. (ah, heresy!)

lol. Shame! I'll come running to you for help when I get into DirectX, probably by about the year 2050 ;-) I do have an interesting sound idea. (We're waaaay off topic now, but oh well :-)) Is it a lot of work to set up DirectSound to take an array of data and play it through a sound card? Say a combined 8 cylinder intake and exhaust pressure profile from a simulated engine, at different rpm levels, etc. :-)? I'd be curious what my data might "sound" like. Perhaps it would be too "computery", but heck, an engine sound *is* this pressure profile, so maybe it would work! If so, even changing the camshaft a little would produce a new sound. What do you think? Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

>It's just that I apply a braking torque (or force) and if this is >large, it is normal that the wheel starts moving badly. However, I >check somewhere that the brakes keep the wheel from moving, and then >fix the rotation speed to 0. Haven't tested yet what the numbers are, >but it must be in there. Not a big problem probably. > Frustrating. Once your friction reversal algo is right, it'll probably go away. Wierd though that it came back. Maybe the slipratio differential equations you're using now are causing this. (Stab in the dark on my part) >His slip vector algorithm does do well I must say. ;-) >I currently use a friction circle approach from Genta's book, where >you downsize Fy (lateral) based on Fx and the maximum Fx. Wierd. I still don't have the book, but I would think that inputting slip ratio and slip angle into Pacejka's formula would give the right output, without reducing anything. It seemed to me that that was the point of it, to do away with the friction circle. I better get the book, I guess :-) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

On Sat, 5 May 2001 12:13:02 +0200, "�artijn" <[email hidden]> wrote:

Quoted text (12 lines)

>>Ah! Heresy! (a hype term right now) >>I hope he was talking about controller updates. I won't accept physics >>updates tied to the framerate anymore. >>It's like getting slomo or fastmo when your machine is slow or fast. >>Unnecessary and not difficult to get done. > >I agree Ruud... >but i expect this is exactly where GP2/3 fails horribly, i think its physics >engine runs at whatever the framerate is. Thats why the framerate is stored >in the replay files, as when viewing replays, the physics model is >recalculated (only driver inputs and start X-Y are stored), so varies >between source and replay will produce replays that make no sense.

Sounds like it uses the same code as Revs did. ;-) >It also explains the slomo, and the resulting problems (impossibilities) for >online or networked racing (time synchronization). In other words, it sucks. Ofcourse, code written like that becomes overly complex and can only become harder to maintain. Too bad this perhaps means there will never be GP4, since Geoff should do a complete rewrite. And not in assembler, please. Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

On 06 May 2001 20:31:47 GMT, [email hidden] (J. Todd Wasson) wrote: ... > lol. Shame! I'll come running to you for help when I get into DirectX, >probably by about the year 2050 ;-) Hope I'll be around then. ;-) When pushing 80, I hope we do have the virtual powerchair with mind connectors (which all babies will get implanted at birth) so we can actually feel the G forces by neural stimulations.

Quoted text (7 lines)

> I do have an interesting sound idea. >(We're waaaay off topic now, but oh well :-)) Is it a lot of work to set up >DirectSound to take an array of data and play it through a sound card? Say a >combined 8 cylinder intake and exhaust pressure profile from a simulated >engine, at different rpm levels, etc. :-)? I'd be curious what my data might >"sound" like. Perhaps it would be too "computery", but heck, an engine sound >*is* this pressure profile, so maybe it would work!

Check out Staccato (http://www.staccatosys.com/). WSC uses it, for example. There's a small car engine demo which bases the sound on some variables. I don't know exactly how active they are; I emailed them some time ago to see if their product would be multiplatform (Linux/IRIX/Win32), but haven't heard from them. Given the small example I heard on TrackTalk some time ago (when the West brothers were giving an interview), you can get it too great heights. The only drawback I see here is that people will want to insert their own samples, and it's easier that way. But the best thing would be a mix of samples and synthesizer-like malformers, something like that. > If so, even changing the camshaft a little would produce a new sound. What >do you think? Difficult to get working like you want to, I think. :) But setting up a few DX sound buffers is relatively easy. You might want to check out the qdxsbuf.cpp file in my QLib (at my site, at programmers->source code->documentation). It does some sound buffering stuff in DirectX in C++. Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

On Fri, 4 May 2001 15:47:10 +0100, "Ashley McConnell" <[email hidden]> wrote: >Yeah, I reckon i need to unplug some of the new stuff until it handles right >again. Although I think my policy of "optimise when its finished" has >caught up with me, I had a dt time of 0.046 last night when i was debugging >just before i went to bed which would indicate 25Hz, will check it when I >get home. That's not a lot, lol; most of the time my framerate is higher than that. So you'll get stuttering frames. >I think its the OpenGL text that is to blame though, I have a mass of it, >and a few guys on the OpenGL forum said their program spent 90% of its time >in that code (eek!). So that could be a place to start. Well, on the O2 Racer spends a lot of time in the graphics code yes, up to 95% with 2 cars on the track. But that's just because the graphics are slow. Fortunately, on the PC, I can get 80fps and still a lot of time in the graphics. No need to optimise there. ;-) (but still, the graphics eats up the most). >Keep up the good work Ruud. By the way you are working too hard....work on >that GPL Rank :) Lol, yes, the Rank. The Ring, that's where the seconds are. I hardly ever play GPL, except to see what its physics do. And now, with DX8 and Win2K, it starts stuttering soon and then quickly becomes unplayable. And I have 256Mb RAM, a Geforce2MX/32Mb, so it should be able to do 36fps at all times. I just need newer drivers, but I'm not anxious on doing that. Best thing would be to take it out of my sig. ;-O Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

On 06 May 2001 20:38:34 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (9 lines)

>>It's just that I apply a braking torque (or force) and if this is >>large, it is normal that the wheel starts moving badly. However, I >>check somewhere that the brakes keep the wheel from moving, and then >>fix the rotation speed to 0. Haven't tested yet what the numbers are, >>but it must be in there. Not a big problem probably. > > Frustrating. Once your friction reversal algo is right, it'll probably go >away. Wierd though that it came back. Maybe the slipratio differential >equations you're using now are causing this. (Stab in the dark on my part)

Hm, those quickly get removed when the car gets some speed. I assume its the differential code I put in; that takes torques from 3 directions, calculates the inertia's and the accelerations at all 3 sides. This is totally new compared to what I did before (just calculating torque and then wheel spin velocity or rather acceleration).

Quoted text (8 lines)

>>His slip vector algorithm does do well I must say. ;-) >>I currently use a friction circle approach from Genta's book, where >>you downsize Fy (lateral) based on Fx and the maximum Fx. > > Wierd. I still don't have the book, but I would think that inputting slip >ratio and slip angle into Pacejka's formula would give the right output, >without reducing anything. It seemed to me that that was the point of it, to >do away with the friction circle. I better get the book, I guess :-)

It's a separate Fx and Fy formula. So it assumes SA=0 for Fx, and SR=0 for Fy (lateral). This keeps the Pacejka formula 'relatively simple'. When combing, you get too much force and you have to cap the force at the circle limits. The combined Pacejka formula is even worse, it seems; more coefficients, more trouble. It's a nice book; I do read some more RCVD sometimes lately, as it contains more textual knowledge, with which you can understand more. The Genta book is already useful just on the basis of the Pacejka formulae alone though (and the appendices with the numbers). Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

Quoted text (8 lines)

>> lol. Shame! I'll come running to you for help when I get into DirectX, >>probably by about the year 2050 ;-) > >Hope I'll be around then. ;-) >When pushing 80, I hope we do have the virtual powerchair with mind >connectors (which all babies will get implanted at birth) so we can >actually feel the G forces by neural stimulations. >

That'd be too cool :-)

Quoted text (23 lines)

>> I do have an interesting sound idea. >>(We're waaaay off topic now, but oh well :-)) Is it a lot of work to set up >>DirectSound to take an array of data and play it through a sound card? Say >a >>combined 8 cylinder intake and exhaust pressure profile from a simulated >>engine, at different rpm levels, etc. :-)? I'd be curious what my data >might >>"sound" like. Perhaps it would be too "computery", but heck, an engine >sound >>*is* this pressure profile, so maybe it would work! > >Check out Staccato (http://www.staccatosys.com/). WSC uses it, for >example. There's a small car engine demo which bases the sound on some >variables. I don't know exactly how active they are; I emailed them >some time ago to see if their product would be multiplatform >(Linux/IRIX/Win32), but haven't heard from them. >Given the small example I heard on TrackTalk some time ago (when the >West brothers were giving an interview), you can get it too great >heights. >The only drawback I see here is that people will want to insert their >own samples, and it's easier that way. But the best thing would be a >mix of samples and synthesizer-like malformers, something like that. >

WOW! The Staccato engine sound demo at their site is awesome. I've got some code now that can probably do what I want, it'll be awhile until I can throw some data in and see what it sounds like. I just spent the past 3 days getting an OpenGL system up and running. BIG improvement over my wireframe graphics, although really silly looking compared to Racer :-) Still, it's neat to have skidmarks again :-) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

On 13 May 2001 19:18:05 GMT, [email hidden] (J. Todd Wasson) wrote: ... > WOW! The Staccato engine sound demo at their site is awesome. I've got some >code now that can probably do what I want, it'll be awhile until I can throw >some data in and see what it sounds like. I just spent the past 3 days getting >an OpenGL system up and running. Ah, things used to be 'click this button to install', but today you have a world of time to spend on getting your machine up like you want to. :) > BIG improvement over my wireframe graphics, >although really silly looking compared to Racer :-) Still, it's neat to have >skidmarks again :-) Ah, skidmarks! Don't have those yet, but some plans are already laid out on paper. Just eyecandy really. And the sun has started to shine here, which is really pushing my productivity low. So much nicer to have diner at the beach with nice girls by my side, than to add a better torque division algorithm in the differential code. ;-) Makes me feel more human. I'll do a beta release of v0.4.5 tonight I think. So many things that ramble, but the way things are going now, it's slowing down a bit due to the summer, and doing 3 platforms is beginning to get a mess (esp. with my Linux machine not neatly hooked to the other machines, making scripting a bit harder). Ah well. First I'll have to watch the last part of the F1 race. Missed it because I was on the beach. ;-) Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/