How we might achieve all tilesets at once ..

[Goth Zagog-Thou]

I've gotten into the habit of eyeballing the source code from time to time (Master versions, of course). I'd like to start a discussion about how we could possibly do that whilst maintaining compatibility with current-style maps.

I see that in /src/map.h (line 34 onward) that we enum TYPE_OF_TERRAIN as follows:

Code: Select all

/* The different types of terrain as far as the game is concerned */
enum TYPE_OF_TERRAIN
{
	TER_SAND,
	TER_SANDYBRUSH,
	TER_BAKEDEARTH,
	TER_GREENMUD,
	TER_REDBRUSH,
	TER_PINKROCK,
	TER_ROAD,
	TER_WATER,
	TER_CLIFFFACE,
	TER_RUBBLE,
	TER_SHEETICE,
	TER_SLUSH,

	TER_MAX,
};

and #define our three tilesets immediately after that.

What if we were to prefix those and differentiate them into three groups to read:

Code: Select all

/* The different types of terrain as far as the game is concerned */
enum TYPE_OF_TERRAIN
{
	TER_AR_SAND,
	TER_AR_SANDYBRUSH,
	TER_AR_BAKEDEARTH,
	TER_AR_GREENMUD,
	TER_AR_REDBRUSH,
	TER_AR_PINKROCK,
	TER_AR_ROAD,
	TER_AR_WATER,
	TER_AR_CLIFFFACE,
	TER_AR_RUBBLE,
	TER_AR_SHEETICE,
	TER_AR_SLUSH,
        TER_UR_SAND,
	TER_UR_SANDYBRUSH,
	TER_UR_BAKEDEARTH,
	TER_UR_GREENMUD,
	TER_UR_REDBRUSH,
	TER_UR_PINKROCK,
	TER_UR_ROAD,
	TER_UR_WATER,
	TER_UR_CLIFFFACE,
	TER_UR_RUBBLE,
	TER_UR_SHEETICE,
	TER_UR_SLUSH,
        TER_RM_SAND,
	TER_RM_SANDYBRUSH,
	TER_RM_BAKEDEARTH,
	TER_RM_GREENMUD,
	TER_RM_REDBRUSH,
	TER_RM_PINKROCK,
	TER_RM_ROAD,
	TER_RM_WATER,
	TER_RM_CLIFFFACE,
	TER_RM_RUBBLE,
	TER_RM_SHEETICE,
	TER_RM_SLUSH,
	TER_MAX,
}; 

And then have the engine grab the needed tile for that type? Or would this be a little bit *too* vague?

[Per]

Why do you want all tilesets at the same time? They represent different geographic locations that were not meant to blend.

[Berg]

If you want to change the look of the terrain make a new tile set..
A island tile set would be nice palm trees and hula girls etc.

[Shadow Wolf TJC]

Why do you want all tilesets at the same time? They represent different geographic locations that were not meant to blend.

Parts of some tilesets could, in theory, coexist in real-life. This is especially true with the Urban tileset, which could be set geographically anywhere, wet or dry, cool or warm, though there could also be, say, a cool dry desert, a tundra, where mountains have icecaps like in the Rockies tileset, while the ground below is barren like in the Arizona tileset, or a tropical setting, where it mixes the green grass found in the Rockies tileset with the sandy textures from the Arizona tileset.

[NoQ]

Why do you want all tilesets at the same time?

To make amazing maps!

[Goth Zagog-Thou]

ShadowWolf and NoQ hit it on the head. It's to make amazing maps and because the tiles can all work interchangeably. Snowy Desert, for example. Grey meets Red (like the geography one would see in Utah and Montana). Things like that.

[Rman Virgil]

.

It's also the next logical step on the heels of the already implemented universal map feature set.
.

[Goth Zagog-Thou]

And it would make converting FlaME over to the 3.1+ way of doing terrain that much easier, when that time comes.

[vexed]

I've gotten into the habit of eyeballing the source code from time to time (Master versions, of course). I'd like to start a discussion about how we could possibly do that whilst maintaining compatibility with current-style maps.
...

Code: Select all

/* The different types of terrain as far as the game is concerned */
enum TYPE_OF_TERRAIN
{[snip]
	TER_AR_WATER,
	TER_UR_WATER,
	TER_RM_WATER,

}; 

And then have the engine grab the needed tile for that type? Or would this be a little bit *too* vague?

Why would water/rubble/whatever behave any differently in urban than it does in arizona or ... ?

All you need to do is load up the textures, then fix the corresponding files that look up said texture.
Look in data\base\tileset.
Yeah, that is using the "decals" way like in 2.X... if you want to handle all textures via code on the new system, you need to fix the code and how maps are made with flame...

BTW, the resource system in WZ is ... not very smart, so, if someone was going to load all possible textures, it is possible to run out of texture memory on some machines.

[NoQ]

So it's necessary to make the resource systems smart and load only the textures that are actually used on a particular map ... >.<

[Goth Zagog-Thou]

Well, for water it shouldn't be necessary, but perhaps in the future someone might want lava (which can be treated like water, at least until hover propulsion units go over it, in which case it could be scripted that they take damage).

Thinking outside the box -- and thinking ahead so that the new terrain system could have the flexibility to handle things like lava and whatnot.

Never hurts to discuss.

[NoQ]

Probably a color adjustment for textures (and water) could be cool too ...

[NoQ]

Emm guys i just realized something. I think we already have everything we need to make multi-tileset maps as map-mods, without changing a single line of code, substituting png files or tripling memory usage.

All we need is to understand how Mysteryem's sandmod works. It modifies wrf files to inject another png file into vram and modifies some other file to assign it to a certain tile class. I think we can attach existing png files to tilesets in a similar way.

I'll try to come up with a proof of concept map-mod when i have time.

[Goth Zagog-Thou]

Oh hot damn! That's one of the reasons why I love this community so much -- we REALLY are thinkers.

I await that with baited breath, NoQ. Outstanding! /cheer

[NoQ]

One thing i forgot to mention is that it won't work on decals. But decals aren't too large to include when necessary.

It also might work on water (including some weird things like making the water cracky or fluffy etc.)