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

Hi, Mart, and all.

> I only read your patch, I didn't actually test it (will do later), but I think 
> there is at least one problem with it.
> 
> It is about the function linuxModLoad. What should it do? It should load the 
> module and return if it was succesfull. So, at some point this function is 
> called. Then the caller only knows if loading the module was succesfull or 
> not. So it must obtain the data of the loaded module on another way. This is 
> done by an assumption: modules are always placed in front of the list. So, by 
> dereferencing the module list, it gets the module which has just been loaded.
> 
> But as far as I can see, you break that assumption. If a module is already 
> loaded, nothing happends. 

You are right.

> Because raceinit.cpp in raceengineclient use that 
> assumption, it will assign the wrong robot to a car, and proberbly causes 
> crashes in some cases.

I had not noticed this assumption, and I have not checked robot/car associations
: so I must go on working !

> Of course, there also is an (easy) solution: if a module is already loaded, 
> move it to the front.

Good solution !

> It is possible that one library can be loaded by several sopath's. Think about 
> a relative path and a absolute path. I don't see any circumstanses where this 
> could happen in Torcs. And even if it happends, it will work the same way as 
> it works now. I think documenting this assumption is a good idea.

Your are right : I check if a module has already been loaded only by comparing
the stored sopath. And nothing guarantees that the stored sopath is the absolute
normalized user-expanded ... path of the library. So the check is not perfect !
So, 2 solutions : document or fix !

> I see that you check if calloc was succesfull. It means that Torcs doesn't 
> directly crash if the computer is out of memory. Is this a good thing?

I've always been thinking that a brutal crash whithout any explanation
is NEVER a solution ... So in this case, I printf a message on the console,
and return to the caller ... But you may argue that :
- the message is only seeable in debug mode and if torcs is run
   in a console
- Torcs will soon crash because other m/callocs are not checked ...
But isn't it a (very small) improvement, yet ?

Thank for your help, Mart !

Cheers,

Jean-Philippe.

Hi, Christos, Bernhard and all.

May be it's too late top answer, but one never knows ...

 > Question to all developers:
 > Is there a reason for not allowing RTTI? The 'performance' claim seems weak.

I don't see any (and particularly NOT the 'performance' one).

 > Would the code work without /GR if I used a static cast?

Yes, it should, as static_cast is exactly the same as dynamic_cast,
except that there is no run-time check that the cast is safe.

Cheers, Jean-Philippe.

Hi Jean-Philippe (and others),

Op Saturday 19 April 2008 17:16:43 schreef Annick et Jean-Philippe:
> Hi, all, again.
>
> As promised, this is the second half of the "no maximum number of
> interfaces for Torcs modules" patch (too big for Torcs-devel list).
> You can apply it after or before the first half, as you want ... the result
> will be the same.
>
> As an illustration, and also an example of how to use the new feature
> in a robot code, you will also find a patch that adds an 11'th car
> to the "bt" robot (I could not keep myself from choosing the Ford GT 40
> Concept, with its so gorgeous sound !).
>
> Please, test it and tell me what you think !
> Feel free to comment, propose more, ...
>
> Cheers,
>
> Jean-Philippe.
>
> PS: Tested on Linux Mandriva 2008.0 GCC 4.2.2 rc x86_64
>            and Windows XP SP2 VC6 SP6

I only read your patch, I didn't actually test it (will do later), but I think 
there is at least one problem with it.

It is about the function linuxModLoad. What should it do? It should load the 
module and return if it was succesfull. So, at some point this function is 
called. Then the caller only knows if loading the module was succesfull or 
not. So it must obtain the data of the loaded module on another way. This is 
done by an assumption: modules are always placed in front of the list. So, by 
dereferencing the module list, it gets the module which has just been loaded.

But as far as I can see, you break that assumption. If a module is already 
loaded, nothing happends. Because raceinit.cpp in raceengineclient use that 
assumption, it will assign the wrong robot to a car, and proberbly causes 
crashes in some cases.

Of course, there also is an (easy) solution: if a module is already loaded, 
move it to the front.

It is possible that one library can be loaded by several sopath's. Think about 
a relative path and a absolute path. I don't see any circumstanses where this 
could happen in Torcs. And even if it happends, it will work the same way as 
it works now. I think documenting this assumption is a good idea.

