torcs-devel Mailing List for TORCS - The Open Racing Car Simulator

Hi everyone,

I'd like to suggest a couple of spelling changes:

1. racescreens/results.cpp
   Replace "Dammages" with "Damage" at lines 119 and 266.

2. raceengineclient/raceengine.cpp
   Tweak the switch statement to avoid producing forms like '11st', '12nd',
and '13rd'.
   
   I've included a patch for the second change.
   
Thanks,
Scott Randal


*** raceengine.cpp	Sun Aug  8 18:43:24 2004
--- raceengineNEW.cpp	Sat Aug 21 21:59:22 2004
***************
*** 114,117 ****
--- 114,118 ----
      static float color[] = {0.0, 0.0, 1.0, 1.0};
      tSituation	*s = ReInfo->s;
+     char *numSuffix;
  
      tReCarInfo *info = &(ReInfo->_reCarInfo[car->index]);
***************
*** 257,274 ****
  				ReRaceBigMsgSet(buf, 10);
  			    } else {
! 				switch (car->_pos % 10) {
! 				case 1:
! 				    sprintf(buf, "%s Finished %dst", car->_name, car->_pos);
! 				    break;
! 				case 2:
! 				    sprintf(buf, "%s Finished %dnd", car->_name, car->_pos);
! 				    break;
! 				case 3:
! 				    sprintf(buf, "%s Finished %drd", car->_name, car->_pos);
! 				    break;
! 				default:
! 				    sprintf(buf, "%s Finished %dth", car->_name, car->_pos);
! 				    break;
  				}
  				ReRaceMsgSet(buf, 5);
  			    }
--- 258,278 ----
  				ReRaceBigMsgSet(buf, 10);
  			    } else {
! 				numSuffix = "th";
! 				if (abs(12 - car->_pos) > 1) { /* leave suffix as 'th' for 11 to 13 */
! 				  switch (car->_pos % 10) {
! 				  case 1:
! 				      numSuffix = "st";
! 				      break;
! 				  case 2:
! 				      numSuffix = "nd";
! 				      break;
! 				  case 3:
! 				      numSuffix = "rd";
! 				      break;
! 				  default:
! 				      break;
! 				  }
  				}
+ 				sprintf(buf, "%s Finished %d%s", car->_name, car->_pos, numSuffix);
  				ReRaceMsgSet(buf, 5);
  			    }

Jason Fleming wrote:
> Like, disregard this thread. Everything is working fine except my voodoo 
> logic. At present, my force feedback module updates at a lower rate than 
> the rest of the system… so collisions were missed if they were brief and 
> fell between the update interval. Oops. Easily fixed. Sorry for the 
> confusion.

Good news :-)

I had the same problem for producing crash sounds, that's why
a flag is stored when a collision is detected by the simu
and reset by the sound function when used.

Eric.

> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* tor...@li... 
> [mailto:tor...@li...] *On Behalf Of *Jason 
> Fleming
> *Sent:* Thursday, August 12, 2004 1:41 PM
> *To:* tor...@li...
> *Subject:* RE: [Torcs-devel] Collisions with walls
> 
>  
> 
> Oops. Looks like SimCarCollideXY is called appropriately. Although, for 
> some reason I have not yet discovered, the car can bounce off the wall 
> even if no car corners are outside of the segment walls. Still looking 
> into this... if anyone knows why, please let me know.
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* tor...@li... 
> [mailto:tor...@li...] *On Behalf Of *Jason 
> Fleming
> *Sent:* Thursday, August 12, 2004 11:49 AM
> *To:* tor...@li...
> *Subject:* [Torcs-devel] Collisions with walls
> 
>  
> 
> There are times that the car bounces off the wall and does not make a 
> crash sound. Is this intentional? Looking at the collide functions, it 
> is possible to bounce off the wall yet not process SimCarCollideXY. Is 
> this intentional?
> 
>  
> 
> I am trying to find a good place to compute force feedback collision forces.
> 

