lua-users home
lua-l archive

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


Ergh. Would you not be better off treating them as light userdata? You can
compare void* values and they won't go through any nasty floating point
conversions which might bring you problems. That's on the C side at least, I
don't know how you might perform Lua operations (comparison, deconstruction
into ID/verification elements) on them; although I don't know how you are
doing that now if you are passing them round as floating point numbers...

-----Original Message-----
From: Leigh McRae [mailto:leigh.mcrae@rockstartoronto.com]
Sent: 07 October 2003 17:19
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 handles
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 numbers
two and from floats?

Leigh McRae
Lead Programmer
Rockstar Games Toronto
www.rockstargames.com


----- Original Message ----- 
From: "Chris Chapman" <Chris.chapman@visentertainment.com>
To: <lua@bazar2.conectiva.com.br>
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 out
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 giving
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 now
> encountering problems with garbage collection.
>
> What seems to be happening is that the 64-bit unsigned integers in the lua
> state (->GCthreshold and ->nblocks) are being corrupted, because as far as
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 of
> the string table before.
>
> I realise this is probably best suited to newsgroups for PS2 compilers, so
> 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 double
> precision operations. Even after defining LUA_NUM_TYPE to be float instead
> 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 be?
> 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
>
>