I see that you check if calloc was succesfull. It means that Torcs doesn't 
directly crash if the computer is out of memory. Is this a good thing?

Regards,

Mart

Hi, Christos, and all.

 > Hm.. probably we can make the CPU go to sleep when waiting for the next
 > vertical blank too. I noticed that when I have vblank turned on on my
 > old system, CPU % went down from 100% to something a bit less (since
 > anyway TORCS has nothing to do until it can draw the next frame)...
 > but that probably has more to do with OpenGL.

I have tested this setting, but it's hard to say ...
may be, yes, the CPU is not always 100% if "Sync to vblank" is on.

But on the same subject, I noticed that on windows, there is a special
Torcs setting in the "Options/Display" screen : "Max Frequency",
that is not present on Linux. And as I have a 60 Hz flat panel,
I put this frequency to 60, and this time, the CPU seems noticeably
under 100% (may be 60-80) ...

Isn't this another way to make less noise and heat ?

So, question : why isn't this setting accessible on Linux ?

Cheers,

Jean-Philippe.

Hi, Olethros, and all.

 > Hm.. probably we can make the CPU go to sleep when waiting for the next
 > vertical blank too. I noticed that when I have vblank turned on on my
 > old system, CPU % went down from 100% to something a bit less (since
 > anyway TORCS has nothing to do until it can draw the next frame)...
 > but that probably has more to do with OpenGL.

I have tested this setting, but it's hard to say ...
may be, yes, the CPU is not always 100% if "Sync to vblank" is on.

But on the same subject, I noticed that on windows, there is a special
Torcs setting in the "Options/Display" screen : "Max Frequency",
that is not present on Linux. And as I have a 60 Hz flat panel,
I put this frequency to 60, and this time, the CPU seems noticeably
under 100% (may be 60-80) ...

Isn't this another way to make less noise and heat ?

So, question : why isn't this setting accessible on Linux ?

Cheers,

Jean-Philippe.

Hi, all.

As a consequence of the "no maximum module interfaces" patch,
this is the updated version of the "Cool CPU during config" patch, usefull
only if you want to apply it AFTER the "no maximum module interfaces" one.

Yours,

Jean-Philippe.

Hi, all, again.

As promised, this is the second half of the "no maximum number of interfaces for 
Torcs modules" patch (too big for Torcs-devel list).
You can apply it after or before the first half, as you want ... the result will 
be the same.

As an illustration, and also an example of how to use the new feature
in a robot code, you will also find a patch that adds an 11'th car
to the "bt" robot (I could not keep myself from choosing the Ford GT 40 Concept,
with its so gorgeous sound !).

Please, test it and tell me what you think !
Feel free to comment, propose more, ...

Cheers,

Jean-Philippe.

PS: Tested on Linux Mandriva 2008.0 GCC 4.2.2 rc x86_64
           and Windows XP SP2 VC6 SP6

Hi, all.

This time, I've got it : this is the "no maximum number of interfaces for Torcs
modules" patch.

WARNING: This is only the first half of the patch (too big for Torcs-devel 
list); next half comes in the following message ...

It enable developper to write Torcs modules with any (positive) number of
interfaces ; as far as robots are concerned, it means any number of cars.

It is completely backward compatible with already written modules
(they can continue to have a maximum of 10 interfaces), as it does not change
nor the API nor the awaited behaviour of the module entry point
"int <module name>(tModInfo*)".
And even with robots that are written in other languages, as tModInfo structure
did not change.
As for the backward binary compatibility, I suppose it should be possible,
but I did not paid attention to the various modified DLL entries order.
May be there some little work on this side, if anyone need's it ...

If you want to write a module with more (or less) maximum number of interfaces,
you only have to add a new entry "int <module name>MaxNbItf()" in the module
code, and make that entry return the desired number.
Torcs TGF infrastructure uses that number to allocate the tModInfo array,
at module load time, taking a default 10 value when the new entry is not there.
The deallocation is also in charge of the TGF infrastructure.