-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
               TORCS - http://torcs.org
             The Open Racing Car Simulator
         AKA The Other Release Coming Soon (Skin'r)
            How soon is soon ? (RaceBlizter)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Like, disregard this thread. Everything is working fine except my voodoo
logic. At present, my force feedback module updates at a lower rate than
the rest of the system... so collisions were missed if they were brief
and fell between the update interval. Oops. Easily fixed. Sorry for the
confusion.

=20

  _____ =20

From: tor...@li...
[mailto:tor...@li...] On Behalf Of Jason
Fleming
Sent: Thursday, August 12, 2004 1:41 PM
To: tor...@li...
Subject: RE: [Torcs-devel] Collisions with walls

=20

Oops. Looks like SimCarCollideXY is called appropriately. Although, for
some reason I have not yet discovered, the car can bounce off the wall
even if no car corners are outside of the segment walls. Still looking
into this... if anyone knows why, please let me know.

=20

  _____ =20

From: tor...@li...
[mailto:tor...@li...] On Behalf Of Jason
Fleming
Sent: Thursday, August 12, 2004 11:49 AM
To: tor...@li...
Subject: [Torcs-devel] Collisions with walls

=20

There are times that the car bounces off the wall and does not make a
crash sound. Is this intentional? Looking at the collide functions, it
is possible to bounce off the wall yet not process SimCarCollideXY. Is
this intentional?

=20

I am trying to find a good place to compute force feedback collision
forces.

Oops. Looks like SimCarCollideXY is called appropriately. Although, for
some reason I have not yet discovered, the car can bounce off the wall
even if no car corners are outside of the segment walls. Still looking
into this... if anyone knows why, please let me know.

=20

  _____ =20

From: tor...@li...
[mailto:tor...@li...] On Behalf Of Jason
Fleming
Sent: Thursday, August 12, 2004 11:49 AM
To: tor...@li...
Subject: [Torcs-devel] Collisions with walls

=20

There are times that the car bounces off the wall and does not make a
crash sound. Is this intentional? Looking at the collide functions, it
is possible to bounce off the wall yet not process SimCarCollideXY. Is
this intentional?

=20

I am trying to find a good place to compute force feedback collision
forces.

There are times that the car bounces off the wall and does not make a
crash sound. Is this intentional? Looking at the collide functions, it
is possible to bounce off the wall yet not process SimCarCollideXY. Is
this intentional?

=20

I am trying to find a good place to compute force feedback collision
forces.

Hi All

> And you say the camera height calculation grGetHOT() uses the
> opengl query? Maybe we can replace it with something else, then. Also,

I inspected the code and it does not query OpenGL state.

bye, Bernhard.

-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

Hi Christos

> And you say the camera height calculation grGetHOT() uses the
> opengl query? Maybe we can replace it with something else, then. Also,

No, I just suspect it...

> the glitches that you mention must only occur when you use the fly
> camera, correct?

Too long ago when I tested it, I cannot remember:-(

bye, Bernhard.

-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

Interesting.

And you say the camera height calculation grGetHOT() uses the
opengl query? Maybe we can replace it with something else, then. Also,
the glitches that you mention must only occur when you use the fly
camera, correct?

-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

Hi All

>> You have to be really careful if you want avoid such glitches... if you
>> are in a time critical situation then you have to:
>> - never read back or
>> - having multiple threads so that just one thread needs to wait for the
>> query.

An here from the red book:
http://www.rush3d.com/reference/opengl-redbook-1.1/appendixh.html

"Query commands flush as much of the stream as is required to return 
valid data but don't guarantee to complete all pending rendering commands."

bye, Bernhard.

-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

Hi All

> You have to be really careful if you want avoid such glitches... if you
> are in a time critical situation then you have to:
> - never read back or
> - having multiple threads so that just one thread needs to wait for the
> query.

Here some lines from Mark. J. Kilgard's "OpenGL, Programming for the X 
Windows System", ISBN 0-201-48359-9, page 398:
"In general, avoid calling all routines (typically the glGet* routines) 
  that return OpenGL state. These routines often result in a complete 
stalling of the graphics hardware pipeline."

bye, Bernhard.


-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

Hi Christos

>>A nice example which could cause stalls is the readback of the height in
>>the flying camera, does it require a read of OpenGL server state? If
>>this is the case, then this stalls and TORCS goes sleeping till the
>>result is here (because OpenGL needs to render to be able to answer the
>>query).
>>
> 
> 
> If that is true then I can only say *yikes*. How common is it that

It is:-(

> queries are only answered after rendering is complete?

I think that is always the case that you need to render till the point
where the query occurs.
Say we are interested in reading back OpenGL serverstate (e.g. a matrix,
whatever). Then of course you are querying in a sequence of commands,
and that you get the correct results the previous transformations must
be performed, before you can get the answer... e.g.:

glRotate()
glTranslate()
glRotate()
glTranslate()
glRotate()
glTranslate()
glRotate()
glTranslate()
Read back modelview matrix

Now that means that the whole rendering queue needs to be processed
before you get the modelview matrix back... and then performance starts
really to suck because there is no other way than to wait for the result
--> no parallelism anymore.

You have to be really careful if you want avoid such glitches... if you
are in a time critical situation then you have to:
- never read back or
- having multiple threads so that just one thread needs to wait for the
query.

bye, Bernhard.

-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

Hi Christos

>>I do not agree about that. If you sync to vblank the software is
>>sleeping/idling (I do not know how nvidia implemented it) till the new
>>frame is spit out (there is just the main thread in TORCS). This can
>>cause a performance loss (ok, it depends how you define better performance).
>>
> 
> Oh, yes. That depends on whether the client (torcs) sleeps from the
> moment of the Render request until the first vblank. This would be
> bad. A better way would be something like this:
> 
> 0. Set flag=false
> 
> 1. Client sends Render()
> 
> 2.
> -If (flag) then client must sleep.
> -If (!flag), Server sets flag to true and starts rendering scene in
> back buffer; the client continues running.
> 
> 3. Client continues processing and at some point goes to 1.
> 
> I. VBLANK Interrupt: If (flag) and  back
> scene has finished rendering: swap buffers and set flag to
> false (this would mean that if a client had just sent a Render(), we
> immediately start rendering the new scene); Otherwise do nothing.
> 
> <end>
> 
> Anyway, this stuff can be implemented on the server side so that the
> game can work fluidly without knowing anything about double-buffering.

That very depends on a lot of conditions (Def: "the server": OpenGL 
server side):
- When you cannot render you have to store the commands in a buffer of 
finite size, so when the buffer is full, you get stalled again 
(immediate mode returns when the command has been executed from the 
client view, so the command must have been enqueued on the server at least).
- You definitively need to signal the server (OpenGL server side) when 
the scene is complete, otherwise it will potentilly draw never (glFlush, 
or the tough blocking one glFinish).
- If you do an OpenGL query, then the server must render first to give 
the answer.

So it is very dependent on the OpenGL driver, the hardware capabilities, 
the glutSwapBuffer implementation and on the implementation of the 
application if you can use potential parallelism... NEVER read data from 
the server if time matters.

A nice example which could cause stalls is the readback of the height in 
the flying camera, does it require a read of OpenGL server state? If 
this is the case, then this stalls and TORCS goes sleeping till the 
result is here (because OpenGL needs to render to be able to answer the 
query).

I think TORCS is quite lousy what OpenGL performance concerns, because 
we render the most stuff in immediate mode. Things like the possibility 
of deformable objects also kill performance (otherwise you could use 
vertex_buffer_objects or display lists, sharing the whole vertices of 
equal cars, just changing texture state). The readback of the height of 
the flying camera kills performance as well as hell I guess... before 
that was introduced (1.2.1) I could let run TORCS over the network 
(remote OpenGL, indirect rendering), now (1.2.2) its impossible.

> So, you can only get lockups/glitches if the simulation code is too
> fast :)

I don't think so, a lot of constraints need to be fulfilled that this 
finally works...

bye, Bernhard.

-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

> > I tried to enable double-buffering on my NVIDIA card, by setting:
> > __GL_SYNC_TO_VBLANK=1 to avoid shearing.
> >
> > Theoretically this should result in a better performance since the
> > game does not waste cycles rendering a new scene when the current
> > display cycle has not finished.
>
> I do not agree about that. If you sync to vblank the software is
> sleeping/idling (I do not know how nvidia implemented it) till the new
> frame is spit out (there is just the main thread in TORCS). This can
> cause a performance loss (ok, it depends how you define better performance).
>
Oh, yes. That depends on whether the client (torcs) sleeps from the
moment of the Render request until the first vblank. This would be
bad. A better way would be something like this:

0. Set flag=false

1. Client sends Render()

2.
-If (flag) then client must sleep.
-If (!flag), Server sets flag to true and starts rendering scene in
back buffer; the client continues running.

3. Client continues processing and at some point goes to 1.

I. VBLANK Interrupt: If (flag) and  back
scene has finished rendering: swap buffers and set flag to
false (this would mean that if a client had just sent a Render(), we
immediately start rendering the new scene); Otherwise do nothing.

<end>

Anyway, this stuff can be implemented on the server side so that the
game can work fluidly without knowing anything about double-buffering.
Indeed, I just tried the latest version of the NVIDIA drivers and it
seems that  these work a bit better. I get rock-steady 85 fps on most
tracks unless I turn anti-aliasing on.


> When the frame is ready to become spit out TORCS has to wait with
> vblank, otherwise it could draw and perform the next simulation steps
> (resolution is 1/500 [s] -> 500Hz).

It depends on the server implementation. If it is implemented the way
I describe then TORCS only has to wait in the case when the second
buffer is still being rendered (or has been rendered but there has
been no VBLANK interrupt since). If the simulation takes more than
1/70 to finish, then the second buffer will always have been rendered
[assuming a simple scene for rendering here].

So, you can only get lockups/glitches if the simulation code is too
fast :)

Multi-threading should be cool for a lot of things, but there
might be problems with timing, of course.


-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)

