lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

  I didn't see a eq metamethod for Lua 4.  I will check again, if so I will
use this.  I did write a function called AreEqual() for the scripters but I
felt dirty and it was really prone to error.

  Casting the value of a handle to a void pointer would work, as a previous
post suggested.  Looking back on the problem, I am thinking that it was more
of a tolua issue I was having.  I ended up changing tolua to treat Handles
as numbers when maybe what I really wanted was void pointers.  I will have
to look at it again, thanks for the ideas.

Leigh McRae
Lead Programmer
Rockstar Games Toronto

----- Original Message ----- 
From: "Virgil Smith" <>
To: "'Lua list'" <>
Sent: Tuesday, October 07, 2003 1:32 PM
Subject: RE: Lua on the PlayStation2

> If you have a 32 bit "handle", I'd suggest using a Light User Data rather
> than a number, that should work around the float issue and be a little
> misleading in the type information.
> If you wish the compare to be handled properly (in a semantic fashion
> indicating that 2 handles reference the same object) then use a full user
> data and set an "eq" metamethod.
> -----Original Message-----
> From:
> []On Behalf Of Leigh McRae
> Sent: Tuesday, October 07, 2003 11:19 AM
> To: Lua list
> Subject: Re: Lua on the PlayStation2
>   I am using lua 4 and I tried to switch the doubles to floats but I had
> some problems.  I have a class called Handle that is really just a 32bit
> number that uses 16bits as an id and 16bits for instance verification.
> These couldn't be passed around and compared like pointers since two
> can be the same but be in different memory locations.  So started passing
> them as numbers.  When I switched Lua to use floats instead of doubles, it
> broke.  The handles would be casted to a float and it would loose its real
> value.
>   I decided to leave the doubles in for now and address the problem later
> :(  I wonder if Lua 5.0 will be the same.  Does Lua 5.0 cast all its
> two and from floats?
> Leigh McRae
> Lead Programmer
> Rockstar Games Toronto
> ----- Original Message -----
> From: "Chris Chapman" <>
> To: <>
> Sent: Monday, October 06, 2003 8:45 AM
> Subject: Lua on the PlayStation2
> > Just curious if anyone else has had issues trying to use Lua straight
> of
> > the box on the PS2? We've been using it for a while, but in a fairly
> limited
> > way. After redirecting the memory managers to our own version, and
> it
> > a 256KB heap to play in everything seemed to work okay. However after
> > loading up a bunch more scripts and using it in a more active way, I'm
> > encountering problems with garbage collection.
> >
> > What seems to be happening is that the 64-bit unsigned integers in the
> > state (->GCthreshold and ->nblocks) are being corrupted, because as far
> I
> > can see the compilers are generating 32-bit arithmetic instructions for
> the
> > garbage collection/ string table resizing routines. They didn't show up
> > before because we never actually had an opportunity to shrink the size
> > the string table before.
> >
> > I realise this is probably best suited to newsgroups for PS2 compilers,
> > I'll be posting it there as well; however I'd be interested to hear from
> > other developers using Lua in a PS2 environment - what did you have to
> tweak
> > to get Lua a) working and b) fast?
> >
> > When we ran our game through the Performance Analyser, Lua showed up as
> the
> > worst single culprit for performance, and a lot of that was due to
> > precision operations. Even after defining LUA_NUM_TYPE to be float
> > of double, there are still many functions both in the API and internally
> > which expect double precision arguments. Does anyone know what the
> > implications of a global search and replace for float to double would
> > How many of the 64 bit values (long is 64 bit on a PlayStation2) used
> > throughout the library are actually required to be 64-bit? Especially
> given
> > that the VM is expected to be running in a low-memory environment.
> >
> > Thanks
> > ChrisC
> >
> >