I have not changed the published robots code in this patch (but see below, yet).
But I have "upgraded" all the other Torcs modules (ssggraph, track, telemetry,
simuv2 an simuv3), of course to save the huge amount of wasted memory, as these
module only have 1 interface ;-)

I have also upgraded the "human" module to enable any number of human drivers.

And also upgraded the driverconfig screen to make full use of the enhancement
(mainly added the vertical scrollbar for the driver scrolllist and a "new"
button to create a driver).
And also, even it was not absolutely necessary, I made the following improvements :
- added the "copy" button, to copy ANY driver settings (control settings and
calibration inluded),
- fixed the general OK/Cancel behaviour of the 4 screens driverconfig,
controlconfig, mousecoonfig and joystickconfig : now, when you cancel anywhere,
the modifications you made can't be saved in the preferences.xml file.

Also fixed some memory-leaks associated to modules interfaces management.

As an illustration, and also an example of how to use the new feature
in a robot code, you will also find a patch that adds an 11'th car
to the "bt" robot (I could not keep myself from choosing the Ford GT 40 Concept,
with its so gorgeous sound !).

Please, test it and tell me what you think !
Feel free to comment, propose more, ...

Cheers,

Jean-Philippe.

-- 
Annick MICHEL
Jean-Philippe MEURET
Place de l'Eglise
63260 Saint-Agoulin
Tél: 04 73 33 36 02

Hi,

If anyone is interested in testing the package, you can find a link  
to it here.

http://publish.uwo.ca/~shudson2/Home/Blog/ 
00505B56-1583-49F6-8AA4-097278E65A9C.html

Steve

On 16-Apr-08, at 10:58 AM, Stephen D. Hudson wrote:

> Hi,
>
> I have a mac package ready to go.  It is version 1.3.0 for PPC (would
> likely work on Intel) and OS X 10.3.9 or later.  Everything it needs
> is included inside the package and the only thing missing is the
> lliaw robot, as I couldn't compile it.  I should be able to create a
> universal binary for 10.4, but I will wait and make sure there are no
> problems with the package.  It would take more work to compile this
> for 10.2.8.
>
> Where can the package go?
>
> Steve
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http:// 
> java.sun.com/javaone
> _______________________________________________
> Torcs-devel mailing list
> Tor...@li...
> https://lists.sourceforge.net/lists/listinfo/torcs-devel

------------------------------------------------------------------------ 
------------------------------------
Stephen Hudson                                          Lab:      
(519) 661-2111 x85035
Department of Physics and Astronomy    Office:  (519) 661-2111 x86436
The University of Western Ontario            Web:    http:// 
publish.uwo.ca/~shudson2
London, ON, N6A 3K7                                Email:   
shu...@uw...
------------------------------------------------------------------------ 
------------------------------------

Hi,

	I'm involved in a research project for an urban driving simulator,
which will be based on torcs. The first challenge I must face is the
crossing roads, as far as I know, tracks on torcs are represented as a
linked list of segments (straight or left/right turns), the track must
be closed and each segment must be linked to its previous and next.

	Well, my idea is to create a special segment for crossing (only 2-road
perpendicular crossing for now), I'll have to modify the XML definition,
telling what segments come out from each of the 4 sides of the crossing,
then change the track segment class by adding the extra information on
the crossings, the XML track loader in order to link the list properly,
the race engine, so when you are leaving a crossing you'll jump to the
segment pointed to by the XML, not to the trk->seg->next segment, and
eventually the collide() function of the uvsim. Am I right?

	I'll have also to modify the trackeditor to get a visual representation
of crossing and avoid the madness of editing manually the XML.
	I must dig a little more in the code, but any help would be greatly
appreciated.

	Has anyone done anything like that?

	Thanks in advance!

	Mike

Hi,

I have a mac package ready to go.  It is version 1.3.0 for PPC (would  
likely work on Intel) and OS X 10.3.9 or later.  Everything it needs  
is included inside the package and the only thing missing is the  
lliaw robot, as I couldn't compile it.  I should be able to create a  
universal binary for 10.4, but I will wait and make sure there are no  
problems with the package.  It would take more work to compile this  
for 10.2.8.

Where can the package go?

Steve

Hi, all.

