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

> Hello Thorsten,
>
> Christos Dimitrakakis is currently working on sound,
> he uses PLIB and added different sounds depending
> on the surface, added also doppler, multiple car sounds...
> (get the latest CVS for the changes).
> I think you should see with him for the integration
> of your changes.

Yeah, though I wrote the code for PLIB, it is very simple code, so it
should be easily transferred to OpenAL. The only snag is the way I
have hardcoded sound priorities, with a number of channels allocated
for prioritised engine sounds. All other looping sounds use one
channel each, but the code is not generalised properly. I'll do an
update today to separate the managing code from the plib calls. Does
OpenAL do sound prioritisation automatically?


Eric had mentioned that earlier versions of OpenAL had problems with
large doppler shifts and large sampling rate changes. I guess that
this is not a problem with the current version?


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

thorsten hackbarth wrote:
> hi,
> i'm using PLIB > 1.6 but 
>  configure.in 
> is broken:
> line 133 should be changed
> from 
> 
>  if ( PLIB_VERSION = MIN_PLIB_VERSION ) {
> 
> to 
>   if ( PLIB_VERSION < MIN_PLIB_VERSION ) {
> 
> 
> thanks
> 
> thorsten
> 
> 

I agree, but in the past, backward compatibility was not
the standard for PLIB ;-) fortunately between the 1.6 and 1.8
versions all the features used continue to work :-)
But at the time releasing the 1.2.2 version, only the 1.6.0
version of PLIB was existing, I was not sure that the next
release would be compatible so it was coded like that.
I should say that the 1.8 version of PLIB has a lot more
nice features.

BTW, in the TORCS CVS tree, the configure.in accept
further versions of PLIB ;-)

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

hi,
i'm using PLIB > 1.6 but 
 configure.in 
is broken:
line 133 should be changed
from 

 if ( PLIB_VERSION = MIN_PLIB_VERSION ) {

to 
  if ( PLIB_VERSION < MIN_PLIB_VERSION ) {


thanks

thorsten

Christos Dimitrakakis wrote:
> I think my current simu code might have created some problems with the
> bt/damned robots at race start. Does it happen to anybody that these
> robots start going reverse at very high speed at the beginning of the
> race when using simuv3?
> 
> 

On my system they behave as usual (going forward I mean)
but I noticed that the damaging code is not disabled
when the race is not yet started, so the wheels can be
damaged because the cars are left on the track at about
1 m height.

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

Hello Thorsten,

Christos Dimitrakakis is currently working on sound,
he uses PLIB and added different sounds depending
on the surface, added also doppler, multiple car sounds...
(get the latest CVS for the changes).
I think you should see with him for the integration
of your changes. Also, you can use torcs-devel mailing
list (I forwarded this mail to the list) so all the
interested people can participate.

Bye,
Eric.

fth wrote:
> hello,
> i played arround with openAL (open AudioLibary)
> -> www.openal.org 
> and started integrating it into torcs.
> ( i like the doppler effect when crashed in a wall and all the other cars 
> passing by...:o)
> is anyone already working on that?
> where can i send the changes i made?
> is it useless because it means more dependencies to < 1.0 libs?
> 
> bye
> 
> thorsten
> 
> 



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

I think my current simu code might have created some problems with the
bt/damned robots at race start. Does it happen to anybody that these
robots start going reverse at very high speed at the beginning of the
race when using simuv3?


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

> Christos Dimitrakakis wrote:
> > Hm, when I moved the learning code to libs/learning and added a
> > makefile similar to robottools, compilation was working OK, but then
> > my berniw-derived robot failed when torcs tried to dynamically link
> > the driver module. Everything else seems dandy: the created library,
>
> what is the error ?
>

When it loaded berniw.so, it complained of not finding a symbol that
was related to my library (the class symbol DiscretePolicy, to be
precise). When I move the policy code to robot tools and have it with
the librobottools.so library it works OK. Maybe I have to specify
somehow that liblearning.so is to also be used?

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

Christos Dimitrakakis wrote:
> Hm, when I moved the learning code to libs/learning and added a
> makefile similar to robottools, compilation was working OK, but then
> my berniw-derived robot failed when torcs tried to dynamically link
> the driver module. Everything else seems dandy: the created library,

what is the error ?

> liblearning.so, is in the correct place along with all the other
> libraries, the berniw compilation works fine. Is there some other step
> I need to do so that the new lib is dynamically linked?/
> 

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

Hm, when I moved the learning code to libs/learning and added a
makefile similar to robottools, compilation was working OK, but then
my berniw-derived robot failed when torcs tried to dynamically link
the driver module. Everything else seems dandy: the created library,
liblearning.so, is in the correct place along with all the other
libraries, the berniw compilation works fine. Is there some other step
I need to do so that the new lib is dynamically linked?/

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

I have added some learning routines for robots. Please look at the
README before using them. Probably some tuning will have to be made
and it is also possible that we can devise a particular algorithm that
will make learning easier in the simple environment of the racetrack.
Currently the general purpose algorithm decreases times by 1-1.5 s for
berniw9 on e-track-3, using simuv3. Training takes about 2000 laps.

I placed the general-purpose learning code in src/libs/learning/
The berniw-derived code that uses these routines is not provided, but
I am giving instructions on how to modify your own robot to take
advantage of these routines. As with all learning algorithms, if you
want them to work reasonably fast you have to tune a number of things.
I hope everything is explained in the README and the header files.

More algorithms can be added... if you feel that you have a robot that
can learn something during driving we can discuss how it can be
implemented using this algorithm, or whether we need new algorithms.

Have fun.

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

Hi Guy

> You were right, i had multiple versions of libGLU on my system. Removing
> the older one fixed my problem. Thank you very much.

Nice that it works now:-) Thank you for your detailed report.

bye, Bernhard.


-- 

visit my homepage http://www.berniw.org

Bernhard,

You were right, i had multiple versions of libGLU on my system. Removing
the older one fixed my problem. Thank you very much.


For archiving purpose, lemme explain what i understood of the hows and
whys a bit. Some other FreeBSD users could meet the same problem.

So, that computer where the problem occured have been running FreeBSD 4.x
branch for multiple years now, and thus every software there has been
updated many times (through the ports system for taking advantage of
processor-specific optimizations).

Some time ago, OpenGL on FreeBSD was installed through a separate package
(Mesa), but this has changed (during the last year i believe) : OpenGL
features are now incorporated in the main XFree librarys package/port.

So it happened that I still had the old version from the Mesa package along
with the more recent provided by the XFree86-libraries package.

To fix that situation i had to :
- Remove the Mesa Package.
- Force reinstallation of the XFree86-libraries package (some files may
have been deleted by the Mesa removal).
- Force reinstallation of the nvidia-driver package (this need is specific
to my machine) because it replace some files from XFree86-libraries with
its own nvidia-optimised version.
- Force reinstallation of torcs (and probably any other software using
OpenGL) to have it no longer linked with the old version of the libs.


Attached is an extract of the "investigations" I made after your advices
for locating that conflict.


Thank you again for your help, and forgive me for this
not-really-torcs-related thread :]

