Config
Log for #openttdcoop.devzone on 23rd February 2014:
Times are UTC Toggle Colours
01:34:48  *** yorick has quit IRC
03:16:07  *** Supercheese has joined #openttdcoop.devzone
03:33:49  *** gelignite has quit IRC
06:30:40  *** ODM has joined #openttdcoop.devzone
07:19:18  *** TheODM has joined #openttdcoop.devzone
07:22:50  *** ODM has quit IRC
07:34:51  *** Supercheese has quit IRC
09:37:40  *** Alberth has joined #openttdcoop.devzone
11:21:48  *** frosch123 has joined #openttdcoop.devzone
11:27:50  *** oskari89 has joined #openttdcoop.devzone
12:15:56  *** oskari89 has quit IRC
12:28:51  <DevZone> Project opengfx-mars build #38-push: SUCCESS in 2 min 21 sec: https://jenkins.openttdcoop.org/job/opengfx-mars/38/
12:51:31  *** yorick has joined #openttdcoop.devzone
14:41:39  *** Hirundo has quit IRC
14:43:00  *** Hirundo has joined #openttdcoop.devzone
14:43:53  *** Rubidium has quit IRC
14:43:55  *** Rubidium has joined #openttdcoop.devzone
16:20:41  <DevZone> Project opengfx-mars build #39-test: SUCCESS in 2 min 12 sec: https://jenkins.openttdcoop.org/job/opengfx-mars/39/
16:20:49  <DevZone> Project Townnames - German build #22-test: SUCCESS in 7.8 sec: https://jenkins.openttdcoop.org/job/german-townnames/22/
16:20:50  <DevZone> Project NML - NewGRF Meta Language build #263-nightlies: SUCCESS in 3 min 3 sec: https://jenkins.openttdcoop.org/job/nml/263/
16:48:55  <DevZone> Project Dutch Trainset build #88-push: SUCCESS in 1 min 21 sec: https://jenkins.openttdcoop.org/job/dutchtrains/88/
16:49:06  <DevZone> Project FISH is ships build #169-push: SUCCESS in 1 min 28 sec: https://jenkins.openttdcoop.org/job/fish/169/
16:50:41  <DevZone> Project Iron Horse build #688-push: SUCCESS in 1 min 46 sec: https://jenkins.openttdcoop.org/job/iron-horse/688/
16:51:10  <DevZone> Project Dutch Road Furniture build #14-push: SUCCESS in 2 min 4 sec: https://jenkins.openttdcoop.org/job/dutchroadfurniture/14/
16:51:11  <DevZone> Project Dutch Rail Furniture build #22-push: SUCCESS in 29 sec: https://jenkins.openttdcoop.org/job/dutchrailfurniture/22/
16:51:41  <DevZone> Project 2ccts build #36-push: SUCCESS in 30 sec: https://jenkins.openttdcoop.org/job/2ccts/36/
17:05:53  *** oskari89 has joined #openttdcoop.devzone
17:22:02  <DevZone> Project Japanese Buildings build #120-nightlies: SUCCESS in 16 sec: https://jenkins.openttdcoop.org/job/jpbuild/120/
17:34:06  <DevZone> Project Finnish Rail Infrastructure - Rails build #234-nightlies: SUCCESS in 8 min 19 sec: https://jenkins.openttdcoop.org/job/frissrails/234/
17:48:11  <DevZone> Project Iron Horse build #689-nightlies: SUCCESS in 1 min 21 sec: https://jenkins.openttdcoop.org/job/iron-horse/689/
18:51:59  *** gelignite has joined #openttdcoop.devzone
19:49:35  <Alberth> planetmaker: it's a bit more quiet here, any idea about the state of opengfx mars, or how to get such an idea?
19:50:26  <planetmaker> I don't think anything really happend... only way I would know to check is hg log on main or sub projects
19:51:06  <planetmaker> I've a somewhat bad concience. I meant to do more than I actually did so far
19:52:46  <Alberth> well, I got into industries, and they seem somewhat done for a first version to me. There is the snowy stuff to do, but meh
19:53:05  <Alberth> so I wonder what to switch to
19:53:24  <Alberth> perhaps I should find sprites that are not used or so?
19:53:40  <planetmaker> right. snowy version might be something for after first release
19:55:10  <Alberth> there is also the issue of cargo that I don't know how to do, or rather, I'd like your opinion on it
19:55:14  <planetmaker> https://paste.openttdcoop.org/show/3136/ <-- do we have some bad alignment?
19:55:42  <Alberth> the industries have a cargo table, and I ran into another cargo table in the trains iirc
19:56:03  <Alberth> obviously, they should be shared, but if so, where?
19:57:37  <Alberth> in industries I'd be surprised, I used a computer program to find the areas, and checked all buildings for alignment, although not while being build
19:57:41  <planetmaker> I wondered about a place for commonly shared stuff, too. I didn't exactly find a good answer yet
19:58:22  <planetmaker> I wondered whether these snippets should go into the graphics dir / sub-repo. But that's somewhat wrong
19:58:48  <planetmaker> Or whether we should create a new shared code dir in the main repo? Or a new one? Or rename 'graphics' into shared?
19:59:26  <Alberth> I can see a number of options  1. define a place for it, and other take it from there   2. opengfx main repo   3. merge repos into 1
19:59:35  <Alberth> *others
20:00:56  <Alberth> 1 seems to be the simplest answer, but it may make stuff somewhat unfindable
20:02:13  <Alberth> another consideration is perhaps whether these newgrfs should be playable stand-alone, or always together?
20:02:17  <planetmaker> hm... slight preference: while it's somewhat 'wrong' it might be preferrable to put the shared code in a sub-dir in the graphics (sub)repo.
20:02:44  <Alberth> at least we know where to look for shared stuff then :)
20:02:54  <planetmaker> for that reason, yes
20:03:08  * Alberth is +1 for that
20:03:23  <planetmaker> as to the latter question: Personally I prefer to be able to use the NewGRFs in principle stand-alone
20:03:43  <planetmaker> even though they're strongly designed to be used alongside eachother
20:04:03  <planetmaker> (if they were not stand alone, there'd be no point to have different repos and NewGRFs i nthe first place)
20:04:26  <Alberth> k, it was not clear to me
20:05:21  <Alberth> http://www.tt-forums.net/viewtopic.php?f=29&t=70047   did you see this clash between manual industries and opengfx+industries?
20:05:22  <Webster> Title: Transport Tycoon Forums View topic - Manual Industries 2r5 with openGFX industries? (at www.tt-forums.net)
20:05:45  <Alberth> the latter doesn't have a check for manual industries, it seems; I briefly checked the code
20:06:57  <planetmaker> yes, I noticed. Seems indeed like a missing check
20:07:15  <planetmaker> actually opengfx+ industries has a feature (request) to add the manual industries feature to it
20:07:32  <Alberth> how predictable :p
20:08:55  <planetmaker> I think I added that feature request myself ages ago
20:08:59  <planetmaker> :)
20:09:41  <Alberth> I am also somewhat wondering what to do with nml in long term; the least amount of work would be to switch to python 3
20:10:13  <Alberth> adding partial compile, or rewrite to c++ can also be considered, but seem a lot more work
20:10:57  <planetmaker> mercurial is also struggling with the transition to python3
20:11:03  <planetmaker> mercurial devs themselves
20:11:50  <planetmaker> does python3 allow partial compile?
20:12:03  <planetmaker> or was that part of c++ suggestion?
20:12:39  <Alberth> partial compile of nml code I meant, probably through partially compliled nfo or so
20:13:19  *** Supercheese has joined #openttdcoop.devzone
20:13:36  <Alberth> although it may be a bit overkill; grfcodec seems fast enough
20:13:41  <Alberth> afaik
20:15:00  <Alberth> there is no such feature request in opengfx+industries :)
20:15:28  <planetmaker> http://dev.openttdcoop.org/issues/2624
20:16:00  <Alberth> oh, I am blind :)
20:17:08  <planetmaker> with NML future you raise an important question though, IMHO
20:17:24  <planetmaker> Both is not easy, but python2->python3 certainly is easier than a transition to c++
20:17:47  <planetmaker> the question though is: what's 'better' in the long run?
20:18:02  <planetmaker> and can a transition python->c++ be a smooth one?
20:18:26  <planetmaker> I really dread a dead time with really no progression at all. All time spent only on conversion with nothing really gained
20:18:36  <planetmaker> (it's what killed netscape etc...)
20:20:25  <planetmaker> but it might open the door to a faster compiler. But... honestly, I do not feel competent enough to actually make that decision
20:21:00  <planetmaker> I really do feel incompetent when it comes to compiler development. I lack a lot of knowledge there
20:21:09  <Alberth> if I have to do it, I start from scratch in c++, building nml with the same functionality
20:21:38  <Alberth> the important thing is that we need the existing tool in the mean time
20:22:57  <planetmaker> NML won't vanish. What I can surely do is do the 'support' I did so far. Adding new properties and variables as they are added
20:23:05  <Alberth> obviously, you can use the python code to look how it can be done, but without deep understanding of newgrf, I will fail at a simple 1-to-1 conversion, if it's wrong, I wouldn't know where to look
20:23:10  <planetmaker> Fixing the occasional bug. Like also you and frosch do
20:24:03  <Alberth> thus I need to see and write each class from scratch, so I understand what they do, and how they work together
20:24:25  <planetmaker> Hm, yes
20:24:29  <Alberth> yeah, perhaps an experiment towards python 3 would be a good step
20:24:51  <planetmaker> would that make c++ easier?
20:25:13  <Alberth> not really, but it ensures we'll keep nml alive
20:25:22  <planetmaker> and is speed the only reason for c++?
20:25:39  <planetmaker> or is there something which slipped my mind or which I miss?
20:25:41  <Alberth> given that nml is too slow currently, yep
20:26:42  <Alberth> y3xo did an experiment to handle graphics by c++, but the overhead python -> c++ was too big
20:27:16  <planetmaker> I see
20:27:37  <Alberth> the alternative is of course to make partial compilable files with nml, and link them together
20:27:49  <Alberth> then you normally need to process only a few files
20:28:07  <planetmaker> that will impose quite some limitations on how you can write your code
20:28:29  <Alberth> depends on the back-end, which currently doesn't exist at all
20:28:42  *** oskari89 has quit IRC
20:29:04  <Alberth> hmm, and probably also you need external declarations in nml
20:29:13  <Alberth> that may defeat the entire purpose :p
20:29:18  <planetmaker> you mean to implement a kind of pre-processor step. Or compiling to object code which then only still needs linking?
20:30:14  <Alberth> the latter, but if you want to read only a few files, they need to have enough information to be processed, in particular info from files that are not read
20:30:30  <Alberth> so you need to declare such things
20:30:52  <Alberth> eg "spriteset foo;"    meaning that "foo" points to a sprite set
20:30:58  <planetmaker> the problem I then always see is the action2 numbering
20:31:25  <frosch123> you can also go the nml->nfo in python, nfo->grf in c++ route
20:31:27  <planetmaker> you can't have global ones then. or you need additional syntax to delcare something global
20:31:55  <planetmaker> nmlc can already output nfo. That's a solved problem really?
20:31:57  <Alberth> frosch123: yes, if grfcodec is fast enough
20:32:01  <frosch123> iirc the only thing with that was the nml by default chooses the compression, but that is could be moved to the nfo->grf part as well
20:32:18  <planetmaker> ah
20:32:47  <frosch123> grfcodec may have ugly/magic/horrible code, but it is fast and works :)
20:33:11  <frosch123> "works" as in, there has been enough testing and fixing
20:33:18  <planetmaker> yup
20:33:43  <Alberth> that would make python fast enough ?
20:33:46  <frosch123> generally i think staying with python as much as possible is better than trying c++
20:34:19  <Alberth> it's much less work at least :)
20:36:26  <frosch123> nfo may also be the wrong intermediate format
20:36:35  <planetmaker> so basically going back to what we had before: nml->nfo instead of nml->grf
20:36:45  <planetmaker> or something new
20:36:54  <frosch123> if we want to go towards partial compile, we may want some format with references to ids or so
20:37:20  <planetmaker> the IDs might be replaced in the final compile step, yes
20:37:30  <planetmaker> during linking
20:37:55  <frosch123> basically, resolve all switches during a partial compile, but keep the item names and cargo labels and such
20:38:27  <frosch123> and parameter names and such
20:38:52  <frosch123> yeah, basically resolve only the switches and leave the rest :p
20:39:26  <planetmaker> might do the trick
20:39:27  <Alberth> if grfcodec is fast enough, it may be overkill to do that
20:40:11  <frosch123> he :p i was refering to the case that "nml->nfo" is not fast enough
20:42:37  <Alberth> ah, ok
20:43:25  <frosch123> and if it really is needed we can speed up grfcodec a lot
20:43:39  <planetmaker> hm. Ok. So let's stay with python. Try at a python2->3 conversion. And try to split processing into two separate phases, so that in a 'linking' steps which allows partial compiles
20:43:42  <frosch123> it is currently quite slow with 32bpp because it has only one file opened at a time
20:43:50  <frosch123> so, it closes and reloads the same files all the time
20:44:03  <planetmaker> resolveing the switches might take already quite some time.
20:44:14  <frosch123> so, if you are really interested you could cache more graphics files, and even make the whole thing multithreaded
20:44:43  <Alberth> we should hire andy :p
20:45:38  <planetmaker> :)
20:45:48  <planetmaker> last multithready by him was a fork bomb :P
20:47:19  <planetmaker> but adding threading to especially graphics processing...
20:49:38  <Alberth> I am sure there are lots of things that can be improved :)
20:59:59  *** TheODM has quit IRC
21:40:18  *** Alberth has left #openttdcoop.devzone
21:45:36  *** gelignite has quit IRC
22:43:58  *** frosch123 has quit IRC

Powered by YARRSTE version: svn-trunk