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

Hi all

> Ok, the problem arises I guess if the file "trackname.ac" (e.g. 
> "dirt-6.ac") file does not exist yet, and if you choose "-S" its 
> actually not generated and the elevation mapper crashes. Yes, those 
> tools are quite tough to use... I will have a look into detecting that 
> and spit out a message.

Here this fix, that should do the trick for now.

Bye, Bernhard.

-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Hi Stephen

> Yey!  Fix works great.  Mine had some problems with the file path trying to load the meshfile... it prepended the directory name TWICE on the 
> mesh file.  I hacked it by doing:

Which file and where?

>     sprintf(buf, "", track->category, track->internalname);
>     ssgModelPath(buf);
>     printf("meshfile: %s\r\n", meshFile);
>     root = (ssgRoot*)ssgLoadAC(meshFile);
> 
> 
> But not sure why this happened in the first place.   Once I got past that problem, it DID generate the PNG correctly (no crash)!  Good job!

You mean that? :

WARNING: ssgLoadAC: Failed to open 
'tracks/dirt/dirt-1/tracks/dirt/dirt-1/dirt-1.ac' for reading

Ok, the problem arises I guess if the file "trackname.ac" (e.g. 
"dirt-6.ac") file does not exist yet, and if you choose "-S" its 
actually not generated and the elevation mapper crashes. Yes, those 
tools are quite tough to use... I will have a look into detecting that 
and spit out a message.

Bye, Bernhard.

-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Hi all

One more trackgen fix. The msh files cause AC3D to crash when trying to 
open a generated msh file because it claimed to have 2 kids but there 
was just one. Please test it and report the results (should work with 
vanilly 1.2.3).

Bye, Bernhard.


-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Hi Stephen

> I tried the new tgf.cpp  in my source tree... I recompiled tgf.dll and client.dll and trackgen.exe and I still get the crash.  I'm on windows XP 
> and used Visual Studio.NET 2003 to compile...
> 
> I'm using:
>   trackgen.exe -c dirt -n dirt-6 -S -E 1

Attached a new maintrackgen.cpp, I did not check if it compiles/works 
with vanilla 1.2.3, could you check anyway if it solves the problem?

Bye, thank you for testing and reporting,

Bernhard.

-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Hi Stephen

> I tried the new tgf.cpp  in my source tree... I recompiled tgf.dll and client.dll and trackgen.exe and I still get the crash.  I'm on windows XP 
> and used Visual Studio.NET 2003 to compile...
> 
> I'm using:
>   trackgen.exe -c dirt -n dirt-6 -S -E 1

Hey, this one crashes on Linux as well, good catch (that is good news 
actually, IMHO):-)

> To get the crash.  Without the "-E 1" I don't get a crash (so obvious specific to this feature).

Great:-) So the normal operation seems at least to work now. Thank you 
for your help and hints, bye

Bernhard.

-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Hi,

I tried the new tgf.cpp  in my source tree... I recompiled tgf.dll and client.dll and trackgen.exe and I still get the crash.  I'm on windows XP 
and used Visual Studio.NET 2003 to compile...

I'm using:
  trackgen.exe -c dirt -n dirt-6 -S -E 1

To get the crash.  Without the "-E 1" I don't get a crash (so obvious specific to this feature).

  Stephen

Hi all

There are some updates in CVS:
- updated tgf.cpp with fixes for win32 (malloc, realloc) (Bernhard).
- new pit door (Speedychonchon).

Bye, Bernhard.

-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

I remember I once did the same thing. I had a wrapper that added extra
info the the block allocated by malloc, by augmenting the allocated
size, so that later I could check for leaks.

Perhaps the code does something like that? Although I don't see such
info being inserted anywhere.


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

Hi all

Here the fixes for the previous problems. I still do not know why the 
fixed segments are needed, but with standard malloc and co in tgf torcs 
does not work.

Sorry for spamming...;-) As attachment a fixed tgf.cpp, could the 
Windows users test that (vanilla 1.2.3). It is not yet formatted and 
reviewed.

It would be nice if former reporters of trackgen/accc problems could try 
this.

Installation:
- Replace the original tgf.cpp with this one.
- Recompile the whole project.

Bye, Bernhard.

-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Hi all

Ok, now talking a bit to myself...

> Hi all
> 
> To save time I ask the Windows wizards on the list before trying to 
> figure this out myself;-)
> 
> Today I tried to track down some problems regarding the toolchain within 
> Windows (trackgen, accc). Now I hit the first time the code which 
> redefines malloc, realloc, free, and some more (I have not been aware of 
> that before). Example (shortened):
> 
> tgf.h:
> #ifdef WIN32
> #define malloc _tgf_win_malloc
> 
> tgf.cpp:
> void *_tgf_win_malloc(size_t size)
> {
>  char * p = (char*)GlobalAlloc(GMEM_FIXED, size + 4 );
> 
>  *(int*)( p ) = size;

Ok, looks not too bad for me, but I still do not know why not just to 
use malloc and co from the library...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/globalfree.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/globalalloc.asp

> 
>  return p + 4;
> }
> 
> So I have some questions regarding this:
> - Is it still necessary or is it a 16bit Windows artifact?
> - Why is it necessary (I would assume that even if you maintain a 
> pointer into "dll" data the data is within the process virtual address 
> space, so it is always at the same address for the same process. Or not, 
> hmmm... confused)?
> - What is this +4 on allocation and -4 on free good for?

