Updated extra-large-maps patch, version 12 (for r23992)
Posted: 17 Jul 2007 02:42
[UPDATE]
Updated to 23992.
[UPDATE]
Updated to 20829. Changes from v11:
Fixed crash (assertion) with NewGRF debug window and tileindex over 16M.
[UPDATE]
Updated to 20820. Functionality is the same, but the patch was updated to reflect minor changes in the code.
[UPDATE]
Updated to 19615. Functionality is the same, but the patch was updated to reflect minor changes in GUI code.
[UPDATE]
Updated to 19000. Functionality is the same, but the patch was updated to reflect major changes in GUI code.
[UPDATE]
Updated to 16679. Changes from v10:
Update to current trunk (train collision checking speedup and some enumification added to trunk)
[UPDATE]
Updated to 16601. Changes from v9:
Train collision checking speedup. No more int64 are used. Now in most cases, even no multiplication is used at all.
When selecting map size, map sizes too large for current dimension (with regard to map size selected for other dimension) are painted in red. This can be used to quickly see how large value I can choose before the game starts complaining about too many tiles ... (thus if I select value in red, then I need to decrease the other value ... )
Changes from v8:
Cleaned up the coding style to be more consistent with OpenTTD coding style.
Changes from v7:
Fixed bug that could cause trains which are more than 2047 tiles apart in one dimension to crash (overflow in train collision check), introduced in 11877 while somebody fixed some other bug.
[UPDATE]
I have updated the patch for r11849. From now on, I am including here only the version with large limits. The version with "reasonable" limits supposed to go to trunk is now updated only in the appropriate bugtracker task - http://bugs.openttd.org/task/1059
[UPDATE]
I have updated the patch for r11781 and now there are two versions. One with "reasonable" limits (max 8192 map, max 4 Mi tiles (2^22)) that aims for trunk, one with "large" limits, maximal that could be reasonably run on 32bit architectures (without things like 3gb:1gb user/kernel split, etc) - the limits are 1048576 max map size and maximum of 64 Mi tiles (2^26) = 1.2GB memory eaten. You can have for example 1048576 x 64 or 8192 x 8192 map with these limits.
The "large" version comes with precompiled windows binaries.
Changes from v6:
* When map size too large is selected, the text gets red-colored to indicate it.
* Strings are no longer in translation and are generated dynamically
* Limits decreased to "reasonable" values, however increasing them is very simple. Just open map.h and modify MAX_MAP_TILES_BITS from 22 to 26 and MAX_MAP_SIZE_BITS from 13 to 20. This will enable resolutions like 1048576*64 or 8192*8192 (and you'll need 1.3GB memory for them). If you have 2.6GB, you can set MAX_MAP_TILES_BITS to 27 and have yet larger sizes, etc ...
Changes from v5:
* Removed workaround around bug that was fixed in 10719 (not showing 64bit ints in NUM and COMMA).
Changes from v4:
* fixed selected resolution clamped to 2048 when it is saved in openttd.cfg
Changes from v3:
* fixed misaligned combobox in scenario editor
* fixed crash when map_x & map_y in config file was outside permitted bounds when starting scenario editor
I have included new version of the patch. Along with defining maximum alowed dimension of the map (which I have raised to 262144) there is maximum number of tiles in the map (It is 4096*4096). If necessary to change the limit, it can be changed in one place (map.h) and rest of the code will reflect the changed limit (You should be able to raise it up to 32768*32768 theoretically before some overflow may possibly occur, though raising the limit that high will require 64bit architecture and insane amounts of RAM, so I suggest it stays at 4096*4096, which works well on good PC's (which is ~ 1.5-2 Ghz CPU + 512Mb RAM) with reasonable number of towns and industries
When user selects too large resolution exceeding maximal number of tiles when he wants to generate new land, he gets a warning and new land is not generated unless he reselect some smaller resolution.
Saving and loading now works fine.
This version is now enough stable to be candidate for including into trunk.
[/UPDATE]
I have created experimental patch that allows you to play with maps up to 8192 x 8192.
There are few problem with such large sizes:
* Generating such large map takes ... quite long
* Tileloop for such large map eats considerable amount of CPU time, so even if the map is "empty", you need good CPU to get decent performance
* You need lot of memory (8192 x 8192 needs 1.3GB, 4096 x 4096 needs 340MB)
Noodly resolutions (1024x4096, 512x8192) with reasonable number of tiles work fine without any problems or big memory/CPU demands (they perform like 2048x2048)
So ... do you think it will be good patch for trunk, if number of tiles will end up to be limited to 4millions?
(for example Italy scenario will be good with 1024x4096 map size. Or scenario in any other country which is thin and long)
Updated to 23992.
[UPDATE]
Updated to 20829. Changes from v11:
Fixed crash (assertion) with NewGRF debug window and tileindex over 16M.
[UPDATE]
Updated to 20820. Functionality is the same, but the patch was updated to reflect minor changes in the code.
[UPDATE]
Updated to 19615. Functionality is the same, but the patch was updated to reflect minor changes in GUI code.
[UPDATE]
Updated to 19000. Functionality is the same, but the patch was updated to reflect major changes in GUI code.
[UPDATE]
Updated to 16679. Changes from v10:
Update to current trunk (train collision checking speedup and some enumification added to trunk)
[UPDATE]
Updated to 16601. Changes from v9:
Train collision checking speedup. No more int64 are used. Now in most cases, even no multiplication is used at all.
When selecting map size, map sizes too large for current dimension (with regard to map size selected for other dimension) are painted in red. This can be used to quickly see how large value I can choose before the game starts complaining about too many tiles ... (thus if I select value in red, then I need to decrease the other value ... )
Changes from v8:
Cleaned up the coding style to be more consistent with OpenTTD coding style.
Changes from v7:
Fixed bug that could cause trains which are more than 2047 tiles apart in one dimension to crash (overflow in train collision check), introduced in 11877 while somebody fixed some other bug.
[UPDATE]
I have updated the patch for r11849. From now on, I am including here only the version with large limits. The version with "reasonable" limits supposed to go to trunk is now updated only in the appropriate bugtracker task - http://bugs.openttd.org/task/1059
[UPDATE]
I have updated the patch for r11781 and now there are two versions. One with "reasonable" limits (max 8192 map, max 4 Mi tiles (2^22)) that aims for trunk, one with "large" limits, maximal that could be reasonably run on 32bit architectures (without things like 3gb:1gb user/kernel split, etc) - the limits are 1048576 max map size and maximum of 64 Mi tiles (2^26) = 1.2GB memory eaten. You can have for example 1048576 x 64 or 8192 x 8192 map with these limits.
The "large" version comes with precompiled windows binaries.
Changes from v6:
* When map size too large is selected, the text gets red-colored to indicate it.
* Strings are no longer in translation and are generated dynamically
* Limits decreased to "reasonable" values, however increasing them is very simple. Just open map.h and modify MAX_MAP_TILES_BITS from 22 to 26 and MAX_MAP_SIZE_BITS from 13 to 20. This will enable resolutions like 1048576*64 or 8192*8192 (and you'll need 1.3GB memory for them). If you have 2.6GB, you can set MAX_MAP_TILES_BITS to 27 and have yet larger sizes, etc ...
Changes from v5:
* Removed workaround around bug that was fixed in 10719 (not showing 64bit ints in NUM and COMMA).
Changes from v4:
* fixed selected resolution clamped to 2048 when it is saved in openttd.cfg
Changes from v3:
* fixed misaligned combobox in scenario editor
* fixed crash when map_x & map_y in config file was outside permitted bounds when starting scenario editor
I have included new version of the patch. Along with defining maximum alowed dimension of the map (which I have raised to 262144) there is maximum number of tiles in the map (It is 4096*4096). If necessary to change the limit, it can be changed in one place (map.h) and rest of the code will reflect the changed limit (You should be able to raise it up to 32768*32768 theoretically before some overflow may possibly occur, though raising the limit that high will require 64bit architecture and insane amounts of RAM, so I suggest it stays at 4096*4096, which works well on good PC's (which is ~ 1.5-2 Ghz CPU + 512Mb RAM) with reasonable number of towns and industries
When user selects too large resolution exceeding maximal number of tiles when he wants to generate new land, he gets a warning and new land is not generated unless he reselect some smaller resolution.
Saving and loading now works fine.
This version is now enough stable to be candidate for including into trunk.
[/UPDATE]
I have created experimental patch that allows you to play with maps up to 8192 x 8192.
There are few problem with such large sizes:
* Generating such large map takes ... quite long
* Tileloop for such large map eats considerable amount of CPU time, so even if the map is "empty", you need good CPU to get decent performance
* You need lot of memory (8192 x 8192 needs 1.3GB, 4096 x 4096 needs 340MB)
Noodly resolutions (1024x4096, 512x8192) with reasonable number of tiles work fine without any problems or big memory/CPU demands (they perform like 2048x2048)
So ... do you think it will be good patch for trunk, if number of tiles will end up to be limited to 4millions?
(for example Italy scenario will be good with 1024x4096 map size. Or scenario in any other country which is thin and long)