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

Bernhard Wymann wrote:
> 
> hi all
> 
> i got the latest cvs version (after i got the mail) and tried to build
> under windows. but it fails because it doesn't find the header files
> (eg. tgf.h, ...). is anywehre a README or something with some hints?
> 
> to the version (tested under linux, obiously;-)):
> - the shadow needs still improvment, because now it obscures parts of
> the wheels and the car, looks very ugly.
> - smoke should change color to brown abroad (in the grass) combined with
> some paricles flying around, because friction is to small for smoke,
> it's more flying dirt and grass.
> - the cars get stuck in grass when they come to stop there, and just
> hang in the grass.

I should check that, I changed the rolling resistance in the simulation
so the cars and wheels are less shaking at rest... I have to check 
on different surfaces.

> - the dammages are quite tough now, hard times to survive a race.

Didn't change that part... but the robots maybe more aggressive now.

> 
> all in all it's very nice, most i like the new smoke:-) cool.

yes, and the skidmarks are promising too from what I have seen
from Christophe.

> 
> thank you, bye all, bernhard.

Thanks,
Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                       TORCS
            The Open Racing Car Simulator
                 http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Bernhard Wymann wrote:
> 
> hi all
> finally i managed to read the READMEWIN32.txt. but i could it just read
> under linux, under windows it's crap with the standard editor (notepad).
> then the following problems took place:
> i run setup_win32.bat and setup_win32_debug.bat. after that i tried to
> compile a debug version. there was in the linking stage a missing file
> (i think it was plib), so it didn't build. after that i built a release
> version, that worked then well:-) when i run the wtorcs.exe, i got a
> glut message, "couldn't create rendering context", so i thought there
> was somthing with the included glut32.dll. i simply deleted it, in my
> system folder is already one from the nvidia opengl-sdk. so i tried
> again, and it finally started. i could switch between the menus etc.,
> but when i would like to start a race or practice on every track, a
> memory protection fault popped up. any ideas?
> 
> the last message i see is in the opengl view:
> - loading track 3d description...
> and on the command prompt:
> - loading tracks/e-track-6/background.png
> 
> ah, my system has windows 2000 sp2.

Arg, it was tested only on W98...
I'll try it on W2000.

> 
> bye, bernhard.

Thanks,
Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                       TORCS
            The Open Racing Car Simulator
                 http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

hi all
finally i managed to read the READMEWIN32.txt. but i could it just read 
under linux, under windows it's crap with the standard editor (notepad). 
then the following problems took place:
i run setup_win32.bat and setup_win32_debug.bat. after that i tried to 
compile a debug version. there was in the linking stage a missing file 
(i think it was plib), so it didn't build. after that i built a release 
version, that worked then well:-) when i run the wtorcs.exe, i got a 
glut message, "couldn't create rendering context", so i thought there 
was somthing with the included glut32.dll. i simply deleted it, in my 
system folder is already one from the nvidia opengl-sdk. so i tried 
again, and it finally started. i could switch between the menus etc., 
but when i would like to start a race or practice on every track, a 
memory protection fault popped up. any ideas?

the last message i see is in the opengl view:
- loading track 3d description...
and on the command prompt:
- loading tracks/e-track-6/background.png

ah, my system has windows 2000 sp2.


bye, bernhard.

hi all

i got the latest cvs version (after i got the mail) and tried to build 
under windows. but it fails because it doesn't find the header files 
(eg. tgf.h, ...). is anywehre a README or something with some hints?

to the version (tested under linux, obiously;-)):
- the shadow needs still improvment, because now it obscures parts of 
the wheels and the car, looks very ugly.
- smoke should change color to brown abroad (in the grass) combined with 
some paricles flying around, because friction is to small for smoke, 
it's more flying dirt and grass.
- the cars get stuck in grass when they come to stop there, and just 
hang in the grass.
- the dammages are quite tough now, hard times to survive a race.

all in all it's very nice, most i like the new smoke:-) cool.

thank you, bye all, bernhard.

Hi All,

A beta of the current sources of TORCS is available
here: http://torcs.org/tmp/wtorcs-devel-1.0.1.tgz (15MB)

The changelog is:

- Win32 port (projects for VC++6.0 included) sorry
  for Rémi and Bernhard but a lot of robots are not
  yet ported. read the READMEWIN32.txt for the compil
  info.

- Smoke

- mouse control of the player's car when no joystick
  is available

