Re: Breaking the 10-limit : Problems/Questions for Windows build

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 ;-)

-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/torcs-devel