Is this possible?

[unmerged(11294)]

I was wondering if this is at all possible (the terrain underneath)... Was talking to Hive and he said something about max memory or something, that it could surpass it and be too much memory.

Well he may be right and before I continue i wanted to ask others around if they knew if this was at all possible, thanks.

Also wondering if theres threads on mapping, like i dunno how to seperately shade seazones, and Hive's vague explaining didnt help much

 

[Birger]

There's a 16 megabyte limit in lightmap, so the map can't be any "bigger" than that.

Care to share those settings for drawing the map? It looks really sweet.

 

[Hive]

Also wondering if theres threads on mapping, like i dunno how to seperately shade seazones, and Hive's vague explaining didnt help much

Pfft, I already told you: magic wand is your friend.

 

[Hallsten]

<map>

I was wondering if this is at all possible (the terrain underneath)... Was talking to Hive and he said something about max memory or something, that it could surpass it and be too much memory.

Well he may be right and before I continue i wanted to ask others around if they knew if this was at all possible, thanks.

Also wondering if theres threads on mapping, like i dunno how to seperately shade seazones, and Hive's vague explaining didnt help much

That map is so good looking, if it could actually be realised it'd do A LOT for the look and feel of the game. good work!

 

[Hive]

That map is so good looking, if it could actually be realised it'd do A LOT for the look and feel of the game. good work!

I'm pretty sure you will exceed the 16 megs limit with this all over.

 

[Inferis]

Probably.

The 16meg limit is not so much imposed by the compression, but rather due to the offset mechanism used to find a block. These are the offsets in the beginning of the file, and they are only 24 bits wide, limiting the total size of the file to 16 megs (640K ought to be enough for anyone?).

AFAIK, the other games have 32 bit offsets. I don't know the rationale for keeping the offsets small, except for memory constraints: adding an extra byte means 592x228 or 131k extra (which is not THAT much), but it does allow for larger compressed blocks which might give for much larger memory footprint for the game.
But just expanding the offsets to 4 bytes does not much, if you keep the map the same, so I don't really know why Johan did this.

 

[unmerged(11496)]

That map is so good looking, if it could actually be realised it'd do A LOT for the look and feel of the game. good work!

That *is* pretty sweet!

I just snagged his terrain color mod, so he certainly has the chops...hope it all "fits!"

 

[WiSK]

But just expanding the offsets to 4 bytes does not much, if you keep the map the same, so I don't really know why Johan did this.

Perhaps a hangover from EU1?

What I'd really like to do, if I ever had the time, is write an optimiser which would look at the most effective way to draw each block. You once wrote to me in email about how the quadtree is a really clever thing, and it is, provided the underlying data doesn't work against it.

The problem with many of these nice looking textures is that they are exactly the kind of data which doesn't work well with the quadtree. Whereas the smooth (but perhaps a little boring) radial gradients used by Paradox are ideal for such a compression method.

One thing that bothered me when I finally succeed to make the map shading editable was that I never got the same level of compression as Johan's original blocks. This especially when downsizing from lightmap1 to the higher zooms. I'm guessing that Johan somehow preprocessed his photoshop source files to make best use of the quadtree.