Transport Tycoon Forums

GeekToo is knowledgeable (even very much so?) about NewGRFs but he's also very busy so I'd rather not bug him with this unless he explicitly offers his help.

Is it a big job? Perhaps he could take a break from the patch to do it (after all, it is necessary to make progress).

Best let people speak for themselves I reckon. If we concentrate on our own 'fields' (areas of skill) and discuss what needs to be done in other fields, then people can take on these tasks as they wish.

Being an embedded software engineer by profession, I am used to go through a couple of steps before writing a (change in) specification of a software project.

-identify the stakeholders
-identify the gains and losses of every stakeholder when the changes get implemented
-define the business case, in real life this means: do the profits outweigh the costs, for an open source project this is a little harder to define, but it guess it comes down to: can we find a developer to implement the changes given the benefits for the end user, compared to the efforts of making the change? In other words, if a change would require tremendous effort, but no end user would notify the difference, not many devs would do it for free.

When the business case has been set, ie there is a possibility of a profit, the next step, defining the specifications is started. The first step, WHY do we do it and what do we gain by it, is important before proceding to the step of specification: WHAT needs to be implemented, and after that, HOW dow we do it (design)

So, let's start with the first step:
Stakeholders:
-end users, game players
-graphics developers
-code developers


Second step (why do we want the change, and what does every (group of) stakeholders gain or lose with the change. I have my ideas about this, but because I want this to be an open discussion, I will not fill it in, but let's see what others think about this, so please reply if you've got an opinion about this.

Glad to see you're considering it!

Benefits:

1) Would allow the graphics to be easily distributed in a uer-friendly way (like via BaNaNas). This would be the big one as it's currently not a real base set.
2) Would make it easier to add to, like making NewGRFs.
I'm sure there's more...

That is a solid structure, no denying that. The questions are actually very similar to the ones answered in the graphics development project spec (in that project's case of course), from a slightly different perspective. It's great that you put it in writing, should speed up the thinking process for me somewhat.

Of course number 1 issue is that there is no revenue in making OpenTTD, therefore what we stand to gain is at best a reduction in losses in the long haul at the expense of increased immediate losses. Those losses cannot be compared because they are based on people's time and the value of people's time changes as time passes. The long-term gains are created by the clarity of having a single standard graphics delivery method for content developers, distributors and users to figure out.

The parties listed previously also constitute the group of stakeholders, with the addition of game client developers, who stand to lose their time supporting the code when it hits trunk. Basically you did think it out pretty well already, does not leave much to comment on apart from the addition of the game dev team.

As for why the feature is needed, for the uses of this conversation I will reference my posts in the recent discussion on the subject in the EZ patch thread.

The stakeholders are the game players here. The best source for consensus is the original game. We can say with some confidence that the 'stakeholders' are in an agreement in liking the look of TT. Therefore meeting this standard/style/look is in essence the same.

In identifying the losses and gains to stakeholders we need to consider what is an option (in game setting), and what is not. E.g. Having FZ on or off could be an option. Where as the issue of the embanked sprites, if solved, may not be. This would be justified by no-one really being interested in keeping the bug. Nothing would really be lost.

I think the 3rd point, of balancing work/gain is of some importance in relation to making the graphics work exactly as the 8bpp ones do. To put it simpler, is the project a branch with the aim of integration to trunk? and, what arguments are there for/against this? dev support, general increase in notability, specific coding requirements, handing over decision calls and spec setting etc. Also, there's the question of when to do these things. The importance of things will change. At a point of sprite replacement completion compatibility with trunk will possibly be more important than now.

Excellent post Geektoo.

GeekToo wrote:-identify the gains and losses of every stakeholder when the changes get implemented

.....

Second step (why do we want the change, and what does every (group of) stakeholders gain or lose with the change. I have my ideas about this, but because I want this to be an open discussion, I will not fill it in, but let's see what others think about this, so please reply if you've got an opinion about this.

This is a question that really needs an answer before proceeding with the next step. Wasila gave two advantages, although 1) can also be achieved through other means, and I'm not sure what he means with "make it easier to add to". Jupix wrote about some disadvantages of the current system, but nothing specific about 32bpp graphics in grfs.

One thing too keep in mind is network compatibility. When a grf has only 32bpp and no 8bpp sprites it can't be used by ttdpatch nor by openttd when an 8bpp blitter is used. That means that as soon as such a "32bpp grf" is used in a network game, you force all players to use a 32bpp blitter to join your game. I think it'd the first "setting" (as in server configuration, including the used newgrfs) that breaks network compatibility between 2 openttd clients of the same version. The easiest way around this only adding the 32bpp graphics to the grf when it also has the 8bpp sprites, but then you'd be right back where you are now with png files.

What do you think about adding a small meta-information file to each tar, giving each tar a name and description. That way 32bpp tars could be enabled/disabled the same way as newgrf files, with the exception that it'd be safe to change them in a running game (if that's technically possible). I haven't thought this through that well, so there might be obvious problems with this too.

