I suppose it is time we add a nightly 32bpp archive.
I believe it is better to maintain a separate 32bpp archive than to bundle PNGs together with the grfs:
32bpp PNGs are much bigger in size and we won't have new artwork often.
Currently 32bpp PNG's are scattered around, and this is not very helpful for new players.
Besides my sprites, there are a few others in the forums that fit to OpenGFX's style and we could also use some of those available for extra zoom patch. Of course we should be cautious to avoid sprites that do not fit with OpenGFX style (For example most extra zoom structures have different scale and shading).
#1 Updated by foobar about 10 years ago
Good suggestion. Maybe a repository will help get OGFX32 off the ground and get other people interested. A split of the main OpenGFX development would be good to raise more awareness for a 32bpp version.
Athanasios, are you interested in maintaining such a repository? Ofcourse we can and will help you to create a useful structure. But after that you'll be the main guy to keep the set 'alive', like I did for OpenGFX in the period that progress was zero to none. Eventually others can join you maintaining the set, in the meantime we'll keep an eye out
But before a repo can be created, we need a name for the project. I think my OGFX32 is quite catchy, but you might disagree. I greatly discourage to use the full "OpenGFX" in the name, as that might confuse people thinking it's a successor of OpenGFX, which it isn't.
For the structure it would be useful to know how 32bpp work in the game. I have a clue, but am unaware of the details. Maybe planetmaker is interested in creating a makefile that packs pngs into a useful releasable bundle. Maybe the makefile can do the actual pngcodec'ing from some list of values.
#3 Updated by Ammler about 10 years ago
I would start like the 8bpp project, for first, just some newgrfs with 32bpp stuff. IMO, it is wrong to make 32bpp bounded to a base set, I tried to tell that the 32bpp project but they won't listen.
The existing 32bpp extra zoom graphics are mainly not usable with openttd trunk, like no chance to see, which state a signal has.
Wouldn't it make sense to make the 32bpp and 32bpp extra zoom with same graphics, just more details on openttd trunk level?
#5 Updated by athanasios about 10 years ago
I didn't have in mind a separate project. (Just to keep in a separate zip or tar the pngs available.) The 32bpp pngs will not be yet another replacement set for the original grfs. No grfs here. Just pngs. Pngs just display in place of the pcxs when you run the game in 32bpp and do nothing more. So no extra code is needed (except the x and y offsets set in the png file itself), and no compilation like a grf. I now see that mentioning about OpenGFX32 or ogfx32 will cause some confusion to outsiders. Maybe we can use something like 'OpenGFX_32bpp sprites' or 'OpenGFX_pngs' or simply '32bpp_pngs'.
I do not expect so many to join so we can have a png for all OpenGFX sprites in the near future, still you are right foobar-artists will have an incentive to contribute (take into consideration that some draw in 32bpp and then reduce). Leaving the png's around, as we currently do, doesn't help anyone (neither players nor artists, and even worse the developers. We nagged a lot for 32bpp support and unlike other features/patches they added it. But we didn't do much to utilize this feature. - Then 'we' come again and complain because developers don't add this or that feature...)
Ammler, it is true that the same pngs are able to replace even original grfs (Just a few (extra grf) will need their file name renumbered). Still we should not separate them from OpenGFX. Their role is to improve the visibility of OpenGFX in 32bpp mode. Actually for many sprites, what needs to be done is only an anti aliasing. For others some colors to be replaced or pixel tweaking. We do not need to draw a completely new sprite for every existing sprite. OpenGFX tries to be close to original sprites. The extra zoom project is quite different in style. Just like you cannot mix Simutrans pak128 with pakComic. OK, not so much of a difference-here we can borrow some sprites, but with discretion. Of course I would like to have the extra zoom project display well also in normal zoom-a task that requires plenty photoshopping to display properly specific sprites as you stated. Extra zoom does not need to have any grfs to display (just the renumbering I mentioned above)-unless they want to make an 8bpp equivalent, which I do not believe is what they intend to do. But in the future they will need. There are already so many additional 'extra zoom' buildings rendered, that deserve a new grf.
Similarly for our case we will also need a new grf for 'new' OpenGFX or better 'plus' stuff-to avoid confusion with extra 'OTTD' grf. OpenGFX+, which can contain both 8bpp and 32bpp stuff will be a subproject to extend OpenGFX (e.g like the extra aircraft in av8 set). It is not wise to add such stuff either to OpenGFX 'extra' grf or mix '+' 32bpp pngs with 32bpp pngs that simply replace 8bpp sprites.
Now about maintaining a repository I must admit that I am not a coder, but if it does not require any special skills, I volunteer. As we are not to expect too much contribution from artists, we may have a 'nightly', but it will probably be a 'weekly' if not a 'monthly' (LOL)-still it is better than nothing. Let anyone prove me wrong on this, and I will be happy! ;-)
#6 Updated by foobar about 10 years ago
Athanasios, I must admit that I initially read "repository" where you wrote "nightly". That's two completely different things and a bad from my side
Still I think a seperate repository is useful, as that makes both contribution and creation of nightlies that much easier. As "project" it can be a sub-project of OpenGFX so that it doesn't have to be completely seperate. And by project I mean a project page here on devzone.
Similarly OpenGFX+ can become a sub-project as well as soon as we have stuff for that (and the will to actually start to create it).
Maintaining a repository doesn't require any specific skills. You just need to set up Mercurial on your computer and the ability to use a makefile. Provide us with your public OpenSSH key and commit access can be set up for you. More info in the Guide section at the top of the page.