Slicing strategy for industry/house graphics...advice?

[andythenorth]

I am going to need to start slicing FIRS graphics for coding soon:
http://tt-foundry.com/sets/FIRS/schema/graphics

I have prepped lots of vehicle graphics for code, but no graphics for industry/houses. I'm clear on the basics - blue bounding box, indexed palette, pcx, width a multiple of 4.

As usual, I'll have a go at this and see what I learn, but some tips might be useful. I have had a look at PBI and it seems that slices can be larger than a tile (makes sense).

Constraints:
- we need flexibility in layouts (the buildings are designed for this); alternative layouts need to be quick to produce, reusing same graphics
- animation will be added in future to many industries
- all my files are layered photoshop, I can split the ground tiles and individual buildings easily

Any advice?

cheers,

Andy

[frosch]

The easiest, most fool-proof way (that will never result in glitches) to do that, is

• to use one bounding box (BB) per tile that
• starts at <0, 0, 0> and
• has size <16, 16, z> with z < 128,
• and to draw only inside this bounding box.

So, everywhere where that is possible you should just stick to that

Likely there are cases when those items are too restrictive, esp. with animations. In that case it is harder to find something that works.

But there are some general rules:

• Groundsprites must be exactly of the size of the tile, else they will glitch when they or neighboured tiles have foundations or not.
• Try to use as few BB as possible. Use childsprites instead if you want to draw multiple sprites.
• Childsprites must not extent over the parent sprite. Add transparency to the parent sprite in that case.
• Graphics extending over the left or the right of the tile will cause glitches as OTTD does not add them to the list of sprites to draw, when it updatred the screenrect just left or right of the tile.
• Try to avoid overlapping BB of very different size/shape.
• When you have multiple BB on a tile, often it is better to make them of simliar shape and put them next to each other, even though parts of the sprites extend over them.

But as you see, everything is quite fishy. I always wanted to write some tool that checks the spritelayout and detects glitches, but never got around to it

Finally, for debugging you should know the effect of Ctrl-B inside OTTD

[FooBar]

Now that Ctrl+B is interesting. All of a sudden I understand the whole bounding-box principle.

Whoever invented Ctrl+B:

[andythenorth]

The easiest, most fool-proof way (that will never result in glitches) to do that[..snip...]

thanks