This brings us right back to GeekToo's second step:

why do we want the change, and what does every (group of) stakeholders gain or lose with the change

This should really be answered more detailed before continuing with step 3. If the post by GeekToo isn't reason enough, "what's the purpose of this patch? Why would it be useful?" is a question that would surely be asked (if not implied by it's description) before it's included in trunk. If a disadvantage is only found out then because you didn't think it though beforehand, it could be a lot of wasted time.

I always felt that 32bpp should just be another toggleable palette for a base grf/newgrf... But that's just my 2c.

Yexo wrote:This is a question that really needs an answer before proceeding with the next step.

Frankly, the answers you're looking for are already posted in this, and the patch thread. The tars seem to me like a hacky content delivery medium, aren't toggleable, can't make a standalone graphics pack, and can't be distributed through BaNaNaS. As for having to expend energy on overhauling the NewGRF format and parser to make them support 32 bits, while unfortunate, it's just something that I believe should be done. There isn't much more to say that I haven't covered earlier.

Wasila gave two advantages, although 1) can also be achieved through other means

Like implementing in game management for tars, incl. support in BaNaNaS? I always assumed that is out of the question, based largely on the fact that the format, despite it's inherent problems, is a well-established format of distributing our content, and still there hasn't been a whisper on supporting it in BaNaNaS, and no GUI for managing tars either.

Jupix wrote about some disadvantages of the current system, but nothing specific about 32bpp graphics in grfs.

I don't understand what you expect me to write to cover "specifics about 32bpp graphics in grfs". If you mean technical stuff to specify how it would work, then don't hold your breath while waiting for me to write that, since I don't know the first thing about the technical side of grfs. That topic needs to be covered by programmers or GRF coders, i.e. people who know what they're doing.

If you mean why I think 32 bit gfx should go in GRFs, specifically, then the answer is very simple. GRF is the de facto OTTD medium for graphics, and if we were to move on from the tar format, then GRFs would be the obvious choice for a replacement medium, as there would be no more confusion on what format aspiring artists need to learn, etc. Not to mention the simplicity of having to support only one format in the game client.

One thing too keep in mind is network compatibility. When a grf has only 32bpp and no 8bpp sprites it can't be used by ttdpatch nor by openttd when an 8bpp blitter is used. That means that as soon as such a "32bpp grf" is used in a network game, you force all players to use a 32bpp blitter to join your game. I think it'd the first "setting" (as in server configuration, including the used newgrfs) that breaks network compatibility between 2 openttd clients of the same version.

Fair enough. Although running the -EZ patch doesn't make you very network compatible, either.

How this should work, of course, is that the game client can enable the 32 bit blitter on the fly (or it would be on by default), and you're prompted to download the necessary GRFs upon joining. I'm not pretending that implementing this would be the easiest way.

