NewObjects specification

[SAC]

...which is absolutely fantastic to say the least!

I have a number of different projects as far as New Objects concerns, currently put on hold as I can't find enough space to make them come true. But this side effects will most definately change everything...

Lakie, you're a genious...

[Lakie]

Well, Rubidium should also get credit for refining the specifications, and helping to consolidate the implementations of NewObjects of TTDPatch and OpenTTD.

~ Lakie

[SAC]

Obviously...

My mistake...

Cheers Rubidium

[wallyweb]

As we need to develop a whole new spec/mechanism to give objects a layout and the time it takes for new specs to be properly tested I don't intend to do any work on this before 1.1 is branched, i.e. I won't push it into the 1.1 stable series.

Unfortunately real life interference prevented me from following up on this since OpenTTD 1.1 was branched.
Is this a good to time to revive the discussion around the potential for this feature? In a recent discussion, SAC was asking me about this feature, so a demand for it would seem to extend beyond myself and Michael Blunck:

The only "irregular layout" in TTD that I´m aware of is that of industries.

Maybe we could stick to that, resp borrow from it?

Any thoughts?

[michael blunck]

I´m just getting aware of the fact that newobjects don´t have an equivalent of callback "decide drawing default foundations (30 (industry tiles) / 14E (houses) / 150 (airports))".

Had this been overseen in the specification? Or should it be done "manually" (similar to stations)?

regards
Michael

[FooBar]

I'm not sure if this is what you're after, but foundations are drawn by default and can be disabled by an object flag. If you then want custom foundations, you have to add these manually to the object spritelayout.

From what I understand this flag is the replacement of the callback. If you actually need it to be a callback to conditionally draw foundations or not, then that is not possible.

[michael blunck]

Err, this was really a question to the developers ...

I'm not sure if this is what you're after, but foundations are drawn by default and can be disabled by an object flag. If you then want custom foundations, you have to add these manually to the object spritelayout.

Thanks FooBar, I´m doing exactly this all the time.

From what I understand this flag is the replacement of the callback.

Nah, it is not.

If you actually need it to be a callback to conditionally draw foundations or not, then that is not possible.

Point is that TTDPatch/OTTD are able to draw "custom foundations" for "houses, industry and airports" (nfo spec) "automatically", i.e. w/o having to manually check for all the slope variations. OTOH, stations don´t have that CB either (objects implementation is similar to stations), so that´s where my question arises: is it intentionally, or had it been forgotten?

regards
Michael

[FooBar]

At least we've established that you're well aware of all the possibilities.

[michael blunck]

At least we've established that you're well aware of all the possibilities.

Yeah, both objects and stations have a bit flag to control drawing of foundations:

stations:
bit3 - "use custom foundations on sloped tiles (the lowest byte of var. 10 is 2 for foundation sprites)"

objects:
bit5 - "do not display foundations if on a slope"

But it remains unclear from the spec what this means: Is there a mechanism for managing custom foundations like in stations (stations even support two modes for custom foundation drawing!), or is it only possible to deter the game to draw the usual foundations (and to supply something own in this case, either a custom foundation or part of the tile´s graphics to replace the usual foundation)?

For stations, the mode of operation of bit3 seems to be closely connected with that of bit0, but objects have no support of different sprite sets for ground sprites, at least that I know of. Nor mentioning of var10 returning appropriate information.

Documentation is deplorably questionable on this subject, it´d need a developer to supply valuable information.

regards
Michael

[planetmaker]

For objects it simply means "no foundations are drawn" and you'll have to adjust your sprites and tile layout to the actual slope of the tile. You then can draw your own foundations as part of the tile layout.

[Michi_cc]

For OpenTTD you can probably achieve a similar effect by using an advanced sprite layout with register offset, which is used to select the proper ground sprite.

-- Michael Lutz

[michael blunck]

For objects it simply means "no foundations are drawn" and you'll have to adjust your sprites and tile layout to the actual slope of the tile. You then can draw your own foundations as part of the tile layout.

I.e., the way how custom foundations are handled by some of the other features (the newGRF supplies an additional sprite block with the foundations, and then they´re drawn by the game according to the actual slopes w/o any further tinkering by the newGRF) is not available to objects, right?

Question remains why this had been "forgotten"? Figuring out the set of slopes of a certain tile by the newGRF and decide which part foundations to draw is quite an additive effort which could have been easily avoided?

Apart from the discrepancy w/r to other features.

[edit]

For OpenTTD you can probably achieve a similar effect by using an advanced sprite layout with register offset, which is used to select the proper ground sprite.

Too complicated for this trivial task, IMO.

regards
Michael

[planetmaker]

For OpenTTD you can probably achieve a similar effect by using an advanced sprite layout with register offset, which is used to select the proper ground sprite.

