FS#1059 - Extra large maps patch
Attached to Project:
OpenTTD
Opened by Bilbo (bilbo) - Friday, 20 July 2007, 00:23 GMT
Last edited by andythenorth (andythenorth) - Monday, 14 August 2017, 20:11 GMT
Opened by Bilbo (bilbo) - Friday, 20 July 2007, 00:23 GMT
Last edited by andythenorth (andythenorth) - Monday, 14 August 2017, 20:11 GMT
|
DetailsI think that the extra large maps path is now enough stable to be candidate for including into trunk.
And there it is - attached is patch for r10634 This patch enable to play on maps up to 262144 high and up to 262144 wide, although not that large in both dimensions at once. There is maximal number of tiles, changeable in map.h - theoretically it could be upped to 16384*16384 and still work on 32bit machines (possibly even more for 64bit ones), but I decided to limit it to 16.7 million tiles (4096*4096 map), which is the most that reasonably fast computers (~2ghz, 512mb ram) can reasonably handle. Changing the limit in map.h is all that is needed for the limit to change, rest of the code will accomodate to this. Performance on smaller map sizes is unaffected by this patch. Other dimensions are also possible, like 8192x2048, 16384x1024 ... 262144x64. The last one is very nicely playable with fast airplanes, planes now actually spend more time in flight than by accelerating, landing, circling, taxiing, loading, unloading, etc ... Savegame compatibility is maintained, except older versions won't be able to load maps with one or both of dimensions larger than 2048 tiles Link to forum thread: https://www.tt-forums.net/viewtopic.php?f=33&t=33137 
map-256k-10634.patch
(16.7 KiB)
|
This task depends upon
Closed by andythenorth (andythenorth)
Monday, 14 August 2017, 20:11 GMT
Reason for closing: Won't implement
Additional comments about closing: Not a current goal for OpenTTD. Thanks.
Monday, 14 August 2017, 20:11 GMT
Reason for closing: Won't implement
Additional comments about closing: Not a current goal for OpenTTD. Thanks.
|
|
fixed selected map resolution clamped to 2048 when it is saved in openttd.cfg
Like there is
FS#716- a bug that will occur with long straight 2000 tiles of track without signals. A bug which will not happen on 1024 x 1024 maps. Not so common, but sometimes such tracks are build, mainly for testing :) It may be possible that some other internal limit will be triggered, but I am not aware of any currently.As to the larger map sizes. I tried to generate many maps of various width and playing some games on it.
On some of the large maps I tested old AI was present and it behaved normally, as on regular size maps.
I played several hours with plane route over 260000 squares, with several times saving, exiting and loading the map again.
I have not yet tried to create a train, bus and ship route across all the 260000 squares. I think I'll have yet to test that.
I have not noticed any side effects or odd behavior.
But still it looks pretty weird ...
Don't include other languages than english.txt
+ uint64 map_x = 1U << _patches_newgame.map_x;
+ uint64 map_y = 1U << _patches_newgame.map_y;
+ uint64 tiles = map_x * map_y;
+
+ if (tiles > MAX_MAP_TILES) {
This can be done much faster. _patches_newgame.map_x + _patches_newgame.map_y > MAX_POWER_TWO will do the same ;) (2^a * 2^b = 2^(a+b) ;))
+ SetDParam(0, MAX_MAP_TILES);
+
+ SetDParam(1, tiles);
Silly enter.
+ case GLAND_GENERATE_BUTTON: { // Generate
No need for the {} there.
Also, 262144 is just too big. Please make the max value 65536.
Make the MIN_MAP_SIZE, ... enums.
Don't use doxygen comments inside functions.
Last comment: we have doubts 4kx4k really works. Please keep the maximum allowed tiles on 4M for now. In the future we can do tests to increase this value.
Second, if an invalid amount of mapx/mapy combination is selected, make the text RED. This is a clear indication to the user that the value is too large, which should help out the process of selecting a valid combination :)
So the limits would be applied only to newly-created games.
Creation of new games could be restricted to 8192.
I can change the max_map_tiles to 4M, as it could be easily raised later :)
I'll do the other changes, but I wonder why not include czech translation as well?
As a default behaviour, we never impose translations, we let them do the job.
So, in this case, it will make the patch smaller.
So only english.txt is enough
Well, I have removed the czech translation as requested. I have moved them to separate file (map-256k-11415-czech.patch). Feel free not to use the file :)
Also, I encounteres small issue:
I wondered whether it is possible to add strings to combo boxes without them having a string ID (or generating such strings with ID's dynamically)
Now when the maximum is to be raised, you still need to update string ID's in translations
Idea is, when someone changes just the constants (MAX_MAP_SIZE_BITS, ...), everything would work without need to make additional changes (like adding extra strings to translation) and things like:
STR_512 :512
STR_1024 :1024
STR_2048 :2048
STR_4096 :4096
could disappear from translations.
Is there any version of ShowDropDownMenu and DrawString that takes ordinary string (const char *) as input instead of string ID?
Also, I am attaching new patch with above mentioned corrections done (map-256k-11415.patch), although I don't get what was meant with "Make the MIN_MAP_SIZE, ... enums." and I have not yet made the text to be red in the GUI with invalid selection. I'll look into it further, I'll try also to somewhat avoid the StringID's for the combobox for the path to be better configurable...
map-256k-11415-nolimit.patch = map-256k-11415.patch with the above mentioned change
Difference against previous version:
* No longer need numbers in translation, so changing map size limits in future is easy, just modify map.h, no more need to add extra string for larger map sizes. (Note: str_64, str_128 and alike would need to be evicted from non-english language files. Do you have some automated way of doing that, or should I write a script to do it and send a patch that will clean the other language files?) Also rising maximal dimension over 8192 in future would need to resize the GUI a bit, otherwise the strings will end up misaligned
* When map size that is too large is selected, the text will turn red, as TrueLight suggested.
map-256k-11616-czech.patch (optional) contain translation for czech language.
Good thing is that the changes simplified my patch (from 14.5kb to 9.5kb)
I hope the patch is now fine to get in trunk.
I am attaching updated patch (functionality remains exactly the same as in old one, no new features)
I am attaching patch updated to trunk (r13664).
Attaching fixed patch.
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 selcted 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 ... )
Attaching patch updated to current trunk