The easiest way around this only adding the 32bpp graphics to the grf when it also has the 8bpp sprites, but then you'd be right back where you are now with png files.

Not quite, there would be benefits over tars, mainly in ingame manageability and distribution. Dunno if the 8 bit blitter could display 32 bit graphics in 8 bits without the content actually being in 8 bits, in other words, dunno if it would actually be necessary to include 8 bit variants of the graphics for the 8 bit blitter, but like I said, even this would be better than tars.

What do you think about adding a small meta-information file to each tar, giving each tar a name and description. That way 32bpp tars could be enabled/disabled the same way as newgrf files, with the exception that it'd be safe to change them in a running game (if that's technically possible).

So long as the format would be supported by the dev team (meaning there would be no outcry about yet another content format), and BaNaNaS, and the user experience would be at least as seamless and straightforward as with NewGRFs, then I don't object.

This should really be answered more detailed before continuing with step 3. If the post by GeekToo isn't reason enough, "what's the purpose of this patch? Why would it be useful?" is a question that would surely be asked (if not implied by it's description) before it's included in trunk. If a disadvantage is only found out then because you didn't think it though beforehand, it could be a lot of wasted time.

I get what you're saying but don't really get why you're saying it. We've pretty much been through that. If you're unclear on something, take up specifics, so I can attempt to explain my POV.

OK, time for a summary:

From the users / players point of view, the most wanted features to improve the 32bpp ease of use seem to be:
1. ingame switch between 32bpp and 8bpp.
2. ability to download 32bpp contents ingame.
3. enable/disable 32bpp tars/spritegroups in the gui
4. multiplayer safety, 32bpp players and 8bpp players should be able to join the same server

Ad 1. This requires both 32bpp and 8bpp content to be present on the players computer. I'm not sure whether an ingame blitter switch is possible, but an ingame change in the config file and a message to restart the game sure is possible
Ad 2. Needs possibility of up/downloading 32bpp contents to/from Bananas and changes to the game to list/download that. That certainly is an area that needs improvement, currently we can download AIs, newgrfs, scenarios, but no 32bpp content, and that raises the bar for inexperienced users, and makes things more awkward for experienced ones, having to download tars seperately
Ad 3. Interesting feature for sure, but needs more discussion: do we want that per tar/spritegroup or per baseset etc
Ad 4. Personally I think there is no discussion here: 32bpp or 8bpp is a client side matter only (I have not tried it for some time but I also think the EZ patch is MP safe, though it may be hard to find a server on exactly that trunk rev).

Jupix wrote:Like implementing in game management for tars, incl. support in BaNaNaS? I always assumed that is out of the question, based largely on the fact that the format, despite it's inherent problems, is a well-established format of distributing our content, and still there hasn't been a whisper on supporting it in BaNaNaS, and no GUI for managing tars either.

Just a tar with sprites doesn't really have enough information to be managed via a gui in-game, the only way to select a set would be through the filename of the tar. The fact that no work has been done on this so far may very well be that none of the devs has enough interest in it to start coding. As I said before, including a simple metafile (look at the .obg/.obs files for the graphics/sound base sets for example) could solve the "not enough information to show in gui" part, then you'd just need a gui to enable/disable sets. Adding 32bpp graphics as optional replacement to grf files (ie add 8bpp graphics but also 32bpp (extra-zoom) graphics in the grf) would be another option, then they would be used as soon as a 32bpp blitter is enabled and the grf is active. After either of these options is implement it could be included in bananas. Support for extra zoom level graphics in bananas is a complete different matter, as that would mean uploading content to bananas that isn't supported by the OpenTTD from openttd.org.

If you mean why I think 32 bit gfx should go in GRFs, specifically, then the answer is very simple. GRF is the de facto OTTD medium for graphics, and if we were to move on from the tar format, then GRFs would be the obvious choice for a replacement medium, as there would be no more confusion on what format aspiring artists need to learn, etc. Not to mention the simplicity of having to support only one format in the game client.

