Log for #openttdcoop.devzone on 28th February 2012:
Times are UTC Toggle Colours
06:13:07  *** JVassie has joined #openttdcoop.devzone
07:15:38  *** JVassie has quit IRC
08:31:55  <Brot6> OpenGFX - Bug #3729: Snow issues (planetmaker) @
08:41:37  <Brot6> OpenGFX - Bug #3729: Snow issues (planetmaker) @
08:50:02  *** andythenorth has joined #openttdcoop.devzone
09:30:36  <Brot6> FIRS Industry Replacement Set - Revision 2711:235e66f048cc: Docs: update changelog prior to 0.7.1... (andythenorth) @
09:30:36  <Brot6> FIRS Industry Replacement Set - Revision 2712:3c209564d26f: Added tag 0.7.1 for changeset 235e66f... (andythenorth) @
09:37:17  <Brot6> firs: update from 0.7.0 to 0.7.1 done -
09:37:20  <andythenorth> yay
09:37:24  * andythenorth was waiting for that
09:45:54  <andythenorth> that was an unexpected release :)
10:16:31  <planetmaker> it was
11:00:50  <andythenorth> well..we had some WIP
11:00:57  <andythenorth> and I wanted to see if bananas worked
11:34:47  * andythenorth wants to make some FIRS tickets go away
11:34:53  <andythenorth> there an overwhelming number
11:35:13  <Brot6> FIRS Industry Replacement Set - Code Review #3430: 'legacy' tiles in basetiles.pnml (andythenorth) @
13:29:19  *** andythenorth has quit IRC
13:31:26  *** ODM has joined #openttdcoop.devzone
14:16:49  *** Webster` has joined #openttdcoop.devzone
14:17:43  *** Brot6_ has joined #openttdcoop.devzone
14:18:34  *** Webster has quit IRC
14:18:34  *** Webster` is now known as Webster
14:19:05  *** Brot6_ has quit IRC
14:19:25  *** XeryusTC has quit IRC
14:19:25  *** V453000 has quit IRC
14:19:25  *** tneo has quit IRC
14:19:25  *** Yexo has quit IRC
14:19:25  *** Brot6 has quit IRC
14:20:22  *** Brot6 has joined #openttdcoop.devzone
14:20:31  *** Brot6 is now known as Guest4400
14:20:40  *** XeryusTC has joined #openttdcoop.devzone
14:20:40  *** V453000 has joined #openttdcoop.devzone
14:20:40  *** tneo has joined #openttdcoop.devzone
14:20:40  *** Yexo has joined #openttdcoop.devzone
14:20:40  *** Brot6 has joined #openttdcoop.devzone
14:21:12  *** Brot6 has quit IRC
14:21:29  *** Guest4400 is now known as Brot6
14:22:45  *** Brot6 has joined #openttdcoop.devzone
15:34:24  *** andythenorth has joined #openttdcoop.devzone
15:46:46  <Brot6> BANDIT - Revision 305:57f1da81e690: Add: types graphic for NA trucks (andythenorth) @
16:29:21  <Brot6> OpenGFX - Revision 947:ebe597164c9d: Fix #3729: Tile height definition changed in NML 0.3, causin... (planetmaker) @
16:29:21  <Brot6> OpenGFX - Bug #3729 (Closed): Snow issues (planetmaker) @
16:39:23  *** Doorslammer has joined #openttdcoop.devzone
16:42:42  <andythenorth> ho
16:42:53  <andythenorth> so bananas won't upgrade a grf?
16:43:00  * andythenorth didn't know that
16:43:03  <andythenorth> :)
16:43:32  <andythenorth> so even for bug fix releases, players need a new game...
16:43:50  <planetmaker> yes
16:43:55  <andythenorth> it's the usual 'newgrfs can be explodey'
16:44:23  <planetmaker> yup
16:44:25  <andythenorth> even if I know the changes are 100% safe, another grf may still go insane
16:44:54  <planetmaker> it will only resort to a different version if the original version cannot be found
16:45:04  <andythenorth> I could bugfix, another grf was relying on my bug and breaks or disables...
16:45:14  <andythenorth> [among other cases]
16:46:22  <andythenorth> 0.7.2 FIRS for April 1?
16:47:09  <planetmaker> maybe
16:49:36  <andythenorth> it's minor fixes only
16:49:41  <andythenorth> but I seem to be busy ;)
17:04:58  *** Doorslammer has quit IRC
17:14:04  <Brot6> grfcodec: update from r915 to r920 done -
17:21:49  <Brot6> nml: update from r1853 to r1860 done -
17:27:52  <Rubidium> how is one supposed to provide alternative sprites for base_graphics?
17:27:59  <Rubidium> in NML
17:28:33  <Rubidium> alternative_sprites(1145, ZOOM_LEVEL_IN_1x, BIT_DEPTH_32BPP, "32/sprites/ogfx1_base/1145.png") { [ -25. -18 ] }
17:28:37  <Rubidium> doesn't seem to do it
17:28:58  <Rubidium> complaining the name must be an identifier
17:30:13  <planetmaker> I fear it currently is not supposed to work... hm
17:32:45  <Rubidium> if (openttd_version < version_openttd(1, 2, 0, 23232)) {
17:32:50  <Rubidium> that's not needed anymore ;)
17:32:56  <Rubidium> in trunk
17:33:25  <planetmaker> which file?
17:36:37  <planetmaker> a grep for "openttd_version" only gives me a single version check in extra-header.pnml
17:38:51  <planetmaker> but maybe that check should be slightly updated... from 23667 to whatever RC1 is
17:58:52  <Rubidium> for me there are many version check in ogfxe_extra.nml
17:59:35  <Rubidium> most if not all can be removed in ogfx trunk
18:02:32  <planetmaker> in the 0.4 branch there are many. In the default branch there shouldn't be any left
18:03:12  <Rubidium> hmm, am I then in the 0.4 branch?
18:03:29  <planetmaker> possibly?
18:03:52  <planetmaker> what does hg branch tell you?
18:04:03  <Rubidium> 0.4
18:05:48  <Rubidium> planetmaker: I think you can even remove that version check ;)
18:06:05  <Rubidium> as only by then grf container v2 was introduced
18:06:13  <planetmaker> Might be... as it won't work for ^^ reason?
18:06:39  <Rubidium> yep, it'll fail to load the grf anyway
18:07:28  <Rubidium> although the question is when you need that comparison again
18:17:44  <planetmaker> well. Such comparison certainly will be needed at some time again :-) Though much more likely is the need to add conditional cases in other parts of the code than a general version check which disables the grf.
18:33:08  *** Chris_Booth has joined #openttdcoop.devzone
18:33:12  <Chris_Booth> is there a limit howmany refit options a wagon has?
18:33:14  <Chris_Booth> for example could I make a superwagon that could refit to any cargo?
18:41:45  <Yexo> yes, you can do that
18:42:49  <Yexo> Rubidium: "base_graphics some_id(1145, ...) {...}", after that you can do "alternative_sprites(some_id, ....) {...}"
18:42:53  *** frosch123 has joined #openttdcoop.devzone
18:42:56  <Yexo> an undocumented feature :p
18:43:12  <Chris_Booth> aaaah cool
18:46:17  <Chris_Booth> I wonder why no one has made this wagon
18:47:20  <Yexo> because it's boring for gameplay?
18:47:54  *** andythenorth has quit IRC
18:51:04  <Chris_Booth> not quite Yexo it would make refit games have endless possibilities
19:00:03  <Brot6> NewGRF Meta Language - Revision 1861:938dfbe5cfea: Feature: cropping/tile compression for 32bpp s... (yexo) @
19:19:58  <Yexo> how do 32bpp sprites + mask sprites work in openttd?
19:20:25  <Yexo> part of the sprite is in 32bpp, if you want to use company colours you put those in the mask file, but what happens with transparency?
19:23:06  <michi_cc> Nothing? Transparency is by alpha channel.
19:23:57  <Yexo> if (colour_fmt == SCC_PAL && *pixel == 0) sprite->data[i].a = 0x00; <- I was wondering about that line, but missed the difference between == and &
19:24:18  <Yexo> it all makes sense now :)
19:24:42  *** andythenorth has joined #openttdcoop.devzone
19:24:58  <michi_cc> You couldn't use mask == 0 for transparency anyway, as that is already the value for '
19:25:01  <michi_cc> no remap'
19:27:38  <Yexo> is the alpha channel relevant when a remap is done?
19:28:01  <Rubidium> Yexo: so most (if not all) base graphics would need to get IDs, right?
19:28:12  <Yexo> yes
19:28:19  <Rubidium> sounds like a lot of work
19:28:29  <Rubidium> although it's a good moment to look really good at everything
19:28:32  <Yexo> or nml can be changed to allow numeric values for base graphics
19:29:58  <Yexo> this can also help a lot
19:30:15  <Rubidium> yep
19:30:25  <Rubidium> that's the "look really good at everything" method ;)
19:30:35  <Rubidium> group everything in logical chunks
19:30:37  <Yexo> I think that's the best solution anyway
19:30:52  <Yexo> otherwise you'd need to duplicate the mask filename a lot more
19:30:55  <Yexo> like the filename already is
19:34:08  <Rubidium> for 32bpp/ez it might be useful to be able to have somewhat constructed filenames; so sprites/png/infrastructure/monorail_level_crossing_%i.png
19:34:21  <Rubidium> and that depending on the index within the block the %i is substituted
19:35:10  <Rubidium> that way you won't need to specify each of the seperate sprites on all the lines
19:35:36  <Yexo> question is: is that really useful or only because the old format had one sprite per file?
19:36:36  <Yexo> also any kind of filename depending on position is block doesn't play very nice with templates
19:37:13  <Yexo> it can still work, but it's much less obvious what the actual position is in that case
19:37:25  <Rubidium> true
19:37:42  *** JVassie has joined #openttdcoop.devzone
19:40:37  <Rubidium> I'm also wondering if 32bpp or EZ sprites should be in the same PNG per (logical) block or not
19:41:34  <Rubidium> NML should, in theory, be faster if you're working with only seperate sprites, right? Since it loads the PNGs from disk every time
19:41:38  <Yexo> I think for manually drawn sprites they should, but as soon as the sprites are generated by rendering a 3d model it's probably easier to have them in different files
19:41:44  <Yexo> currently yes
19:44:48  <Rubidium> which somewhat sucks with templates as they work with one file, right?
19:45:33  <Yexo> you could have a template argument for every file, but otherwise yes
19:46:15  <Rubidium> and that's basically the reason I thought of such a "self-counting" method for file name generation
19:46:31  <Yexo> <- this is already possible though
19:46:38  *** andythenorth has quit IRC
19:47:48  <Rubidium> looks like it'd be worth it to look at splitting the 8bpp sprites into seperate files as well so you can optimally reuse templates
19:48:14  <Yexo> I don't see the relevance there
19:48:36  <Yexo> but splitting some of the large 8bpp png's into smaller ones certainly seems like a good idea
19:48:51  <Rubidium> template tmpl_foo(file, zoom <<1, 2, 4, 0.5, ...>>) { [ 32 * zoom - 1, -32 * zoom + 1, file + "_0.png"], ...}
19:49:21  <Yexo> ah :)
19:49:54  *** andythenorth has joined #openttdcoop.devzone
19:50:30  <Yexo> <- this would be trivial to support (only a new builtin 'str' function that converts an int to a string)
19:52:57  <andythenorth> "sprites/32bpp/${num}.png", "sprites/32bpp/${num}m.png"
19:52:58  <andythenorth> ?
19:55:54  <Yexo> same effect, but that doesn't fit nml style at ll
19:59:03  <andythenorth> neither does this :)
19:59:19  * andythenorth just likes chameleon and such
20:03:09  *** Chris_Booth has left #openttdcoop.devzone
20:05:22  <andythenorth> in nml, you've written a language that is *very* amenable to templating
20:05:24  <andythenorth> thanks for that ;)
20:09:44  <Yexo> in RGB + M mode you can't have any fully transparent pixels, right?
20:18:49  <michi_cc> Yes, if you need transparency, supply an alpha channel.
20:20:42  <Yexo> so that mode is almost completely useless
20:20:57  <Yexo> as practically any sprite needs to have some fully transparent pixels
20:39:22  <michi_cc> Mostly, yes. Maybe for some GUI sprites.
20:46:58  <Rubidium> I'd only bother with RGBA(M) sprites like grfcodec does ;)
20:47:19  <Yexo> yeah, would've been easier
20:47:31  <Yexo> already implemented RGB(A)(M) now though
21:02:20  <Brot6> BANDIT - Revision 306:f98bfb80e15d: Codechange: use 'points' instead of sequence to avoid the ugl... (andythenorth) @
21:16:24  <Brot6> BANDIT - Revision 307:56c83214d654: Codechange: have PixaSequence object handle more of what it n... (andythenorth) @
21:31:04  <Rubidium> planetmaker: what's the idea of terrain.xcf? Should the other terrain types also be included in there? Is there some composition, or is it just adding layer and layer of sprite data?
21:33:00  <planetmaker> Rubidium, terrain.xcf generates all water sprites like rivers, canals, sea shores
21:33:08  <Rubidium> or would it be fine to manually create a png for each "type" of ground tile?
21:33:46  <planetmaker> see sprites/png/waterfeatures/waterfeatures.xcf2png
21:34:21  <planetmaker> thus... I'd very much prefer to have all ground tiles from that file as it will allow to generate matching shores, canals and rivers without (much) further effort
21:34:45  <planetmaker> additionally those (same) tiles will also need to go in the respective infrastructure file. Which is similarily structured
21:35:05  <planetmaker> It's not (yet) completely generated everything from that file, but that's my idea behind it
21:35:20  <planetmaker> removing the need to manually create all those compository tiles
21:35:27  <Rubidium> not sure whether bare land, rough land or fields will ever get rivers and such
21:36:05  <planetmaker> yes, true. Those might not be needed to be generated from that file
21:36:30  <planetmaker> though... actually the transitions are also a good thing to be created from that with semi-transparent layers
21:36:35  <planetmaker> between the grass and the bare
21:36:46  <planetmaker> it's not done yet, though
21:37:12  <planetmaker> basically the same way snow transitions are used within that file
21:37:37  <planetmaker> But it's not needed to do that, if the sprites exist in another form
21:38:36  <planetmaker> Rubidium, are you thinking of some sprites in particular?
21:41:52  <Rubidium> the ones in sprites/base/base-3924-terrain.pnml and sprites/base/base-4090-farm-fields.pnml
21:44:40  <Rubidium> Yexo: NML 1856 seems to assert on OpenGFX 947's extra.grf
21:44:47  <Yexo> yep
21:44:59  <Yexo> that's the bit I'm currently fixing (after some other problems)
21:45:22  <Yexo> nmls ogfx1_base.grf is now 3 bytes smaller than the one encoded by grfcodec for some reason
21:47:39  <Rubidium> planetmaker:
21:48:58  <planetmaker> ah, that looks nicely like one of those simplifications I long want to see done :-)
21:49:09  <planetmaker> removing those ominous big png files :-)
21:50:16  <planetmaker> for snow I used a naming in 4th like grass-snow14.png, though
21:51:13  <planetmaker> thus I probably would have chosen bare-temperate-14.png or so. But... not sure it's a good idea :-)
21:52:18  <Rubidium> 03, 13, 23 then ;)
21:52:28  <Rubidium> but that's splitting hairs ;)
21:52:35  <planetmaker> hm, yeah
21:52:43  <planetmaker> I guess: please commit it
21:53:09  <Rubidium> nah, that'll trigger a compile bug
21:54:10  <planetmaker> hm, it does?
21:54:17  <Yexo> nml is broken
21:54:56  <planetmaker> well. That should not stop committing good patches to OpenGFX ;-)
22:02:23  <Yexo> Rubidium: const bool long_chunk = grfcontversion == 2 && sx > 256; <- that's grfcodec code
22:02:43  <Yexo> but openttd's spriteloader does "long_chunk = decompressed_size > 0xFFFF;"
22:02:58  <Yexo> if you have a very wide but only a few pixels high sprite this'll fail
22:04:04  <Rubidium> Yexo: openttd's long chunk is probably grfcodec's long format
22:04:38  <Yexo> hmm, right
22:05:14  <Yexo> that's waht I'm messing up
22:16:42  <Brot6> NewGRF Meta Language - Revision 1862:98994f0b8131: Feature #3712: fully support 32bpp sprites inc... (yexo) @
22:18:12  <Brot6> NewGRF Meta Language - Feature Request #3712 (New): New 32 bpp format (yexo) @
22:19:41  <Yexo> nml seems to be even slower than it already was :(
22:21:02  <planetmaker> many things were added meanwhile...
22:21:11  <Yexo> but I did find a nice feature in pythons list comprehensions, see the new crop_sprite function:
22:22:34  <planetmaker> that looks neat
22:23:14  <andythenorth> are you looking at the slice?
22:23:18  <andythenorth> or the all() ?
22:23:23  <Yexo> the slice :)
22:23:44  <planetmaker> hm... I don't quite understand when you use size_x and size_y, though
22:23:46  <Yexo> data[::size_x] <- I wasn't familiar with that
22:23:50  <andythenorth> use that slice a lot in web apps
22:23:57  <andythenorth> my_url[:30]
22:24:02  <andythenorth> or such
22:24:04  <andythenorth> for long strings
22:24:10  <Yexo> that one I knew, this one is different :)
22:24:19  <Yexo> a=[0,1,2,3,4,5,6]
22:24:29  <Yexo> a[::2] == [0,2,4,6]
22:25:01  <Yexo> del a[2::3]
22:25:13  <Yexo> now a == [0,1,3,4,6]
22:26:47  <planetmaker> ah
22:27:57  <andythenorth> how cunning
22:28:39  <Yexo> 9m12 build time for opengfx (for only the nml steps)
22:28:43  <andythenorth> L[::-1] :)
22:29:04  <Yexo> a=[1,2,3]
22:29:11  <Yexo> a[::-1] == [3,2,1] ;)
22:29:50  <Yexo> Rubidium: you can commit to opengfx now, nml works again
22:30:01  <planetmaker> well. OpenGFX has never been lightening fast in being processed, Yexo
22:30:35  <andythenorth> how much slower did nml get? :)
22:30:50  <Yexo> not sure, didn't measure before, only after
22:31:20  <andythenorth> let's see
22:33:20  <andythenorth> the effect on BANDIT is marginal (if any)
22:33:32  <andythenorth> ~6.5s before and after updating
22:33:58  <andythenorth> I had r1822 previously
22:34:20  <Yexo> Rubidium: just upgraded to grfcodec r920 (from r916), not it complains about "Offset too large" while encoding ogfx1_base.grf
22:34:31  <andythenorth> but I cheat with passing nfo to grfcodec...
22:34:39  <Yexo> it's an error in the uncompress code, called to check that the compression went correct
22:35:15  <Rubidium> bah...
22:35:17  <Rubidium> not today
22:36:17  <Yexo> r919 works correctly, r920 does not
22:37:10  <Rubidium> so that's the reason?
22:37:15  <Yexo> no clue
22:38:48  <Brot6> OpenGFX - Revision 948:bdc5ab491184: -Codechange: refactor sprite sheets for sprites/base/base-39... (Rubidium) @
22:38:48  <Brot6> OpenGFX - Revision 949:bf262bfa23d5: -Codechange: refactor sprite sheets for sprites/base/base-40... (Rubidium) @
22:38:48  <Brot6> OpenGFX - Revision 950:34fa3e392e07: -Codechange: remove the need for terrain04.png from base (Rubidium) @
22:39:46  <Yexo> hmm, I think a missing check for if (*lastcodepos == 0x80) after the loop in realcompress
22:40:03  <Yexo> that explains also the 3 byte difference in nml vs grfcodec r916
22:40:12  <Yexo> the "unlikely" scenario happens 3 times
22:40:16  *** JVassie has quit IRC
22:44:00  <Brot6> GRFCodec - Revision 921:be8732bc6179: -Fix (r920): in some scenarios even more unlikely than the ... (yexo) @
22:45:05  <Rubidium> thanks Yexo
22:46:13  <planetmaker> thanks, Rubidium :-)
22:50:33  <Brot6> BANDIT - Revision 308:f88776488801: Codechange: renderer now handles coloursets and some transforms (andythenorth) @
22:50:33  <Brot6> BANDIT - Revision 309:9404d88ba2ca: Codechange: delete deprecated transform methods (andythenorth) @
22:50:33  <Brot6> BANDIT - Revision 310:5efd196e843a: Codechange: restore ability to mask out colours with a transform (andythenorth) @
22:51:24  <Yexo> good night
22:51:29  <andythenorth> bye Yexo
22:54:28  *** andythenorth has left #openttdcoop.devzone
22:55:46  <planetmaker> good night, Yexo
23:01:48  <Brot6> BANDIT - Revision 311:e6349d6092c3: Codechange: use a better method to init transforms for a sequ... (andythenorth) @
23:13:47  <Brot6> BANDIT - Revision 312:4880806c4098: Codechange: put render passes in a list - prep for allowing p... (andythenorth) @
23:21:46  <Brot6> BANDIT - Revision 313:f9621eefb20c: Codechange: move more gestalt details out of spritesheet clas... (andythenorth) @
23:26:27  *** ODM has quit IRC
23:30:01  *** frosch123 has quit IRC

Powered by YARRSTE version: svn-trunk