Is there any reason for setup_win32.bat and setup_win32_debug.bat
being nearly the exact copy one of the other ?
Same question about setup_win32-data-from-CVS.bat and 
setup_win32-data-from-CVS_debug.bat ?
Last, is there any reason for having so much redundant lines
in these files ?

I suppose the answer to these 3 question is : they were generated automatically ...
But may be there is another reason ...

I propose to change them in the following ways, in order so make maintenance 
simpler, quicker and less error-prone :
- make the _debug version call the non debug one with a string parameter
   whose value would be "runtimed" (of course, "runtime" by default)
- eliminate useless lines
- have exactly one instance of each file name to copy in each .bat file
   (and not 3, like now).


Do you have any objection, better suggestion ?

Cheers,

Jean-Philippe.

Hello Wolf-Dieter (and others),

Op Monday 14 April 2008 17:54:18 schreef Wolf-Dieter Beelitz:
> Hello all,
>
> I found this message about a security bug in libpng.
>
> http://libpng.sourceforge.net/Advisory-1.2.26.txt
>
> Cheers
>
> Wolf-Dieter

I think Torcs doesn't have this issue, because it doesn't have the third 
condition. After grepping through the source code, there doesn't seems to be 
any call to png_set_read_user_chunk_fn or png_set_keep_unknown_chunks.

Regards,

Mart

Hello all,

I found this message about a security bug in libpng.

http://libpng.sourceforge.net/Advisory-1.2.26.txt

Cheers

Wolf-Dieter

On 9-Apr-08, at 10:34 PM, Stephen D. Hudson wrote:
>> I don't remember any special problems getting display settings
>> working, but the sound was simply a matter of linking to the
>> openal framework.  Plib also provides a sound mechanism - does
>> that not work for you either?  Sorry I can't help much other than
>> ask questions; hopefully other people with Macs will volunteer :)
>>
>> cheers
>> Andrew
>
> Okay, maybe the problems aren't as bad as they look.  It is  
> possible the display settings problem is due to a misplaced  
> configuration file, but I thought I had them all in the right  
> places.  I'll post the errors I get with sound, maybe they can be  
> fixed too.  There is a problem with conflicting class names that I  
> tried to fix.  It is possible that I caused the second problem  
> while trying to fix this one.  The second error was basically the  
> same for the OpenAL sound interface and the plib sound interface.

The class SoundSource conflicts with a system framework that plib  
links against on Mac.  I had renamed this to TorcsSoundSource but I  
didn't change all of the code where the class was instantiated and  
that was causing the problems.  After correcting this, sound works.

I can change display settings, but only if the application is  
launched from the terminal or from within XCode.  If it is launched  
by Finder, it crashes when trying to apply the new settings.  
Apparently Finder does something funny with argv.  Is anyone familiar  
with this?

Steve

Hello Jean-Philippe (and others),

Op Sunday 13 April 2008 11:12:30 schreef Annick et Jean-Philippe:
> Hi, Mart, Wolf-Dieter and all.
>
> Even better, may be :
> - again, 2 kinds of modules :
>    * the the current one, with a maximum of 10 interfaces
>    * a new one, with unlimited nb of interfaces
> - the first kind is totally unchanged
> - the second kind keeps its 'extern "C" void <module name>(tModInfo*)'
> entry point, with usual implementation
>    but it has a new 'extern "C" unsigned int <module name>_NbItf()' DLL
> function that simply returns the number of interfaces it publishes
>    (= number of cars for a robot)

I agree that this is a better idea.

> At module load time,
>    1) TGF checks first for the second entry point
>    2) if it finds it, it calls it and get the real number of interfaces
>    3) if it does not find it, it assumes this number is MAX_MOD_ITF (10)
>    4) then it dynamically allocates the array of tModInfo
>       with the determined size, and pass it to the normal entry point
>
> Advantages :
> - no dynamic allocation by the modules => less potential issues with
> alloc/free done with different C libs ...
> - even less changes in robots/modules code
>
> Flaws :
> - ??? => tell me !

I don't see any at the moment.

> Cheers,
>
> Jean-Philippe.

Regards,

Mart

Hi, Mart, Wolf-Dieter and all.

