Additonal extra base GRFs (openttdw.grf/ogfxe_extra.grf)

[GeekToo]

Why are the spritenumbers in the ogfxe_extra.grf not equal to the ones in the openttdw.grf?
This way you make it impossible for 32-bpp sprites to replace the openttdw.grf/ogfxe_extra.grf by just adding a symbolic link, like it works for the trg*.grf files?

[FooBar]

Why are the spritenumbers in the ogfxe_extra.grf not equal to the ones in the openttdw.grf?

Because that was rejected as feature: http://dev.openttdcoop.org/issues/208

I reopened the issue, as there is a need for the feature right now

[GeekToo]

Ok, thanks.
I guess for now, it's best to not replace the ofgxe_extra.grf sprites in the 32bpp tars, because they may change to the openttdw numbering again?

[Ammler]

Again, why don't you make your own newgrf, at least for the newgrf features. also openttdw.grf can change...

Edit: Foobar, please discuss that with openttd devs. I don't think it makes sense.

[planetmaker]

Ok, thanks.
I guess for now, it's best to not replace the ofgxe_extra.grf sprites in the 32bpp tars, because they may change to the openttdw numbering again?

The sprites in the extra newgrf have no defined order as it basically is a newgrf in its own right. My personal proposal is to code those 32bpp as a newgrf, too. That's the standard way to handle those things; players then can include that as a static newgrf.

I see no need for complication there.

[GeekToo]

It's not a 'normal' newgrf, as it's part of the base graphics, so I cannot switch it off. Having to create a new newgrf, which is basically a copy of the one that already exists, does not really make sense to me, apart from the fact that having to create a newgrf is an extra hurdle for 32bpp creations, that is not really necessary.

I did not ask to complicate things, I just want to simplify them, by keeping the spritenumbers, at least in the base graphics the same. Currently the complication is moved to the 32bpp tar creators.

[planetmaker]

So... shoving it into my shoes is easy?

Maybe you could provide me with a patch for ogfxe_extra.pnfo.

[GeekToo]

No, Planetmaker, I'm certainly not trying to shove anything in anybodies shoes.
And don't get me wrong, I was not attacking or belittling the work of the OpenGFX guys, I think you did a great job, that helped OTTD a step further.

And I'm also not interested in creating an atmosphere of newgrf guys against 32-bpp guys, I think we can complement each other in serving a wide range of users with different tastes.

My question was just technically oriented. For most sprites, we can replace
the base graphics by a symlink from the directory named after the original
grf, to the equivalent directory named after the ogfx grfs. That way we can
replace sprites for both groups of users. Except for the openttdw to the ogfxe_extra directory. Here the spritenumbering is different, and symlinking won't work.

Both you and Ammler suggest to create a new newgrf for 32bpp.
I was serious that I don't see a reason for this. For 8bpp sprite replacing, this is the standard way of doing things.
But not for 32bpp.
We just need a base/new grf, so we know what directory to create to put the png files in, and the spritenumbers, so give the correct filename to the png. For base graphics both already exist. Creating an extra newgrf that basically copies this information, with dummy 8bpp graphics in them just does not make sense to me. Maybe you have a point, and am I completely wrong, but then please provide a reason why it is better. Yes, you can disable a newgrf, but when I don't want to see 32bpp graphics, I start an 8bpp blitter, probably faster too.

