Log for on 2nd February 2014:
Times are UTC Toggle Colours
07:00:41  *** Supercheese has quit IRC
09:13:07  *** adf88 has joined
09:13:07  *** ChanServ sets mode: +v adf88
09:24:39  *** Alberth has joined
09:24:39  *** ChanServ sets mode: +v Alberth
10:01:14  *** Ristovski has joined
10:50:15  *** adf88 has quit IRC
10:59:30  <fonsinchen> Hello
11:49:11  *** frosch123 has joined
11:49:11  *** ChanServ sets mode: +v frosch123
12:03:34  <fonsinchen> The diagonal tile iterator is actually running "backwards". I wonder if we should change that.
12:06:29  <frosch123> what is backwards/forward?
12:07:11  <frosch123> even for the orthogonal one i would not know whether it runs X or Y first
12:18:53  <fonsinchen> Well, it runs from corner2 to corner1, contrary to the documentation
12:19:07  <fonsinchen> Simple parameter renaming fixes that.
12:20:11  <frosch123> hmm, how does it behave with level land in case you do not have enough money?
12:20:23  <frosch123> maybe it is also switched in the gui
12:20:42  <frosch123> but well, i wouldn't know where it should start leveling either :p
12:21:23  <fonsinchen> I'm working on a little patch to add a simple diagonal tile area and fix all the inconsistencies in there.
12:21:55  <frosch123> yeah, i am thinking about cases where the iteration order might actually matter
12:22:02  <frosch123> i.e. what would be affected by "fixing" it
12:32:59  <fonsinchen> I'd just do that on a purely syntactical base. Just switch the order of arguments in the two places it's used ...
12:34:12  <fonsinchen> Or maybe not. It just looks nicer when the diagonal and orthogonal iterators have the same order of arguments
12:34:42  <fonsinchen> And I seem to remember that the diagonal leveling when not enough money actually works "backwards".
12:34:51  <fonsinchen> That's somewhat unintuitive anyway
12:44:32  <fonsinchen> In fact the _orthogonal_ leveling and raising starts at the end of the area you've dragged ...
12:46:45  <fonsinchen> I think we should change them both to start at the start of the area you've dragged.
12:50:34  <frosch123> does it always start at the end? or does it depend on drag direction? (upwards/downwards)
13:06:36  <fonsinchen> It's pretty random. It doesn't get much more random if we revert the behaviour for diagonal iteration, but the code will look nicer.
13:07:09  <frosch123> :p
13:16:02  <fonsinchen> I'm not adding a virtual base class for OrthogonalTileArea and DiagonalTileArea. Instead I'll typedef OrthogonalTileArea to TileArea
13:16:34  <fonsinchen> Polymorphic tile areas probably aren't very useful but we want that shorthand.
13:57:17  *** ChanServ changes topic to "OpenTTD Dev Channel || Latest SVN: r26288 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
14:06:24  <fonsinchen> - the last 3 commits
14:11:22  <frosch123> the second one changes the positions of the explosions
14:11:34  <frosch123> previously they were on 4 corners, now they are on 2 only
14:12:34  <frosch123> hmm, ah, i guess that makes no sense for diagonal?
14:13:31  <fonsinchen> Yes, in diagonal you can only have 2 half of the time anyway
14:13:48  <fonsinchen> So I figured, to make it consistent, only show two for orthogonal, too.
14:14:03  <fonsinchen> (I don't think anyone will notice that anyway)
14:14:17  <frosch123> oh, i doubt that :p
14:16:52  <frosch123> why is there a cast to (TileIterator*) in rail_cmd.cpp:1530 ?
14:17:23  <fonsinchen> Because the compiler will complain if it's not there.
14:17:44  <fonsinchen> It needs to know the return type of the expression
14:17:53  <fonsinchen> Silly, but we can't do much about that.
14:18:09  <frosch123> hmm, i expected it would be needed on both sides of the :
14:18:51  <fonsinchen> It's enough on one side because on the right side it can infer the type from the explicitly specified one on the left then.
14:20:35  <frosch123> looks fine to me, maybe ladncapeCmdClearArea
14:20:49  <frosch123> looks fine to me, maybe CmdClearArea could use area_start instead of p1 as well
14:22:36  <fonsinchen> CmdClearArea is much shorter. I think we can stick with the original variable names there.
14:53:27  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26289 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
14:53:52  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26290 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
14:54:13  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26291 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
17:53:06  *** frosch123 has quit IRC
17:56:09  *** frosch123 has joined
17:56:09  *** ChanServ sets mode: +v frosch123
18:20:28  *** adf88 has joined
18:20:28  *** ChanServ sets mode: +v adf88
18:45:34  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26292 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:14:35  *** Alberth has quit IRC
19:17:33  <fonsinchen> MJP seems convinced that fixes FS#5863 and FS#5867
19:17:39  <fonsinchen> It's a one-liner
19:18:12  <fonsinchen> I don't quite see why it fixes it and I have no way to test it either
19:20:28  <frosch123> GameSizeChanged already calls MarkWholeScreenDrity
19:20:44  <frosch123> so at least the "+" line has no effect
19:21:22  <fonsinchen> Can we be sure that the next time around the screen will be "ready" to be drawn to or does that just incidentally work because of timing?
19:22:07  <frosch123> at line 1307 UpdateWindows is called while _draw_mutex is hold
19:22:20  <frosch123> s/hole/owned/ whatever
19:22:37  <frosch123> same seems to be the case in ClientSizeChanged
19:28:27  <frosch123> the _wnd.buffer_bits thingie is assigned in AllocateDibSection
19:28:37  <frosch123> so maybe the mutex rather needs moving out of the if ?
19:29:30  <frosch123> so well, having just as few test-ability as you, the diff does not look very plausbile to me
19:30:27  <frosch123> <- my guess would be that, but no idea either :)
19:34:58  <frosch123> comparing it with sdl suggests that ChangeResolution may also need to lock the mutex
19:36:50  <fonsinchen> Actually have windows XP around here. Maybe I'll boot that up and play around a bit.
19:37:00  <fonsinchen> See you later
19:38:45  <frosch123> hmm, when ChangeResolution need to lock the mutex, maybe ToggleFullscreen needs as well
19:38:52  <frosch123> (for sdl)
20:54:40  *** frosch123 has quit IRC
22:49:46  *** Ristovski has quit IRC
22:50:55  *** adf88 has quit IRC
23:55:30  *** Supercheese has joined
23:55:30  *** ChanServ sets mode: +v Supercheese

Powered by YARRSTE version: svn-trunk