Sprite Limits (Other)

[wallyweb]

It might be time to increase the sprite limit for the "Other" category.
Is this even possible?
The current limit is 11483. As you can see from the attached image, I am already at 11472, and I haven't loaded thgergo's bridges yet, not to mention some other interesting files.
The sprite hog in this case is obviously George's ECS Industries, and I suppose I could turn off some of his vectors, but this would defeat some interesting potential for game play.
Perhaps we could ask George to use fewer sprites, but this would defeat some very interesting graphical effects.
Also, with recent advances in the work on newobjects, we can expect even more pressure on this sprite limit.
(Note to OpenTTD players: I realize that this may not be an issue with OTTD, but I am a TTDPatch player, so unless sprite limits are an OTTD issue as well, please keep replies to this thread to TTDPatch )

"Other" Sprite Limit

sprite_limits.png (6.42 KiB) Viewed 7636 times

[eis_os]

A feature can only have 16383-4900 extra sprites, and we can load no more then 64k sprites concurrently. Without a internal rewrite to use pointers everywhere and a complete rewrite of features like bridges the answer is no for TTDPatch in the near future.

[wallyweb]

Thanks Oskar. I was afraid of that.
What about a redistribution to allow the creation of another feature?
Currently we have:
Trains: 11483
Road Vehicles: 11483
Ships: 8724
Planes: 8724
Houses: 8724
Others: 11483

The ones in bold seem to be underused. Perhaps they could be reduced so as to accommodate a new feature, perhaps "Industries", or "Stations" or something similar? Is this possible?

[eis_os]

Generally yes, but the relevant action code for these have to be tested in a way drawing works correctly...
(Note, Houses, Industries and Objects share the same extra space by design as the drawing code is shared,
so you would need to ask Lakie if he tests processtileaction2 so it works correctly, the relevant code already is partly in...)

PS: Ohh, and what feature would you like to cut sprites from? George happily fills the full road vehicle count...

[wallyweb]

PS: Ohh, and what feature would you like to cut sprites from? George happily fills the full road vehicle count...

True ... We would just have to make sure that George does not try his hand at Ships, Planes and Houses. Also, if it were possible to create a separate "Industies" or "Stations" feature, then "Others" could probably be reduced as well.

[Lakie]

As I understand Csaboka's code, he does not check if proctileaction2 fails from the functions he calls it, I merely replicated similar code for it following his examples of its use.
However I do realise now that I forgot to add a check that it actually found the action2 when rewriting the function in a neater form. I shall commit this after checking for any more mistakes

[Edit] If you mean does it fetch and load the sprites into game correctly, then yes that does work.
Also that jump may as well be irrelevant as you need the an action2 for a tile otherwise the grf wouldn't be loadable or the objects usable.

~ Lakie

[eis_os]

I still have the idea of grf local spriteids, so no hurry! UpdateVehBox is quite a problem however as TTDPatch doesn't know the grf anymore...

[michael blunck]

What about a redistribution [...]

As long as sprite numbers are static, all sprite pools will be easily exhausted. Redistributing their limits because some seem to be "underused" doesn´t make sense at all. Those numbers have been agreed upon after hard struggles and have to remain, at least to support coders with long-running projects. Besides from this, the number of available sprite IDs for ships, planes and houses had already been reduced in the past. However, there´s no real reason to do so. Only because TTD is centered on trains and there are more train-IDs than plane or ship-IDs, trains were allocated more sprites than some of the other object classes. OTOH, I have a (still unreleased) NewHouses .grf with >10,000 sprites, and there´s even a NewShipsXL in the works with a much larger sprite number than the old one, due to being able to get more ship models into 11 veh-IDs today, due to novel CB36 properties.

Simply because each pool size can be exhausted, they will get exhausted. Except by restrained usage as long as there´s a static sprite limit.

There´s no need to include every .grf available in every game.

regards
Michael

[wallyweb]

There´s no need to include every .grf available in every game.

True, and I certainly don't, but with a representative selection from each group, I am still running into those accursed yellow flags. usually when I try to use George's ECS Vector Industries, which is really too bad as they do, as I previously mentioned, offer some interesting features.

NewHouses .grf with >10,000 sprites, and there´s even a NewShipsXL in the works

Intriguing ...

[michael blunck]

[...] I am still running into those accursed yellow flags. usually when I try to use George's ECS Vector Industries, which is really too bad [...]

Maybe it would be possible to have separate sprite pools for all major features: trains, rvs, ships, planes, stations, houses, industry tiles. In this way, e.g. George would get separate pools for his ECS vectors and the LVs, rather than having to coexist with houses and stations, or with trams.

O/c, this wouldn´t add more space for sprites in total, but yield a better communication between sets and coders, and a better understanding for the public.

regards
Michael

[eis_os]

Maybe it would be possible to have separate sprite pools for all major features: trains, rvs, ships, planes, stations, houses, industry tiles. In this way, e.g. George would get separate pools for his ECS vectors and the LVs, rather than having to coexist with houses and stations, or with trams.

We do, still there is currently a hard limit of 0xFFFF loadable sprite ids, Actions can't store more, TTD doesn't, TTDPatch either...

Please check:
http://svn.ttdpatch.net/trac/browser/tr ... rlimit.asm

And see here:
http://www.bytetransfer.de/projects/ttd ... epatch.png

The only option left is to rewrite TTD(Patch) at certain places to directly access the sprites in the grf.
The current concept: We hook all access to feature based sprite ids and convert them to real sprite ids (16bit).Then the following code checks various stuff like Sprite Size, Relative X Y to successfully change Bounding Boxes or do sprite sorting...