To conclude, I see a couple of possible ways we could go:
-continue to support both basegraphics sets in 32 bpp. It would
mean either renumbering the sprites in ogfxe_extra (lot of (boring) work),
or split the tars (or copy the pngs in them), and renumber the sprites in
them (also a lot of (boring) work).
-drop the support for both sets, and aim only for the original dos, original
windows, or opengfx grfs (in this case I'd opt for opengfx). That would mean
the set to replace would have to be relatively stable (additions are not a problem, renumbers are, as they render tar sets (partly) unusable).
-copy the opengfx grfs, and create a new obg set for 32bpp. Imho opinion not preferred, it just creates redundant data and bananas downloads, and the only advantage is independance of opengfx grfs.

I have not really made up my mind what's the best option, but I wanted to
share my view upon the matter.

[Rubidium]

Stability of the sprite numbers in the 'extra' GRF can't be guaranteed.

There's one block of GUI sprites that occasionally gets one extra (older OpenTTDs are lenient enough to ignore the extra sprites). Now imagine we add a new feature that requires extra sprites and requires those to be added via a new action 5. In this case, without renumbering, you can only add it to the end of the file (no problem so far), however... now we can't add extra GUI sprites without renumbering the sprites or adding a whole new action 5 just for the new GUI sprites, until we add a new action 5 for something else and we need a third action 5 for GUI sprites.

Now if you package the 32bpp sprites with a NewGRF you can do the renumbering and release the updated 32bpp sprites + the sprite replacing NewGRF and the problems are much smaller (the set doesn't become unuseable by a renumbering in the 8bpp base graphics). You could even add extra 'comment' actions so the sprite numbers are 'nice', e.g. autorail starts at 100, GUI sprites start at 200.

[GeekToo]

Thanks, Rubidium, that's the kind of answer I was looking for. I'm not against adding a newgrf, but I always like to know WHY things are needed, and this makes sense.
I'm not a newgrf expert, so I'd like to know whether it is possible to create such an newgrf 'index table' without having to provide 8bpp pcx, and will it work for both basegraph sets?

[Rubidium]

It won't work without a 8bpp pcx, however... I reckon that a trivial 1x1 pcx reused in each replaced sprite does suffice and that it can probably be a 'static newgrf', i.e. a NewGRF that doesn't need to be loaded on all clients of a server.

Yes, with the NewGRF for the 'extra' (or even all the other) graphics both OpenGFX as the original graphics will be replacable.

[Roujin]

Drawback: The 32bpp set has to be complete, as the fallback would be to the 1x1 dummy sprites, not the base set's sprites. Correct?

[Rubidium]

Drawback: The 32bpp set has to be complete, as the fallback would be to the 1x1 dummy sprites, not the base set's sprites. Correct?

Yes, but whether that's a drawback I doubt. After all, you can consider to not add dummy sprites for the sprites you don't have in 32bpp yet (or use comment sprites).

[planetmaker]

I'm certainly not trying to shove anything in anybodies shoes.(...)

I'm sorry, obviously my comment was received much harsher than it was intended - and my explanation of the reasons for my reluctance next to non-existant. I took your words not in an offensive nor in an overly demanding way and my reply obviously carried the wrong tone and was too brief.

My question was just technically oriented.

Seems like Rubidium answered it already, thanks.

All which is basically needed (as far as I see it) is the source of the extra newgrf, add another GRFID, replace all sprites by the same black dummy sprite. Remove those sprites which you don't need or don't want to replace (for now) and compile that into a newgrf. So... not much extra work is needed there. And then make a tar which takes that newgrf as the base. If you use only actions 5 and A (as the extra newgrf (mostly) does), those newgrfs can be used as static newgrfs and anyone can use them even in MP, if the server doesn't use them; basically servers shouldn't use them as then there'd be those voide sprites for people who don't use the 32bpp... but you might, of course, also supply the 8bpp sprites which OpenGFX (or openttdw/d.grf) has there in order to avoid that kind of confusion; also in that case the source and the graphcis are already there and just needs shortening by the parts which you don't want to replace.

All this said: I also hope earnestly for a nice and full 32bpp replacement and I don't want to sabotage it. Surely not!

[Ammler]

Maybe we could make a official 32bpp extra grf, which if exist, openttd loads automatically? This grf, you could include to your tar.

What happens, if you have 2 tars replacing same sprites?

Moderators, could this thread be splitted from the start of 32bpp talk out and moved to the 32bpp Forum? (Proposal for new title there: "additonal extra base grf (openttdw.grf/ogfxe_extra.grf) replacements")

[CookiePinguy]

(You should now improve some of the graphics, like the paper wagons (that using sprites from fruit etc..) or the drinks factory!)

The fizzy drinks factory was never meant as a master piece of art. It was meant as something to get OpenGFX going after having being on standby mode for a few months. I'm more of a programmer type of person and even if I would have spent a week or two on the fizzy drinks factory, it wouldn't have become as good as in my imagination (I can tell it looked really cool in there). If you have the talent of pixel art you are free to improve it.

While I have the self insight to say that pixel art is not my thing and the fizzy drink factory might not meet up to the highest OpenGFX standard, I would appreciate a bit nicer wording* for something I've spent two days of work on in order to help the project forward. Though I do know there is people that has spent far more time on the project and whom I'm thankful for their dedicated hard work.


* = I find the exclamation mark after the fizzy drinks factory like yelling at its in your opinion poor quality.

My intention with the ! was express my happiness for the results of your work (Full post) not the opposite regarding the factory.
And sorry for not using more detailed wording for my post that could avoided possible misinterpretation.

[GeekToo]

Maybe we could make a official 32bpp extra grf, which if exist, openttd loads automatically? This grf, you could include to your tar.

I made a first proof of concept, and it does work very well for the extra coast tiles.
http://www.tt-forums.net/viewtopic.php?p=852397#p852397