Transport Tycoon Forums

ECS Wood Vector + 32bpp png from http://wiki.openttd.org/32bpp_Extra_Zoom_Levels_Files (Lumbermill , Printing Works)
Is there anyone who will finish it?

My advice would be: don't do any work on it. Devs will make a commit and make all of your hard work useless, even if you've spent thousands of hours on it, they will not even send a PM or announce on the forum that formats will change, making the work useless. When you try to get your work back in, they will be picky about standards, that will get changed during a discussion, but ignored if someone puts in a large set with the same problems. It is sad but true (thanks Metallica) to see that most of the once very active 32bpp community has left, but I understand it completely.

While I am a developer, I wasn't much involved in the entire 32bpp introduction/change (nor do I care about 32bpp very much), and saw things happen much like you did (although I came in much much later).

I agree it is sad that work needed to be redone, but it's often inevitable, it's virtually impossible to do everything right the first time with such large changes.
Using the tar method would require all newgrf authors to distribute some of the graphics in the newgrf and some other graphics in a tar file. That doesn't work very well either, merging 32bpp into newgrf is a much better solution.

We were of course well aware of your previous work, and have tried to rescue it. Rubidium wrote a script to do the conversion mostly automatically, but couldn't go further due to licensing problems. iirc Yexo also offered help, provided that a set of freely distributable graphics could be created.
Unfortunately, nobody managed to separate the freely distributable graphics from the non-distributable graphics, and have the energy to continue from that point.

In my view, it is not right to blame us for failing to handle proper licensing of the graphics. You would have had the exact same problem if we continued using the tar format. Our change just made the licensing issue more immediate.

ECS Wood Vector + 32bpp png from http://wiki.openttd.org/32bpp_Extra_Zoom_Levels_Files (Lumbermill , Printing Works , Papermill , forest house)

Hello all!

I am a returning OpenTTD fan, and about 2 weeks ago was looking into the 32bpp progress so far. As I understand there are basically two efforts:

1. This "32bpp Extra-zoom" effort: it was doing GREAT until an important development architecture change upset a lot of graphics artists here. Furthermore the licencing on the various completed graphics was unclear.
2. zBase, which was started using the newer (post OTTD 1.2) architecture immediately, and also has a clearer licencing situation.

Now I looked at zBase, and it is a brilliant effort because it is for all intents and purposes complete. But, when compared to this older 32bpp EZ project, I must say I find the graphics produced here more vibrant, more detailed and generally more visually appealing.

Now the major stumbling block in getting these graphics working in newer versions of OTTD appears to be the fact that they need to now be "compiled into" a ".grf" file. And the .grf files are a whole lot more picky about the graphics formats, sizes and palettes that the previous .tar-based mechanism probably was.

Well being a stubborn developer myself (but without prior experience in OTTD), I set out to try it anyway And after a week of intense working, I think I have something pretty well worth the effort now:


As you can see, I am using the "zBase" base set, and my grfs with the 32bpp ez sprites compiled in. Any baseset can be used though, including OpenGFX or original_windows.

What I have done, is set up a software project (with Makefiles etc...) which basically generates .NML files based on the actual graphic sprites and masks found. I used the last "nighltly dev" release from this project which I could find for the graphics files. Now the newest NML compiler is pretty fussy about what kind of graphics you feed into it, in particular mask files. So I spent most of my time actually tweaking mask files: many of those were not 100% correct (wrong size, wrong colours, wrong palettes etc...). The original "create.txt" script posted somewhere in this thread was my original inspiration, although it produces ".nfo" files, whereas I wanted to work with the higher-level and more developer-friendly ".nml" format. Also for replacing e.g. the tram vehicle sprites (The trams themselves come from a .grf named "generictrams"), .nml files are A LOT easier than .nfo files.

So now that I have a basic build architecture set up, it is actually very simple to drop in new or updated .png sprites, and/or masks, and... it might even by worth considering continuing the project ???

I see basically two jobs in that regard:

1. Sorting out the licencing on existing sprites: according to http://jupix.info/openttd/gfxdev-repo/index.php?act=all, that is only really a problem for 17 of the entries... As I understand this is mostly a question of missing "sources" ? (A dubious concept in the case of graphics files imho, but ok)
2. Filling in the missing graphics work. These are the parts I found:
- temperate climate: sports stadium and statue! (I have seen images of the completed statue, but it was apparently never released??). Rail vehicles newer than the T.I.M (aka TGV), Monorail vehicles, Maglevel vehicles, and the valuables car. Maglev tracks. Ships, Canals, locks. The newer generation of aeroplanes (Airtaxi and beyond). Bank. Now I am no graphic artist, but this seems managable to me?
- tropical climate: all rail engines, some cargo cars. Most industries specific to this climate (e.g. water supply, copper mine, ...). Trees.
- arctic climate: all ground tiles with snow, empty, with roads, with rail tracks, level crossing. maglev tracks. a few town buildings are also missing.

Now concerning all the problems around licencing, I am a little nervous about publishing the build project which I currently have. I could release purely the build infrastructure (Makefiles, shell scripts, .pnml stubs etc) and make it GPL but then you would still need the corrected graphics files (I had to fix at least half of all mask files if not more), and those I probably can't simply release given the current licencing situation right?

