Devs: Map size limit _desperately_ needs an increase

[Caydr]

I read another thread on this subject somewhere but I can't find it now. Anyway, point is, even if it's a lot of work I think this needs to be a high priority for upcoming versions. I (and others, I'm sure) have big plans... but the engine cannot handle them in its present state. A maximum size more like 32768 or 65536 (8x what it is now) would likely be a good spot if a maximum size is necessary at all.

[Buggi]

Yeah I looked at the code... Needs to be adjusted a few places, though I'm not sure how embedded that hardcoded number is.

[10053r]

Check out the other thread I started on this. It shows where in the code to make the change...

It seems to be related to the texture memory issue. If we increase the map texture to be more than 1024 x 1024, then it will work?

[Ace07]

Check out the other thread I started on this. It shows where in the code to make the change...

It seems to be related to the texture memory issue. If we increase the map texture to be more than 1024 x 1024, then it will work?

The problem stems from the fact that textures are meant to be fairly small. The bigger they are, the slower the engine goes.

If there was a way to split the texture even into 4 pieces, you could probably get bigger maps.

[[K.B.] Napalm Cobra]

Doesn't it split into to hundreds, if not thousands of tiles when compiling?

It seems to be related to the texture memory issue. If we increase the map texture to be more than 1024 x 1024, then it will work?

I've got an 8192x8192 and it works, I think you mean heightmap.

[Ace07]

I am not sure....I hope it doesn't do it the way I say. Using one big texture for the entire map would be wasteful of the GPU's resources. I know it isn't a tilebased system, but I still don't really understand how maps work.

[SJ]

Well the spring map is covered by several textures. The main texture is indeed 8192*8192 for a 16x16 (TA screens) map. This texture is created as needed from tiled data and should already support more or less infinite maps. But there are also two other textures for the shading and overlay (los, height) textures. These are updated realtime as the map (or los situation) changes and are 1024*1024 for a whole 16*16 map. So to make them bigger one would have to make these grow for larger maps.

The only slight problem is that they are updated often so they cant be compressed and they have to be power of two. So even for a moderate larger size than 16*16 (say 18*18 ) they would have to become 2048*2048 and start taking lot of texture memory.

[10053r]

The only slight problem is that they are updated often so they cant be compressed and they have to be power of two. So even for a moderate larger size than 16*16 (say 18*18 ) they would have to become 2048*2048 and start taking lot of texture memory.

K. I don't really know what I'm talking about here, but it sounds like you are rendering the whole map as one object? What if you rendered it as many tiles? Couldn't you then have maps as large as you want? You would have issues with getting them to blend into each other, but it sounds like putting in the work to make this work would have other advantages as well, like increased performance overall.

[[K.B.] Napalm Cobra]

I think he's saying that because they are created on the fly, losmaps etc may become unefficently big.

[SJ]

The main problem with breaking them up as the main color texture is as you say that the seems would probably very visible. It could maybe be solved by a texture border but I have never gotten good results with that. If someone want to experiment, go ahead. Otherwise I will proabably just make them grow in the next version and ppl that want to play big maps will have to have big graphic cards.

[10053r]

The main problem with breaking them up as the main color texture is as you say that the seems would probably very visible.

3 points.

1) 1024 x 1024 x 32 is 4.2 megabytes That isn't that big. We can double the size to 2048 x 2048 x 32 and still fit in 17 MB, which is getting pretty large, but will fit into a 512 MB graphics card just fine. And if we are willing / able to cut the resolution on the heightmap to only 16 bit, rather than 32 bit, we can get it down to 8.3 megabytes. 2048 x 2048 heightmaps are 32 x 32 screens, OTA style. That's respectable, but I'd like to see up to 100 x 100 supported, so this approach won't work really, since we'd be looking at 8192 x 8192 to get that, which works out to 134 MegaBytes, even with only 16 bits of height resolution.

2) If each pixel of heightmap resolution was its own rectangular solid, then the seams wouldn't show, because the map would be full of them. Additonally, you could support perfectly vertical edges, which would be nice for places like core prime. And then you could load as many of them as you wanted to fit in graphics card memory at one time. Smaller memory graphics cards would be able to just show less terrain at once, which would solve the issue once and for all. Maps would only be limited by the size of the texture maps for them, and height maps wouldn't be an issue at all. This is very programming intensive, though, I'd imagine, and would probably entail a reworking of much of the internals and the map format.