Too complicated for this trivial task, IMO.

That's one of the use cases the adv. spritelayouts were explicitly designed for.

Code: Select all

spritelayout spritelayout_name { 
	ground { 
		sprite: groundsprite_set(slope_to_sprite_offset(nearby_tile_slope(0, 0))); 
		recolour_mode: RECOLOUR_REMAP; 
		palette: PALETTE_USE_DEFAULT; 
	} 
}

EDIT: IIRC it was considered. But as stations are special in the way they handle their tile layouts and all other tile specs are more like houses and industries it was decided to not follow the stations special way to handle things. Leaving it to the NewGRF to decide on how foundations are drawn is the much more flexible approach. And as quoted above not more than 6 lines to get full slope awareness. In NFO a function to convert tile slope to offset might come in handy the same way but would be needed once and for all only, too.

[michael blunck]

That's one of the use cases the adv. spritelayouts were explicitly designed for.

I doubt that.

In fact, that particular feature seemed to have been developed for the really "complicated" cases. But instead, "custom foundations" (for e.g. stations) don´t even need any "special" treatment: just set up a sprite block with the foundation sprites and use var10 to distinguish between "ground sprite" and "foundation", and Bob´s your uncle.

And your code is even half way there, BTW.

regards
Michael

[Lakie]

EDIT: IIRC it was considered. But as stations are special in the way they handle their tile layouts and all other tile specs are more like houses and industries it was decided to not follow the stations special way to handle things. Leaving it to the NewGRF to decide on how foundations are drawn is the much more flexible approach. And as quoted above not more than 6 lines to get full slope awareness. In NFO a function to convert tile slope to offset might come in handy the same way but would be needed once and for all only, too.

Indeed, I remember discussing it with Rubidium a long time ago. I can't remember the reasons for why it was dropped but I think it was along the lines of being considered redundant, or not worth the hassle implementing considering the available functionality can already achieve it...

~ Lakie

[frosch]

Disclaimer: I am not sure whether the original question was about why there is only a flag and no callback to disable the default foundations, or whether it was about why there is no mechanism to draw simple or extended foundations like for stations. Anyway I am answering the latter.

This was not forgotton. This is just not possible.

Stations draw sprites by resolving the A123 chain, which then returns a spriteset. Stations can resolve the A123 multiple times to get spritesets for foundations, and up to eight (TTDP: two) spritesets for the sprite layout.

Houses, industries, objects and airports otoh do not return a spriteset in the A123 chain, but a sprite layout. Combing multiple sprite layouts is not exactly a sane thing, nor does it feel appropiate to solve the foundation case.
Originally this approach of drawing a single fixed sprite layout was quite tedious: If you needed variations in the sprite layouts, you needed a sprite layout for every combination (combinatorical explosion). To overcome this restriction we added advanced sprite layouts with register modifiers to OpenTTD. This allows to put different sprites into the same sprite layout and to combine independent decisions into one layout (i.e. no combinatorical explosion).

Are advanced sprite layouts with register modifiers too complex for this task? No, not at all! You just need to read the slope from the tile, mask some bits, put it into some register and reference it from the spritelayout. Then you can just put the foundations sprites into the Action1 in the order needed.

Independent whether someone is heading for simple or extended foundations (using the terms from stations), this should not be more than 4 pseudo sprites. Using var 7E procedure calls these even only have to appear once. The example in the original design document in fact does something similar: slope aware ground sprites.

[michael blunck]

[...] This was not forgotton. This is just not possible.

Stations draw sprites by resolving the A123 chain, which then returns a spriteset. Stations can resolve the A123 multiple times to get spritesets for foundations, and up to eight (TTDP: two) spritesets for the sprite layout.

Houses, industries, objects and airports otoh do not return a spriteset in the A123 chain, but a sprite layout.

Ah, thanks for clearing this up. Obviously, I´ve been irritated by the fact that newobjects (initially, in TTDPatch) had been based more on the stations concept than on houses or industry tiles.

regards
Michael

[Quast65]

As we need to develop a whole new spec/mechanism to give objects a layout and the time it takes for new specs to be properly tested I don't intend to do any work on this before 1.1 is branched, i.e. I won't push it into the 1.1 stable series.

Unfortunately real life interference prevented me from following up on this since OpenTTD 1.1 was branched.
Is this a good to time to revive the discussion around the potential for this feature? In a recent discussion, SAC was asking me about this feature, so a demand for it would seem to extend beyond myself and Michael Blunck:

The only "irregular layout" in TTD that I´m aware of is that of industries.

Maybe we could stick to that, resp borrow from it?

Any thoughts?

This would be a very useful feature for eyecandy stuff, so one more graphicsdeveloper can be added to the list of requestors