Feature #208

Reorder ogfx_extra to make it easier to maintain

Added by foobar over 10 years ago. Updated over 9 years ago.

Status:ClosedStart date:2009-06-15
Priority:LowDue date:
Assignee:foobar% Done:

10%

Category:ExtrasEstimated time:2.00 hours
Target version:-

Description

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.


Related issues

Related to OpenGFX - Feature #108: Unduplicate nfo code Rejected 2009-05-27
Related to OpenGFX - Feature #820: Base files splitting Closed 2010-03-15

History

#1 Updated by foobar over 10 years ago

  • % Done changed from 0 to 10

#2 Updated by Ammler over 10 years ago

After some sleep and day off from opengfx, I am not sure anymore, if we should try to sync our newgrf with openttdw.grf, it would be proper imo to make the 32bpp graphics as newgrfs. In fact I asked there. ;-)

Let us wait for that answers...

#3 Updated by foobar over 10 years ago

  • Status changed from New to Feedback
  • Priority changed from Normal to Low
  • Target version deleted (0.2.0)

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.

#4 Updated by planetmaker almost 10 years ago

  • Status changed from Feedback to Rejected

Too much work for too little gain. Doubtful anyway there'll be a 32bpp repo which really uses this anytime soon.

#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...
http://www.tt-forums.net/viewtopic.php?p=851375#p851375

#6 Updated by Ammler almost 10 years ago

1) Are openttdw.grf sprites constant?
2) does opengfx.grf have the same amount of sprites?

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

#8 Updated by planetmaker almost 10 years ago

planetmaker wrote:

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

@Ammler:

1) No
2) No

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.

#10 Updated by Ammler almost 10 years ago

But new sprites might not just be appended, they could also be inserted, so all following sprites are wrong, or a simple compatibility clause on the header does make the whole extra grf invalid for existing 32bpp tars.

#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". ;-)

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

#15 Updated by foobar almost 10 years ago

Don't know if it helps the 32bpp project. I know it helps us as future discussion is out of our ballpark and for me that's worth something as well.

#16 Updated by Ammler over 9 years ago

does r359 help here?

#17 Updated by foobar over 9 years ago

  • Status changed from Reopened to Closed

I think it does :)

Also available in: Atom PDF