News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

North America 5120x3276

Started by kierongreen, July 08, 2012, 11:01:01 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

kierongreen

This includes all of the continental United States, Mexico and Cuba, along with some other Central American and Caribbean countries. Water height should be set to -10.

Source is from USGS data, with significant processing afterwards, including altering the perspective. I can't give guarantees about the entire coastline but I've made sure that New York, Washington and San Francisco are reasonable (although Manhatten is only 3 tiles wide at this size...)

I'm planning this as a testbed for climate and water height work. Though even with this extreme heightrange the Great Lakes are only 1 or two tiles above sea level (with Niagara Falls being 1 tile high). The Appalachian Mountains are up to 9 tiles high, with the Rockies stretching to 20 tiles high. They should prove a formidable challenge for anyone aspiring to complete the Transcontinental Railroad!

I've tested this with my double height patch - it may not display entirely as intended in standard simutrans.

Download link:
http://simutrans-germany.com/files/upload/northamerica5120x3276.zip

Fabio


kierongreen

New version with corrections made to coastline - link above updated to new version.

Isaac Eiland-Hall

The Gulf Coast looks pretty reasonable. If it was a totally hand-made map, I might expect the bays I know to be better represented - but for a tweaked map, it's quite good. Let me be clear: I approve and think it's good - I'm impressed with the quality. :)

I wish I had the patience to do things like replicate the actual rivers... :)

Lmallet

Since Canada is barely included and Alaska missing, this map should be called half-of-North-America.  :)

But still, a very good looking map! 

kierongreen

QuoteSince Canada is barely included and Alaska missing, this map should be called half-of-North-America.
So little of Canada is included I actually didn't even mention it in the description! The map goes up to 50 degrees north, so Southern Ontario and Quebec, along with Nova Scotia are the main areas of Canada included. I've nothing against Canada (or Alaska), it was purely a practical decision not to include it as correcting for distortion above 50 degrees north was going to become increasingly difficult. Also I've deliberately edited out Newfoundland (along with Haiti and the Dominican Republic) as these islands would be half off the map in any case.

QuoteIf it was a totally hand-made map, I might expect the bays I know to be better represented - but for a tweaked map, it's quite good.
On the Gulf Coast I checked the areas around Houston, New Orleans and the Florida Keys (along with parts of the Mexican coast) with Google Maps to ensure a reasonable accuracy. For other areas I did a quick check to make sure there wasn't any huge errors, but the large number of lagoons and barrier islands mean that it's quite difficult to represent everything. If you want to give suggestions for areas you are familiar with that would be very welcome! :)

I'd be very impressed if someone could create a detailed hand made map of North America at this size, it would require a fair bit of patience I think!

Incidentally other areas I did quite a bit of tweaking with were Nova Scotia, the New England Coast, New York, Philadelphia, the Delaware River and San Francisco.

To use the Great Lakes properly will require water height editing, I've not tried this yet but that will mean more fun and games working out the coastline there!

Combuijs

How did your computer survive this map? Anyway, it is now available on Simutrans Maps, plus an honourable mention in the Simutrans blog. It is the biggest map known at the moment.
Bob Marley: No woman, no cry

Programmer: No user, no bugs



kierongreen

It was actually a bigger problem with memory editing the bitmap than it was playing in simutrans. I dread to think how much load a developed map this big would place on the processor - but there is a lot of ocean so it might not be too bad. Only issue in simutrans for me was that the double height landscape takes about 2 hours to generate for this map for some reason (I may look into exactly why it takes so long). Incidentally this is very close to the absolute limit of simutrans maps at the moment (they have to be less than 16.7m tiles, i.e. 4096x4096 or equivalent).

derajjared


Combuijs

Quote from: kierongreen on September 04, 2012, 08:33:08 PM
Incidentally this is very close to the absolute limit of simutrans maps at the moment (they have to be less than 16.7m tiles, i.e. 4096x4096 or equivalent).

Yes, 4896 tiles short. You could have made a 5121x3276 map, but not a 5120x3277 map...  :P
Bob Marley: No woman, no cry

Programmer: No user, no bugs



Carl

Quote from: kierongreen on September 04, 2012, 08:33:08 PM
Incidentally this is very close to the absolute limit of simutrans maps at the moment (they have to be less than 16.7m tiles, i.e. 4096x4096 or equivalent).

How does this limit manifest itself? I've played around with significantly larger maps for testing, and haven't yet run into any game-breaking problems. However, I did alter the executable to make it large-address aware, i.e. able to occupy more than 2GB of RAM. I guess that's subverting the problem.

kierongreen

Ground labels may become corrupted on large maps (particularly when rotating). This also affects station and town names, as well as user added labels. From boden/grund.cc:

// since size_x*size_y < 0x1000000, we have just to shift the high bits
#define get_ground_text_key(k,width) ( ((k).x*(width)+(k).y) + ((k).z << 25) )

// and the reverse operation
#define get_ground_koord3d_key(key,width) koord3d( ((key&0x01ffffff))/(width), ((key)&0x01ffffff)%(width), ((key)>>25) | ( (key&0x80000000ul) ? 0x80 : 0x00 ) )