>> I undersand that it could be big issue to break the pure-C interface,
>> so, I gave up the "std::vector" solution, and I'm currently working
>> on a pure-C one :
>> - the tModInfo array would be allocated on the heap by the module itself,
>>    at DLL load-time, in its "Module entry point" function
>>    (whose signature would become : extern "C" int xxx(tModInfo**))
>> - it would be freed by the module unloading functions in tgf lib.
> 
> I see a (small) problem with this. It is not given that the robot is compiled 
> with the same compiler as the rest of the code. If a piece of code is 
> allocated with the _tgf_win_malloc function in tgf.cpp, you can't free it 
> with the normal free function. So, in my opinion, it must be forced to use 
> the malloc function matching with the free function. I think that is best 
> done if the reallocation is done in a function.

Even better, may be :
- again, 2 kinds of modules :
   * the the current one, with a maximum of 10 interfaces
   * a new one, with unlimited nb of interfaces
- the first kind is totally unchanged
- the second kind keeps its 'extern "C" void <module name>(tModInfo*)' entry 
point, with usual implementation
   but it has a new 'extern "C" unsigned int <module name>_NbItf()' DLL function
   that simply returns the number of interfaces it publishes
   (= number of cars for a robot)

At module load time,
   1) TGF checks first for the second entry point
   2) if it finds it, it calls it and get the real number of interfaces
   3) if it does not find it, it assumes this number is MAX_MOD_ITF (10)
   4) then it dynamically allocates the array of tModInfo
      with the determined size, and pass it to the normal entry point

Advantages :
- no dynamic allocation by the modules => less potential issues with alloc/free
   done with different C libs ...
- even less changes in robots/modules code

Flaws :
- ??? => tell me !

Cheers,

Jean-Philippe.

Hello, Mart, and all.

>> May be another reason to feel that a MinGW port would be great ;-)
> 
> I also have an idea about this. At the moment, there are two seperate build 
> systems (one for Linux and one for Windows). If those two are merged with a 
> build tool like CMake, a MinGW port is much easier.
> 
> Of course, the huge disadvantage of this is the huge amount of work required 
> to write and test it (especially the test part).

May be the current Unix build system (configure, make) would also be OK
on Windows with the Cygwin/MingGW couple ?

As for CMake, you're right, it's a powerfull build system, and far more 
multi-platform than we need ... but there would be some work to switch !
And I'm not sure this is the real priority now ...

Anyway, to be back on the Windows VC 6 build, I'm pretty sure we'll have
at least to come to use multi-threaded DLL run-time lib one day,
and may be the SDL port will be the trigger.
And for sure, there will be no other choice for the internet gaming project ...

Regards,

Jean-Philippe.

Hi, Mart, Wolf-Dieter, and all.

So, if I try and sum up on the 10-limit core subject :
- we must be carefull with memory allocation, and use standard lib C
   malloc/calloc/free function, in order to continue to be able
   to compile robots with another compiler than the rest of Torcs
   (a kind of binary compatibility ?).
- this is even more true for robots that are developped
   with other languages than C (Delphi is an example).
- it would be great if there was no need to change a single bit
   in existing robots/modules if they don't want the unlimited
   number of cars/interfaces facility.

Thinking about these constraints, I had an idea :
- have TGF support 2 kinds of modules :
   * the current one, with a maximum of 10 interfaces
   * a new one, with unlimited nb of interfaces
- the first kind is totally unchanged
- the second kind don't have
   the 'extern "C" <module name>(tModInfo*)' entry point,
   but this one : extern "C" <module name>_uni(tModInfo**)
   (UNI for Unlimited Number of Interfaces)
- at module load time,
   1) TGF checks first for the second entry point
   2) if it finds it, it calls it
      (this entry points dynamically allocates its array of tModInfo
       whatever its size ; the array has 1 more null element at the end,
       to expose its "length without any special new field)
   3) if it does not find it, it then checks for the "old" 1st one
   4) if it finds it, it dynamically allocates a 10-long array of tModInfo
      and pass it to the found entry point
- of course, at unload time, there are some different little things to do
   in order to free memory, whether we have an "old-style" module,
   or a "new-style" one, so I must add a "ModuleType" field in tModInfo
   to keep this in mind ...