The +4, -4 is currently to store the size of the block, and the 
implementation assumes that the handle matches the address.

I think that the _tgf_win_realloc function does not implement the usual 
realloc, look from the man page:

        realloc()  changes the size of the memory block pointed to
        by ptr to size bytes.  The contents will be  unchanged  to
        the minimum of the old and new sizes; newly allocated mem­
        ory will be uninitialized.  If ptr is NULL,  the  call  is
        equivalent  to malloc(size); if size is equal to zero, the
        call is equivalent to free(ptr).  Unless ptr is  NULL,  it
        must  have  been  returned by an earlier call to malloc(),
        calloc() or realloc().

        realloc() returns a pointer to the newly allocated memory,
        which is suitably aligned for any kind of variable and may
        be different from ptr, or NULL if the  request  fails.  If
        size  was equal to 0, either NULL or a pointer suitable to
        be passed to free() is returned.  If realloc()  fails  the
        original  block  is  left  untouched  - it is not freed or
        moved.

Or from MS:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_realloc.asp

The actual code:
void *_tgf_win_realloc(void * memblock, size_t size)
{
	void * p = _tgf_win_malloc(size);

	if (!p) {
		_tgf_win_free(memblock);

Hmm, frees the wrong block if memory allocation failed, does it? If I 
get it right it should just free the original here if the given size was 
0 "If realloc()  fails  the original  block  is  left  untouched  - it 
is not freed or moved."

		return NULL;	
	} else {
		memcpy(p, memblock, min(*(int*)((char*)memblock-4), (int)size) );

Hmm, does not free the original block...
	
   return p;
	}
}

This stuff looks very suspect to me, any thoughts (for me it simply does 
not match the spec from the man page)? I will try to switch to the c 
library functions and see what happens, but I think this code has some 
reason, but what is it good for?

Bye, Bernhard.



-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Hi all

To save time I ask the Windows wizards on the list before trying to 
figure this out myself;-)

Today I tried to track down some problems regarding the toolchain within 
Windows (trackgen, accc). Now I hit the first time the code which 
redefines malloc, realloc, free, and some more (I have not been aware of 
that before). Example (shortened):

tgf.h:
#ifdef WIN32
#define malloc _tgf_win_malloc

tgf.cpp:
void *_tgf_win_malloc(size_t size)
{
  char * p = (char*)GlobalAlloc(GMEM_FIXED, size + 4 );

  *(int*)( p ) = size;

  return p + 4;
}

So I have some questions regarding this:
- Is it still necessary or is it a 16bit Windows artifact?
- Why is it necessary (I would assume that even if you maintain a 
pointer into "dll" data the data is within the process virtual address 
space, so it is always at the same address for the same process. Or not, 
hmmm... confused)?
- What is this +4 on allocation and -4 on free good for?

I ask because I have a feeling that some trouble caused by the tools 
come from this definitions:
- Perhaps segments are a "rare" resource (size of GTD/LDT -> 
global/local descriptor tables), so if e.g. trackgen gets a lot of small 
structures we might run out of segment descriptors.
- Another point is that it might be a very inefficient call (e.g glibc 
malloc on Linux does not call brk/sbrk every time, it gets "huge" blocks 
of memory that it has some spare for the next call to avoid switches 
into the kernel context).

Bye, thank you for the hints,

Bernhard.


-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Bernhard Wymann a =E9crit :

> Hi Speedy
>
>> I've tried to draw a new garage door :
>> http://speedy.chonchon.free.fr/fichiers/torcs/garage2.jpg
>> the present one is :
>> http://speedy.chonchon.free.fr/fichiers/torcs/garage1.jpg.
>
>
> Great, is it ok if I commit it to the CVS?
>
> Bye, Bernhard.
>
Hi Bernhard.
No problem ;-) . I send you the file in a "personal" e-mail ;-) .

Bye
--=20
SpeedyChonChon

----------------------------------------------------------
AIM : /SpeedyChonChon/
ICQ : /302814595/
MSN : /ab...@ho.../
http://speedy.chonchon.free.fr
----------------------------------------------------------

Hi Speedy

> I've tried to draw a new garage door :
> http://speedy.chonchon.free.fr/fichiers/torcs/garage2.jpg
> the present one is :
> http://speedy.chonchon.free.fr/fichiers/torcs/garage1.jpg.

Great, is it ok if I commit it to the CVS?

Bye, Bernhard.

-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

Much better :-)

