Log for on 9th February 2014:
Times are UTC Toggle Colours
00:08:01  *** Supercheese has joined
00:08:01  *** ChanServ sets mode: +v Supercheese
00:13:31  *** adf88 has quit IRC
00:13:43  *** adf88 has joined
00:13:43  *** ChanServ sets mode: +v adf88
00:14:01  *** Lizz has quit IRC
00:27:57  *** Belugas has quit IRC
00:28:32  *** Belugas has joined
00:28:32  *** ChanServ sets mode: +v Belugas
00:29:18  *** adf88 has quit IRC
00:29:46  *** adf88 has joined
00:29:47  *** ChanServ sets mode: +v adf88
00:36:53  *** adf88 has quit IRC
00:42:28  *** adf88 has joined
00:42:28  *** ChanServ sets mode: +v adf88
00:46:38  *** adf88 has quit IRC
08:44:58  *** Supercheese has quit IRC
09:35:17  *** adf88 has joined
09:35:17  *** ChanServ sets mode: +v adf88
09:54:16  *** Alberth has joined
09:54:16  *** ChanServ sets mode: +v Alberth
12:31:30  *** frosch123 has joined
12:31:30  *** ChanServ sets mode: +v frosch123
12:32:56  *** adf88 has quit IRC
12:38:46  *** adf88 has joined
12:38:46  *** ChanServ sets mode: +v adf88
12:41:16  *** adf88 has quit IRC
12:42:33  <fonsinchen> I actually was serious about ...
12:42:51  <fonsinchen> It has happened to me that I wanted to play a 4096x64 map
12:43:37  <planetmaker> I wonder whether we should not simply allow 4096^2 games then straight away without other limits
12:43:55  <frosch123> fonsinchen: about fs#5898, if you used the dmp-analyse tool from secure, it is "normal" that it fails for assertions
12:44:12  <fonsinchen> oh
12:44:16  <frosch123> it only gives the trace to the assertion, you need real msvc or something
12:44:30  <fonsinchen> To be honest I just blindly trusted TrueBrain there
12:44:37  *** adf88 has joined
12:44:37  *** ChanServ sets mode: +v adf88
12:44:49  * fonsinchen has to set up a 64bit windows at some point
12:45:27  <frosch123> i also think that a setting for the max map size is a bit too much :)
12:45:51  <frosch123> make 4k available, then we can say we allow the maximum that actually works
12:46:18  <Alberth> make it a max_tile_count?
12:46:19  <fonsinchen> People will of course shoot themselves in the foot more often if we just straight out allow it, but OK, I'll just do the 11 -> 12 change then
12:47:04  <planetmaker> "actually works" as in no bugs with planes etc?
12:47:07  *** adf88 has quit IRC
12:47:25  <fonsinchen> Alberth: And then make that configurable? There are people with very fast computers around, I hear ...
12:47:37  <frosch123> planetmaker: yes, the regular patches set it to 8k, which you should be able to break with planes... but well, i did not bother to actually test it :p
12:48:09  <planetmaker> fonsinchen, no, not a configurable max_tile_count. But larger dimensions wher a * b < max_tile_counts, but a or b larger than 4096. But... dunno whether that works with things like planes
12:48:31  <fonsinchen> We can do that in a second step
12:48:45  <fonsinchen> 4096 is pretty long already
12:48:48  <Alberth> I wouldn't go larger than 4096, 2K is already too much imho
12:48:52  <frosch123> bigger than 8000 will not work,
12:49:22  <frosch123> the number of tiles only fails at 64kx64k, the world coordinates fail at 8k and planes fly beyond map borders, so 8k is already too much
12:49:27  <planetmaker> I'm all fine with no other change than 11 -> 12
12:49:56  <planetmaker> let the rest be done by the giant map people first :D
12:49:58  <Alberth> but if you allow 4K*4K fully already, the max tile count seems unneeded
12:50:28  <planetmaker> I think none of us here wants to play 4k^2 full. But there are people who do want that dearly
12:51:02  * Alberth never uses 2k either
12:51:18  <frosch123> well, those people do not run into a cpu problem, because they make the map just more spacy
12:51:24  <planetmaker> Probably one of the last 2k^2 maps I created was for wwottdgd/2
12:51:31  <frosch123> they have very sparse industries and vehicles
12:51:39  <planetmaker> and that showed me quite nicely why it's not the best of ideas :)
12:52:21  <planetmaker> even 1k^2 doesn't work too well with 'coop style'. Too few vehicles indeed
12:52:26  <Alberth> if you look at random 2K^2 maps, it all empty, and one or two lines of connections, which can easily be done at 1K^2
12:52:30  *** adf88 has joined
12:52:30  *** ChanServ sets mode: +v adf88
12:52:38  <fonsinchen> With long and narrow maps you can have a "bus" type network which has its own challenges
12:52:44  <fonsinchen> I kinda like it.
12:53:00  <frosch123> yes, narrow likely works :)
12:53:04  <Alberth> what does 4K add what you don't have with 2K ?
12:53:29  <planetmaker> fonsinchen, the 4096x64 or 4096x128 maps are interesting for me, too :)
12:53:42  <planetmaker> Alberth, long trains with meaningful tracks
12:53:42  <fonsinchen> 2kx64 is actually the same as 512x256, space-wise. You can fill it pretty quickly
12:53:47  <planetmaker> not 5 tile but 15 tile
12:54:05  <fonsinchen> Also that
12:54:10  <planetmaker> and the income is insane on those maps :P
12:54:29  <planetmaker> oh, I guess I'll prepare a map for publicserver :D
12:54:39  <Alberth> you're the planetmaker, just make a more stretched world  :P
12:54:48  <planetmaker> :DD
12:54:56  <planetmaker> egg-world
12:55:17  <Alberth> add a few din
12:55:21  <frosch123> banana shaped world with pota-ghat?
12:55:28  <Alberth> dinosauriers at it :)
12:56:09  <planetmaker> I like that, frosch123 :)
12:56:37  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26319 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
12:56:48  <fonsinchen> There we go.
12:57:14  * fonsinchen goes and sets up windows 7 now
12:57:27  <Alberth> it's a feature! :)
13:04:51  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26320 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
13:05:12  *** adf88 has quit IRC
13:05:24  *** adf88 has joined
13:05:24  *** ChanServ sets mode: +v adf88
13:05:46  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26321 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
13:06:35  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26322 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
13:55:31  * Rubidium has recently generated quite a number of 2048x2048 games
13:58:56  <Rubidium> fonsinchen: what about landscape.cpp:729?
13:59:27  <fonsinchen> Oh
13:59:40  <Rubidium> settings like max_bridge_length and max_tunnel_length?
13:59:52  <Rubidium> nodelist.hpp:54
14:06:13  <frosch123> magic constants copied all over the place without assert_compile :p
14:06:36  * Rubidium wonders how many people use 8192x8192 as for me the first try hit an assertion in landscape.cpp:736
14:07:32  <Rubidium> @calc 8192*8192
14:07:32  <DorpsGek> Rubidium: 67108864
14:07:49  <frosch123> <- found one
14:07:59  <fonsinchen> I don't get nodelist.hpp:54
14:08:06  <fonsinchen> What's the point of that?
14:08:45  <Rubidium> IIRC it's the search depth of something
14:09:02  <frosch123> yeah, looks weird
14:09:23  <fonsinchen> Why can you only exhaust one map dimension during that search?
14:09:24  <Rubidium> not sure though
14:10:01  <Rubidium> I guess it was a reasonable assumption that you're only have a junction on every other tile (and a signal on the remaining ones)
14:13:13  <fonsinchen> r19161 reduced that seemingly arbitrary number by a factor of 100
14:14:07  <Rubidium> okay, then it's not related; I just grepped for 2048 and looked at stuff that might be related
14:23:33  <fonsinchen>
14:24:21  *** adf88 has quit IRC
14:25:03  *** adf88 has joined
14:25:03  *** ChanServ sets mode: +v adf88
14:25:04  <frosch123> is MAX_MAP_SIZE accessible from there? or does it cause an include mayhem?
14:26:07  <frosch123> landscape.cpp could get an assert_compile(lengthof(feedbacks) == 2 * MAX_MAP_SIZE_BITS - 12) or so
14:31:41  <fonsinchen> -11 as 64x64 is in
14:31:44  *** Oldskool has joined
14:33:14  <fonsinchen> assert_compile(lengthof(feedbacks) == 2 * MAX_MAP_SIZE_BITS - 2 * MIN_MAP_SIZE_BITS + 1);
14:33:32  <fonsinchen> (both min and max are inclusive)
14:36:01  <frosch123> fonsinchen: fs#5901 uses manual distribution
14:36:08  <fonsinchen> I know
14:36:21  <frosch123> so the cargo got their by misclicking in the orders
14:36:30  <fonsinchen> That's why the next station should be INVALID_STATION
14:36:40  <fonsinchen> but it is 46657
14:37:11  <fonsinchen> So when the train comes and loads "just anything", which is INVALID_STATION, it doesn't load it.
14:37:12  <frosch123> oh, i see
14:37:49  <frosch123> i wasn't aware that the destinations have influence even if not using cdist
14:38:04  <fonsinchen> Well, the data structures are the same
14:38:35  <fonsinchen> I have to come up with some key to the multimap items in the station cargo list.
14:38:39  <frosch123> i thought it has something to do with Vehicle::last_visited_station or something
14:39:10  <fonsinchen> No, somehow that key got corrupted.
14:40:19  <fonsinchen> with nice assert_compile and additional use of MIN_MAP_SIZE_BITS when using the feedbacks.
14:40:45  <frosch123> MAX_MAP_SIZE in settings.ini does not work?
14:41:07  <Rubidium> Error: Assertion failed at line 68 of /home/rubidium/openttd/clean/src/newgrf_debug_gui.cpp: (index >> 24) == 0
14:41:31  <Rubidium> I guess I shouldn't destroy an airport at the southern tip of a 8192 by 8192 map
14:42:08  <frosch123> the original mapsize patch changes the window_number of the debug gui to get more bits for the tileindex
14:42:44  <fonsinchen> frosch123: We probably shouldn't make that freely configurable or people will come with lots of things like Rubidium just experienced.
14:43:08  <fonsinchen> I already underestimated the problems that even a change to 4096 will bring.
14:43:15  <frosch123> yeah, me too :p
14:44:47  <Rubidium> did you even check all commands with tiles?
14:46:39  *** adf88 has quit IRC
14:46:51  *** adf88 has joined
14:46:51  *** ChanServ sets mode: +v adf88
14:47:09  <frosch123> grepping for "TileIndex.*p[12]" does not give any suspicious
14:47:15  <frosch123> looks like all tileindex are 32 bit
14:47:33  <Rubidium> and the map size we push to the NewGRFs?
14:47:41  <frosch123> that i checked :)
14:48:20  <frosch123> that is fine till 2**21
14:49:21  *** adf88 has quit IRC
14:49:33  <frosch123> that is 2**21 edge length, 2**261 tile count
14:49:36  *** adf88 has joined
14:49:36  *** ChanServ sets mode: +v adf88
14:50:33  <Rubidium> multi-dimensional maps?
14:51:25  <Rubidium> @calc 261/21
14:51:25  <DorpsGek> Rubidium: 12.4285714286
14:51:43  <Rubidium> 13+ dimensions
14:52:00  <frosch123> we can only return 2 dims
14:52:23  <frosch123> 3rd dim is another var
14:52:34  <frosch123> the mapsize var would have enough space for a 4th dim though
14:52:43  <Rubidium> so, then the maximum number of tiles, if 2**21 is the maximum along one edge, is 2*(2**21) = 2**(2*21) = 2**42 tiles
14:54:14  <Rubidium> just shy by a few orders of orders of magnitude (about factor 10**66)
14:54:25  <Rubidium> or am I missing something obvious?
14:54:57  <frosch123> well, i am not sure whether you want to tiles on 256 height levels separately
14:55:01  <Rubidium> besides map z-index, but that's only 2**8
14:55:05  <frosch123> if industries can spawn above each other
14:56:09  <fonsinchen> Ah, I see what you mean
14:56:58  <Rubidium> ah... there it is... the reason why 2**24 is bad; now a map height patch can't use tileindex | height << factor which does not conflict with a magic number (INVALID_TILE)
14:57:25  *** adf89 has joined
14:57:28  <Rubidium> on the other hand, 256 tile levels is probably too much anyhow
14:57:33  <frosch123> hmm, back to serious
14:57:36  <fonsinchen>
14:57:42  <frosch123> i don't see why the newgrf debug window asserts?
14:57:51  <frosch123> we still have only 24 bit tileindex, don't we?
14:58:00  <frosch123> 4096*4096 is 16M
14:58:50  <fonsinchen> Wasn't that assert at 8kx8k?
14:58:50  <Rubidium> frosch123: yes, that assert was from a simple patched 8192x8192 game (where you mentioned planes would go missing; I didn't observe that though
14:59:22  <frosch123> oh, i missed some important context there :)
14:59:37  <Rubidium> fonsinchen's patch looks okay though
14:59:41  *** adf88 has quit IRC
14:59:55  *** adf89 has quit IRC
15:00:07  *** adf88 has joined
15:00:07  *** ChanServ sets mode: +v adf88
15:00:31  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26323 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
15:23:38  *** adf88 has quit IRC
15:29:15  *** adf88 has joined
15:29:15  *** ChanServ sets mode: +v adf88
16:08:31  *** adf88 has quit IRC
16:08:57  *** adf88 has joined
16:08:57  *** ChanServ sets mode: +v adf88
16:11:27  *** adf88 has quit IRC
16:17:19  *** adf88 has joined
16:17:19  *** ChanServ sets mode: +v adf88
16:32:18  <fonsinchen> for FS#5901
16:58:00  <frosch123> does from == MTA_TRANSFER happen?
17:00:42  <fonsinchen> no
17:00:51  <fonsinchen> That's just for completeness
17:01:02  <fonsinchen> and someone could get that idea at some point
17:01:28  <fonsinchen> Then they should at least notice that they have to take care of next_station/loaded_at_xy
17:05:01  * fonsinchen is seriously annoyed by windows 7 taking forever to install...
17:05:55  <frosch123> there are some assumptions about the amounts in the cargo packets, so that they sum up to action_counts and action_counts +/- max_move, when counting from the front
17:06:07  <frosch123> but i guess that does not matter since it moves everything?
17:13:25  *** adf88 has quit IRC
17:13:37  *** adf88 has joined
17:13:37  *** ChanServ sets mode: +v adf88
17:15:48  <fonsinchen> Those assumptions are the same everywhere in cargopacket.* and cargoaction.*
17:15:58  *** adf88 has quit IRC
17:15:58  <fonsinchen> The amounts have to be at packet boundaries.
17:16:38  <fonsinchen> The code could do with a few asserts on that.
17:17:17  <fonsinchen> Ah, OK, I see what you mean
17:17:46  <fonsinchen> In the other methods the amount will be adjusted if you try to move a bad amount.
17:18:20  <fonsinchen> ... sometimes
17:21:07  <fonsinchen> Well, yes, those sanity checks could do with some more love but that's independent of the current problem.
17:32:37  <fonsinchen> PopCargo and ShiftCargo should probably return something.
17:35:22  <fonsinchen> Oh, wait, the CargoActions are able to split packets so once we've checked the maximum we know that the amounts are actually correct.
17:35:39  <fonsinchen> Regarding that, reassign should become a CargoAction, too.
18:03:06  <fonsinchen> Does not work, unfortunately, because we can neither use ShiftCargo nor PopCargo in the general case.
18:03:50  <fonsinchen> We'd need some SpliceCargo for that, but I'd rather restrict it to moving all cargo of a specific designation and by that keeping the packet boundaries intact.
18:09:34  <frosch123> can you add some asserts about that?
18:45:43  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26324 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:01:07  *** Supercheese has joined
19:01:07  *** ChanServ sets mode: +v Supercheese
19:17:22  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26325 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:41:27  <frosch123> anyone ever used helgrind?
19:42:09  * LordAro googles
19:42:48  <LordAro> i suspect clang's thread-sanitizer could do something similar
19:44:12  <frosch123> <- those 3 on startup (with multipe occurences)
19:44:35  <frosch123> LordAro: your thing sounds like static code analysis, which sounds worthless compared
19:44:48  <LordAro> ah, ok
19:45:13  <LordAro> i'm told it's very good though, not that i've ever been able to get it to work :3
19:46:05  <frosch123> well, it may be good nevertheless, but a static analyser is something very different to a live analyser
19:46:29  <frosch123> a static analyser is something you run every night, which produces a lot of numbers, which your boss can show to his boss
19:46:44  <LordAro> :)
19:46:46  <frosch123> a live analyser is a debugger which helps you at a specific problem
19:47:13  <LordAro> indeed
19:48:12  * Rubidium wonders what the file scanners have to do with drawing dirty blocks
19:48:50  <Rubidium> the first one is intentional as far as I can see it
19:49:50  <Rubidium> oh, _realtime_tick
19:50:59  <Rubidium> I doubt we use CPUs where reading a register/bit of memory of 4 bytes is not an atomic operation
19:51:45  <fonsinchen> You can't really rely on that, with all the caching going on.
19:54:09  <fonsinchen> I think I'll solve FS5901 with template specialization instead.
19:55:20  <Rubidium> fonsinchen: I'm not talking about all the caches having the same value
19:56:15  <fonsinchen> Sounded like it. E.g. it's a common mistake to assume a series of write operations will show up in another thread in the same order.
19:56:30  <Rubidium> I'm talking about, if a value changes, that change propagates through the caches in a way that *if* another core were to access it, it is either the new value or the old value. Not that it is part of the new value and part of the old value (for a 32 bit bit of memory on a 32 bit or more CPU)
19:56:56  <fonsinchen> Then, for any half CPU, you're right.
19:57:09  <fonsinchen> ^half sane
19:57:17  <fonsinchen> which apparently I'm not today
19:58:13  <Rubidium> or, in easier terms... if I have a value of 0xFF and want to add 1, that no-one will read that as 0x1FF... but only as 0xFF or 0x100
19:59:05  <frosch123> [20:56] <fonsinchen> Sounded like it. E.g. it's a common mistake to assume a series of write operations will show up in another thread in the same order. <- hmm, i wonder about that.. does a mutex unlock somehow flush all caches?
20:00:31  <fonsinchen> No, but the C++ memory model gives us certain guarantees then
20:01:07  <fonsinchen> I don't know the details off the top of my head and I don't have my Stroustrup around right now ...
20:01:37  <frosch123> <-pff, upon switching from 8bpp to 32bpp blitter
20:02:11  <frosch123> so much data
20:02:34  <fonsinchen> party
20:04:29  <fonsinchen> The interesting things are the data races I guess
20:04:32  <Rubidium> I wanted to say that it wasn't that much, until I realised it hadn't loaded the whole thing yet
20:05:35  <fonsinchen> VideoDriver_SDL::CreateMainSurface vs. DrawSurfaceToScreenThread seems an obvious problem
20:12:33  <frosch123> <- switching back from 32bpp to 8bpp, likely the same
20:20:16  <frosch123> <- some more from game start, which were missing in 3075
20:20:48  <frosch123> looks like 3075 and 3080 are harmless
20:21:32  <frosch123> they are about realtime_tick and _cur_palette.dirty, and some thread termination checks
20:26:50  <frosch123> <- let's see whether that changes stuff
20:28:14  <frosch123> funny, all that output is from the same SwitchNewGRFBlitter context
20:37:36  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26326 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
20:53:30  <fonsinchen> much nicer for FS#5901
20:56:12  <Rubidium> first added line ends with previously and the second added line starts with it
20:57:19  *** adf88 has joined
20:57:19  *** ChanServ sets mode: +v adf88
20:58:16  <fonsinchen> Yeah, that was reserved twice :/
21:01:05  <fonsinchen> then
21:01:22  <fonsinchen> and that I found on the way
21:04:31  <Rubidium> what if I have 3 units of cargo; action_counts[MTA_TRANSFER] = 1 and max_move = 1; won't the third loop create an empty cargopacket?
21:05:01  <Rubidium> the units of cargo are in separate cargopackets
21:05:37  <fonsinchen> what is your MTA_DELIVER?
21:05:47  <fonsinchen> it gets clamped in the beginning
21:06:51  <Rubidium> 2?
21:07:29  <Rubidium> oh, never mind... missed the condition in the for
21:08:51  <Rubidium> seems okay to me
21:10:25  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26327 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
21:16:04  *** Alberth has left
21:25:18  <frosch123> <- msvc barfs on something
21:25:29  <frosch123>  	..\src\cargopacket.cpp(872): error C3416: 'VehicleCargoList::Reassign' : an explicit specialization may not be explicitly
21:27:18  <frosch123> instantiated
21:40:25  <frosch123> <- result with 3081
21:42:52  <frosch123> no idea what those mean
21:43:12  <frosch123> they give only one trace, not two
21:45:02  <frosch123> but 3081 is apparently wrong wrt. fullscreen
21:45:45  <frosch123> unlike the change resolution case the mutex is already locked in that case due to weirdly different behaviour for button click vs. dropdown clicks
21:47:30  <frosch123> i guess that asymmetry sucks :p
21:53:03  <frosch123> pff, if i maximize the window and then select a smaller resolution in game options, it does not resize the window
21:53:07  <frosch123> does that also happen for you?
22:01:47  <planetmaker> you're speaking for windows? or any os?
22:07:17  <frosch123> no sdl
22:07:24  <frosch123> no, sdl :)
22:09:07  <frosch123> <- new version of the sdl patch
22:10:05  <frosch123> oh.., nvm, just realized that that diff is complete nonesense :p
22:11:08  <frosch123> well, night then :)
22:11:12  *** frosch123 has quit IRC
22:16:19  *** adf88 has quit IRC
22:16:33  *** adf88 has joined
22:16:33  *** ChanServ sets mode: +v adf88
22:27:42  *** adf88 has quit IRC
22:28:10  *** adf88 has joined
22:28:10  *** ChanServ sets mode: +v adf88
22:35:13  *** adf88 has quit IRC
22:35:56  *** adf88 has joined
22:35:56  *** ChanServ sets mode: +v adf88
23:40:07  *** adf88 has quit IRC
23:40:22  *** adf88 has joined
23:40:23  *** ChanServ sets mode: +v adf88
23:47:30  *** adf88 has quit IRC
23:47:42  *** adf88 has joined
23:47:42  *** ChanServ sets mode: +v adf88

Powered by YARRSTE version: svn-trunk