News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Climate texture images

Started by Max-Max, October 08, 2013, 05:32:28 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Max-Max

When generating Climate textures we use:

Obj=ground
Name=ClimateTexture
# water
Image[0][0]=texture-climate.0.0
# beach/desert
Image[1][0]=texture-climate.0.1
# tropic (uses standard grass)
Image[2][0]=texture-climate.0.6
# mediterran (uses standard grass)
...
...


What is the second index used for? It is always set to zero in the .dat files I have been looking in.

Is it possible to define more than one texture for a climate and have Simutrans randomly pick one each tile to minimize repetitive patterns?
- My code doesn't have bugs. It develops random features...

Ters

Water uses it for animation. I don't know if other climates would animate if given other frames, or if it's just a vestigial consequence of sharing the same data structure.

kierongreen

They wouldn't animate - it is indeed vestigal. Minimising repetitive patterns would be possible with a small amount of code, quite a large increase in number of stored images and a reasonable way of generating a fixed number to use for each tile.

Max-Max

#3
Quote from: Ters on October 08, 2013, 05:49:59 PMWater uses it for animation. I don't know if other climates would animate if given other frames, or if it's just a vestigial consequence of sharing the same data structure.
That was my first though too, but the water animation look like this:

Obj=ground
Name=Water
# hangtyp * animation
Image[0][0]=ls-water-128.0.0
Image[1][0]=ls-water-128.0.1
Image[2][0]=ls-water-128.0.2
Image[3][0]=ls-water-128.0.3


Here the second index is also 0.

Quote from: kierongreen on October 08, 2013, 08:30:38 PM
They wouldn't animate - it is indeed vestigal. Minimising repetitive patterns would be possible with a small amount of code, quite a large increase in number of stored images and a reasonable way of generating a fixed number to use for each tile.

Yes I tried to add more Climate textures but nothing happened. Makeobj did add them to the PAK file so I guess it would be quite "simple" to have the world generator to pick one randomly.

Unfortunately I have no experience of the code beyond GUI stuff...  :-[

The writer calls the first index hangtype and the second for phase (if I got the right writer "ground_writer.cc").
Hangtype spans from 0 to 127 while phase spans the range from 0 to a signed int.
- My code doesn't have bugs. It develops random features...

kierongreen

Having more than one texture for each climate would expand image numbers considerably. Each new texture would need 65 images to go with it. So, 4 images for each climate would mean 7*3*65=1365 extra images. Well, maybe not the end of the world but still quite a few more.

It's not a question of the world generator picking one randomly (that would mean storing more information). Rather have a simple algorithm to give a "random" number for each tile.

Max-Max

Quote from: kierongreen on October 08, 2013, 09:24:28 PM
Having more than one texture for each climate would expand image numbers considerably. Each new texture would need 65 images to go with it. So, 4 images for each climate would mean 7*3*65=1365 extra images. Well, maybe not the end of the world but still quite a few more.
I don't follow where you get those numbers from?
There are 8 climate textures and if I want for example temperate to have 4 images to chose from, it would be the 8 + 3 images. Where do you get 3*65 from?

Quote from: kierongreen on October 08, 2013, 09:24:28 PM
It's not a question of the world generator picking one randomly (that would mean storing more information). Rather have a simple algorithm to give a "random" number for each tile.
Well, that was what I meant, use map seed so it gets the same every time... ;)
- My code doesn't have bugs. It develops random features...

kierongreen

Each texture needs to be mapped to each slope image it might be used for (avoids calculating the transformations during drawing). So that's 65 images for each texture. I'd assume you'd want all climates to have a variety of textures too, so put both together...

Max-Max

Quote from: kierongreen on October 08, 2013, 09:59:36 PM
Each texture needs to be mapped to each slope image it might be used for (avoids calculating the transformations during drawing). So that's 65 images for each texture. I'd assume you'd want all climates to have a variety of textures too, so put both together...
Ahh, Simutrans creates the images, I don't have to paint over 1000 images :D Okay I get it...

Still it would be a neat option for the PAK designers... With today's computer standar, I don't think memory is an issue... ;)
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on October 08, 2013, 08:50:50 PM
That was my first though too, but the water animation look like this:

Obj=ground
Name=Water
# hangtyp * animation
Image[0][0]=ls-water-128.0.0
Image[1][0]=ls-water-128.0.1
Image[2][0]=ls-water-128.0.2
Image[3][0]=ls-water-128.0.3


Here the second index is also 0.

I was confused by the layout of the pak64 dat file. First index is indeed the animation, while the second index is the depth. I got it backwards, but the rest should be correct.

prissi

You are right, most of the images does not need to be 2D image lists. Since those are stored in lists of lists, traversing them could take up dome time when getting too large. Although in profiling list traversal did not show up; but then those template functions may be inlined and never show up in profiling.

Dwachs

The image number is cached per tile. So these lists do not need to be traversed each time the tile is displayed.
Parsley, sage, rosemary, and maggikraut.

prissi

This is true, but marker, borders, and slopes are looked up more frequently. Still, might not be an issue (beyond a source of confusion aparently).