--

        Guy P.

Hi Steve

>> Ok, then I have some more possibilities in mind (I had exactly the 
>> same problem in the beginning with Windows, the problem was GLU 1.2 
>> versus GLU 1.3, GLU 1.2 was not able to handle 
>> GL_UNSIGNED_INT_8_8_8_8). I use in gluBuild2DMipmaps as input format 
>> GL_UNSIGNED_INT_8_8_8_8 if GLU version 1.3 is available 
>> (-->GLU_VERSION_1_3 is defined). Now it is possible that you have 
>> outdated OpenGL headers or an other GLU version, so please check:
>> - Is the symbol GL_UNSIGNED_INT_8_8_8_8 defined in you GL header files 
>> (-->if not, update)
>> - Have you just one libGLU installed in the system?
>> - Are the header files matching the version, which version do you have?
>> - If you change in src/modules/graphic/ssggraph/grtrackmap.cpp
> 
> 
> If you are unsing PLIB to load these textures then that's not it because
> PLIB doesn't use GLU - it builds its own MIPmaps.

This texture is a bit different, it is generated dynamically during 
runtime, and then mipmapped via GLU, so it is not "loaded" by any means.

bye, Bernhard.

-- 

visit my homepage http://www.berniw.org

Bernhard Wymann wrote:

> Ok, then I have some more possibilities in mind (I had exactly the same 
> problem in the beginning with Windows, the problem was GLU 1.2 versus 
> GLU 1.3, GLU 1.2 was not able to handle GL_UNSIGNED_INT_8_8_8_8). I use 
> in gluBuild2DMipmaps as input format GL_UNSIGNED_INT_8_8_8_8 if GLU 
> version 1.3 is available (-->GLU_VERSION_1_3 is defined). Now it is 
> possible that you have outdated OpenGL headers or an other GLU version, 
> so please check:
> - Is the symbol GL_UNSIGNED_INT_8_8_8_8 defined in you GL header files 
> (-->if not, update)
> - Have you just one libGLU installed in the system?
> - Are the header files matching the version, which version do you have?
> - If you change in src/modules/graphic/ssggraph/grtrackmap.cpp

If you are unsing PLIB to load these textures then that's not it because
PLIB doesn't use GLU - it builds its own MIPmaps.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Hi Guy

> Ok, i checked yesterday night, and that problem (track minimap replaced
> with a solid blue zone, with only the cars dots shown) always happens,
> wether i am running the game in fullscreen or windowed mode.

Ok.