- the dynamic allocations are made in a new cpp file that does not
   include tgf.h, and so, don't know anything about _tgf_win_xxx replacements
   of standard libc malloc/calloc/strdup/free functions under windows.

This way :
- no change needed for any robot that don't want more than 10 cars
   (as for the other modules of Torcs like simuv2, simuv2, ssggraph, track,
    telemetry ; on the contrary, human will have it, of course !)
   (I'm not completly sure, but it seems that there should even be no need
    to recompile robots DLLs for them to work with modified torcs binaries ...)
- if a robot wants more than 10 cars, just need to change its module entry point
   to xxx_uni and do the new allocation job. That's all.

I'm currently testing this solution (so far, it works like a charm under Linux).
If you are interested, just for comments (work in progress), please find 
attached new TGF files modinfo.h/cpp (.h included by tgf.h), modified tgf.h, 
modified bt.cpp for a 11'th car and modified linuxspec.cpp
(windowsspec.cpp still to complete).

Please tell me if it meets your expectations, and feel free to comment.

Regards,

Jean-Philippe.

PS: Wolf-Dieter, your last mail introduces lots of questions/requests
     around the 10-limit subject, and I'll try and look at them, but later,
     when the core subject will be completed ;-)

Hi Steve, and all.

> Quick question: Are people compiling Torcs on linux with gcc 4?

Yes, I use gcc 4.2.2 20070909 (prerelease) (on Mandriva 2008.0)

Regards,

Jean-Philippe

Eric Espie wrote:
> I made 3D wheels for all the cars in CVS based on the current wheel texture.
> I also fixed the problem about the specular color I introduced with the 
> 3D wheel code.
>
>   
That is excellent Eric, thanks a lot!

I made 3D wheels for all the cars in CVS based on the current wheel texture.
I also fixed the problem about the specular color I introduced with the 
3D wheel code.

Have fun,
Eric.

Hi Steve (and others),

Op Thursday 10 April 2008 04:34:23 schreef Stephen D. Hudson:
> Quick question: Are people compiling Torcs on linux with gcc 4?

Yes, I use gcc-4.1.2.

Regards,

Mart

Hi Jean-Philippe.

Op Wednesday 09 April 2008 19:48:18 schreef Annick et Jean-Philippe:
> Hi, Mart, and all.
>
> I undersand that it could be big issue to break the pure-C interface,
> so, I gave up the "std::vector" solution, and I'm currently working
> on a pure-C one :
> - the tModInfo array would be allocated on the heap by the module itself,
>    at DLL load-time, in its "Module entry point" function
>    (whose signature would become : extern "C" int xxx(tModInfo**))
> - it would be freed by the module unloading functions in tgf lib.

I see a (small) problem with this. It is not given that the robot is compiled 
with the same compiler as the rest of the code. If a piece of code is 
allocated with the _tgf_win_malloc function in tgf.cpp, you can't free it 
with the normal free function. So, in my opinion, it must be forced to use 
the malloc function matching with the free function. I think that is best 
done if the reallocation is done in a function.

> I will propose you the patch when I'm ready (and sure it runs OK on
> Windows).
>
> About the Delphi robots, I would appreciate more info on the way
> they are done, in order to make any modification as simplest as possible
> for them. Wolf-Dieter, if you read me ... Or anyone else knowing it.
>
> Cheers,
>
> Jean-Philippe.

Regards,

Mart

> I don't remember any special problems getting display settings
> working, but the sound was simply a matter of linking to the
> openal framework.  Plib also provides a sound mechanism - does
> that not work for you either?  Sorry I can't help much other than
> ask questions; hopefully other people with Macs will volunteer :)
>
> cheers
> Andrew

Okay, maybe the problems aren't as bad as they look.  It is possible  
the display settings problem is due to a misplaced configuration  
file, but I thought I had them all in the right places.  I'll post  
the errors I get with sound, maybe they can be fixed too.  There is a  
problem with conflicting class names that I tried to fix.  It is  
possible that I caused the second problem while trying to fix this  
one.  The second error was basically the same for the OpenAL sound  
interface and the plib sound interface.

Quick question: Are people compiling Torcs on linux with gcc 4?

Cheers,

Steve