SpeedyChonChon wrote:
> Hi
> 
> I've tried to draw a new garage door :
> http://speedy.chonchon.free.fr/fichiers/torcs/garage2.jpg
> the present one is :
> http://speedy.chonchon.free.fr/fichiers/torcs/garage1.jpg.
> 
> Tell me, please, what do you think about that.
> 
> Thank
> 
> Bye
> -- 
> SpeedyChonChon
> 
> ----------------------------------------------------------
> AIM : /SpeedyChonChon/
> ICQ : /302814595/
> MSN : /ab...@ho.../
> http://speedy.chonchon.free.fr
> ----------------------------------------------------------
> 

Hi

I've tried to draw a new garage door :
http://speedy.chonchon.free.fr/fichiers/torcs/garage2.jpg
the present one is :
http://speedy.chonchon.free.fr/fichiers/torcs/garage1.jpg.

Tell me, please, what do you think about that.

Thank

Bye
-- 
SpeedyChonChon

----------------------------------------------------------
AIM : /SpeedyChonChon/
ICQ : /302814595/
MSN : /ab...@ho.../
http://speedy.chonchon.free.fr
----------------------------------------------------------

Hi all

I would like to have an updated website for the TORCS project within 12 
to 24 months, so I have some questions:
- Should we update at all?
- Strengths/weaknesses of the current site, of a potential new site?
- Does anybody have a CMS suggestion (*)?
- Some suggestions about the layout/functionality/spirit?
- Volunteers (Important, I will have not the time to do it till mid 07 I 
think)?
- Other thoughts?

I would like to update the site for the following reasons:
- Security.
- It should be more clear what the site is about on the first glimpse.
- Checking accordance with updated terms of use (sf.net).

The possibilities range from a mere update to the latest phpnuke 5.x up 
to a change to a different CMS with a complete redesign.

Thank you for your suggestions, bye

Bernhard.


(*) Requirements:
- Free (GPL or similar).
- Because we are hosted on sf.net it must be some kind of PHP/MySQL CMS.
- It should be possible to migrate the current data (manually is ok, we 
have to do it just once).
- Be aware of sf.net legal/technical limitations (**).

(**)
http://sourceforge.net/docman/display_doc.php?docid=753&group_id=1#projectweb
http://sourceforge.net/docman/display_doc.php?group_id=1&docid=4297#top

-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

simuv2:

- Updated 'free' differential to agree with simuv3.
[see discussion on mailing list a couple of months back]

simuv3:

- Changed default options for tyre temperature and wear to have no
effect. Currently temperature and wear caused a bit too large loss in
grip, have to fine tune it maybe.

- Fixed (I think) some calculations in collide.cpp for car2car
collisions, but still it's not working properly.


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

Hi all

There are some updates in CVS:
- New sound code from Christos (*)
- Some new makefiles for tracks to avoid distributing unnedded files.

(*) It is super cool, check it out. Be aware that the build system and 
the implementation itself has some missing bits. Before you compile 
TORCS you need to download and install OpenAL from 
http://www.berniw.org/trb/download/openal.tar.bz2 (unpack, go to the 
linux directory, follow the instructions in INSTALL). You need this 
version, it has some patches from Christos which are not yet part of the 
OpenAL CVS:-) Configure does not yet check for the presence of OpenAL 
(first I need to know if Christos patches go into the official tree or 
if we have to include our own version into TORCS, this might take some 
time to sort this out).

Bye, have fun,

Bernhard.


-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb

I have updated files in src/interfaces/ src/libs/confscreens and
src/modules/graphic for the new sound interface.

Currently there is a backend of the new sound interface to OpenAL and
a partial backend to plib (only engine sound). We need to add a couple
of details like which cars have a turbo sound and which not, and
perhaps a filter for OpenAL.

The OpenAL I am running is patched by me to fix pitch problems. The
standard one should work, but would sound a bit strange I guess.
We need to add it to the tree, if we want to make a release. Can
someone do that and then I'll patch it on the CVS? (I think I already
posted a patch on the list)

Anyway, enjoy.


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

Hi all

I commited the following changes:
- Visualize clutch command value (Bernhard).
- Simplyfied conditional compiling in grtrackmap.cpp, it requires now 
OpenGL 1.3 compatible header files. (Bernhard).
- Added configure test for GL_ARB_texture_compression (Bernhard).
- Added configure test for GL_VERSION_1_3 (Bernhard).
- Disabled mipmapping of "*shadow*" texture files (Bernhard).
- Backface culling for car shadow (Bernhard).
- Added texture compression (Bernhard).
- Added texture downscaling (Bernhard).
- Fixed an issue in sound/simu config screen (after changing values and 
hitting cancel the fields did not represent the current settings) 
(Bernhard).
- Added OpenGL configuration screen (Bernhard).
- Fixed inconsistency of texture loaders, "_nmm" is now obsolete, use 
"_n" (Bernhard).

Bye, Bernhard.


-- 

Visit my homepage http://www.berniw.org
Official TORCS racing: The TORCS Racing Board, http://www.berniw.org/trb