Actually tars are ignored by the client, in the sense that when browsing directories a tar is read as just another subdirectory. So loading a png for every sprite is really one of the simplest formats the client could support. I do agree it's far from user friendly.

GeekToo wrote:1. ingame switch between 32bpp and 8bpp.
Ad 1. This requires both 32bpp and 8bpp content to be present on the players computer. I'm not sure whether an ingame blitter switch is possible, but an ingame change in the config file and a message to restart the game sure is possible

This would be an excellent first step that would also be useful in trunk.

2. ability to download 32bpp contents ingame.

Before this can be implemented a decision need to be made about the format. Also it should be possible to enable/disable the graphics via the gui (see point 3), otherwise there would be confusion when they're downloaded but not working (for example no 32bpp blitter) or there is no way to disable them again from in game after downloading graphics.

3. enable/disable 32bpp tars/spritegroups in the gui

IMHO this is a very important feature to increase the usage of 32bpp graphics, together with 2. of course.

4. multiplayer safety, 32bpp players and 8bpp players should be able to join the same server
Ad 4. Personally I think there is no discussion here: 32bpp or 8bpp is a client side matter only (I have not tried it for some time but I also think the EZ patch is MP safe, though it may be hard to find a server on exactly that trunk rev).

As I said in my previous post, this makes grfs with only 32bpp graphics impossible.

Yexo wrote:The fact that no work has been done on this so far may very well be that none of the devs has enough interest in it to start coding.

That seems like a common problem WRT to 32 bit gfx. Making our stuff as compatible (in a philosophical sense as well as the technical sense) with the existing graphics ecosystem is an effort to remedy that problem.

As I said before, including a simple metafile (look at the .obg/.obs files for the graphics/sound base sets for example) could solve the "not enough information to show in gui" part, then you'd just need a gui to enable/disable sets.

Like I said, if the implementation and user-experience would be neat, and would address the problems we're attempting to solve here (including but not limited to shipping a game client with just a 32 bit base set and no 8 bit equivalents), I wouldn't object.

Adding 32bpp graphics as optional replacement to grf files (ie add 8bpp graphics but also 32bpp (extra-zoom) graphics in the grf) would be another option, then they would be used as soon as a 32bpp blitter is enabled and the grf is active.

If that's the way it has to be, technically, by which I mean it can't be solved by a couple of nights' programming, then so be it. But from my perspective, it's stupid to have to ship 8 bit graphics only to get the game client to boot, when the player clearly wants to play with 32 bit gfx only.

Support for extra zoom level graphics in bananas is a complete different matter, as that would mean uploading content to bananas that isn't supported by the OpenTTD from openttd.org.

Getting EZ graphics on there is, in my opinion, a necessary step step towards trunk support for EZ.

What's actually happening here is: EZ graphics won't go on BaNaNaS before the patch is in trunk, and the patch won't be going in trunk before the content is on BaNaNaS. This goes for a lot of the other proposed changes as well. Stuff won't happen before EZ is in trunk, but getting EZ into trunk pretty much depends on those changes being implemented.

Either of those has to happen in order for us to move forward, and I hope you'll agree that it's easier for us to implement the more transparent stuff first, like making additions to the GRF system (or making tars toggleable, if you prefer) and implementing support for 32 bit content on BaNaNaS.

Actually tars are ignored by the client, in the sense that when browsing directories a tar is read as just another subdirectory. So loading a png for every sprite is really one of the simplest formats the client could support. I do agree it's far from user friendly.

I know how tars work. My points stand.

As I said in my previous post, this makes grfs with only 32bpp graphics impossible.

