Important for set designers: please tell us how many sprites

[eis_os]

Hello


Because of an internal limit of 0xFFFF realsprites we need to rearrange the extended spritelimits otherwise TTDPatch will malfunction. And for George it won't be better if the spritelimit patch would have been written different.

So please tell me for each category (as in action0 ) how many realsprites you use or plan to use (best way with grf name and if it disables other sets)


The current plan is to place planes, ships and newhouses into one extended sprite block for the next alpha/betas...

[minime]

So please tell me for each category (as in action0 ) how many realsprites you use or plan to use (best way with grf name and if it disables other sets).

I'm afraid the for what I'm working on now, it's impossible to guess at this stage.

The current plan is to place planes, ships and newhouses into one extended sprite block for the next alpha/betas...

Could you possibly detail your plans fully? For example, if you combine those three features, what will happen with the IDs you have liberated?

Would this block be subdivided any further, or would those 3 features share the limit? For ships it shouldn't be much of a problem considering how few there are - GRF Status reports roughly 500 sprites there. Current planeset appears to use some 500 sprites too, but that one I can see growing a little more (I won't speak for the devs tho).

I'd be more concerned about buildings tho - there are 255 IDs allowed, 4 construction stages, all kinds of animation that can be done. I could certainly see a townset grow to a few thousand realsprites, but it would take a lot of time (and an inefficient coding method) to get to the point where it would reach the current limit.

Since you're considering combining several features together into one block, would it be feasible to combine all the sprites into one block of size 0xFFFF (or something along those lines), and as such eliminate the individual sprite limits?

[DaleStan]

For the PlaneSet, currently dev version has about 600, with probably around 300 liveried sprites waiting to be added.

[eis_os]

@minime

Please consinder reading the topic: http://www.tt-forums.net/viewtopic.php?t=12249 why there is a ~11000 limit of sprites and a limit of 65535, if you don't understand it please ask a other forum member maybe, I don't want to discuss it again why this and that happens. Please don't mix vehicle ids with spritelimit and maybe consinder I know what I do, atleast most times.

@all

So we can say that ships, planes and new houses use 1500 Sprites each.

The question is now what is with TTRS3

[michael blunck]

> we need to rearrange the extended spritelimits

What does that mean? A change of the existing 11xxx sprites number per class?

> So we can say that ships, planes and new houses use 1500 Sprites each.

Each, or in total? And no, why should anyone say such a thing?

Please give us more information about the things you´re going to change (and why).

regards
Michael

[Patchman]

> we need to rearrange the extended spritelimits

What does that mean? A change of the existing 11xxx sprites number per class?

We found that we're possibly allowing over 65535 active sprites at the moment, which is bad and possibly already breaking things.

Currently, that will happen if there are over ~3600 active newhouses sprites.

> So we can say that ships, planes and new houses use 1500 Sprites each.

Each, or in total? And no, why should anyone say such a thing?

We need to remap some of the "extended" ranges to stay within 65535 sprites. One (the easiest) possibility would be to limit newhouses to ~3600 sprites. Another would be to combine newships, newplanes and newhouses is some way so that we have either 11383 for them in one block, or ~14000 in two blocks.

Finally, the new font loading should really use an extended sprite limit too, so that should be taken into consideration with the above as well.

However, we need to know which feature would need how many sprites to set the block sizes.

[michael blunck]

> we need to know which feature would need how many sprites to set the block sizes

That´s not easy to tell beforehand.

Let´s start differently. For vehicles, there´s a strong link between sprite limit and vehicle ID limit: you don´t need to "spare" sprites if all veh-IDs have been already used up (i.e. normally there´s only one "big" train set active at a given time and the number of sprite variations is limited to a certain degree).

In principal, the same is true for all other vehicles (ships, planes and trucks/busses). OTOH, there are different numbers of IDs available for these vehicle classes, i.e. if there will be only 11 ship IDs in the future we´d clearly use less var sprites for them.

For buildings and industry tiles this is difficult to tell. From my opinion, these objects are using up a lot of sprites (e.g. for animations). As a consequence, I wouldn´t like to see them limited without a really serious reason, instead I´d say that we should allocate as much sprites as possible for them.

regards
Michael

[minime]

Please consinder reading the topic: http://www.tt-forums.net/viewtopic.php?t=12249 why there is a ~11000 limit of sprites and a limit of 65535