Labels each have a unique value which is a combination of x,y and z coordinates. Having this in one 32bit value means that it is quicker to look up. It's as a list rather than reserving a pointer for every tile as this saves memory (for a maximum size map this size that would take up an additional 64MB of memory).

Actually looking at this seems like it will be 2^25 not 24 so 33.4m tiles (contradicting one comment in the code). 25 bits combined for x and y, 7 bits for z.

transporter

I don't think that link's working. I downloaded a set of islands with that file still labeled as north america

kierongreen

Have you made sure water height is set to -10?

Carl

#14
Quote from: kierongreen on September 04, 2012, 11:09:12 PM
Ground labels may become corrupted on large maps (particularly when rotating). This also affects station and town names, as well as user added labels. From boden/grund.cc:

// since size_x*size_y < 0x1000000, we have just to shift the high bits
#define get_ground_text_key(k,width) ( ((k).x*(width)+(k).y) + ((k).z << 25) )

// and the reverse operation
#define get_ground_koord3d_key(key,width) koord3d( ((key&0x01ffffff))/(width), ((key)&0x01ffffff)%(width), ((key)>>25) | ( (key&0x80000000ul) ? 0x80 : 0x00 ) )


Labels each have a unique value which is a combination of x,y and z coordinates. Having this in one 32bit value means that it is quicker to look up. It's as a list rather than reserving a pointer for every tile as this saves memory (for a maximum size map this size that would take up an additional 64MB of memory).

Actually looking at this seems like it will be 2^25 not 24 so 33.4m tiles (contradicting one comment in the code). 25 bits combined for x and y, 7 bits for z.

Thanks, that's very interesting. If the limit is indeed 33.5m (around 5800 * 5800) then I think "out of memory" errors on map creation may prevent exceeding it with an unmodified exe, in many cases.

Combuijs

Quote from: transporter on September 05, 2012, 03:20:58 AM
I don't think that link's working. I downloaded a set of islands with that file still labeled as north america

If you download from Simutrans Maps, there is a readme.txt file in the zip file, which states exactly what Kierongreen said: water level = -10.
Bob Marley: No woman, no cry

Programmer: No user, no bugs



transporter

I downloaded from the link at the top. No readme file. Only the map file itself.

VS

Ah, ok. The message with link also says...
Quote from: kierongreen on July 08, 2012, 11:01:01 AM
Water height should be set to -10.
... sorry, couldn't resist :D I would have done the same, anyway - maybe tried changing water level after the first failure.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Combuijs

#18
Quote from: Combuijs on September 05, 2012, 06:52:09 PM
If you download from Simutrans Maps, there is a readme.txt file in the zip file, which states exactly what Kierongreen said: water level = -10.

Quote from: transporter on September 06, 2012, 12:16:17 AM
I downloaded from the link at the top. No readme file. Only the map file itself.

I now this post is in vain, because you apparently can't read, but you really should download this map from Simutrans Maps http://maps.simutrans.com/downloads/britishisles2440x3816.zip. Simutrans Maps guarantees you that it is always a zip-file (no rar, 7z etc.), that there is additional information if necessary (for example water height) and that it is either the only map of the region or a very good playable map.

Edit: 300 edits to get the link right ...
Bob Marley: No woman, no cry

Programmer: No user, no bugs



VS

Lol, we had an edit war it seems :D I fixed the link, too.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

asaphxiix

hello kierongreen, can you tell us what cpu and ram you have?
thanks

kierongreen

Dual core atom 1.6Ghz (D510), 2GB RAM.

transporter

How are you able to run that map with that little?! I have twice that and it freezes for the season changes

prissi

Season change is mostly determined by trees. Without trees memory consumption and season change are much much less severe.

kierongreen

Indeed - I haven't tried playing this with trees. The main problem with this map is how long it takes (especially with my double height patch) to generate a new map using this heightmap - around 20 minutes if I remember correctly. Undoubtedly a developed map this big would probably be too much for my computer.

It's often quite handy for developers to have machines less powerful than average. If you can get a game working on a slow computer it will work nicely on a faster one...

transporter

What things are going on at the end of each month? The game slows to half speed for a few seconds then speeds back up again

IgorEliezer

Quote from: kierongreen on November 11, 2012, 10:41:46 PM
Indeed - I haven't tried playing this with trees. The main problem with this map is how long it takes (especially with my double height patch) to generate a new map using this heightmap
Off-topic: what if the map generation were split into squares of 256x256 tiles? And as the player "walks" farther from the origin, new squares are generated based on heightmap or map seed?

transporter

Once those squares are generated, would they stay? It's sounds like what Minecraft does. But the terrain stays there the whole time so it wouldn't change the seasonal change problem once your map grows too large

kierongreen

I don't think continuing to generate the map after starting a game is going to work that well. For me at least one of the first things I do is to scroll around looking at where cities and terrain features are to plan where initial transport links will be. Then there is question of ships crossing ungenerated terrain and so on...