Log for #openttdcoop.devzone on 2nd September 2010:
Times are UTC Toggle Colours
00:12:40  *** Seberoth has quit IRC
00:55:30  *** OwenS has joined #openttdcoop.devzone
01:18:06  *** thgergo has quit IRC
06:25:52  <planetmaker> good morning
06:29:20  <Brot6> FIRS Industry Replacement Set - Revision 1312:e107a6f1589b: Feature: improved Sand Pit graphics (andythenorth) @
08:24:26  *** Seberoth has joined #openttdcoop.devzone
08:38:13  *** ODM has joined #openttdcoop.devzone
09:13:42  <Brot6> OpenGFX - Bug #1388 (Closed): check station roofs' transparency (planetmaker) @
09:13:42  <Brot6> OpenGFX - Revision 520:670823c18970: Fix #1388 (r450): No more broken glass on station roofs (planetmaker) @
09:13:42  <Brot6> OpenGFX - Bug #1388 (Closed): check station roofs' transparency (planetmaker) @
09:21:54  <Brot6> OpenGFX - Feature #839: 4737-4742: Fizzy drink factory (planetmaker) @
09:28:38  <Brot6> OpenGFX - Feature #1255: Gumdrops for Toyland Lighthouse and Radio Antenna (planetmaker) @
10:25:46  <Brot6> FIRS Industry Replacement Set - Feature #1389 (Assigned): For INCOMPATIBLE_VERSION14, state what ... (foobar) @
10:36:38  *** KenjiE20 has joined #openttdcoop.devzone
10:45:03  <Brot6> FIRS Industry Replacement Set - Feature #1389: For INCOMPATIBLE_VERSION14, state what OpenTTD ver... (planetmaker) @
10:47:16  <Brot6> FIRS Industry Replacement Set - Feature #1303: Include action14 strings into translations (planetmaker) @
10:49:03  <Brot6> FIRS Industry Replacement Set - Feature #1305: Detect missing strings (planetmaker) @
10:50:26  <Ammler> Froix didn't get my hint to make his own thread for the trees ;-)
10:51:49  <planetmaker> :-) Nvm it
10:52:04  <Brot6> FIRS Industry Replacement Set - Feature #1305: Detect missing strings (planetmaker) @
10:52:04  <Brot6> FIRS Industry Replacement Set - Revision 1313:1014da1cc6f1: Fix #1362: Don't include nfo header t... (planetmaker) @
10:52:04  <Brot6> FIRS Industry Replacement Set - Bug #1362 (Closed): Duplicate NFO header (planetmaker) @
10:52:05  <planetmaker> But you're right :-)
10:55:21  <Ammler> he has already a newgrf, so he doesn't look for a coder, does he?
10:57:01  <planetmaker> Yes he knows how to deal with that
10:57:13  <planetmaker> He's the same one as with the Shanghai maglev
10:58:19  <Ammler> maybe we can ask him to make snowy temperate trees from the already opengfx trees
10:58:19  <Brot6> FIRS Industry Replacement Set - Feature #1389: For INCOMPATIBLE_VERSION14, state what OpenTTD ver... (planetmaker) @
10:58:19  <Brot6> FIRS Industry Replacement Set - Revision 1314:cc8c7b765581: Feature #1305: change to the script l... (Ammler) @
10:59:14  <planetmaker> Actually _I_ wouldn't mind to have those trees in OpenGFX
10:59:17  <Ammler> shall I add that script to the build script, or does the makefile already run it?
10:59:34  <planetmaker> what script?
10:59:43  <Ammler> the missing strings thing
10:59:58  <planetmaker> it's not run automatically
11:00:05  <planetmaker> But it's not needed either.
11:00:10  <planetmaker> Missing translations are no error
11:00:14  <Ammler> nah
11:00:31  <Ammler> not for abort, but for the errors log
11:04:27  <Ammler> isn't it a error
11:04:34  <Ammler> if a undef is missing?
11:05:12  <Ammler> and it seems that is all what that script does, it doesn't check for missing translations
11:05:41  <Ammler> IMO, you should incldue to make and fail
11:07:21  <planetmaker> There will never be an undef missing :-)
11:07:29  <planetmaker> There will only be one too much
11:07:40  <planetmaker> for those which are not defined in the translated language
11:07:57  <planetmaker> And that's a non-op
11:08:28  <Ammler> oh, so the undef is generated automatically?
11:08:33  <planetmaker> No
11:08:48  *** thgergo has joined #openttdcoop.devzone
11:08:49  <Ammler> hmm, so how will there never be one missing?
11:08:56  <planetmaker> if you define a new English string, you also undef it
11:09:13  <planetmaker> and the same undef file is used for every language
11:09:26  <Ammler> yep, but the undef isn't checked, is it?
11:09:39  <planetmaker> it isn't
11:09:55  <Ammler> hmm, shouldn't the undef script be a sed of english?
11:10:11  <planetmaker> That'd be ideal, yes
11:17:33  <Terkhen> the script can be used for checking missing translation too, you only need to pass it a part of the translation file as a parameter (for example check_language 04 or check_language spa will check the spanish translation)
11:18:04  <Terkhen> and IMO missing strings at remove_defines should be treated as an error
11:18:59  <planetmaker> yes, they are that. But generating that file automatically would avoid that error ;-)
11:19:13  <Brot6> FIRS Industry Replacement Set - Feature #1390 (New): Feature: Generate lang/remove_defines.pnfo a... (planetmaker) @
11:21:00  <Terkhen> indeed :)
11:21:12  <planetmaker> hm. Script done :-P
11:22:49  <Brot6> FIRS Industry Replacement Set - Feature #1390: Feature: Generate lang/remove_defines.pnfo automat... (Ammler) @
11:29:28  <Brot6> FIRS Industry Replacement Set - Feature #1390: Feature: Generate lang/remove_defines.pnfo automat... (Ammler) @
11:35:13  <Ammler> planetmaker: where are the docs of opengfx?
11:36:39  <planetmaker> in the docs folder?
11:36:45  <Ammler> only ptxt
11:36:49  <Brot6> FIRS Industry Replacement Set - Feature #1390: Feature: Generate lang/remove_defines.pnfo automat... (planetmaker) @
11:37:12  <planetmaker> yeah, they're currently in docs, too
11:37:16  <planetmaker> and in $DIR_NAME
11:37:26  <planetmaker> But... don't rely on any of those two
11:38:19  <Ammler> they aren't in both
11:38:29  <planetmaker> did you run make docs?
11:38:36  <planetmaker> if you only run make, they're not built
11:39:10  <Ammler> I run make bundle_zip
11:39:16  <Ammler> the zip is without
11:39:53  <Ammler> make: Nothing to be done for `docs'.
11:40:21  <Ammler> ./sprites/source/missing_chars.txt <-- the only txt file
11:41:02  <Ammler> make should really build the docs
11:41:14  <Ammler> you just need to differ for installation
11:41:15  <planetmaker> no. Make bundle is enough
11:41:31  <planetmaker> If make bundle* doesn't build it, it's a bug indeed
11:41:35  <planetmaker> But make need not build it
11:42:27  <Ammler> yep, take this as a bug report :-)
11:42:38  <planetmaker> I'll forget it ;-)
11:44:54  <Ammler> hmm, I wonder, why the CF didn't complain
11:45:03  <Ammler> maybe I should flag the readme with "R"
11:50:28  <planetmaker> what should the CF have complained about?
11:50:35  <planetmaker> oh... nvm. The missing docs
11:52:51  <Brot6> Example NewGRF Project - Feature #1391 (New): Version check for "tools" and abort (Ammler) @
11:53:08  <planetmaker> well. maybe. But... then read the definitions from the Makefile
11:53:19  <planetmaker> Or the configuration therein becomes void
11:53:27  <planetmaker> or rather pointless
11:54:53  <Brot6> Example NewGRF Project - Bug #1392 (New): make builds no docs (.txt) files anymore (Ammler) @
11:57:25  <planetmaker> Ammler, testing which which project...?
11:57:37  <Ammler> yep, that is why I made the report there :-)
11:57:37  <planetmaker> which revision? which call?
11:57:43  <Ammler> all
11:57:53  <Ammler> well, I tested ogfx and firs
11:58:33  <planetmaker> and you called make bundle_zip?
11:59:03  <planetmaker> hm... yes :S
11:59:14  <planetmaker> damn damn.... yet another patch in my growing makefile patch queue
11:59:50  <Ammler> no
11:59:54  <Ammler> I just run make
12:00:05  <Ammler> that should be enough for building
12:00:29  <Ammler> installing is the next step... :-)
12:00:35  <planetmaker> no. Docs should not be build by calling make
12:00:47  <Ammler> mäh
12:00:47  <Brot6> Example NewGRF Project - Bug #1392 (New): make builds no docs (.txt) files anymore (Ammler) @
12:01:04  <Ammler> that is ugly
12:01:05  <planetmaker> They only need building when you build a bundle
12:01:16  <Ammler> I like to have up2date docs
12:01:22  <planetmaker> then make docs
12:01:37  <Ammler> I like "others" to have up to date docs
12:02:00  <planetmaker> Ammler, docs are never generated on a call to make
12:02:11  <Ammler> that is really bad
12:02:36  <Ammler> are you sure, it wasn't before?
12:03:01  <Ammler> I rarly run make <something> local
12:03:10  <Ammler> and I had txt files
12:03:58  <planetmaker> it's generated when you call install, of course
12:04:10  <planetmaker> But I'm sure it has been this way since r0
12:04:48  <Ammler> if so it is wrong since r0
12:06:18  <Ammler> just made "hg up 100 && make" and txt files are there
12:06:30  <Ammler> (in ogfx)
12:07:25  <Ammler> well, anyway, the split the ticket to a urgent bug and a low prio feature request :-)
12:14:18  <planetmaker> I consider it a bug request
12:15:36  <planetmaker> when I make a newgrf I don't need its documentation done
12:15:43  <planetmaker> I test whether the newgrf compiles
12:15:55  <planetmaker> It's a development tool
12:16:07  <planetmaker> I only need the documentation when I ship the thing
12:16:28  <Ammler> the readme does also have dev docs like the build targests
12:17:09  <Ammler> and what is a "bug request"?
12:17:15  <Ammler> :-D
12:17:47  <Ammler> well, at least for the bundles, there should be docs, so that part is urgent
12:18:14  <Ammler> there other part, I will learn to life with it :-(
12:19:23  <Ammler> it would be a "Feature revive request" :-)
12:20:06  <Ammler> I am sure, you confused building and installing...
12:20:35  <planetmaker> `all'
12:20:36  <planetmaker>     Compile the entire program. This should be the default target. This target need not rebuild any documentation files; Info files should normally be included in the distribution, and DVI files should be made only when explicitly asked for.
12:20:39  <planetmaker> ^^
12:21:25  <planetmaker> as such I go by the official makefile documentation
12:21:25  <Ammler> yes, user docs maybe
12:21:35  <planetmaker> there are no other docs
12:21:47  <Ammler> the readme has infos about building, doesn't?
12:22:28  <planetmaker> yes.
12:22:51  <planetmaker> As such the argument could be: Ship pre-compiled documentation with the tar balls
12:23:24  <planetmaker> +source
12:24:59  <Ammler> but you know, it doesn't build also for bundles?
12:27:02  <planetmaker> I know now.
12:27:11  <planetmaker> And that is a real problem
12:27:14  <Brot6> Example NewGRF Project - Bug #1392: make builds no docs (.txt) files anymore (Ammler) @
12:27:50  <Ammler> [13:39] <Ammler> I run make bundle_zip
12:27:52  <Ammler> [13:39] <Ammler> the zip is without
12:30:35  <planetmaker> yes :-) I know since then :-)
12:31:03  <planetmaker> now is a relative time span :-P
12:31:34  <planetmaker>
12:31:36  <Webster> Title: Front Page - The Long Now (at
12:32:08  <Ammler> maybe, there is no need to cpp the opengfx readme at all
12:33:00  <Ammler> you are member?
12:37:36  <planetmaker> I'm not a member. But I find it kinda a cool project
13:21:52  *** GT has joined #openttdcoop.devzone
13:45:00  <DJNekkid> yey, a14-support for 2cc-set isnt THAT much work afterall! :D:D
13:46:46  <planetmaker> :-)
13:52:21  <DJNekkid> _most_ stuff is "outside" of the language-file
13:52:28  <DJNekkid> there is "only" the engine names thats inside
13:53:40  <DJNekkid> and excel is, as always, my friend :D
13:53:46  <GT> If I have actions 2 and 3 in 32bpp_extra.grf, does that make it unsafe for static usage?
13:54:12  <GT> Hi, btw
13:54:29  <DJNekkid> hi
13:54:30  <DJNekkid> and; yes
13:54:38  <DJNekkid> *most* likely
13:55:33  <GT> ogfxe_extra also does have them, but probably gets away with it because it is a *real* base set?
13:56:23  <DJNekkid> unless ogfxe_extra isnt socall "opengfx+" thats not a base-set, its an "addon" to opengfx
13:57:24  <Ammler> GT, what is the use to add such things to 32bpp_extra?
13:57:32  <Ammler> I thought, that is used for 32bpp only?
13:58:20  <Ammler> if you have some "special" 32bpp graphcis, add a newgrf to the tar
13:58:57  <planetmaker> GT, ogfxe_extra gets away with it as it's part of a base set, yes
13:59:09  <planetmaker> the action2/3 stuff in it is fishy nevertheless
13:59:15  <Ammler> really?
13:59:19  <Ammler> :-o
13:59:45  <GT> Why are they there anyway, to randomize the waterworks per climate, or something?
13:59:45  <planetmaker> that's my understanding :-)
13:59:59  <planetmaker> No. per-climate stuff doesn't need action2/3
14:00:06  <Ammler> you want to remove the rivers?
14:00:12  <planetmaker> No :-P
14:01:00  <planetmaker> I've not looked at the water part for ages, but afair it is needed to supply the sprites in their current form; maybe some random stuff, I don't exactly know. Maybe for the slope-awareness
14:01:05  <Ammler> GT climate switches are Action7, no problem to use
14:02:03  <GT> Yes, but the action 7s are used to skip an action 3, that is used to select one of multiple actions2 if Im correct, Im not a newgrf expert
14:02:22  <GT> (talking about ogfxe_extra)
14:02:23  <planetmaker> action7 is just a jump. Whatever it jumps...
14:02:36  <GT> it jumps an action 3
14:02:43  <planetmaker> that's fine
14:02:56  <GT> depending on the climate
14:02:58  <planetmaker> but the action3 is what makes a newgrf afaik non-static
14:03:21  <Ammler> yes, but opengfx_extra doesn't need to be static
14:03:22  <GT> right, so I was wondering why they are there
14:03:35  <Ammler> just "MP"-safe :-)
14:03:35  <planetmaker> just because we can :-P
14:03:55  <Ammler> or it is a bug in the static checking...
14:04:03  <planetmaker> And we can - despite this non-static influence - do that for two reasons:
14:04:12  <planetmaker> - it doesn't have a game-changing influence in MP
14:04:33  <planetmaker> - there's little or no water newgrfs which do more than relatively simple sprite replacements
14:04:37  <GT> :), PM, but what feature does it implement, in other words, if I rip them  out for 32bpp-extra, what will i be missing
14:04:58  <Ammler> nothing
14:05:03  <planetmaker> dunno quite. Some nice things related to water tiles
14:05:08  <planetmaker> But nothing essential
14:05:19  <Ammler> everything can be done with a newgrf
14:06:06  <Ammler> well, if you have the 32bpp waters also in those variations, you can keep it
14:06:13  <GT> Ammler, the problem is that the initial screen does show some coast lines, that are not shown correct without the 32bpp-extra.grf, so I want to make it static
14:06:59  <Ammler> GT, I still would recommend to talk to the openttd devs to load 32bpp-extra alsways
14:07:04  <GT> (for 32bpp only that is)
14:07:09  <Ammler> yes
14:07:23  <Ammler> I assume, you do that already in the ez patch
14:07:41  <GT> no, not yet
14:07:42  <planetmaker> let me understand this: you obviously do more than a sprite-replacement there, adding your own water newgrf. And then it fails?
14:08:04  <Ammler> planetmaker: 32bpp-extra is like a newgrf, not like ogfx-extra
14:08:11  <Ammler> so it isn't loaded at openttd start
14:08:33  <planetmaker> yes. Of course not
14:08:42  <GT> unless it would be static
14:08:57  <planetmaker> Sure static works on the title screen?
14:09:15  <Ammler> mäh, what is bad about my idea?
14:09:27  <planetmaker> besides... can't you just provide the sprites in the same form as OpenGFX does?
14:09:35  <planetmaker> Wouldn't that solve the issue?
14:09:47  <GT> same form?
14:09:55  <Ammler> or what about branching opengfx baseset and make a 32bpp variant
14:10:03  <Ammler> where the only difference is the other extra file
14:10:14  <planetmaker> hm... doesn't 32bpp work the way that you provide the same sprite number as 32bpp and it gets drawn instead?
14:10:24  <planetmaker> Like... usual 32bpp sprites work in trunk?
14:10:38  <Ammler> yep, but you can't do that for ogfx_extra
14:10:45  <planetmaker> why not?
14:10:54  <Ammler> because there it changes the number
14:11:07  <planetmaker> when? Only when new sprites get added
14:11:12  <GT> you provide pngs with a number as in the nfo, and in the directory named after the newgrf, and then they get replaced
14:11:12  <Ammler> you missed that whole discussion?
14:11:51  <planetmaker> GT, ok, and then it still doesn't work with the water?
14:12:00  <Ammler> planetmaker: that is the whole point about the 32bpp-extra, what do you think is that grf for?
14:12:14  <GT> so when the openttdw.grf changes, every png would need to be renumbered, that is why we have a 32bpp-extra, that is the base for the png numbers
14:12:31  <GT> It is basically a copy of ogfxe_extra / openttdw,
14:12:47  <planetmaker> combined, right?
14:12:57  <planetmaker> hm... no
14:12:58  <GT> without the colour tables and some other useless stuff
14:13:17  <Ammler> if you branch opengfx, you would need that useless stuff
14:14:00  <Ammler> but you can append that to the end
14:14:04  <GT> only ogfxe_extra would need to be branched, the numbers in the other base grfs dont change
14:14:18  <Ammler> yes, but you need them in your baseset
14:14:24  <Ammler> you can't replace just one file
14:14:28  <planetmaker> GT, but numbers only change when sprites are added in the middle, right?
14:14:37  <GT> right
14:15:10  <planetmaker> So, would it help, if we added the water in the beginning? Then it's very unlikely to change, except if we change the water itself?
14:16:44  <GT> another problem is that the numbering between openttdw and ogfxe_extra is different, so players with different base sets, cannot use the same set of pngs, that is another reason for having the newgrf
14:16:46  <Ammler> hmm, I give up...
14:18:20  <planetmaker> hm, yes... Then you'll need to have the grf loaded statically
14:19:31  <planetmaker> GT, then you could do similar like for the base grfs: they require a certain GRFID FF XX YY ZZ (XX and ZZ are kinda fixed, too) and load it statically ,if that number is found
14:19:44  <planetmaker> ignoring possibly dangerous stuff
14:20:56  <planetmaker> alternatively we could produce a version without the action3 stuff... Did you by chance try an OpenGFX without it and test whether all your things then work out for you?
14:21:18  <planetmaker> I mean... should be moderately easy for you to build a custom version for testing purposes
14:21:30  <planetmaker> you have all the tools :-)
14:21:48  <GT> correct, but I first wanted to check that Im on the right track, that actions 3 are unsafe,
14:22:03  <planetmaker> yes, I *think* so.
14:22:13  <planetmaker> I didn't reply in the thread as I'm not 100% sure
14:22:29  <planetmaker> action2 is actually the critical one
14:22:31  <GT> I think Ammlers idea isnt that bad: when a 32bpp blitter is active, always try toload the 32bpp-extra grf
14:22:40  <planetmaker> but an action3 always refers to an action2
14:23:08  <planetmaker> GT, yes, possibly. But as said, require a certain GRFID, except the last byte of it
14:23:32  <planetmaker> look like how the check for the extra newgrf of base sets is done
14:24:44  * GT is going to do some experiments, thanks for the replies, cu
14:25:12  <planetmaker> no problem :-)
14:30:55  <Rubidium> hmm, so Mac OS X users always have to play with 32bpp-extra if it's found?
14:31:13  <Ammler> wouldn't matter
14:31:19  <Ammler> not supported os anyway ;-)
14:31:22  <Rubidium> (yes, recent Mac OS X builds don't support 8bpp)
14:32:11  <Ammler> hmm, is there another reason left to use 32bpp blitter then?
14:32:28  <Ammler> if you like to play with 8bpp graphcis
14:38:59  <Ammler> Well, most proper would be a branch of ogfx, also easiest to maintain...
14:39:58  * planetmaker kicks Ammler 
14:40:01  <Ammler> branch ogfx, replace the ogfxe_extra.pnfo with your pnfo and you are done
14:40:04  <planetmaker> I don't support your notion
14:40:11  <Ammler> where?
14:40:22  <Ammler> ah :-)
14:40:23  <planetmaker> I don't want to be forced upon 32bpp
14:40:32  <Ammler> you aren't
14:40:35  <planetmaker> Or you can forget that I can test and develop OpenGFX
14:40:59  <Ammler> only, if you have the 32bpp-extra.grf in your share
14:41:36  <planetmaker> No. I actually think that OpenTTD needs a button *somewhere* which en- or disables the use of the 32bpp sprites, if the 32bpp blitter is active
14:42:13  <Ammler> or 32bpp graphcis should all be done as newgrfs :-)
14:42:26  <Ammler> or own baseset any you have the switch
14:44:19  <planetmaker> Hm. That *might* be best
14:44:45  <planetmaker> The modifications required would be on the bananas side mostly: allow additional 32bpp files in the uploaded base set
14:44:48  <Ammler> hmm, shall we merge ogfx and 32bpp-extra?
14:45:07  <planetmaker> Then 32bpp could 'just' add black 8bpp sprites and supply 32bpp for everything
14:45:17  <planetmaker> then the 5 original grfs would be tiny
14:45:35  <Ammler> I don't think, the 32bpp people fear the size :-)
14:45:37  <planetmaker> or is my assumption somewhere flawed?
14:45:51  <planetmaker> Ammler, but 3MB more or less do matter...
14:46:01  <Ammler> for a 100MB file?
14:46:15  <Ammler> where I would guess, around 50% is done maybe less
14:46:42  * Rubidium wonders whether they're ever going to pick up on my idea with NML :)
14:46:53  <Ammler> the 32bpp extra sprites are 7MB already
14:48:14  <Ammler> planetmaker: it is more the other side around, if we are ready to merge the 7MB from 32bpp-extra to our repo
14:49:08  <Ammler> I guess not, so the easiest is too clone ogfx and pull from time to time
14:49:15  <planetmaker> yes
14:49:33  <planetmaker> OpenGFX must not get needlessly larger by a few 100% percent
14:54:15  *** frosch123 has joined #openttdcoop.devzone
15:22:18  *** yorick has joined #openttdcoop.devzone
15:45:51  <Hirundo> [reading backlog] Rubidium: what idea with NML?
15:47:12  <Brot6> 2cc train set - Revision 593:471e3fd80adf: Change: in preparation for action14: (DJNekkid) @
15:49:36  <Brot6> 2cc train set - Revision 594:18fb7c9c9cc7: Fix: Forgot to add a file in the prev. rev (DJNekkid) @
16:00:10  <Ammler> Hirundo: 32bpp support
16:01:07  <Hirundo> to automagically create png files with the correct naming/offsets etc?
16:01:36  <planetmaker> possibly
16:01:47  <planetmaker> But... that's kinda difficult and subjet to its own extension
16:01:50  <planetmaker> +c
16:08:42  *** frosch has joined #openttdcoop.devzone
16:08:55  <Ammler> Hirundo: yes, and creating the png files with name like the sprite number
16:09:43  <Hirundo> <- writing the tEXt chunk should be possible
16:09:44  <Webster> Title: digital sanitation engineering: Python, PIL and PNG metadata, take 2 (at
16:10:36  <Ammler> basically you define beside the 8bpp png also the other pngs
16:10:45  <Ammler> (the zoom-level stuff)
16:11:58  *** frosch123 has quit IRC
16:11:59  *** michi_cc has quit IRC
16:11:59  *** SmatZ has quit IRC
16:11:59  *** tneo has quit IRC
16:12:07  *** frosch123 has joined #openttdcoop.devzone
16:12:07  *** michi_cc has joined #openttdcoop.devzone
16:12:07  *** SmatZ has joined #openttdcoop.devzone
16:12:07  *** tneo has joined #openttdcoop.devzone
16:12:22  *** frosch123 has quit IRC
16:13:42  <Hirundo> What's the current situation of the 32bpp stuff? Much activity?
16:14:21  <Ammler> well, they have basically no system and there is no big support from tools
16:14:29  <Ammler> it is very complicated to make 32bpp stuff
16:15:42  <Yexo> Hirundo: what nml needs first is a syntax for alternative graphics
16:15:51  <Brot6> 2cctrainset: update from r592 to r594 done (4 errors) -
16:16:16  <Yexo> we have a syntax to supply the filename/size/offsets for 8bpp sprites, but we need the same for 'alternative' graphics
16:16:33  <Yexo> where alternative is currently only 32bpp in normal zoom, but in a way that it can later be extended to extra zoom levels
16:16:51  <Brot6> firs: update from r1309 to r1314 done (883 errors) -
16:17:11  <Hirundo> As far as I can tell, those need the same information (xpos/ypos/xrel/yrel/xsize/ysize), although the rectangle to use of often the entire file
16:17:30  <Yexo> exactly
16:18:11  <Hirundo> We could say that specifying 0,0,0,0 as rectangle is equivalent to the entire file.
16:18:13  <Yexo> but I think it's better if we don't rely on the fact that it's often one sprite per file
16:18:34  <Yexo> I think it'd be a lot easier for them too if they could just copy a 8bpp sprite file and just draw over the 8bpp graphics
16:18:38  <Brot6> nforenum: update from r482 to r484 done -
16:18:51  <Yexo> currently that's not possible because the tools don't support that
16:19:13  <Hirundo> That's for no-zoom?
16:19:28  <planetmaker> o_O @ FIRS errors.... did I screw up?
16:19:38  <Brot6> nutracks: update from r112 to r114 done (2 errors) -
16:19:46  <Yexo> yes
16:19:54  <Yexo> for extra-zoom it might be different
16:19:56  <frosch> even normal zoom 32bpp can have two png per sprite
16:20:02  <Ammler> Hirundo: currently they have one file per sprite, but Yexo means, that it would be easier to have multiple sprites per file anyway
16:20:06  <planetmaker> frosch, two?
16:20:15  <Hirundo> CC mask
16:20:16  <Yexo> planetmaker: company color mask
16:20:19  <planetmaker> ah
16:20:20  <frosch> a rgfa one, and an indexed one for company colours and such
16:20:28  <frosch> though the latter is incompatible with extra-zoom afaik
16:20:29  <Ammler> planetmaker: I would wait for the rebuild :-)
16:20:46  <planetmaker> Ammler, not sure. IIRC I had those, too
16:21:00  <Brot6> opengfx: update from r519 to r520 done -
16:21:07  <Ammler> me too, then I updated nforenum and the errors are gone
16:21:09  <Brot6> Following repos didn't need a nightlies update: 32bpp-extra (r38), airportsplus (r53), basecosts (r20), belarusiantowns (r0), comic-houses (r71), fish (r387), frenchtowns (r3), grfcodec (r244), heqs (r372), metrotrackset (r56), newgrf_makefile (r172), nml (r700), ogfxplus (r41), openmsx (r97), opensfx (r97), snowlinemod (r42), swedishrails (r147), swisstowns (r13), transrapidtrackset (r15), ttdviewer (r25), ttrs (r18), worldairlinersset
16:21:09  <Brot6> (r663)
16:21:28  <Ammler> theoretically it should annouce that...
16:23:33  <Hirundo> I assume that the lack of a complete, written spec is one of 32bpp's problems?
16:24:10  <Ammler> does trunk 32bpp support CC?
16:24:15  <Yexo> no, a lack of coordination
16:24:15  <frosch> yes
16:24:46  <Ammler> so why does ez needs "special support"?
16:24:48  <frosch> Hirundo: everyone who talks about 32bpp has different goals, so it is kind of hard to advance to the specs-writing-stage :)
16:24:59  <frosch> Ammler: ez does not recolour, but does some hue transition
16:25:27  <frosch> but i do not know the details, i only know the bugreports about 32bpp not working in trunk :p
16:25:54  <frosch> it's called "new experimental company colour algorithm" or so
16:26:04  <Hirundo> so RGB -> HSB -> shift hue -> RGB?
16:26:30  <frosch> yes, i would guess only for company colours though, but no idea
16:26:59  <Ammler> planetmaker: warnings are gone:
16:27:09  <Ammler> strange is that it wasn't announced :-(
16:27:32  *** Seberoth has quit IRC
16:27:39  <frosch> Hirundo: it is at the very top of the diff
16:27:47  <frosch>
16:29:41  <michi_cc> It's no wonder 32bpp isn't progressing as long as many people associate 32bpp with the last list from and not with what it is: more colours at the same time.
16:29:43  <Webster> Title: Transport Tycoon Forums • View topic - To Do, Roadmap, Feature requests (at
16:29:46  <planetmaker> hm
16:29:52  <Hirundo> "declare variables at first use", "min() is not invented here, let's use our own"
16:29:57  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: 2cctrainset (4 errors), 32bpp-extra (1 errors) (Diffsize: 13), airportsplus (Diffsize: 1), basecosts (Diffsize: 11), comic-houses (3 errors) (Diffsize: 13), firs (Diffsize: 6327), fish (5 errors) (Diffsize: 1), heqs (Diffsize: 1), metrotrackset (Diffsize: 1), newgrf_makefile (Diffsize: 1), snowlinemod, transrapidtrackset (Diffsize: 12), ttrs (125
16:29:57  <Brot6> errors) (Diffsize: 1322), worldairlinersset
16:30:31  <Ammler> he, I don only announce, if a grf got worse, not better :-)
16:31:36  <frosch> does someone know what 32bpp does wrt. 2cc and house/bridge or newgrf supplied recolouring?
16:31:39  <Ammler> <-- same md5sum
16:31:56  <frosch> or are 32bpp houses not meant to be recoloured?
16:32:44  <planetmaker> no idea
16:33:14  <planetmaker> he, hi michi_cc :-) I never knew you were in this channel, too ;-)
16:35:07  <michi_cc> planetmaker: Your IRC client doesn't have a nick list? :)
16:35:31  <planetmaker> It does. And it's right on my screen to the right of all the text... but... :-)
16:40:04  * planetmaker wonders whether actually EZ and 32bpp are related... or rather should be related
16:42:01  <planetmaker> probably not
16:42:25  <planetmaker> As such EZ needs a sane algorithm to smoothly extrapolate graphics...
16:42:31  <Ammler> hmm, about nml, couldn't we with a kind of sed convert the opengfx to nml?
16:42:57  <planetmaker> OpenGFX base grfs might work
16:42:59  <Ammler> then we only need "special" work for the extra grf
16:43:03  <planetmaker> yes
16:43:22  <planetmaker> should be a moderately easy tasks. Both things actually
16:43:41  <Ammler> one spriteset per file, I guess?
16:44:12  <Ammler> well, we might have troubles with the already templated things
16:45:24  <planetmaker> hm. yes
16:45:53  <planetmaker> I suggest one sprite set per "set". Where "set" is a set of lines without empty line in between.
16:59:16  <planetmaker> GT still here? What indeed about the idea to propose an extra-zoom patch which only provides a zoom-in functionality? Independent of the bit-depth used?
16:59:26  <planetmaker> s/propose/provide/
17:00:37  <planetmaker> GT, kinda implementing a hqx2 algorithm for that end is by the looks a nice idea. Might be not quite easy, though...
17:00:50  <planetmaker> But that way it might be moderately easy to get such thing into trunk
17:01:00  <planetmaker> It's a single feature. Doesn't touch other existing stuff...
17:08:16  <Ammler> that was the initial idea about makeing mq for the ez patch
17:09:48  <planetmaker> it might be complicated enough to warrant its own mq all by itself.
17:14:34  <DJNekkid> now ...
17:14:39  <DJNekkid> what parameters do the 2cc-set have
17:15:01  <DJNekkid> purchase/running costs? :)
17:15:06  <Ammler> default 9
17:15:29  <DJNekkid> perhaps separate running- and purchasecosts?
17:15:30  <Ammler> that's all I remember :-)
17:17:17  <planetmaker> DJNekkid, why not? :-)
17:17:43  <planetmaker> was there a region parameter?
17:17:49  <DJNekkid> there was :)
17:19:27  <DJNekkid> should we reintroduce it?
17:19:41  <planetmaker> did you remove it?
17:19:51  <DJNekkid> basicly
17:20:03  <DJNekkid> it seemed like it confused people
17:20:17  <planetmaker> With a14 it suddenly becomes accessible :-)
17:20:23  <DJNekkid> exactly
17:20:51  <planetmaker> well. Your choice basically.
17:20:58  <planetmaker> You could also put that off till 2.1 or so
17:22:16  <DJNekkid> so extensive regions still?
17:24:28  <planetmaker> Not sure :-)
17:24:40  <Brot6> 32bpp-extra - Revision 39:0451ecd5cc53: Add: devzone CF seems to need an md5 target (GeekToo) @
17:24:45  <planetmaker> I'm not sure how much it'd be used and what best would be the way to configure it
17:25:00  <planetmaker> ls
17:25:39  <DJNekkid> there was,iirc, 10 regions
17:25:55  <planetmaker> around that, yes
17:26:52  <DJNekkid> east,west,north(scandinavia),south europe, n/s america, africa, asia, oceania
17:29:17  <DJNekkid> there are balsicly: lots of w-europe, pretty many e-europe, some american(both N and S) and scand, a handfull of asian, and barely african and oceania
17:29:49  <planetmaker> yeah
17:30:07  <planetmaker> I wonder whether one could make a switch for each of the major countries
17:30:59  <DJNekkid> hmm
17:31:07  <Ammler> why should someone reduce those per parameter?
17:31:17  <Ammler> is that a ttdp feature?
17:32:31  <DJNekkid> huh?
17:33:24  <planetmaker> Ammler, scenario designers
17:34:08  <Ammler> DJNekkid: it isn't worth imo
17:35:37  <DJNekkid> worth it?
17:35:45  <DJNekkid> its a VERY easy feature to introduce
17:36:47  <Ammler> rather send the time to balance the set with ukrs/nars/dbset/jptrains...
17:37:14  <Ammler> I would prefer moar, not leass
17:37:22  <DJNekkid> agreed :D
17:37:59  <DJNekkid> balance in what way?
17:38:09  <DJNekkid> capacities?
17:38:13  <DJNekkid> running costs?
17:38:17  <Ammler> prcies
17:38:25  <Ammler> so someone can compete with 2cc against dbset
17:39:02  <Ammler> maybe someone will ever make a "set" filter :-)
17:40:11  <DJNekkid> well, i prefer to have the default costs quite high
17:40:26  <Terkhen> hmmm... I think I could remove #defines from language files in FIRS doing something similar to that write_undef.diff
17:40:52  <DJNekkid> but the two new parameters should be able to balance it out quite well...
17:41:01  <DJNekkid> with separate purchase and running costs
17:41:08  <Ammler> DJNekkid: yes, but if I enable the "make compatible with dbset", the prices for a ICE sould be the same on both sets
17:42:51  <DJNekkid> like "excatly" the same?
17:43:06  <DJNekkid> currently an ICE3 p-cost is aprox 1/2 of db-set
17:43:46  <Ammler> well, just an example :-)
17:45:36  <Brot6> #openttdcoop Server Patch Pack - Revision 5:389faaca98bf: Change: enalbe automatic release building (Ammler) @
17:55:29  *** Seberoth has joined #openttdcoop.devzone
18:23:57  *** Alberth has joined #openttdcoop.devzone
18:31:31  *** Seberoth has quit IRC
18:31:41  *** Seberoth has joined #openttdcoop.devzone
18:53:48  *** Seberoth has quit IRC
18:58:14  *** Seberoth has joined #openttdcoop.devzone
19:05:56  <Brot6> OpenGFX - Revision 521:68c1706adbc3: Change #1263: Slightly different colour for one of the rough... (planetmaker) @
19:09:42  <Brot6> OpenGFX - Feature #1263: Toyland Rough Land (planetmaker) @
19:46:34  <Brot6> OpenGFX - Revision 522:5951f28fa639: Fix #1392 (r513): Build the documentation files and bundle t... (planetmaker) @
19:49:38  <Brot6> Example NewGRF Project - Bug #1392 (Closed): make builds no docs (.txt) files anymore (Ammler) @
19:49:38  <Brot6> Example NewGRF Project - Revision 173:0b9a54a4efc1: Fix #1392: Build and bundle the documentation... (planetmaker) @
19:49:38  <Brot6> Example NewGRF Project - Bug #1392 (Closed): make builds no docs (.txt) files anymore (planetmaker) @
20:06:25  <Brot6> OpenGFX - Feature #942: Profit icons are too similar to "moving" icon (frosch) @
20:14:43  <Hirundo> "If xoffs is negative, yoffs must be one lower than the wanted value." <- Yet Another Nfo Quirk :o
20:16:10  <frosch> :p
20:17:26  <planetmaker> what?!
20:17:30  <planetmaker> that's evil
20:21:20  <Brot6> #openttdcoop Server Patch Pack - Bug #1393 (New): 78 (compiler) @
20:22:57  <Brot6> Autopilot - Revision 82:506bc7916258: Change: content_download to ignore (Ammler) @
20:30:04  <Hirundo> I doubt that OpenTTD implements YANQ correctly, as I've found no trace of it in the code
20:31:48  <Yexo> Hirundo: which action/feature is that?
20:32:10  <Hirundo> both airports and industries
20:32:22  <Hirundo> tile layout, for type = 0xFF
20:34:50  <planetmaker> Hirundo, wth is that, YANQ?
20:34:59  <Yexo>  <- Yet Another Nfo Quirk :o
20:35:06  <planetmaker> :-D loool
20:35:22  <Yexo> I can't find a trace of openttd implementing that either
20:35:56  <Yexo> I did find out that a newgrf can cause an index out of bounds by copying the layout of a non-existing industry
20:38:55  <Hirundo> Does anyone know of a station grf that allows building a station that has both 'rail' and 'non-rail' tiles in one unit?
20:38:57  <Rubidium> Hirundo: I hope they explained my idea adequately, if not please say so
20:39:07  <Rubidium> (my idea = the NML thing from hours ago)
20:40:24  <Hirundo> defining 32bpp[normal|EZ] sprites in NML and generating the correct pngs/offsets should be possible
20:47:23  <planetmaker> please let that rather be additions for > 0.1 :-P
20:47:27  <Yexo> Any comments on this syntax?
20:49:29  <Hirundo> How does this work for spritesets?
20:50:15  <planetmaker> Yexo, that doesn't seem consistent
20:50:23  <planetmaker> usual way to do seems to be
20:50:42  <Yexo> like that?
20:50:48  <Yexo> ^^ for Hirundo
20:50:49  <planetmaker> block_type (name, parameters) { ... }
20:51:28  <Hirundo> That makes spritesets global
20:51:44  <Yexo> aren't they already global?
20:52:47  *** Alberth has left #openttdcoop.devzone
20:52:53  <Hirundo> They are currently per-spriteblock
20:53:22  <planetmaker> hm, I withdraw my last comment
20:53:30  <Yexo> I didn't know that
20:53:35  <Hirundo> At least in code, the documentation probably doesn't contain such subtleties
20:53:44  <planetmaker> Synatx is fine with me
20:54:41  <Hirundo> Does it allow defining 32bpp sprites without 8bpp ?
20:54:51  <Yexo> Hirundo: in that case we could just force the alternative_graphics block also in the spriteblock-block
20:54:58  <Yexo> no, it doens't
20:55:08  <Yexo> but it doesn't need to, because a newgrf always needs 8bpp sprites
20:56:08  <Hirundo> Allowing that might be nice for the 32bbp guys who work on base sprites
20:57:06  <Yexo> that doesn't work, nml is meant to write a grf as output
20:57:20  <Yexo> it's not a 32bpp graphics development tool
20:57:51  <Yexo> but just replacing the name by the sprite number allows it, so it's no problem for the syntax
21:00:00  <GT> Yexo, are the offsets in the file and the size needed? They have to be split in seperate pngs anyways
21:00:20  <Hirundo> nml could do that for you
21:00:29  <Yexo> They have to be split in seperate pngs anyways <- there is no reason to split them, nml can do that
21:00:56  <Hirundo> We could also allow 0,0,0,0 as xpos/ypos/xsize/ysize and take that to mean 'entire image file'
21:01:11  <Yexo> if you define a template you can reuse that
21:01:45  <Hirundo> Can airports have more than 1 layout per rotation ?
21:02:09  <Yexo> yes
21:02:21  <Yexo> airports can have multiple layouts, and each layout has a rotation-property
21:02:57  <GT> most artists generate a single or multiple pngs, and pngcodec that, having to merge the pngs to a single file, define the offset and size in nml would mean extra work compared to current situation. So the 0,0,0,0 Hirundo proposes would be nice
21:03:01  <Yexo> so it can also be used to seperate between a modern and old look
21:03:45  <Yexo> 0,0 meaning "complete file" is fine by me
21:04:23  <Yexo> GT: mind that pngcodec is no longer needed because nml will do that part
21:04:49  <GT> of course, I was refering to the current way of working
21:05:10  <GT> where you only need to specify the ingame ofsett with pngcodec
21:05:40  <Brot6> NewGRF Meta Language - Feature #1394 (New): tile layouts (Hirundo) @
21:05:42  <GT> so the nml replacement ideally would only need that same data,
21:06:03  <GT> which would be accomplished with the 0,0,0,0 syntax
21:06:31  <Hirundo> To what extent are the offsets for buildings standard, or at least dictated by a formula?
21:07:01  <Yexo> what i meant is that if you create a 32bpp png file with all the sprite in the same locations/sizes, the offsets can be reused, resulting in for example this:
21:10:14  <planetmaker> Hirundo, the x offset usually is -31, if they take the full width. If it's smaller... well
21:10:25  <planetmaker> And the height gives you an indicator for the y-offset
21:10:52  <planetmaker> like 0-(height-31) or similar
21:11:39  <GT> Yexo:sound very nice, I was just reluctant to have to add the offset and size always, even when using single sprites per tar.
21:11:54  <GT> s/tar/png/
21:12:21  <Yexo> I can understant that, but with Hirundo proposal to use 0,0 that shouldn't be a problem, right?
21:12:28  <GT> right
21:13:38  <GT> so if that is added, it offers extra possibilities for templating, and no extra work for single sprite pngs, so that sound about how we want it
21:13:50  <GT> it = nml
21:14:24  <Yexo> only thing it doesn't support is coding sprites without a grf, so for the basesets you'll still have to use pngcodec (or we need to find a solution for that in nml too)
21:16:16  <GT> there are no sprites without a grf, so define the basesets in nml, and you're fine :)
21:19:27  <Yexo> yep :)
21:21:33  <planetmaker> :-)
21:22:29  <planetmaker> he. That'll give extra incentive to convert OpenGFX quickly to NML once we have a release
21:22:49  <planetmaker> Unfortunately I cannot do that without a release... Packagers would jump my throats ;-)
21:22:52  <GT> pm: I did some experiments with loading the 32bpp_extra.grf at game startup, but not a lot of success
21:23:02  <planetmaker> hm :-(
21:23:24  <planetmaker> not a lot success means: it didn't load or it didn't resolve the issue even if loaded?
21:23:43  <GT> ripping out the actions 3 makes the grf safe for static  use, but it is not used at game start screen
21:23:59  <planetmaker> oh, drat
21:25:01  <GT> so the only way I've found so far, is to define a 32bpp.obg file ( a copy of opengfx.obg), and replacing the ogfxe_extra with 32bpp_extra.grf
21:25:46  <GT> defining a grfid starting with FF, or even completely ffffffff did not work
21:26:43  <Brot6> OpenGFX - Revision 523:0b11ace3e9a3: Feature: GUI sprites for vehicle profits, new news messages ... (planetmaker) @
21:26:50  <GT> did not work: ffffffff gave an error (system grf), start with ff did not solve the issue
21:27:00  <planetmaker> well. Of course defining the GRFID alone doesn't help. You need to tell OpenTTD also to always load it like a base set grf
21:27:29  <GT> yes, and that worked, when defined in the obg file
21:28:03  <planetmaker> Yes. My suggestion is: kinda recognize it as a base grf always. Additionally to the existing one
21:28:37  <planetmaker> But... Might be more trouble than it's worth
21:28:56  <planetmaker> And defining a separate base set might not be the worst idea; actually it might be the most logical one
21:30:06  <GT> not really a lot of trouble, more  a logistic problem: take ogfx base set, and replace ogfxe_extra with 32bpp_extra.
21:30:25  <planetmaker> hm yes. What's the difference of those files?
21:30:43  <Brot6> NFORenum - Revision 485:5a0cf83e3c0e: Update: Action 5 type 15 has A0 sprites now. (frosch) @
21:30:52  <Rubidium> yay :)
21:30:56  <planetmaker> :-)
21:31:04  <GT> no colortables, and basically fixed numbering (which even might be solved with nml)
21:31:06  <planetmaker> Next nightly will compile fine again :-)
21:31:15  <planetmaker> fixed numbering?
21:31:40  <planetmaker> Well, that's what I offered a lot of times: we keep the numbers fixed :-)
21:31:56  <planetmaker> Unless there are new GUI sprites. But then all things need an update anyway
21:32:07  <GT> yes, but not in sync with original graphics
21:32:29  <planetmaker> that's not possible
21:32:44  <GT> so a seperate grf to base the 32bpp sprite numbers upon is still the best option to keep things working
21:32:47  <Rubidium> planetmaker: you can't keep the numbers fixed
21:33:00  <Rubidium> whenever we need another action15 type you're basically screwed
21:33:01  <GT> for both groups of users: ogfx and original graphics
21:33:18  <Rubidium> either you add it at the end and the next time a GUI sprite is added you get into trouble
21:33:19  <planetmaker> yes and yes
21:33:30  <Rubidium> or you add it before the GUI sprites and you're already in trouble
21:34:02  <frosch> nml could also generate a 8bpp fallback from the 32bpp stuff, e.g. greyscale or so
21:34:28  <frosch> or black with red text "activate 32bpp blitter" :p
21:34:34  <planetmaker> :-D
21:34:48  <GT> so the only problem now is that is has to be loaded at game start, so the coast line is correct in the initial screen already.
21:35:05  <planetmaker> Btw, your crown will be shown irrespective of base set, frosch :-)
21:35:14  <frosch> yeah, noticed that :)
21:35:34  <planetmaker> and thanks for the quick patch / feature :-)
21:36:28  <frosch> well, it took a bit longer, as it continues from the wrong backup or so...
21:37:15  <frosch> night though :)
21:37:20  <Rubidium> night frosch
21:37:20  <GT> best option would be to have a bundle with the ogfx base set, and replace the ogfxe_extra with 32bpp_extra and a separate obg file. Would take no more than some scripting on the openttdcoop server I guess
21:37:22  *** frosch has quit IRC
21:37:49  * Rubidium wonders how bad it is to add a third palette "3", which is 32 bits with a DOS paletted fallback
21:41:31  <Brot6> NewGRF Meta Language - Feature #1395 (New): sprite layouts (Hirundo) @
21:42:48  <GT> Rubidium:  you mean extend the newgrf spec so it can incorporate real 32bpp data?
21:43:43  <GT> I'm also wondering whether it would need to be 40 bits (for the mask file)
21:44:01  <Rubidium> no, just make it a proper base graphics set
21:44:20  <Rubidium> i.e. include your own "version" of opengfx
21:44:37  <Rubidium> it's size effect would be relatively minimal
21:44:59  <Rubidium> and we could consider automatically switching to a 32 bits blitter when selecting that set
21:45:25  <Rubidium> you'd also not need to worry about the sprite numbers in the original graphics and/or OpenGFX
21:45:52  <Rubidium> that's (ofcourse) primarily about the extra GRFs
21:47:40  <GT> Well, that about what I was pondering about about: define a new obg, copy opengfx for the  base grf except the extra file, that gets replaced with 32bpp_extra. Automatic activating of the blitter is even better (though the animated one is a pita for 32bpp)
21:50:23  <GT> (replacing some colours with others is not a nice job when using several million of colors)
21:51:41  <Ammler> then I would make a proper branch, which you can from time to time pull
21:51:46  <planetmaker> good night frosch...
21:52:02  <GT> animation could be done with mpng, or proprietary with using multiple sprites per png
21:52:51  <planetmaker> why is the animated one bad for 32bpp?
21:52:53  <Yexo> Rubidium: I fail to see the advantage of that. As long as the 32bpp baseset is incomplete it'll probably use some 8bpp graphics
21:53:00  <planetmaker> nvm
21:54:00  <Yexo> so the "palette" of the 32bpp baseset would need to be set to the palette of those 8bpp graphics anyway
21:54:47  <planetmaker> GT: then one could define the firs 192(?) colours to be subject to palette effects with 32bpp
21:55:05  <planetmaker> maybe my understanding is wrong, but that shouls suffice
21:55:07  <planetmaker> *should
21:55:42  <Rubidium> Yexo: it will always use some non-32bpp graphics, but having a way to automagically select the blitter and not having to worry about sprite numbers in the original graphics/opengfx for it to work right is probably quite beneficial
21:56:46  <Yexo> I agree about that part, but then it probably needs 2 new pallete entries "3: 32bpp with dos-paletted substitute, 4: 32bpp with windows-paletted substitute"
21:57:08  <Brot6> serverpatches: update from  to r20690 done (7 errors) -
21:58:31  <planetmaker> Yexo: that should not be needed
21:58:56  <Rubidium> or maybe just another field telling it's 32 bpp :)
21:59:04  <Rubidium> blitter? :)
21:59:07  <planetmaker> One substitute palette should be enough as you would need to define the 8bpp fallback sprites anyway
21:59:16  *** ODM has quit IRC
21:59:38  <Yexo> separate field might be better
21:59:50  <Yexo> and that's also completely backwards compatible
22:06:54  <GT> pm: the problem is that 32bpp sprites are not limited to 255 colours.  Palettes are an 8bpp concept. If you limit animation to 192 colours, you're effectively back to 8bpp. Eg the water waves: you cannot select a couple of colors from all the blue gradients, and replace them with something else, and still have a nice 32bpp wave
22:07:51  <planetmaker> GT: you're saying you can't have a nice wave with 192 different colours?
22:08:32  <GT> how many of them are blue variants?
22:08:37  <planetmaker> all
22:08:57  <planetmaker> in that case :-)
22:09:30  <planetmaker> That's where the 32bpp "palette" could be different.
22:09:46  <planetmaker> it doesn't need a palette as 32bpp has all colours
22:10:06  <planetmaker> But you have a palette anyway. So you could use that for re-colour and animation purposes
22:10:28  <planetmaker> setting it for the sprite as you need it
22:10:44  <planetmaker> well... probably don't mind me there, though :-)
22:12:13  <GT> well, I have to give it some thought, but with the mask files, and code we have now, it is not possible imo to have nice 32bpp animation
22:21:23  <planetmaker> hm, yeah
22:27:04  <GT> btw, recolour is already taken care of in the EZ patch, by using a blending algorithm that blends the original sprite colour with the colour of the mask, which gives a much better result than just replacing the company colours with the 8bpp mask file pixes as in trunk
22:27:59  <Yexo> if you can split off that part of the code that might be considered for inclusing in trunk already
22:28:14  <Yexo> because if I understood you correctly that's separate from ez
22:30:32  <GT> yes, the ez-patch definately needs a split up: there is zoom-in, real transparency (also for shadows), larger company manager faces, interpolation for zoom out instead of cutting out half the pixels, cc recolour, spritecache for every zoom level
22:31:49  <Ammler> GT, the devzone now would support building the patch queue
22:32:02  <Ammler> like I just tested with the server patch pack
22:32:13  <GT> I saw: add an mq dir to the .devzone
22:32:24  <Ammler>
22:32:28  <GT> Would that also support nightly builds
22:32:31  <GT> ?
22:32:50  <Ammler> it is kinda prepared to support a "testing"
22:32:57  <Ammler> but I need to finish that
22:33:33  <Ammler> currently, you just need to tag the patch queue with the hash it applies
22:33:37  <Brot6> OpenGFX - Feature #942: Profit icons are too similar to "moving" icon (planetmaker) @
22:33:54  <Ammler> then it creates the hg repo for qclone or clone
22:34:23  <Ammler> ->
22:34:56  <Ammler> clone would be needed for the CF
22:35:01  <Ammler> qlcone for others
22:35:41  <planetmaker> [00:27]	<GT>	btw, recolour is already taken care of in the EZ patch, by using a blending algorithm that blends the original sprite colour with the colour of the mask, which gives a much better result than just replacing the company colours with the 8bpp mask file pixes as in trunk <-- nice :-)
22:36:08  <planetmaker> isn't it an idea to use something like that for animation: changing the recolour map periodically?
22:36:15  <GT> That would be a big improvement, as windows support for the ez patch is frequently asked for, and I dont make windows bins anymore since my virusscanner decided that msys is dangerous and should not be started.
22:36:34  <planetmaker> :-D
22:36:59  <Ammler> well, I do make the build just for a "automatic" test, if it works
22:37:51  <Ammler> GT for enabling the tag building .devzone/build/releases/enable
22:37:56  <Ammler> just touch
22:38:11  <GT> releases or nightly?
22:38:30  <Ammler> how would you like to build nightly?
22:38:31  <GT> since I've never made a release
22:38:55  <Ammler> well, the release in this case is just a "fixed" revision
22:39:08  <Ammler> it's not openttd stable :-)
22:39:54  <GT> so, create the enable file, create the mq dir and tag the patch queue should do the trick?
22:40:17  <planetmaker> yes
22:40:54  <Ammler> the tag name should be the hash of the "reviewed" openttd trunk.hg
22:41:10  <GT> Nice, that is surely going to go on my already overloaded todo list
22:42:22  <Ammler> just check the serverpatches repo as example
22:42:28  <GT> full hash or "short" hash
22:42:42  <GT> Ammler: certainly will do
22:43:17  <Ammler> I don't think, that matters
22:43:35  <Ammler> just don't use the rev, as the trunk.hg differs from the devzone clone of it
22:44:10  <GT> OK, seems logical
22:44:32  <GT> Shit, if only I had lots of spare time
22:44:35  <Ammler> maybe we could use the svn rev number
22:44:43  <Ammler> might look nicer
22:44:54  <Yexo> that's not unique
22:45:01  <GT> Not?
22:45:08  <Ammler> Yexo: how is that possible?
22:45:28  <Yexo> if GT has two different patch versions for the same svn version, the svn versino alone is not enough to identify which one was used
22:45:55  <Ammler> Yexo: same would happen with the hash
22:46:31  <Ammler> we do not talk about the hash of the patch commit
22:46:54  <Ammler> what I need to know is the parent
22:47:04  <Ammler> which is the same as svn rev or hash
22:47:17  <GT> wouldn't the hash be used for the upstream checkout, combined with the latest version of the patch queue?
22:48:18  <Ammler> hmm?
22:48:20  <GT> (which about is what Ammler typed faster than me) :)
22:50:45  <Yexo> Ammler: ah, I didn't know you were talking about the hash of the parent repo
22:50:51  <Yexo> in that case the svn rev can be used as well
22:59:13  <Ammler> the patches do also have a Parent
22:59:44  <Ammler> but what to do if there are more patches with different parents
23:14:25  <GT> The parent of a patch can refer to a hash in a local repo, so I dont think it is needed to check that, the correct hash of the upstream repo should be the responsibility of the patch queue  writer.
23:14:54  <GT> as indicated by the tag
23:16:22  <GT> unless Im wrong about the parent is pointing to the hash of the repo it is created in
23:17:45  <planetmaker> yes and no. parent is always the previous rev. That may be the previous patch in a queue
23:21:05  <Brot6> repository /home/ottdc/hg-repos/clientpatches registered in Redmine with url /home/ottdc/hg-repos/clientpatches
23:21:05  <Brot6> repository /home/ottdc/hg-repos/clientpatches created
23:21:14  <GT> in that case every patch in a series will have a different parent, even more argument to not check.
23:21:23  <Ammler> GT, the mq patch has the parent in it's header
23:21:35  <Ammler> the parent hash of the repo it is applied to
23:22:27  <GT> Ok, so the parent is pointing to the main repo, and not to the previous rev in the patch queue?
23:23:06  <GT> the main repo may be local, so also not available in the remote repo
23:24:52  <GT> The way I see it, the complete patch stack is compatible with a certain version of the main (remote) upstream repo, and that one should be tagged.
23:25:26  <Ammler> GT a mq is not always a repo
23:25:26  <GT> IE, the queue should be tagged with that rev
23:26:46  <GT> No, but in that case the mq certainly is local
23:27:03  <Ammler> # Parent 930fc651306cd28401c4a4c722d577edf5cf3407
23:27:24  <Ammler> and that hash, you find in the mainrepo
23:27:30  <Ammler> not in the mq repo
23:27:55  <Ammler> and that does tell you to which hash the patch is "refreshed"
23:29:57  <GT> yes, clear, but then the patch queue maintainer knows to which rev the main repo and the patch stack is updated to, and he should tag the queue with that rev.
23:30:34  <Brot6> #openttdcoop Client Patch Pack - Revision 6:5da8dc01dc23: Added tag r20145 for changeset 9005c0c5... (Ammler) @
23:31:19  <Ammler> that should now create a repo and apply those patches
23:33:41  <Brot6> #openttdcoop Client Patch Pack - Revision 7:fc25643a7a0c: Change: enable release building (Ammler) @
23:35:21  <Brot6> #openttdcoop Client Patch Pack - Bug #1396 (New): 78 (compiler) @
23:37:07  <Brot6> Autopilot - Revision 84:291b51f5d8d5: Feature: configurable endargs to the command (Ammler) @
23:37:25  *** thgergo has quit IRC
23:40:39  *** Westie has quit IRC
23:42:47  <GT> Well, time to sleep, cu soon
23:43:11  <GT> bye
23:44:41  *** GT has left #openttdcoop.devzone
23:48:45  *** KenjiE20 has quit IRC
23:49:46  *** Westie has joined #openttdcoop.devzone
23:54:41  <Brot6> clientpatches: compile of r20145 still failed (#1396) -

Powered by YARRSTE version: svn-trunk