Increasing max # changepages?

Got a cool idea that should be in R'n'D? Let's hear it!

Moderators: Flumminator, Zomis

Post Reply
Tomi
Posts: 339
Joined: Wed Aug 03, 2005 3:37 pm
Location: Slovakia

Increasing max # changepages?

Post 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?
Zomis
Posts: 1502
Joined: Mon Jun 21, 2004 1:27 pm
Location: Sweden
Contact:

Post 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! ;)
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post 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.
Zomis
Posts: 1502
Joined: Mon Jun 21, 2004 1:27 pm
Location: Sweden
Contact:

Post 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...:roll: I can't remember why I did that conversion actually... but I'll look over that some day :)
asiekierka
Posts: 143
Joined: Fri Aug 19, 2005 6:18 am
Location: Poland
Contact:

Post by asiekierka »

I think 99 should be enough.
Or 256.
Or 999.
ok. I like the 32767 idea of mine.
GraphicsPack project: 90%
IconXT project: 100% (version final is ready)
Tomi
Posts: 339
Joined: Wed Aug 03, 2005 3:37 pm
Location: Slovakia

Post by Tomi »

IMO 99 sooner or later (but probably sooner) won't be enough.
User avatar
Sascha
Posts: 348
Joined: Fri May 12, 2006 6:17 pm
Location: Germany
Contact:

Post by Sascha »

But I'm wondering, which CE uses over 10.000 change pages?!
Image
Tomi
Posts: 339
Joined: Wed Aug 03, 2005 3:37 pm
Location: Slovakia

Post 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. :-)
Zomis
Posts: 1502
Joined: Mon Jun 21, 2004 1:27 pm
Location: Sweden
Contact:

Post 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?
Tomi
Posts: 339
Joined: Wed Aug 03, 2005 3:37 pm
Location: Slovakia

Post 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.
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post 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).
Zomis
Posts: 1502
Joined: Mon Jun 21, 2004 1:27 pm
Location: Sweden
Contact:

Post 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.
Post Reply