Sprite Limits (Other)

[SAC]

Done! See below;

[michael blunck]

According to the debug listing, there are "GRF conflicts" between a couple of ECS vector .grfs, hence they don´t get activated.

Maybe asking about that problem in George´s ECS thread would be appropriate?

regards
Michael

[wallyweb]

Done! See below;

Hi SAC. I see you have other industry files besides George's vectors. Try disabling all other industry tiles with a # before their lines in your newgrf.cfg.

Those ttdpatch.cfg.0001 etc. are ok. They are backups created by ttdpc. Simply delete them if they are a bother to you.

[SAC]

According to the debug listing, there are "GRF conflicts" between a couple of ECS vector .grfs, hence they don´t get activated.

Maybe asking about that problem in George´s ECS thread would be appropriate?

regards
Michael

The odd thing is that I have them listed in the same order as "wallyweb", and he seems to get them to work with no problems at all!

Done! See below;

Hi SAC. I see you have other industry files besides George's vectors. Try disabling all other industry tiles with a # before their lines in your newgrf.cfg.

Those ttdpatch.cfg.0001 etc. are ok. They are backups created by ttdpc. Simply delete them if they are a bother to you.

They are listed in my newgrf.cfg, but they are not activated in game. Even if I disable all other .grf's, I still cannot use more than those three mentioned; ECS Town, Basic & Machinery!

[wallyweb]

Done! See below;

Hi SAC. I see you have other industry files besides George's vectors. Try disabling all other industry tiles with a # before their lines in your newgrf.cfg.

They are listed in my newgrf.cfg, but they are not activated in game. Even if I disable all other .grf's, I still cannot use more than those three mentioned; ECS Town, Basic & Machinery!

They must be disabled such that they do not appear in the status window, even with a red flag.

[George]

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.

George tries his hands on industries, houses and RVs And my plan is to increase the number of sprites

[George]

i.e. not sprites of excessively long var2 chains (Hi, George ).

They are not long. I plan to make them longer
And they are documented with action C. I suppose it makes the code readable

[wallyweb]

George tries his hands on industries, houses and RVs And my plan is to increase the number of sprites

Hmm ... We seem to be out of rooms ... Do you have a reservation?

[George]

George tries his hands on industries, houses and RVs And my plan is to increase the number of sprites

Hmm ... We seem to be out of rooms ... Do you have a reservation?

According to the current speed - yes, about two years

[wallyweb]

According to the current speed - yes, about two years

Good ... One of our best engineers is already at work adding more rooms to the Hotel Sprite Blocks.

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

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

[eis_os]

Status report:
+ added experimental features switch
+ added the necessary fragment and relocations for sprite sorting
+ added a new AddGroundSprite, AddSprite

It's not possible to keep the spritelimit blocks of the old system for debugging the new code,
so before the code can be tested all necessary pieces (at least so vehicle grfs can be loaded) have to be finished.

Todos:
- AddLinked and AddRelative Sprites
- Drawing sortedsprites
- Vehicle Bounding Box Functions
- GRF Loading and activating (TTDPatch/TTD)
- Add tests so only real sprites can be drawn, this should avoid drawing random memory blocks
- Fix canals as sample for action based sprite drawing
- Find someone who fixes all other features.

After TTDPatch works again:
Go back to the sprite sorting routines and rewrite the GroundSprites to be normal Sprites and sort them

[michael blunck]

Status report [...]

Oskar, what´s the aim of your undertaking, in terms of future sprite limits?

regards
Michael

[eis_os]

The goal:
4900 Sprites of TTD without doing caching (swapin/swapout). The GRF is fully loaded into memory at once.
11k Other Sprites, (GRM ones, for recolouring and such tasks)
Action 1: 11k Sprites per individual GRF.

All Sprites in memory use the same layout -> GRF Author helper can edit every real sprite and only has one location.

This means that Action1 sprites aren't feature based any more but they are GRF local. A reason why the rewrite is so complicate, instead of tracking simply what feature a sprite has, the Action3 to GRF Spritelst pointer need to be tracked.
Currently TTD(Patch) caches additional the sprite header for sorting, because TTD sprites may not be loaded currently, this will be removed completely...

If you need more then 11k sprites you can split the grf. You can't have more then 11k action1 sprites currently per feature anyway, so I don't think that is much of a problem

Generally as TTD doesn't any caching any more after the rewrite, the GRF Memory could be allocated differently under Windows and changed at runtime. (But the Action system would need tweaks)

[SAC]

They must be disabled such that they do not appear in the status window, even with a red flag.

Hmm, tried that too, but to no avail! I'm wondering if it could be a patch setting of mine perhaps, because even if I load the station sets I'm using, I should be well below the maximum limits, so all in all there shouldn't be a problem.

I do not understand this!

[eis_os]

Only if miscmods.smallspritelimit would be enabled, can you please backup your ttdpatch.cfg and try a default one?

[michael blunck]

[...]
11k Other Sprites, (GRM ones, for recolouring and such tasks)
Action 1: 11k Sprites per individual GRF.
[...]

How about GRM in general? Unfortunately, this feature isn´t used much at the time being, yet it´s one of the most interesting and helpful one (see e.g. discussion on German tt-forums about .grf incompatibilities). ATM, I´m going to equip all my .grfs under development with GRM.

Now it seems, things will be changing with regards to GRM?

@Oskar
SAC´s miscmods and miscmods2 are both set to "off".

regards
Michael

[eis_os]

Sorry but I can't follow you. Since when do you allocate action1 sprites with GRM?
You only use GRM for sprite allocation if you need a sprite in the default TTD sprite space (non-feature based sprite, recolouring as example) => Action5. This will be the 11k sprites in the other block as before and will be allocated exactly as before. (From a GRF standpoint) Or what other use do you mean?

[michael blunck]

Sorry but I can't follow you. Since when do you allocate action1 sprites with GRM? [...]

Hehe, sorry. My fault.

regards
Michael

[wallyweb]

Hmm, tried that too, but to no avail! I'm wondering if it could be a patch setting of mine perhaps, because even if I load the station sets I'm using, I should be well below the maximum limits, so all in all there shouldn't be a problem.

I do not understand this!

Hi SAC,
I made and attached a newgrf.cfg from your debug file.
Open the file in your Notepad and follow the instructions at the top of the file.

[George]

How about GRM in general? Unfortunately, this feature isn´t used much at the time being,

I have 49 sprites but I plan to have much more