A new concept: Instead converting them, we find the relevant code accessing informations on sprites, rewrite them to find the relevant grf specific sprite stream (this is on some places very hard, TTD caches sprite ids so the grf is lost*) and access this Data directly. Narrow down the possible sprite sorting room to fit the current grf pointer too.

* We can't simply store a pointer in an id field as we only have 16bits and TTD alters sprite number to change directions...

----
I simply have no time to fix all bugs when I would change TTDPatch in that way and doing a branch wouldn't solve that problem either as people couldn't test it and report bugs. As the change is bigger then the last we can't do it as Patch Switch without having a huge performance penalty.

[michael blunck]

I understand that increasing the sprite limit above FFFF seems to be a major undertaking. However, from one of your links above, it can be seen that meanwhile too many sprites are allocated to "other", especially "stations" and "industry tiles" seem to be ever growing sprites classes.

44 vard exsfeaturemaxspritesperblock
45 dd EXTBASE_TRAINS+EXTCOUNT_TRAINS // 0 trains
46 dd EXTBASE_RVS+ EXTCOUNT_RVS // 1 road
47 dd EXTBASE_SHIPS+ EXTCOUNT_SHIPS // 2 ships
48 dd EXTBASE_PLANES+EXTCOUNT_PLANES // 3 planes
49 dd EXTBASE_OTHER+ EXTCOUNT_OTHER // 4 stations
50 dd EXTBASE_OTHER+ EXTCOUNT_OTHER // 5 canals
51 dd EXTBASE_OTHER+ EXTCOUNT_OTHER // 6 bridges (unused)
52 dd EXTBASE_HOUSES+EXTCOUNT_HOUSES // 7 newhouses
53 dd 0 // 8 specialvars
54 dd EXTBASE_OTHER+ EXTCOUNT_OTHER // 9 industry tiles
55 dd EXTBASE_OTHER+ EXTCOUNT_OTHER // 10 industries
56 dd EXTBASE_OTHER+ EXTCOUNT_OTHER // 11 cargoes
57 dd 0 // 12 sounds
58 dd EXTBASE_OTHER+ EXTCOUNT_OTHER // 13 airports
59 dd EXTBASE_OTHER+ EXTCOUNT_OTHER // 14 signals
60 dd EXTBASE_OTHER+ EXTCOUNT_OTHER // 15 objects
61 checkfeaturesize exsfeaturemaxspritesperblock, 4
62 endvar

regards
Michael

[eis_os]

Well, as I said, what other category do you want to kill/merge for it? There is no more room in the 0xFFFF range, so you can only merge other categories to create new blocks

Simple rules:

• One block can only have 11483 sprites at max.
• You can't have more then 65535 sprites (reduced by 4900 TTD sprites, some gaps between sprite spaces I never fixed).

If I remember correctly ~15 sprites aren't used, so we have around 65520 sprite ids used by all Blocks...

[wallyweb]

I am admittedly a neophyte, but that table raises some questions:

1. Because a feature exists in the table, does that mean that feature has to have a sprite limit assigned to it?
[Depending upon the answer to that question, the next questions may be moot]
2. Why is "6 bridges" marked as unused? If it is indeed unused, Can this feature be renamed?
3. Why is it that " 8 specialvars" and "12 sounds" seem to be without variables? Can each of these be renamed and assigned variables?

44 vard exsfeaturemaxspritesperblock
51 dd EXTBASE_OTHER+ EXTCOUNT_OTHER // 6 bridges (unused)
53 dd 0 // 8 specialvars
57 dd 0 // 12 sounds

[eis_os]

It's a table that maps grf features to sprite blocks.
TTDPatch doesn't use Action1 sprites for bridges... You can't rename a feature. You can only assign features certain blocks.
A feature that will never allow action1 sprites can be simply zero, you could as well use the "Other" block.

-edit-
The "other" block is special in the sense that is the normal block that TTDPatch will use for GRM too as it follows linear the TTD sprites, if the Feature specific drawing code in TTDPatch doesn't know how to use the extended sprite limit right, it will work still because featurebasedspriteid = realspriteid

[michael blunck]

Well, as I said, what other category do you want to kill/merge for it? [...]

None of them. Simply because pruning away 1000 sprites from rvs, ships and planes each would be a moot undertaking because by the next ECS version they´re all be eaten up again.

@Wally

I see from your list above that you have assembled quite a couple of .grfs in your list. Could you please find out which of those are heavily using category "other"? I presume that George´s ECS vectors will use its 11483 sprites nearly exclusively, but I just want to be sure.

regards
Michael

[wallyweb]

I see from your list above that you have assembled quite a couple of .grfs in your list. Could you please find out which of those are heavily using category "other"? I presume that George´s ECS vectors will use its 11483 sprites nearly exclusively, but I just want to be sure.

ttdbasew.grf uses 1187.
Canadian Station Set and Industrial Station Renewal Set are the other heavy users in the OTHER category.
I do have several others in the OTHER category, but taken all together, they total to less than either of the station sets or George's ECS Vectors.
Actually, George's ECS Vectors are not that high when loaded alone. However, adding the stations to them pretty well uses up the limit, leaving little room for anything else.

[michael blunck]

Canadian Station Set and Industrial Station Renewal Set are the other heavy users in the OTHER category. [...]

How many sprites are they using?

regards
Michael

[wallyweb]

How many sprites are they using?

ttdbasew = 1187
all ECS Vectors 2986 - 1187 = 1789
Canadian Stations 6427 - 1187 = 5230
Industrial Stations 3487 - 1187 = 2300

[michael blunck]

Canadian Stations 6427 - 1187 = 5230

That´s a lot. Smells like a massive amount of redundant sprites. (Even my working copy of NewStations XL has only about 1300 sprites.)

I´ll have a look.

regards
Michael