Page 1 of 1
Increasing max # changepages?
Posted: Sat Feb 03, 2007 11:13 am
by Tomi
As you probably know, the World Making Technique uses a large amount of changepages. In extreme cases, the number of changepages is so large that the CE must be split in two (or more).
I'd like to ask this: how difficult is it to increase the max # of changepages. I understand it's difficult for CEs, because many elements would probably have to be renumbered etc, but changepages are stored in classical numbered arrays.
I wonder... What about unlimited n.o. changepages?
Posted: Sat Feb 03, 2007 12:07 pm
by Zomis
Unfortunately, this isn't as easy as it could be... which can be proved by a script on a "World Making Challenge" level
Code: Select all
var
I, J: Integer;
begin
for I:=1 to 256 do
if element_info[CE(I)].modified_settings then
if element_info[CE(I)].description = 'room 1' then
begin
for J:=0 to element_info[CE(I)].num_change_pages do
Messi('CE ' + element_info[CE(I)].description + '(page, trigger_page)', [J, element_info[CE(I)].change_page[J].trigger_page]);
end;
end.
This script will output:
Code: Select all
CE room 1(page, trigger_page): 0, -1
CE room 1(page, trigger_page): 1, 1
CE room 1(page, trigger_page): 2, 2
CE room 1(page, trigger_page): 3, 4
CE room 1(page, trigger_page): 4, 8
CE room 1(page, trigger_page): 5, 16
CE room 1(page, trigger_page): 6, 32
CE room 1(page, trigger_page): 7, 64
CE room 1(page, trigger_page): 8, 128
CE room 1(page, trigger_page): 9, 256
CE room 1(page, trigger_page): 10, 512
CE room 1(page, trigger_page): 11, 1024
CE room 1(page, trigger_page): 12, 2048
CE room 1(page, trigger_page): 13, 4096
CE room 1(page, trigger_page): 14, 8192
CE room 1(page, trigger_page): 15, 16384
CE room 1(page, trigger_page): 16, 32768
CE room 1(page, trigger_page): 17, 65536
CE room 1(page, trigger_page): 18, 131072
CE room 1(page, trigger_page): 19, 262144
CE room 1(page, trigger_page): 20, 524288
CE room 1(page, trigger_page): 21, 1048576
CE room 1(page, trigger_page): 22, 2097152
CE room 1(page, trigger_page): 23, 4194304
CE room 1(page, trigger_page): 24, 8388608
CE room 1(page, trigger_page): 25, -1
CE room 1(page, trigger_page): 26, -1
CE room 1(page, trigger_page): 27, 0
So as you see, trigger_page ANY is saved as "-1", and trigger_page 3 is saved as "4" and so on... following a 2^x structure.
The main question is, why is trigger_page stored in this way? Why not use trigger_page ANY = 0, trigger_page 1 = 1, trigger_page 2 = 2... and so on...?
In order to add more change pages, we either need more bits to store the trigger_page (1 bit per page), or we need to change this way of storing/saving the pages..
I guess there's only one man who can answer this question: HOOOLLGER!
Posted: Sat Feb 03, 2007 2:54 pm
by Holger
> So as you see, trigger_page ANY is saved as "-1", and trigger_page 3 is
> saved as "4" and so on... following a 2^x structure.
Nearly true, but with one exception: The value is stored as a 32 bit field, which has to interpreted as "unsigned", so it's not "-1", but "0xffffffff" instead. So, "any change page" really means "each bit for every change page is set". This solution is good for both simplicity and performance, but limits the number of change pages to 32.
To extend this, it would have to be changed to a list of active change pages, which could then be stored as just numbers instead of bit values. In the game, it would then be represented as a boolean array for each CE instead of a 32 bit value with set or unset bits.
Posted: Sat Feb 03, 2007 5:37 pm
by Zomis
>> So as you see, trigger_page ANY is saved as "-1", and trigger_page 3 is
>> saved as "4" and so on... following a 2^x structure.
>Nearly true, but with one exception: The value is stored as a 32 bit field,
>which has to interpreted as "unsigned", so it's not "-1", but "0xffffffff"
>instead. So, "any change page" really means "each bit for every change
>page is set". This solution is good for both simplicity and performance, but
>limits the number of change pages to 32.
Details
But I knew that actually
>To extend this, it would have to be changed to a list of active change pages,
>which could then be stored as just numbers instead of bit values. In the
>game, it would then be represented as a boolean array for each CE instead
>of a 32 bit value with set or unset bits.
So how is this bitfield used in the game engine today? I see no point for saving it as a bitfield in the files, since you can't make a CE change by page of 2 and 3 of another CE. You'd have to make two seperate change pages for that, or use "any".
But I guess this bitfield is used a lot in the game engine, so I wonder - how? It would really be nice if the # of change pages could increase. But I do not like the idea of "unlimited" change pages - but I do like the idea of 65535 of them
Anyway (a little off-topic now...), if the # of change pages should increase I guess I should try changing the storation of those in RND Scripter, currently I have a static array and not a dynamical array for them. Which means that 32 empty change pages is stored for all other elements as well...
I can't remember why I did that conversion actually... but I'll look over that some day
Posted: Wed Feb 14, 2007 9:18 am
by asiekierka
I think 99 should be enough.
Or 256.
Or 999.
ok. I like the 32767 idea of mine.
Posted: Fri Feb 16, 2007 6:16 pm
by Tomi
IMO 99 sooner or later (but probably sooner) won't be enough.
Posted: Fri Feb 16, 2007 6:27 pm
by Sascha
But I'm wondering, which CE uses over 10.000 change pages?!
Posted: Fri Feb 16, 2007 6:31 pm
by Tomi
For example, a CE that uses...
this? (BTW Holger, if you haven't already, that one is IMHO really worth implementing...)
On second thought... OK, maybe 10,000 *is* enough.
Posted: Fri Feb 16, 2007 6:36 pm
by Zomis
Tomi wrote:IMO 99 sooner or later (but probably sooner) won't be enough.
I agree. Just making a static change to 99 would be very pointless. A change to 65535 (which is, as some of us know, the highest value of a 2-byte unsigned integer) would make more sense.
But now I just started to wonder, is a 65535 paged CE realistic to handle for the game engine? Holger?
Posted: Sat Mar 03, 2007 2:14 pm
by Tomi
Maybe the game engine could handle it -
Moore's Law: The speed of hardware doubles every 18 months.
...but maybe not:
Gates' Law: The speed of software halves every 18 months.
Posted: Sat Mar 03, 2007 8:35 pm
by Holger
> But now I just started to wonder, is a 65535 paged CE realistic to handle
> for the game engine? Holger?
Yes, I think so. It could be done with constant complexity (unless you use many of them, of course -- then you would of course get linear complexity).
But generally, when not using them or only using very few change pages, the engine should be able to handle it with the same runtime complexity, yes. (This would of course require replacing the bit-based change page handling by boolean array based change page handling).
Posted: Fri Mar 30, 2007 9:02 am
by Zomis
Holger wrote:(This would of course require replacing the bit-based change page handling by boolean array based change page handling).
I was just wondering, wouldn't it be possible to replace it with an array of integer bit-based handling, just like the CE properties? So page 1-32 would be in the first array position, 33-64 in the next array position, and so on? I don't know which the best way is to solve it though.