IRC logs for #openttd on OFTC at 2009-11-08
⏴ go to previous day
00:32:25 *** pete is now known as Guest1159
00:32:49 *** Guest1159 is now known as pete
00:35:01 *** Eddi|zuHause has joined #openttd
01:11:00 *** welshdragon has joined #openttd
01:32:49 *** KenjiE20|LT has joined #openttd
02:40:11 *** HerzogDeXtEr has joined #openttd
04:10:29 *** Rubix`` has joined #openttd
05:02:50 *** HerzogDeXtEr has joined #openttd
05:19:07 *** ltsampro1 has joined #openttd
07:22:34 <Rhamphoryncus> I'm playing with ECS construction and agriculture vectors. I'm trying to build a cement train, but I can't find a cement car. Anybody know what I'm missing?
07:22:56 <Eddi|zuHause> a proper vehicle set?
07:23:18 <Rhamphoryncus> I have all the trucks..
07:24:52 <Rhamphoryncus> No ECS vehicle set that I can see
07:25:28 <Rhamphoryncus> and the only other NewGRFs I'm running are for trams and (in one case) trucks
07:28:00 <Eddi|zuHause> i always find it funny that people can talk so much without giving _any_ information
07:28:32 <Rhamphoryncus> hrm. I think you're right though. Trucks work because I can refit them. Trains need entirely new cars.. and I guess they didn't include the required train cars in ECS. Need to grab a third-party set
07:30:49 <Eddi|zuHause> try the set "old wagons, new cargos", it adds the refit options to the default wagons
07:32:28 <Rhamphoryncus> I also found a forum post suggesting 2CC or Nars
07:32:47 <Rhamphoryncus> My searches for cement were getting nothing because the problem isn't specific to cement
07:33:48 <Rhamphoryncus> aha, cement, thankies :D
07:57:55 *** Alberth has joined #openttd
08:44:30 <Lachie> g'day, anyone here good with grfcodec?
09:02:43 *** Progman has joined #openttd
09:03:09 <Rubidium> Lachie: yes, but others might know the answer on your real, but well hidden, question too
09:09:12 <Lachie> well, I'm a little embarrassed to be asking this, since I've been coding for a few years now. But I've only now switched over from GRFMaker to plain old NFO. I've set everything up and it all works quite well. The problem is the decoded .grf has spat out .pcx files which vastly different colours then the original source files. This isn't a problem for editing of the NFO, as when reencodedthe colours are normal. But it will be difficult to do any editing on the
09:09:32 <Lachie> I've searched/googled, and not much came up regarding the issue
09:09:51 <Rubidium> use -p <some number> to use the right palette
09:10:02 <Rubidium> for both encoding and decoding
09:21:31 *** |Jeroen| has joined #openttd
09:30:54 *** Grelouk has joined #openttd
09:36:05 *** Grelouk_ has joined #openttd
09:43:02 *** thepalm has joined #openttd
10:40:01 *** Luukland has joined #openttd
10:43:59 *** oskari89 has joined #openttd
10:50:12 *** smallfly has joined #openttd
11:06:49 *** Polygon has joined #openttd
11:17:02 *** frosch123 has joined #openttd
11:44:46 *** Terkhen has joined #openttd
12:05:50 *** andythenorth has joined #openttd
12:07:09 *** welshdragon has joined #openttd
12:08:11 *** KenjiE20 has joined #openttd
12:11:53 <CIA-4> OpenTTD: rubidium * r18006 /trunk/src/genworld_gui.cpp: -Codechange: make the world generation progress window nested
12:19:11 <CIA-4> OpenTTD: frosch * r18007 /trunk/src/train_cmd.cpp: -Codechange: No need to call CB 36 'running cost factor' if the vehicle has no running cost class anyway.
12:23:15 <CIA-4> OpenTTD: frosch * r18008 /trunk/src/ (6 files in 3 dirs): -Codechange: Rename NUM_PRICES to PR_END, and use the Price enum some more.
12:38:12 <CIA-4> OpenTTD: rubidium * r18009 /trunk/src/ (genworld_gui.cpp lang/english.txt): -Codechange: make the 'create scenario' window nested
12:45:28 <CIA-4> OpenTTD: alberth * r18010 /trunk/src/station_gui.cpp: -Codechange: Split StationViewWindow::OnPaint in four functions.
12:48:02 *** welshdragon has joined #openttd
12:48:11 <andythenorth> quiet round here....
12:48:37 <andythenorth> No pixels for me today. I've watched 8 episodes of West Wing, more to come :P
12:50:10 <Forked> I'm someone what hooked on borderlands
12:57:14 *** Chillosophy has joined #openttd
13:01:54 <planetmaker> it comes and goes in waves. Though trunk changed more than on some other, less quiet days...
13:02:04 <planetmaker> Maybe there's a relation? ;-)
13:02:17 <CIA-4> OpenTTD: frosch * r18011 /trunk/src/ (6 files): -Feature(ette): [NewGRF] CB 36 for roadvehicle property 09 'running cost factor'.
13:02:17 <planetmaker> s/relation/connection/
13:26:13 *** Dred_furst has joined #openttd
13:36:00 <CIA-4> OpenTTD: rubidium * r18012 /trunk/src/ (55 files in 3 dirs): -Codechange: make the world generation windows nested; they'll need some tweaks to use the full potential though
13:39:15 *** fonsinchen has joined #openttd
13:48:30 *** andythenorth has joined #openttd
13:59:11 *** andythenorth has joined #openttd
14:00:16 *** lewymati has joined #openttd
14:10:33 *** andythenorth has joined #openttd
14:15:48 *** Polygon has joined #openttd
14:18:42 *** Rexxars has joined #openttd
14:18:44 *** thingwath has joined #openttd
14:20:29 *** thingwath has joined #openttd
14:21:11 *** andythenorth has joined #openttd
14:32:02 *** Chris_Booth is now known as Guest1195
14:32:04 *** Chris_Booth has joined #openttd
14:42:01 *** nicfer1 has joined #openttd
14:49:09 <Paul2> openttd download speeds in vista as terribley slow (as in 100k in a couple of MINUTES), known issue? internet and server both fine speed wise. Must be openttd client
14:50:18 <Rubidium> never had trouble with slow download speeds, except when the upload of the server was slow
14:55:35 <Paul2> server is fine. It's my server in a datacentre, and everyone else can connect/download fine
14:55:51 <Paul2> I think it might be this ISP (virgin media) doing some traffic shaping or something...
14:56:19 <Paul2> anyone else on virgin media ADSL in the UK?
14:56:23 *** Rubix`` has joined #openttd
14:56:50 *** andythenorth has joined #openttd
15:02:40 <Paul2> the connection /eventually/ downloads, then Client #16 is dropped because it took longer than 500 ticks for him to join
15:03:06 <Paul2> and then you reconnect and it has to download it all again and it's about 10k bigger everytime to download
15:03:33 <planetmaker> sounds like a slow connection for you, Paul2
15:03:46 <planetmaker> or the server. or somewhere in between
15:04:18 <Paul2> must be the ISP here I think. :(
15:04:40 <planetmaker> If I started a server at my home, you'd have probably the same difficulties connecting to it. I've quite slow upload
15:05:00 <planetmaker> do you know the connection speed of the server? Did you try other servers?
15:05:05 <Paul2> so in theory I should be able forward it through SSH to the server, but it doesnt seem to want to play nice.
15:05:12 *** lewymati has joined #openttd
15:05:25 <planetmaker> ah... sorry, your server
15:05:52 <planetmaker> and what version?
15:05:53 <Paul2> yes. it's a vps, sharing gigE or something. server is fine.
15:05:57 <Rubidium> for OpenTTD both the server and client need to be in sync, then only the commands the clients execute are sent over, which means that if more trains etc. get added to the game, the savegame gets bigger
15:06:40 <planetmaker> and each tree adds a byte or so to savegame size ;-)
15:07:31 <Paul2> could it be something to do with me using opengfx and other clients using the old standard ones?
15:07:43 <Paul2> although server only has opengfx as well
15:07:54 <frosch123> planetmaker: disable compression, and trees will not affect filesize anymore
15:08:32 <planetmaker> frosch123, hehe :-)
15:09:04 <planetmaker> but I guess that's not good for the traffic consumption of MP servers open to the internet ;-)
15:09:40 *** fonsinchen has joined #openttd
15:10:15 <Rubidium> planetmaker: it's very good for the consumption of traffic
15:11:06 <planetmaker> Paul2, what version?
15:11:39 <planetmaker> and I also need the IP, as your server's name is the one from the config...
15:12:11 <Paul2> server 0.7.3, client 0.7.3
15:12:44 <Paul2> server ip: 212.13.195.53
15:13:29 <Paul2> it's name is helpfully 'unnamed server' at the moment, but it's a 2048x2048 temperate one, current date 1960ish
15:14:52 <Alberth> yeah, I always get lost at such maps
15:15:11 <planetmaker> ok, map downloaded in 1 second ;-)
15:15:11 <Paul2> i know...just a saved game my friend had
15:15:19 <planetmaker> it's not your server then :-P
15:15:22 <Paul2> (ignore train junctions, most are rubbish)
15:15:36 <Paul2> he just gave me saved game file to host
15:15:55 <planetmaker> I mean: it's not your server which has a slow connection ;-)
15:16:24 <Paul2> Yes :) must be this ISP here.
15:16:34 <Paul2> Damn the girlfriend not caring about having a good ISP :p
15:17:30 *** andythenorth has joined #openttd
15:17:30 <planetmaker> that's the Netherland's map, rightß
15:17:36 <Alberth> set the server to use port 80 :p
15:18:30 <Paul2> haha suppose I could...didnt even think of that. :(
15:21:48 <Paul2> you know the 'online content' menu in openttd. what port does that download over?#
15:21:57 <Paul2> because that is very slow as well...
15:22:02 <DorpsGek> frosch123: OpenTTD uses TCP and UDP port 3979 for server <-> client communication and UDP port 3978 for masterserver (advertise) communication (outbound)
15:22:07 <Paul2> (and I assume that would be http :80)
15:22:15 <frosch123> hmm, but which is bananas?
15:22:16 <CIA-4> OpenTTD: alberth * r18013 /trunk/src/ (window.cpp window_gui.h): -Codechange: Add possibility to change window size during ReInit().
15:22:53 <planetmaker> Sacro, ping timeout
15:22:58 <Paul2> frosch123: yeah that's what I meant. Bananas is the content thing isnt it?
15:23:30 <TrueBrain> hmm .. @ports info is outdated
15:23:47 <frosch123> bananas uses also 3978, but tcp
15:23:48 <TrueBrain> TCP 3978 is used for concent service
15:25:20 <Paul2> so taht would make sense with that being slow to download too
15:25:28 <Paul2> Any of you guys from the UK?
15:25:35 <TrueBrain> traffic shaping never makes sense
15:25:48 <TrueBrain> most of us abandoned UK years ago
15:26:31 <CIA-4> OpenTTD: alberth * r18014 /trunk/src/station_gui.cpp: -Codechange: Station view window uses pure nested widgets.
15:28:11 *** andythenorth has joined #openttd
15:32:18 <Sacro> planetmaker: hm, thanks
15:36:33 *** welshdragon has joined #openttd
15:45:02 *** andythenorth has joined #openttd
15:55:17 *** andythenorth has joined #openttd
16:15:27 *** Biolunar has joined #openttd
16:25:03 *** Coco-Banana-Man has joined #openttd
16:46:38 <CIA-4> OpenTTD: rubidium * r18015 /trunk/src/ (45 files in 2 dirs): -Codechange: redesign the world generation windows to make 'proper' use of nested widgets.
16:48:40 *** stuffcorpse has joined #openttd
16:52:56 *** HerzogDeXtEr has joined #openttd
16:59:19 *** Rubix`` has joined #openttd
17:05:31 *** welshdragon has joined #openttd
17:17:11 *** oskari89 has joined #openttd
17:28:44 *** Rhamphoryncus has joined #openttd
17:36:38 *** Progman has joined #openttd
17:42:27 *** HackaLittleBit has joined #openttd
17:46:34 *** HackaLittleBit has quit IRC
17:48:04 <_ln> hmm, 20 metres of water in an underground station is bad, no?
17:49:01 <fjb> Depends on the direction.
17:58:04 *** Chruker has joined #openttd
18:05:07 <CIA-4> OpenTTD: frosch * r18016 /trunk/src/ (economy.cpp economy_func.h economy_type.h newgrf.cpp): -Codechange: Move the arbitrary basecost multiplier offset (8) to newgrf loading and make the internal state zero-based instead.
18:12:08 *** HackaLittleBit has joined #openttd
18:22:32 *** HackaLittleBit has quit IRC
18:22:41 *** |Terkhen| has joined #openttd
18:23:46 <_ln> hello absolute value of Terkhen
18:26:08 *** Rubix`` has joined #openttd
18:38:46 *** |Terkhen| is now known as Terkhen
18:43:59 *** Grelouk has joined #openttd
18:45:39 <CIA-4> OpenTTD: translators * r18017 /trunk/src/lang/ (7 files): (log message trimmed)
18:45:39 <CIA-4> OpenTTD: -Update from WebTranslator v3.0:
18:45:39 <CIA-4> OpenTTD: arabic_egypt - 15 changes by kasakg
18:45:39 <CIA-4> OpenTTD: german - 1 changes by planetmaker
18:45:39 <CIA-4> OpenTTD: greek - 1 changes by fumantsu
18:45:40 <CIA-4> OpenTTD: hungarian - 1 changes by Petert
18:45:40 <CIA-4> OpenTTD: indonesian - 1 changes by prof
19:03:08 *** thisismyname has joined #openttd
19:21:45 <CIA-4> OpenTTD: rubidium * r18018 /trunk/src/company_gui.cpp: -Codechange: make the 'buy company' window nested
19:23:00 <CIA-4> OpenTTD: rubidium * r18019 /trunk/src/engine_gui.cpp: -Codechange: make the 'engine preview' window nested
19:23:23 *** Grelouk_ has joined #openttd
19:25:19 *** Coco-Banana-Man has quit IRC
19:25:59 *** Rubix`` has joined #openttd
19:32:10 <CIA-4> OpenTTD: alberth * r18020 /trunk/src/station_gui.cpp: -Codechange: Make the company station list window nested.
19:36:29 <CIA-4> OpenTTD: alberth * r18021 /trunk/src/station_gui.cpp: -Codechange: Have a widget for every cargo-type to eliminate searching.
19:36:52 *** Coco-Banana-Man has joined #openttd
19:46:31 *** HerzogDeXtEr1 has joined #openttd
19:49:25 <CIA-4> OpenTTD: rubidium * r18022 /trunk/src/ (widget.cpp window_gui.h): -Cleanup: remove some (now) unused button resize functions
19:53:40 *** Luukland has joined #openttd
19:53:47 * Luukland makes all phones ring
19:53:56 <Luukland> Its me :D Rampam rampam pam
19:54:13 *** ChanServ sets mode: +v tokai
19:55:39 * Luukland tHrows a finger at Fugas
19:57:08 <Luukland> Wondering about what?
19:58:02 <Luukland> We need to make a trap Fugas
19:58:20 <Fugas> yep, and catch one troll to it
19:58:32 <Alberth> Fugas: Luukland is a bit noisy today, throwing stones, letting phones go off, throwing fingers
19:58:55 <Luukland> Its because someone has feed the trolls!!
19:59:14 * Alberth suspects Luukland is the only troll here
19:59:51 <Rubidium> @kickban Luukland 3600 feeding time!
19:59:52 <frosch123> what do you expect from a twelve year old
20:00:11 <Rubidium> @kban Luukland 3600 feeding time!
20:00:11 *** DorpsGek sets mode: +b *!~luukland@ip195-211-208-87.adsl2.static.versatel.nl
20:00:12 *** Luukland was kicked by DorpsGek (feeding time!)
20:00:56 <Rubidium> I don't like it when my phone rings when it isn't even powered up!
20:02:07 <Fugas> bad, trolls reproduce here
20:08:45 *** Rubix`` has joined #openttd
20:10:10 *** HerzogDeXtEr has joined #openttd
20:12:54 *** HackaLittleBit has joined #openttd
20:29:37 *** StarLionIsaac has joined #openttd
20:32:35 *** Grelouk has joined #openttd
20:37:00 <Hirundo> When drawing a WWT_TEXT widget, the colour passed as widget parameter is cast to a TextColour, and then used to draw the string
20:37:31 <Hirundo> Why does it work like this, given that the values of TextColour don't match the values of Colours
20:40:37 <Alberth> yeah, looking into it.
20:40:53 <Alberth> the old widgets seem to do it
20:41:47 <Alberth> that probably also the answer.
20:42:01 <Alberth> I didn't invent anything new, just copied old widget behavior.
20:43:19 <Alberth> you can have a look when it was introduced this way, but I would not be surprised if that if very old.
20:43:41 <Alberth> I also have no idea what will break if you change it.
20:47:51 <Hirundo> Given the broken behaviour of today I doubt much stuff will break, if any
20:50:38 <Alberth> It got added for a reason I guess. You'll have to check each one.
20:52:28 <CIA-4> OpenTTD: alberth * r18023 /trunk/src/timetable_gui.cpp: -Codechange: Make the timetable window nested.
20:52:42 <Hirundo> At the time it was added, widget->color was a byte and not an enum, so no cast was needed
20:56:05 <Hirundo> The comment for Widget::colour refers to docs/ottd-colourtext-palette.png, which displays the text colours :S
20:56:08 <Alberth> there are 81 occurrences of WWT_TEXT. 5 are in widget.cpp, the others are usages, it seems
20:56:40 <Hirundo> But the variable is of type Colours, and Colours != TextColour :S
20:57:40 <Alberth> Frankly, I am too tired to think about colours atm, sorry. I am less than 5 minutes away from bed
20:58:39 <Alberth> (also, I have no idea why we have two colour enums, but there is a reason I am sure)
20:59:21 <Alberth> So I am willing to change something around WWT_TEXT, but not now.
20:59:51 <Hirundo> OK, thanks for your time
21:00:11 *** DorpsGek sets mode: -b *!~luukland@ip195-211-208-87.adsl2.static.versatel.nl
21:00:31 *** Luukland has joined #openttd
21:00:36 <Luukland> Feeding time over :D
21:05:24 *** HerzogDeXtEr1 has joined #openttd
21:08:37 <HackaLittleBit> Rubidium: If you have time, could you please have a glance at fs3304, it fresh from the press :)
21:15:16 <planetmaker> HackaLittleBit, the coding style is not entirely heeded: use tabs only to indent lines. Not to align comments
21:15:32 <planetmaker> and in the first comment it's Byte instead of "Bite"
21:16:19 <HackaLittleBit> thanks Ill change it
21:20:11 <planetmaker> also never use // for comments
21:20:17 <planetmaker> always use /* blah */
21:21:07 <planetmaker> I notice that the original code is not always following style there, too ;-)
21:21:33 <planetmaker> maybe convert that to doxygen entries: ///< draw_tile_proc
21:24:17 <planetmaker> concerning functionality I'm too tired right now. Also I'm not RB ;-)
21:29:22 <HackaLittleBit> thanks anyway, I will post rectified patch asap
21:33:48 <planetmaker> I like the prospect of custom bridge heads :-)
21:34:45 <HackaLittleBit> me too and I know there are more people
21:51:56 <HackaLittleBit> planetmaker: Done :)
21:52:43 *** HackaLittleBit has quit IRC
21:56:29 <Paul2> has anyone ever got to 1000 in detailed performance rating?
21:56:41 <Paul2> I guess it can't be /that/ hard...
21:57:51 <Rubidium> I'd like to change that question to: who hasn't ever got that rating?
21:59:14 <Paul2> I'd never really bothered trying or keeping an eye on it.
21:59:29 <Paul2> We are on 850ish now and friend wants to get to 1000...sounds reasonable
22:00:08 <Rubidium> do you have enough stations/vehicles for that? The rest is fairly easy to get to the magic value
22:00:17 <Eddi|zuHause> well, it can be really difficult if you have long-running trains or small road vehicles
22:00:21 <planetmaker> I usually don't get 1000 points. But I don't care about non-profitable feeder vehicles
22:01:14 <Paul2> yeah some feeder vehicles in the £1-2k ish region I think...
22:01:22 <Paul2> and not enough stations, apart from that fine
22:01:25 <planetmaker> you'll need to sell them ;-)
22:01:48 <Rubidium> or mass autoreplace them so they're < 2 years old :)
22:02:04 <planetmaker> then they don't count?
22:02:28 <Rubidium> hmm... that might've changed a while ago?
22:02:38 <planetmaker> dunno. You tell me :-)
22:02:55 <planetmaker> I thought it changed that unserviced stations don't count anymore
22:04:03 <Paul2> ahhh i was going to try that trick. damn :p
22:04:06 <Rubidium> yes, and unprofitable vehicles aren't counted either
22:19:00 <aggro> Can someone look at the latest svn version of file src/3rdparty/minilzo/minilzo.c line 1137
22:19:26 <aggro> Does it start with "#elif definedLZO_CC_WATCOMC)" or did my machine mix something up?
22:21:52 <aggro> The author's versions of that line seems to start with "#elif (LZO_CC_WATCOMC"
22:22:34 <Rubidium> the author's version throws a gazillion warnings with the compiler warnings we've enabled
22:23:01 <aggro> Ok, but is your version more correct with missing )?
22:23:40 <Eddi|zuHause> aggro: well, obviously add the "(", and test if it compiles
22:24:46 <CIA-4> OpenTTD: rubidium * r18024 /trunk/src/3rdparty/minilzo/minilzo.c: -Fix (r17217): missing (
22:27:18 <Eddi|zuHause> planetmaker: i heard that allegro has trouble resizing
22:28:38 <Rubidium> planetmaker: well, please come with a fix cause it doesn't happen for me :(
22:28:46 <planetmaker> hm... ok, I should find out which driver I use...
22:29:06 <Eddi|zuHause> and i still don't like opengfx...
22:29:17 <Eddi|zuHause> is it intended that the tracks have gaps in them?
22:29:20 <planetmaker> Rubidium, it's nothing which happens every time, not even most of the time
22:29:20 <aggro> line 1434: #elif defined(LZO_CC_INTELC) && (__INTEL_COMPILER >= 800) && LZO_CC_SYNTAX_GNUC)
22:29:42 <planetmaker> it's hard to re-produce, but with a bit of patience I manage here.
22:30:25 <Eddi|zuHause> aggro: how about you find all these places, and gather them in one patch?
22:33:05 <aggro> 1460: #elif defined(LZO_CC_MWERKS) && (__MWERKS__ >= 0x3200) && (defined(LZO_OS_WIN32) || (defined(LZO_OS_WIN64))
22:33:26 <planetmaker> how do I find out which video driver OpenTTD uses for me? I'm pretty sure it uses SDL, but...
22:34:30 <glx> -ddriver with the right debug level
22:34:46 <aggro> Did the 3rd party authors reject your patch about fixes for compiler warnings? They seem to have these things correct.
22:35:26 <Rubidium> aggro: I asked him about fixing the warnings, or at least look at them, but I never heard anything from him
22:38:07 <Rubidium> anyhow, that code is full of support for magic compilers that probably don't even exist anymore
22:38:27 <Rubidium> it seems to work perfectly fine for all compilers OpenTTD supports
22:42:29 <aggro> line 1556: # elif defined(LZO_CC_MSC) && (_MSC_VER < 900))
22:43:17 <planetmaker> it happens only when I very quickly resize the window...
22:43:38 *** Progman has joined #openttd
22:46:36 <aggro> line 1635: # elif defined(LZO_OS_OS2) && defined(LZO_CC_ZORTECHC))
22:46:52 <aggro> I wonder did I catch them all.
22:47:14 <planetmaker> and I'm using SDL
22:47:38 <planetmaker> aggro, IRC is no good place to make a collection of <whatever>
22:51:32 <Rubidium> anyhow, IIRC it was LLVM that complained about those things
22:51:48 <planetmaker> Rubidium, I'm testing on linux right now. Nothing OSX-ish ;-)
22:52:22 <planetmaker> oh... nvm. You didn't talk to me :-P
22:53:00 <Rubidium> so maybe it's better to just revert to the 'clean' minilzo and leave those llvm users with the warnings
22:53:22 <Rubidium> although, that might suck with the OSX compiles
22:53:43 <Eddi|zuHause> but we're dropping OSX anyway :p
22:53:54 <planetmaker> by default OSX doesn't use llvm
22:54:24 <planetmaker> though currently it trades compile speed for execution speed
23:03:32 *** Nite_Owl has joined #openttd
23:07:37 <aggro> Well thanks for listening. 1:00 am, work tomorrow -> sleep now, bye
23:26:18 <Rubidium> hmm.. too bad aggro left :(
23:27:27 <Rubidium> it's gcc 4.5 that gave those warnings (and errors)
23:27:41 <Eddi|zuHause> but who uses THAT...
23:29:25 <planetmaker> Rubidium, did you port the threaded SDL to OpenTTD 0.7.3 ?
23:29:44 <planetmaker> I can reproduce the same resizing odities there, too
23:30:16 <planetmaker> then it's got nothing to do with it.
23:30:37 <Rubidium> then it's probably a SDL issue; OpenTTD not getting the message that the window got resized
23:31:02 <planetmaker> Strange, though, but seems most plausible
23:31:31 <planetmaker> especially as it regains the whole window, if the window is moved or re-sized again or alike
23:34:01 <planetmaker> I just wonder that I should be the first to notice this...
23:35:36 <Rubidium> can't find an obvious reason for it (i.e. a bug report with google)
23:35:56 <Rubidium> besides people having issues with sdl backed by opengl on windows
23:37:42 <planetmaker> hm... possibly it's related: when I resize, the whole window sometimes gets black
23:38:00 <planetmaker> hm... even stranger: now I had a black bar upon start...
23:38:44 <Rubidium> maybe it's a realloc of some sort, causing the buffer to be empty?
23:38:47 <planetmaker> Does it have problems with displays of 2580 x 1024?
23:39:29 <planetmaker> I would suspect something like that. I've little knowledge how X11 drivers handle this.
23:40:37 *** Rubix`` has joined #openttd
23:40:52 <planetmaker> he, thanks. Ok, I guess we can attribute it to SDL then.
23:41:22 *** Coco-Banana-Man has quit IRC
23:42:11 <planetmaker> as will then be probably the fact, that not even each time I start the whole window is filled out, if it's larger than one monitor.
23:43:15 <planetmaker> hm... shouldn't it remember the window size?
23:44:13 <planetmaker> arg. OpenTTD remembers.
23:44:32 <planetmaker> But the window gets created over both monitors, if the window size was larger than one monitor...
23:44:42 <planetmaker> so... also not your bug ;-)
23:56:52 <CIA-4> OpenTTD: rubidium * r18025 /trunk/src/3rdparty/minilzo/ (lzodefs.h minilzo.c): -Fix (r17217): more missing/extra parentheses (for compilers I've never heard of)
continue to next day ⏵