> I will try with a different video card when i have some time (currently is
> a geforce 4 - ti version if i remember well). Other than that, what could i
> do to help locate the cullprit ?

Ok, then I have some more possibilities in mind (I had exactly the same 
problem in the beginning with Windows, the problem was GLU 1.2 versus 
GLU 1.3, GLU 1.2 was not able to handle GL_UNSIGNED_INT_8_8_8_8). I use 
in gluBuild2DMipmaps as input format GL_UNSIGNED_INT_8_8_8_8 if GLU 
version 1.3 is available (-->GLU_VERSION_1_3 is defined). Now it is 
possible that you have outdated OpenGL headers or an other GLU version, 
so please check:
- Is the symbol GL_UNSIGNED_INT_8_8_8_8 defined in you GL header files 
(-->if not, update)
- Have you just one libGLU installed in the system?
- Are the header files matching the version, which version do you have?
- If you change in src/modules/graphic/ssggraph/grtrackmap.cpp


#ifdef GLU_VERSION_1_3
#define THE_GL_PIXEL_TYPE       GL_UNSIGNED_INT_8_8_8_8
#else
#define THE_GL_PIXEL_TYPE       GL_BYTE
#endif

to

#define THE_GL_PIXEL_TYPE       GL_BYTE

or

#define THE_GL_PIXEL_TYPE       GL_UNSIGNED_INT_8_8_8_8

what happens then? Does one version work? Please submit also you 
"glxinfo -l".

bye, thank you, Bernhard.

-- 

visit my homepage http://www.berniw.org

All,

Ok, i checked yesterday night, and that problem (track minimap replaced
with a solid blue zone, with only the cars dots shown) always happens,
wether i am running the game in fullscreen or windowed mode.

Also, the mirror in the pilot view from within the cockpit always works very
well.


I will try with a different video card when i have some time (currently is
a geforce 4 - ti version if i remember well). Other than that, what could i
do to help locate the cullprit ?



Thierry : Ho well then if you are the commiter for that port i guess you
did already know it was updated :] Do you experience that problem i
describe with the minimap ?


cheers

--
        Guy P.

Le Lun  3 mai 04 =E0 17:07:51 +0200, gu...@de... <gu...@de...=
ndns.org>
 =E9crivait=A0:
> BTW to help Thierry Thomas with his problem, i just noticed the FreeBSD
> port of torcs is now uptodate (version 1.2.2).

Thanks Guy, but I have committed this port myself ;-)

> So he'd want to try totally wiping his previous installation and do a "=
cd
> /usr/ports/games/torcs && make install clean" after updating his ports =
tree
> (see the FreeBSD Handbook at http://www.FreeBSD.org if not familiar wit=
h the
> ports system).
> Could help, as this ports system is here to avoid the headache which is=
 to
> deal with various dependencys yourself.

I hope so! Unfortunately, it does not handle misconfigurations...

Regards,
--=20
Th. Thomas.

Bernhard Wymann wrote:

> There is also a possibility that your hardware driver allows e. g. just 
> 256x256 textures,

The PLIB texture loader deals with that case.  If the texture is too large
for the OpenGL implementation, it halves its size and tries again...and keeps
doing that until it fits.

There is one possibility though - there were some old Mesa versions that had
a broken implementation of 'GL_PROXY_TEXTURE_2D' that tricked PLIB into thinking
that no textures of any size were allowed.  You can compile PLIB with
-DPROXY_TEXTURES_ARE_BROKEN to insert a work-around for this bug.

AFAIK, that version of Mesa was once shipped with RedHat - but has never been seen
in the wild on any other distro.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Le Lun  3 mai 04 =E0 12:18:42 +0200, Bernhard Wymann <be...@bl...>
 =E9crivait=A0:
> Hi Thierry

Hello,

> Do other games run, e. g. Tuxcart, Tuxracer, bzflag? I'm just curious i=
f=20
>  your OpenGL driver is broken. If I understand you correct, TORCS runs,=
=20
> but simply no textures are used? Are no textures used at all, or do som=
e=20
> work (like the counters, info displays etc.)?

You are right: it was a problem with my configuration. I don't know
exactly what, but I have reinstalled XFree86-libs + freeglut + my
drivers and everything is now OK.

Regards,
--=20
Th. Thomas.

On 03-May-2004 Bernhard Wymann wrote:
> Hi Guy
> 
>> This said, the bug that display a solid blue square instead of the race
>> minimap at top right corner of screen is there. Someone else mentioned
>> that
> 
> So I guess you run TORCS in a window, and it happens just "sometimes, 
> but not always"?
> 
>> bug on another system (Linux i think ?), so it may actually be a real
>> bug
>> and not a platform specific issue.
> 
> Do you use the Nvidia graphic driver? A problem is if you run TORCS in a 
> window and the window is covered (partly or full) the the capturing of 
> the map fails. I suspect this is an OpenGL driver "optimization" 
> problem, because the map is not rendered and captured in this case. Btw. 
> the same happens with the rear mirror if the TORCS window is covered. 
> The only solution I see for that is using pbuffers where they are 
> available (look in the TODO in grtrackmap.cpp). The reason why I did not 
> implement that yet, is because it is platform dependent (WGL/GLX).
> 
> bye, Bernhard.

