Log for #openttdcoop.devzone on 26th February 2012:
Times are UTC Toggle Colours
00:05:56  *** Zuu has quit IRC
00:17:33  *** Zuu_ has quit IRC
01:05:33  *** JVassie has quit IRC
02:05:58  *** frosch has joined #openttdcoop.devzone
02:12:36  *** frosch123 has quit IRC
02:51:11  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Support #3738 (New): Multi-car consists (Leanden) @
02:53:15  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Support #3728 (Feedback): Resized tem... (Leanden) @
03:33:51  *** frosch has quit IRC
08:00:32  <Brot6> GRFCodec - Revision 907:98f074743759: -Fix: missing newline in grfstrip help (Rubidium) @
08:00:32  <Brot6> GRFCodec - Revision 908:81c7bcabb99d: -Fix: show the error message that the filename could not be... (Rubidium) @
08:00:32  <Brot6> GRFCodec - Revision 909:4b7b49d3e2bb: -Change: ignore WITH_PNG in NFORenum. We know NFO with PNG ... (Rubidium) @
08:00:33  <Brot6> GRFCodec - Revision 910:1315cae63dc6: -Change: let GRFCodec fail more clearly when it encounters ... (Rubidium) @
08:02:30  <Brot6> NFORenum - Feature #1751 (Closed): How to use escape for a part of a field? (Rubidium) @
08:12:56  <Brot6> GRFCodec - Revision 911:bad952310a69: -Feature-ish: when in a base GRF do not warn about the shor... (Rubidium) @
08:12:56  <Brot6> NFORenum - Bug #2013 (Closed): nforenum warns about action5 sprite count for shore tiles in base ... (Rubidium) @
08:19:46  *** Zuu has joined #openttdcoop.devzone
08:20:46  <Brot6> GRFCodec - Revision 912:e9247c67bef1: -Change: do not warn when there are more than the prescribe... (Rubidium) @
08:20:46  <Brot6> GRFCodec - Revision 913:b11be37d419d: -Change: do not warn when the NewGRF uses a base GRF GRF ID (Rubidium) @
08:49:19  *** ODM has joined #openttdcoop.devzone
09:37:20  *** Zuu has quit IRC
09:45:51  *** Doorslammer has joined #openttdcoop.devzone
09:53:29  *** Doorslammer has quit IRC
09:59:26  <Jupix> Yexo: thanks for the headsup on cgtextures
10:03:06  <planetmaker> Jupix, I think the statement was "releasing those textures is not allowed"
10:03:30  <planetmaker> (in an OSS package)
10:03:40  <Jupix> derivative works also and that includes renders of models where those textures are used
10:04:34  <Jupix> it's not a huge issue. just need to replace those textures with open ones
10:04:43  <planetmaker> yep, of course
10:05:14  <planetmaker> then I mis-understand how you use "heads up" on something :-)
10:06:03  <planetmaker> (I use to interpret it as "it's a good thing keep going"
10:06:49  <planetmaker> which these textures aren't. But there are many OSS projects which have many nice textures
10:07:24  <Jupix> I use this interpretation:
10:07:26  <Webster> Title: heads-up - definition of heads-up by the Free Online Dictionary, Thesaurus and Encyclopedia. (at
10:08:07  <planetmaker> interesting. Thanks, seems i have to re-learn that word
10:08:22  <planetmaker> false friend with German language
10:18:05  <Rubidium> interesting... grfcodec and nml have a different idea whether a sprite should be saved chunked or not
10:18:19  *** JVassie has joined #openttdcoop.devzone
10:24:47  <planetmaker> as with best compression?
10:28:26  <Rubidium> yep
10:28:51  <Brot6> GRFCodec - Revision 914:e57d314be5f7: -Fix-ish: account for the 4 extra grf container version 2 b... (Rubidium) @
10:31:55  <Rubidium>
10:32:34  <Rubidium> it's all quite insignificant, but still ;)
10:34:53  <planetmaker> interesting... it will save nearly 1MB from a full OpenGFX then later
10:43:34  <Rubidium> I wouldn't say that just yet
10:44:03  <Rubidium> it might be that the NML compressor is better at larger 'data sets'
10:45:56  <planetmaker> well, but iirc sprites in (New)GRFs have no choice which way they get compressed (if at all)? Or do I err?
10:49:46  <Rubidium> well, there's chunked and non-chunked encoding
10:50:11  <Rubidium> given OpenTTD re-encodes them after loading them it doesn't matter at all which one to use. For TTDP it might matter though
10:50:52  <Rubidium> so grfcodec -n and nml try both schemes, then LZ77-ish compress that and compare the compressed sizes
10:51:15  <Rubidium> given the LZ77 compressors probably aren't equal, you'd have a difference there
10:51:44  <Rubidium> which is why GRFCodec and NML decide differently on what to store chunked and what to store non-chunked
10:52:07  <Rubidium> so I think the major difference is in the actual compressor and the rest is relatively insignificant
10:52:51  <Rubidium> although NML's comparison could be improved similar to r914 of GRFCodec, though that's probably a relatively small part of the difference
11:02:15  <planetmaker> well. For TTDP it's about irrelevant when we speak of grf v8 or nfo v32. Hm, but so the LZ77 has a 'dictionary' which differs then...
11:05:04  <Rubidium> well, the compressor's algorithm probably differs a bit
11:06:03  *** LordAro has joined #openttdcoop.devzone
11:10:30  <Brot6> Dutch Trains 2.0 - Revision 254:db5ad6aec5e2: Feature: finish HS-DD coach (issue #2951, issue #3345) (foobar) @
11:10:30  <Brot6> Dutch Trains 2.0 - Revision 255:ebbbbf200dd7: Feature: finish HIJSM 4-8-10 coach (issue #2951, is... (foobar) @
11:12:16  <LordAro> why do the logs for the last couple of days not appear to be working?
11:13:11  <planetmaker> which logs?
11:13:18  <LordAro> correction: why is it that 24th and 25th feb do not work?
11:13:24  <LordAro> e.g.
11:14:40  <planetmaker> I think the idea was to not have logs of this channel ;-)
11:15:42  <LordAro> for 2 specific days? :P
11:15:46  <LordAro> 26th works
11:21:57  <planetmaker> hm :-) Then I don't know
11:40:33  <Yexo> Rubidium: interesting, nmlc lz77 implementation was made with grfcodec's code as reference
13:19:07  *** Doorslammer has joined #openttdcoop.devzone
13:39:19  <Brot6> Japanese Landscape - Code Review #3705 (Feedback): Comments & suggestions (dandan) @
13:41:20  <Brot6> Japanese Tracks - Feature Request #3615 (Closed): Use new track type label scheme (dandan) @
13:43:42  <Brot6> Japanese Landscape - Revision 10:832fa3e7c026: Use darker rice field graphics (dandan) @
13:47:05  *** LordAro has quit IRC
13:49:36  <planetmaker> The server needs a restart. We'll be back shortly
13:58:04  *** Webster has joined #openttdcoop.devzone
13:58:06  *** Brot6 has joined #openttdcoop.devzone
13:58:21  *** ^ekipS^ has joined #openttdcoop.devzone
13:58:23  *** Yexo- has joined #openttdcoop.devzone
13:58:54  *** pm has joined #openttdcoop.devzone
13:59:03  *** V453000 has quit IRC
13:59:13  *** ^Spike^ has quit IRC
13:59:13  *** ^ekipS^ is now known as ^Spike^
13:59:25  *** planetmaker has quit IRC
13:59:25  *** pm is now known as planetmaker
13:59:25  *** tneo- has joined #openttdcoop.devzone
13:59:31  *** XeryusTC has quit IRC
13:59:31  *** avdg has quit IRC
13:59:38  *** Yexo has quit IRC
13:59:41  *** Ammller has joined #openttdcoop.devzone
13:59:50  *** Terkhen has quit IRC
13:59:53  *** Ammler has quit IRC
13:59:55  *** tneo has quit IRC
13:59:55  *** Ammller is now known as Ammler
13:59:55  *** Guest4082 has quit IRC
14:00:22  *** Terkhen has joined #openttdcoop.devzone
14:00:47  *** XeryusTC has joined #openttdcoop.devzone
14:00:52  *** V453000 has joined #openttdcoop.devzone
14:01:23  *** avdg has joined #openttdcoop.devzone
14:04:35  <Brot6> NewGRF Meta Language - Feature #3739 (New): Extended action1 (Hirundo) @
14:09:00  *** andythenorth has joined #openttdcoop.devzone
14:21:23  <Brot6> Japanese Landscape - Code Review #3705: Comments & suggestions (PaulC) @
14:26:34  *** frosch123 has joined #openttdcoop.devzone
14:33:34  *** Yexo- is now known as Yexo
14:48:02  <Brot6> Dutch Trains 2.0 - Revision 256:763c4682c15d: Feature: finish remaining historic passenger wagons... (foobar) @
14:48:03  <Brot6> Dutch Trains 2.0 - Revision 257:00c0715308f9: Feature: finish historic mail wagons (issue #3345) (foobar) @
14:58:46  *** V453000 has quit IRC
14:58:46  *** Ammler has quit IRC
14:58:46  *** planetmaker has quit IRC
14:58:47  *** avdg has quit IRC
14:58:47  *** Terkhen has quit IRC
14:58:47  *** Yexo has quit IRC
14:58:47  *** ^Spike^ has quit IRC
14:58:47  *** SmatZ has quit IRC
14:58:47  *** Hirundo has quit IRC
14:58:47  *** XeryusTC has quit IRC
14:58:47  *** tneo- has quit IRC
14:59:48  *** Hirundo has joined #openttdcoop.devzone
14:59:58  *** SmatZ has joined #openttdcoop.devzone
15:00:18  *** Yexo has joined #openttdcoop.devzone
15:00:43  *** planetmaker has joined #openttdcoop.devzone
15:00:48  *** avdg has joined #openttdcoop.devzone
15:01:03  *** tneo has joined #openttdcoop.devzone
15:01:14  *** Ammler has joined #openttdcoop.devzone
15:02:18  *** ^Spike^ has joined #openttdcoop.devzone
15:02:18  *** Terkhen has joined #openttdcoop.devzone
15:02:48  *** V453000 has joined #openttdcoop.devzone
15:02:50  *** XeryusTC has joined #openttdcoop.devzone
15:20:25  <Brot6> NewGRF Meta Language - Revision 1838:5b4055b7f812: Add: Regression test for font_glyph (Hirundo) @
15:20:25  <Brot6> NewGRF Meta Language - Revision 1840:2a349d7c0ed4: Fix: Rename all occurences of 'base_sprites' t... (Hirundo) @
15:20:25  <Brot6> NewGRF Meta Language - Revision 1839:d7625535e8c9: Codechange: Refactor replace[new] blocks to wo... (Hirundo) @
15:20:28  <Brot6> NewGRF Meta Language - Revision 1841:3e01f866df87: Codechange: Refactor base_graphics to work wit... (Hirundo) @
15:20:31  <Brot6> NewGRF Meta Language - Revision 1842:82dc4e8f60b4: Add: Regression test for base graphics. (Hirundo) @
15:20:35  <Brot6> NewGRF Meta Language - Revision 1843:e7a1b56d4c8a: Codechange: Refactor spriteset to work with th... (Hirundo) @
15:20:39  <Brot6> NewGRF Meta Language - Revision 1844:ea44046b144c: Codechange: Move the call to get_all_sprite_da... (Hirundo) @
15:20:43  <Brot6> NewGRF Meta Language - Revision 1845:6f69b96cf8a7: Feature: Let the alt_sprites block accept a 'b... (Hirundo) @
15:21:50  <Hirundo> Yexo: Stage one done ^^
15:21:57  <Yexo> already reading it :)
15:23:08  <Hirundo> now, time to extend the nfo/grf output
15:26:43  <Yexo> Hirundo: where did the heights in r1838 come from?
15:26:53  <planetmaker> <-- Hirundo, from that diff: do you set 32bpp blitter when defining any alternative sprites?
15:27:06  <Yexo> openttd uses 6/10/18 px as height for sprite fonts
15:27:25  <Hirundo> Yexo: AFAIK I copied something from ogfx
15:27:34  <Yexo> ok
15:27:45  <Hirundo> planetmaker: yes, diff line 8.8 (
15:28:17  <planetmaker> that's not really sensible when only defining 8bpp zoom sprites, or?
15:28:21  <Yexo> opengfx uses 8/13/21 indeed
15:28:33  <planetmaker> yes... ^
15:28:38  <planetmaker> which is problematic
15:28:41  <planetmaker> but it does
15:28:51  <Yexo> should be 8/12/20 I think
15:28:55  <Hirundo> r1845 changes alt_sprites to set any_32bpp sprites iff the alt_sprites are actually 32bpp instead of 8bpp
15:29:07  <planetmaker> ok :-)
15:29:13  <Hirundo> Yexo: Did you already add something for masks?
15:29:25  <Yexo> nope
15:29:44  <Yexo> wasn't sure what exactly you were coding and didn't want to cause conflicts
15:29:47  <planetmaker> I wasn't at r1845 yet
15:32:11  <Hirundo> Yexo: actually, hg blame tells me mask files were added in r1682 (oct 11)
15:32:52  <Yexo> well, yes
15:33:16  <Yexo> but that implementation forces all parameters of the mask to be exactly the same as for the sprite with one exception: the filename
15:33:20  <Hirundo> < didn't know that
15:35:23  <Yexo> it seems I never documented that :(
15:35:35  <Yexo> we could keep using that,what do you think?
15:36:16  <Hirundo> makes sense
15:36:33  <Hirundo> I guess you'll use the same layout for mask and normal sprites 99% of the time
15:37:08  <Hirundo> 'mask' could be amended later to be either a "file" or ["file"[, xoffs, yoffs]]
15:37:38  <Yexo> not xoffs/yoffs but left_x/upper_y
15:38:06  <Yexo> you probably meant the correct thing, but it's confusing
15:38:13  <Hirundo> exactly
15:38:48  <Yexo> can I help with any part?
15:39:44  <Hirundo> not atm, I think
15:52:36  <Hirundo> How do empty real sprites work as part of a multi-part sprite? (both in grf and nfo)
15:53:52  *** andythenorth has quit IRC
15:56:09  <Yexo> suppose you have a special sprite for a rail vehicle for in the build gui
15:56:19  <Yexo> you need a spriteset with 8 sprites, but 7 of those will be unused
15:56:49  <Yexo> instead of manually creating an empty sprite and putting it there, you put an empty sprite
15:57:54  <Yexo> no realsprite should be written for those if possible, but I'm not sure it is, otherwise a 1x1 transparant image should be written
15:57:55  <Hirundo> Yes, I know that
15:58:19  <Hirundo> Current NFO syntax is "-1 * 1 00"
15:58:28  <Hirundo> that doesn't seem to lend itself very well to extension
15:58:42  <Yexo> that's basically a pseudo-sprite of length 0
16:00:11  <Hirundo> afaik length 1, binary 0
16:00:30  <Yexo> hmm, right
16:04:21  <Hirundo> Is there a real benefit of using that, instead of a 1x1 blue pixel?
16:06:46  <Yexo> probably not
16:07:21  <Hirundo> saves a few bytes, I guess
16:08:04  <Hirundo> Though I'm not sure, how you'd output an empty sprite in nfo, if other zoom levels are non-empty
16:08:17  <Yexo> not
16:08:24  <Yexo> if one zoom level is empty, all must be empty
16:08:40  <Yexo> or rather: empty 8bpp normal zoom: all zoom levels must be empty
16:08:56  <Yexo> non-empty 8bpp normal zoom: if any other zoom level is empty, don't write it at all and fall back to the 8bpp sprite
16:11:11  <Yexo> or we could simply allow it (in which case we have to use an empty 1x1 pixel)
16:20:17  *** Doorslammer has quit IRC
16:26:55  *** andythenorth has joined #openttdcoop.devzone
16:28:33  <Hirundo> Yexo: Are recolour sprites still written to the data section?
16:30:14  <Yexo> not sure, frosch123  / Rubidium? ^^
16:35:46  <Yexo> actually, yes, I'm quite sure they're still written to the data section
16:35:58  <Yexo> that part is already implemented in nml
16:36:04  <frosch123> i would have said "no", but cannot remember either :)
16:36:19  <frosch123> but likely grfcodec cannot distinguish them
16:37:21  <Yexo> grfcodec cannot distinguish a recolor sprite from other pseudo-sprites (you need to parse the sprites to do that, which grfcodec doesn't do), so it must store them in the data section like other pseudo sprites
16:37:42  <Hirundo> makes sense
16:37:51  <frosch123> yeah, but i wonder whether ottd supports both
16:38:11  <Hirundo> consequence is, that you cannot have alternative_sprites for recolour sprites
16:38:32  <frosch123> if we ever want to compress the data section, it would either have to load the recolour sprites permanently into the spritecache, or they may not be in the data section
16:38:37  <Yexo> but do alternative sprites for recolour sprites make sense at all?
16:38:37  <planetmaker> does that make sense, though?
16:38:46  <Hirundo> no
16:38:53  <frosch123> alternative sprites for recolour sprite? no :)
16:39:08  <Hirundo> but it needs code to check, which is important to me right now :-)
16:39:31  <frosch123> there are no alternative sounds either :)
16:39:40  <frosch123> only realsprites have the zoomlevel and bitdepth bytes
16:39:43  <planetmaker> now, that'd be weired :-)
16:40:04  <frosch123> actually, alternative sounds per zoomlevel would make sense
16:40:10  <planetmaker> like in zoom-out the train makes 'moo' and looks like a cow. And zoomed-in it makes 'woof' and looks like a dog? :-P
16:40:16  <planetmaker> would it?
16:40:36  <frosch123> you would only hear birds when zoomed in
16:40:46  <Hirundo> Yexo: Is there any specific reason why RecolourSpriteAction extends RealSpriteAction?
16:40:52  * planetmaker sees a nice desync there, though
16:41:26  <Yexo> no
16:41:30  <Hirundo> Only thing I see is that both may have a sprite_num set by base_graphics
16:41:30  <frosch123> newgrfs cannot tell whether a sound is playing or not
16:42:34  <andythenorth> planetmaker: when does it make 'moof' ?
16:42:51  <Yexo> when you zoom out :p
16:45:39  <planetmaker> :-)
16:51:15  <Brot6> NewGRF Meta Language - Revision 1846:9ef6563d95a1: Fix : Real sprite lists may contain unexpanded... (Hirundo) @
17:05:04  <michi_cc> frosch123: OpenTTD does load recolour sprites permanently into the sprite cache (it didn't before).
17:05:49  <frosch123> so nml could very well put them not in the data section :)
17:08:21  <michi_cc> It even has to, as OpenTTD will fail otherwise currently.
17:09:23  <frosch123> what? does ottd have to load them permanently, or must recolour sprites not go into the data section?
17:09:40  <michi_cc> They must not go into the data section.
17:10:09  <frosch123> eugh... so what does grfcodec do with them?
17:10:17  <Yexo> now I wonder how grfcodec handles that
17:10:36  <michi_cc> Oh, sorry, no of course they must not go into the sprite section :)
17:11:07  <michi_cc> Recolour sprites are pseudo-sprites and go where all other pseudo-sprites go.
17:12:47  <Brot6> grfcodec: update from r906 to r914 done -
17:18:49  <Brot6> nml: update from r1834 to r1846 done -
17:20:09  <Yexo> so how does openttd handle them?
17:25:04  <frosch123> michi said, they are loaded permanently into the spritecache when loading the grf
17:25:28  <frosch123> so, the data section can be made compressed
17:36:48  <michi_cc> Yes. Everything in the data section is loaded on the spot, and everything in the sprite section (currently real sprites and sounds) is loaded on-demand.
17:37:35  <Hirundo> so zooming in for the first time can create a noticeable lag?
17:38:17  <michi_cc> No, as OpenTTD loads all zoom levels at the same time. Scrolling could though in theory.
17:38:54  <michi_cc> Zooming out also, because there might be lots of not loaded sprites previously not visible.
18:06:35  <Brot6> OpenGFX - Bug #3719 (Closed): DevZone compile failed (compiler) @
18:06:35  <Brot6> OpenGFX - Bug #3719 (Closed): DevZone compile failed (planetmaker) @
18:07:26  <Brot6> OpenGFX - Bug #3722 (Closed): DevZone compile failed (compiler) @
18:07:26  <Brot6> OpenGFX - Bug #3722 (Closed): DevZone compile failed (planetmaker) @
18:10:56  <Brot6> OpenGFX - Bug #3729: Snow issues (planetmaker) @
18:50:32  <Brot6> OpenGFX - Bug #3729: Snow issues (PaulC) @
19:01:54  <Brot6> OpenGFX - Bug #3729: Snow issues (PaulC) @
19:07:11  <planetmaker> Ammler, I guess with the 32bpp sprites we might want to up the attachment size for the DevZone
19:07:26  <planetmaker> According to Jupix it'll need something like 10MB+
19:13:09  <Brot6> BANDIT - Revision 294:6ff07ca3424c: Codechange: various docs and other things (andythenorth) @
19:15:14  <Brot6> GRFCodec - Revision 915:24c7f0b56e46: Feature: support cargo-type 0x0A in Action3 Railtypes (yexo) @
19:30:47  *** andythenorth has quit IRC
19:31:11  *** andythenorth has joined #openttdcoop.devzone
19:36:59  <Rubidium> Yexo: oh, so the nml lz77 isn't a standard library (I assumed it was)
19:37:55  <Yexo> I wasn't able to find one at the time
19:39:36  <Rubidium> but that definitely makes the difference more interesting ;)
19:40:38  <Yexo> my first guess would be an off-by-one when encoding large sprites
19:40:57  <Yexo> it probably doesn't encode large transparant areas as efficient as possible
19:49:27  <Brot6> Dutch Trains 2.0 - Revision 258:a6c84215f91a: Feature: finish old cargo wagons (issue #2951, issu... (foobar) @
19:49:27  <Brot6> Dutch Trains 2.0 - Revision 259:63313261eae9: Feature: finish remaining cargo wagons (closes #295... (foobar) @
19:49:27  <Brot6> Dutch Trains 2.0 - Revision 260:9199bdaae6ce: Change: use same running cost base and engine class... (foobar) @
19:49:31  <Brot6> Dutch Trains 2.0 - Feature #2951 (Closed): Livery options (foobar) @
19:49:34  <Brot6> Dutch Trains 2.0 - Feature #3345 (Closed): Vehicle properties (foobar) @
20:22:07  <Rubidium> reduces the file size of nml slightly, though I still see differences in the compressor output for some reason
20:23:03  <Yexo> feel free to commit that :)
20:23:25  <Yexo> if you've set that up that is, I can commit it otherwise
20:25:28  <Brot6> NewGRF Meta Language - Revision 1847:e4d8d66f78ed: Codechange: reduce the file size of GRFs sligh... (Rubidium) @
20:26:06  <Rubidium> that's 51 of the 708 bytes difference for arctic
20:44:34  <Yexo> there is one difference I can spot in the lz77 code between nml and grfcoded: nml encodes a non-compressed chunk up to 128 bytes while grfcodec will stop at 127 bytes
20:45:57  <Rubidium> yup, though changing that doesn't change the size for arctic. It makes the file more equal to the grfcodec one
20:46:26  <Rubidium> it might be an improvement to use 128 bytes in grfcodec as well, but that'll be relatively insignificant I fear
20:46:36  <Yexo> yes
20:47:03  <Yexo> it only matters when there are either exactly 128 bytes in a block or 255+ bytes
20:47:05  <Yexo> both are unlikely
20:48:34  <Rubidium> exactly
20:48:52  <Rubidium> I've seen it at least twice in arctic though
20:49:57  <Rubidium> @base 16 10 9f
20:49:57  <Webster> Rubidium: 159
20:51:19  <Yexo> do you know on which sprites there is a difference?
20:51:47  <Rubidium> 158
20:51:55  <Rubidium> but they're differently encoded
20:52:02  <Rubidium> (or arctic)
20:52:42  <Rubidium> grfcodec is chunked, nml isn't
20:52:51  <Rubidium> grfcodec is 1 byte smaller than nml
20:53:10  <Rubidium> 0x289 vs 0x28a
20:56:17  <Rubidium> is the difference
20:57:01  <Rubidium> I've decoded and encoded with grfcodec this time without GRFCodec redetermining the best compression (so it uses NML's decided compression type)
20:57:25  <Yexo> I (accidentally) did that too, there is still a difference
20:57:53  <Yexo> hmm, seems to make no difference
20:58:34  <Yexo> sorry, flawed testing, it does make a difference
21:00:07  <Brot6> GRFCodec - Bug #3740 (New): Can't compile grfcodec anymore (Snail) @
21:00:39  <Rubidium> augmented the diff with the preceeding bytes from the begin of the sprite
21:04:50  <Brot6> GRFCodec - Bug #3740: Can't compile grfcodec anymore (Rubidium) @
21:05:24  <Rubidium> on the other hand, the first bit probably isn't a big problem as it's still the same size
21:12:11  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Revision 12:1c971e64cc20: Fix: #3735,... (oberhuemer) @
21:12:11  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Revision 13:c20887a52740: merge (oberhuemer) @
21:12:11  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Bug #3735 (Closed): GRF isn't being c... (oberhuemer) @
21:15:52  <Brot6> GRFCodec - Bug #3740: Can't compile grfcodec anymore (Snail) @
21:16:10  <Brot6> britrains: update from r11 to r13 done (4 warnings) -
21:17:53  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Revision 14:b0f01521281b: Fix: 390 sp... (oberhuemer) @
21:21:09  <Brot6> britrains: update from r13 to r14 done (4 warnings) -
21:28:07  <Yexo> the difference is not in lz77 but in the tile (chunked) encoding part
21:28:15  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Revision 15:5480a05f5cf3: Fix: remove... (oberhuemer) @
21:28:58  <Yexo> nml takes a shortcut that leads to problems with sprites that have a (large) transparent area in the middle of a line (between non-transparant pixels)
21:29:56  <Rubidium> yup
21:30:39  <Rubidium> (or at least, it's the chunked encoding that's different)
21:30:41  <Yexo> does grfcodec -n -g 1 work properly with very wide sprites?
21:30:56  <Yexo> my guess it is errors out in encodetile
21:31:06  <Yexo> sprites.cpp:690
21:31:19  <Rubidium> I guess that might fail yes
21:32:10  <Brot6> britrains: update from r14 to r15 done (4 warnings) -
21:35:23  <Rubidium> but if it's a shortcut in the tile encoding, then you more or less know about it and I won't dig deeper
21:35:37  <Yexo> that's fine :)
21:36:09  <andythenorth> 'colour' or 'color'  ?
21:36:15  <Yexo> for specific sprites it can also be an improvement
21:36:18  <andythenorth> or avoid the issue, and call it 'hue' ?
21:36:25  <andythenorth> for variable and method and class names
21:36:30  <Yexo> I have a testcase now where nml performs better than grfcodec
21:36:34  <Rubidium> andythenorth: you're british, right?
21:36:44  <Yexo> so it's a "shortcut" that can optimize in certain cases
21:36:44  <Rubidium> so colour ;)
21:37:01  <andythenorth> recolor sprites though :P
21:38:02  <Yexo> tile compression is basically: for each line: skip transparant parts, encode normal parts, after that compress using lz77
21:38:39  <Yexo> nml skips the transparant parts at the beginning and end of a line and always encodes the part in the middle normally, grfcoded encodes all parts seperately
21:39:01  <frosch123> andythenorth: ottd uses BE consistently, that's why the blitter are called 32/8bpp-optimized :p
21:39:09  <Yexo> so if there is a single transparant pixel in the middle nml is more efficient (lower overhead), while if there is a larger transparant block grfcodec is more efficient
21:39:40  <andythenorth> I could duck the issue and use 'col', but my brain parses it as 'column'
21:39:55  <Yexo> I don't think there is an easy way to determine the best way to encode
21:40:25  <Rubidium> how much overhead is there in encoding transparency?
21:40:27  <Yexo> probably something hardcoded like "<=3 transparant pixels: just encode it, >3 pixels: skip it" is the best achievable solution
21:40:55  <Yexo> 2 bytes (or 4 for long chunks)
21:41:32  <Yexo> but there is a maximum to the length of each chunk, so if you have to split it up anyway you better do so at a transparant pixel (if possible)
21:42:09  <Yexo> but then: all this is done before lz77 compression, so even if it might be one byte less in some line it can lead to worse compression later on
21:42:12  <Rubidium> oh... TMWFTLB ;)
21:42:33  <Yexo> yep :)
21:43:00  <Yexo> I'll probably try to change NML's code to work exactly like grfcodec, just to verify after that they do exactly the same
21:45:37  <Brot6> NewGRF Meta Language - Code Review #3741 (New): Tile (=chunked) compression (yexo) @
21:46:04  <Yexo> thanks for your work Rubidium, identifying sprite 158 in opengfx arctic made it a lot easier to find
21:47:06  *** frosch123 has quit IRC
21:48:13  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Revision 16:7033afbdc0aa: Fix: #3735,... (oberhuemer) @
21:51:53  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Bug #3742 (New): DevZone compile failed (compiler) @
22:01:04  * andythenorth writes a kind of unit test
22:01:07  <andythenorth> how quaint
22:01:19  <andythenorth> more of a guard than a unit test tbh
22:01:32  <Brot6> GRFCodec - Bug #3740: Can't compile grfcodec anymore (Rubidium) @
22:01:48  * Rubidium pokes planetmaker to see whether he can confirm #3740
22:01:48  <Brot6> Rubidium: #3740 is "GRFCodec - Bug #3740: Can't compile grfcodec anymore - #openttdcoop Development Zone"
22:02:21  <planetmaker> Rubidium, no, I can't
22:03:09  <planetmaker> I basically asked the questions you asked. And upon "reply" you answered already
22:05:52  <planetmaker> Even though I have even the same minor version of the OS as he does.
22:06:46  <andythenorth> I should try?
22:07:02  <planetmaker> if you care. Might be interesting
22:07:12  <planetmaker> did you do so before? I guess...
22:07:23  <andythenorth> I have 10.6.8
22:07:25  <andythenorth> so not same
22:07:29  <planetmaker> not?
22:07:29  * andythenorth tries anyway
22:07:41  <andythenorth> oops
22:07:48  <andythenorth> I read 10.6.6 for snail
22:07:54  <andythenorth> eyes need testing
22:09:08  <andythenorth> I did 'make clean' then 'time make all'
22:09:13  <andythenorth> builds fine, 31s
22:09:37  <Brot6> GRFCodec - Bug #3740: Can't compile grfcodec anymore (Snail) @
22:09:51  <andythenorth> I have r915 grfcodec
22:12:15  <Brot6> NewGRF Meta Language - Revision 1840:2a349d7c0ed4: Fix: Rename all occurences of 'base_sprites' t... (Hirundo) @
22:12:15  <Brot6> GRFCodec - Bug #3740: Can't compile grfcodec anymore (andythenorth) @
22:13:24  <Rubidium> thanks for confirming it isn't just Mac OS X gone haywire in general ;)
22:13:44  <Rubidium> but it basically means: unreproducable and unsolveable
22:13:49  <Brot6> BANDIT - Revision 295:c88747eb9c19: Codechange: refactor some names, add start of sequence and se... (andythenorth) @
22:13:49  <Brot6> BANDIT - Revision 296:8c9e0892c176: Codechange: remove apparently unneeded list (andythenorth) @
22:13:49  <Brot6> BANDIT - Revision 297:48416bbc0db8: Codechange: PixaSequenceCollection and PixaMixer basically no... (andythenorth) @
22:13:51  <Brot6> BANDIT - Revision 298:c9c2a1bb5e3d: Codechange: do a little towards making coloursets work (andythenorth) @
22:14:09  * andythenorth got into a coding mood
22:14:13  <andythenorth> but is now in bed mood
22:14:16  <Rubidium> so about the right time to do lots in the third dimension
22:14:52  <Brot6> GRFCodec - Bug #3740: Can't compile grfcodec anymore (planetmaker) @
22:15:47  * andythenorth wonders if this code will look stupid in the morning
22:15:56  <andythenorth> passing around custom functions with options dicts :P
22:16:17  * andythenorth wonders if anyone will ever need a custom colour-transform
22:16:32  * andythenorth goes to sleep
22:16:33  <andythenorth> bye
22:16:35  *** andythenorth has quit IRC
22:22:42  <Brot6> NewGRF Meta Language - Revision 1848:2f938e394c73: Feature #3712: Allow outputting multiple sprit... (Hirundo) @
22:22:42  <Brot6> NewGRF Meta Language - Revision 1849:28e1c7341776: Feature #3712: Store zoom level and bit depth ... (Hirundo) @
22:22:42  <Brot6> NewGRF Meta Language - Revision 1851:92fe8b5bce03: Cleanup: Remove some dead code. (Hirundo) @
22:22:43  <Brot6> NewGRF Meta Language - Revision 1850:6e9e4aec6875: Add: Some (quite useless) alternative sprites ... (Hirundo) @
22:22:47  <Brot6> NewGRF Meta Language - Revision 1852:d2cd444671d3: Feature(tte): Labels for recolour sprites, as ... (Hirundo) @
22:22:51  <Brot6> NewGRF Meta Language - Revision 1853:f3830bb211d9: Codechange: Don't make RecolourSpriteAction in... (Hirundo) @
22:23:47  <Brot6> NewGRF Meta Language - Feature Request #3712: New 32 bpp format (Hirundo) @
22:24:31  <Brot6> NewGRF Meta Language - Feature Request #3712: New 32 bpp format (Hirundo) @
22:24:48  <Hirundo> Yexo: Almost done...
22:24:56  <Yexo> great :)
22:25:06  <Yexo> some code to read in the train tomorrow :)
22:25:09  <Yexo> good night
22:25:18  <Hirundo> goodnight
22:29:22  <planetmaker> nice, Hirundo
22:33:38  *** ODM has quit IRC
23:18:20  *** JVassie has quit IRC
23:39:37  <Brot6> Central European Train Set - Revision 648:ea7bb5958094: some incomplete and probably wrong attemp... (Eddi) @
23:39:37  <Brot6> Central European Train Set - Revision 649:cce232900d6a: misc tracking table updates that somebody... (Eddi) @
23:44:16  <Brot6> Central European Train Set - Bug #3743 (New): DevZone compile failed (compiler) @
23:56:06  <Hirundo> ^^ It's quite possible that NML contains errors at this point, please file a bug report if you think you found any

Powered by YARRSTE version: svn-trunk