Recap of February 2012 Changes and How To Go Forward

[Jupix]

Situation now:

• Tars no longer work in OpenTTD after 1.1.5, new delivery method is inside .grf files alongside 8bpp sprites
• Graphics are packaged with a new version of grfcodec
• We now know how the final product of the base set conversion project will be packaged and distributed: First alongside the 8bpp OpenGFX+ packages, and finally, alongside the 8bpp OpenGFX proper
• 32bpp versions of existing OpenTTD graphics have a new release process
• The "nightly packages" are now obsolete and the script will be deleted soon
• The jupix.info repository is becoming pointless and will be deleted or repurposed at some point

To artists

Relevant bits to you are:

If you are making conversion graphics, the old standards for graphics still apply:
- Set cohesion
- GPLv2 or compatible
- Sprites for "normal zoom", zi2 and zi4 required
- Sources have to be released with the sprites

Upon release, content will now go through the following release path:

1. Create ticket at the OpenGFX+ issue tracker:
- For aircraft, go here: http://dev.openttdcoop.org/projects/ogf ... issues/new
- For airports: http://dev.openttdcoop.org/projects/air ... issues/new
- For civilian buildings: http://dev.openttdcoop.org/projects/ogf ... issues/new
- For industries: http://dev.openttdcoop.org/projects/ogf ... issues/new
- For landscape: http://dev.openttdcoop.org/projects/ogf ... issues/new
- For RVs: http://dev.openttdcoop.org/projects/ogfx-rv/issues/new
- For ships: http://dev.openttdcoop.org/projects/ogf ... issues/new
- For rail vehicles: http://dev.openttdcoop.org/projects/ogf ... issues/new
- For anything else use the OGFX project tracker: http://dev.openttdcoop.org/projects/opengfx/issues/new

2. Fill in the following info:
- Tracker: Feature Request
- Subject: "32bpp sprites for Ginzu A4 (SETNAME XXXX-XXXX)" or something descriptive like that
- Description as you would have entered in the old repo, AND ALSO, ALIGNMENT INFORMATION (upper left coordinates of sprite within file, width/height, offsets)
- Category: 32bpp
- Files (if you hit a limiter then compress harder and create multiple packages):
* File 1: just a package of sprites for your entry
* File 2: package of sources as you would have been packaging a standard tar
* File 3: license.txt with in which you release your content under GPLv2 or a compatible license

3. Announce your release here: http://www.tt-forums.net/viewtopic.php?f=36&t=46675

4. Your release will get judged according to the standard we've agreed on and if it's ok, will get put in OpenGFX+

5. The ticket you posted supports discussion and revision, therefore the product will mature quite organically at that location.

OpenGFX+ is a collection of graphics and functionality divided into small sets, to make it easier to finish a set at a time. Once those sets are complete, the 32bpp graphics will trickle down to OpenGFX proper. So one day there will be an official OpenGFX release like any other and it will automatically contain your 32bpp sprites.

If you are making a standalone NewGRF, you probably understand what has happened technologically and what you need to do to update your NewGRF from the old format to the new.

For release, you now have two options:
1. Create a thread for your project here at the forums and/or
2. Ask the ottdcoop guys for your own project at their DevZone, which will give you all the infrastructure you will ever need


To admins

The jupix.info repo is becoming obsolete. I suggest you now stop working on stuff that is there.

What we need to do is take content off the old repo that is already release-worthy and correctly licensed (meaning it follows the old standards:
- Set cohesion
- GPLv2 or compatible
- Sprites for "normal zoom", zi2 and zi4 required
- Sources have to be released with the sprites)
and re-release it using the "new process". This needs no artist involvement unless he chooses to do so first. To release someone else's work, follow the process laid out above.

Stuff that needs writing at the wiki:
- Developing 32bpp NewGRFs
- Base set conversion project -> Implementation bit
- Playing with 32bpp graphics - needs a total rewrite


To coders

Coding graphics to work as newgrf's works a bit differently than the pngcodecing we've been using. Yexo and planetmaker have agreed to help us code graphics that enter their badass lair at the OGFX+ DevZone. I suggest that you also learn the ropes as this is the way 32bpp graphics will work from now on.