Hi Christos

> I tried to enable double-buffering on my NVIDIA card, by setting:
> __GL_SYNC_TO_VBLANK=1 to avoid shearing.
> 
> Theoretically this should result in a better performance since the
> game does not waste cycles rendering a new scene when the current
> display cycle has not finished.

I do not agree about that. If you sync to vblank the software is 
sleeping/idling (I do not know how nvidia implemented it) till the new 
frame is spit out (there is just the main thread in TORCS). This can 
cause a performance loss (ok, it depends how you define better performance).

When the frame is ready to become spit out TORCS has to wait with 
vblank, otherwise it could draw and perform the next simulation steps 
(resolution is 1/500 [s] -> 500Hz). That has the consequence that e.g. 
at 70Hz you have to wait in the worst case 1/70 [s] and then the 
simulation is 1/70 [s] behind, this means 7 simulation steps. Now 
depending on your system it has to catch up with the simulation time 
before it renders a frame, an that can lead to glitches if you think of 
it (e.g. if your system was able to follow the simulation without 
performance reserves, then it will take some time to recover).

The same happens if you select a lot of cars on a slow system, this can 
lead to glitches or stall the graphics completely (as long at TORCS is 
behind it does not draw).

> However, what I noticed was that, while the CPU usage dropped from
> 100% to around 80%, the game became quite glitchy. That might be
> attributable to either the rendering loop or the way the time
> interactions between the sim and the gfx is handled. Probably
> the rendering loop  assumes there is no double-buffering and
> this breaks things though I am not sure if that is controlled from
> torcs or from plib.