3) So what if you were to change the heightmap horizontal resolution? Do we really need bumps that are 1 /16 the area of a metal extractor? I think OTA only supported 1 / 4th, and even if it didn't I think that is a reasonable size. If we were to make the smallest possible bump in the terrain be the size of a mine or a flea, then we could double map size without affecting memory at all. Then we could quarter the vertical resolution to 8 bit (these are floats, right?) and go from 16 x 16 OTA style to 64 x 64 OTA style. That's not too small. In 24 months, when graphics card memory has quadrupled, we can double it again to 128 x 128 screens, which will be a very respectable maximum map size.

Here are the numbers. Each pixel of horizontal resolution is currently 1 / 64th of a screen of OTA resolution. So we make it into 1 / 32, making an OTA screen be 32 x 32 instead of 64 x 64. I think I read somewhere that vertical resolution is currently 32 bit, so we quarter it to 8 bit, and make it a float. That still leaves us with some billions of possibilities for heights. But even if it is an int, that still leaves us with 256 possibilities for height, which is really ok. So now we have a 1024 x 1024 x 8 texture memory object to fit in memory. That is 1 megabyte. Each time we double max hotizontal size, we quadruple memory consumption. So we double it twice, making for a 17 MB object. Since 4096 / 32 is 128, we have achieved 128 x 128 screens of OTA size and fit our objects into memory in a resonable manner.

I don't think game mechanics can really handle much more than 100 screens without making games longer than a day, so this should work nicely.

[[K.B.] Napalm Cobra]

512 MB graphics card

Hahahhahhahahhahahhahhahhahahhahahhahahhah.

Raise your hand if you have a 512meg graphics card?

[SJ]

Considering that some ppl want us to increase the heightmap resolution i dont think they would be to happy if we cut it in half. And these textures arent the heightmap, the heightmap isnt read from textures.

[Neuralize]

I would rather have bigger maps than deformable terrain

[Buggi]

Mine's 256meg

Would it be possible to compress the maps in memory? How often do you have to access them?

[[K.B.] Napalm Cobra]

Every time you render?

[Snooky]

2048x2048 (16384x16384) seems good enough to me. A 32x32 map in TA is getting pretty big and this would cover 95% of most games (especially multiplayer) played period. In fact I am willing to bet most games on maps over 16x16 are typically played by us LAN gamers anyway.

I'd say give us the option to go at least 32x32.

-S

[Torrasque]

For me 32*32 would cover 95% of my games too. It's 4 times bigger than 16*16. 64*64 would be very cool but 16 time bigger than now...I think I would play it 2x per year :)

[Redfish]

I've hardly ever played any maps over 18x18(PD) in multiplay. Must be all the newbs playing those HUGE metal maps

[10053r]

I've hardly ever played any maps over 18x18(PD) in multiplay. Must be all the newbs playing those HUGE metal maps Razz

K. I'm willing to argue with you till I'm blue in the face about the value of large maps, but I object being called a nube. I've been playing TA since 1998. I feel I've earned the right to say with a certain level of authority that very enjoyable and strategic gameplay can occur on maps up to 50 x 50 screens. It is a different game than "The desert triad", sure. But is a GOOD game, especially when you have a 4 vs 4 game on that level, with each team playing in its own lab so they can talk to each other.

Game I like playing take epic scale to a whole new level. Amongst my friends, we rush each other sure, but we consider an attack in the first half hour a rush. We have Krogoth rushes, and nuke rushes (my record is 11 minutes to big-K stepping out of the gantry on eastside-westside). We lament the faliability of nuke defense of OTA (it can be overloaded by launching 3 volleys of 4 nukes each, even if the enemy nuke defense has over 12 missles and time to launch them). A NORMAL game for me involves over 12K per tick of energy produced.

18 x 18 means that a bertha stuck in the middle can hit the whole freaking map. I am strongly in favor of territory being fought over, rather than all territory being in play at all times. That is, there should be territory that is mine, territory that is yours, and territory that is no man's land. 18 x 18 means that even the middle of my base is no man's land.

Real tanks can fire for miles. Larger maps mean more realism. Realism isn't always a good thing, but I am in favor of it in this case. You shouldn't always know where your enemy is, and you shouldn't be able to hit his base from your own. So yes, we need 100 x 100 maps. Someone smarter than me figure out how to make it work and fit in 256 mb of graphics memory. Those cards are only $50 these days.