- the cool McLaren skins (in gimp format with layers !
  look in data/cars/models/mclaren-f1/*.xcf)

- A new car: 360 modena, but the skin is not yet done.

- For Linux only, a lap by lap graph is done at the end
  of the race -> see results/res.png

All of this is unfinished, but worth a look.

Have fun,
Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                       TORCS
            The Open Racing Car Simulator
                 http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Hi,

Bernhard Wymann wrote:
> 
> hi all
> 
> i would like also to put some comments/thoughts to the torcs future.
> 
> > Simulation:
> > -----------
> >   Tires:
> >       - different types of tires for different surfaces
> >       - more stability in tire reaction
> >       - tire temperature and wear
> >       - tire pressure
> >       - camber
> 
> i think the only things worth to implement are tire temperature and
> wear. why that? so, already now, you have a lot of parameters on the car
> you can change, and if we add more it will become very hard to find a
> near optimal setup. why? think of all free car parameters (say N) as
> parameters on an N-dimensional function, and consider the optimal setup
> as the minimum or maximum of this function. while it's easy to get
> minima or maxima for 2 dimensions it becomes REALLY difficult in higher
> dimensions, because for eg. N=10 you have one minimum, one maximum and
> if you have a "bad" function 2^10-2 = 1022 saddle points, and a huge
> number of local minima/maxima. so, the chance to get the optimal setup
> becomes really small, because we already have much more than 10 parameters.

It is possible by the use of the categories definitions to limit the parameters
modifications, so races can be restrained to specific categories allowing
very few parameters change.
But, by allowing the parameters modifications it is possible to play on the
two sides, the robot driving abilities and the settings of the cars, that's
two ways of improving the lap time.

I know that I have a HUGE documentation effort to produce about how to
configure the cars and every other points relative to the robots.

> 
> >
> >   Transmission:
> >       - better equations for differentials and better support of 4WD
> 
> didn't have a look on them, no comment.

It's just that I'm not happy with the current implementation.

> 
> >
> >   Suspensions:
> >       - limit the suspension effect (no more jumps on michigan...)
> 
> didn't have a look on it, no comment. it's just a bit funny if the cars
> fly around;-)
> 
> >
> >   Aero:
> >       - better configuration (try to find other name for wings...)
> 
> i have a feeling that also the aerodynamics-equations need improvment:
> if you put the car on the front axis say 50 mm above the ground, and on
> the rear at 150 mm there should be kind of a "diffusor" effect, i miss that.

This is also a point to improve, I agree.

> 
> >
> >   Damages:
> >       - localisation of dammages
> >       - effects on car 3D body
> >       - effects on wheels, engine, ...
> 
> i think that's very cool, but not really urgent.
> 
> >
> >   Weather:
> >       - rain, snow, ice, temperature, wind...
> 
> this is also nice, but will be not too easy to handle with the bots. i
> think on changing conditions during the race. hmm, will the be a module
> called libracestewards.so (simulating the stewards, responsible for the
> rules and safety), which will send the pace car on the track, when the
> rain becomes too hard or too much wrecks are on the race track? (just as
> idea...);-)

Interresting

> 
> >   Tracks:
> >       - temperature, adherence modification on the cars path
> >       - borders
> >       - not only circuit but also open roads
> >       - documentation on the track format (a tutorial ?)
> 
> >
> > Races:
> > ------
> >       - flag management for the robots (blue, yellow, red, black...)
> >         - race rules (like speed limit in the pit lane...)
> >       - pace car
> >       - different start procedures (warming lap, start from rest or behind pace car)
> >       - championship modes and season management
> >       - qualif sessions
> >       - results and record saving
> >
> > Teams:
> > ------
> >       - group robots in teams
> >       - play the "team manager":
> >               The team manager can send orders to the robots
> >               and can receive information messages from the robots.
> >               you can take decisions like slow down / pit / don't pit...
> >
> > Robots:
> > -------
> >       - different classes of robots: from beginner to "wizard" (thx berniw)
> >         to allow beginners to write new robots
> >       - Communication with "team manager" (see network races)
> >       - tutorials
> 
> hmm, all the gameplay features, which would make the games nice for
> humans, will make it very hard for the bots... i think you should really
> think about, if you want to go towards a racing game for humans, where
> the bots are "faked" (like in commercial games), or towards a bot racing
> game, where the environment stays quite easy. aginst going toward a
> "normal" racing game is IMHO, there is already a great one, look at
> http://www.marketgraph.nl/gallery/racer. looks ok, doesn't it?
> 
> >
> > Telemetry:
> > ----------
> >       - more easily customizable telemetry and more integrated to the program,
> >         it currently uses gnuplot too draw the figures
> 
> this would be of high value.
> 
> >
> > Network and replay:
> > -------------------
> >       - network play for humans
> >       - store replay of races
> >
> > Network races:
> > --------------
> >       - play team manager by network, so you can participate to robots races.
> >
> > Graphic & Sound:
> > ----------------
> >       - enhance graphic quality, framerate (LOD)
> >       - multitexture / bump mapping for cars (PLIB)
> >         - skid marks and smoke
> >       - mirror in driver view (PLIB)
> >       - configurable on-screen information (position and content)
> >       - custom dashboard
> >       - better sound (OpenAL) 3D (engine, rolling, transmission, wind, skid, collisions)
> 
> all nice, but most important IMHO are improving speed (LOD) and better
> sound.
> 
> >
> > GUI:
> > ----
> >       - better menu navigation for player configuration
> >       - display of the cars pictures and info on selection screen
> >       - display of the tracks pictures and info on selection screen
> >       - allow the player to choose the color of the car
> >       - cars settings screen
> >
> >
> 
> display of the cars in the selection would be nice, eg. rotating on a
> nice presentation plane, lots of reflections and some technical data
> like engine characteristics, etc. and similar the the tracks.

I agree that at least the characteristics of the cars or tracks
should be displayed on the selection screens.

> 
> what i missed above:
> 
> - to get high quality pictures, the texture size of the cars sould be at
> least 1024x1024 under use of s3tc where available. if there is lack of
> memory on the graphics board, one could generate automaticly lower
> resolution textures (perhaps you do already for mipmapping?)
> 
> - enhanced graphics configuration menu, where you can switch eg.
> environment mapping on and off, you can choose a smaller visibility
> range, 16 or 32 bit textures, etc.
> 
> - "real" shadows (everything on everything) with "shadow mapping" (needs
>   just multipass rendering or some extensions, no projection matrices to
> the floor or something like that). disadvantage: CAN become quite blocky
> near the camera (depends on Z-buffer resolution and Z-far/Z-near).
> 
> - better environment (looks very artificial), could we borrow the
> clouds/weather partially from flight gear? better trees, etc. i think
> this will be possible, if we get free recources from LOD (i expect
> really a boost from that).

I leave the graphic part to Christophe, he has a lots of ideas on the subject.

> 
> - moving parts on the car (not just wheels) eg. suspension, for formula
> one cars.
> 
> - a cool intro (not a film) rendered by torcs from a replay/replays with
> music (look at the parsec demo, it's quite cool IMHO).

Need to implement the replay first ;-)

> 
> - tire changing in pits (obvious, but not availible yet, because not needed)
> 
> - graphical configuration screen for robot parameter files.
> 
> - use of multithreading, split of (at least) rendering/simulation.

May be shared with network client/server split.

> 
> - small release cycles, so that torcs pops up often in news ( all 2 or 3
> months).
> 
> ok, what would i put on the task list as project manager for the near
> future?:
> 
> 1. finish and integrate the windows port.

This point is currently in progress, this is the current task.

> 2. documentation, tutorial bot and track, to get more audience.

This one should be in high priority, and all the help is welcome.

> 3. testing, release 1.1.
> 
> 4. tire wearing & temperature, tire changing in pit.

This will change the grip of the cars, so the robots will have to face 
a new problem...

> 5. level of detail.

I am thinking about this as the next task.

> 6. better sound.

Christophe is in charge of the graphic and sound enhancements.

> 7. testing release 1.2.
> 
> 8. decision where to go -> robot/human/network etc.
> 9. version 2.0 todo document.
> 
> final remarks:
> 
> the direction i would prefer is toward an even greater robot simulation,
> great sound, great graphics, etc. why i don't need another "human"
> racing game? simple, because there are already a lot commercial games
> for windows, PS2 (have you seen GT3 graphics? i can just say:
> ooooooooooooooooh, great), ..., which are really great, and there is an
> open source competitor, the racer, which i think looks also great. what
> do you think about that?
> 
> bye, bernhard.

The direction is clearly towards the robot simulation.
The idea is not to be another racing game, but the ability to
drive was done to test the simulation itself.
When you drive yourself you found more easily the simulation
problems, because the robots tends to "compensate" when
the simulator is not accurate, and problems can be masked.
For example, the robots are really better that human when
driving unstable cars.

Maybe, it can convince new people after trying the human part
that it could be fun to program a robot, no ?

Thanks for the comments,
Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                       TORCS
            The Open Racing Car Simulator
                 http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

hi all

i would like also to put some comments/thoughts to the torcs future.

> Simulation:
> -----------
>   Tires:
> 	- different types of tires for different surfaces
> 	- more stability in tire reaction
> 	- tire temperature and wear
> 	- tire pressure
> 	- camber


i think the only things worth to implement are tire temperature and 
wear. why that? so, already now, you have a lot of parameters on the car 
you can change, and if we add more it will become very hard to find a 
near optimal setup. why? think of all free car parameters (say N) as 
parameters on an N-dimensional function, and consider the optimal setup 
as the minimum or maximum of this function. while it's easy to get 
minima or maxima for 2 dimensions it becomes REALLY difficult in higher 
dimensions, because for eg. N=10 you have one minimum, one maximum and 
if you have a "bad" function 2^10-2 = 1022 saddle points, and a huge 
number of local minima/maxima. so, the chance to get the optimal setup 
becomes really small, because we already have much more than 10 parameters.

> 
>   Transmission:
> 	- better equations for differentials and better support of 4WD


didn't have a look on them, no comment.

> 
>   Suspensions:
> 	- limit the suspension effect (no more jumps on michigan...)


didn't have a look on it, no comment. it's just a bit funny if the cars 
fly around;-)

> 
>   Aero:
> 	- better configuration (try to find other name for wings...)


i have a feeling that also the aerodynamics-equations need improvment: 
if you put the car on the front axis say 50 mm above the ground, and on 
the rear at 150 mm there should be kind of a "diffusor" effect, i miss that.

> 
>   Damages:
> 	- localisation of dammages
> 	- effects on car 3D body
> 	- effects on wheels, engine, ...


i think that's very cool, but not really urgent.

> 
>   Weather:
> 	- rain, snow, ice, temperature, wind...


this is also nice, but will be not too easy to handle with the bots. i 
think on changing conditions during the race. hmm, will the be a module 
called libracestewards.so (simulating the stewards, responsible for the 
rules and safety), which will send the pace car on the track, when the 
rain becomes too hard or too much wrecks are on the race track? (just as 
idea...);-)


>   Tracks:
> 	- temperature, adherence modification on the cars path
> 	- borders
> 	- not only circuit but also open roads
> 	- documentation on the track format (a tutorial ?)

> 
> Races:
> ------
> 	- flag management for the robots (blue, yellow, red, black...)
>         - race rules (like speed limit in the pit lane...)
> 	- pace car
> 	- different start procedures (warming lap, start from rest or behind pace car)
> 	- championship modes and season management
> 	- qualif sessions
> 	- results and record saving
> 
> Teams:
> ------
> 	- group robots in teams
> 	- play the "team manager":
> 		The team manager can send orders to the robots
> 		and can receive information messages from the robots.
> 		you can take decisions like slow down / pit / don't pit...
> 		
> Robots:
> -------
> 	- different classes of robots: from beginner to "wizard" (thx berniw)
> 	  to allow beginners to write new robots
> 	- Communication with "team manager" (see network races)
> 	- tutorials


hmm, all the gameplay features, which would make the games nice for 
humans, will make it very hard for the bots... i think you should really 
think about, if you want to go towards a racing game for humans, where 
the bots are "faked" (like in commercial games), or towards a bot racing 
game, where the environment stays quite easy. aginst going toward a 
"normal" racing game is IMHO, there is already a great one, look at 
http://www.marketgraph.nl/gallery/racer. looks ok, doesn't it?

> 
> Telemetry:
> ----------
> 	- more easily customizable telemetry and more integrated to the program,
> 	  it currently uses gnuplot too draw the figures


this would be of high value.

> 
> Network and replay:
> -------------------
> 	- network play for humans
> 	- store replay of races
> 
> Network races:
> --------------
> 	- play team manager by network, so you can participate to robots races.
> 
> Graphic & Sound:
> ----------------
> 	- enhance graphic quality, framerate (LOD)
> 	- multitexture / bump mapping for cars (PLIB)
>         - skid marks and smoke
> 	- mirror in driver view (PLIB)
> 	- configurable on-screen information (position and content)
> 	- custom dashboard
> 	- better sound (OpenAL) 3D (engine, rolling, transmission, wind, skid, collisions)


all nice, but most important IMHO are improving speed (LOD) and better 
sound.

> 
> GUI:
> ----
> 	- better menu navigation for player configuration
> 	- display of the cars pictures and info on selection screen
> 	- display of the tracks pictures and info on selection screen
> 	- allow the player to choose the color of the car
> 	- cars settings screen
> 
> 

display of the cars in the selection would be nice, eg. rotating on a 
nice presentation plane, lots of reflections and some technical data 
like engine characteristics, etc. and similar the the tracks.


what i missed above:

- to get high quality pictures, the texture size of the cars sould be at 
least 1024x1024 under use of s3tc where available. if there is lack of 
memory on the graphics board, one could generate automaticly lower 
resolution textures (perhaps you do already for mipmapping?)

- enhanced graphics configuration menu, where you can switch eg. 
environment mapping on and off, you can choose a smaller visibility 
range, 16 or 32 bit textures, etc.

- "real" shadows (everything on everything) with "shadow mapping" (needs 
  just multipass rendering or some extensions, no projection matrices to 
the floor or something like that). disadvantage: CAN become quite blocky 
near the camera (depends on Z-buffer resolution and Z-far/Z-near).

- better environment (looks very artificial), could we borrow the 
clouds/weather partially from flight gear? better trees, etc. i think 
this will be possible, if we get free recources from LOD (i expect 
really a boost from that).

- moving parts on the car (not just wheels) eg. suspension, for formula 
one cars.

- a cool intro (not a film) rendered by torcs from a replay/replays with 
music (look at the parsec demo, it's quite cool IMHO).

- tire changing in pits (obvious, but not availible yet, because not needed)

- graphical configuration screen for robot parameter files.

- use of multithreading, split of (at least) rendering/simulation.

- small release cycles, so that torcs pops up often in news ( all 2 or 3 
months).


ok, what would i put on the task list as project manager for the near 
future?:

1. finish and integrate the windows port.
2. documentation, tutorial bot and track, to get more audience.
3. testing, release 1.1.

4. tire wearing & temperature, tire changing in pit.
5. level of detail.
6. better sound.
7. testing release 1.2.

8. decision where to go -> robot/human/network etc.
9. version 2.0 todo document.


final remarks:

the direction i would prefer is toward an even greater robot simulation, 
great sound, great graphics, etc. why i don't need another "human" 
racing game? simple, because there are already a lot commercial games 
for windows, PS2 (have you seen GT3 graphics? i can just say: 
ooooooooooooooooh, great), ..., which are really great, and there is an 
open source competitor, the racer, which i think looks also great. what 
do you think about that?

bye, bernhard.

Christophe Guionneau wrote:
> 
> hello,
> 
> Marc Gueury wrote:
> 
> > It is just a wishlist:
> > Building system
> > ----------------
> > But I would firstly like a easier system to run/build Torcs.
> > I do not see the reason to have 2 type of directory structures,
> > one for building Torcs, and one to run it.
> >
> 
> May be for having a binary+data delivery more easy than delivery the full source tree. It is the case
> for the Win32 binary delivery, the directory structure for the running game is built during the
> compilation process. Binary,  dlls and data are moved in a separate directory structure and it is easy
> to make an archive with all the necessary files.
> It is true that I did'nt agree with this building philosophy at the early begining, but by the time, it seems
> to be a good solution.

It's a kind of "coding standard" I always use...
It's just easier to distribute binaries only as explained by Christophe.

> 
> > (
> >  Also I know that the answer will be "NO", but if there
> >  were not dynamic libraries, it will be a lot easier
> >  to port the code to another platform
> > )
> > -> My own crittics about that : there is a system that works now very well
> > -> Leave it like it is :-)
> > The goal of all this is to have for example an Kdevelop or VC++ project
> > easily  "debugable", "compilable" in an IDE. (I am not a fan of emacs and vi)
> >
> I did part of the WIN32 port, and of course the built post-processes are not easy to tune, but in fine
> it works now very well.
> But, even on WIN32, I use emacs ;=)

I have the goal (the dream ?) to distribute a robot development environment 
allowing you to develop your robot without rebuilding all TORCS, but just your own DLL.
All that with updated documentations, APIs... A project in the project, any volunteers ?

BTW, There will be soon the windows/linux merged sources with VC++ 6.0 projects
based on the work of Christophe.
Maybe I can have a look at Kdevelop, for a robot development environment.

> 
> > Graphics
> > ---------
> > 1) OpenGL lighting for the track and for the cars.
> > 2) Environment mapping for the car.
> >
> There is no light on car, but there is a very "light" environment mapping on the car. This env-map sure must
> be improved, IMHO the cars look plastic !
> 
> > If you want I can help you to implement those.
> > In rars 0.90, (1) is already implemented and I have (2)
> > working in my current implementation.
> > Track
> > ------
> > Have you seen the current track file format of Rars ?
> > - the attribute are set in a different way, the file is a lot shorter
> > - there is the notion of Y.
> >    Imagine the track like a game of "petit train electrique"
> >    To make the rail, you have 3 type of rails
> >    - straight rails
> >    - curve rails (right, left)
> >    - y rails (one direction go straight and the other go right or left)
> >
> The XML file are very flexible, there are easy to expand and refine, but the price is the size.

A track editor would be the solution to the XML complexity... another project in the project...

> The Y type segment has been in project for a long time, but the real difficulty is not to handle a Y track configuration in the description file but in the simultation and in the robot minds.

I thought that the robots and the simulation engine were complex enough without adding multiple paths handling...

> 
> The whishlist is getting longer.
> 
> cgu.
> 
> > Control
> > --------
> > Keyboard control for the cars.
> >
> I hardly encourage eric to implement keyboard control, even if racing with two keys is not easy.

I was thinking about mouse control instead of keyboard control, but maybe 
I'll try both of them.

> 
> I'm working on graphic improvements, things like smokes and skidmarks. And may be,  as
> all real-3D-racing-project, torcs will have unuseful-crappy-lens-flares !
> 
> > Marc


Thanks for your comments,
and Marc, I hope that with the windows port soon available we'll see
your robots on TORCS ;-)

Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                       TORCS
            The Open Racing Car Simulator
                 http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

hello,

Marc Gueury wrote:

>It is just a wishlist:
>
>Building system
>----------------
>But I would firstly like a easier system to run/build Torcs.
>I do not see the reason to have 2 type of directory structures,
>one for building Torcs, and one to run it.
>

May be for having a binary+data delivery more easy than delivery the 
full source tree. It is the case
for the Win32 binary delivery, the directory structure for the running 
game is built during the
compilation process. Binary,  dlls and data are moved in a separate 
directory structure and it is easy
to make an archive with all the necessary files.
It is true that I did'nt agree with this building philosophy at the 
early begining, but by the time, it seems
to be a good solution. 

>
>(
> Also I know that the answer will be "NO", but if there
> were not dynamic libraries, it will be a lot easier
> to port the code to another platform
>)
>-> My own crittics about that : there is a system that works now very well
>-> Leave it like it is :-)
>
>The goal of all this is to have for example an Kdevelop or VC++ project
>easily  "debugable", "compilable" in an IDE. (I am not a fan of emacs and vi)
>
I did part of the WIN32 port, and of course the built post-processes are 
not easy to tune, but in fine
it works now very well.
But, even on WIN32, I use emacs ;=)

>
>Graphics
>---------
>1) OpenGL lighting for the track and for the cars.
>2) Environment mapping for the car.
>
There is no light on car, but there is a very "light" environment 
mapping on the car. This env-map sure must
be improved, IMHO the cars look plastic !

>
>If you want I can help you to implement those.
>In rars 0.90, (1) is already implemented and I have (2)
>working in my current implementation.
>
>Track
>------
>Have you seen the current track file format of Rars ?
>- the attribute are set in a different way, the file is a lot shorter
>- there is the notion of Y.
>   Imagine the track like a game of "petit train electrique"
>   To make the rail, you have 3 type of rails
>   - straight rails
>   - curve rails (right, left)
>   - y rails (one direction go straight and the other go right or left)
>
The XML file are very flexible, there are easy to expand and refine, but 
the price is the size.
The Y type segment has been in project for a long time, but the real 
difficulty is not to handle a Y track configuration in the description 
file but in the simultation and in the robot minds.

The whishlist is getting longer.

cgu.


>
>Control
>--------
>Keyboard control for the cars.
>
I hardly encourage eric to implement keyboard control, even if racing 
with two keys is not easy.

I'm working on graphic improvements, things like smokes and skidmarks. 
And may be,  as
all real-3D-racing-project, torcs will have unuseful-crappy-lens-flares ! 

>
>Marc
>
>Eric Espie wrote:
>
>>Hi all,
>>
>>Here are some directions about TORCS future,
>>I'd like to get some comments on the following list.
>>The list is not ordered...
>>This list reflects the needs for improvements from my point
>>of view:
>>
>>Simulation:
>>-----------
>>  Tires:
>>        - different types of tires for different surfaces
>>        - more stability in tire reaction
>>        - tire temperature and wear
>>        - tire pressure
>>        - camber
>>
>>  Transmission:
>>        - better equations for differentials and better support of 4WD
>>
>>  Suspensions:
>>        - limit the suspension effect (no more jumps on michigan...)
>>
>>  Aero:
>>        - better configuration (try to find other name for wings...)
>>
>>  Damages:
>>        - localisation of dammages
>>        - effects on car 3D body
>>        - effects on wheels, engine, ...
>>
>>  Weather:
>>        - rain, snow, ice, temperature, wind...
>>
>>  Tracks:
>>        - temperature, adherence modification on the cars path
>>        - borders
>>        - not only circuit but also open roads
>>        - documentation on the track format (a tutorial ?)
>>
>>Races:
>>------
>>        - flag management for the robots (blue, yellow, red, black...)
>>        - race rules (like speed limit in the pit lane...)
>>        - pace car
>>        - different start procedures (warming lap, start from rest or behind pace car)
>>        - championship modes and season management
>>        - qualif sessions
>>        - results and record saving
>>
>>Teams:
>>------
>>        - group robots in teams
>>        - play the "team manager":
>>                The team manager can send orders to the robots
>>                and can receive information messages from the robots.
>>                you can take decisions like slow down / pit / don't pit...
>>
>>Robots:
>>-------
>>        - different classes of robots: from beginner to "wizard" (thx berniw)
>>          to allow beginners to write new robots
>>        - Communication with "team manager" (see network races)
>>        - tutorials
>>
>>Telemetry:
>>----------
>>        - more easily customizable telemetry and more integrated to the program,
>>          it currently uses gnuplot too draw the figures
>>
>>Network and replay:
>>-------------------
>>        - network play for humans
>>        - store replay of races
>>
>>Network races:
>>--------------
>>        - play team manager by network, so you can participate to robots races.
>>
>>Graphic & Sound:
>>----------------
>>        - enhance graphic quality, framerate (LOD)
>>        - multitexture / bump mapping for cars (PLIB)
>>        - skid marks and smoke
>>        - mirror in driver view (PLIB)
>>        - configurable on-screen information (position and content)
>>        - custom dashboard
>>        - better sound (OpenAL) 3D (engine, rolling, transmission, wind, skid, collisions)
>>
>>GUI:
>>----
>>        - better menu navigation for player configuration
>>        - display of the cars pictures and info on selection screen
>>        - display of the tracks pictures and info on selection screen
>>        - allow the player to choose the color of the car
>>        - cars settings screen
>>
>>Thanks in advance for your comments,
>>Eric.
>>--
>>=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
>>                       TORCS
>>            The Open Racing Car Simulator
>>                 http://torcs.org
>>=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
>>
>>_______________________________________________
>>Torcs-devel mailing list
>>Tor...@li...
>>https://lists.sourceforge.net/lists/listinfo/torcs-devel
>>
>
>
>_______________________________________________
>Torcs-devel mailing list
>Tor...@li...
>https://lists.sourceforge.net/lists/listinfo/torcs-devel
>

It is just a wishlist:

Building system
----------------
But I would firstly like a easier system to run/build Torcs.
I do not see the reason to have 2 type of directory structures,
one for building Torcs, and one to run it.

(
 Also I know that the answer will be "NO", but if there
 were not dynamic libraries, it will be a lot easier
 to port the code to another platform
)
-> My own crittics about that : there is a system that works now very well
-> Leave it like it is :-)

The goal of all this is to have for example an Kdevelop or VC++ project
easily  "debugable", "compilable" in an IDE. (I am not a fan of emacs and vi)

Graphics
---------
1) OpenGL lighting for the track and for the cars.
2) Environment mapping for the car.

If you want I can help you to implement those.
In rars 0.90, (1) is already implemented and I have (2)
working in my current implementation.

Track
------
Have you seen the current track file format of Rars ?
- the attribute are set in a different way, the file is a lot shorter
- there is the notion of Y.
   Imagine the track like a game of "petit train electrique"
   To make the rail, you have 3 type of rails
   - straight rails
   - curve rails (right, left)
   - y rails (one direction go straight and the other go right or left)

Control
--------
Keyboard control for the cars.

Marc

Eric Espie wrote:

> Hi all,
>
> Here are some directions about TORCS future,
> I'd like to get some comments on the following list.
> The list is not ordered...
> This list reflects the needs for improvements from my point
> of view:
>
> Simulation:
> -----------
>   Tires:
>         - different types of tires for different surfaces
>         - more stability in tire reaction
>         - tire temperature and wear
>         - tire pressure
>         - camber
>
>   Transmission:
>         - better equations for differentials and better support of 4WD
>
>   Suspensions:
>         - limit the suspension effect (no more jumps on michigan...)
>
>   Aero:
>         - better configuration (try to find other name for wings...)
>
>   Damages:
>         - localisation of dammages
>         - effects on car 3D body
>         - effects on wheels, engine, ...
>
>   Weather:
>         - rain, snow, ice, temperature, wind...
>
>   Tracks:
>         - temperature, adherence modification on the cars path
>         - borders
>         - not only circuit but also open roads
>         - documentation on the track format (a tutorial ?)
>
> Races:
> ------
>         - flag management for the robots (blue, yellow, red, black...)
>         - race rules (like speed limit in the pit lane...)
>         - pace car
>         - different start procedures (warming lap, start from rest or behind pace car)
>         - championship modes and season management
>         - qualif sessions
>         - results and record saving
>
> Teams:
> ------
>         - group robots in teams
>         - play the "team manager":
>                 The team manager can send orders to the robots
>                 and can receive information messages from the robots.
>                 you can take decisions like slow down / pit / don't pit...
>
> Robots:
> -------
>         - different classes of robots: from beginner to "wizard" (thx berniw)
>           to allow beginners to write new robots
>         - Communication with "team manager" (see network races)
>         - tutorials
>
> Telemetry:
> ----------
>         - more easily customizable telemetry and more integrated to the program,
>           it currently uses gnuplot too draw the figures
>
> Network and replay:
> -------------------
>         - network play for humans
>         - store replay of races
>
> Network races:
> --------------
>         - play team manager by network, so you can participate to robots races.
>
> Graphic & Sound:
> ----------------
>         - enhance graphic quality, framerate (LOD)
>         - multitexture / bump mapping for cars (PLIB)
>         - skid marks and smoke
>         - mirror in driver view (PLIB)
>         - configurable on-screen information (position and content)
>         - custom dashboard
>         - better sound (OpenAL) 3D (engine, rolling, transmission, wind, skid, collisions)
>
> GUI:
> ----
>         - better menu navigation for player configuration
>         - display of the cars pictures and info on selection screen
>         - display of the tracks pictures and info on selection screen
>         - allow the player to choose the color of the car
>         - cars settings screen
>
> Thanks in advance for your comments,
> Eric.
> --
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
>                        TORCS
>             The Open Racing Car Simulator
>                  http://torcs.org
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
>
> _______________________________________________
> Torcs-devel mailing list
> Tor...@li...
> https://lists.sourceforge.net/lists/listinfo/torcs-devel

Hi all,

Here are some directions about TORCS future,
I'd like to get some comments on the following list.
The list is not ordered...
This list reflects the needs for improvements from my point
of view:

Simulation:
-----------
  Tires:
	- different types of tires for different surfaces
	- more stability in tire reaction
	- tire temperature and wear
	- tire pressure
	- camber

  Transmission:
	- better equations for differentials and better support of 4WD

  Suspensions:
	- limit the suspension effect (no more jumps on michigan...)

  Aero:
	- better configuration (try to find other name for wings...)

  Damages:
	- localisation of dammages
	- effects on car 3D body
	- effects on wheels, engine, ...

  Weather:
	- rain, snow, ice, temperature, wind...

  Tracks:
	- temperature, adherence modification on the cars path
	- borders
	- not only circuit but also open roads
	- documentation on the track format (a tutorial ?)

Races:
------
	- flag management for the robots (blue, yellow, red, black...)
        - race rules (like speed limit in the pit lane...)
	- pace car
	- different start procedures (warming lap, start from rest or behind pace car)
	- championship modes and season management
	- qualif sessions
	- results and record saving

Teams:
------
	- group robots in teams
	- play the "team manager":
		The team manager can send orders to the robots
		and can receive information messages from the robots.
		you can take decisions like slow down / pit / don't pit...
		
Robots:
-------
	- different classes of robots: from beginner to "wizard" (thx berniw)
	  to allow beginners to write new robots
	- Communication with "team manager" (see network races)
	- tutorials

Telemetry:
----------
	- more easily customizable telemetry and more integrated to the program,
	  it currently uses gnuplot too draw the figures

Network and replay:
-------------------
	- network play for humans
	- store replay of races

Network races:
--------------
	- play team manager by network, so you can participate to robots races.

Graphic & Sound:
----------------
	- enhance graphic quality, framerate (LOD)
	- multitexture / bump mapping for cars (PLIB)
        - skid marks and smoke
	- mirror in driver view (PLIB)
	- configurable on-screen information (position and content)
	- custom dashboard
	- better sound (OpenAL) 3D (engine, rolling, transmission, wind, skid, collisions)

GUI:
----
	- better menu navigation for player configuration
	- display of the cars pictures and info on selection screen
	- display of the tracks pictures and info on selection screen
	- allow the player to choose the color of the car
	- cars settings screen


Thanks in advance for your comments,
Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                       TORCS
            The Open Racing Car Simulator
                 http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=