IRC logs for #openttd.dev on OFTC at 2012-10-11
⏴ go to previous day
00:42:19 *** Supercheese has joined #openttd.dev
01:12:57 *** Supercheese has joined #openttd.dev
10:53:38 *** Hirundo_ has joined #openttd.dev
10:54:08 *** Yexo- has joined #openttd.dev
10:56:38 *** |Terkhen| has joined #openttd.dev
11:00:16 *** pm is now known as planetmaker
11:03:12 *** fonsinchen has joined #openttd.dev
11:32:32 *** Supercheese has joined #openttd.dev
12:30:49 *** ChanServ sets mode: +v Yexo
13:42:50 <Belugas> Yexo, looks like you have been quite tedious at the task :)
13:43:29 <Yexo> yes indeed, it took quite some time
13:43:49 <Yexo> looks like I'm almost there now
13:43:54 <Belugas> you had to modify the sources, or just the compiler?
13:44:11 <Yexo> I've used the gcc compiler from the android ndk
13:44:53 <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> libsdl.org 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:14 <Yexo> ^^ that might be inaccurate
13:47:41 * Belugas sends tons of congratulations to Yexo for hard work :)
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:47 <Yexo> but on the other hand I properly compile openttd with our own buildsystem, no nasty hacks like removing stdafx.h
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: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
15:53:03 *** frosch123 has joined #openttd.dev
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:39 *** |Terkhen| has left #openttd.dev
16:17:47 *** Terkhen has joined #openttd.dev
16:17:47 *** ChanServ sets mode: +v Terkhen
16:58:48 *** Alberth has joined #openttd.dev
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 #openttd.dev
18:03:21 <Alberth> frosch123: is it useful to discuss the reolver object patches, or is it too early?
18:05:57 <frosch123> forgot what the state was :s
18:06:30 <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:37 <Alberth> and as a result, also not much opinion about it
18:12:30 <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:35 <frosch123> anyway, i think the basic rule holds, first make it good, then make it fast
18:16:55 <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:57 <frosch123> your queue updated to tip (back then)
18:21:59 <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:57 <Alberth> quite likely, towns are used a lot
18:27:26 <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:31 <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:13 <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:46 <frosch123> then, replace the features each by each
18:37:45 <Alberth> something in that direction :p
20:35:52 *** FLHerne has joined #openttd.dev
20:44:19 *** Alberth has left #openttd.dev
continue to next day ⏵