Sprite Limits (Other)

[wallyweb]

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

I just verified the numbers and they are accurate. Let's see ... It does contain a parameter for setting seasonally varying snow levels for the game; there are four types of fences for the game, also available by parameter; the platforms are animated similar to yours, for varying passenger levels, and Gare Centrale is a minimum 4 x 4, plus extensions. Gare Centrale's parking lot covers the platforms and is animated, showing varying quantities of cars.

[michael blunck]

Let's see ... [...]

Regardless of its content, a lean station set would not contain any redundant sprites. Obviously, the CanSet isn´t a lean set, it contains lots of redundant sprites.

I.e.

Code: Select all

grfcodec -d canstnw.grf

and have a look into cansetw.pcx yourself.


Good thing it´s not George´s ECS vectors ...

regards
Michael

[eis_os]

It's easier to code (tm)

[wallyweb]

Let's see ... [...]

Regardless of its content, a lean station set would not contain any redundant sprites. Obviously, the CanSet isn´t a lean set, it contains lots of redundant sprites.

I.e.

Code: Select all

grfcodec -d canstnw.grf

and have a look into cansetw.pcx yourself.

Unfortunately I'm not grfcodec friendly so I must take your word for it. My take on the conversation so far is that it would appear that "stations" would benefit the most by having their own feature as it seems to be the one that players such as myself are most apt to be overly compulsive in including multiple sets in our grf configurations.

Good thing it´s not George´s ECS vectors ...

Yes ... good thing indeed ...

[michael blunck]

[...] Obviously, the Canadian Station Set isn´t a lean set, it contains lots of redundant sprites.

Unfortunately I'm not grfcodec friendly so I must take your word for it.

Well, let´s have a go with one of the first real sprites in the Canadian Station Set, say #103. Now, this sprites isn´t included one or two times, which would be sufficient for normal usage. No, possibly because of security reasons , it has been included 72 times! And that´s no single occurence. There are lots and lots of other redundant sprites. IMO, this is poor programming style.

My take on the conversation so far is that it would appear that "stations" would benefit the most by having their own feature as it seems to be the one that players such as myself are most apt to be overly compulsive in including multiple sets in our grf configurations.

Well. As Oskar already pointed out a couple of times, at the moment, there´s a hard limit on the number of real sprites. And then, there will always be an even lower limit on sprites of a certain category, whatever we try to organize them.

So what can be done? We need to code grfs in a tight manner, and we shouldn´t acquire every .grf from the net. We just had that discussion next door (in the German tt-forums) where many people are using the OpenTTDCoop#-Pack with its 46 MB data, indiscriminately. And o/c there´s no day on earth that someone doesn´t create a "new" .grf to add to the heap ...

regards
Michael

[wallyweb]

... CanSet ...

Well, obviously I'm not qualified to get into programming styles, but just to be sure, you are referring to canstnw.grf, the Canadian Station Set and not the Canadian Train set?

Well. As Oskar already pointed out a couple of times, at the moment, there´s a hard limit on the number of real sprites. And then, there will always be an even lower limit on sprites of a certain category, whatever we try to organize them.

This I understand. The only way to accommodate the proposal for a unique "Stations" block is to rob Peter (Objects) to pay Paul (Stations).

So what can be done? We need to code grfs in a tight manner,

This goes to a coder's style. Hmmm ... Perhaps you could write a tutorial on efficient shortcuts to grf coding.

and we shouldn´t acquire every .grf from the net. We just had that discussion next door (in the German tt-forums) where many people are using the OpenTTDCoop#-Pack with its 46 MB data, indiscriminately. And o/c there´s no day on earth that someone doesn´t create a "new" .grf to add to the heap ...

Well, I must admit that I do try to acquire every .grf from the net, even yours. However, I consider them to be my pallet, if you will, from which I select some appropriate vintages to accommodate my game of the day, which is set out in a very limited daily newgrf.cfg menu. The "#" is very handy for this.

[michael blunck]

... CanSet ...

[...] just to be sure, you are referring to canstnw.grf, the Canadian Station Set and not the Canadian Train set?

Yes, sorry. The Canadian Station Set. I´ve corrected my post above.

Thanks for your further reflections on the theme.

regards
Michael

[wallyweb]

Thanks for your further reflections on the theme.

Not at all ... I thank you for your input to the discussion. It has certainly helped to lend focus to the direction.

By the way, my remark about using "#" ... I think I may have missed a very good pun ... A "#" cheese is very good with this.

[michael blunck]

[...]
By the way, my remark about using "#" ... I think I may have missed a very good pun ... A "#" cheese is very good with this.

Apropos cheese, did I tell you about my last weekend´s Barolo? A Castiglione Tinella, quite old and perfectly matured. A very complex wine, an unbelievable experience for the sense of taste. Unfortunately (again), it was the last bottle ...

