Important for set designers: please tell us how many sprites

[minime]

[0] minime: sprite IDs stored in a word, high two bits reserved for marking transparency/recoloring (IIRC), leaving 16384. Then each feature must have access to all ~5000 TTD sprites, leaving ~11k for GRF-defined sprites.

Cheers. I've figured it out, I just didn't see the topic at first.

[OzTrans]

Here are some details ...

Canadian Trainset (CanSetw.grf)

. this set operates stand alone, no other train sets should be active. Other sets are not checked/deactivated; it is up to the player to only have the CanSet active.

. v0.2 has about 6200 sprites of which 3800 are active, estimated active sprites for v0.3 about 8000 and the way DanMacK is going could easily reach 10,000 once complete.

Canadian Stationset (CanStnw.grf)

. this is not a stand alone set, other sets can operate side by side.
. v0.1 has about 500 sprites of which 260 are active, estimated active sprites once complete about 1000+.

Norwegian Trainset (NsbSetw.grf)

. this is not a stand alone set either, other sets can operate side by side with limits.
. v0.4 has about 1800 sprites of which 920 are active, estimated active sprites once complete about 3000.

[George]

George who already explained that 11k sprites are to less for each cargo. He already calculated some number, can't find it currently here.

http://www.tt-forums.net/viewtopic.php? ... mit#387094

[eis_os]

In the Planeset, the Osprey requires 120 sprites, and I could drop that by at least 15 by cheating the some of the never-used sprites into "-1*1 00"s. But I know what Oskar thinks of that.

They count as active sprites because they are handled like this. And TTD will crash when it tries to display it. So you can't cheat this way.

There was a side discussion about the language file and grfauthor helper.
I have some ideas for a new system after stable which will remain to 11k blocks but more then 5.2 blocks total and reduce one layer and access the memory directly. (This can be slower or faster, currently I have no idea)
Aka faked spriteid to sprite pointer instead of faked to real sprite to pointer as we use it now. However as I said, I have no idea if it would have any perfomance impact. Atleast you can count that some alphas won't be useable because of Sprite problems after such a dramatical change. A other idea atleast for completly new features (say newroutes) is to use a new DrawSprite/AddSprite system to have more faked ids to pointers, however Josefs action system can only handle 0xFFFF sprites aswell!

I do think with my easier layout that I have in my mind to even recycle places currently not useable. Faked sprite id could use some sprites from under baseoursprites (<4900). Atleast vehicles. I think some extra 1000 sprites for busses would make George very happy. Btw. thanks for your mail.

If you need to know more about how TTDPatch stores currently the sprite blocks you can look at my site under other. If you need even more insight, a73 should have a much more readable spritelimit assembler file.