[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Lua on the PlayStation2
- From: Dave Owens <DaveO@...>
- Date: Mon, 6 Oct 2003 13:46:26 +0100
I didn't even get that far.. See post from last week.
As for the number type, it would be nice if we could have one place where we
could change this to whatever we required. I did get this side working (PC)
but I really loathed having to change the Lua code.
From: Chris Chapman [mailto:Chris.email@example.com]
Sent: 06 October 2003 13:45
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.