OzTransLtd wrote:eis_os wrote:GRF Local sprite range: You will get them via grm, a grf local spritenumber will be returned ...
Good …
Dealing with action-As : normally, I request a single 'find' (and if successful, a 'reserve') for all sprites stored in all action-As. If I can, I'll use only one action-A in a GRF (bridges being the exception). With bridges, the contiguous sprite range reserved is carved up, so that I can use action-7s to store same size blocks depending on player choices somewhere within the reserved space. There are 4 blocks, one each for normal rail, monorail and maglev, as well as one for road bridges. Sprite blocks (which are normal and narrow gauge rail, as well as 'brick' or 'bitumen' bridge decks) will then be stored in one of the blocks depending on parameters current at game start. This approach works very well and should serve me just as well with grf local sprite blocks.
That should work, as said, you should get actually a sprite number local from your grf or if old code is used an ActionA in TTD sprite number space.
OzTransLtd wrote:
The following is a sample with 2 action-1s for one vehicle ...
That is a good sample how I deal with multiple action-1s for the same feature and I use this approach with all features.
Ok, that helps me a bit.
OzTransLtd wrote:
… the best way would be to some commented nfo dumps from your station grfs via email so I can see what you did and what you want to do ...
I only have a source (.SRC) and an undocumented output (.NFO). I'll see what I can do, give me a few days.
SRC? Anyway, I think I know roughly what you do, I will come back to your offer later if something in my code doesn't work
OzTransLtd wrote:
To sum it up. I understand what you are proposing as follows and it should not have a material impact on my already coded GRFs :
= I decide to use GRF local sprites.
Yes, the format how to support them with stations is still in flux as a new station drawing code may be necessary. For stations this could mean:
You can use Action1, Action A and TTD sprites, or you can use Action 1, X (GRF Local Sprites) and TTD sprites.
OzTransLtd wrote:
= I can use any number of Action-As; together with GRM to get an offset, which I add to the action-A sprite via an action-6.
= To address individual sprites in an action-A, I use the relative position (and adding the via GRM received offset to it).
= I use an action-A sprite in the same way, as I would use and address a TTD-sprite from trg1r.grf.
I will try to keep Action A much or less the same. Otherwise all GRFs would break
OzTransLtd wrote:
= Action-1s are used unchanged via sets, with the offset into each set provided by the patch and I need not know what the sprite number is (e.g. 0 to 7 for vehicles, or sprite number from the tile layout for stations). Actual sprite numbers are all translated and mapped the the GRF local sprite block and I need not be aware of what they are.
TTDPatch will resolve action2ids locally to Action1, so every Action1 virtually uses sprite number 1 instead of a feature based sprites number. This should be transparent to user. Only problem if you try to load a new big grf without my patches enabled: To much sprites will be used then.
OzTransLtd wrote:
Just one question, how is the GRF Author Helper feature affected by this ? Can we still use the sprite number in .NFO to access individual sprites stored in an action-1 block.
It should work better after it will be fixed, as Sprites won't be cached or inserted anymore. The TTDPatch windows version may introduce a reload GRF button as GRFs could be reloaded much easier. (This would need tweaking code so all currently relevant static information will be reloaded too)
OzTransLtd wrote:
I think we can all be very happy chaps, if we get 11k of sprites per action-123 chain in a GRF. CanStn won't use more than 5,000 across all action-As and -1s. CanRail, will be very happy with about 16k of them. If this is possible, the entire TTDPatch community will owe you a big thank you …
Finally, if we get 4GB pseudo sprite sizes, proposed by DaleStan, the sky is the limit ...
My current status:
+ New experimental feature switch, still not useable
+ Sprite caching code killed, TTD now uses always the loaded sprite.
+ Checked the grf spec what TTD really means with some bit flags
+ Started to write a new grf loader
+Marked some code for rewrite
Plans:
As soon as the no caching code works, I can test the base. If this works, move this code to be the default.
Then I can change Action2 to use grf local sprites. (maybe only certain features as start)
Remove the features from the feature based sprite system. Remove the code completely as soon as there aren't any feature based sprite ranges any more.