[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua on the PlayStation2
- From: "Leigh McRae" <leigh.mcrae@...>
- Date: Tue, 7 Oct 2003 14:28:25 -0400
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.
Rockstar Games Toronto
----- Original Message -----
From: "Virgil Smith" <email@example.com>
To: "'Lua list'" <firstname.lastname@example.org>
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: email@example.com
> [mailto:firstname.lastname@example.org]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
> 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" <Chris.email@example.com>
> To: <firstname.lastname@example.org>
> 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
> > the box on the PS2? We've been using it for a while, but in a fairly
> > way. After redirecting the memory managers to our own version, and
> > 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
> > can see the compilers are generating 32-bit arithmetic instructions for
> > 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
> > to get Lua a) working and b) fast?
> > When we ran our game through the Performance Analyser, Lua showed up as
> > 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
> > that the VM is expected to be running in a low-memory environment.
> > Thanks
> > ChrisC