regards
Michael

[wallyweb]

Unfortunately (again), it was the last bottle ...

You shall have to go down to the store for more.

[eis_os]

I already created a local branch to write down some ideas for grf specific sprite blocks, I hope I can add some Compiler defines to enable/disable this and commit the stuff to trunk..

[SAC]

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 )

sprite_limits.png

Hmm, I've obviously not seen this topic before, but it's interesting! Especially the fact that I can tell you're able to load all the ECS vectors while I can't. Only like three of them, and your "Other Sprite Category" takes up more than 11000 sprites, while mine only uses 4000? How come? Is this a setting I need to adjust with the patch, or is there something else I need to do? I can't even use MB's NewStations and IndustrialRenewal at the same time, thus forcing me to make some mixing and matching using other stations sets out there. I've attached my own Graphics Status below as an example!

As for the New Objects feature, will that affect the "Other Category" for sprites as well? And while at the subject, what determines the "number" of sprites? Is the actual sprite itself, or does the size of a sprite have a signficant meaning here as well?

[eis_os]

For ECS start from scratch...
We talk about Sprite IDs (of activated real sprites)
All non specific ones (houses, vehicles) of TTDPatch GRFs go into the "other" block.
One block can only have 11483 sprites at max.
You can't have more then 65535 real sprites (reduced by 4900 TTD sprites, some gaps between sprite spaces I never fixed).


Status report:
+ removed most caching function with a generic fetchsprite function
+ started to write a new grf loader (for TTD sprites)
+ find some import structures for sprite sorting
+ raw new DrawSprite function

Still to fix:
Sprite Sorting routines
Vehicle Bounding Box Functions
...
Add old Spritelimit functions for testing again

[wallyweb]

You can't have more then 65535 real sprites (reduced by 4900 TTD sprites, some gaps between sprite spaces I never fixed).

SAC's GRF Status window shows that she has "Total number of sprites: 70966".
Does the 65535 maximum apply to this field (In which case she exceeds the limit)?
Or does it apply to her "Active sprites : 16578" field (In which case she has not reached the limit)?

[michael blunck]

SAC's GRF Status window shows that she has "Total number of sprites: 70966".
Does the 65535 maximum apply to this field (In which case she exceeds the limit)?
Or does it apply to her "Active sprites : 16578" field (In which case she has not reached the limit)?

The latter. "Active sprites" means activated real sprites, i.e. not sprites of excessively long var2 chains (Hi, George ).

regards
Michael

[wallyweb]

SAC's GRF Status window shows that she has "Total number of sprites: 70966".
Does the 65535 maximum apply to this field (In which case she exceeds the limit)?
Or does it apply to her "Active sprites : 16578" field (In which case she has not reached the limit)?

The latter. "Active sprites" means activated real sprites, i.e. not sprites of excessively long var2 chains (Hi, George ).

regards
Michael

So what is preventing SAC from loading more active sprites in the "Other" category?
i.e. Are sprites of excessively long var2 chains (Hi, George ) affecting this in some way?

[michael blunck]

So what is preventing SAC from loading more active sprites in the "Other" category?

I don´t know. We would need more information on this to get an idea.

i.e. Are sprites of excessively long var2 chains (Hi, George ) affecting this in some way?

I don´t think so.

regards
Michael

[wallyweb]

So what is preventing SAC from loading more active sprites in the "Other" category?

I don´t know. We would need more information on this to get an idea.

i.e. Are sprites of excessively long var2 chains (Hi, George ) affecting this in some way?

I don´t think so.

regards
Michael

Thanks Michael.

@SAC - Check the order of grf's listed in your newgrf.cfg file. Make sure that George's ECS Vectors are listed after ttdpbasew.grf AND before all other grf's.

[SAC]

Hmm, still doesn't work. Even if I turn off ALL other .grf's I'm using, I'm still only able to load ECS Town, ECS Basic, and ECS Machinery! Adding those other ECS .grf's gives me those nasty yellow flags! And I've put them in the exact same order as you Wally, with the TTDPBasic on top!

I'm a bit puzzled when it comes to your ability to load Canadian Stations, (with that large number of sprites) along with IndustrialStationsRenewal as I can't even load MB's NewStations and IndustrialStationsRenewal and to those add my 3 testfiles, (BlankTiles), each of them providing 108 sprites...? Odd indeed! Something is wrong!

I've attached some files to this post in case someone should find time to have a look! On another note, noticed I have like 4 other ttdpatch.cfg in my folder, labeled cfg.0001, cfg.0002, cfg.0003, and cfg.0004! Am I supposed to have that?

[eis_os]

Click on "Debug" and post the grfdebug.txt too so we can see the error messages...