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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/e107a6f1589b 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) @ http://dev.openttdcoop.org/issues/1388 09:13:42 <Brot6> OpenGFX - Revision 520:670823c18970: Fix #1388 (r450): No more broken glass on station roofs (planetmaker) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/670823c18970 09:13:42 <Brot6> OpenGFX - Bug #1388 (Closed): check station roofs' transparency (planetmaker) @ http://dev.openttdcoop.org/issues/1388#change-3712 09:21:54 <Brot6> OpenGFX - Feature #839: 4737-4742: Fizzy drink factory (planetmaker) @ http://dev.openttdcoop.org/issues/839#change-3713 09:28:38 <Brot6> OpenGFX - Feature #1255: Gumdrops for Toyland Lighthouse and Radio Antenna (planetmaker) @ http://dev.openttdcoop.org/issues/1255#change-3714 10:25:46 <Brot6> FIRS Industry Replacement Set - Feature #1389 (Assigned): For INCOMPATIBLE_VERSION14, state what ... (foobar) @ http://dev.openttdcoop.org/issues/1389 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) @ http://dev.openttdcoop.org/issues/1389#change-3715 10:47:16 <Brot6> FIRS Industry Replacement Set - Feature #1303: Include action14 strings into translations (planetmaker) @ http://dev.openttdcoop.org/issues/1303#change-3716 10:49:03 <Brot6> FIRS Industry Replacement Set - Feature #1305: Detect missing strings (planetmaker) @ http://dev.openttdcoop.org/issues/1305#change-3717 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) @ http://dev.openttdcoop.org/issues/1305#change-3717 10:52:04 <Brot6> FIRS Industry Replacement Set - Revision 1313:1014da1cc6f1: Fix #1362: Don't include nfo header t... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/1014da1cc6f1 10:52:04 <Brot6> FIRS Industry Replacement Set - Bug #1362 (Closed): Duplicate NFO header (planetmaker) @ http://dev.openttdcoop.org/issues/1362#change-3718 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) @ http://dev.openttdcoop.org/issues/1389#change-3715 10:58:19 <Brot6> FIRS Industry Replacement Set - Revision 1314:cc8c7b765581: Feature #1305: change to the script l... (Ammler) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/cc8c7b765581 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) @ http://dev.openttdcoop.org/issues/1390 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) @ http://dev.openttdcoop.org/issues/1390#change-3720 11:29:28 <Brot6> FIRS Industry Replacement Set - Feature #1390: Feature: Generate lang/remove_defines.pnfo automat... (Ammler) @ http://dev.openttdcoop.org/issues/1390#change-3720 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) @ http://dev.openttdcoop.org/issues/1390#change-3721 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) @ http://dev.openttdcoop.org/issues/1391 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) @ http://dev.openttdcoop.org/issues/1392 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) @ http://dev.openttdcoop.org/issues/1392 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) @ http://dev.openttdcoop.org/issues/1392#change-3722 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> http://www.longnow.org/ 12:31:36 <Webster> Title: Front Page - The Long Now (at www.longnow.org) 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) @ http://dev.openttdcoop.org/projects/2cctrainset/repository/revisions/471e3fd80adf 15:49:36 <Brot6> 2cc train set - Revision 594:18fb7c9c9cc7: Fix: Forgot to add a file in the prev. rev (DJNekkid) @ http://dev.openttdcoop.org/projects/2cctrainset/repository/revisions/18fb7c9c9cc7 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> http://blog.client9.com/2007/08/python-pil-and-png-metadata-take-2.html <- writing the tEXt chunk should be possible 16:09:44 <Webster> Title: digital sanitation engineering: Python, PIL and PNG metadata, take 2 (at blog.client9.com) 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) - http://bundles.openttdcoop.org/2cctrainset/nightlies/r594 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) - http://bundles.openttdcoop.org/firs/nightlies/r1314 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 - http://bundles.openttdcoop.org/nforenum/nightlies/r484 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) - http://bundles.openttdcoop.org/nutracks/nightlies/r114 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 - http://bundles.openttdcoop.org/opengfx/nightlies/r520 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: http://bundles.openttdcoop.org/firs/nightlies/r1314/log/RELEASE-2.diff 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> http://dev.openttdcoop.org/projects/32bpp-ez-patches/repository/entry/ez.diff 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 http://www.tt-forums.net/viewtopic.php?p=879945#p879945 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 www.tt-forums.net) 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> http://bundles.openttdcoop.org/firs/nightlies/r1314/log/REBUILD/r1314/ <-- 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) @ http://dev.openttdcoop.org/projects/32bpp-extra/repository/revisions/0451ecd5cc53 Powered by YARRSTE version: svn-trunk