Bernhard,

Thanks for your time,

Well, I do use the nvidia driver indeed and do run torcs windowed. But
this "bug" seems to always happen, and I don't think I ever tested to cover
the torcs window with another one (when running, torcs usually occupy my
whole mind :] ).

I think neither did I try to race "from within the cockpit", so I cannot
tell now if the rear mirror also performs this way.

I will try to 1) run torcs fullscreened and 2) see how the rear mirror is
behaving later this evening, and will leave you informed here.



BTW to help Thierry Thomas with his problem, i just noticed the FreeBSD
port of torcs is now uptodate (version 1.2.2).
So he'd want to try totally wiping his previous installation and do a "cd
/usr/ports/games/torcs && make install clean" after updating his ports tree
(see the FreeBSD Handbook at http://www.FreeBSD.org if not familiar with the
ports system).
Could help, as this ports system is here to avoid the headache which is to
deal with various dependencys yourself.


Enjoy your day.


--
        Guy

Hi Guy

> This said, the bug that display a solid blue square instead of the race
> minimap at top right corner of screen is there. Someone else mentioned that

So I guess you run TORCS in a window, and it happens just "sometimes, 
but not always"?

> bug on another system (Linux i think ?), so it may actually be a real bug
> and not a platform specific issue.

Do you use the Nvidia graphic driver? A problem is if you run TORCS in a 
window and the window is covered (partly or full) the the capturing of 
the map fails. I suspect this is an OpenGL driver "optimization" 
problem, because the map is not rendered and captured in this case. Btw. 
the same happens with the rear mirror if the TORCS window is covered. 
The only solution I see for that is using pbuffers where they are 
available (look in the TODO in grtrackmap.cpp). The reason why I did not 
implement that yet, is because it is platform dependent (WGL/GLX).

bye, Bernhard.

-- 

visit my homepage http://www.berniw.org

I built 1.2.2 from sources (the port was not updated yet) on FreeBSD 4.9 a
few weeks ago, and i did not meet that trouble.

What other information could help Th. Th. solving his problem ?


This said, the bug that display a solid blue square instead of the race
minimap at top right corner of screen is there. Someone else mentioned that
bug on another system (Linux i think ?), so it may actually be a real bug
and not a platform specific issue.

What information/tests/whatever may i provide/use to help solve this
problem ?




While I'm here for my 1st post, let me give the TORCS team many
congratulations for their excellent work ! :]

Regards.

--
        Guy 'DeVice' P.

Hi Thierry

>>Can you try with PLIB-1.8.x ?
>>but it should work with the 1.7.0 as it is the same as the
>>1.6.0
> 
> 
> I have just tried with plib-1.8.3: same problem.

Do other games run, e. g. Tuxcart, Tuxracer, bzflag? I'm just curious if 
  your OpenGL driver is broken. If I understand you correct, TORCS runs, 
but simply no textures are used? Are no textures used at all, or do some 
work (like the counters, info displays etc.)?

There is also a possibility that your hardware driver allows e. g. just 
256x256 textures, could you please send the output of "glxinfo -l" and 
eventually the output of TORCS when configured/compiled with 
"--enable-debug" like Eric already mentioned. An ingame screenshot would 
be nice also.

What architecture do you run (ia32, amd64, ...)?

Bye, thank you, Bernhard.

-- 

visit my homepage http://www.berniw.org

I have now fixed the transmission in simuv3. Now the engine RPM never
increases faster when it is in-gear than when it is in neutral. This
results in a much more easily controlled power-skid for high-power
cars. I have also added a reciprocal coupling between the engine
and transmission, so now if you rev up and then let go of the clutch
there is a short spin. The opposite happens whenever you gear down, so
that if you drive a RW-drive and geardown at very high revs on a curve
you get an effect similar to a touch of the handbrake. I also changed
the tickover mechanism to be actually a simple controller that
increases throttle when revs are too low, as in real cars. There is
currently no mechanism to turn the engine off, however.

I have also placed a new sound for mclarenf1, sampled from a real
mclarenf1.

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

Le Dim  2 mai 04 =E0 10:56:51 +0200, Eric Espie <eri...@fr...>
 =E9crivait=A0:
> Can you try with PLIB-1.8.x ?
> but it should work with the 1.7.0 as it is the same as the
> 1.6.0

I have just tried with plib-1.8.3: same problem.

Regards,
--=20
Th. Thomas.