Any suggestions are welcome on how to proceed. I would really love to see the missing graphics work completed, as this 32bpp extra-zoom set is (to me) really very graphically appealing. And just in case I didn't already say so: thank you very much to all the original artists for producing all this fantastic work!

29.1.2014 small update: by trawling through this thread carefully, I was able to find the statue and temperate bank and integrate them also. Additionally I build the monorail station and level crossing by adding and combining exisiting rail sprites using nothing more than gimp. That's unfortunately just about the limit of my graphics abilities though...

Hi & welcome back!

jimmyb5 wrote: 1. This "32bpp Extra-zoom" effort: it was doing GREAT until an important development architecture change upset a lot of graphics artists here. Furthermore the licencing on the various completed graphics was unclear.
2. zBase, which was started using the newer (post OTTD 1.2) architecture immediately, and also has a clearer licencing situation.

That's basically the current situation, yes. I believe (and hope) though, that every new feature needs a bit time to be properly picked up. zBase definitely took the lead here and shows how things can be done, but I'm confident that we'll see further 32bpp work in the future - especially as IMHO the support directly in NewGRFs makes it easier to support those, though it may be seen more picky in one way, but it needs the grf anyway for any kind of graphics, so it's not more effort to insert there an additional reference to 32bpp graphics..

jimmyb5 wrote: Well being a stubborn developer myself (but without prior experience in OTTD), I set out to try it anyway And after a week of intense working, I think I have something pretty well worth the effort now:

What I have done, is set up a software project (with Makefiles etc...) which basically generates .NML files based on the actual graphic sprites and masks found. I used the last "nighltly dev" release from this project which I could find for the graphics files. Now the newest NML compiler is pretty fussy about what kind of graphics you feed into it, in particular mask files. So I spent most of my time actually tweaking mask files: many of those were not 100% correct (wrong size, wrong colours, wrong palettes etc...). The original "create.txt" script posted somewhere in this thread was my original inspiration, although it produces ".nfo" files, whereas I wanted to work with the higher-level and more developer-friendly ".nml" format. Also for replacing e.g. the tram vehicle sprites (The trams themselves come from a .grf named "generictrams"), .nml files are A LOT easier than .nfo files.

So now that I have a basic build architecture set up, it is actually very simple to drop in new or updated .png sprites, and/or masks, and... it might even by worth considering continuing the project ???

Sure, please do!

