Log for #openttdcoop.devzone on 2nd March 2012:
Times are UTC Toggle Colours
05:40:49  <Brot6> BANDIT - Revision 332:fbf9e596f378: Codechange: gestalt for tipping trailers now uses Pixa methods (andythenorth) @
05:47:00  <Brot6> BANDIT - Revision 333:2658e88e3ecf: Codechange: cleanup some load state support code (andythenorth) @
06:51:04  *** JVassie has joined #openttdcoop.devzone
07:18:58  *** JVassie has quit IRC
07:33:07  *** Zuu has joined #openttdcoop.devzone
07:40:26  *** andythenorth has joined #openttdcoop.devzone
08:26:28  *** Zuu has quit IRC
08:36:28  *** andythenorth has quit IRC
09:11:46  *** andythenorth has joined #openttdcoop.devzone
09:45:02  *** andythenorth has quit IRC
11:39:12  <Ammler> hmm, nml is gpl-2.0+ ?
11:39:21  <Ammler> is wrong then
11:49:08  <Ammler> planetmaker: about the licenses, maybe we can say, that the license needs at least be osi approved, which cc-by aren't
11:49:31  <Ammler>
11:49:32  <Webster> Title: SPDX Standard Licenses (at
11:50:01  <Ammler> we really sucked at licensing opengfx :-(
11:50:40  <Ammler> but I guess, as excuse this happen before we get part of the managers
11:52:19  <planetmaker> well, OpenGFX is gpl v2. That's quite ok, I think
11:52:26  <planetmaker> Today I'd choose gpl v2+. But well
11:52:44  <planetmaker> and going with osi-approved licenses seems fine to me. Though I'd accept cc-by, too
11:54:30  <Brot6> NewGRF Meta Language - Bug #3766 (New): License not clearly stated as GPL-2.0+ (Ammler) @
11:55:48  <Ammler> the "legal team" of suse found this bug btw. :-)
11:56:11  <Ammler> it seems like the review the source seriously
11:56:18  <Ammler> they*
11:57:14  <planetmaker> <-- so what do I answer? "None of the source codes I have or writes allows to use a 'no derivatives' clause"?
11:57:15  <Webster> Title: Transport Tycoon Forums View topic - [CONCEPT] Locomotion sprites to OpenTTD 32-bit graphics (at
11:58:09  <Ammler> planetmaker: that is up2you, I only care what will be hosted on devzone :-)
11:58:27  <Ammler> but of course you can always change your license of your "onlywork"
11:58:35  <planetmaker> everything I work in NewGRF terms will be hosted on the DevZone ;-)
11:58:50  <Ammler> well, nc-nd is a double nono
11:59:10  <planetmaker> and I'm not interested in the sprites, if I can't use them for OpenGFX or OpenGFX+ tbh
11:59:14  <Ammler> we can allow nc, but for sure no nd
11:59:25  <planetmaker> which was my plan: using them for OpenGFX+ Trains
12:00:04  <Ammler> but we really should be aware more about the + in gplv2 :-)
12:00:10  <planetmaker> thus it's absolutely true that I can't release the NewGRF. It's GPL and it needs the 8bpp sprites which I'm not even sure who drew them.
12:00:35  <planetmaker> well, yes, that's important
12:00:41  <planetmaker> or can be
12:01:28  <Ammler> planetmaker: as the owner of devzone, I would never force you to license something gplv2+, that will always be up to you :-P
12:01:53  <planetmaker> well. you're as much 'owner' of it as I am ;-)
12:02:01  <Ammler> so if you really want, well license it nc-nd
12:02:07  <planetmaker> no, I don't
12:02:23  <planetmaker> and I even may not license a derivative of OpenGFX+Trains as -nc-nd
12:02:29  <planetmaker> I don't own all copyrigh there
12:03:13  <Ammler> well, ask him, how you should do it
12:03:18  <planetmaker> besides I'm really not interested in -nc-nd licensed newgrfs
12:03:31  <Ammler> it would be best, if he comes to same conclusion as you :-)
12:08:09  <Ammler> <-- this should be unsticked
12:08:10  <Webster> Title: Transport Tycoon Forums View topic - 32bpp-extra: a new openttdcoop project! (at
12:14:25  <planetmaker> did you report it?
12:14:37  <planetmaker> I've no authority in that forum
12:15:17  <planetmaker> (even though I think it would make sense to give the openttd devs that in the newgrf forum, too ;-) )
12:18:36  <Ammler> I tried to tell that orudge many times, but ignored :-P
12:19:01  <planetmaker> it's not really important
12:19:09  <planetmaker> after all: it works
12:20:56  <Ammler> yes, but only because I bascially removed subscription on basically every thread
12:21:11  <planetmaker> eh?
12:21:43  <Ammler> well, and because I unsubscribed everywhere, I have no clue, if it is better now :-)
12:21:55  <planetmaker> what's bad?
12:22:34  <Ammler> as said, might be ok now
12:23:14  <Ammler> I do not really read the forums often anymore
12:23:30  <Brot6> Dutch Trains 2.0 - Feature #3746: Coaches (Voyager1) @
12:23:54  <Ammler> and before I mostly read subscribed threads
12:33:09  *** andythenorth has joined #openttdcoop.devzone
15:20:10  <Brot6> Japanese Trains - Feature #3767 (New): Code MUs differently (oberhuemer) @
15:47:45  <Brot6> Japanese Trains - Feature #3767 (Assigned): Code MUs differently (oberhuemer) @
15:47:45  <Brot6> Japanese Trains - Feature #3767 (Assigned): Code MUs differently (dandan) @
15:48:54  <Brot6> Japanese Trains - Feature #3767 (Assigned): Code MUs differently (dandan) @
16:25:51  <Brot6> Dutch Trains 2.0 - Revision 273:08befcdde226: Feature: improved graphics of Lint41/H (graphics by... (foobar) @
17:16:09  <Brot6> nml: update from r1862 to r1867 done -
17:23:52  <Brot6> ogfx-trains: update from r296 to r297 done (48 warnings) -
17:26:09  <Brot6> bandit: update from r326 to r333 done (1 warnings) -
17:28:10  <Brot6> BANDIT - Revision 334:cce0ecfaf9d5: Change: new graphic for Hackler B80 (DanMacK) (andythenorth) @
17:29:08  <Yexo> who wrote some house drawing scripts?
17:29:29  <Yexo> I wonder if those could be used to generate good-enough quality sprites for the extra zoom levels, at least in 8bpp
17:29:38  <Yexo> might be a nice start for ogfx-houses
17:30:42  <andythenorth> zephyris did
17:31:02  <andythenorth> I proved that Pixa could do some building shapes
17:31:07  <andythenorth> but zeph's were far more house like
17:31:21  <andythenorth> although...why not just render?
17:32:25  <Yexo> render what?
17:32:26  <Yexo> Pixa might be interesting too, didn't look too closely at that yet
17:33:26  * andythenorth feels there is a world of free CGI models out there somewhere
17:33:36  <andythenorth> but turbosquid seems not to be that place :P
17:33:50  <andythenorth> are there not bazillions of google sketchup houses somewhere?
17:34:00  <Brot6> cets: update from r650 to r651 done (187 warnings) -
17:34:01  <andythenorth> Pixa will do blocky buildings well
17:34:13  <andythenorth> teaching it to do sloped rooves is probably tmwftlb
17:34:20  <Yexo> not sure if rendering sketchup models will lead to nice sprites
17:34:46  <Yexo> it was more a general idea, don't want to start working on it just now
17:36:14  <andythenorth> I think pixa could be taught to intelligently scale
17:36:19  <andythenorth> perhaps not by me though
17:36:54  <andythenorth> I think it maybe could use interpolation to scale up quite well
17:37:15  <Brot6> dutchtrains: update from r272 to r273 done (4 warnings) -
17:37:53  <Terkhen> I'm checking the 32bpp forum, specifically the february recap post, awesome :)
17:38:23  <Terkhen> I should work in opengfx+ road vehicles again
17:39:07  <Brot6> britrains: update from r20 to r21 done (2 warnings) -
17:43:08  <Brot6> OpenGFX+ Road Vehicles - Feature Request #3544 (Assigned): FS#4975 - Buses engine's power (Terkhen) @
17:44:01  *** ODM has joined #openttdcoop.devzone
17:51:44  <andythenorth> anyone got experience handling pngs with alpha using PIL?
17:52:00  * andythenorth is about to try
17:53:18  <Brot6> NewGRF Meta Language - Bug #3765 (Closed): NML builds faulty OpenGFX+ Trains (r297) (planetmaker) @
17:53:18  <Brot6> NewGRF Meta Language - Revision 1868:f6004fbb4192: Fix #3765 r1833: some bytes intended for the d... (yexo) @
17:53:18  <Brot6> NewGRF Meta Language - Bug #3765 (Closed): NML builds faulty OpenGFX+ Trains (r297) (yexo) @
17:53:21  <andythenorth> wondering if I need to give it RGBA or such
17:53:40  <Yexo> internet in the train is good for some things :)
17:54:02  <Yexo> planetmaker: not yet verified whether it works in openttd, but grfcodec decodes it correctly now
17:54:25  <Yexo> andythenorth: yes, nml loads rgba png's just fine
17:54:33  <Yexo> at least I think it does, haven't heard any complaints yet :p
17:54:39  <Hirundo> andythenorth: image mode is "RGBA" IIRC
17:55:01  <Yexo> in "RGB" mode every pixel is a tuple with 3 integers, in "RGBA" mode the tuple simply has 4 values
17:55:07  <Yexo> easy as that :)
17:55:14  <Hirundo> ^exactly
17:58:10  <andythenorth> k
17:58:21  <andythenorth> so I'd need to export RGBA pngs from photoshop, not paletted
17:59:09  * andythenorth wonders how paletted support alpha anyway
17:59:25  <andythenorth> does work for web graphics afaik
17:59:43  <Hirundo> you might have a RGBA palette
18:00:05  <Yexo> paletted just means that for every pixel an index in some palette is stored
18:00:21  <Yexo> each palette entry can be RGB, RGBA or whatever else you want
18:00:28  <andythenorth>
18:00:29  <Webster> Title: Intro to PNG Features (at
18:00:37  <andythenorth> the pixel just gets an extra component
18:00:42  <Yexo> in openttd's context it's usually an 8bit RGB palette (where the exact colors are strictly defined)
18:01:12  <Brot6> Dutch Trains 2.0 - Feature #3768 (New): NID & mDDM (Voyager1) @
18:01:53  <andythenorth> the context here is compositing (imagine pasting steel coils onto a truck)
18:02:08  <Yexo> oh, seems it works a little bit differently. The palette still contains RGB information but each pixel has "palette index + alpha"
18:02:18  <andythenorth> I could ignore alpha and just not draw any pixel that is blue
18:02:58  <Yexo> if the source is already in the properly palette, just don't draw pixels with palette index 0
18:03:09  <Yexo> if the source is RGBA, use the alpha channel information
18:03:42  <andythenorth> +1
18:04:03  <andythenorth> tonight's fun project  :)
18:04:31  <Yexo> hehe :)
18:06:08  <andythenorth> coding Pixa is the most ottd fun I've had in a while
18:06:23  <andythenorth> reminds me of when my job was coding flash games
18:10:40  <andythenorth> maybe I can get the images straight out of a psd with the alpha
18:11:20  <Yexo> my train is arriving :)
18:11:22  <Yexo> bye
18:11:43  <andythenorth> bye
18:13:46  <andythenorth> is it ok to rely on psds?
18:13:59  <andythenorth> from an open-ness point of view?
18:14:14  <andythenorth> I kind of do anyway, so I guess it's a moot point :P
18:27:24  *** Zuu has joined #openttdcoop.devzone
18:34:19  <Brot6> make-nml: compile of r0 still failed (#3730) -
18:43:27  *** frosch123 has joined #openttdcoop.devzone
18:54:16  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-industries (Diffsize: 127099), firs (6 warnings), opengfx, foobarstramtracks (Diffsize: 28769), manindu (Diffsize: 2), newgrf_makefile (Diffsize: 1), rust (15 warnings) (Diffsize: 6813), dutchtramset (21 warnings) (Diffsize: 20613), swisstowns (Diffsize: 51), dutchroadfurniture (Diffsize: 165910), spanishtowns (Diffsize: 8), frenchtowns
18:54:16  <Brot6> (Diffsize: 21), ogfx-rv (42 warnings) (Diffsize: 20398), ogfx-landscape (2 warnings) (Diffsize: 31742), swedishrails (Diffsize: 9075), german-townnames (Diffsize: 5042), dach (104 warnings) (Diffsize: 25201), belarusiantowns (Diffsize: 72), indonesiantowns (1 warnings) (Diffsize: 350), airportsplus (Diffsize: 1161)
19:02:35  <andythenorth> so what is gimp doing for opengfx?
19:02:52  <andythenorth> and do you want to test this psdparser thing?
19:02:59  <andythenorth> np if busy / not interested...
19:03:47  <Terkhen> what is psdparser?
19:04:07  <andythenorth>
19:04:08  <Webster> Title: jerem/psdparse ยท GitHub (at
19:04:34  <andythenorth> it appears to be a (mostly) complete python module to read psd layers
19:04:44  <andythenorth> it worked with the one psd I've tested it upon
19:05:35  <andythenorth> I mention as gimp seems to be a limiting step for compile performance
19:05:39  <Terkhen> nah, it requires coding
19:06:43  <Terkhen> but yes, gimp is annoyingly slow
19:06:54  <andythenorth> no guarantee that this other thing isn't too
19:07:13  <andythenorth> although there might also be php or perl modules for psd parsing
19:07:16  <andythenorth> or some flavour of c
19:08:45  * Terkhen would prefer a simple console application to include it inside the existing makefile framework
19:09:36  <andythenorth> python wrapper around psdparser and PIL
19:09:42  <andythenorth> probably not hard
19:09:47  <andythenorth> but I don't know the use case
19:10:40  <planetmaker> andythenorth: a psd parser won't help with gimp source files
19:11:17  <andythenorth> are they convertable?
19:11:18  <planetmaker> gimp exports layers from image files to other files
19:11:18  <andythenorth> hmm
19:11:26  <andythenorth> is gimp psd support read only?
19:11:36  <planetmaker> gimp can import psd, not sure whether it can write
19:12:58  <andythenorth> not sure PIL can work with xcf (are your files xcf?)
19:23:27  <frosch123> btw... did someone already check whether gimp can handle layers with rgb and paletted data in the same picture?
19:23:40  <frosch123> would be useful for rgbam stuff :)
19:28:35  <planetmaker> I didn't find such option so far
19:28:48  <planetmaker> the palette stuff seemed to work on all layers simultaneously
19:28:55  <planetmaker> but maybe I missed so far
19:29:13  <planetmaker> andythenorth: yes, the files are xcf. PIL's support for that is poor
19:29:34  <frosch123> yeah, that's what i remembered as well
19:30:02  <frosch123> are your scripts able to extract layers with specific names?
19:30:45  <andythenorth> hmm
19:31:04  <andythenorth> is the gimp slowness a non-problem anyway?  how often is it run?
19:31:25  <frosch123> quite often after make clean :p
19:33:29  <andythenorth> I'm not sure if a PIL route would be any faster
19:33:36  <andythenorth> it's ~7s to generate 36 spritesheets atm
19:38:38  <andythenorth> although that's completely meaningless as the problems are different :P
19:44:10  <frosch123> hmm, there are "xcftools", which is said to be a command line tool that can extract layers from gimp images
19:44:30  <frosch123> my package manager knows it
19:59:22  *** ODM has quit IRC
19:59:39  *** ODM has joined #openttdcoop.devzone
20:00:16  <andythenorth> frosch123: xcftools appears to be designed for this purpose
20:00:17  <andythenorth>
20:00:18  <Webster> Title: Henning Makholm's software (at
20:00:35  <frosch123> andythenorth: i am already trying to put it into the ogfx makefile
20:01:10  <frosch123> it contains a tool to list the names of layers as well as extracting single layers
20:01:19  <frosch123> but i guess it won't be able to handle psd
20:01:27  <frosch123> though py-imaging is said to handle psd
20:02:07  <andythenorth> orly? :)
20:02:12  <andythenorth> I'll look at that
20:02:22  <andythenorth> pyparser handles at least 1 psd so far :)
20:02:43  <andythenorth> oh py-imaging is just a synonym for PIL
20:03:04  <andythenorth> PIL handles psd read only, it can seek to layers, but seems to have trouble actually getting useful image data out of them
20:03:44  <andythenorth> it can handle the composite 'flat' image of all layers fine from a psd
20:06:25  <frosch123> imagemagick might also be a try
20:08:44  * andythenorth reads
20:09:52  <frosch123> hmm, how does the ogfx build process work...
20:10:06  <frosch123> the *scm look generated, but they are tracked by hg
20:13:54  <planetmaker> frosch123: the script only is able to operate with layer names
20:14:10  <planetmaker> the scm are tracked?
20:14:25  <frosch123> hg purge did not remove them
20:14:41  <andythenorth> hmm, google suggests imagemagick is meant to be 'better' than PIL.  But it's not clear what the criteria are :P
20:14:42  <frosch123> nor did maintainer-clean
20:14:44  <planetmaker> hm... maybe I added them so that building w/o generating everything works
20:14:46  <planetmaker> probably
20:15:03  <frosch123> maintainer-clean removes the generated pngs
20:15:06  <frosch123> but not the scm
20:15:09  <planetmaker> but maintainer-clean should delete the scm
20:15:35  <frosch123> hmm, it did...
20:15:48  <frosch123> oh, hmm, does hg purge maybe skip ignored files?
20:16:14  * frosch123 is confused
20:18:04  <frosch123> ok, anyway, apparently i need to process the xcf2png with xcftools
20:18:18  <frosch123> and ogfx only generates stuff from xcf, not from psd
20:18:28  <frosch123> so, psd is no trouble
20:19:16  <andythenorth> psd is of interest to me, not ogfx :)
20:19:26  <andythenorth> I conflated the issues slightly :P
20:19:51  <frosch123> ogfx contains psd as well, but they are not involved in the build process
20:19:52  <planetmaker> with xcftools?
20:20:17  <planetmaker> gimp is uses on the scm. And the scf2png is a handwritten file
20:20:26  <frosch123> planetmaker: a package that can extract layers from xcf files
20:20:35  <frosch123> i am trying to remove the gimp dependency from ogfx
20:20:43  <frosch123> and use xcftools instead
20:20:48  <frosch123> and then see how much faster it is
20:20:51  <planetmaker> xcftools was something I recall testing
20:20:59  <planetmaker> For instance I couldn't compile it
20:21:14  <planetmaker> on my machine. Which made it quite unattractive... iirc
20:21:24  <frosch123> it's known by the debian package manager
20:21:31  <frosch123> so seems to be an osx issue
20:21:38  <planetmaker> and it's another dependency which gimp is replaced by and which is much harder to get by
20:21:52  <planetmaker> hm, it's in debian?
20:21:56  <frosch123> yes
20:22:19  <frosch123> i would not have bothered with some random thing found on the webs :)
20:22:44  <frosch123> no idea whether it is in suse
20:26:06  *** Rubidium has joined #openttdcoop.devzone
20:26:38  <planetmaker> ok, I'll have to check out that tool then again
20:26:41  <planetmaker> I guess
20:27:50  <andythenorth> hmm
20:27:58  <andythenorth> other people report compiling xcftools for mac
20:28:07  <andythenorth> I didn't try yet though
20:28:59  <planetmaker> ok, maybe I've faulty memory. It's known to happen
20:29:47  <andythenorth> I remember you tried stuff
20:30:04  <andythenorth> I've just discovered the seashore OS X app I installed to read xcf files at that time :P
20:30:15  <planetmaker> :-D
20:30:44  <andythenorth> and I guess you don't want to be dependent on layered psds
20:32:25  <frosch123> he, i found a bug in ogfx
20:32:33  <planetmaker> hm?
20:32:41  <Rubidium> what did I do wrong? ;)
20:32:47  <frosch123> my makefile aborts with "xcf2png: The image has no layer called 'GridTropical'"
20:32:55  <frosch123> and indeed there is a typo in the layer name
20:33:03  <frosch123> so, what does the current build process do?
20:33:23  <frosch123> the name in the xcf is "GridTropcial"
20:33:55  <planetmaker> oh
20:35:02  <planetmaker> I guess it should be fixed in the xcf. But... why does it build for me?
20:35:08  <planetmaker> or the devzone?
20:35:44  <Rubidium> cause gimp "silently" ignores it?
20:37:08  <frosch123> there is no GridDesert either
20:38:49  <frosch123> <- a bit hacky (since i still use the scm, though they do not really have a purpose anymore), but fast
20:39:21  <frosch123> the layer extraction takes less than a second
20:39:28  <frosch123> nml is slowest now :p
20:42:11  <Rubidium> yep, it's definitely faster
20:42:20  <Rubidium> is the resut the same?
20:42:52  <frosch123> <- result of tip + diff
20:42:52  <Rubidium> so next step'll be: make nml that much faster ;)
20:43:14  <frosch123> does someone still have a build from gimp?
20:43:23  <frosch123> so i do not have to rebuild it? :)
20:43:35  <Rubidium> the CF?
20:44:13  <Rubidium>
20:44:30  <frosch123> extra is different
20:44:35  <Rubidium> tropical and extra differ
20:44:46  <frosch123> well, tropical is the bug i fixed
20:44:49  <Rubidium> possibly the M
20:44:53  <frosch123> hmm, maybe extra as well
20:44:59  <andythenorth> :o imagemagick looks insanely full featured
20:45:08  <frosch123> yes, sure, i fixed the rivers, so i changed extra
20:45:21  <frosch123> andythenorth: imagemagick is a big mess
20:45:36  <frosch123> but if it works, it works
20:46:30  <Rubidium> frosch123: I'll try a build without the Makefile change
20:47:13  <andythenorth> I'll stick with PIL :)
20:48:23  <frosch123> planetmaker: btw. the xcf2png files contained the parameters for xcf2png in just the right order :)
20:48:51  <planetmaker> does there have to be an order?
20:48:52  <frosch123> eugh...
20:49:08  <frosch123> only now i notice that they are called the same... xcf2png
20:49:21  <frosch123> planetmaker: i just prepend a "xcf2png -o"
20:49:26  <Rubidium> tropical has the same md5sum as you got when built with gimp
20:49:42  <frosch123> "-o" is followed by the output filename, then comes the xcf filename, and then the layer names
20:52:34  <Rubidium> xcf2png seems to yield the exact same result as gimp
21:00:31  <planetmaker> if it's really that much faster... it's definitely worth it
21:01:41  <Brot6> OpenGFX - Bug #3769 (New): waterfeatures.xcf2png references wrong layers (frosch) @
21:02:08  <frosch123> ^^ the bug with the typo is obvious, but i have no idea how the desert grid is supposed to be
21:03:22  <frosch123> devzone uses suse, doesn't it? does suse know xcf2png?
21:07:29  <Rubidium> xcf2png: real    0m0.012s
21:07:35  <Rubidium> (for a single png)
21:07:52  <Rubidium> sprites/png/trees/temperate/tree_wide_01_leaf.gimp.scm in this case
21:08:34  <Rubidium> gimp: real    0m1.843s
21:08:55  <Rubidium> for xcf2png I took the longest of 4 runs, for gimp I took the shortest of 4 runs ;)
21:10:28  <frosch123> how unfair :p
21:10:45  <Brot6> SuperLib - Revision 52:c8e972fd480a: Remove: unused variables (Zuu) @
21:10:46  <Brot6> SuperLib - Revision 53:6441a5468884: Feature: Functions for storing data in vehicles/stations (or... (Zuu) @
21:11:49  <Rubidium> yeah, 150 times faster vs 200 times faster (average of xcf2png was a little over 9);)
21:12:24  <Rubidium> with a deviation of like 30% ;)
21:12:40  <Rubidium> the gimp ones were (relatively) much closer
21:14:11  <michi_cc> planetmaker: I tried compiling xcf2png on cygwin just out of curiosity, and I had to apply the debian patches to get it to work, so maybe you have to do that for OS X as well.
21:14:27  <Brot6> SuperLib - Revision 54:2309bfa95d8e: Fix: Forgot to commit the actual new source file (Zuu) @
21:14:29  <frosch123> lol
21:14:46  <frosch123> so, it is maintained by debian :p
21:15:46  <michi_cc> Well, it's only two important patches, one is for libpng14+ (so not needed if you still have 1.2) and the other fixed some makefile problem with libs.
21:19:43  <Ammler> planetmaker: gimp supports export to psd, as foobar worked on ogfx, we agreed to save gimp files as psd
21:20:59  * frosch123 would have suggested the convert all psd to xcf just for the better build process
21:22:29  <Ammler> also if another tool needs first building, I would stay with gimp as tht is part of standard repos on the known distros :-)
21:23:00  <Ammler> or it could be part of nml
21:23:03  <frosch123> xcf2png should at least be an alternative to gimp
21:23:24  <frosch123> and it is part of the good distros :p
21:24:01  <frosch123> debian and gentoo have it
21:24:18  <Rubidium> and fedora
21:24:31  <Ammler> what is package name?
21:24:36  <frosch123> xcftools
21:24:36  <Rubidium> xcftools
21:24:49  <Rubidium>
21:25:13  <Ammler> well, that des not exist on suse
21:26:08  <Rubidium> though the question is whether an at least factor 200 speedup of image creation is wanted or not (and the ability to run it on all cores at once)
21:26:27  <Rubidium> thus speeding it up even more
21:26:45  <frosch123> Rubidium: the makefile can check for both xcf2png and gimp
21:26:52  <frosch123> and use whatever it available
21:27:13  <frosch123> so, the proper distributions can build fast :p
21:27:23  <Rubidium> there is one caveat...
21:27:38  <Rubidium> ... xcf2png results in different PNGs (binary) than gimp
21:27:42  <Ammler> why not use psd and the tool andythenorth suggested?
21:28:05  <frosch123> because it is only a suggestion yet?
21:28:13  <Rubidium> Ammler: because that's a proprietary format?
21:28:23  <Ammler> yes, but a python script might be easiesr
21:28:41  <Ammler> coud be included to nml
21:28:47  <frosch123> didn't andy said the python thingie does not work with psd?
21:29:06  <Ammler> I thought, it doesn't with xcf :-)
21:29:07  <michi_cc> psdparser seems to be even more obscure than xcftools, can't find it in debian for example.
21:29:14  <frosch123> (i thought you were refering to imagemagick)
21:29:55  <Ammler> michi_cc: it is just script using pil, afaik
21:31:11  <Rubidium> anyhow... you'd be choosing between
21:31:39  <Rubidium> a) a proprietary format with a random person that tried to understand said format and wrote some script for it
21:31:52  <Rubidium> b) an open format with a tool written by the author of the format
21:34:18  <Ammler> I would chose b :-P
21:34:52  <michi_cc> Get suse to carry xcftools then, even debian can do it :)
21:35:10  <Rubidium> also, if you are so vocal about "only" allowing GPL (or other free stuff) on your server, why would you allow a non-free format in favor of a closed/proprietary format?
21:35:12  <Ammler> ah, that would be no big deal
21:35:19  <andythenorth> psdparser is a non-supported tool
21:35:35  <andythenorth> with only two contributors and no distributions
21:36:18  <Ammler> michi_cc: specially if fedora has it, it is mostly easy to copy the spec
21:36:25  <andythenorth> I'm dubious about using psdparser even during graphics generation
21:37:08  <andythenorth> I might try it anyway
21:37:33  <Ammler> xcftools might also be able to handle psd maybe
21:37:46  <andythenorth> no.  xcf only afaict
21:38:08  <andythenorth> you'd script gimp to do the psd, then xcftools to get the layers out
21:38:10  <andythenorth> maybe
21:38:23  <frosch123> Ammler: no, it can only handle xcf
21:38:26  <frosch123> i tried it :)
21:38:38  <Rubidium> just convert psd to xcf once
21:38:59  <andythenorth> how many loading states are needed for a vehicle?
21:39:00  <andythenorth> 3?  4?
21:39:10  <andythenorth> I could template for n, but it's tmwftlb
21:39:15  <andythenorth> I need to pick a number...
21:39:49  <frosch123> with extra zoom you might need more :p
21:40:13  <frosch123> anyway, it depends on the loading speed and capacity of your vehicle
21:40:29  <frosch123> it makes no sense to define more graphics than the vehicle will usually take cargo for
21:42:05  <andythenorth> ach, I'll pick 4 :)
21:43:08  * Rubidium ponders whether/how/where to continue with refactoring the sprite sheets of opengfx
21:44:25  <andythenorth> write a PIL script to detect blue boxes, then make each one a png :P
21:44:31  <andythenorth> perhaps not entirely helpful
21:44:42  <andythenorth> "PNG is pronounced ping"
21:44:45  <andythenorth> how stupid
21:45:28  <frosch123> andythenorth: considering terrain.xcf with its about 50+ layers, ogfx seems to take a different approach :)
21:47:24  <Rubidium> actually, for terrains you should be able to generate all (clear) sprites from ~40 sprites
21:47:39  <Brot6> BANDIT - Feature #3684 (Rejected): Draw box trailers to various lengths + styles (andythenorth) @
21:47:39  <Brot6> BANDIT - Feature #3689 (Rejected): Draw pup version of trailer (andythenorth) @
21:47:41  <planetmaker> well... yes, maybe
21:47:45  <Rubidium> or even less if you use recolouring
21:48:03  <planetmaker> might actually be nice.
21:48:09  <andythenorth> recolouring ftw
21:48:34  <Rubidium> then... 10 sprites (5 generic, 5 toyland) and 10 recolourings
21:48:52  <planetmaker> The xcf as they are, are created for two reasons: easy grid + no grid versions. And easy overlay with shores, rivers, infrastructure, canals etc
21:48:59  <planetmaker> thus the latter match the ground
21:49:38  <Brot6> SuperLib - Revision 55:d6b6c4bb8097: Add: Initial support for building airports for industries (Zuu) @
21:49:39  <Brot6> SuperLib - Revision 56:85775c1fe829: Add: Functions to find char or string in a string from the back (Zuu) @
21:49:39  <Brot6> SuperLib - Revision 57:8086c6510fbf: Fix: ReadStrFromObjectName didn't work. Also relocate code t... (Zuu) @
21:49:40  <Rubidium> hmm, more recolorings actually, although you could construct the intermediate recolourings from the "empty" and "full" tile recolourings
21:49:53  <planetmaker> For the sake of generating the ground sprites along, it's not worth it. The important thing is the composition with the overlays
21:49:57  <planetmaker> *alone
21:50:23  <Rubidium> planetmaker: yes, these generated sprites should then be the base for further composition
21:51:23  <andythenorth> could generate gridlines / no gridlines
21:51:43  <Rubidium> however, what annoyed me was that I was seeing the same sprites over and over again as underlying layer
21:51:50  <frosch123> andythenorth: ogfx already does so
21:52:05  <Rubidium> being copied over and over again making it very hard to change the ground tiles reliably
21:52:17  <andythenorth> same problem I have in my sets
21:52:58  <planetmaker> Rubidium: well, mostly I contained it to two files meanwhile: terrain.xcf and infrastructure.xcf
21:53:07  <planetmaker> and indeed, that copying annoyed me quite a lot
21:53:28  <planetmaker> missing basically is the use of the ground tiles in some industries and houses
21:53:47  <Rubidium> planetmaker: what about the sprite sheets I recently extracted from terrain04.png?
21:54:07  <planetmaker> you mean the ground tile refactoring?
21:54:21  <Rubidium> yep
21:54:22  <planetmaker> yes... it had not been ported to OpenGFX itself
21:54:32  <frosch123> ah, rb made that insane xcf? :)
21:54:41  <Rubidium> frosch123: hell NO
21:54:45  <planetmaker> :-D
21:55:08  <planetmaker> I basically created and expanded the xcfs where they saved work for me
21:55:33  <Rubidium> and I'm seeing the same with the infrastructure
21:55:35  <planetmaker> But I did not spend an aweful lot of time on replacing the existing sprites while they are the same.
21:55:44  * andythenorth hasn't opened these there a predictable grid structure? 
21:55:54  <andythenorth> i.e. would it be trivial to composite with PIL?
21:55:56  <frosch123> look at terrain.xcf
21:56:10  <frosch123> xcf2png does the composition
21:56:10  <Rubidium> the terrain one is almost predictable
21:56:27  <Rubidium> there are two places where there should be 1 extra pixel between the sprites
21:56:36  <Rubidium> then it'd be spaced nicely everywhere
21:57:16  <andythenorth> hmm
21:57:21  <andythenorth> my xcf view is frankly shit
21:58:05  <andythenorth> I'll have to get gimp or such
21:59:01  <Rubidium> @calc 19*8
21:59:01  <Webster> Rubidium: 152
21:59:27  <andythenorth> anyway compositing images is pretty trivial with PIL
21:59:35  <andythenorth> on my todo list for Pixa is:
21:59:52  <andythenorth> - opening a bitmap and convert it to Pixa sequence
22:00:02  <andythenorth> - automatically knock out any blue when pasting
22:00:03  <Rubidium> the 152 field sprites can be generated with 6 sprites (1 flat, 4 steep, 1 hay bale) and 8 recolourings
22:00:16  <andythenorth> - utility to make it easier to define colour transforms
22:00:33  <planetmaker> yep, they can. And it would probably make sense to use such thing
22:01:49  <Rubidium> @calc 28*19+4*4
22:01:49  <Webster> Rubidium: 548
22:02:06  <Rubidium> wow... 700 terrain sprites
22:03:27  <Rubidium> 6 field, 5 normal, 8 rough, 5 rocks, 5 toyland -> 29 sprites
22:04:09  <Rubidium> and some 40 recolourings and we're done
22:04:24  <Rubidium> only 10% of the sources needed
22:06:49  <Rubidium> then 12 road tiles (x5 for pavement/desert/toyland) can be used to construct all road tiles
22:07:28  <Brot6> BANDIT - Feature #3770 (New): Setup Pixa gestalts to draw cargo sprites (andythenorth) @
22:09:12  * andythenorth looks at the terrain tile pngs
22:09:20  <andythenorth> are the recolourings so simple?
22:09:52  <Rubidium> it definitely feels that way
22:10:07  <andythenorth> the fields look quite...drawn
22:10:57  <andythenorth> if the artists have intervened, and drawn new pixels, instead of just used flood fill....recolouring won't work :|
22:11:11  <andythenorth> hmm
22:11:17  <andythenorth> photoshop -> diff layers
22:11:39  <frosch123> i don't think the recolouring would work for extra zoom sprites
22:11:48  <frosch123> grass just looks different than snow
22:12:15  <frosch123> though snow/desert and arctic/tropic/temperate grass might work with recolouring
22:12:19  <andythenorth> so field 08 and field 18 are different pattern :(
22:13:04  <Rubidium> andythenorth: the fields should have the same pattern with different colours
22:13:09  <planetmaker> andythenorth: I'm sure that the fields are somewhat recoloured. It's Zeph's work
22:13:11  <andythenorth> they don't
22:13:12  <Rubidium> the problem is that they aren't always
22:13:19  <andythenorth> artists :P
22:13:31  <andythenorth> engineers should make the art
22:13:51  <planetmaker> Grass, desert, snow are different textures, thus no re-colouring. But the grass in all three landscapes: yes
22:14:19  <Rubidium> planetmaker: why can't they have the same base texture with different recolouring?
22:14:21  <planetmaker> well... fields and same pattern, different colour: The stuff grows...
22:14:41  <planetmaker> Rubidium: you now mean desert and grass and snow?
22:14:50  <Rubidium> planetmaker: yes
22:14:58  <planetmaker> it has a different 'granularity' or roughness
22:15:37  <andythenorth> frosch123: snow is indeed different to grass in original game
22:16:12  <Rubidium> might be solved by recolouring where you squash colours together in a fancy way; going from 200 colours -> ~10?
22:16:32  <Rubidium> otherwise it's 10 sprites extra ;)
22:16:50  <andythenorth> also arctic and temperate grass are also different :o
22:16:59  <Rubidium> though it complicates bare -> arctic
22:17:21  <Rubidium> which you'd then need to composite in some manner with masks
22:17:53  <Rubidium> though... then you could use these masks for the other transitions as well reducing the number of recolour sprites
22:18:31  <planetmaker> well, the texture of the grasses could well be the same, just recoloured. No problem there IMHO
22:19:04  <andythenorth> the fields would be trivial to do
22:19:15  <andythenorth> layer 1 is brown
22:19:19  <andythenorth> layer 2 is the grass
22:19:44  <andythenorth> for each growth state, draw more / less of the green pixels in layer 2
22:19:47  <andythenorth> ignore the others
22:19:52  <andythenorth> you get more or less grass
22:20:06  *** ODM has quit IRC
22:21:27  <andythenorth> afaict bare is just a recolour of temperate grass
22:25:03  <andythenorth> also....zeph did a pretty awesome job on the terrain tiles ;)
22:25:27  <Rubidium> andythenorth: that's basically the idea of the mask; just let pixels XYZ of the lower layer "shine" through
22:25:44  <andythenorth> treat it as a knockout mask
22:26:29  <andythenorth> if the tiles were drawn in false colour it would be trivial
22:26:55  <andythenorth> if you have 8 colours in final result, draw in 16
22:27:03  <andythenorth> some are knocked out as needed
22:27:11  <andythenorth> some are merged down to one colour
22:27:26  <Rubidium> yep, also possible
22:27:30  <andythenorth> but the drawing is already done :P
22:27:32  <Rubidium> requires more recolour masks
22:27:56  <Rubidium> though you'd need 4 times the colours compared to the ones currently used
22:27:58  <Zuu> Yexo: Did you forget the AIOrder.AIOF_* flags when you removed the "AI" prefix to enum flags?
22:28:36  <Zuu> Eg is it a bug that there exist GSOrder.AIOF_TRANSFER
22:28:54  <andythenorth> it's basically what the function on l4 here is doing:
22:29:03  <andythenorth> draw stuff, or not draw stuff
22:29:49  <andythenorth> I'd probably do it differently for the tile case
22:29:53  <planetmaker> fields also need a ripe stage and a harvested stage. Which kinda is Earth again
22:30:45  <andythenorth> one thing that can be done with Pixa-style is, rather than pure compositing, use one image as a set of control codes to draw in another image
22:31:10  <andythenorth> so you might always draw over the base earth
22:31:31  <andythenorth> picking n colours from a grass layer
22:34:49  <andythenorth> I'm not sure you gain much for existing 8bpp opengfx
22:35:03  <andythenorth> but maybe if 32bpp is being added....
22:35:28  <andythenorth> you gain maintainability at the cost of complexity
22:35:35  <andythenorth> but who needs to maintain grass tiles anyway? :P
22:37:40  <andythenorth> hmm
22:37:52  <andythenorth> but rocks and such seem like a clear case for compositing at least
22:38:41  <andythenorth> and shore tiles :o
22:41:06  <andythenorth> ugh
22:41:12  * andythenorth discovers infra08.png
22:41:23  <Rubidium> andythenorth: discover infra06 as well
22:41:41  <andythenorth> yeah
22:41:51  <andythenorth> so....did I mention I've written a pixel generator? :P
22:41:56  <Rubidium> also discover terrain04.png in somewhat older versions of opengfx
22:42:05  <andythenorth> and it can composite... :P
22:42:18  <Rubidium> andythenorth: when is it of LordPixaII stability/quality? ;)
22:42:30  <andythenorth> dunno
22:42:33  <andythenorth> only I'm testing it
22:42:46  <andythenorth> it's not packaged well yet
22:43:07  <andythenorth> but I discover what it's missing by testing it against cases
22:43:36  <andythenorth> you may find it easier to roll your own anyway
22:43:44  <andythenorth> what it does isn't hard
22:43:55  <andythenorth> it's only taken so long because I'm a bad programmer
22:44:52  *** frosch123 has quit IRC
22:46:27  <andythenorth> ho
22:46:29  <andythenorth> haybales
22:47:58  <andythenorth> so...infrastructure (road, rail) doesn't get partial snow because....?
22:48:04  <andythenorth> - lack of bits spare?
22:48:13  <andythenorth> - too expensive to calculate?
22:48:16  <andythenorth> - no graphics?
22:48:31  <andythenorth> - nobody cares?
22:48:56  <planetmaker> c) and missing ingame support
22:49:28  <planetmaker> it would need a change how snow cover is calculated: global height. In principle feasible. I'm not exactly sure why it wasn't done
22:49:47  <planetmaker> Our grf-frog just left
22:50:39  <andythenorth> but openttd could be patched to calculate it?
22:50:56  <Rubidium> andythenorth: yes
22:51:07  <andythenorth> graphics could be generated...
22:51:17  <Rubidium> andythenorth: better not ;)
22:51:20  <andythenorth> no benefit to me, I use SF base set :P
22:51:27  <Rubidium> better let OpenTTD do the composition itself
22:51:47  <Rubidium> makes it work nicer with different tile sets and rail types
22:51:48  <andythenorth> you could also do that for....all the other composited tiles...
22:51:59  <planetmaker> Rubidium: the composition itself would be very helpful wrt ground sprites
22:52:15  <planetmaker> like that nothing needs define a ground tile
22:52:23  <planetmaker> as there'll always be one
22:52:54  <Rubidium> though it'll be a quite significant "event" to get everything to change
22:52:54  <planetmaker> which also could be like grass + (partial) snow cover + grf-supplied ground+building sprites
22:52:58  <andythenorth> no more holes in the scenery when you screw up your newgrf :)
22:53:18  <planetmaker> ah, the change was the point...
22:53:32  <andythenorth> we needs something for v2 anyway
22:53:53  <andythenorth> or 1.3...
22:54:08  <Rubidium> ad it might be better to somewhat start from scratch with certain things at some point
22:54:30  <andythenorth> what about all the legacy newgrf crap :P
22:54:39  <Rubidium> drop it ;)
22:54:52  <andythenorth> how about full 3D? :)
22:55:15  <andythenorth> maybe not, eh?
22:55:22  <Rubidium> though it'd probably even mean dropping original graphics support
22:55:48  <Rubidium> as then you can do the really significant cleanups
22:56:05  <Rubidium> and prepare everything to be much more generic
22:56:15  <Rubidium> like all climates on the map
22:56:51  <Rubidium> though I fear it never comes out of the idea stage
22:57:24  <Rubidium> mostly as it'll cause a lot of drama and work
22:58:18  <andythenorth> no more SF sprites? :(
22:58:24  * andythenorth would be sad
22:58:40  <michi_cc> planetmaker: You want then? :p
22:58:59  <planetmaker> That's what I thought about, indeed
22:58:59  <andythenorth> doesn't everyone? :)
22:59:51  <planetmaker> though I recall that discussion predating that patch
23:00:02  * andythenorth just wants less stupid tram-rail crossings 
23:00:08  <andythenorth> and even tried to patch for it
23:01:08  <andythenorth> also....good night
23:01:13  * andythenorth was up at 4am
23:01:19  <andythenorth> and may be so again :P
23:01:21  <planetmaker> ui. Sleep well
23:01:32  <andythenorth> bye
23:01:33  *** andythenorth has quit IRC
23:07:35  <Brot6> BANDIT - Feature #3771 (New): Setup Pixa to draw more trailer types (andythenorth) @
23:18:38  * Zuu misses GSOrder.UnshareOrders
23:18:46  * Zuu goes and file a feature request
23:22:05  <planetmaker> does the feature request feature a file?
23:34:20  <Zuu> planetmaker: No attached file
23:34:41  <Zuu> do you want a file? :-)
23:47:10  <Yexo> Zuu: I didn't do that, that was truebrain's work
23:47:14  <Yexo> so complain to him please :)
23:47:22  <Yexo> (yes, I like delegating complaints)
23:47:31  <Zuu> I've filed a bugreport now.
23:47:56  * Yexo wonders how long until I'll have to fix that anyway :p
23:48:01  <Zuu> It will make sense to fix this before 1.2 is out as then only very few GS have to change.
23:48:16  <Yexo> yes, but on the other hand: 1.2 is already branched
23:48:27  <Yexo> rc1 has been released, so not sure we want to change it now
23:48:52  <Zuu> GSOrder.AIOF_* has only been available for a limited amount of time. The only GS that I know use it is the tutorial.
23:49:06  <Zuu> Hmm, true
23:49:31  <Zuu> Could be added to 1.3 and have it in compatibility layer.
23:49:40  <Yexo> yep
23:49:44  <Yexo> same can still be doen for 1.2
23:50:14  <Yexo> document it as [AI/GS]Order.OF_* but have the old names (AIOF_*) still available in the compatibility layer
23:50:59  <Zuu> Sounds good, as that will make it easier to release gamescripts with the new name with compatibility for 1.2.
23:55:19  <Zuu> Regarding FS#5089 (missing UnshareOrders etc): Unless you are faster, I will probably make a patch myself as to get forward with my fleet management GS.
23:58:47  <Yexo> I doubt I'm faster
23:58:51  <Yexo> but we'll see
23:58:55  <Yexo> good night

Powered by YARRSTE version: svn-trunk