>This way, you can store 64 different values of each data type for each
>element!
Ah, I see... and there are 4 different kinds of data sizes: 8 bit, 16 bit, 32 bit, and multibyte. And 256/4=64
Then I see why 64 is a good number here.
>Don't panic -- it's not really variable size. It's just that the static
>initialization only uses those values that matter, while the rest are just
>left away (and are automatically initialized with zeroes by the C
>compiler). This is just to make things more readable and skip as many
>unused values as possible (and not to type too much when
>programming...
).
I don't panic, I ask
Ah, I see... and I just found out that Delphi handles this the exact same way, but in Delphi I have to write "element: -1; save_type: SAVE_CONF_ALWAYS", and so on... but it's ok to leave some stuff out. Which is good... however, I can't declare it as constant in Delphi because of the pointers. So I have to use a little workaround, which redefines chunk_config_CUSX each time it is called (that is, each time the xx_ei pointer changes).
Speaking about that, I was wondering...
Code: Select all
xx_ei = *ei; /* copy element data into temporary buffer */
...
*ei = xx_ei;
There's something suspicious here... you copy all the data from ei to xx_ei, right? At first I was thinking that you just changed the pointers. But that's not it, because 1. xx_ei is defined as static. And 2. if you changed the pointer, I don't see any reason for this: *ei = xx_ei;
That's how you handle the pointer problem I encountered in Delphi. Your xx_ei is static since it always point to the same place, but it's dynamic since it can change the value, clever! Too bad Delphi doesn't like that idea..
>It's used to copy all those different CE values inside the level editor
>(when you use copy/cut/paste), to prevent to much redundancy which
>usually results in errors (adding a new CE property and adding it to the
>loading/saving code, but forgetting to add it to the copying code).
Ah, I see... and now when I look more into it, it seems like those new structures are being used much more than I originally thought. Certainly not a bad idea! Both being used for copying and setting to default as well, nice!
>You're more or less right here! C does not know anything about arrays
>at all, in fact -- it only knows pointers. (The C compiler knows
>something, but that's all...) For static arrays, I could use "sizeof()" here
>to determine the size of the initialized array, and divide by the size of
>the array itself, but this would be horrifying ugly and potentially
>error-prone, and won't work with dynamically allocated arrays at all.
Oh, that's right. Completely forgot about that, but now that you mention it I remember. C really doesn't have a clue about arrays. But in what way the compiler has it, that I wonder? Or maybe you mean that it optimizes all the pointer-code so that it actually acts like an array? In any case, I agree with you. Having a NULL-structure is much better in that case than a bunch of sizeof() checks.
>Yep -- most CE levels get significantly smaller when loaded and saved
>again using the new micro chunks, as most values are still at their
>default values. The only problem is if you change the default values later
> -- but this can be solved relatively easy with some compatibility code...
Hmm... changing the default values later... that's right... I wonder how that compatiblity code would look like? Let's say the default time changes from 100 to 120, how would that look in the source? Just wanted to know so I could get an idea about how it can be done in Delphi
My guess though is that you do something like the following:
Code: Select all
{
-1, SAVE_CONF_ALWAYS,
TYPE_INTEGER, CONF_VALUE_16_BIT(3),
&li.time, (level->game_version >= VERSION_IDENT(3,2,0,9) ? 120 : 100)
},
I like this style more and more 
