OpenGFX - Graphics Base Set

[Bus]

Oh yes I understand all that, I was just referring to

the 2 remaining signal types are reserved for future developments (e.g. advance signals)

which is apparently not true because toyland uses them. But anyway thank you guys for clearing up some things for me.

[planetmaker]

Oh yes I understand all that, I was just referring to

the 2 remaining signal types are reserved for future developments (e.g. advance signals)

which is apparently not true because toyland uses them. But anyway thank you guys for clearing up some things for me.

Eddi is right and you seem to fall for a (common) mis-understanding which is easy if one is not aquainted with how the internals work:

Toyland uses alternative graphics for the usual signal types (as it also does use alternative graphics for a number of other things). That doesn't change the fact that there are - in all climates - two signals types still available. But they have as of now no meaning and are not yet supported. That is anywhere except in some prospective patches, like weak path reservations or alike.

[Bus]

I have to admit that I don't really know much abut opengfx but where exactly are these toyland graphics stored? I certainly didn't see them in ogfxe_extra (except for those two slots which we're talking about) and ogfxt_toyland should only contain the original TTD graphics right? (Meaning no PB signals.)

[FooBar]

OpenGFX supports different signals in toyland, but currently the PBS signals are exactly the same as the ones in the other climates. Only the normal block signals have slightly different graphics in toyland. These particular block signals are in ogfxt_toyland. The pbs signals are in ogfxe_extra.

[Ammler]

BTW: signals are one of the most important missing things for next release....
(http://dev.openttdcoop.org/issues/280)

[Bus]

Well that's what I'm talking about -- toyland DOES use different graphics for PB signals, the ones stored in the supposedly unused slots. (Only electric ones though.) Just start a new toyland game and build an electric PB signal. It will have a purple pole.

[Lord Aro]

What about toyland airports?

[planetmaker]

What about toyland airports?

Good idea. I'll happily implement them as soon as I do have the sprites.

Well that's what I'm talking about -- toyland DOES use different graphics for PB signals, the ones stored in the supposedly unused slots. (Only electric ones though.) Just start a new toyland game and build an electric PB signal. It will have a purple pole.

Hm... that *MIGHT* be a bug of the wrong palette being used.

[FooBar]

I had another look and it turns out that the poles are actually drawn purple: http://dev.openttdcoop.org/projects/ope ... ls_pbs.pcx

Regardless of pole colour, those signals have exactly the same functionality as their counterparts in the other climates. Difference in graphics and difference in signal slot are not necessarily the same thing.

[ChillCore]

I have noticed a small alignment glitch with the soccerfield.
See attachement: Notice the white line underneath it which is leftover pixels from the querry tool.

Tested with OpenTTD r20164 and OpenGFX r466.

[Ammler]

Quite a shame, we didn't notice that yet, as this is partially in the last release already. I fixed it with r467, please review and if it still fails, feel free to reopen #1107.

Many thanks for this report.

Edit: nightly: http://bundles.openttdcoop.org/opengfx/ ... es/LATEST/

-Ammler

[ChillCore]

Sorry for the delay. I was busy with RL.
#1107 will not need re-opening. Thank you for the quick fix.

Many thanks for this report.

No problem. It is all about making my/your/our OpenTTD experience better.
We should be thanking YOU(and everybody involved) for maintaining and improving this massive set.


I found a few more. See attachment.
Notes:
-These sprites were taken from the scenario editor, year 1950.
-Not all "shops & offices" sprites are misaligned.

[Ammler]

It would be very helpful, if you use the NewGRF Developer Tools and then the Sprite Aligner, with that tool, you could tell us the Sprite Number of the houses. You like to try?

Eventually, you can already tell us the current offsets and how those should be...

Greets and Thanks
Ammler

[ChillCore]

Sprite Aligner ... thank you for reminding me.
Although wiki suggests to enable it through the console I prefer to enable it in the config file.

Please find attached corrected offsets.
I assume construction stages need to be corrected also. Do you need spritenumbers for those also?
Grey underlay tile is drawn correctly.

note:
Currently is r467

[Ammler]

Yeah, those houses use sprite width 66 instead 64, and that needs other offset (32 instead 31), with using grfcodec -c, this all get worse. You have quite some other numbers in your SpriteAligner screens than I have.

Please check again today nightly, I have changed all offsets to 32 with r468, what you think?

Greets
Ammler

[ChillCore]

You have quite some other numbers in your SpriteAligner screens than I have.

If you mean sprite numbers, please ignore.
It is what happens if you have the querry or bomb tool enabled while selecting a sprite or when clicking too high on a sprite so the tile behind is selected also. (All sprites under the mouse pointer are selected.)

Please check again today nightly, I have changed all offsets to 32 with r468, what you think?

Computer says no ... sorry.

(Although there is some improvement in the right direction compared to r467.)

I have made a new fresh install. Windows binary, openttd.cfg near the .exe and only OpenGFXr 468 in the data folder to make sure no other sprites can influence.
Please see attachments. I hope it is more clear now ...

Regards
ChillCore

[Ammler]

Problem is spotted, those houses use a "non-default" bounding box:

evil_boundingbox.png (18.16 KiB) Viewed 2489 times

So now the question, how to find those and is there any formula for the offsets?

Greets
Ammler

[ChillCore]

evil_boundingbox.png

You mean these evil boundingboxes?

Now the Questions with capital Q are:
How badly do we want to keep backward compatibility with the original sprites?
Is OpenTTD to be tuned to the graphics or are the graphics to be tuned to the sizes they were in TTD?

ps:
I have not adjusted the boundingboxes for the other sprites that were corrected in r468 nor have I checked them yet ...
Und yes, the corresponding original sprites will move a bit with the patch applied but they do not leave the tile.

[Ammler]

wait, wait

I didn't mean, you should change the OpenTTD source, I was just wondering, if it is possible to see in the source, which houses do have a non-standard bounding box, so when we adjust those houses, we don't forget one.

It isn't worst, if we can't use templates for some houses. We just should be sure, which houses that are. Your diff at least helps me searching in the right place...

Greets
Ammler

[maquinista]

OpenTTD should accept custom bounding boxes for default sprites.