Page 1 of 18

Updated extra-large-maps patch, version 12 (for r23992)

Posted: 17 Jul 2007 02:42
by Bilbo
[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)

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 03:01
by Snorbuckle
Good LORD.

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 05:23
by athanasios
So we should ask someone to create a scenario with Chile! :wink:

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 06:56
by DJ Nekkid
sounds cool...

with a 8192x8192 one could probably make a fairly good mockup of the whole europe without haveing to place only capitals and thoose would be rather close to each other...

but there is the performance issues... guess thats why TTDlx only had 256x256 maps...

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 08:51
by White Rabbit
I wouldn't be playing the extra large maps, even if I could. The largest size I ever played with is 1024x1024, and even then I only covered about 1/2 of the map before 2090.

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 11:59
by MJS
How did you get to 2090? I thought OTTD ended in 2051?

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 12:00
by Tom0004
MJS wrote:How did you get to 2090? I thought OTTD ended in 2051?
the game carrys on untill what ever date you want, just that you get your high score in 2050

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 16:43
by nicfer
I think that large maps (bigger than 2048x2048 = 4194304 tiles) should be disabled (if you try to put in a coordinate size 4096 while the other is also 4096 the selector returns to the previous selection and a error message is shown). Also, sizes bigger than 1024x1024 (1048576 tiles) should be disabled (or maybe 524288 tiles max, because 1024x1024 will be a hell to play for dial-up players :P).

See later.

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 16:50
by Bilbo
UnderBuilder wrote:I think that large maps (bigger than 2048x2048 = 4194304 tiles) should be disabled (if you try to put in a coordinate size 4096 while the other is also 4096 the selector returns to the previous selection and a error message is shown). Also, sizes bigger than 1024x1024 (1048576 tiles) should be disabled (or maybe 524288 tiles max, because 1024x1024 will be a hell to play for dial-up players :P).
I think 2048*2048 are not to be removed, dialup users just have to avoid servers with such large maps :)

Yesm, I plan to do the 4194304 tiles limit before trying to get this to trunk, since larger map won't fully work due to some other limitations anyway (actually, the only hard limitation I encountered is the saving and loading of such game. Other than that, only speed of CPU+size of RAM limits you)

But no such limit is currently there, cause the patch is experimental and ... let the people try even the monstrously huge map sizes :)

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 17:53
by nicfer
UnderBuilder wrote:Also, sizes bigger than 1024x1024 (1048576 tiles) should be disabled (or maybe 524288 tiles max, because 1024x1024 will be a hell to play for dial-up players :P).

