Battlezone Forums

Is it possible? If so, how is it done? If not, is it possible to implement into the next patch or something?

I vote for this.

I ask this because I've been splitting textures into 16 pieces to reduce tiling and whatnot and wish to inquire about being able to do that and more. Also, transitional textures could be used on layer 0 to great effect if the texture amount was 20-30 or more. This would make maps look a lot better on terrain detail low and would work in the same way as creating a shadow map to eliminate the need to have light sources on.

Knowing how the TERs are formatted, no, and this won't be changing soon if ever as it would mean an entire new map format.

You can make transparent .png textures that convert to dxtbz2 very well, spraying these about helps break up the tiled look.
A shadow effect can be achieved with the colour layer.
command line \Shellmap 256 (for example) will make a 256x256 picture of the Illuminated map in the bz2 directory, you can then adjust this and use winter to re-paint the map with it. If you do it right you can get very nice looking shadows permanently painted onto the map. This also helps break up the tiled look.
Having 16 textures on low terrain detail (layer 0), would probably perform worse that 8 on high.

Nielk1 wrote:Knowing how the TERs are formatted, no, and this won't be changing soon if ever as it would mean an entire new map format.

AFAIK, omitted TextureTile #'s in the terrain file simply cause the editor to behave as if the said tile is a blank one. Don't know how adding the capability to add more Texture Tiles would change that behavior.

EDIT: I thought you said TRN, not TER . Whoops.

People who select low detail terrain, do so because they value performance over appearance, A good map will appease them, just use a very ordinary looking 128x128 or 256x256 all over layer 0, the colour layer will provide some variation. Put all the other textures on layers 1-3. That way you give everyone what they want.

MrTwosheds wrote:People who select low detail terrain, do so because they value performance over appearance, A good map will appease them, just use a very ordinary looking 128x128 or 256x256 all over layer 0, the colour layer will provide some variation. Put all the other textures on layers 1-3. That way you give everyone what they want.

Properly mixed up layer 0 textures should not be harmful to FPS since they do not use alpha transparency like the layer 1-3 textures. There are also some players that don't use high terrain detail simply because their PCs cant handle it (they are CPU intensive), and others who prefer low terrain detail due to the medium detail tiling bug in 1.3.

Yes, the vets who run low textures don't run it on high because then they would need to use their left hand to continuously crank their PC rather than only occasionally

Exactly. I know one player who can barely play maps with a 400m vis range without his PC going all to hell. I swear, his computer must be powered by a hamster and maybe the hamster doesnt run very fast.

That's my point, don't use layer 0 to decorate the maps, its there to help those with clockwork pc's or laptops, just the one texture is great for them, 16 is much less so. Put the eye candy where it can be turned off.
Medium is just ugly, its not a bug as such, its just a legacy compromise, use either high or low, most modern gaming pcs can handle high terrain without any noticeable issues, it is actually fairly well optimised now.
The big performance hits come from all lights and fog(any).

MrTwosheds wrote:A shadow effect can be achieved with the colour layer.
command line \Shellmap 256 (for example) will make a 256x256 picture of the Illuminated map in the bz2 directory, you can then adjust this and use winter to re-paint the map with it. If you do it right you can get very nice looking shadows permanently painted onto the map. This also helps break up the tiled look.
Having 16 textures on low terrain detail (layer 0), would probably perform worse that 8 on high.

http://bz2maps.us/phpBB/viewtopic.php?f=19&t=3026

I use this technique already and it has fairly realistic results.

Exactly. I know one player who can barely play maps with a 400m vis range without his PC going all to hell. I swear, his computer must be powered by a hamster and maybe the hamster doesnt run very fast.

Sent? Manslayer?

Nielk1 wrote:Knowing how the TERs are formatted, no, and this won't be changing soon if ever as it would mean an entire new map format.

Shame that, could you explain why that is the case? Can the formatting not be changed to allow more?

Zero Angel wrote:Exactly. I know one player who can barely play maps with a 400m vis range without his PC going all to hell. I swear, his computer must be powered by a hamster and maybe the hamster doesnt run very fast.

That's all well and good, but there is a reason Microsoft wants nobody to support IE6 anymore. XP is losing support. I mean really, when you can go to any junkyard and find any PC there to salvage that is better than yours, it is time to no longer support that demographic. We have a beautiful DX9 renderer now, use it.

Mortarion wrote:Shame that, could you explain why that is the case? Can the formatting not be changed to allow more?

One issue is backwards compatibility. Which should make more sense after the 2nd issue.

The second is the actual formatting of the file. The textures are stored in one nibble of the info DWORD for a given cluster (1 terrain tile of 4 by 4 vertexes). As there are 4 layers in a cluster, and thus 4 textures, and 2 nibbles is a BYTE, and 2 BYTEs is a WORD, this takes up half of the entire DWORD. The other half holds bits of ownership data and other important misc stuff.

Adding another whole WORD per cluster would raise the texture count to 255 though it would require some fancy footwork in the coding. There are a lot of places in BZ2 that expect a nibble not a BYTE.

While I would support the inclusion of more texture options, doing it would cause massive shock waves though the entire code base. There is a chance that it isn't as bad as it looks to me, however, I find it doubtful that a game like BZ2 was made with any robustness considering it was released with a huge portion of its content cut and buggy as all hell. The interface looks, at first glance, like it could support more textures since it passes integers, however, there is no way to know how the rest of the BZ2 code uses this. I will look into it more but I figure there is a slumbering beast of "ME WANT NIBBLE, NOT BYTE" somewhere in the BZ2 code.

For reference, after header data, the terrain structure is organized in clusters from top left to bottom right. These clusters contain 16 shorts for height, 16 bytes for normal, 16*3 bytes for color,16*3 bytes for alpha for the 3 overlaying layers, 16 bytes for the 'Cell' data, and a DWORD for the info. That order might not be perfect. If you wish to really understand the TER structure, you can look at the TER editor that was posted by Nitroxis, however he does not sort the data into clusters (which makes it easier to understand). I posted some altered code that is able to get at the textures but it took some bit-shifting and bitwise operations to filter it correctly.

You know, after writing this even I am wondering if BZ2 could handle 256 textures for the terrain instead of 16. Changing the format of the TER actually wouldn't be that bad. I was afraid of nibbles floating around but there is an even number of nibbles because there is an even number of layers, and 2 nibbles makes a byte. I think I might ask GSH some questions regarding this.

There is the issue that it goes from 14 BYTES per cluster to 16 if there were more textures, which would result in a similar increase in all map sizes. If we used a half-nibble (even weirder code) the texture cap would be 64.

Yea... I need to think about this more. And maybe bug GSH a bit. Might take till June till I have the time to really get into it. And if on the rare chance something did come of it it would probably not be pb7 (if pb7 exists).


EDIT:
One addendum, the system has to be fast. Like bit-shifting to get it done fast.

For example, this gets the texture number out of the info DWORD right now: There is no existing container to hold a DWORD+BYTE, or a WORD+BYTE (if we snap off the WORD of misc data) so there is no elegant way to pull this off.

If the system allowed 256 textures the code would look like this: Where Info would be changed into a WORD and the half of it that had the texture data would be moved and added to the new WORD to form a DWORD.

In any case its a pretty big change to format and would mess with everything else in the game. But it's interesting.

as a computer illiterate that went way over my head, but thanks for taking the time to explain it, ill look over that another time... lol