I have no problems here even with my PIII-550, GeForce 3, but I have to 
select a reasonable set of drivers and I never use vblank... I played 
some time ago with the simulation loop and meant to have found some 
ideas for improvment, but they are not to implement that easily.

What I have in mind for a very long time (since 2001) is enabling 
multithreading in TORCS (future CPU's seem to be multicore/SMP or at 
least SMT), so this would probably help to increase performance on such 
systems a bit (of course the speed up would not be 2.0... but it might 
help to fix such lock ups even on single CPU's, e.g. on system calls the 
one thread goes to sleep (e. g. positioning the harddisk head for 
writing the screenshot), so the other thread can continue its work). But 
that is not that easy to implement... you need to copy and syncronize 
data, etcetc...

- You could execute AI code of different modules in parallel.
- You could render in a separate thread (copy of tSituation, 
synchronisation).
- If you capture a movie you copuld delegate the png/write stuff into 
another thread (I think here the speedup could be almost optimal).
- Probably more...

In all cases where  TORCS sleeps on system calls multithreading would 
also improve on singe CPU's (e.g. everything which involves writing to 
disk).

> Flipping: when OpenGL flipping is enabled, OpenGL can perform buffer
> swaps by changing which buffer the DAC scans out rather than copying
> the back buffer contents to the front buffer;  this is generally a
> much higher performance mechanism and allows tearless swapping during
> the vertical retrace (when __GL_SYNC_TO_VBLANK is set).  The
> conditions under which OpenGL can flip are slightly complicated, but
> in general: on Geforce or newer hardware, OpenGL can flip when a
> single full screen unobscured OpenGL application is running, and
> __GL_SYNC_TO_VBLANK is enabled.

Hmm, I thought it would also do page flipping without 
__GL_SYNC_TO_VBLANK... but that seems to be wrong.

bye, Bernhard.

-- 

visit my homepage http://www.berniw.org
coming soon: The TORCS Racing Board, http://www.berniw.org/trb

I tried to enable double-buffering on my NVIDIA card, by setting:
__GL_SYNC_TO_VBLANK=1 to avoid shearing.

Theoretically this should result in a better performance since the
game does not waste cycles rendering a new scene when the current
display cycle has not finished.

However, what I noticed was that, while the CPU usage dropped from
100% to around 80%, the game became quite glitchy. That might be
attributable to either the rendering loop or the way the time
interactions between the sim and the gfx is handled. Probably
the rendering loop  assumes there is no double-buffering and
this breaks things though I am not sure if that is controlled from
torcs or from plib.

Does vertical blank syncing work OK in your systems?


Here is the NVIDIA text:

Flipping: when OpenGL flipping is enabled, OpenGL can perform buffer
swaps by changing which buffer the DAC scans out rather than copying
the back buffer contents to the front buffer;  this is generally a
much higher performance mechanism and allows tearless swapping during
the vertical retrace (when __GL_SYNC_TO_VBLANK is set).  The
conditions under which OpenGL can flip are slightly complicated, but
in general: on Geforce or newer hardware, OpenGL can flip when a
single full screen unobscured OpenGL application is running, and
__GL_SYNC_TO_VBLANK is enabled.

-- 
Christos Dimitrakakis
IDIAP (http://www.idiap.ch/~dimitrak/main.html)