Log for #openttdcoop.devzone on 25th October 2010:
Times are UTC Toggle Colours
00:03:57  <SmatZ> good night, planetmaker :)
01:01:07  <Brot6> Unable to connect to execution expired
02:05:29  *** Webster has joined #openttdcoop.devzone
02:18:50  *** thgergo has quit IRC
02:19:08  *** Lakie has quit IRC
02:30:00  *** Levi has quit IRC
06:07:16  <Rubidium> planetmaker: AFAIR the compile farm is able to compile those obese (5 binary) universal binaries
06:07:56  <planetmaker> aye
06:08:29  <planetmaker> I'm wondering whether to change 'universal' to just i386 as it works everywhere on intel or to also include x86_64
06:08:37  <planetmaker> which would somewhat be pointless then
06:09:17  <planetmaker> see the patch I linked in the other universe
06:47:07  <Brot6> 2cc train set - Feature #1726: 81-740 (Voyager1) @
07:15:32  *** ODM has joined #openttdcoop.devzone
08:33:55  *** andythenorth__ has joined #openttdcoop.devzone
08:46:29  <Brot6> 2cc train set - Feature #1727 (New): NY R44 (Voyager1) @
10:22:09  *** Levi has joined #openttdcoop.devzone
10:22:48  *** Levi has left #openttdcoop.devzone
10:22:52  *** Levi has joined #openttdcoop.devzone
10:34:31  *** Levi has quit IRC
10:46:09  *** KenjiE20 has joined #openttdcoop.devzone
11:03:31  <Brot6> 2cc train set - Bug #1724: Some chsnges in USSR engines. (simozzz_AK) @
11:05:49  <Brot6> 2cc train set - Feature #1727: NY R44 (Voyager1) @
11:13:23  <Brot6> 2cc train set - Bug #1724: Some chsnges in USSR engines. (Voyager1) @
11:25:52  <Brot6> 2cc train set - Feature #1726: 81-740 (simozzz_AK) @
12:00:54  *** Lakie has joined #openttdcoop.devzone
12:13:11  *** Webster has joined #openttdcoop.devzone
13:00:12  * Lakie starts working on an nml bjects tutorial
13:00:58  <Lakie> I just noticed though the reference document seems a bit thin around spritesets, templates and spritegroups.
13:02:19  <planetmaker> all documentation clarifications and extensions welcome :-)
13:02:42  <Lakie> Heh, just means I can't refer to it like I could nfo...
13:03:27  <planetmaker> Just do it in spite of, if you need to :-)
13:03:39  <planetmaker> but... better not, of course ;-)
13:04:21  <Lakie> Heh, well it just means I'll have to explain them better...
13:05:20  <planetmaker> :-P
13:05:50  <Lakie> As not to scare people of nml. ;)
13:06:39  <planetmaker> :-)
13:07:28  <Lakie> its x, y, sx, sy, xoff, yoffs, type? for the array of numbers?
13:07:55  <Lakie> in a spriteset?
13:09:38  <planetmaker> x,y, sizeX, xizeY, offsetX, offsetY
13:09:54  <planetmaker> , encoding
13:09:57  <planetmaker> optionally
13:10:20  <planetmaker> where encoding is what is 3rd in the NFO style, transparency and alike
13:12:53  <planetmaker> btw, did you notice that meanwhile meanwhile both OpenTTD and OpenGFX only use png sprites?
13:38:54  *** Levi has joined #openttdcoop.devzone
13:55:54  * andythenorth__ remembers there are some FIRS translations in the dev thread
13:56:01  <andythenorth__> they shouldn't be forgotten!
13:56:45  <planetmaker> yes. But do you plan to release now?
13:57:50  *** Lakie` has joined #openttdcoop.devzone
14:03:40  *** Lakie has quit IRC
14:04:07  <andythenorth__> planetmaker: no release planned yet
14:06:53  <planetmaker> then there's not much point to update the translations now ;-)
14:07:41  <planetmaker> rather I could use the time to think of *better* translations for some. Though lugo(?) added some improvements IIRC
14:28:15  *** Lakie` is now known as Lakie
14:35:54  <Lakie> I know last ones optional, does it work out if it should be for example a tile compression 09?
14:38:11  <Lakie> So for example, if I had 1 1 09 39 64 -31 -8, and thus [ 1, 1, 64, 39, -31, -8 ], would it detect that the last one should be 09 or would I need to specify that, planetmaker?
14:40:01  <planetmaker> It has no intelligence there, just a default value
14:40:16  <Lakie> so 01
14:40:18  <Lakie> Ok.
14:40:20  <planetmaker> Dunno which, I seem to remember 3, but...
14:40:23  <planetmaker> ok 1 :-)
14:40:58  * Lakie shall just ommit it then for simplicity.
14:41:55  <planetmaker> fair enough. It's part of the sprite set description anyway
14:42:04  <planetmaker> you need not really deal with that
14:42:13  <planetmaker> after all - I usually use templates there anyway ;-)
14:42:24  <planetmaker> (which IMHO is one of the BIG advantages here)
14:42:56  <Lakie> Do templates automatically increment?
14:43:15  <Lakie> Since from my quick play about with it, generally you only get one sprite per spriteset
14:43:21  <Lakie> (for objects)
14:44:58  <planetmaker> increment?
14:45:19  <Lakie> Yeah, well if I define two sets of sprites in the template (offsets etc)
14:45:39  <planetmaker> a template is just an arbitrary number of sprites defined, possibly their alignment and placement modified by parameters
14:45:51  <Lakie> And use them in two sprite sets, will it use the first set of values for the first spriteset and the second set of values for the second spriteset?
14:46:18  <planetmaker> template blubber(x,y) { [0,y, 10, 10, 0, 0] [x, y, 10, 5, 10, 10] }
14:46:44  <planetmaker> Sorry, I still don't get you. A template is just saving you to re-do alignment
14:46:56  <Lakie> Its just otherwise I feel it may be more useful for vehicles than objects,
14:47:17  <planetmaker> depends basically how you arange your real sprites in the graphic files
14:47:33  <Lakie> True
14:47:46  <planetmaker> I still would - for example - always use the same template for a ground tile
14:47:53  <planetmaker> once written, never wrong (or always)
14:48:18  <Lakie> Well, unless you have faked foundations. :)
14:48:58  <Lakie> But, I think I follow, its just so you don't have to retype offets and such?
14:49:22  <planetmaker> Basically
14:49:39  * Lakie ponders if planetmaker should write the description and use for most of the nml tutorial instead. ;)
14:49:46  <planetmaker> :-P
14:50:18  <planetmaker> Well... I wrote the _current_ description of the sprite blocks ;-)
14:50:25  <planetmaker> obviously it's a FAIL ;-)
14:50:30  <Lakie> Heh
14:51:01  <Lakie> Well, from what I understand (limited obiously), spriteblocks are really just containers or a method of grouping for building of action1s
14:51:29  <Lakie> spritesets are the actual sprites, and spritegroups (in my content) are the tile layouts
14:51:36  <planetmaker> Well... there's two things: templates and spriteblocks / sets
14:51:39  <planetmaker> yes
14:51:52  <planetmaker> probably. But I don't know tile layouts ;-)
14:52:01  <Lakie> Meh, they are easy!
14:52:13  <planetmaker> people keep saying that :-)
14:52:39  <planetmaker> I guess they'll remain somewhat slightly shrouded till I actually programme them myself
14:52:46  <planetmaker> Maybe... I should programme another airport
14:52:57  <planetmaker> but I'd need graphics :-(
14:53:50  <Lakie> spritegroup basic_tile { ground { ttdsprite: 1420; } building { ttdsprite: 2632; recolor : 0; xtextent: 16; yextent: 16; zextent: 30; } }
14:53:55  <planetmaker> or start OpenGFX+ Industries. But... that'd be too many projects going on
14:54:00  <Lakie> Not really, tile layouts can use base graphics
14:54:04  <Lakie> As shown above
14:54:07  <planetmaker> :-)
14:54:40  <Lakie> Notably its a lot more readable when on multiple lines...
14:54:52  <planetmaker> sure. But that's easily done in the source
14:54:58  <Lakie> Aye
14:56:18  *** frosch123 has joined #openttdcoop.devzone
14:56:19  <planetmaker> I'm still amazed that I can redefine all rail / monorail and maglev waggons in only 1800 lines of code; including graphics for a lot of cargos
14:56:33  * Lakie figures he should cover grf (thoughthats so basic anyway), tempplate?, spriteblock (um, container?), spriteset, spritegroup, switch and itm...
14:56:46  <Lakie> Hmm..
14:56:59  <Lakie> I imagine templates help cut out a number of lines?
14:57:29  <planetmaker> they let me cut a lot of lines as I only need to do like half a dozen of alignments
14:57:35  * andythenorth__ is finding nfo / cpp templates are cutting down code a lot
14:57:39  <andythenorth__> especially action 1 blocks
14:57:45  <Lakie> I think in my sample, with comments removed, the nfo was just smaller than the nml...
14:57:56  <planetmaker> that might be
14:58:15  <Lakie> And it is fairly readable. :)
14:58:20  <planetmaker> after all nfo is basically the bytes written down. While in NML (at least I) tend to use longer, speaking names
14:58:30  <Lakie> True
14:58:56  <Lakie> Also to do with styles, I prefer a newline for {, most don't
14:59:35  <planetmaker> Depends ;-)
15:00:17  <Lakie> Heh
15:00:37  <planetmaker> a short sprite group can be one line. But longer...
15:01:06  <Lakie> Well, technically even long ones can be one line...
15:01:20  <Lakie> I imagine one could write the whole nml as a single line?
15:01:22  <Lakie> >_>
15:01:30  <Lakie> Or does it not like that?
15:01:50  <frosch123> manindu has quite long lines after preprocessing
15:02:26  <frosch123> most of it is done via #define macros which use \ in front of nl, which gets removed on preprocessing :)
15:03:36  <frosch123> so even though nml is written in python, nml itself does not care about whitespace :p
15:04:09  <Lakie> Heh, I don't think its reading the films as python but more a tag based language?
15:04:17  <Lakie> films? files*
15:05:04  <frosch123> it being lr(1) parseable is everything what counts :)
15:05:38  <frosch123> to my experience that is the biggest trouble in processing nfo files
15:06:45  <Lakie> lr(1)?
15:07:32  <frosch123> parseable from left to right with single look-ahead token
15:07:44  <frosch123>
15:07:45  <Webster> Title: LR parser - Wikipedia, the free encyclopedia (at
15:08:34  <frosch123> i.e. you know the meaning of every token in the moment you read it
15:09:12  <Lakie> Ah
15:09:27  <frosch123> which does not hold for nfo. you can read a number, and it may be a byte for pseudosprite, or a spritenumber depending on "*" or "**" or something else following after that
15:09:33  <Lakie> I think the only things which don't follow that would be strings?
15:09:47  <Lakie> I guess.
15:10:24  <Lakie> Well, sprites just have a number, most pseduo sprites have <num> * <length> and wave files have <num> ** or something
15:29:33  *** Lakie has quit IRC
15:34:52  *** Lakie has joined #openttdcoop.devzone
15:43:17  *** ODM has quit IRC
15:45:13  *** Lakie has quit IRC
16:20:15  <Brot6> heqs: update from r471 to r473 done -
16:20:39  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r635), 32bpp-extra (r39), ai-admiralai (r71), airportsplus (r64), basecosts (r22), belarusiantowns (r7), comic-houses (r71), firs (r1481), fish (r404), frenchtowns (r4), grfcodec (r785), indonesiantowns (r37), manindu (r5), metrotrackset (r56), newgrf_makefile (r220), nml (r915), nutracks (r117), ogfx-trains (r85), ogfx-trees (r41), opengfx (r553), openmsx (r97), opensfx (r97),
16:20:39  <Brot6> smts (r19), snowlinemod (r45), swedishrails (r187), swisstowns (r20), transrapidtrackset (r15), ttdviewer (r26), ttrs (r23), worldairlinersset (ERROR r666)
16:21:33  <Brot6> indonesiantowns: compile of r37 still failed (#1704) -
16:22:16  <Brot6> swisstowns: compile of r20 still failed (#1705) -
16:23:02  <frosch123> oh, worldairlinersset is quite devlish
16:23:09  <Brot6> worldairlinersset: compile of r666 still failed (#1725) -
16:45:09  <planetmaker> hehe
16:46:02  <planetmaker> about 5.4146 times more devilish than you :-P
16:49:32  <Brot6> 2cc train set - Feature #1728 (New): NY R1 (Voyager1) @
16:49:32  <Brot6> 2cc train set - Feature #1728: NY R1 (Voyager1) @
17:10:31  *** ODM has joined #openttdcoop.devzone
17:17:55  *** Levi1 has joined #openttdcoop.devzone
17:22:55  *** Levi has quit IRC
17:40:09  *** thgergo has joined #openttdcoop.devzone
18:10:03  <Brot6> 32bpp-ez-patches: update from r21028 to r21038 done -
18:18:56  <Brot6> clientpatches: update from r21028 to r21038 done -
18:20:07  <Brot6> serverpatches: compile of r21038 still failed (#1658) -
18:38:38  <planetmaker> oh, I read that you _have to_ correct "a few" cargo classes in FIRS, andythenorth__
18:38:53  <planetmaker> or his majesty's ships won't transport goods
18:39:02  <andythenorth__> I have been talking to our friend
18:39:07  <andythenorth__> goods is actually wrong
18:39:09  <andythenorth__> don't know why
18:39:24  <planetmaker> wrong is a relative term
18:39:40  <planetmaker> it was afaik changed to BETTER reflect refit capabilities
18:39:54  <andythenorth__> "inconsistent with other definitions of goods"
18:40:49  <planetmaker> I know
18:41:31  <andythenorth__> I thought it was a bug?
18:41:34  <andythenorth__> perhaps it's a feature
18:41:38  <andythenorth__> it's lost in the depths of time
18:41:53  <andythenorth__> I'll lend him my ships :)
18:41:59  <andythenorth__> they're at least as good, if not better
18:42:17  <planetmaker> it is not a bug. It was discussed at least two days
18:42:41  <andythenorth__> we should document that somewhere then
18:42:46  <planetmaker> IIRC. But I don't know the single arguments. And they might be differently weighted meanwhile
18:42:49  <andythenorth__> like the endless WDPR debate
18:42:58  <planetmaker> is there a debate about them?
18:43:03  <andythenorth__> no longer
18:45:25  <planetmaker> I've support for them as both, wood chips as well as boards
18:47:17  <andythenorth__> what other classes 'need' changing
18:47:47  <planetmaker> none needs changing
18:48:05  <planetmaker> it will all mess up the current support I built
18:48:30  <andythenorth__> I am quite happy with them as is
18:48:32  <Brot6> FIRS Industry Replacement Set - Revision 1482:c9bb2425726e: Change: documented some stuff on carg... (andythenorth) @
18:48:37  <planetmaker> so am I
18:49:05  <andythenorth__> cargo sprites are over-rated anyway :P
18:49:45  <planetmaker> not at all ;-)
18:49:59  <planetmaker> OpenGFX+Trains will have special ones for every cargo and wagon ;-)
18:50:11  <planetmaker> though fruit and fruit+vegetables won't be different
18:50:16  <planetmaker> but they don't co-exist anyway
18:50:27  <planetmaker> and similar
18:52:14  <planetmaker> actually I even drew a chemical wagon for it ;-)
18:52:21  <planetmaker> or better: modified
19:09:12  *** andythenorth__ has quit IRC
19:19:24  *** andythenorth_ has joined #openttdcoop.devzone
19:25:09  * andythenorth_ has *full* cargo sprite support for FISH :P
19:25:28  <andythenorth_> but the cargo is covered by hatches, so you never see it :D
19:25:45  <planetmaker> :-P
19:26:06  <planetmaker> hehe. OpenGFX+Trains will feature HEQS vehicles :-)
19:26:28  <planetmaker> something needs to go as vehicles. And farm supplies. They do very well :-)
19:26:30  <planetmaker> If you don't mind
19:27:18  <andythenorth_> GPL :)
19:27:22  <andythenorth_> I don't mind
19:27:28  <andythenorth_> they are quite big though ;)
19:34:11  <planetmaker> well. There's a (new) normal car. But also one farming truck
19:34:16  <planetmaker> So there's a bit variety
19:34:28  <planetmaker> Yes, GPL, but... :-) Asking is nice :-P
19:36:31  <andythenorth_> indeed ;)
19:38:35  <planetmaker> we might try some re-colouring on the vehicles, maybe
19:38:50  <planetmaker> But I'll have to figure that out before anyway. Same for containers
19:39:02  <planetmaker> just because ;-)
19:39:15  <planetmaker> (well, and I need an NML example for recolour sprites)
19:59:15  <andythenorth_> planetmaker: are you using 2cc?
19:59:27  <planetmaker> we will, yes
19:59:45  <andythenorth_> iirc, we decided recolour doesn't work 2cc
20:00:04  <andythenorth_> it was mr. frosch who thought that
20:00:18  <planetmaker> it's either or, yes
20:00:23  <planetmaker> afaik
20:00:29  <andythenorth_> shame
20:00:48  <andythenorth_> I was considering writing a photoshop action to pre-process cargo sprites
20:00:53  <planetmaker> but a wagon carrying a container doesn't need tw colours on the 15 pixels which constitute the wagon itself ;-)
20:00:54  <andythenorth_> but I think it would be fragile
20:02:56  <frosch123> andythenorth_: planetmaker: you would not need any custom recolour sprites if you use one or both of the company colours for cargo/random recolouring
20:03:29  <frosch123> i.e. using cb 2d you can set the two recolour colours to use, while keeping one or none of the company colours
20:03:43  <frosch123> so you could draw the wagon with company colour, and the container with a second randmo colour
20:06:56  <frosch123> hmm, no, i guess i failed at that already last time :p
20:07:25  <frosch123> maybe we should just add another resultvalue to cb 2d to make it more useful
20:07:57  <planetmaker> frosch123: that's the idea with the containers
20:08:25  <planetmaker> random colour with CC for some other parts.
20:08:35  <planetmaker> But I haven't yet looked deeply at the technical aspect
20:10:14  * andythenorth_ wants to be able to remap specific colours on a cb :P
20:11:08  * frosch123 found a bug
20:15:34  <Rubidium> frosch123: how many legs does it have?
20:15:45  <frosch123> one too many
20:20:26  <frosch123> ah, i remember how it worked! action D can read the 2cc colourmap offset which you can then return in cb 2d plus the needed offset
20:24:37  <frosch123> hmm, but.. can you already read patchvariables with nml?
20:25:54  <frosch123> does not look like it
20:30:34  <planetmaker> one can
20:31:12  <planetmaker> if not named, always var[0xB3] or so will work
20:31:45  <frosch123> i doubt that :p
20:32:06  <frosch123> you confuse action679d variables with patch variables
20:33:01  <planetmaker> extra_callback_info1/2?
20:33:16  <frosch123>
20:34:02  <planetmaker> nml/docs/reference.html#vars-general
20:34:34  <planetmaker> they should be covered (mostly)
20:35:11  <frosch123> i see only action679d variables, no patch vars
20:35:11  <planetmaker> se rails for example checks for driving side
20:35:40  * andythenorth_ wonders what the internals of a grf look like
20:35:43  <Hirundo> I doubt that patch variables are implemented, but we can work on that :)
20:36:01  <Rubidium> so far lzma2 is usually faster than zlib6 for savegame + download. In one case is was ~1% slower
20:36:02  <Hirundo>
20:36:03  <frosch123> Hirundo: planetmaker needs patchvar 11 :)
20:36:15  <Rubidium> and I guess this isn't the right window
20:36:21  <Hirundo> andythenorth_: see link above^^
20:37:19  <Rubidium> Hirundo: linking that is lame. Just should've said, read the docs in grfcodec's docs directory
20:37:28  <frosch123> andythenorth_: be careful though, the docs are writte by a asm programmer
20:37:32  <andythenorth_> hmm
20:37:53  <andythenorth_> I am trying to work out if we could process graphics to replace colour using grfcodec
20:37:55  <Hirundo> andythenorth_: Read the docs in grfcodec's docs directory.
20:38:13  <Hirundo> why (ab)use grfcodec for that?
20:38:17  <andythenorth_> why not?
20:38:34  <Hirundo> Because I don't use grfcodec to play music either
20:39:15  <andythenorth_> Hirundo: because recolouring cargo sprites manually is very dull :P
20:39:23  <andythenorth_> and a photoshop action to do it reliably is hard
20:40:06  <Hirundo> Is it as simple as applying a recolour sprite?
20:40:20  <Hirundo> ('simple' in coding terms)
20:40:31  <andythenorth_> I don't know
20:41:06  <Rubidium> andythenorth just wants to implement #1403
20:41:06  <Brot6> Rubidium: #1403 is "GRFCodec - Feature #1403: Replace Animation Colors - #openttdcoop Development Zone"
20:41:39  <andythenorth_> more or less yes
20:41:50  <andythenorth_> a helper app could do it
20:42:07  <andythenorth_> I started trying to understand PIL to see if I could use a colour transform
20:42:47  <andythenorth_> but even if i succeed, it would introduce a very non-standard tool to my sets
20:42:58  <Hirundo> You should switch to nml :)
20:43:28  <andythenorth_> I'll use it for new sets...probably
20:44:02  <andythenorth_> recolor sprites are applied in-game
20:44:03  <andythenorth_> ?
20:45:34  <frosch123> they are applied during drawing, just before writing to the screenbuffer
20:45:48  <andythenorth_> isn't that slow?
20:46:38  <frosch123> compared to what?
20:46:53  <andythenorth_> compared to not doing it :)
20:47:39  <frosch123> well, it is only done when recolouring is needed
20:47:52  * andythenorth_ tries to work out how a recolor sprite could say 'no change' for a given value
20:48:08  <frosch123> i.e. drawing non-recoloured sprites does not look up the identity-recolouring
20:48:21  <frosch123> andythenorth_: recolour to same value
20:48:41  <andythenorth_> but then the 1cc * 2cc problem occurs
20:48:53  <andythenorth_> *many* recolour tables needed
20:49:10  <frosch123> no, only if you want to use non-standard recolourings
20:49:15  <frosch123> like three colours
20:49:39  <andythenorth_> which is what I want to do "|
20:49:41  <andythenorth_> :|
20:49:52  <andythenorth_> four colours to be exact ;)
20:49:52  <frosch123> if you restrict to 1cc plus your own rules for the second cc, you do not need any custom recolouring
20:50:19  <frosch123> four colours?
20:50:38  <frosch123> i know heqs are slightly bigger vehicles, but how do you want to fit four colours on them?
20:50:42  <andythenorth_> most bulk cargos are drawn with four colours
20:50:54  <andythenorth_> (this is all related to recolouring cargos)
20:51:15  *** welshdragon has quit IRC
20:51:24  <frosch123> what do you mean with "drawn with four colours"...?
20:51:59  <andythenorth_> frosch123: you have HEQS checked out?
20:52:18  <frosch123> i pulled yesterday iiirc
20:52:37  <frosch123> at tip again
20:53:06  <andythenorth_> have a look at something like "sprites/graphics/60t_mining_truck.pcx"
20:53:30  <andythenorth_> you'll see how the cargos are done
20:53:57  <frosch123> well, but the cargo has only one colour
20:54:08  <frosch123> and the truck as well
20:54:23  <frosch123> so, that vehicle would work with cb 2d without adding any custom recolourings
20:54:32  <andythenorth_> in the case of HEQS yes true
20:54:41  <andythenorth_> in the case of FISH...not so much :)
20:54:46  <andythenorth_> FISH is fully 2cc
20:54:55  <andythenorth_> so no cargo sprites in FISH
20:55:12  <andythenorth_> as I can't face endless copy-paste-pick-colour-fill :o
20:55:21  <andythenorth_> the code would be trivial
20:55:38  <Hirundo> You can easily generate those sprites, but the number of them might become problematic if you want TTP compatibility
20:55:49  <Hirundo> s/TTP/TTDP
20:55:53  <andythenorth_> that seems to be topic of the week :P
20:56:04  <andythenorth_> I care not at all about TTDP compatibility
20:56:30  <andythenorth_> :)
20:56:50  <Hirundo> Even then, each set of recolor sprites is 65kb of uncompressed memory
20:57:26  <Hirundo> It may be a bit much to do that at runtime, while generating the correct sprites is also possible at compile time
20:57:38  <andythenorth_> seems better to just automate it at compile time
20:57:48  <frosch123> Hirundo: iirc there are not enough spriteslots to load enough recolour sprites
20:58:07  <andythenorth_> I want to figure out a way to take a source png, replace specific colours and append to a file
20:58:18  <Hirundo> how many slots are there?
20:58:41  <frosch123> hmm, actually i am not sure
20:58:43  <Hirundo> The number of needed sprites is n*256, with n being the number of recolour variants
20:59:02  <andythenorth_> it seems...not efficient to do it in run time
20:59:08  <frosch123> it depends which spriterange grm uses
20:59:58  *** welshdragon has joined #openttdcoop.devzone
21:00:37  <frosch123> Hirundo: ignore my comment
21:00:49  <frosch123> there are 12000 free slots
21:01:03  <frosch123> :)
21:01:49  <frosch123> andythenorth_: does a simple java application suffice to apply recolourning to png files?
21:02:09  <frosch123> resp. does java work on your mac?
21:02:14  <andythenorth_> I think so
21:02:19  <andythenorth_> Steve is trying to kill it though
21:02:55  <andythenorth_>
21:02:56  <Webster> Title: Gosling blows lid off Jobs Java nonsense • The Register (at
21:05:36  <andythenorth_> frosch123: would it be a thing I run just once to make a 'final' png spritesheet?
21:05:46  <andythenorth_> or would it be a thing called by make?
21:08:15  <frosch123> how you like, but maintaining one .png and generating the other on make sounds more logical
21:10:15  *** Webster has joined #openttdcoop.devzone
21:10:46  <andythenorth_> we can try it and see :)
21:11:07  <andythenorth_> I guess I meant there would need to be a way for make to pass options to the helper app....
21:11:14  <andythenorth_> (such as the colour remapping)
21:14:30  *** Guest609 has quit IRC
21:30:07  * andythenorth_ goes to bed
21:32:27  *** andythenorth_ has quit IRC
21:33:40  *** frosch123 has quit IRC
22:00:26  <Brot6> OpenTTD WebConfig - Revision 5:753b5302e66f: Removed weird symbols added by Notepad++ in line 0. (Levi) @
22:02:20  <Rubidium> s/weird symbols/BOM/
22:02:43  *** Lakie has joined #openttdcoop.devzone
22:02:46  <Levi1> what's BOM?
22:03:05  <Rubidium> Byte order mark
22:03:28  <Rubidium> two bytes to encode what unicode encoding the file has
22:03:45  <Rubidium> (or three in case of UTF8)
22:03:58  <Levi1> ok... the revision was actually to see whether mercurial push works again, but thanks for the explanation :)
22:16:48  <Lakie> Rubidium: I thouhgt UTF-8 only has one order of bytes?
22:17:38  <Lakie> Oh, sorry misread, a 3 byte sequence. :x
22:20:37  *** Webster has joined #openttdcoop.devzone
22:26:05  *** Guest618 has quit IRC
22:29:44  *** Lakie has quit IRC
23:51:58  *** thgergo has quit IRC

Powered by YARRSTE version: svn-trunk