The pain with the graphics from the previous 32bp graphics is actually to sort out those which you have no license for. Those which you do have one for - no problem to use them with the license they allow. I don't want to encourage it, on the contrary, but with a bit of entering gray area, you can work with different licenses for code and graphics, even individual graphcs. I'd say combination of GPL and CC-BY, CC-BY-SA are unproblematic, CC-BY-NC is, well, found, too. And the -ND clause would rather be a nogo (also as you would not be allowed to modify them in any way in the first place, it's not advisable to use). So please have a look and use those which will work and can be included without much headache. Just to be kind and safe, it probably is advisable to have some file which documents the licenses of graphics similar to here or here or here.
As to what constitutes source: one gotta work with what one has. And there's nowhere written that 32bpp graphics must have a blender file as source - 32bpp can be created as pixel art and pixel pushing like you described just fine.

jimmyb5 wrote:Now concerning all the problems around licencing, I am a little nervous about publishing the build project which I currently have. I could release purely the build infrastructure (Makefiles, shell scripts, .pnml stubs etc) and make it GPL but then you would still need the corrected graphics files (I had to fix at least half of all mask files if not more), and those I probably can't simply release given the current licencing situation right?

Well, depends. See above Make a list which sprite follows which license and remove those from usage where you have no license or which are released under a no derivative license. Then you're also very welcome to have the project hosted at the DevZone

I don't know what you wrote exactly as source code: I would suggest to create a NewGRF out of the sprites you like (instead of a base set) - NewGRFs are easier to extend and adjust to what you consider nice. And for simplicity you can still resort to sprite replacement where appropriate.

I'm sure there'll be more than a few people who'll appreciate your effort - I surely will.

planetmaker wrote: ... - especially as IMHO the support directly in NewGRFs makes it easier to support those, though it may be seen more picky in one way, but it needs the grf anyway for any kind of graphics, so it's not more effort to insert there an additional reference to 32bpp graphics..

Yes, I would agree. Especially since we can now code grf files in "nml" which is a lot more developer-friendly than "nfo" was. Quite possibly this was a major sticking point at the time of the architecute switch.

planetmaker wrote:

jimmyb5 wrote: ...
So now that I have a basic build architecture set up, it is actually very simple to drop in new or updated .png sprites, and/or masks, and... it might even by worth considering continuing the project ???

Sure, please do!

Well I am useless at graphics work, trust me: I am a developer But I do want to make it easy on the graphics artists who were doing so well here until about mid-2012. If any of these would wish to come back and finish off some of the missing graphics work, I think we could provide a pretty compelling 32bpp graphics set!

planetmaker wrote: The pain with the graphics from the previous 32bp graphics is actually to sort out those which you have no license for. Those which you do have one for - no problem to use them with the license they allow. I don't want to encourage it, on the contrary, but with a bit of entering gray area, you can work with different licenses for code and graphics, even individual graphcs. I'd say combination of GPL and CC-BY, CC-BY-SA are unproblematic, CC-BY-NC is, well, found, too. And the -ND clause would rather be a nogo (also as you would not be allowed to modify them in any way in the first place, it's not advisable to use). So please have a look and use those which will work and can be included without much headache. Just to be kind and safe, it probably is advisable to have some file which documents the licenses of graphics similar to here or here or here.
As to what constitutes source: one gotta work with what one has. And there's nowhere written that 32bpp graphics must have a blender file as source - 32bpp can be created as pixel art and pixel pushing like you described just fine.

Well that is precicely what I have been doing. My project contains a "COPYING" file, which tries to state this situation (which components fall under which copyright). It can be edited and updated to make things clearer, as new artwork is added, or as the licences on existing art are clarified.

Furthermore as (for the moment) the project generates a standalone grf file, there is no requirement that this grf (or its components) follow any particular licence right? Users can decide for themselves what they wish to allow in their games...

planetmaker wrote: I don't know what you wrote exactly as source code: I would suggest to create a NewGRF out of the sprites you like (instead of a base set) - NewGRFs are easier to extend and adjust to what you consider nice. And for simplicity you can still resort to sprite replacement where appropriate.

I'm sure there'll be more than a few people who'll appreciate your effort - I surely will.

Very kind So yes indeed, the project generates a grf file from the source sprites and masks (in png format). I have set up a project on the openttdcoop devzone here, where you can download the code, and the generated grf.

The code currently relies on bash, sed, awk, find etc... so it will only really run on unixlike systems (including linux & mac os x). Running it on windows is probably not possible, although the resulting grf file can of course be used anywhere.

I'm working on graphics for ICS Industrial Stations Renewal 0.9.2 done about 50% > 600 sprites.
http://dfiles.eu/files/iue2qexrl

JRD wrote:I'm working on graphics for ICS Industrial Stations Renewal 0.9.2 done about 50% > 600 sprites.
http://dfiles.eu/files/prxa19i0q

Maybe you should talk to mart3p from the ISR set about that.

It's nice to see this kinda moving again.

I know I pop my head in only very very occasionally here but I'm still stumped by this concern over having source files for the graphics.

Is it really necessary under the license documentation for artwork to have source files provided?

It clearly has to be hugely flexible given artists can just paint things from nothing, or do they need to submit their mood boards and reference inspiration photos so another artist can re-create an asset using the same influences hehe.


Anyway, to my point.

If anyone wants my help to just make sprites I'll happily chip in.

I don't know anything about the back-end and graphics integration into Open TTD but I can (and enjoy) making graphics along these lines. 3DS Max + textures files + whatever else can all be sent.


Just loaded up Open TTD again recently and sad to see this stuff never made it to a fully polished final revision. It looks so amazing even if I'm modelling dustbins or concrete pre-fab 1970's flats I'll be happy!


Cheers

Dave

@ jimmyb5

WOW! you are a legend... those screen prints look fantastic.

I have recently started playing using Zbase, I noticed in your screenshot that you have the 'blocky' rivers that i have, with zbase turned off would you see a nicely rendered version of the opengfx rivers? just interested by your comment that you could use with opengfx.

I have to say, as a newb i have caught on quickly that this community is probably up there with the most dymanic, well run and passionate development teams, the changes that look possible here would bring this game back into our homes. Thank you all!

please clarify though, is your work a continuation of project 1 (32bit zoom) or 2 (zbase) ? or is this a 3rd project?

JRD any news?

relu19 : I'm working on the train set, see my web.

nice, there's anyone who is working on planes ans ships? or maybe buildings? except those made by varivar.
thank you all,
keep up the good work.

JRD I love you station set,and train set, i will wait you for end it,to start new game

JRD wrote:I'm working on graphics for ICS Industrial Stations Renewal 0.9.2 done about 50% > 600 sprites.

Nice stuff! It works well with zbase and various 32bpp trains & vehicles. We can have nice looking extra zoom games with lots of extra material. But I wish more of it could be available through the normal content download system. Zbase is, but everything else 32bpp has to be discovered in the forums and downloaded manually.

I have 32bit grvts, 32bit opengfx trains, and now partial 32bpp ISR. All discovered by chance, and I wonder if there is more that I simply haven't found. It'd be so much easier if all was available through the game.

As far as I know, there are only a couple of 32bpp projects not available via in-game content because they're still in development and the authors haven't deemed them to be ready yet. One of those that you missed is Pikkabird's freshly-released Pineapple Express set.

kamnet wrote:Pineapple Express

Near enough I suppose.

Attention "indstatr_32.grf" in OTTD 1.4.0 does not work correctly !?

screen from 1.3.2


screen from 1.4.0


_________________________

EDIT:

Fixed ! "indstatr_32.grf" is new 0.9.3 version.

what do you mean ? I apparently works well to my