To players

After OpenTTD 1.1.5, all 32bit graphics that end in .tar will stop working. No matter what you do with the blitter or where you put the graphics they will not work. The new way is .grf files.

If you want to just play the original OpenTTD in 32 bit graphics, then what you will now be doing is installing new versions of OpenGFX+.

Do not take this change as a negative thing, because:

• NewGRFs are the format that we always wanted 32bpp sprites to come in.
• When 32bpp NewGRFs start coming out, there is no longer any game client hacking to get 32 bit gfx to work. They will work outta box. You just download a .grf, and bang, you've got 32bpp graphics.
• We now have developer backing for both our release process and EZ!

At first, content will become available slowly because the standards set by OpenGFX+ are as rigorous as the most rigorous standards laid out in my project spec. Few of our releases so far meet those standards. Once we get our house in order, more content will become available, so stay tuned.

You can always have the latest by downloading the latest OpenGFX+ packages.

[GeekToo]

How to go forward?

I read the question, and it expresses my feelings very exact. The new way of 32bpp graphics loading creates a completely new situation, since all 32bpp graphics are now unavailable to the average user. It also is a perfect moment to ask the QUESTION: how to go forward?

I am totally confused, I am extremely happy that extra zooms made it to trunk. One minute later, I am very sad for the amount of hours that various contributors have wasted to the 32bpp project, because they can not be used at all anymore.
When I look at my own stuff:

32bpp-extra newgrf: Useless now, pngs can not be loaded anymore. Recovery: I created a script: http://www.tt-forums.net/viewtopic.php?p=999939#p999939 that can create a newgrf in the new format, but that is only usable for the geeks. What would be needed is a location where the newgrf could be downloaded for the average user.

32bpp-extra-zoom patch: partially implemented in trunk. EZ-patch still is looking a lot better, but EZ funcitionality is in trunk. Things that really need thought in trunk: animation and company colours: animation, based on palette colours just does not work in 32bpp. Company colours in trunk just look plain ugly, the way to use mask files needs attention. Applying the patch to trunk is not possible anymore, lots of changes, may need a complete rewrite.

My 32bpp grass tar: not usable anymore, has pngs, and not zi2 and zi4 pngs

My (and JoeD) GUi tar: not usable anymore, same reason, non-extra zooms are not listed even anymore (which makes no sense for GUI graphics)

My work on wiki on downloadable Zo or z2 tars: useless

Then, looking at the work of others:
All of Maquinistas newgrf and pngcodec work: useless (well, could be upgraded pretty easy to new situation with some scripting, but now is not reachable),

All of Lord Aro work at the repo: useless, unless converted to newgrf or baseset

All of Jupix's work: none of the work on repo or nightly build is usable.

Sure, it can be repaired, but then again the QUESTION: how to go forward?

IMHO, there is a big gap between what is available on the Jupix repo, and the OGFX+ standard. Actually, only Ben Robbins's work and maybe some other graphics would meet the demands.



So: the QUESTION: how to go forward?

My opinion:

*There are two main graphics dev-streams:
--stuff to go in OGfX
--stuff to be made available as newgrf.

