IRC Logs | #openttd.dev

12:03:34 <fonsinchen> The diagonal tile iterator is actually running "backwards". I wonder if we should change that.

12:07:11 <frosch123> even for the orthogonal one i would not know whether it runs X or Y first

12:18:52 <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:44 <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: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: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"

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: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: http://webster.openttdcoop.org/?channel=openttd.dev || 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"

18:45:34 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26292 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"

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: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:26 <frosch123> http://paste.openttdcoop.org/show/3063/ <- 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:38:45 <frosch123> hmm, when ChangeResolution need to lock the mutex, maybe ToggleFullscreen needs as well