First of all, I haven't suggested raising nor questioned the 2^16-1 limit on total number of sprites.
Second of all, I've assumed that by the word "rearrange" in

Because of an internal limit of 0xFFFF realsprites we need to rearrange the extended spritelimits

you mean changing their relative sizes. Maybe I understood that wrong, but you could hardly say you were making your plans and intention as clear as possible, so please forgive me.
Third of all, that thread is over year old - I can hardly assume that information there is up to date, so I believe my questions were more than valid.

Please don't mix vehicle ids with spritelimit

So are you denying that if there are N possible building/vehicle/whatever IDs, each of which can have at least M sprites, you won't need at least N*M sprites?

In the case of buildings we have 255 different buildings and each can have at least 8 sprites (4 construction stages, ground + main sprite for each). That would make the minimum required 2040 sprites (in order correspond to the basic capabilities of the patch). However, now we have many more possibilities on how to vary the appearance of buildings, as well as the option to animate it, hence it would be possible to use even more sprites than that. I used 30 sprites for just one house to provide a lot of variety, and while I could reuse a lot of them for other buildings, it still has the potential to become a few thousand if you combine a few sets together.

---

In regards to what Patchman said:

That ~14000 option looks like a decent alternative. Would a scheme such as:

• 1/6 - ships
  1/6 - airplanes
  1/6 - glyphs
  1/2 - houses

work?

---

For buildings and industry tiles this is difficult to tell. From my opinion, these objects are using up a lot of sprites (e.g. for animations). As a consequence, I wouldn´t like to see them limited without a really serious reason, instead I´d say that we should allocate as much sprites as possible for them.

I absolutely agree.

Cheers,
minime

[Zimmlock]

I do not understand this but i know i can't make more than 255 houses, but lets assume i make 255 houses, and it are all 1 tile houses i would need 1530 sprites (6 sprites per house, 1 construction ground sprite, 1 finished building ground sprite, 3 construction stages and a finished building house sprite), and normaly i can draw for each construction site a ground tile to, if that would be the case i would need 2040 sprites.
A 2 tile house needs (with construction ground sprites) 16 sprites.
A 4 tile house needs (with construction ground sprites) 32 sprites
but i have many 2 and 4 tile houses ....
So just keep this in mind, i can live with the 255 limit but it would be a desaster to run out of sprites.
If the calculation is for all buildings from various GRF i would like to claim minimal 3000 sprites for houses.

[eis_os]

I didn't make any planes or fix to something. Neither was here a discussion about changeing vehicle ids, house ids or something. The simple problem is to devide the sprites in chunks for all features.

Again, how many sprites do you (as set designer) need. I don't want any discussion about vehicle station houses id. I want simple clear answers:

"Because I want to use all house ids I guess I need around 4000 sprites."
I know that trainsets and busses/trams need 11k sprites.


I never said you need to worry about internal details, I want simple answers nothing more

-edi-
If you say you need for the newhouses 6000 Sprites it's aswell ok, generally you should know how much you already have of your set finished. So it's shouldn't be a problem to make an assume how many sprites you will need.

[michael blunck]

Oskar,

> Again, how many sprites do you (as set designer) need.

As already mentioned, "That´s not easy to tell beforehand." Simply, because we didn´t yet build all the sets we want to build.

> I know that trainsets and busses/trams need 11k sprites.

Aha. From where do you know that? AFAIR, there are 116 veh-IDs for trains, 88 for road vehicles, 11 for ships, 41 for aircrafts, and 255 for buildings - so what?

11483/116 = 99 sprites per train vehicle
11483/88 = 130 sprites per road vehicle

> If you say you need for the newhouses 6000 Sprites

6000/255 = 23 sprites per building

Does this make sense for you?

regards
Michael

[minime]

I didn't make any planes or fix to something. Neither was here a discussion about changeing vehicle ids, house ids or something.

I don't remember saying anything about changing IDs. You're the one who keeps bringing that up.

The simple problem is to devide the sprites in chunks for all features.

Yes, the problem is to make an informed decision, which you don't seem to want to let me (or others) do. Considering there are some tradeoffs we have to consider, I think it is important to base this on more than just the current spritecount, and both Michael and Zimmlock seem to have the same opinion.

The 6k sprites is much more reasonable limit BTW, but as michael pointed out, there's still some disproportion.

[eis_os]

> I know that trainsets and busses/trams need 11k sprites.

