Log for #openttdcoop.devzone on 21st July 2012:
Times are UTC Toggle Colours
00:08:09  *** LordAro has quit IRC
01:15:13  *** Nat_aS has joined #openttdcoop.devzone
01:22:43  *** Dr_Tan has quit IRC
01:35:37  *** NataS has joined #openttdcoop.devzone
01:43:04  *** Nat_aS has quit IRC
02:58:35  *** Dr_Tan has joined #openttdcoop.devzone
03:05:29  *** NataS has quit IRC
05:04:46  *** Diablo has joined #openttdcoop.devzone
05:05:02  *** Diablo has left #openttdcoop.devzone
06:12:47  *** ODM has joined #openttdcoop.devzone
07:09:36  *** LordAro has joined #openttdcoop.devzone
07:51:35  *** Alberth has joined #openttdcoop.devzone
07:51:56  <Alberth> I was missing a window ;)
08:18:30  *** frosch123 has joined #openttdcoop.devzone
08:28:36  <Rubidium> nml takes quite a bit of time with ogfx1_base in zbasebuild
08:38:06  <Alberth> yep, with only around 300 32bpp sprites added so far
08:38:52  <Alberth> mess a bit with sprites, type "make", do something else for 15 minutes :)
08:43:11  <Rubidium> almost easier to test code first with newgrf and then just dump it in the zbase (and build+test with lots of sprites at once)
08:43:45  <Rubidium> nml -u instead of nml -c might help a bit
08:44:09  <Rubidium> about 4 minutes instead of 10
09:30:58  <Brot6> zBase - Bug #4083 (Resolved): depot too big / not even thick walls XAlberthX @
09:30:58  <Brot6> zBase - Bug #4083 (Resolved): depot too big / not even thick walls XAlberthX @
09:33:39  <Alberth> How can you close a ticket?? #4083 doesn't close; the status only has 'resolved' in its list, but that apparently does not imply closed.
09:33:40  <Brot6> Alberth: #4083 is "Bug #4083: depot too big / not even thick walls - zBase - #openttdcoop Development Zone"
09:34:01  <Alberth> Bleh Brot6
09:35:21  <Alberth> oh, access rights of course :p
09:35:50  <Alberth> does it make sense to allow setting to 100% done then?
09:41:04  <Hirundo> Alberth: I have been and am working on making NML faster by caching real sprites
09:41:41  <planetmaker> moin
09:42:00  <Hirundo> What do I need to use zBase for testing?
09:42:10  <Hirundo> zBase, zBaseBuild and opengfx ?
09:42:19  <Hirundo> moin
09:42:30  <planetmaker> yes
09:42:42  <planetmaker> and they need to be named just like that
09:43:44  <planetmaker> lrwxr-xr-x  1 ingo  staff        16 19 Jul 21:49 terrain -> ../zbase/terrain
09:43:49  <planetmaker> zbase actually
09:44:19  <Alberth> moin planetmaker Hirundo
09:44:31  <Alberth> Hirundo: nice, that should help :)
09:44:47  <planetmaker> Alberth: only developers and managers of a project can close issues
09:45:09  <planetmaker> should I make you one of zbase? I guess
09:45:11  <Alberth> yeah, I figured as much
09:45:48  <Alberth> oh, no problem, one of the zbase devs can close it when they feel like it :)
09:45:58  <planetmaker> made you dev of it
09:46:07  <Alberth> bummer :)
09:46:13  <planetmaker> there's only one zbase dev till then. Now two :-P
09:46:52  <Alberth> thanks :)
09:47:45  <Brot6> zBase - Bug #4083 (Closed): depot too big / not even thick walls XAlberthX @
09:47:45  <Brot6> zBase - Bug #4083 (Closed): depot too big / not even thick walls XAlberthX @
11:28:24  <Brot6> NewGRF Meta Language - Revision 1931:8eaf5047d94e: Remove: Now-unused command-line parameter 'sprite... XHirundoX @
12:07:10  *** LordAro has quit IRC
12:07:35  *** LordAro has joined #openttdcoop.devzone
12:08:18  *** LordAro has quit IRC
12:08:44  *** LordAro has joined #openttdcoop.devzone
12:11:32  *** LordAro has quit IRC
12:12:00  *** LordAro has joined #openttdcoop.devzone
12:12:37  <Alberth> Hirundo:   <-- to prevent generation of '' on each run.
12:13:45  <Hirundo> Does it do that o_0? I thought it was cached
12:14:27  <Alberth> yeah, in that file :p
12:14:42  <Alberth> or are special things done during install ?
12:14:54  <Alberth> I am running trunk, uninstalled basically
12:15:05  <Hirundo> same here
12:16:26  <Alberth> rm regression/ ; make -C regression 001_action8 ; ls regression/
12:16:31  *** LordAro has quit IRC
12:17:08  *** LordAro has joined #openttdcoop.devzone
12:18:58  <Hirundo> My dates back to february
12:19:48  <Alberth> it builds that file on the first run, or when you touch the rules, I guess
12:20:52  <Hirundo> regression/ may be removed by the regression makefile (if using 'clean')
12:22:03  <Alberth> I get the file in zbasebuild, ie the directory where nml is running
12:24:08  <Alberth> ply will build the tables in memory each time if it cannot load this file, but I think it's fine, as the grammar is not that large
12:46:01  <Brot6> zBaseBuild - Revision 16:92b697b93be9: Add: road, monorail, maglev depots, fixed (mostly) rail depot... XAlberthX @
13:01:20  *** LordAro has quit IRC
13:03:24  *** LordAro has joined #openttdcoop.devzone
13:16:32  <Brot6> zBase - Bug #4084 (New): depot blender challenges XAlberthX @
13:38:22  <Ammler> planetmaker: installed rhodecode on port 5000 (needs ssl tunnel)
13:39:00  <planetmaker> oh :-)
13:39:12  <Ammler> looks like we sould also need ldap to share the accounts easiest
13:40:27  <Ammler> hmm, let me try to clone a big repo :-)
13:42:12  <Ammler> hmm cloning of ogfx-trains needs 30min
13:42:22  <Ammler> when does it usually brak?
13:42:41  <Alberth> before the end?  :)
13:43:34  <Ammler> well, I thought, it is always same time
13:43:36  * Alberth is bored of zbase coding
13:43:47  <Ammler> same amount of bytes downloading
13:44:16  <Alberth> would probably be route dependent
13:44:38  <Alberth> as well as time of day and/or week and/or year
13:50:43  <Ammler> nono
13:50:59  <Ammler> well, I could try myself but I just wait :-P
13:51:17  <Ammler> hmm, download now 40mins :-P
14:03:22  <Ammler> marcel@xps:~/test> hg clone http://admin@localhost:5000/ogfx-trains
14:03:24  <Ammler> destination directory: ogfx-trains
14:03:25  <Ammler> requesting all changes
14:03:27  <Ammler> adding changesets
14:03:28  <Ammler> adding manifests
14:03:30  <Ammler> adding file changes
14:03:31  <Ammler> added 728 changesets with 119741 changes to 45149 files
14:03:33  <Ammler> updating to branch default
14:03:34  <Ammler> 20043 files updated, 0 files merged, 0 files removed, 0 files unresolved
14:03:36  <Ammler> marcel@xps:~/test> du -sh ogfx-trains/
14:03:37  <Ammler> 2.2G    ogfx-trains/
14:04:10  <Ammler> so it's an issue of nginx or gunicorn
14:20:02  <dihedral> Alberth, are you familiar with using osgi?
14:20:29  <Alberth> unfortunately, somewhat
14:20:43  <Alberth> I use it at work
14:22:06  <dihedral> unfortuantely?
14:22:16  <dihedral> is there something else you prefer?
14:23:14  <Alberth> no, I just hate Eclipse
14:23:32  <dihedral> you do not need to go the eclipse way :-P
14:24:03  <Alberth> please explain that to my co-workers :p
14:24:07  <dihedral> eclipse uses equniox, there is also felix for example
14:24:12  <dihedral> :-D
14:24:20  <dihedral> well, let me explain my main issue
14:24:30  <Alberth> oh, osgi in its own is quite useful
14:25:04  <dihedral> currently i use a single classloader, adding an extra url (./plugins) to look for further .jar files, and to load them, and by making use of spi I load classes
14:26:03  <dihedral> jar1 is loaded by default and does all the spi stuff, jar2 is loaded separately
14:26:48  <dihedral> if jar 2 now tries to this.getClass().getClassLoader().getResourceAsStream("some/file.txt");
14:27:09  <dihedral> and exactly this file path exists in jar1, the file from jar1 is read, not the file from jar2 :-P
14:27:47  <dihedral> is it a) better to use a separate classloader for each jar? or would it make sense to stop trying to increase the use of spi and hop on to the boat of osgi?
14:28:14  <dihedral> s/or would/or b) would/
14:28:14  <Brot6> dihedral meant: "is it a) better to use a separate classloader for each jar? or b) would it make sense to stop trying to increase the use of spi and hop on to the boat of osgi?"
14:28:22  <Alberth> wouldn't an absolute path work ?
14:28:48  <dihedral> with /home/blah/dev/plugins/jar2.jar!/some/file.txt ?
14:28:51  <dihedral> tried that
14:28:55  <dihedral> does not seem to find the file
14:29:21  <dihedral> and as long as everything is still in a jar file, i do not know how to access it other than getResourceAsStream()
14:30:16  <Alberth> there isn't much else you can do with a txt file :)
14:30:18  <dihedral> or do i not need the exclamation mark?
14:31:05  <dihedral> :-P
14:31:27  <dihedral> i mean with new File(...) for example
14:31:28  <Alberth> iirc there was a special character, not sure whether you need it or whether it is !    There are several subtle different ways of pointing to a file
14:31:45  <dihedral> hmm
14:31:51  <Alberth> some are url-ish, other are file-system-ish
14:34:00  <Alberth> osgi (the little I know about from plugin development) completely separates packages. You cannot ask what other projects exist or get some entry point
14:34:23  <Alberth> but perhaps that's eclipse doing weird things :(
14:35:34  <dihedral> so you have no chance of plugin dependencies?? that cannot be correct, as even plugins in eclipse can depend on functions provided by other plugins
14:36:14  <Alberth> oh you can have plugins, but there is an import list
14:36:44  <Alberth> and an export list too (expose these packages to other plugins)
14:37:08  <Alberth> so you can only import code from projects on the import list
14:37:47  <dihedral> currently osgi makes my head explode :-P
14:37:56  <Alberth> yeah
14:38:01  <dihedral> i fail to see how i could drop all my spi stuff and use osgi instead
14:38:09  <Alberth> too abstract too generic and not well documented at all
14:38:54  <Alberth> basically you have to read internet blog and articles to get an understanding, afaik
14:39:05  <dihedral> i'm fucked!
14:39:07  <dihedral> :-D
14:39:19  <Alberth> welcome to java, dihedral :)
14:40:00  <Alberth> although the various web frameworks in Python are also very good in this
14:40:35  <Alberth> but maybe I am getting too old :)
14:41:18  <dihedral> even in the java irc channel i got bashed and told all the time to use osgi, and only pointed to the official tutorials which imo suck
14:41:42  <dihedral> spi on the other hand + reflections make things a lot more easier
14:41:55  <dihedral> at least in my little world
14:42:08  <Alberth> until you hit a limit, like some/file.txt :p
14:43:00  <dihedral> yep
14:43:13  <dihedral> if i remove the directory and file from jar1 i have no issue though :-P
14:43:44  <dihedral> it's just that i found out that it will load the first file it finds, undless i find a way to specify a fixed jar file to look inside :-P
14:43:48  <Alberth> Probably a lot of my confusion comes from eclipse tbh, but I find it all too much to grasp
14:46:03  <dihedral> i am happy not to be the only one :-P
14:47:21  <Alberth>
14:47:22  <Webster> Title: /cif2/branches/chi3-typechecker-196-7/src/common/ – CIF (at
14:49:06  <Alberth> that's what we use to get a 'main' class from a jar file
14:49:53  <Alberth> don't know whether it is of any use to you
14:50:32  <dihedral>
14:50:34  <dihedral> :-D
14:52:42  <Alberth> not, judging by the imports :)
14:53:04  <dihedral> hehe
14:54:23  <dihedral> IF i create a separate classloader for each jar file, my problem will be, plugins interacting with eachother, as no plugin will be able to know the other
14:54:46  <dihedral> simply by there being no chance of knowing the class definition
14:55:53  <Alberth> tbh, I think plugins are more trouble than they are worth
14:56:26  <dihedral> how else is one going to be able to create a modular app?
14:56:43  <Alberth> euhm, how do they interact if they don't know each other?
14:57:11  <Alberth> since when is it good that a module does not know what other modules it talks to?
14:57:18  <dihedral> my aim is/was that grapes mainly do nothing else than plugin handling, and everything else being handled by plugins
14:57:37  <dihedral> Alberth, that is why i only use ONE classloader
14:57:47  <dihedral> as otherwise i cannot know the other plugins
14:58:50  <Alberth> sounds to me like you conflicting requirements
14:58:56  <Alberth> +have
14:59:22  <Alberth> you want plugins to know each other, but not interfer in any way
15:01:37  <dihedral> no, i want a way that inside jar2 i can access a resource located in jar2
15:01:54  <dihedral> no matter if jar1 has a resource unter the same path
15:02:01  <dihedral> relative path of course
15:02:30  <dihedral> and the special char is '!' so /path/to/jar.jar!/path/to/resource.txt
15:02:42  <dihedral> however, it cannot be used with the File class
15:04:57  <Alberth> make a separate classloader for each with a parent to some code that allows querying class loaders of other plugins?
15:05:22  <Alberth> although that sounds an awful lot like some osgi-ish thing
15:06:05  <dihedral> :-D
15:06:38  <dihedral> there must be a more simple way to force accessing a file inside a very specific jar
15:07:52  <dihedral> and then i'll simply create a wrapper method somewhere
15:08:08  <dihedral> or i write my own classloader :-D
15:10:30  <dihedral> well, own classloader would cause more issues than relieve
15:20:09  <dihedral> this.getClass().getProtectionDomain().getCodeSource().getLocation() this gives me the path of the jar file that the code is executed in
15:20:45  <dihedral> specifically it ran from a password plugin jar file and returned /home/nathanael/Development/grapes/../berries/plugins/password-0.1-SNAPSHOT.bundle.jar
15:21:25  <Alberth> and such nested objects don't scare you?
15:22:36  <Hirundo> I have trouble downloading zbase, connections get interrupted -> transactions rollback
15:22:57  <Alberth> Ammler: ^^ test-person
15:23:41  <Alberth> yeah, zbase is too big for http
15:23:59  <Alberth> you could try loading only a few revisions at a time
15:25:01  <planetmaker> Hirundo: you can try via ssh. Your key is installed on the server
15:25:23  <Hirundo> Alberth: I'm doing just that at the moment
15:25:31  <dihedral> too big for http??
15:25:44  <dihedral> i download gigabytes via http ... :-P
15:26:00  <Alberth> dihedral: either that or too many interactions between server and client
15:28:10  <dihedral> uh - found a very nasty workaround :-P
15:29:04  <Hirundo> planetmaker: I don't know if my private key survived several reinstalls and switching from cygwin to a VM
15:29:33  <planetmaker> that I don't know either ;-)
15:35:11  <dihedral> Alberth, :-D
15:35:13  <dihedral> \o/
15:35:18  * dihedral jumps for joy
15:35:30  <dihedral> this.getClass().getProtectionDomain().getCodeSource().getLocation().toURI().resolve("jar:" + this.getClass().getProtectionDomain().getCodeSource().getLocation().toURI() + "!/dictionaries/words6.txt").toURL();
15:44:50  <dihedral> ops even simpler :-P
15:45:05  <dihedral> new URL("jar:" + this.getClass().getProtectionDomain().getCodeSource().getLocation().toURI() + "!/dictionaries/words6.txt);
16:18:11  <Brot6> Berries - Revision 33:87d98202b8fc: Fix: only read the passwords file inside this jar file (fixes #2... XdihX @
16:18:11  <Brot6> Berries - Bug #2327 (Closed): Read passwords file only from own plugins jar XdihX @
16:23:14  <dihedral> Alberth,
16:23:41  <Brot6> Grapes - Revision 152:a181f945126b: Change: ingore XdihX @
16:23:41  <Brot6> Grapes - Revision 153:83294c8ece6c: Change: knowing which plugin causes an Exception while its init(... XdihX @
16:23:41  <Brot6> Grapes - Revision 154:706dcdf51cb9: Add: Methods to get URL / InputStream Objects from a resource lo... XdihX @
16:25:19  <Alberth> dihedral:  nice !  quite simple
16:25:40  <dihedral> indeed
16:25:57  <dihedral> why is it not documented anywhere - i googled for this issue quite a few times
16:26:17  <dihedral> and where could i document it without opening a blog myself :-P
16:27:20  <Alberth> in the java file? :)
16:49:08  <Brot6> zBase - Bug #4085 (New): 'jitter' in the bricks of the copper ore mine animation XAlberthX @
16:51:15  <Brot6> zBaseBuild - Revision 17:2134a4302bd7: -Add: copper ore mine, diamond mine, fixed coal mine. XAlberthX @
16:54:18  <dihedral> Alberth, if google reads that :-P
16:54:54  <Alberth> it does probably, but it does not return it to you :p
16:57:12  <dihedral> iirc they have stopped reading publicly available source files, or rather they do not show them in the results anymore
16:58:10  <Alberth> makes sense, there is little information in them, except for a few
16:58:36  <Alberth> but extracting the information is way too complicated
17:06:44  <dihedral> google codesearch was lovely :-P
17:07:23  <Alberth> oh, that actually existed?  Never knew that :)
17:09:27  <dihedral> you could search for language, etc.
17:09:37  <dihedral> they now only provide that for projects on google code
17:10:28  <dihedral> if in java you needed examples of certain packages being used it was very helpful :-P
17:10:39  <Alberth> I can imagine :)
17:11:30  <Alberth> hmm, one whole day of work, just about 60*3 new sprites added
17:12:10  <Rubidium> Alberth: that sucks :(
17:12:22  <Rubidium> did you try nmlc -u instead of nmlc -c for a speedup?
17:12:58  <Rubidium> that leaves out cropping and compressing the sprites, which yielded a ~60% speed up last time I tried
17:13:30  <Alberth> no, but I haven't build many times, i was mostly messing with the sprite aligner for each depot
17:14:27  <Alberth> and the computations ran in parallel with my natural breaks, like lunch, coffee, and dinner :)
17:15:52  <Alberth> we should make a file with sprite offsets that you can edit from within openttd with the sprite aligner :p
17:19:39  <Brot6> nml: update from r1930 to r1931 done -
17:51:11  <planetmaker> it might speed up things considerably, if opengfx sprites were converted to DOS. Then we could use grfcodec instead of nmlc
17:52:26  <Alberth> I was somewhat pondering to attach a small program to nml to do the heavy calculation stuff
17:53:01  <Alberth> except
17:53:18  <Alberth> I have so many other things to do already :p
17:58:53  <planetmaker> which calculation, Alberth?
18:00:29  <Alberth> whatever nml is doing after deciding what to generate, mostly
18:01:05  <Alberth> Python is bad at byte/bits pushing, you should do that in C or cython or so
18:03:44  <Alberth> ie the experiment by RB suggests it spends 6 minutes on compressing/cropping images
18:06:16  <Rubidium> Alberth: simpler would be generate the nfo, let grfcodec do the compressing/cropping
18:06:20  <planetmaker> ah. You mean to out-source the sprite processing
18:06:49  <planetmaker> Rubidium: yes. That approach requires opengfx to have only DOS-paletted sprites, though. It doesn't have that atm
18:07:06  <Alberth> planetmaker: better extend grfcodec then
18:07:08  <planetmaker> nmlc on the other hand detects the palette and auto-converts to DOS
18:08:50  <Hirundo> I'm still working on adding caching to nml
18:08:54  <Alberth> theoretically, nml could build an AST like what grfcodec uses, and then call grfcodec as a library to do its processing
18:09:45  <Alberth> Hirundo: does that work on compile farms?
18:10:03  <Alberth> which build everything one time from scratch, every day
18:10:11  <Hirundo> Alberth: I don't know
18:10:26  <Hirundo> If it creates a completely clean environment, probably not
18:10:57  <Alberth> for newgrf developers it would help a lot, I think
18:11:45  <Hirundo> I hope so, I can't test until I have the bugs ironed out
18:12:03  <Alberth> Hirundo: where do you store the cache?
18:12:24  <Hirundo> Currently next to the grf
18:12:39  <Hirundo> as foo.grf.cache and foo.grf.cacheindex
18:12:55  <Hirundo> .cacheindex contains the meta-data as JSON, .cache the raw sprite data
18:13:55  <Alberth> sounds good
18:14:05  <planetmaker> Alberth: such thing would work on our CF. And the caching would work, too. But there it's not that important
18:14:39  <planetmaker> thus starting with clean would give no bonus. But... really it matters for us at home when dev'ing
18:15:39  <Alberth> sure, and it is an order of magnitude simpler to cache results than to speed up these calculations
18:15:59  <Alberth> especially if you don't want to lose cross-platform operation
18:16:18  <Hirundo> the only way to achieve a real speedup is to use C/C++, either as some module or via grfcodec
18:17:41  <Alberth> eventually, you could merge nml and grfcodec  so you don't need to generate text that grfcodec parses again
18:17:51  <Alberth> but that's even more complicated
18:19:49  <Rubidium> doesn't sound like a sane solution
18:20:20  <Rubidium> because that requires massive grfcodec changes, and it's not a codebase I'd like to add another input format to
18:22:02  <Alberth> grfcodec would become somewhat of a backend library
18:22:32  <Alberth> I don't think you'd keep much of the current grfcodec structure
18:22:32  <Rubidium> at that moment it doesn't resemble grfcodec anymore
18:22:57  <Alberth> indeed, it get split in many pieces
18:23:21  <Alberth> it's more more likely in such a case that you add nfo as input format to nml
18:23:27  <Hirundo> You might as well rip out the image loading / sprite writing code (it's GPL, right?) and let that write the 'sprite section' of the grf, while NML writes the 'data section'
18:24:14  <Rubidium> image loading is very nasty code
18:24:51  <Hirundo> nasty in what way?
18:24:53  <Alberth> another option is to make a somewhat higher level format. Basically, nml should tell what to generate, not actually do the generation
18:25:44  <Rubidium> 1) DaleStan code
18:25:49  <Hirundo> that format exists already as nfo
18:26:22  <Alberth> Rubidium: it may be easier to rewrite the current nml code to C
18:26:28  <Rubidium> 2) massive sharing with sprite writing code
18:26:54  <Alberth> Hirundo: partial compilation?
18:27:15  <Rubidium> 3) lots of similarly named/functioning functions, but slightly different. The only way to know which one gets actually ran is by running it in a debugger
18:27:43  <Rubidium> 4) spent weeks trying to get the sprite reading/writing code to actually function when adding 32bpp support
18:28:00  <Rubidium> 5) still don't understand the code or what I did to that code
18:28:10  <Hirundo> :o that's baad
18:29:00  <Hirundo> Alberth: Could you explain? partially compiling what?
18:29:13  <Rubidium> the sprite writing code is slightly better are it was mostly rewritten, but heavily intertwined with writing the actual data
18:29:21  <Alberth> Hirundo: compile each .pnml file separately
18:29:36  <Alberth> then 'link'
18:30:45  <Hirundo> Alberth: That's really tricky, NML was not designed with that in mind
18:31:54  <Hirundo> It may be possible, but with restrictions (e.g. no cross-referencing action2s)
18:32:00  <Alberth> currently you don't even have a format to express the information you need during linking. In fact, I wouldn't know what you need to know at that stage
18:32:42  <Alberth> but most of the action/sprite/xyz number assignments would move out of nml
18:33:19  <Alberth> unfortunately, it is probably tmwftlb
18:34:00  <Hirundo> Alberth: How long does building zbasebuild take for you?
18:34:17  <Alberth> which revision?
18:34:26  <Rubidium> I think that such a pnml should work together with the cached compiled real sprites. Then you store the nml AST that you optimised as much as possible (replacing static stuff), and build the sprites. When linking you load the ASTs, link them together, run another optimisation run and emit everything with the cached real sprites
18:34:53  <Brot6> FISH - subtypes_5.png XandythenorthX @
18:34:58  <Rubidium> Hirundo: few revisions ago it was 10 minutes for me (or 4 with -u and without -c)
18:35:14  <Alberth> for a baseset it should be really simple
18:35:42  <planetmaker> for the 5 base grfs yes. The extra is just a normal newgrf
18:35:44  <Hirundo> Indeed (ignoring the extra grf)
18:35:49  <planetmaker> though simple mostly, too
18:36:12  <Alberth> Hirundo: I can measure it if you want, I have seen 13 minutes execution time, but I did not time it
18:36:35  <Hirundo> It's done with the first two now, so I expect it to finish soon
18:36:45  <Hirundo> (ish)
18:39:31  <Rubidium> Hirundo: did you do -jN ?
18:40:14  <Rubidium> if so, then everything seems to be done except the base one, and it still takes probably more time than it took to build the others
18:40:21  <Alberth> or in general, expect several nml's running concurrently :)
18:42:18  <Hirundo> I did not do -jN, but I don't know if it helps inside a VM
18:42:51  <planetmaker> depends on the config, whether it can use severa cores
18:43:01  <Hirundo> CPU usage is a little above 50% (dual core machine)
18:46:24  <Rubidium> how much time is spent in Windows -> DOS palette conversion?
18:47:12  <Rubidium> i.e. might it be feasible to convert the palette and use grfcodec for creating the actual GRFs?
18:47:49  <Rubidium> although... you might just try it with grfcodec right now and ignore the wrong colours for the non 32bpp sprites
18:48:04  <Rubidium> for development that might help
18:48:24  <Rubidium> (don't know how long building such a grf with grfcodec would take though)
18:55:27  <Hirundo> Currently I'm doing 'time make' with caching enabled and cache files present, so we'll see...
18:55:59  <planetmaker> o_O. Still building
18:57:48  <Hirundo> No, rebuilding
18:57:57  <Hirundo> caching only works the second time :-)
18:58:47  <Alberth> it works the first time too, but you get 100% cache misses :p
18:58:50  <planetmaker> I'm talking of my 'time make' :-P
18:59:10  <Alberth> although, if you use the same sprite more than once?
19:00:16  <Brot6> FISH - Revision 782:dee171bda336: Change: cargo subtypes work across more cases of 'class is present... XandythenorthX @
19:04:04  <Brot6> FISH - subtypes_6.png XandythenorthX @
19:05:15  <Brot6> FISH - subtypes_7.png XandythenorthX @
19:05:19  <Hirundo> Using the same sprite more than once will make use of the cache
19:22:55  <Alberth> Hirundo: make  1697.61s user 12.85s system 99% cpu 28:32.28 total  <-- 'time make' after 'make clean'
19:23:39  <Alberth> ie full rebuild
19:25:25  <Rubidium> Hirundo: w.r.t. reuse, what if you use -c and one has nocrop and the other (same image) doesn't have nocrop?
19:27:28  <Alberth> good night
19:28:01  *** Alberth has left #openttdcoop.devzone
19:36:37  <Brot6> FISH - Revision 783:7ba80670d9d5: Change: make subtype strings light blue XandythenorthX @
19:56:15  <Brot6> FISH - Revision 784:1db266c09212: Change: make subtypes simpler, don't bother with special cases XandythenorthX @
20:01:56  <Brot6> FISH - Revision 785:e327988cbd4e: Change: set subtype strings according to graphics template used XandythenorthX @
20:17:53  <Brot6> FISH - Revision 786:afca17115676: Codechange: unify some autorefit stuff XandythenorthX @
20:27:46  <Brot6> FISH - Revision 787:642b2209c01a: Change: partial completion of autorefit; also remove some incorrec... XandythenorthX @
20:52:54  *** LordAro has quit IRC
20:57:17  *** frosch123 has quit IRC
21:16:37  *** LordAro has joined #openttdcoop.devzone
21:38:05  *** ODM has quit IRC
22:53:05  <Hirundo> Rubidium: Cropping yes/no is part of the 'key' used for the cache, so a cropped sprite won't be reused for a non-cropped one
23:07:00  <Brot6> zBase - Revision 24:a760531c8c8b: Add: Paper mill. XzephyrisX @
23:20:57  <Brot6> NewGRF Meta Language - Revision 1932:8e4ef7518f2b: Add: Constant CB_RESULT_REFIT_COST_MASK XHirundoX @
23:26:04  <Brot6> zBase - Revision 25:fb26e835fa47: Add: Updated power station working files (unfinished). XzephyrisX @

Powered by YARRSTE version: svn-trunk