I use bigmaps all the time when I use openttd ,but it's infested with bugs!
Are there any updates planned in the foreseeable future?
Electrified railways' be good but Openttd really needs a much better selection of locos and road vehicles ,along with diagonal roads but I guess I'm dreaming when of the possibility of all that in one tt game!
Latest with biggermaps?
Moderator: OpenTTD Developers
Hmmz.. you guys are all bigmap addicted aren't you? 
Here is a small update from me. I am currently trying to get bigmap in SVN. To accomplish this we have to walk through some steps.
First, we need to make all the code compatible with more tiles (currently, the limit is 65536, 256x256, the map-size). The patch for this is ready, and awaiting merging with SVN (the current OpenTTD version, nightly build, call it how you want).
Second, we are going to make the map dynamicly. This means for you, the end user, that you can pick any map between 50x50 and 255x255. So maps of 200x50 will be possible and so on. This will be done in a memory saving way, so it will still work on old PCs.
Third, we are going to change industry-placing, city-placing and stuff like that, so it scales good with the map. Maybe it will be merged in one patch with the second one, we will see.
Last, we are going to increase the map-size to a max of 65536x65536 (yes, that will be possible, only you will need like a 1 THz PC to run the game smoothly). Most likely the max will be set to 1024x1024, and I will suggest to publish 2 version: the low-mem version (max 256x256), and the high-mem version (max 1024x1024). The savegames will be compatible, which means that a high-mem can always read a low-mem, and that a low-mem can only read maps from a high-mem which are below 256x256.
This is what I have planned. Currently we are finishing step 1... took about a week to get it all done. You do the math how long the rest will take
(exponential )
Here is a small update from me. I am currently trying to get bigmap in SVN. To accomplish this we have to walk through some steps.
First, we need to make all the code compatible with more tiles (currently, the limit is 65536, 256x256, the map-size). The patch for this is ready, and awaiting merging with SVN (the current OpenTTD version, nightly build, call it how you want).
Second, we are going to make the map dynamicly. This means for you, the end user, that you can pick any map between 50x50 and 255x255. So maps of 200x50 will be possible and so on. This will be done in a memory saving way, so it will still work on old PCs.
Third, we are going to change industry-placing, city-placing and stuff like that, so it scales good with the map. Maybe it will be merged in one patch with the second one, we will see.
Last, we are going to increase the map-size to a max of 65536x65536 (yes, that will be possible, only you will need like a 1 THz PC to run the game smoothly). Most likely the max will be set to 1024x1024, and I will suggest to publish 2 version: the low-mem version (max 256x256), and the high-mem version (max 1024x1024). The savegames will be compatible, which means that a high-mem can always read a low-mem, and that a low-mem can only read maps from a high-mem which are below 256x256.
This is what I have planned. Currently we are finishing step 1... took about a week to get it all done. You do the math how long the rest will take
(exponential )
truelight, great work!
but hurry up so I can get my spinoff to the SVN version
but hurry up so I can get my spinoff to the SVN version
Creator of the Openttd Challenge Spinoff, Town Demand patch
After action reports: The path to riches, A dream of skyscrapers
After action reports: The path to riches, A dream of skyscrapers
imo, just release one with the limit set to the 65536x65536, and just let people know when they go to download it, etc what the suggested limits are. Its easier than trying to maintain two versions, and if there's masochists out there that really really want a 16384x8096 map or something wierd and really huge, let 'em clunk away playing it.TrueLight wrote:Last, we are going to increase the map-size to a max of 65536x65536 (yes, that will be possible, only you will need like a 1 THz PC to run the game smoothly). Most likely the max will be set to 1024x1024, and I will suggest to publish 2 version: the low-mem version (max 256x256), and the high-mem version (max 1024x1024). The savegames will be compatible, which means that a high-mem can always read a low-mem, and that a low-mem can only read maps from a high-mem which are below 256x256.
Hehe, too bad that is not possible. The consequents are too great. I can type here a lot of technical stuff explaining it, but it comes down to the fact that when we put the limit to 65536x65536, a map of 256x256 would use 65536x256 bytes of memory.. so all of a sudden the game is not playable on a old computer, or a PALM, or something like that. And no, if we want to keep the speed in the game, that can not be done in any other wayElshar wrote:imo, just release one with the limit set to the 65536x65536, and just let people know when they go to download it, etc what the suggested limits are. Its easier than trying to maintain two versions, and if there's masochists out there that really really want a 16384x8096 map or something wierd and really huge, let 'em clunk away playing it.TrueLight wrote:Last, we are going to increase the map-size to a max of 65536x65536 (yes, that will be possible, only you will need like a 1 THz PC to run the game smoothly). Most likely the max will be set to 1024x1024, and I will suggest to publish 2 version: the low-mem version (max 256x256), and the high-mem version (max 1024x1024). The savegames will be compatible, which means that a high-mem can always read a low-mem, and that a low-mem can only read maps from a high-mem which are below 256x256.
But it will all work out just fine, you will see
The main problem is that you compile the limit into the game.. for people who understand a bit of the code: TILE_X_BITS is compiled hard-coded, so TILE_XY and GET_TILE_X/Y are really fast. TILE_X_BITS is therefor always reserved in the memory (in the way of 1 << TILE_X_BITS). In other words, when you compile a version with TILE_X_BITS to 16, all maps are the size of 65536xTILES_Y. When you pick a lower X, you simply do not see a part of the map. It is there in the memory! So you understand, not many PC's can handle that amount of memoryBouke wrote:Yes... please don't bother people with 2 different versions. Simply display a warning when the users selects a (too) large map.
But I will discuss this on IRC with dev's.. when we agreed on it I will let you guys know
I have a suggestion:
You can make a max of size of map 1024x1024 but you can still select sizes like 6000x6000 and more but when you do so the original game closes and imediately runs another executible that has it's limit set to superhuge maps and you can start plaing your superhuge map.
So in that way when there are two executibles you don't waste any memory when loading 256x256 map becouse you run it on big maps executible which counts 1024x256 bytes
And when you play the game with 6000x6000 then then you waste memory becouse you run it on superhuyge maps executible wich counts
65536x6000
so this way you can have all kinds of maps in one release with two exe's
which are made that you always start with low mem one and can swich to hihg mem one when you select a superhuge map and press the start game button.
You can make a max of size of map 1024x1024 but you can still select sizes like 6000x6000 and more but when you do so the original game closes and imediately runs another executible that has it's limit set to superhuge maps and you can start plaing your superhuge map.
So in that way when there are two executibles you don't waste any memory when loading 256x256 map becouse you run it on big maps executible which counts 1024x256 bytes
And when you play the game with 6000x6000 then then you waste memory becouse you run it on superhuyge maps executible wich counts
65536x6000
so this way you can have all kinds of maps in one release with two exe's
which are made that you always start with low mem one and can swich to hihg mem one when you select a superhuge map and press the start game button.
I like this ideaKiller 11 wrote:I have a suggestion:
You can make a max of size of map 1024x1024 but you can still select sizes like 6000x6000 and more but when you do so the original game closes and imediately runs another executible that has it's limit set to superhuge maps and you can start plaing your superhuge map.
So in that way when there are two executibles you don't waste any memory when loading 256x256 map becouse you run it on big maps executible which counts 1024x256 bytes
And when you play the game with 6000x6000 then then you waste memory becouse you run it on superhuyge maps executible wich counts
65536x6000
so this way you can have all kinds of maps in one release with two exe's
which are made that you always start with low mem one and can swich to hihg mem one when you select a superhuge map and press the start game button.
Don't know if it is possible, but I like it As said: TILE_X_BITS can _not_ be dynamicly because that would slow down the whole game.. things like TILE_XY en GET_TILE_X would be about 10 times slower then they are now... do a search for them and check how many times they are used.. you do the math..Bouke wrote:Well... why then hardcode the TILE_X_BITS? If you could make that one dynamic there's no problem at all.
-
lucaspiller
- Tycoon
- Posts: 1228
- Joined: 18 Apr 2004 20:27
-
Moriarty
- Tycoon
- Posts: 1395
- Joined: 12 Jun 2004 00:37
- Location: United Kingdom of Great Britain and Northern Ireland
- Contact:
[quote]how much memory will it use[/quote]
This is a laymans answer.
TTD presently uses about 7-8mb or my machine, for a regular 256*256 map, which contains the 65 536 squares.
assuming a 65 536 * 65 536 map, that gives us 4 294 967 296 squares, which is of course 65536 times larger.
So by my (admitidly rather inacurate) maths, that means it would require in the vicinity of:
65536 * 7 = 458 752 MB (or 450GB or ram).
But then of course the 7-8 mb isn't all information about the map. much of it is graphics.
so let's try another way.
Assuming that each square contains 1 byte of information (i don't know how much each square has, so i'm being conservative).
There will be 4 294 967 296 squares, which means 4 294 967 296 bytes.
which is about 4GB. Noting that regular 32bit machines can't do more RAM than that anyway, it would seem we're all going to have to upgrade to Athlon 64's
This is a laymans answer.
TTD presently uses about 7-8mb or my machine, for a regular 256*256 map, which contains the 65 536 squares.
assuming a 65 536 * 65 536 map, that gives us 4 294 967 296 squares, which is of course 65536 times larger.
So by my (admitidly rather inacurate) maths, that means it would require in the vicinity of:
65536 * 7 = 458 752 MB (or 450GB or ram).
But then of course the 7-8 mb isn't all information about the map. much of it is graphics.
so let's try another way.
Assuming that each square contains 1 byte of information (i don't know how much each square has, so i'm being conservative).
There will be 4 294 967 296 squares, which means 4 294 967 296 bytes.
which is about 4GB. Noting that regular 32bit machines can't do more RAM than that anyway, it would seem we're all going to have to upgrade to Athlon 64's
You are not far of.. there are about 6 arrays of tiles. So 65536x65536x6 bytes of memory.. which gives us 25 769 803 776 bytes, which is 24 GBMoriarty wrote:This is a laymans answer.how much memory will it use
TTD presently uses about 7-8mb or my machine, for a regular 256*256 map, which contains the 65 536 squares.
assuming a 65 536 * 65 536 map, that gives us 4 294 967 296 squares, which is of course 65536 times larger.
So by my (admitidly rather inacurate) maths, that means it would require in the vicinity of:
65536 * 7 = 458 752 MB (or 450GB or ram).
But then of course the 7-8 mb isn't all information about the map. much of it is graphics.
so let's try another way.
Assuming that each square contains 1 byte of information (i don't know how much each square has, so i'm being conservative).
There will be 4 294 967 296 squares, which means 4 294 967 296 bytes.
which is about 4GB. Noting that regular 32bit machines can't do more RAM than that anyway, it would seem we're all going to have to upgrade to Athlon 64's
You will understand that this is not possible And, maybe I was not that clear on that statement, for this reason alone there will not be a version which can create maps of this size. What I stated was that the absolute max will be 65536x65536 instead of 256x256. It can be limited to any power of 2, so in my opinion 1024 or 2048 should be enough (which gives 7 MB / 25 MB of memory uses). In other words, instead of the 256x256 limit, the limit will be 1024x1024.
what about using a command line variable for example
and if its left empty it defaults to low memory (256) mode enabling the variable to be set here would mean that the game had to be forced to start in the mode that requires the most memory.
Of course i may be miles out because i havnt played with windows programming for years now.
Code: Select all
ttd.exe -bigmapOf course i may be miles out because i havnt played with windows programming for years now.
OpenTTD is platform-independent, Windows only code for a major function like bigger maps will not be accepted, as there are almost as many if not more OpenTTD users on alternative platforms.stewis wrote: Of course i may be miles out because i havnt played with windows programming for years now.
The reason for this is that Windows users can use The Patch, us non Windows users cannot.
Who is online
Users browsing this forum: No registered users and 8 guests