Eg Ben Robbins has created landscape graphics that meets every requirement: all zooms, gpl-2 etc. But there is overlap: landscape with, and landscape without lines. We should decide what is to be included in OGFX, and what to do with the other set. I think OFGX+ is meant for inclusion in OGFX (which would have to be split in more parts: only 8bpp, 32bpp but that would need further splits for the sheer size of the graphics data.

*Who is the lead person for at least OGfX+ project?
*Should 32bpp-extra and OGFXE be merged. 32bpp-extra is only using GPL-2 or what the f*** licences. I paid attention to that from the start, and never included graphics that did not meet that. So everything there could be included pretty fast in OGFX+, but then I hit the all zoom sprites, and source include requirement.

I have several other questions, but this should suffice to at least start a constructive discussion.

[Yexo]

*Who is the lead person for at least OGfX+ project?

Differs per project. In general planetmaker is your best bet, but see the links to all subprojects on http://dev.openttdcoop.org/projects/ogfxplus

*Should 32bpp-extra and OGFXE be merged. 32bpp-extra is only using GPL-2 or what the f*** licences. I paid attention to that from the start, and never included graphics that did not meet that. So everything there could be included pretty fast in OGFX+, but then I hit the all zoom sprites, and source include requirement.

If everything in 32bpp-extra is already GPL, the "source included" requirement should be no problem. If it is, you're not adhering to the GPL. Having said that, I think it makes sense to port everything that was in 32bpp-extra to OpenGFX. After all, that's where you want the sprites to be: in a baseset.
The "all zoom sprites" is more of a nice-to-have. The only requirement is normal zoom graphics, everything else is extra.

[GeekToo]

Thanks Yexo for the reply.

You're right about the source requirement, that could be problematic in some of the sprites in 32bpp-extra.

I think that this: http://jupix.info/openttd/gfxdev-repo/i ... file&id=65 would be a perfect candidate to be included in ogfx+ projects. Source available, gpl-2 licences confirmed. We only would need to use Rubi's script to convert from pngcodeced pngs to newgrf.

[Michi_cc]

Things that really need thought in trunk: animation and company colours: animation, based on palette colours just does not work in 32bpp.

Palette animation works perfectly fine. Select the 32bpp-anim blitter (which is the default OTTD will use when asked via NewGRF Act14 or baseset).

Company colours in trunk just look plain ugly, the way to use mask files needs attention.

Company colours itself are good, but the existing sprites will need more or less rework. Even if the patch algorithm resulted in better quality on average, doing a 100-something line floating point calculation for each pixel is simply wasted time.

-- Michael Lutz

[maquinista]

Company colours in trunk just look plain ugly, the way to use mask files needs attention.

Some of my sprites have a dithered pattern, for example, the factory.

The problem is that not all sprites have it.

Maybe a Imagemagick or a GIMP script could be helpful, but... I don't have idea about how to handle this!

------------------
I have a script that "cleans" the alpha channel of a sprite. It searches the almost-transparent pixels (<15%) and "cleans" them. Then, I adjust the offsets of these cleans sprites with PNG codec. Now, the PNG coded sprites are processed by PNG crop, which cuts the empty areas leaving offsets good. Finally, I use PNG resize to create the Z1 and Z2 sprites.

Well... This is the process that I follow to code vehicles, threes and things which are not attached to the floor.

This script could be helpful to create what I say, but I don't have enough GIMP scripting knowledge to modify it.

This would be the process:

1. Load plain mask.
2. Set mask layer to "colour".
3. Load sprite and place it under the mask.
4. Create a new selection using the alpha channel of mask layer.
5. Invert the selection.
6. Delete pixels of original sprite.
7. Merge these two layers.
8. Convert to indexed with a 8 colours palette (only blue company colours) and using a dithering pattern.
9. Convert back to RGB.
10. Convert now to TTD palette.

This should create a sprite with a dithered pattern.

NOTE: I don't like the GIMP dithering. It has lots of dots with exaggerated colours*. I don't know the reason, but I convert my sprites to Locomotion Palette with Irfanview, which produces smoother results.

*There are eight CC tones. It doesn't have sense to found more of two in a small area which doesn't have a strong colour variation. See these example images of my class 440 sprites converted to Locomotion palette:


This is the result with Irfanview:
https://www.tt-forums.net/viewtopic.php?p=857754#p857754

This is what I got with GIMP, of course, I converted only the rear car and repeated two times for testing purposes:

[Michi_cc]

This should create a sprite with a dithered pattern.

The recolour algorithm in trunk will take the brightness from the RGB part (basically max(R,G,B)) and will use it to modulate the palette colour from the mask. Brightness 64 means no change to the palette colour. This means that in theory you wouldn't need any dithering at all, because you do not need more than one palette colour as long as you vary the RGB brightness accordingly.

-- Michael Lutz

[Jupix]

How to go forward?

I read the question, and it expresses my feelings very exact. The new way of 32bpp graphics loading creates a completely new situation, since all 32bpp graphics are now unavailable to the average user. It also is a perfect moment to ask the QUESTION: how to go forward?

I am totally confused, I am extremely happy that extra zooms made it to trunk. One minute later, I am very sad for the amount of hours that various contributors have wasted to the 32bpp project, because they can not be used at all anymore.

The How To Go Forward question is one that I obviously tried to cover in my initial posting.
It appears I may have at least partially failed.

tbh we have no problem other than the recent diminished flow of content. Lately there was a gap between graphics standards and repo contents anyway - the OGFX+ requires nothing that wasn't required before for the base set conversion. And OGFX+ requires nothing of NewGRFs ... for which there were no requirements before either.

You have to bear in mind that all the work we've done is not in vain even if some sprites are never used again.

It's the same thing as with roadmapping or any strategy. They are helpful when a project is being brainstormed and formed, but as it goes forward, it's not important what steps you take to reach a goal - reaching the goal is what matters.

Building the repo, writing all the stuff that is now irrelevant, creating graphics that are no longer eligible for inclusion as they stand... All were important steps that made the project look more credible and attracted contributions. They showed a glimpse of what a 32bpp OpenTTD might be, which would've not happened had that work not been done. I doubt 32bpp, -ez or 32bpp NewGRFs would be in trunk right now, had it not been for all that work by us.

So: the QUESTION: how to go forward?

My opinion:

*There are two main graphics dev-streams:
--stuff to go in OGfX
--stuff to be made available as newgrf.

That is correct, that is also how I put it in my org paper before the Feb 2012 changes.

Ben Robbins has created landscape graphics that meets every requirement: all zooms, gpl-2 etc. But there is overlap: landscape with, and landscape without lines. We should decide what is to be included in OGFX, and what to do with the other set. I think OFGX+ is meant for inclusion in OGFX (which would have to be split in more parts: only 8bpp, 32bpp but that would need further splits for the sheer size of the graphics data.

IIRC OGFX+ includes both grid versions and no-grid. Therefore Ben Robbins' landscape is even more fitting than you think. The only problem with it AFAIK is that it relies on blitter changes that are not in trunk, therefore make the sprites look weird in trunk builds or something. Haven't tried it so dunno.

*Who is the lead person for at least OGfX+ project?

I suppose that would be planetmaker. Why do you ask? For 9 years the 32bpp graphicsmaking had no lead person at all.
tbh planetmakers efforts are better used in technology rather than acting as a face for 32 bits.

*Should 32bpp-extra and OGFXE be merged. 32bpp-extra is only using GPL-2 or what the f*** licences. I paid attention to that from the start, and never included graphics that did not meet that. So everything there could be included pretty fast in OGFX+, but then I hit the all zoom sprites, and source include requirement.

IMO yes.
The one requirement that is the real problem is the sources one. But you should have it covered already, if it's GPLv2.

I have several other questions, but this should suffice to at least start a constructive discussion.

Fire away.

When I posted the inital posting I listed some wiki articles to be written by admins. Those are some questions that need to be clarified.

It would be mostly my job to write those, but even though this semester's lectures have concluded, I've been hopelessly inundated with non-OTTD32bpp stuff recently; I'm simultaneously writing my Bachelor's Thesis, attending critical exams biweekly, self-studying 3 courses, building my project car, not to mention recent trips to my car club's events. I also try to have time off uni and hobbies for actual zoning out.

[planetmaker]

IIRC OGFX+ includes both grid versions and no-grid. Therefore Ben Robbins' landscape is even more fitting than you think. The only problem with it AFAIK is that it relies on blitter changes that are not in trunk, therefore make the sprites look weird in trunk builds or something. Haven't tried it so dunno.

Indeed. OpenGFX+ Landscape has the option to use tiles w/o border (and that was the main reason for me to create that NewGRF). Thus both versions can be used in that NewGRF very well. OpenGFX itself would get the gridded version unless I find the time to finish the respective OpenTTD patch (but not before summer, I fear).

*Who is the lead person for at least OGfX+ project?

I suppose that would be planetmaker. Why do you ask? For 9 years the 32bpp graphicsmaking had no lead person at all.
tbh planetmakers efforts are better used in technology rather than acting as a face for 32 bits.

Probably right. Though OpenGFX+ is - at least technically - not one project, but many, a collection of different but strongly related NewGRFs. Consider them as linked as, say, the excellent Japan Set. Thus different people can work on different NewGRFs as well. True that I might have my hand to varying degrees in these.

*Should 32bpp-extra and OGFXE be merged. 32bpp-extra is only using GPL-2 or what the f*** licences. I paid attention to that from the start, and never included graphics that did not meet that. So everything there could be included pretty fast in OGFX+, but then I hit the all zoom sprites, and source include requirement.

IMO yes.
The one requirement that is the real problem is the sources one. But you should have it covered already, if it's GPLv2.

I can imagine that e.g. the GUI sprites have no source other than png. So it really needs looking at. We need not be stricter here than with OpenGFX as-is. But if it was rendered from a model, the model is required.

The way I look at OpenGFX and OpenGFX+ projects: consider the OpenGFX+ NewGRFs as staging area for OpenGFX in this respect. If one thing is well covered, it's then easy to copy stuff to OpenGFX.

So what this project needs is
- people who make models and sprites
- people who know to programme NewGRFs

All the sources are public, thus anyone can look, try and get a start at it. Sure enough all help is welcome.

[GeekToo]

Palette animation works perfectly fine. Select the 32bpp-anim blitter (which is the default OTTD will use when asked via NewGRF Act14 or baseset).

No, it does not. Take the water cycle. For 8bpp this is fine, cycle the palette and the water appears to have waves. But for 32bpp, how do you map like 25 shades of blue to 8 colours in the palette?

Company colours itself are good, but the existing sprites will need more or less rework. Even if the patch algorithm resulted in better quality on average, doing a 100-something line floating point calculation for each pixel is simply wasted time.

Don't get me wrong Michi, I did not mean to criticise you or Peter, you did a great job. I know CC is a pain in the ass. I was referring to the current situation, where the masks for the EZ-patch just don't look good in trunk. Which makes me wonder why you would take the max brightness of the mask and the sprite? The EZ-patch, (and I am very well aware of it's flaws, like the hues for some of the CC), took the brightness completely from the sprite, the mask only determined the hue. Which gave problems for CC with the same hue, like gray and white, but was easy for the graphics artists, just give the whole mask the same value, the sprite determines the brightness. Btw, if you're bothered with performance, why do you calculate the recolour for every pixel, iso of making a 32bp-LUT when loading the palette?


@ Jupix: you did not fail in the first post. I completely understood it. But my problem is in the translation of the general concept to specific tasks: what do we do with tars that do not contain sources, or zoom level normal sprites? That would be a large part of the dev-pack. They don't fit in OGFX, but it would be a shame to be lost.
And yes, all our work certainly contributed to inclusion in trunk, I guess we should be proud iso of sad.
The question about lead person: I was just wondering who decides what goes into OGFX, and who can commit. Who decides if it is nml or nfo etc. And I agree that Planetmaker should not be bothered too much with adminastrative tasks, others can do that, where not everyone can do what he can do in nml or nfo or whatever technical stuff.

I promise I now will stop whining about what is lost, and if I have time, make contributions for the new formats, after all that's what we all want: good looking OTTD.

[Alberth]

Don't get me wrong Michi, I did not mean to criticise you or Peter, you did a great job. I know CC is a pain in the ass. I was referring to the current situation, where the masks for the EZ-patch just don't look good in trunk.

I think you are asking the wrong question. Trunk is in general not compatible with any proof of concept patch. In other words, being EZ-compatible was not a design constraint for trunk.
This freedom gives better quality solutions, so I believe it is a good policy.

Talking about problems in trunk while assuming the EZ way of doing things is thus not productive.

I don't know much colours, but the question you should answer is "Can you make good looking CC in trunk today (using any method you can invent)?" (This method is probably different from what EZ did, and also not compatible, it seems.)
If the answer to that question is 'yes', then it is just some work to fix the current sprites. Hopefully an automagic procedure can be created, but even without it, it is solvable.
If the answer to that question is 'no', then please explain the problem, perhaps with a simple example, and file a bug in the FlySpray tracker.

what do we do with tars that do not contain sources, or zoom level normal sprites? That would be a large part of the dev-pack. They don't fit in OGFX, but it would be a shame to be lost.

Indeed it is a shame, but it is the price you pay for not giving enough attention to licensing issues at the start of the project.
Unfortunately, we cannot go back in time, and fix things before they happen.

Assuming people have tried and failed to contact the original authors, my personal opinion is just to delete all of it.

If you keep the sprites around, they might act as a wound that never heals. With every decision in the project you need to think about them as a special case. (New) people will constantly ask for merging the bad stuff with OpenGFX+, try to sneak them back into the project, with all the heated discussions that follow, try to fork the project, and perhaps even add more sprites with bad licenses.
In other words, I see them as a source of constant interference, eating away energy and focus of the project. (Your question is already proof this will happen, I think.)

Deleting all of them will hurt like hell, but it gives a clean break with the past, so everybody can look forward towards the goal of making a colourful base set for trunk without constant bothering about old, incompatible, and basically useless stuff.
It's a waste, it's a shame, it sucks, indeed. But just like burying a dead relative, you have to say goodbye to come to peace with the new situation.



However, I am not involved in the project so it is not my call to make. Also, I have no emotional attachment to any of the sprites, so it is easy talking for me.
I wish you (all of you) luck with the decision.

The question about lead person: I was just wondering who decides what goes into OGFX, and who can commit. Who decides if it is nml or nfo etc. And I agree that Planetmaker should not be bothered too much with adminastrative tasks, others can do that, where not everyone can do what he can do in nml or nfo or whatever technical stuff.

Starting with the latter question, if you want help from Planetmaker, nml will make him happy. That gives you one coder who is not likely to go away any time soon.
Since we are talking base sets here, coding in either nfo or nml is quite comparable, where nml is more likely to move faster to support you.
Last but not least, you were not proposing to switch between nfo and nml as coders come and go, I hope?? If you constantly revert decisions, going forward becomes nearly impossible. (Personally, I believe that new people that say "I want to work in the project, but on my own terms" are more hassle than they are worth. Either they leave before doing anything useful, or they leave after they find not everybody is working in his way. You want people that are willing to adapt their way of doing things to the project, willingness to adapt to the project customs is the first sign of being a useful person.)

With respect to the first part of your question, the people owning OGFX decide, just like any other open source project. As usual, contribute to the project and be a good citizen, and you will get invited too.
It may feel to you like you are giving away control. However, the GPL already states that you don't have control over what you release, and you cannot give away what you don't have in the first place.
Submitting to OGFX has a big advantage, namely others will handle packaging, building newgrfs, and distribution of the sprites.
It means you can concentrate on making the actual sprites, and just dump them in the OGFX tracker.

The nice thing about GPL is that it also protects you. If you totally disagree with what OGFX is doing, you can make a copy of the entire project, and do things differently. The GPL ensures you will have access to everything they do.

Note:
What I find very much missing in all discussions is the question how to mass-produce sprites of ultimate quality?. Discussions of nml versus nfo, or were to dump the sprites, or who commits and who does not, are non-issues until you have 10,000 sprite (-sources) first. People spend large amounts of time preparing for the moment the graphic artist comes walking in, instead of just doing the work, or finding a way to do the work, as a graphic artist is unlikely to be walking in any time soon.

I promise I now will stop whining about what is lost, and if I have time, make contributions for the new formats, after all that's what we all want: good looking OTTD.

I think that's a common goal. Go for it!

Albert

[Jupix]

what do we do with tars that do not contain sources, or zoom level normal sprites? That would be a large part of the dev-pack. They don't fit in OGFX, but it would be a shame to be lost.

I agree, it would be a great shame to just rm -rf all of it, because flawed as it is in some respects, it is our heritage. I always said they don't fulfill the requirements of base set contents; they always were becoming NewGRFs, not actual vanilla game content. So, now they belong as NewGRFs if someone feels like making it happen.

For here and now I'd forget about them, shove them aside and work on a real product first. You can always come back for a side project but the main focus should be a base set replacement.

Like Albert says we need contributors and content now.

[Varivar]

To artists

Relevant bits to you are:

If you are making conversion graphics, the old standards for graphics still apply:
- Set cohesion
- GPLv2 or compatible
- Sprites for "normal zoom", zi2 and zi4 required
.

Are zi2 and zi4 the same as the old z0 and z1? Probably somebody has explained this before, but there's so much talking here that I can't find the answer

[Jupix]

Yep.
zi2 = zoomed in 2x = z1
zi4 = zoomed in 4x = z0

[Rubidium]

what do we do with tars that do not contain sources, or zoom level normal sprites? That would be a large part of the dev-pack. They don't fit in OGFX, but it would be a shame to be lost.

I have made a script that will generate a NewGRF for those tars (or at least tries its best) using ActionA replacement. So most of the current tars can be relatively easily be converted into a usable NewGRF. Yes, it requires a little bit of effort, but one person can do it within a day. The reason I haven't done it is because I rather see stuff being integrated into OpenGFX or proper NewGRFs, and I don't fancy spitting through here trying to find out what can and cannot be legally repacked as that's more or less what my script does. Nevertheless, if it's important to someone, then that someone should invest some time in it.

[GeekToo]

Of course that someone should. Like creating a script that converts the Ben Robbins Ground tar with lines (but could be used for other tars without mask files as well) to a partial nml file. Not finished yet, just showing that I am not only talking, and not working .

Code: Select all

#!/bin/bash
function print_32b_zoomlevel() {
	local idx=$1
	local sprite_nr=$2
	local zoom_level=$3
	
	echo -n "alternative_sprites(block_"
	echo -n $1	
	if [[ $zoom_level -eq 0 ]] ;  then  
		echo ", ZOOM_LEVEL_IN_4X, BIT_DEPTH_32BPP) {"	
	else if [[ $zoom_level -eq 1 ]] ;  then  	
		echo ", ZOOM_LEVEL_IN_2X, BIT_DEPTH_32BPP) {"		
		else 	
			echo ", ZOOM_LEVEL_NORMAL, BIT_DEPTH_32BPP) {"	
		fi
	fi
				
	while [[ $idx -lt $sprite_nr ]] ; do
		local i=$idx"_z"$zoom_level".png" 
		if [[ -f $i ]] ; then
			FOO=`pngcodec l $i | tr ' ' 'n'|grep offs|sed 's/._offs=//;s/^$/0/'|tr 'n' ' '|sed 's/^ //;'`
			printf '[%4s, %4s, "%s"]n' $FOO $i 
		fi
		idx=$((idx + 1))		
	done		
	echo "}"
	echo	
}

function print_block() {
	local idx=$1
	local sprite_nr=$2

	echo -n "replace block_"
	echo -n $1
	echo -n " ("
	echo -n $1
	echo -n -e " "empty.pcx""
	echo ") {"

	while [[ $idx -lt $sprite_nr ]] ; do
		echo "[0,0]"	
		idx=$((idx + 1))		
	done
	echo "}"
	echo
	
	print_32b_zoomlevel $1  $2 0
	print_32b_zoomlevel $1  $2 1
	print_32b_zoomlevel $1  $2 2
}

echo "Constructing NML. This could take a while..."
counter=0
beg_block=-1
prev_spr=-2
sprite_nr=-1
(for i in `ls *.png|sort -n` 
	do 
		sprite_nr=`echo -n $i|sed 's/_z0.png//;s/_z1.png//;s/_z2.png//;'`
		if [[ $sprite_nr -gt $((prev_spr + 1)) ]] ; then
			if [[ $beg_block -ne -1 ]] ; then
				print_block $beg_block $sprite_nr
			fi
			beg_block=$sprite_nr
		fi
		prev_spr=$sprite_nr

		counter=`expr $counter + 1`
	done 
	if [[ $beg_block -ne -1 ]] ; then
		print_block $beg_block $sprite_nr
	fi)	> br_ground_lines.nml

start in a directory with the pngs from the untarred BR ground tiles with lines.

[GeekToo]

Updated the script a bit, and it works! Generates an nml file from an untarred "old" tar.
Sprites from:
http://jupix.info/openttd/gfxdev-repo/i ... file&id=65

nml and nfo attached. Nml probably not perfect, I never coded one.