GMLscripts.com

Discuss and collaborate on GML scripts
Invert

You are not logged in.

#1 2008-07-13 00:49:44

Yourself
Member
Registered: 2007-10-09
Posts: 48

ds_list_append_list

Expand{
    var l1, l2, s1, s2, sr, n, hex;
    hex = "0123456789ABCDEF";
    l1 = argument0; l2 = argument1;
    s1 = ds_list_write(l1); s2 = ds_list_write(l2);
    sr = string_copy(s1, 1, 8);
    n = ds_list_size(l1) + ds_list_size(l2);
    repeat (4) {
        sr += string_copy(hex, ((n & $f0) >> 4) + 1, 1)
           +  string_copy(hex, (n & $0f) + 1, 1);
        n = n >> 8;
    }
    sr += string_delete(s1, 1, 16) + string_delete(s2, 1, 16);
    ds_list_read(l1, sr);
    return l1;
}

Takes two lists as arguments and appends the contents of the second list to the first.

Offline

#2 2008-07-13 03:32:40

xot
Administrator
Registered: 2007-08-18
Posts: 1,239

Re: ds_list_append_list

Pretty sneaky.


Abusing forum power since 1986.

Offline

#3 2008-07-14 21:03:50

Yourself
Member
Registered: 2007-10-09
Posts: 48

Re: ds_list_append_list

What is?

Offline

#4 2008-07-15 00:49:09

xot
Administrator
Registered: 2007-08-18
Posts: 1,239

Re: ds_list_append_list

Abusing the ds_list_read/write functions like that. It's just entirely too diabolical. I like it. Looks to be very fast for GM7 users.

Done any testing for accuracy and speed?


Abusing forum power since 1986.

Offline

#5 2008-07-15 01:46:13

Yourself
Member
Registered: 2007-10-09
Posts: 48

Re: ds_list_append_list

No, I haven't tested its speed at all.  I don't know what you mean about accuracy, though.  This won't lose any accuracy.

I really wish GM used Base64 instead of Hexadecimal for these strings, though.  Hexadecimal is too big.

Offline

#6 2008-07-15 11:13:24

xot
Administrator
Registered: 2007-08-18
Posts: 1,239

Re: ds_list_append_list

Well, you're exploiting an undocumented feature. I think this needs to go through some trials to determine if it works reliably.

This technique might be a fast way to do general hex conversions, at least for large amounts of data. ASCII conversion seems to be a no brainer, but how are numbers stored? IEEE-754 to hex?


Abusing forum power since 1986.

Offline

#7 2008-07-15 16:23:59

Yourself
Member
Registered: 2007-10-09
Posts: 48

Re: ds_list_append_list

It's almost a straight memory dump but in hex.  Here's a little text file I cooked up back when I decided to figure the format out for use from a DLL.  It's quite a verbose format, which is why I'd prefer base 64.

All of GM's data structure's seem to output what is essentially a hex encoded memory dump of the
data structure.  This means that all integers and doubles are encoded in little-endian format.

---------------------------------------------------------------------------------------------------
list, stack, queue:
Offset      Size (b)    Information
0x00        4           DS identifier (see below)
0x04        4           (int) number of elements in structure
Element record
{
    0x00    4       Indicates whether element is a string (1) or real (0)
    0x04    8       IEEE 754 double
    0x0C    4       (int) Length of following string field (0 if not present)
   [0x10    (0x0C)  bytes contained in string (only present if previous field != 0)]
}
---------------------------------------------------------------------------------------------------
map, pqueue:
Offset      Size (b)    Information
0x00        4           DS identifier (see below)
0x04        4           (int) number of elements in structure
Key/Priority record
{
    0x00    4       Indicates whether element is a string (1) or real (0)
    0x04    8       IEEE 754 double
    0x0C    4       (int) Length of following string field (0 if not present)
   [0x10    (0x0C)  bytes contained in string (only present if previous field != 0)]
}
Value record
{
    Same as above
}

Maps store their keys in order first.  Then the values are recorded in order.  For keys, real
values come before strings.  Priority queues are similar in that the priorities are stored before
their associated values, however the priorities are unsorted and show up in the order that they
were added to the queue.
---------------------------------------------------------------------------------------------------
grid:
Offset      Size (b)    Information
0x00        4           (0x59020000)
0x04        4           (int) width
0x08        4           (int) height
Element record
{
    0x00    4       Indicates whether element is a string (1) or real (0)
    0x04    8       IEEE 754 double
    0x0C    4       (int) Length of following string field (0 if not present)
   [0x10    (0x0C)  bytes contained in string (only present if previous field != 0)]
}

Elements are stored in column-major order.

===================================================================================================

Identifers:
list:   0x2D010000
stack:  0x65000000
queue:  0xC9000000

map:    0x91010000
pqueue: 0xF5010000

grid:   0x59020000

Last edited by Yourself (2008-07-15 16:24:50)

Offline

#8 2008-07-16 05:11:50

xot
Administrator
Registered: 2007-08-18
Posts: 1,239

Re: ds_list_append_list

Wow, the similarity of these structures would appear to make transformations between different types a snap. It looks like a real and string could be stored in the same record. Am I reading that correctly?


Abusing forum power since 1986.

Offline

#9 2008-07-16 10:28:07

Yourself
Member
Registered: 2007-10-09
Posts: 48

Re: ds_list_append_list

Yes, both a real and a string can be stored in a record simultaneously.  However, I don't know why that's useful since you'd only be able to access one from GM.  Additionally, the type identifier might cause it to only load the correct type and just ignore the other.

One thing you could do is transform a bunch of lists into a grid or vice-versa where each list is a column.  It also allows you to quickly slice lists and change them between stacks and queues.  However, I think some people used that trick a long time ago (but just supplying the entire string into the read function of a different data structure, rather than reformatting it).

Offline

Board footer

Powered by FluxBB