Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extra large maps patch #1059

Closed
DorpsGek opened this issue Jul 20, 2007 · 29 comments
Closed

Extra large maps patch #1059

DorpsGek opened this issue Jul 20, 2007 · 29 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay

Comments

@DorpsGek
Copy link
Member

bilbo opened the ticket and wrote:

I 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 1638416384 and still work on 32bit machines (possibly even more for 64bit ones), but I decided to limit it to 16.7 million tiles (40964096 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: http://www.tt-forums.net/viewtopic.php?f=33&t=33137

Attachments

Reported version: trunk
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/1059
@DorpsGek
Copy link
Member Author

bilbo wrote:

Updated patch, with one minor bug fixed:

fixed selected map resolution clamped to 2048 when it is saved in openttd.cfg

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment1656

@DorpsGek
Copy link
Member Author

TrueBrain wrote:

Are there any noticeable side-effects of this patch? How good was your bug-testing?


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment1664

@DorpsGek
Copy link
Member Author

bilbo wrote:

Technically, as the patch basically only removes some hardcoded limitations to max size and adapts GUI to that (with exception of raising the pool size to be able to load/save large sizes properly), I can almost guarantee that map sizes under 2048x2048 are not affected by this patch, so if this patch uncovers any bugs, they will manifest only with at least one of the dimensions being 4096 or more.

Like there is #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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment1666

@DorpsGek
Copy link
Member Author

TrueBrain wrote:

The reason I ask, is that in the past we planned a 4kx4k option. This was removed later on (when the bigmap patch was created), as it gave problems. It is possible that by now all those problems are solved already, without really anyone knowing, but we want to make sure it is. Things to look at: lighthouses, transmitters, old-landscape generator, trains, AIs, ... Please let me know if this is tested really well (also by other users). Tnx :)


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment1673

@DorpsGek
Copy link
Member Author

bilbo wrote:

Up till now I found two bugs (slow rail construction which I already reported and bug in old terrain generator which I am going to report), but I found out that openttd without my patch is also affected by them. So my patch is not cause of these bug. Still, I'll test things further and I'll let you know once I'm finished with testing.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment1703

@DorpsGek
Copy link
Member Author

bilbo wrote:

Well, so that was probably not a bug, just the original generator generate quite a lot different landscapes with same settings than with these settings in temperate (half of map is raised, half of map is relatively flat)

But still it looks pretty weird ...


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment1704

@DorpsGek
Copy link
Member Author

bilbo wrote:

Attached newer version. Removed workaround around bug that was fixed in 10719 (not showing 64bit ints in NUM and COMMA).

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment1736

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 4, 2007

TrueBrain wrote:

Some comments:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment2599

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 4, 2007

TrueBrain wrote:

After a bit more talking, some other requests: limit the max values to 8192 for now. This avoids all GUI changes.

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 :)


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment2600

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 6, 2007

bilbo wrote:

65536? Or even 8192? That is not much. I think I'll change the code so that game will load savegame with any number of tiles (as long as dimensions are power of two, at least 64 and total number of tiles is < MAX_MAP_TILES - to keep compatibility if that limit is changed in the future or to be able to load savegames created with other (older) version of this patch)
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?


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment2619

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 6, 2007

Belugas wrote:

Because we have translators who are assigned to that task.
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


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment2620

@DorpsGek
Copy link
Member Author

bilbo wrote:

Yes, I know dev's don't need to do the translations, but why forbid them doing that, especially if I am native czech speaker? :)
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...

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment2692

@DorpsGek
Copy link
Member Author

bilbo wrote:

Attached modified version of the patch - the MAX_MAP_TILES limit is enforced only in GUI when creating or generating a new world, but not when loading a savegame. Thus savegames created with older versions of this patch (or with this patch with modified limits) with larger sizes (like 65536x64) can be loaded (but limit od max. number of tiles is enforced strictly), while still blocking creation of new maps larger than limit (currently 8192) in any dimension.

map-256k-11415-nolimit.patch = map-256k-11415.patch with the above mentioned change

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment2693

@DorpsGek
Copy link
Member Author

bilbo wrote:

Attached is new versiion of patch against 11616 - map-256k-11616.patch

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.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment2935

@DorpsGek
Copy link
Member Author

bilbo wrote:

Added new version compatible with changes in trunk (recent source code refactorings). No functionality changed from previous patch.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment3095

@DorpsGek
Copy link
Member Author

DorpsGek commented Jan 8, 2008

bilbo wrote:

New version adapted to recent minor changes in trunk (moving some thing around headers). Functionality remains the same.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment3178

@DorpsGek
Copy link
Member Author

bilbo wrote:

New version adapted to trunk changes (11848). Functionality remains the same

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment3248

@DorpsGek
Copy link
Member Author

bilbo wrote:

Due to changes in trunk (dynamic dropdown list, genworld_gui adapted to dynamic dropdown list) I have to update my patch again.

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.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment3290

@DorpsGek
Copy link
Member Author

bilbo wrote:

Due to introduction of DrawWindowWidgets function, my code had to be modified again.
I am attaching updated patch (functionality remains exactly the same as in old one, no new features)

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment3332

@DorpsGek
Copy link
Member Author

bilbo wrote:

Updated patch to 12388 (sync with very slight trunk change)

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment3745

@DorpsGek
Copy link
Member Author

bilbo wrote:

Fixed patch for 12388 (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)

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment3746

@DorpsGek
Copy link
Member Author

bilbo wrote:

Ok, so trunk changed a lot and last version of the patch no longer merges with the trunk.

I am attaching patch updated to trunk (r13664).

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment4400

@DorpsGek
Copy link
Member Author

bilbo wrote:

Forgot to reapply fix, that fixed bug when trains too far apart (more than approx. 4096 squares) can crash into each other.

Attaching fixed patch.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment4401

@DorpsGek
Copy link
Member Author

sensation wrote:

hello all!...i m new here. i was searching for something that can permit me tu run extra large maps in OpenTTD.and i foud this forum...how can i run XL maps with this patch that u have here...what am i sopose to do with it?please, give me all the instructions. thank you very much


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment5465

@DorpsGek
Copy link
Member Author

bilbo wrote:

Attaching patch updated to 16598, with coding style fixed up a bit

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment6247

@DorpsGek
Copy link
Member Author

bilbo wrote:

Differences to previously posted 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 ... )

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment6248

@DorpsGek
Copy link
Member Author

bilbo wrote:

Train collision speedup and some parts (some enumifying) was added to trunk.

Attaching patch updated to current trunk

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment6278

@DorpsGek
Copy link
Member Author

DorpsGek commented Feb 4, 2010

bilbo wrote:

Attaching patch updated to current trunk (some modification were required due to adapt to changes in GUI code) - functionality is same as in last patch.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059#comment7517

@DorpsGek
Copy link
Member Author

andythenorth closed the ticket.

Reason for closing: Won't implement

Not a current goal for OpenTTD. Thanks.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1059

@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay labels Apr 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay
Projects
None yet
Development

No branches or pull requests

1 participant