Reorder ogfx_extra to make it easier to maintain
|Category:||Extras||Estimated time:||2.00 hours|
What needs to be done:
- split ogfx_extra.pnfo in seperate files like openttdw does: http://vcs.openttd.org/svn/browser/extra/ottd_grf/split;
- move all extras in respect to openttd to the very end of ogrx_extra (e.g. additional font characters, climate specific rivers/canals, climate specific rail vehicles);
- recode additional shore line grapics to (currently) unofficial ottd-spec;
- make unofficial ottd shoreline spec official.
#1 Updated by foobar over 10 years ago
- % Done changed from 0 to 10
Making spec official done: http://wiki.ttdpatch.net/tiki-index.php?page=Action5#0D_Coast_tile_sprites
#3 Updated by foobar over 10 years ago
- Status changed from New to Feedback
- Priority changed from Normal to Low
- Target version deleted (
Well, updating the newgrf specification didn't hurt as it might be useful to others. Figuring it out was useful to me: I didn't know that the way openttdw.grf handled coast tiles is only valid for base graphics, but OpenTTD's code told me so
On the other hand, splitting ogfx_extra into seperate files wouldn't be bad either. Whether it ends up being used for the primarily intended purpose or whether it just ends up. Doesn't have any priority anymore though.
#5 Updated by foobar almost 10 years ago
- Status changed from Rejected to Reopened
- Priority changed from Low to Normal
It seems there's a need for this feature after all...
#8 Updated by planetmaker almost 10 years ago
Making a newgrf from the 32bpp sounds like a viable solution to the problem, giving it, them and us the flexibility they want and need.
EDIT: Also good point: the sprites in OpenTTDd/w.grf change, if the GUI changes. Thus our sprite numbers will necessarily change.
#9 Updated by foobar almost 10 years ago
But that shouldn't be a problem. We /need/ to keep up with openttd.grf anyways if sprites get added to that. The additional sprites we have can go in the back, so that keeps the numbers of whatever is common between the two sets the same.
Personally I'm not a big fan of using NewGRFs for 32bpp graphics, as I recently expressed in the suggestions forum.
#11 Updated by foobar almost 10 years ago
I'm fully aware of that, but /if/ openttd.grf changes we /must/ keep up with that one way or another. When updating opengfx_extra it's just a small effort to make sure the numbers match.
I don't mind having this issue assigned to me. Even if 32bpp ends up using newgrf for purposes it isn't intended for, I think it's useful to split opengfx_extra for the sole purpose of making it easier to maintain.
#12 Updated by Ammler almost 10 years ago
Yeah, of course, we need to keep track of those changes anyway, but the motivation to do it for the 32bpp development is wrong direction, that's all I mean.
If you do it like that, you will later on be blamed, if you make the grf uncompatible again.
And if the openttdw.grf will become uncompatible, most likely the opengfx has to become uncompatible too.
For us it is easy to change all sprites one row up, but how will the 32bpp, specially the extra zoom guys do it? You give those people "wrong safyness". ;-)
Maybe we could create a real base newgrf, which only has action8 and then the sprites, no Action9/C etc.? And exactly in order of the spec? (Edit2: for this, we would need to reorder current extra grf, too ;-)
#13 Updated by foobar almost 10 years ago
- Subject changed from Reorder ogfx_extra to keep sprite numbers equal to openttdw.grf to support 32bpp project to Reorder ogfx_extra to make it easier to maintain
- Assignee set to foobar
- Priority changed from Normal to Low
- Estimated time set to 2.00
Alright, I can live with such an explanation.
Whatever the 32bpp project does with the results is beyond my worries
EDIT: There's no such thing as a spec that defines the order of the 'extra' grf. Only thing we can do is match what OpenTTD is doing. As long as we keep all Action0/C stuff at the end (beyond the numberings of openttd.grf) we're as compatible as it gets while still providing some extra things.
#14 Updated by Ammler almost 10 years ago
After all, I wouldn't do it before openttd devs tell, they will also try to keep it compatible for existing 32bpp tars...
Well, making it matching openttdw.grf does at least move the responsibilty from us to openttd devs, but does that help the 32bpp guys?
Edit: I guess, you all missunderstood me, I am not against supporting 32bpp, it is the opposite I want, I just fear making this grf match the openttdw.grf isn't enough...