Unfortunately UITextEdit is really bad in terms of performance. It
cannot be used as overlying widget (just like in terminal). On the other
hand we could optimize it by rewriting (unfortunately) the whole widget.
There still is a lot of things to do, but for now it is possible to
select several lines of text and copy it using CTRL + C. In order to
make text copyable in context menu it will be required to override
onMousePress (return true).
@edubart suggested it would be still better to have it done within C as
extra module (just like lbitlib).
"f" a float (4 bytes).
"d" a double (8 bytes).
http://en.wikipedia.org/wiki/IEEE_floating_point
This is something I was always missing - posibbility to operate on
binary files or streams in pure lua. In most cases we do only need to
read simple variables from files such as integers with different amount
of bytes. This "class" will provide that ability.
It's a simple implementation of following C module for lua:
http://www.inf.puc-rio.br/~roberto/struct/
It has much less, though. Following elements have been implemented:
">" flag to set mode to big endian.
"<" flag to set mode to little endian.
"b" a signed char.
"B" an unsigned char.
"h" a signed short (2 bytes).
"H" an unsigned short (2 bytes).
"i" a signed int (4 bytes).
"I" an unsigned int (4 bytes).
"l" a signed long (8 bytes).
"L" an unsigned long (8 bytes).
"s" a zero-terminated string.
An example how to use it:
```lua
local packed = Struct.pack('<LIhBsb', 123456789123456789, 123456789,
-3200, 255, 'Test message', -1)
-- packed is now a lua string we can save to file as binary data
local L, I, h, B, s, b = Struct.unpack('<LIhBsb', packed)
print(L, I, h, B, s, b)
```
You can use g_resources.readFileContents as function to read binary
files and parse them via this class.
I will leave this ugly hack for the time being, but I do encourage to change it later on. The whole "resize" boolean makes no sense since the outfit is resized by the destination rectangle anyway. I believe we should give it a try with a real size of the object defined in dat by the user for creatures bigger than 32x32.
Please keep in mind that we did cut bigger creatures to 48x48 (2*Otc::TILE_PIXELS*0.75f) before as well, so nothing really changed besides ability to properly draw bigger creatures than 64x64 on battlelist.
This was quite ridiculous.
TILESTATE_LAST = 1 << 24
Basically we were creating 2^24 Color structures within the array, each
of them has 4 floats (16 bytes) resulting in about 256 MB of extra
wasted memory.
Konrad Kuśnierz