Log for on 11th October 2012:
Times are UTC Toggle Colours
00:34:43  *** Supercheese has quit IRC
00:42:19  *** Supercheese has joined
00:54:43  *** Supercheese has quit IRC
01:12:57  *** Supercheese has joined
10:53:38  *** Hirundo_ has joined
10:54:08  *** Yexo- has joined
10:54:38  *** pm has joined
10:54:38  *** ChanServ sets mode: +v pm
10:56:38  *** |Terkhen| has joined
10:58:36  *** Hirundo has quit IRC
11:00:06  *** Terkhen has quit IRC
11:00:16  *** planetmaker has quit IRC
11:00:16  *** pm is now known as planetmaker
11:00:17  *** Yexo has quit IRC
11:03:12  *** fonsinchen has joined
11:32:02  *** Supercheese has quit IRC
11:32:32  *** Supercheese has joined
12:30:34  *** Yexo- is now known as Yexo
12:30:50  *** ChanServ sets mode: +v Yexo
13:20:04  <Belugas> hello
13:42:50  <Belugas> Yexo, looks like you have been quite tedious at the task :)
13:43:20  <Yexo> hi Belugas
13:43:29  <Yexo> yes indeed, it took quite some time
13:43:49  <Yexo> looks like I'm almost there now
13:43:55  <Belugas> you had to modify the sources, or just the compiler?
13:44:02  <Yexo> only the so
13:44:04  <Yexo> sources
13:44:12  <Yexo> I've used the gcc compiler from the android ndk
13:44:54  <Yexo> source changes are very minor for just android, a few changes to config.lib to let it recognize ANDROID as host and 3 or 4 #ifdef ANDROID in the code
13:45:25  <Yexo> to get any real output it needs SDL2 (or 1.3 from somewhere else), with requires some more changes, but those should not be android specific
13:46:15  <planetmaker> probably SDL2 then rather than a patched 1.3 from *somewhere*?
13:46:36  <Yexo> has sdl1.2 (stable) and sdl2 (work in progress)
13:47:00  <Yexo> sdl2 is basically a renamed 1.3, but as far as I know there has never been a "stable" 1.3 release
13:47:15  <Yexo> ^^ that might be inaccurate
13:47:20  <Belugas> mmh..
13:47:41  * Belugas sends tons of congratulations to Yexo for hard work :)
13:47:46  <Yexo> thanks :)
13:48:20  <Yexo> sdl2 comes with android support, some builds of sdl1.3 maybe too. The android port on the forum uses a custom version of sdl1.3
13:48:30  <Yexo> that means not so much changes to sdl_v.cpp as I need
13:48:48  <Yexo> but on the other hand I properly compile openttd with our own buildsystem, no nasty hacks like removing stdafx.h
13:48:57  <planetmaker> :-)
13:48:59  <Belugas> yeah
13:49:07  <Belugas> wondered what were the impacts
13:49:15  <Yexo> also the java code required to run an sdl app with sdl2 is very minor (only 1 file with +- 600loc)
13:49:26  <Yexo> the 'other' build uses 10 or so java files with lots of cruft
13:49:59  <planetmaker> :-) very much kudos for getting that done :-)
13:50:01  <Belugas> swa it, indeed
13:50:05  <Belugas> saw
13:50:30  <Belugas> i remember the guy not wanting to rewrite those to c++ or something
13:52:12  <Yexo> tonight I hope to finish including all required data files (language files, baseset etc.) and start cleaning up the mess I created
13:52:36  <Yexo> after that I'll post an howto which should make it very easy to reproduce
13:53:08  <planetmaker> interestingly, the SDL repo has branches for SDL-1.2, SDL-1.3, SDL-1.2-olpc and experimental besides the default branch
13:53:36  <planetmaker> and several gsoc2008/9 ones
13:55:29  <Yexo> first back to work :p
13:59:26  <Belugas> how improper...
15:11:07  *** fonsinchen has quit IRC
15:53:03  *** frosch123 has joined
15:53:03  *** ChanServ sets mode: +v frosch123
16:11:33  <frosch123> there are a lot of small useful patches on fs lately :)
16:17:40  *** |Terkhen| has left
16:17:47  *** Terkhen has joined
16:17:47  *** ChanServ sets mode: +v Terkhen
16:17:49  <Terkhen> hi
16:18:41  <frosch123> hola terkhen :)
16:58:48  *** Alberth has joined
16:58:48  *** ChanServ sets mode: +v Alberth
17:08:47  <Yexo> there are more patches, but it seems we've also been less active in applying them
17:44:12  *** fonsinchen has joined
17:45:34  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24585 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:03:22  <Alberth> frosch123: is it useful to discuss the reolver object patches, or is it too early?
18:03:49  <Alberth> +s
18:05:57  <frosch123> forgot what the state was :s
18:06:31  <frosch123> was there something new since when i played with it?
18:07:56  <Alberth> it raised some questions, but you achieved your aim, was the last what I heard
18:09:54  <frosch123> ok, do we have decided for some final structure (wrt. the base classes)?
18:10:21  <frosch123> and if, is there a way to go more straight to that by merging some changes in the current queue?
18:10:53  <frosch123> resp. reordering it or similar
18:11:15  <Alberth> I think the former question is best answered by you, I have not much clue of the structure there
18:11:38  <Alberth> and as a result, also not much opinion about it
18:12:31  <Alberth> and yes, at least the part I coded has a few turns that can be straightened out, you also added a few I think :p
18:12:56  <frosch123> well, then i think we should go for the baseclasses we currently have
18:13:11  <frosch123> though i think i only ever compiled and linked, and never started :p
18:13:34  <frosch123> did you check whether something is obviously broken? i didn't :p
18:13:55  <Alberth> not more than checking compilation :p
18:14:30  <Alberth> is the code critical w.r.t. speed?
18:14:50  <Alberth> I can imagine making additional objects is not good for execution speed
18:15:45  <frosch123> they were also function pointers before
18:16:06  <Alberth> :)
18:16:36  <frosch123> anyway, i think the basic rule holds, first make it good, then make it fast
18:16:56  <Alberth> sounds like a plan :p
18:16:56  <frosch123> and the new structure should help a lot wrt. secondary scopes
18:17:23  <Alberth> do you have the latest version somewhere available?
18:19:47  <frosch123> <- that's the last state i had
18:19:57  <frosch123> your queue updated to tip (back then)
18:20:02  <frosch123> plus 6xx from me
18:21:02  <Alberth> k
18:22:00  <Alberth> perhaps it is good to start from scratch, so all the changes can be done properly
18:25:12  <frosch123> what would be the ideal order to add stuff?
18:25:57  <frosch123> maybe separate towns first?
18:26:12  <frosch123> 600 + 400 ?
18:26:57  <Alberth> quite likely, towns are used a lot
18:27:27  <frosch123> they also only have one attribute, and are already somewhat separate
18:28:07  <frosch123> hmm, but that would already need separate resolverobjects
18:30:15  <frosch123> so, maybe: 1. ScopeResolver baseclass 2. scoperesolver with function pointers, 3. specialised resovlerobjects retunring scoperesovlers with function pointers, 4. stand-alone town-scoperesolver
18:30:21  <Alberth> I don't even remember how I started :)
18:31:59  <frosch123> i wonder whether there is some way to introduce the baseclasses while keeping the function poiners
18:32:09  <frosch123> so later all features can be converted step by step
18:32:21  <frosch123> while the final structure is already in place
18:32:32  <frosch123> so the big functions are only touched once
18:34:26  <Alberth> you cannot make a new structure, and replacing the functions by stubs forwarding the calls?
18:35:14  <frosch123> hmm, "you can" or "you cannot"?
18:36:11  <frosch123> i guess, we might keep all member variables of the resolverojbect union till the end
18:36:37  <frosch123> make all new functions, and then forward all calls with the old resolverobject structuire
18:36:47  <frosch123> then, replace the features each by each
18:37:46  <Alberth> something in that direction :p
19:53:37  <frosch123> night
19:53:40  *** frosch123 has quit IRC
20:35:52  *** FLHerne has joined
20:44:19  *** Alberth has left
22:51:10  *** fonsinchen has quit IRC
23:20:16  *** FLHerne has quit IRC

Powered by YARRSTE version: svn-trunk