lua-users home
lua-l archive

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

>-----Original Message-----
>From: Dimitris Papavasiliou []
>Sent: Wednesday, September 29, 2004 3:51 PM
>To: Lua list
>Subject: Re: too many items in a constructor
>On Wednesday 29 September 2004 23:39, Peter Loveday wrote:
>> Or perhaps take it to another level, have a table for each 
>scanline, and a
>> table for each pixel.  Then if you need to add in extra 
>channels (Z? ObjID?
>> etc) it won't mess up the format entirely.  So something like:
>> my_image =
>> {
>>     { {r,g,b,a}, {r,g,b,a}, ... }, -- scanline 1
>>     { {r,g,b,a}, {r,g,b,a}, ... }, -- scanline 2
>>     ...
>> }
>> This would allow for up to 256k x 256k textures, with up to 
>256k channels.
>Yes I suppose this and other similar solutions would be 
>possible but I'd 
>prefer not to make things more complex than they need to be 
>unless there's 
>absolutely nothing than can be done with Lua, which in theory 
>shouldn't be 
>the case since it is a VM running in software. Thanks, though, 
>I'll keep it 
>in mind. It's a viable alternative and not nearly as bad as 
>using a string 
>for the image data.

Well, this depends on how you handle it. A table in Lua takes about 50 bytes. So, the format above adds about 50+ bytes per pixel, let alone that every pixel is represented as double (by default. -- 32 bytes) == 82+ bytes. On the other hand the RGBA values usually have a range from 0 to 256, so that a pixel can be represented via 12 byte string+length == 16+ bytes. Now, in many images some pixels have the same values and if so, in Lua, they would be represented via same string object firther reducing the overall memory consumption. I certainly don't know what you do with your images in Lua but on the merits of simple memory consumption strings don't look so bad to me. Accessing values would be pretty fast too as all characters are from '0'-'9' with 3 characters per chanel and it's just a snap to convert "123" into 123.