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.
I absolutely loathe that idea and think that nothing implies that there is "no need" for a standalone 32 bit base set. In fact the need has concrete foundations detailed in this very thread. Not to mention the fact that having the 32 bit base set replacement represent a "second-class citizen" in comparison to its 8 bit counterparts frankly devalues our artists' hard work.
The rest of the points on that list I pretty much agree with.
A completely different issue is in this matter the zoom-levels. But it could follow a similar pattern
The way I thought about zoom levels, and recall going through it with Ben a while back, is that the GRF format would support adding alternative sprites for game items, both in the bit depth sense and the zoom sense. So like you said, the changes would be rather similar.
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.
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.
I don't see how getting rid of chopped vehicles and angular corners is a gameplay change. It's a visual improvement, which the project is all about. You don't want it? Fine. But a lot of people disagree with you.
Even if you consider them gameplay changes, and refuse to accept anything else; there are already plenty of gameplay changes in OpenTTD, most of them toggleable. What's wrong in implementing more?
Anyway, we are not even discussing those features at this time. They are separate issues that we're not trying to push with these changes.
In 2007 we added support for 32 bits graphics in OpenTTD and seemingly no-one could be bothered.
Quite apart from the fact that "no one" is a massive overstatement, there are multiple reasons why the standard zoom 32 bit movement didn't generate a lot of buzz:
- Standard zoom is incredibly underwhelming once you've had a taste of extra zoom.
- As a result of the above, most of the content available in 2007 were rubbish resized EZ sprites that looked blurry and glitchy in standard zoom.
- Outside the above, the content that was available in 2007 was lacking and poorly standardised in comparison to what we have in 2010.
By improving the standards that graphics development adheres to, we are in the process of making even standard zoom 32 bit gfx more valuable. This includes sharpness, LOD and such. So to say no one cares about 32 bit standard zoom is just plain wrong. What's right is that we care more about extra zoom and that's why we want it in trunk.
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.
This is a valuable piece of text. Something that has to be posted in the patch thread so that it's more likely to be addressed.
Of course, even more valuable would be a point-by-point list of what's actually wrong with the code, so we can, you know, fix it.
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. [ ... ] This would mean uploading 300 MiB to bananas via a web form, which probably might not be such a good idea. [ ... ]
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.
Is there a reason not to use the obvious solution, which is to bypass the webapp? Use something like scp to insert the files and a remotely callable PHP script to update the database.
It's going to be a while before we'll have a 300 MiB graphics set available for download. Until then the package sizes are going to be somewhat manageable.
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.
You don't need to host old versions, just the latest one.
But then, that only makes sense when there is something to actually put there that actually works.
If it's tars you want to work, then there's lots of stuff available right now that works. And you don't need the EZ patch for it to work. You only get more zoom levels if you have it.
If it's 32 bit GRFs you want to work, then yeah, we need to sort out the format before we start making changes to BaNaNaS to accomodate it.
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.
I don't see a reason why we can't duplicate the functionality of the 8 bit base sets when it comes to that.
[ ... ] no need to create a separate NewGRF format for 32bpp graphics, [ ... ]
We're not trying to create a separate format, we're trying to push improvements to the old one. As for how that's technically done, you seem to have a lot of ideas that I don't have the expertise to evaluate.
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.
If you're talking about NewGRFs, then that sounds like a nice, useful feature.
If, OTOH, you're talking about a base set... well, I've covered that.
Deciding the behaviour of using 32bpp graphics vs 8bpp graphics on the blitter in use might not be such a good idea though. [ ... ]
IMHO it's a "must have" type of feature. Whatever problems there are preventing its implementation need to be fixed, not just going "meh, too bothersome".