Tallest sprite ingame?

[ChillCore]

Hello everybody,

I am curently finetuning the main viewport scrolling clamping with the more heightlevels patch.
I need to add some pixels more to be able to see what is build on tile(1, 1) heightlevel 255 when fully zoomed in.
Is there anybody that knows how tall, in pixels, the heighest sprite is used ingame?
Also, can I asume this value to be the same for TTDPatch and OpenTTD, if whenever I get to spriting some day?

As always, any help would be greatly appreciated.

[cmoiromain]

I think the height can be changes by newgrf (in TTRS, there are huge skyscrapers, some of the are even glitchy, or at least used to be).

[planetmaker]

Sprite height is indeed set by the individual newgrfs for each sprite seperately. TTRS(?) has some really high skyscrapers, probably a height of 200 pixels or so. In the comic house set I assigne all houses a bounding box height of 180 pixels irrespective of their actual height.

The NewGRF wiki doesn't mention any max value AFAIK http://wiki.ttdpatch.net/tiki-index.php ... oordinates But assuming 200 pixels or so should be safe.

[ChillCore]

Hmm, yes, I have noticed those few glitchy skyscrapers before, hence why I was wondering if there was a maximum height for sprites without having glitches. I would have used that value if it was there.

Thank you for your answers and the link. I will go by 200 pixels for now.

Come to think off it, we also needed to know this for taking a screenshot.

[eis_os]

A ttd sprite can be 255 pixels in height by the newgrf format + any yrel you add....
(I assume you calculate back to original TTD sizes)

[frosch]

Weird topic Every post gives a different answer.

I assume the building height planetmaker refers to is the height of the bounding box in the spritelayout. This height has no influence on the sprite being drawn or not, it only affects sprite sorting, which does not really limit the building height.

Important are some other numbers:
1) ViewportAddLandscape() contains some number which control which tiles are considered for drawing when drawing a certain area on the screen. These values are not changeable by any means of newgrf.

2) MarkTileDirtyByTile() contains some numbers which control which area is redrawn when a tile changes (house build/removed/animation/...).
These values can be changed in TTDPatch (not OpenTTD) via ActionD variables 0x93 .. 0x96. But as case 1) is far more important changing them is quite pointless.

So for your more-height-levels patch MarkTileDirtyByTile() should be fine, and you need to adapt the values in ViewportAddLandscape().

[ChillCore]

Weird topic Every post gives a different answer.

That is to make it easier for me to decide.
Who bids more/less?

I assume the building height planetmaker refers to is the height of the bounding box in the spritelayout. This height has no influence on the sprite being drawn or not, it only affects sprite sorting, which does not really limit the building height.

Everything seems to be drawn correctly with the code as is. The only thing that still needs finetuning regarding the scrolling, is how far we will allow people to scroll and how much pixels we include above tile(1, 1) when taking a giant screenshot.
The chances of having tile(1,1) being generated at height 255 is quite slim. In 99.9% of the cases it will be enough/too_much to just provide for 255 posssible heightlevels.
However I am thinking of introducing different values with different mapsizes. (Seperate function in a later version if possible.)

Important are some other numbers:
1) ViewportAddLandscape() contains some number which control which tiles are considered for drawing when drawing a certain area on the screen. These values are not changeable by any means of newgrf.

2) MarkTileDirtyByTile() contains some numbers which control which area is redrawn when a tile changes (house build/removed/animation/...).
These values can be changed in TTDPatch (not OpenTTD) via ActionD variables 0x93 .. 0x96. But as case 1) is far more important changing them is quite pointless.

VieportAddLandcape() is allready modified and should be future proof(untill now it is), however I can still take a peek in cleantrunk. (Lucky me.)
I will also take a look at those numbers in MarkTileDiryByTile(). Thank you for pointing me to those numbers.

So for your more-height-levels patch MarkTileDirtyByTile() should be fine, and you need to adapt the values in ViewportAddLandscape().

I still consider ic111 to be our lead coder. Although he seems to be a very busy man and it has been some time he has been around.

A ttd sprite can be 255 pixels in height by the newgrf format + any yrel you add....
(I assume you calculate back to original TTD sizes)

Meaning you can have a sprite of size 255 pixels and then you add yrel as offset where it is to be painted in relation to the tile it is on?
Or 255 pixels + yrel allowing for taller sprites?
Sorry if this seems like a weird question. Most of the code is written by ic111, and I didn't go to school for very long.

[michael blunck]

[...] These values can be changed in TTDPatch (not OpenTTD) via ActionD variables 0x93 .. 0x96. But as case 1) is far more important changing them is quite pointless.

You mean in OTTD. In TTDPatch, this does indeed work. There are quite a number of newgrfs which are successfully using action0D vars 93 .. 96.

HTH
regards
Michael

[George]

[...] These values can be changed in TTDPatch (not OpenTTD) via ActionD variables 0x93 .. 0x96. But as case 1) is far more important changing them is quite pointless.

You mean in OTTD. In TTDPatch, this does indeed work. There are quite a number of newgrfs which are successfully using action0D vars 93 .. 96.

Unfortunately it does not work in OTTD. I'd use them with pleasure