Aha. From where do you know that? AFAIR, there are 116 veh-IDs for trains, 88 for road vehicles, 11 for ships, 41 for aircrafts, and 255 for buildings - so what?

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


What is the problem in saying something like this:
If you say your buildings would need 20 sprites each and that we have 255 ids (255*20 = 5100 sprites) so I assume 6500 would be enough.

And sorry Michael, I don't believe you that you have no idea how much a house in newhouses will need


I am somehow disappointed, if you really have no idea, we simple make it 3200 sprites large so it fits and TTDPatch works again.

[michael blunck]

> What is the problem in saying something like this: [...] I assume 6500 would be enough.

Well, the real problem is that you´ll make that number fixed then.

> Michael, I don't believe you that you have no idea how much a house in newhouses will need

AFAIK, the number of sprites isn´t fixed, i.e. there´s no pre-defined number of sprites for "a" house. I do have indeed some buildings with a large number of sprites, but o/c that´s not the case with all my buildings.

> George who already explained that 11k sprites are to less [...]

Well, it should go without saying that even 65535 sprites would be too low a number for his longvehicles sets in the long run.

regards
Michael

[eis_os]

Ok I guess there will be no answer. You have to live with the result of the bug fixing an rearrange.

*closed*

[Patchman]

Well, since there's no easy way to figure this out, maybe the best interim solution would be to allocation a third of the sprites in question to each feature.

So we have 26180 sprites, that means 8725 each for newships, newplanes and newhouses. That will have to suffice, I hope.

[minime]

Well, I was trying to say "do it in a way proportionate to the number of IDs available for each feature".

So something like:
1024 IDs for newships (that's ~93 sprites/ship ID)
4096 IDs for newplanes (roughly 100 sprites/plane ID).
Whatever is the reasonable maximum for houses, 11483 if that's the limit that can't be breached without too much effort (some 45 sprites/building ID in this case).
Whatever is a reasonable number for glyphs, 1024 or 2048 would probably be more than enough.

Reserve the rest for future additions, in order to avoid having to shuffle it around yet again.

Does that sound like a reasonable allotment? Is it feasible to do?

I don't see the reason for this whole scene here, if I've said something inappropriate I appologize. I was only trying to make a decision that I could somehow support and not pull numbers out of a hat.

[Patchman]

There's no need for leaving room for the future, since in the future we can just reshuffle the blocks again as needed. Or maybe by then the limit will have disappeared entirely.

However, allocating by number of IDs is probably not the best. Ships have few IDs but need many sprites, because they show loading states and different cargos. Planes don't need to show loading states (except maybe for the few cargo planes), so they need fewer sprites.

I have now set it to 8725 for each of those three features. For ships and planes it's only 25% less, and for houses it's 140% more, so everyone should be happy I hope

If not, we can always change it...

[DaleStan]

Please consinder reading the topic: http://www.tt-forums.net/viewtopic.php?t=12249 why there is a ~11000 limit of sprites and a limit of 65535,

I understand the 11k/feature limit[0], and the 65535 limit is at least at a nice round number, but since you're already remapping the sprite numbers I don't really understand why you can't just allocate another 11k block, and point $NEW_FEATURE at that 11k block instead of one of the current blocks, but I'll trust that you and Patchman know what you're talking about.

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. The Chinook, in its CC&OL form, will require 200, and the two 747s will require about 120 each, and similar sprite-reduction could be applied to these three too. Those are far and away the most massive planes, though. The a380 and the Ruslan may end up similarly sized to the 747s, but most of the other planes will be quite content with 16 to 32 sprites.
Due to the general lack of cargo-based and loading-based liveries, I don't see the Planeset exceeding, or even reaching, 3000 sprites until/unless the 41 ID limit gets raised. I can easily see it exceeding 1500, though. If people draw enough OL sprites, that is.

[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.

[Patchman]

I understand the 11k/feature limit[0], and the 65535 limit is at least at a nice round number, but since you're already remapping the sprite numbers I don't really understand why you can't just allocate another 11k block, and point $NEW_FEATURE at that 11k block instead of one of the current blocks, but I'll trust that you and Patchman know what you're talking about.

The total number of all active sprites must not exceed 65535 (ATM, until someone fixes that too). That's 5.3 extended blocks, and we have 6 already. So some of them need to reduced. If we add another block, the rest have to be reduced even more...