See later.
It should be
Also, sizes bigger than 1024x1024 (1048576 tiles) should be disabled for network games (or maybe 524288 tiles max, because 1024x1024 will be a hell to play for dial-up players :P).
Sorry for the error :(.

Anyway, great patch.

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 18:19
by Bilbo
UnderBuilder wrote:
UnderBuilder wrote:Also, sizes bigger than 1024x1024 (1048576 tiles) should be disabled (or maybe 524288 tiles max, because 1024x1024 will be a hell to play for dial-up players :P).

See later.
It should be
Also, sizes bigger than 1024x1024 (1048576 tiles) should be disabled for network games (or maybe 524288 tiles max, because 1024x1024 will be a hell to play for dial-up players :P).
Sorry for the error :(.

Anyway, great patch.
Why? 2048x2048 works fine in network game (well, at least for some time, since once train network grows too large and here are too many trains, it is no longer possible to conect in 0.5.[23]. Perhaps it was fixed in nightly, but there are no nightly servers with good settings for that, so I can't try ... since when I tried at localhost, the bug does not manifest itself ... )

There is still plenty of servers running maps with sizes acceptable even for dialup users

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 18:28
by Mchl
I'd love to play 128x8192. Such maps makes your network look more like a single line than a... errr... network...
Can be quite challenging.

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 19:16
by XeryusTC
Dial up users should not be joining games with big maps instead of disabling them for everyone. Why would everyone have to be limited by a rather small group of people (AFAIK)?

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 19:27
by wolf

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 22:10
by Nickel_Plate
Check out this thread for my large maps

http://www.tt-forums.net/viewtopic.php? ... 311&hilit=

I am already up to 8192 x 8192 but you will need lots of cpu power and loads of ram.

Re: Experimental extra-large-maps patch (for r10597)

Posted: 17 Jul 2007 23:49
by Bilbo
Nickel_Plate wrote:Check out this thread for my large maps

http://www.tt-forums.net/viewtopic.php? ... 311&hilit=

I am already up to 8192 x 8192 but you will need lots of cpu power and loads of ram.
Hmm ... basically the same patch as mine, except you solve that savegame problem ... :)

I run some more tests:

Athlon 3000+, 1gb ram
4k*4k (very low cities and industries)
Map generated in 43 seconds (IMHO acceptable)
190Mb RAM consumed during map generation
315Mb during save
~20Mb savegame size (some modern games have over 100Mb per one save, so 20Mb is IMHO acceptable)
Empty game ate around 40% CPU (may be good ...)

-> 4096 x 4096 map will work on 3ghz CPU and 512Mb RAM

But you have to use low number of towns+industries, if you use highest as I did in first attempt, the map will be too slow (it will work, just not in "realtime").

So, when saving, 4K x 4K eats 300MB of RAM, 8K x8K would need 1.2GB during save

With 16K x 16K ... hmm ... you'll need a 64bit system for that.

I may test 16K x 16K once I get to appropriate computer :)

Re: Updated extra-large-maps patch (for r10607)

Posted: 18 Jul 2007 04:40
by Bilbo
I have updated the patch and as it works well for me, I post it here so everybody can test it before I submit it to FS.

The maps can now be 16384 tiles wide! (8 times more than before)
The maps can now be 16384 tiles high! (8 times more than before)

Only problem is that not both at once :)

Still, the limit for map size was raised to 4096*4096 for square sizes and for same number of tiles for non-square sizes, so following (or smaller) map sizes are also possible:
8192 x 2048
16384 x 1024
2048 x 8192
1024 x 16384

See first post for the updated patch.

Re: Updated extra-large-maps patch (for r10607)

Posted: 18 Jul 2007 08:53
by rav
really nice!

I'll start testing it when I get my new laptop (Core2Duo 2GhZ, 2048 RAM, 256MB dedicated graphics card..)
tiny suggestion: would it be possible to write a patch so that OpenTTD will see what your cpu speed and ram is, so you can allow 'dynamical' max map sizes? this would prevent users selecting maps that are too big! :)

Re: Updated extra-large-maps patch (for r10607)

Posted: 18 Jul 2007 15:23
by Bilbo
rav wrote:really nice!

I'll start testing it when I get my new laptop (Core2Duo 2GhZ, 2048 RAM, 256MB dedicated graphics card..)
tiny suggestion: would it be possible to write a patch so that OpenTTD will see what your cpu speed and ram is, so you can allow 'dynamical' max map sizes? this would prevent users selecting maps that are too big! :)
It would be hard to determine what your computer can handle and what not. Some map sizes work well with low number of towns and industries, while they will crawl while your CPU usage is at 100% if you use high number of towns and industries. And once you put in 2000 trains, even smaller maps like 1024x1024 can be slow ..

I think I'll let the users to figure up themselves what their computer can handle and what it can't :)

If you try to run 2048x2048 map on some old computer with 32MB of ram, it won't work either and the game won't try to stop you from that, so defacto I'm keeping status quo :)

Best what can be done is to change AllocateMap to handle error when allocation memory for the map more gracefully, unfortunately, that would require to change the function so that it will return true in success and false in failure. And the same for the functions that call it (InitializeGame). And the same for Load_MAPS and few others. Unfortunately, changing Load_MAPS will require changing rest of the chunk handlers as well, as they need to have same function signature. Then it would be possible to handle the error more gracefully than by crashing with error message.

Re: Updated extra-large-maps patch (for r10607)

Posted: 18 Jul 2007 17:50
by DJ Nekkid
16k*256 would be fun... :)