Times are UTC Toggle Colours
00:08:01 *** Supercheese has joined #openttd.dev 00:08:01 *** ChanServ sets mode: +v Supercheese 00:13:31 *** adf88 has quit IRC 00:13:43 *** adf88 has joined #openttd.dev 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 #openttd.dev 00:28:32 *** ChanServ sets mode: +v Belugas 00:29:18 *** adf88 has quit IRC 00:29:46 *** adf88 has joined #openttd.dev 00:29:47 *** ChanServ sets mode: +v adf88 00:36:53 *** adf88 has quit IRC 00:42:28 *** adf88 has joined #openttd.dev 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 #openttd.dev 09:35:17 *** ChanServ sets mode: +v adf88 09:54:16 *** Alberth has joined #openttd.dev 09:54:16 *** ChanServ sets mode: +v Alberth 12:31:30 *** frosch123 has joined #openttd.dev 12:31:30 *** ChanServ sets mode: +v frosch123 12:32:56 *** adf88 has quit IRC 12:38:46 *** adf88 has joined #openttd.dev 12:38:46 *** ChanServ sets mode: +v adf88 12:41:16 *** adf88 has quit IRC 12:42:33 <fonsinchen> I actually was serious about https://github.com/ulfhermann/openttd/commit/1f56bf82217d7c8191f4ad3b36a199b50f73ece4 ... 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 #openttd.dev 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 #openttd.dev 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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 #openttd.dev 13:05:24 *** ChanServ sets mode: +v adf88 13:05:46 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26321 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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> http://www.tt-forums.net/viewtopic.php?p=1050751#p1050751 <- 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> https://github.com/ulfhermann/openttd/commit/19ca834117e7f326f0ec0c88d2068c0a4f4bf6dc 14:24:21 *** adf88 has quit IRC 14:25:03 *** adf88 has joined #openttd.dev 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 #openttd.dev 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> https://github.com/ulfhermann/openttd/commit/32faa420c7d021b8dab0e53f734d3bca5c13da7c 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 #openttd.dev 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 #openttd.dev 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 #openttd.dev 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> https://github.com/ulfhermann/openttd/commit/d4b8bdcf424fe304ca055c7afd66d724b7bc3255 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 #openttd.dev 15:00:07 *** ChanServ sets mode: +v adf88 15:00:31 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26323 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || 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 #openttd.dev 15:29:15 *** ChanServ sets mode: +v adf88 16:08:31 *** adf88 has quit IRC 16:08:57 *** adf88 has joined #openttd.dev 16:08:57 *** ChanServ sets mode: +v adf88 16:11:27 *** adf88 has quit IRC 16:17:19 *** adf88 has joined #openttd.dev 16:17:19 *** ChanServ sets mode: +v adf88 16:32:18 <fonsinchen> https://github.com/ulfhermann/openttd/commit/40b612063b389989aa94cf2c30012825b0ae8faf 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 #openttd.dev 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: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 19:01:07 *** Supercheese has joined #openttd.dev 19:01:07 *** ChanServ sets mode: +v Supercheese 19:17:22 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26325 || 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: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> http://paste.openttdcoop.org/show/3075/ <- 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> http://paste.openttdcoop.org/raw/3078/ <-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> http://paste.openttdcoop.org/raw/3079/ <- switching back from 32bpp to 8bpp, likely the same 20:20:16 <frosch123> http://paste.openttdcoop.org/show/3080/ <- 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> http://paste.openttdcoop.org/show/3081/ <- 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: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:53:30 <fonsinchen> https://github.com/ulfhermann/openttd/commit/d38e13999682c18a128a0bf01949528b3408f32d 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 #openttd.dev 20:57:19 *** ChanServ sets mode: +v adf88 20:58:16 <fonsinchen> Yeah, that was reserved twice :/ 21:01:05 <fonsinchen> https://github.com/ulfhermann/openttd/commit/dfb060881a5372dedb96a4f614576c8241da13b1 then 21:01:22 <fonsinchen> and https://github.com/ulfhermann/openttd/commit/af3335923dbb3378a2ba0681313c9d1074abad09 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: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 21:16:04 *** Alberth has left #openttd.dev 21:25:18 <frosch123> http://farm.openttd.org/browse/OTTD-TEST-W64BIT-3121/log <- 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> http://paste.openttdcoop.org/show/3082/ <- 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> http://paste.openttdcoop.org/show/3084/ <- 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 #openttd.dev 22:16:33 *** ChanServ sets mode: +v adf88 22:27:42 *** adf88 has quit IRC 22:28:10 *** adf88 has joined #openttd.dev 22:28:10 *** ChanServ sets mode: +v adf88 22:35:13 *** adf88 has quit IRC 22:35:56 *** adf88 has joined #openttd.dev 22:35:56 *** ChanServ sets mode: +v adf88 23:40:07 *** adf88 has quit IRC 23:40:22 *** adf88 has joined #openttd.dev 23:40:23 *** ChanServ sets mode: +v adf88 23:47:30 *** adf88 has quit IRC 23:47:42 *** adf88 has joined #openttd.dev 23:47:42 *** ChanServ sets mode: +v adf88