No, I don't think so. Correct me if I'm wrong, but all it does is make them network-unfriendly. And that's if we can't be bothered to program our way around it, making it so that one player can play with a 32 bit set and another with an 8 bit set (if a player's enabled GRF implements 32 bit graphics, ignore the GRF completely in determining client-to-client compatibility.)

Even disregarding all that, suppose it really is impossible to make alternative graphics compatible between game clients. What exactly is the problem there? Isn't that exactly what happens when players get alternative graphics while staying in 8 bits? What about that behavior makes extending the system to 32 bits "impossible"? By which I mean making it work like I described in my post earlier.

Jupix wrote:(including but not limited to shipping a game client with just a 32 bit base set and no 8 bit equivalents), I wouldn't object.

I don't think that will ever be possible. The baseset contains several sprites that are not really sprites, like pseudo-random data for the original map generator

Support for extra zoom level graphics in bananas is a complete different matter, as that would mean uploading content to bananas that isn't supported by the OpenTTD from openttd.org.

Getting EZ graphics on there is, in my opinion, a necessary step step towards trunk support for EZ.

What's actually happening here is: EZ graphics won't go on BaNaNaS before the patch is in trunk, and the patch won't be going in trunk before the content is on BaNaNaS. This goes for a lot of the other proposed changes as well. Stuff won't happen before EZ is in trunk, but getting EZ into trunk pretty much depends on those changes being implemented.

I don't see at all why the EZ patch depends on EZ-graphics on bananas. In fact the EZ patch existed before bananas, would you say that it would be impossible at that time for EZ to get in trunk because there was no online content service?

Either of those has to happen in order for us to move forward, and I hope you'll agree that it's easier for us to implement the more transparent stuff first, like making additions to the GRF system (or making tars toggleable, if you prefer)

I completely agree till this point.

and implementing support for 32 bit content on BaNaNaS.

IMO this is the wrong way around, the patch should go to trunk before bananas support is implemented. Of course that depends on how it would be implemented, because if 32bpp graphics would go in grf files then there is no new bananas support needed.

Jupix wrote:

Yexo wrote:As I said in my previous post, this makes grfs with only 32bpp graphics impossible.

No, I don't think so. Correct me if I'm wrong, but all it does is make them network-unfriendly. And that's if we can't be bothered to program our way around it, making it so that one player can play with a 32 bit set and another with an 8 bit set (if a player's enabled GRF implements 32 bit graphics, ignore the GRF completely in determining client-to-client compatibility.)

Even disregarding all that, suppose it really is impossible to make alternative graphics compatible between game clients. What exactly is the problem there? Isn't that exactly what happens when players get alternative graphics while staying in 8 bits? What about that behavior makes extending the system to 32 bits "impossible"? By which I mean making it work like I described in my post earlier.

I wrote "impossible" there as a reaction to GeekToo statement:

GeekToo wrote:4. multiplayer safety, 32bpp players and 8bpp players should be able to join the same server
Ad 4. Personally I think there is no discussion here: 32bpp or 8bpp is a client side matter only (I have not tried it for some time but I also think the EZ patch is MP safe, though it may be hard to find a server on exactly that trunk rev).

• We want to keep the 8bpp blitter
• A grf will never be able to detect if the user has selected a 8bpp or 32bpp blitter, for exactly the same reason it isn't able to detect which baseset is used
• If a grf has only 32bpp graphics but no 8bpp alternatives for them, those graphics can't be shown for a client that runs with a 8bpp blitter

Combine those points and it means players that uses the 8bpp blitter can't join a server where a grf with only 32bpp graphics is used. In my opinion this is a big no-no. Possible solutions for this are to either make sure the 32bpp graphics in a grf are alternatives for 8bpp graphics or make 32bpp graphics a complete different thing that would be only enabled client-side, ie no grf but a similar gui for it.

Surely it is dead easy to write a 32bpp-8bpp converter? It wouldn't look anywhere near perfect but would be functional...

Yexo wrote:I don't think that will ever be possible. The baseset contains several sprites that are not really sprites, like pseudo-random data for the original map generator

Well, that pretty much breaks the idea for me. 32 bit gfx should be standalone. If that can't be done with tars, then tars are no good. (In principle, of course.)

I don't see at all why the EZ patch depends on EZ-graphics on bananas. In fact the EZ patch existed before bananas, would you say that it would be impossible at that time for EZ to get in trunk because there was no online content service?

That's not what I'm saying. I'm saying the 32 bit project needs to exist within the existing graphics ecosystem, not outside it as its own playground, for it to be as quick and painless a process as possible to get the patch into trunk. Getting the content on BaNaNaS now is part of that. Before the system existed, there were other considerations, which may or may not exist currently.

As for whether it's impossible ever in the future in any shape or form for the patch to make it into trunk without us making these changes, I shall not comment on that (I can't prove a negative, can I), but by now you probably get what I'm trying to say here.

IMO this is the wrong way around, the patch should go to trunk before bananas support is implemented.

Well, that's where we kinda disagree. Because by experience, I don't see you guys (dev team) giving the patch the time of day before it implements something that lives in the current graphics ecosystem. In theory, I agree that this shouldn't be the case - you devs have had ample time to review the patch and put it in trunk - but that doesn't appear to be how this really works.

Of course that depends on how it would be implemented, because if 32bpp graphics would go in grf files then there is no new bananas support needed.

That's what I'm trying to say. And it'd be easy for the players to get their head around.

Combine those points and it means players that uses the 8bpp blitter can't join a server where a grf with only 32bpp graphics is used.

Please stay with me, it's probably my not understanding the underlying technology, but I just don't see the problem here. All the items in game are called from a GRF with an identifier of some sort, right? So if we don't change the identifiers, what difference does it make from a compatibility POV if the server has loaded a 32 bit base set, and the client an 8 bit one?

I see the problem in the case of NewGRFs but that's a whole another discussion.

Jupix wrote:

Combine those points and it means players that uses the 8bpp blitter can't join a server where a grf with only 32bpp graphics is used.

Please stay with me, it's probably my not understanding the underlying technology, but I just don't see the problem here. All the items in game are called from a GRF with an identifier of some sort, right? So if we don't change the identifiers, what difference does it make from a compatibility POV if the server has loaded a 32 bit base set, and the client an 8 bit one?

I see the problem in the case of NewGRFs but that's a whole another discussion.

Sorry, you're right. I was talking of NewGRFs. But I really don't see the point of changing the grf spec to allow 32bpp graphics in base set grfs but not in NewGRFs. Especially as the extra grf is a NewGRF.

Was the rest of you posts in this topic also only about base sets? I thought the discussion was a bit more generic about "32bpp in (new)grfs". With regard to basesets: I really fail to see the problem of including a 8bpp baseset in that package, you could take opengfx for examle but change the description/name so it can be selected as a separate baseset in the option while proving the graphics via the current tar-loading system. Are the 3mb really such a big problem if you hvae to download xxmb of 32bpp graphics?

Well, the conversation has probably half-verged to touch on NewGRFs as well (unintentionally or not), but from the 32 bit gfx project's POV, the first order of business is building an OpenGFX-style base set that can be marketed as its own standalone product, and making that possible is what we're discussing in this thread.

It's true that the required changes in the GRF spec would also work towards making 32 bit NewGRFs possible (in part sparking the NewGRF-oriented comments in this discussion), but there are other, NewGRF-specific issues, like the ones you have brought up. This thread is for the base set. If you think it's best to ponder the NewGRF-specific issues now, before doing any of the work required for a 32 bit base set, then it might be a good idea to split this discussion into one whose sole purpose would be to reach a concensus on where to go WRT content delivery methods and implementing support for new stuff.

Yexo wrote: But I really don't see the point of changing the grf spec to allow 32bpp graphics in base set grfs but not in NewGRFs.

Mostly, it would be an intermediary step between no 32 bit content in the graphics ecosystem, and all of it there. Implementing it soon would allow us to start working on the base set without having to change the delivery method halfway through the project if/when the GRF spec was revised. It may be that standalone 32 bit NewGRFs would be unsupported but I wouldn't mind, and it doesn't sound like a bad idea to me that 32 bit NewGRFs included 8 bit sprites to make them compatible. So long as the base set would be standalone.

I really fail to see the problem of including a 8bpp baseset in that package, you could take opengfx for examle but change the description/name so it can be selected as a separate baseset in the option while proving the graphics via the current tar-loading system. Are the 3mb really such a big problem if you hvae to download xxmb of 32bpp graphics?

Having to include anything besides the content we specifically want to include is a problem in my book. If it was automatically generated, like Zephyris suggested, then I guess it would be sort of acceptable as a solution to a real, existing problem, but I'd prefer it if even that functionality was built into the blitter (if 32 bit blitter is selected, behave as normal, but otherwise convert stuff on the fly). If we had to include OpenGFX, it'd be even worse. Twice the likelyhood of bugs, and who's going to maintain that component of the set?

It's not so much the bandwidth, but then, it is stupid to waste bandwidth downloading something that you most likely already have anyway. And 1000 users downloading 3 megs works out to a reasonable amount of bandwidth.

Yexo wrote:

• We want to keep the 8bpp blitter
• A grf will never be able to detect if the user has selected a 8bpp or 32bpp blitter, for exactly the same reason it isn't able to detect which baseset is used
• If a grf has only 32bpp graphics but no 8bpp alternatives for them, those graphics can't be shown for a client that runs with a 8bpp blitter

Combine those points and it means players that uses the 8bpp blitter can't join a server where a grf with only 32bpp graphics is used. In my opinion this is a big no-no. Possible solutions for this are to either make sure the 32bpp graphics in a grf are alternatives for 8bpp graphics or make 32bpp graphics a complete different thing that would be only enabled client-side, ie no grf but a similar gui for it.

Given this list of pre-conditions (which I agree with), they imply IMHO a few things:

a) there needs to be added means to OpenTTD client-side to (de-)select via GUI the 32bpp replacement sprites, if a 32bpp blitter is enabled.
b) there's no need for a 32bpp base set, they may easily exist as add-on as they do now, replacing possibly every single sprite of a base set. The format of the extra newgrf doesn't change often; as such a change can be communicated as easily between 8bpp and 32bpp developers as a necessary change between OpenTTD devs and 8bpp developers is communicated (last year it was necessary one, maybe two times, releases were scheduled to within 24 hours concurrently, notification time was ~ one week or so).
c) It might be possible and desirable to extend newgrf specs such that 32bpp sprites can be provided as an alternative to the 8bpp sprites (which still need to be supplied as fall-back). This would make b) possible as static newgrf.
d) It might be nice to change the blitter on a running game: It probably goes into the options menu (where language, base sets etc are selected; it's probably not a light change as it requires directly accessing and handling the graphics device driver(s) and possibly switching modes there).

A completely different issue is in this matter the zoom-levels. But it could follow a similar pattern:
a) Extend the newgrf specs accordingly such that sprites for different zoom levels (further in, but also zoomed-out) can be provided.
b) Implement an improved zoom-function (Zephyris proposed a nice way, I don't have the link to the thread at hand right now) for those cases where no zoom-levels are defined.
Then no changes to other frameworks and user interfaces are needed while maintaining complete compatibility.

Jupix wrote:Because by experience, I don't see you guys (dev team) giving the patch the time of day before it implements something that lives in the current graphics ecosystem.

My experience is that "the 32bpp project" wants to push a lot of changes that would make OpenTTD not like Transport Tycoon, which basically goes directly against what OpenTTD stands for; it being a clone with improvements. Good examples of this are the odd scaled vehicles and angular corners, both which "had to be changed" for the "cause" of 32 bits graphics.
In 2007 we added support for 32 bits graphics in OpenTTD and seemingly no-one could be bothered. That made, at least for me, quite a strong case that you weren't interested in 32 bits graphics, but in pushing your own agenda w.r.t. changing the gameplay instead of just replacing the graphics.

Then there are the many changes in how to handle the grahpics files over time; especially the v9 then v10 and then back to v9 thing comes to mind, although there are undoubtedly more cases. Also looking at the patch itself made me almost cry; it's a coding style mess and I spotted cases where trunk fixes seem to have been reverted. That leads me to conclude that no one has bothered with a serious review of the(ir) code and as such not considered ready for even considering inclusion into trunk.

Things like getting bananas support for the 32bpp graphics is something completely different, however given that the 32 bpp nightly packs are currently around 30 MiB and cover roughly 500 sprites, and a quick count of resizable sprites, i.e. landscape/vehicle/building sprites, exceeds 5000 that would mean a pack of at least 300 MiB. Did I already mention that PNGs are hardly compressable (less than 5% improvement) because they are already zlib compressed? I have to agree that LZMA is twice as good, but also only yields a 10% reduction. This would mean uploading 300 MiB to bananas via a web form, which probably might not be such a good idea. The mirrors will definitely help with solving the "download" problem, however with 300 MiB per release doing frequent releases would fill our server's harddrives quite quickly.
I know for a fact that the current upload backend for bananas will barf at anything where the compressed/uncompressed size is more than some 60 MiB, so that would need to be reworked. But then, that only makes sense when there is something to actually put there that actually works.

The base set contains, like said before, some recolour sprites which might not be that important... however, it also contains a lot of characters, i.e. the font. Most of these characters can be fetched from a norml font but a number of them cannot. Examples of this are the train, truck, bus, ship and aircraft icons in the station name. Ofcourse you can add a load of special casing here, but it would be (arguably) better if you were to supply them in the same way as is currently done; that would mean less duplication of code and therefor less chances of anything going wrong.
It might be relatively easy to update NML to process the 32bpp "extra zoom" sprites referenced. By process I mean downscaling if no downscaled version exists, converting the "normal zoom" sprite to an 8bpp sprite and appropriately setting the x and y offsets. It could also, besides outputting the GRF, copy the 32bpp zoom sprites to the right place and right (numeric) name. This should solve most of the graphics need a specific name and the encoded offset problems without developing something completely new. You can also name and structure the files in something humans can understand. Another advantage is that this way there is no 8bpp problem and no need to create a separate NewGRF format for 32bpp graphics, at the "cost" of having an up-to maybe 5% filesize increase over not including an 8bpp version.

We *could* even consider bananas splitting the uploaded 32bpp package into an 8bpp package and 32bpp package where the 32bpp package depends on the 8bpp package and based on your (current) settings it'll download only the (base) 8bpp or both versions. This would then solve the "need to download 10-100 times as much as needed" if you want to play with just 8 bpp graphics. If we consider "upgrade" to select also the 32bpp packages associated with 8bpp graphics (again changeable by a setting), it would be dead easy to upgrade your bananas downloaded 8bpp to 32bpp if 32bpp graphics exist. In other words, upgrading/initially acquiring the 32bpp graphics would become easy as well, besides the possible few hundred MiB download.

Deciding the behaviour of using 32bpp graphics vs 8bpp graphics on the blitter in use might not be such a good idea though. Ofcourse Mac OS X isn't officially supported, but there the 8bpp blitter doesn't work correctly and I think it is only a matter of time before it happens on other OSes as well. Furthermore I think using 32bpp NewGRFs only makes sense when the base set is 32bpp, so adding a way to specify that a base set has 32bpp graphics and some switch telling you want to use them. If at that moment an 8bpp blitter is used OpenTTD should select a 32bpp blitter, possibly asking for confirmation of that change.