Times are UTC Toggle Colours
00:05:27 *** TomyLobo [~foo@91.65.115.103] has quit [Quit: Standby mode...] 00:09:30 *** Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd 00:16:16 *** Hazzard_ [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Ping timeout: 480 seconds] 00:26:37 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 00:27:22 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Remote host closed the connection] 00:42:53 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 00:52:08 *** SHOTbyGUN [shotbygun@213-186-253-83.bb.dnainternet.fi] has joined #openttd 00:58:21 *** Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd 01:09:06 *** Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has quit [Ping timeout: 480 seconds] 01:11:21 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 01:15:42 *** Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd 01:33:14 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 01:39:20 *** liq3 [~liq3@CPE-120-147-178-81.gdfw1.vic.bigpond.net.au] has joined #openttd 01:39:24 *** shansen [~shansen@212.17.41.140] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzzâŠ] 01:42:02 *** glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye] 02:01:28 *** Pokka [~Octomom@d58-106-24-83.rdl801.qld.optusnet.com.au] has joined #openttd 02:02:58 *** Pikka [~Octomom@d58-106-46-133.rdl801.qld.optusnet.com.au] has quit [Ping timeout: 480 seconds] 02:09:34 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd 02:20:46 *** liq3 [~liq3@CPE-120-147-178-81.gdfw1.vic.bigpond.net.au] has quit [] 02:22:16 *** liq3 [~liq3@CPE-120-147-178-81.gdfw1.vic.bigpond.net.au] has joined #openttd 02:38:13 <liq3> Eddi|zuHause: I looked up one of those supposed OpenGL implementations. It was just an openGL blitter, not a proper OpenGL implementation. 02:43:02 *** InvokeStatic_ [~Invoke@c-24-11-157-247.hsd1.mi.comcast.net] has quit [Read error: Operation timed out] 02:58:11 *** Djohaal [~Djohaal@187.58.245.102] has quit [Read error: Connection reset by peer] 03:08:36 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 03:08:41 *** HerzogDeXtEr [~flex@i59F6A278.versanet.de] has quit [Quit: Leaving.] 03:09:56 *** Pokka [~Octomom@d58-106-24-83.rdl801.qld.optusnet.com.au] has quit [Quit: Leaving] 03:30:16 *** George [~George@185.43.94.91] has quit [Ping timeout: 480 seconds] 03:30:21 *** KWKdesign [~KWKdesign@pool-72-94-147-76.phlapa.fios.verizon.net] has quit [Ping timeout: 480 seconds] 03:30:40 *** George [~George@185.43.94.91] has joined #openttd 03:30:59 *** KWKdesign [~KWKdesign@pool-72-94-147-76.phlapa.fios.verizon.net] has joined #openttd 03:34:44 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 04:12:11 *** Pereba [~UserNick@177.40.221.106] has quit [Quit: I'm a happy AdiIRC user! Get it here: http://adiirc.com/] 04:27:59 *** MTsPony [~MTsPony@008-086-128-083.dynamic.caiway.nl] has quit [Ping timeout: 480 seconds] 04:35:51 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 04:48:44 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 04:56:01 *** Eddi|zuHause [~johekr@p5DC66EDE.dip0.t-ipconnect.de] has quit [] 04:56:19 *** Eddi|zuHause [~johekr@p57BD5EB2.dip0.t-ipconnect.de] has joined #openttd 05:03:58 *** Jomann [~abchirk@p57A086B6.dip0.t-ipconnect.de] has joined #openttd 05:32:42 <__ln__> http://arstechnica.com/gaming/2014/10/the-road-to-civilization-a-conversation-with-sid-meier/ 05:41:00 *** Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer] 05:49:34 <Rubidium> liq3: the problem with "proper" GL is that you can't make a proper 3D rendered version of OpenTTD while using the same scales, and you'd be mostly missing lots of models. A vehicle is (at least) 8 pixels high, then add 1 pixel height for the catenary and bridge and try to fit that within the 8 pixels of height differential between two height levels. Ofcourse you can "fix" this, but then you'd change some fundamental scalings that make the game w 05:50:18 <liq3> Rubidium: I'm not thinking of 3d OGL at all, just 2d OGL. 05:51:01 <Rubidium> oh, and isn't there a limit on the number of sprites you can keep "in memory" for GL? 05:51:07 <liq3> Don't know. 05:51:16 *** theholyduck [~theholydu@172.245.30.36] has quit [Ping timeout: 480 seconds] 05:51:17 <Rubidium> AFAIK you were fairly likely to hit that limit rather soon 05:52:03 <Rubidium> unless you were starting to do all kinds of tricky stuff merging sprites into one "sprite" and using some cropping methods 05:52:53 <liq3> I was thinking of just textured surfaces. 05:56:36 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Ping timeout: 480 seconds] 05:57:06 <liq3> Rubidium: I've been poking around the code... Any hints where OpenTTD does depth sorting? 06:07:39 *** theholyduck [~theholydu@172.245.30.36] has joined #openttd 06:15:05 <planetmaker> moin 06:15:30 <planetmaker> the base game has over 6000 sprites. If you play with NewGRFs you easily have several 10k sprites 06:16:03 <liq3> You don't need to use point sprites. Textured quads would work fine. 06:16:22 <planetmaker> yes, we can write another game, indeed 06:16:40 <planetmaker> and throw away all graphics which we have 06:16:56 <liq3> what? 06:18:41 <liq3> OpenGL can use all the current sprites just fine... 06:20:54 *** Jomann [~abchirk@p57A086B6.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 06:25:48 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 06:27:48 <Supercheese> Jeez, this is one heck of a specific dictionary of terms, and in 6 languages no less: http://ephemeris.alcuinus.net/lexico/geographica4.htm 06:30:33 <Supercheese> all the German terms are so fun to say 06:34:38 *** George [~George@185.43.94.91] has quit [Ping timeout: 480 seconds] 06:37:21 *** George [~George@185.43.94.91] has joined #openttd 06:37:48 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 06:46:11 <planetmaker> he, nice :) 06:47:48 *** Flygon_ [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd 06:54:16 *** Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has quit [Ping timeout: 480 seconds] 07:01:04 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 07:06:18 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 07:18:53 *** Progman [~progman@p57A18055.dip0.t-ipconnect.de] has joined #openttd 07:30:52 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 07:33:37 *** kiwibun [~smuxi@p5B37ED34.dip0.t-ipconnect.de] has joined #openttd 07:59:21 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 08:14:31 *** Celestar [~Celestar@p4FD6E80C.dip0.t-ipconnect.de] has joined #openttd 08:25:03 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 08:26:54 *** Celestar [~Celestar@p4FD6E80C.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 08:57:34 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 09:00:06 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds] 09:00:48 <argoneus> mornink 09:05:31 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 09:06:57 *** gelignite [~gelignite@i528C3B49.versanet.de] has joined #openttd 09:12:05 <NGC3982> Bah, i don't get it 09:12:14 <NGC3982> I'm trying to locally use my server 09:12:20 <NGC3982> I have like a minute of latency over wifi 09:15:10 <liq3> you connected locally right? 09:17:12 <NGC3982> Yes 09:17:19 <NGC3982> It's something with OpenTTD and my wifi 09:17:40 <NGC3982> Using wired or something else works great 09:17:40 *** frosch123 [~frosch@frnk-4d01df20.pool.mediaWays.net] has joined #openttd 09:17:51 <NGC3982> The thing is, the wifi is not that bad for most other things 09:18:12 <NGC3982> I get roughly 1MB of data transfer speed, and i can't seem to notice any lag while surfing the web. 09:19:32 <frosch123> __ln__ is featured in today's xkcd! 09:19:44 <argoneus> wut 09:20:08 <NGC3982> :D 09:20:11 <NGC3982> True. 09:21:41 *** Jinassi [~Jinassi@0001ec72.user.oftc.net] has joined #openttd 09:29:53 *** Eddi|zuHause2 [~johekr@p5DC677B2.dip0.t-ipconnect.de] has joined #openttd 09:34:01 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 09:34:16 *** Eddi|zuHause [~johekr@p57BD5EB2.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 09:36:46 *** TomyLobo [~foo@91.65.115.103] has joined #openttd 09:41:20 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 09:46:22 *** Yotson [~Yotson@2001:980:6ac8:1:2441:476c:3428:d35c] has joined #openttd 09:48:02 *** sla_ro|laptop [~sla.ro@89.121.131.100] has joined #openttd 10:09:46 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 10:19:05 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 10:40:47 <fonsinchen> You can use the OpenGL texture memory as cache for the base texture memory 10:41:08 <fonsinchen> Most of the time you're not using all those 100000 sprites at the same time 10:41:36 <fonsinchen> If I get bored I might take a stab at that ... 10:41:40 <fonsinchen> ... so probably never 10:41:48 <planetmaker> :) 10:42:08 <argoneus> fonsinchen: you live a happy life 10:42:10 <argoneus> if you are never bored 10:42:25 <planetmaker> fonsinchen, a usual game might not have all 6000+ sprites form a base set at the same time, but suprisingly many 10:42:40 <peter1138> I wonder what the difference is between "just an opengl blitter" and "a proper opengl implementation" 10:42:42 <fonsinchen> I'm not so sure. If I was bored more often I might be doing more stuff like that. 10:42:56 <argoneus> I wish I did coding when I was bored 10:43:01 <argoneus> usually I just play starcraft or openttd 10:43:09 <argoneus> (so most of the time) 10:43:12 <fonsinchen> Actually that thing on the forums also includes an OpenGL graphics driver 10:43:13 <planetmaker> I'll recon a third or half of them are used at any time 10:43:51 <fonsinchen> I did have a look at it recently and it seems like a good starting point for further experiments. 10:44:10 <peter1138> What thing on the forums? 10:44:38 <planetmaker> there's an ancient opengl blitter / driver somewhere. 2 years or so, ago? 10:44:46 <peter1138> only 2 years ago? 10:44:50 <peter1138> mine is 6 :) 10:44:54 <fonsinchen> http://www.tt-forums.net/viewtopic.php?f=33&t=38151&hilit=opengl+blitter 10:45:00 <planetmaker> :) timporal memory is fuzzy 10:45:28 <fonsinchen> look in the last pages to get the update I did ages ago. 10:45:58 <peter1138> basically you need to rewrite quite a lot of stuff to get decent performance 10:46:31 <fonsinchen> First you need to get it do all the corner cases of sprite sorting and stuff correctly 10:47:08 <fonsinchen> Then you have to figure out why it's slow on some hardware/software combinations 10:47:38 <fonsinchen> Mind that it was quite a bit faster than the other blitters and graphics drivers on some configurations 10:48:01 <peter1138> Main problem with mine was when zoomed out. 10:48:16 <peter1138> Oh and some problem with loading sprites in another thread. 10:48:40 <fonsinchen> The texture memory and its handling of it may indeed have something to do with that ... 10:49:43 <fonsinchen> But even if we ended up with something that performs better on just some identifiable subset of configurations that would already be great. 10:49:51 <peter1138> Basically the problem is we have no many GetSprite() calls that are only concerned with the size of the sprite 10:50:02 <peter1138> Some of those get called during landscape generation 10:50:17 <peter1138> OpenGL didn't grok multiple threads, back then. 10:50:27 *** Eddi|zuHause2 is now known as Eddi|zuHause 10:50:45 <fonsinchen> It can still have its problems, but there are drivers that handle that quite well by now. 10:50:48 <Eddi|zuHause> <Supercheese> all the German terms are so fun to say <- like "Sternschnuppe"? 10:50:49 <peter1138> At least we should be able to use shaders to do all the colour remapping. 10:51:28 <peter1138> Back in 2008 it was still easier to use the now-deprecated paletted texture extension. 10:56:44 <liq3> peter1138: I'd tell you what the difference is, but I'm still trying to figure out the gfx code :< 10:56:57 <peter1138> haha 10:57:20 <liq3> I've figured out that you're only redrawing parts of the scene every frame... That isn't how opengl tends to work at all. 10:57:28 <liq3> It usually redraws the entire framebuffer every frame. 10:57:36 <peter1138> Yes. that's what I said the other day. 10:58:03 <liq3> And, since all that code that decides what to redraw is tied into a bunch of non-gfx code... Would be so much work to implement opengl. 10:59:08 <liq3> Also, OpenTTD's gfx code is confusing as hell. :< 10:59:54 <peter1138> There are ways to make it more opengl-like, but they basically require replacing a good chunk of ottd 11:00:15 <liq3> Yes. Stuff like SetDirty would be completely unnecessary with OpenGL. 11:01:11 <peter1138> partial scene drawing HAS been done with opengl 11:01:24 <liq3> Yeh I'm sure it has. 11:01:49 <peter1138> i believe simcity 4 does it 11:01:58 <liq3> Hrm, I mean, I suppose you could setup partial scene redrawing with OpenGL too. 11:02:35 <liq3> Sorry, redrawing the whole scene isn't necessary at all with OpenGL. just how I learned to do it. 11:02:55 <Eddi|zuHause> <liq3> Yes. Stuff like SetDirty would be completely unnecessary with OpenGL. <-- it wouldn't be hard to let that function simply do nothing if opengl is used... 11:03:11 <liq3> Yeh, that's probably what I'd do if I implemented OpenGL. 11:03:23 <liq3> Since you'd want to keep the current blitters for compatibility.... I imagine 11:03:36 <Eddi|zuHause> certainly 11:03:54 <peter1138> There'd be a lot of people asking for their money back if not. 11:04:04 <planetmaker> full refund! guaranteed 11:04:13 <Eddi|zuHause> we don't have that kind of money 11:04:13 <liq3> Well, anyone with a computer from the past 10 years can probably run OpenGL with better performance than the current blitters. 11:04:35 <planetmaker> really. Proof it 11:04:49 <liq3> That'd require me to implement OpenGL. No thanks. :P 11:04:50 <planetmaker> in openttd operation that is 11:05:01 <planetmaker> otherwise it's basically only empty words and void claims 11:05:22 <planetmaker> and quickly getting boring, tbh 11:05:22 <Eddi|zuHause> liq3: does that include android phones and raspberry pis? 11:05:36 <liq3> Eddi|zuHause: I have no idea. 11:05:52 <Eddi|zuHause> then don't throw around that kind of allegations 11:06:35 <Eddi|zuHause> maybe i want to run an openttd server on my fritzbox :p 11:06:54 <Eddi|zuHause> (that's probably going to be horrible :p) 11:08:42 <liq3> Phones don't really count as computers. They have awful GPUs :< 11:09:37 <peter1138> But ottd runs on them. 11:09:56 <liq3> hrm 11:11:43 <liq3> oh my bad... Wow Phone GPUs are powerful. 11:11:48 <liq3> ...like compared to old GPUs. 11:11:59 <liq3> Based on benchmarks, I imagine yes even phones would be faster. :p 11:13:03 <Eddi|zuHause> under the assumption that you can create an opengl implementation that would be faster in the first place 11:13:17 <liq3> That's a well founded assumption. 11:13:31 <Eddi|zuHause> which i have not even seen a hint of plausibility for 11:13:52 <liq3> What part. That I can implement one or that a proper OpenGL implementation would be faster? 11:13:58 <peter1138> Judging by your previous statements I don't think you should be assuming anything. 11:14:01 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 11:14:15 <Eddi|zuHause> either of those 11:14:40 <Eddi|zuHause> not that there can be an implementation, nor that you could actually produce it 11:15:34 <peter1138> Heh, iPod touch 4th gen has a retina display... but only 24MB video ram. 11:15:43 <liq3> :o 11:16:31 <peter1138> 256MB ram though, which is plenty for a standard blitter, although i wouldn't like to try 4x zoom. 11:17:03 <peter1138> But hey, that's 4 years old. 11:22:15 <NGC3982> So.. It would play OpenTTD? 11:22:25 <NGC3982> Or did i just correlate because location. 11:23:08 <Eddi|zuHause> it wouldn't, because there is no app store entry for openttd 11:29:51 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 11:38:21 *** Supercheese [~Superchee@76.178.136.186] has quit [Ping timeout: 480 seconds] 11:41:24 <frosch123> liq3: basically you need to find a reason why opengl should be faster in the first place, and not just assuming by its name 11:41:47 <frosch123> you need to find an opengl feature which ottd can benefit at least somewhat from 11:42:51 <fonsinchen> That opengl blitter on the forums was faster for certain high-end GPUs of 2008 (?) if you didn't zoom out too much 11:43:19 <fonsinchen> I guess those things can only have gotten better 11:43:21 <Eddi|zuHause> but "zoom out" was the whole cause of the discussion 11:43:37 <frosch123> fonsinchen: but ottd also got better without opengl, we now have a drawing thread 11:43:53 <frosch123> so, whatever you gained with waiting for transfering data, is now gone 11:44:11 <fonsinchen> As I said: I'm pretty sure there is potential for improvement in the OpenGL blitter, too. 11:45:04 <fonsinchen> But, of course it would be a lot of work to figure out the details 11:45:32 <frosch123> anyway, when i think of opengl i think of texture atlases, texture scaling, mipmapping, shaders and zbuffers 11:46:04 <frosch123> shaders would have been nice for palette animation 11:46:06 <fonsinchen> Going forward I guess our model of doing graphics so far will run into more and more problems on more and more devices. 11:46:13 <frosch123> texture atlasses are likely hell of complicated 11:46:17 <fonsinchen> So we should eventually come up with something 11:46:28 <frosch123> i do not see how openttd could ever use texture scaling, mipmapping and zbuffers 11:46:52 <fonsinchen> sure, it isn't trivial. But you don't have to use all opengl features from the start 11:48:54 <frosch123> maybe, but i actually think you will gain a lot more by utilizing more cpu cores than the gpu 11:49:41 <liq3> frosch123: zooming out causes increased lag even though GPU usage is only at 25%. This is because OpenTTD is doing a bunch of gfx stuff on the CPU, which it shouldn't be. This would be fixed by using a proper gfx API e.g. OpenGL 11:49:49 <frosch123> if the problem is when zoomed out, and you claim to be able to solve it with an gpu, that means you want to solve it parallisation 11:50:05 <frosch123> but you can also do that with the cpu, which i beleive fits ottd a lot better 11:50:20 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 11:50:23 <liq3> CPUs are REALLY SLOW at handling graphics compared to GPUs. 11:50:30 <frosch123> liq3: wrong 11:50:50 <frosch123> gpu are fast at very specific tasks 11:50:56 <liq3> ...like graphics. 11:51:00 <frosch123> and i doubt ottd graphics are part of that 11:51:22 <frosch123> anything that derivates from the standard gpu flow, is way slower 11:52:00 <frosch123> gpu algorithms are trivial compared to what cpus can do 11:52:33 <frosch123> gpu are great to implement a fourier transformation in parallel, but they are unable to execute a fast fourier transformation, so every cpu outperforms them 11:52:35 <liq3> Yes. Because graphics is mostly just huge amounts of 'trivial' math, which CPUs are bad at and GPUs are designed for. 11:52:51 <frosch123> driving the parallelisation into non-sense 11:53:19 <planetmaker> liq3, openttd graphics are not just 'trivial maths'. they require lookup on the map array and state of the objects 11:53:42 <planetmaker> otherwise you can't decide what to draw 11:53:52 <liq3> openttd graphics are extremely simple compared to like Starcraft 2.... :< 11:54:05 <frosch123> liq3: exactly, that's why gpu give no benefit 11:54:16 <frosch123> you can only safe time, if there is time in the processing 11:54:39 <frosch123> ottd will fail to utilizie gpu exactly because the graphics are so simple 11:55:09 <liq3> And yet the graphics still manage to lag modern CPUs. 11:55:25 <planetmaker> no... the game does. not the graphics 11:55:33 <liq3> it lags more when I zoom out. it's the gfx. 11:55:43 <frosch123> none of the processings that are perfomed fast by gpu, are used by gpu 11:55:45 <liq3> Well, it's both. Zooming out increases the gfx, and gives less time to the game logic. 11:56:02 <frosch123> liq3: again wrong 11:56:08 <frosch123> it's not the graphics that lag 11:56:21 <frosch123> it's the loop-up in the game state and deciding what to draw 11:56:29 <frosch123> which will never be done on the gpu 11:56:52 <frosch123> it can be parallelized in theory, but requires restructing in the newgrf processor 11:56:53 <fjb> Moin 11:56:58 <liq3> Checking what's in the view point is extremely simple and fast. :/ 11:57:02 <liq3> view port*. 11:57:07 <frosch123> liq3: again wrong 11:57:09 <liq3> Especially since it's just quads. 11:57:11 <planetmaker> it's not *what*. But *how* 11:57:21 <frosch123> liq3: how do you draw a station? 11:57:36 <liq3> How do I draw a station, or OpenTTD? 11:57:46 <planetmaker> or a train? 11:58:02 <frosch123> liq3: you first discover that it's a station, then you ask a newgrf, execute some scripts, which result in a series of sprites, depending on the various game state variables 11:58:08 <frosch123> it's the same for all tiles 11:58:16 <frosch123> a tile is no single fixed sprite 11:58:28 <frosch123> it's a sequence of sprites, which first needs to be determined 11:58:32 <liq3> ugh procedural programming. >.> 11:58:35 <frosch123> the drawing is a piece of cake afterwards 11:59:12 <liq3> frosch123: that's still incredibly simple. 11:59:37 <liq3> you know, for a CPU 11:59:40 <frosch123> since the drawing does not modify the game state, you can parallelize the task in theory, but not with the current implementation of ottd 12:00:23 *** HerzogDeXtEr [~flex@88.130.185.16] has joined #openttd 12:01:23 <frosch123> whatever, as said before: gpus are good to draw starcraft-style graphics 12:01:27 <liq3> frosch123: the method you described is just a series of if statements. It's really fast for a CPU. 12:01:32 <frosch123> but that has nothing to do with openttd 12:01:39 <liq3> Slow part is doing ANY sort of pixel manipulation. 12:01:50 <frosch123> liq3: again wrong 12:02:00 <frosch123> when zooming out the number pixels stays the same 12:02:04 <frosch123> but the number of tiles increases 12:02:13 <liq3> what? 12:02:31 <frosch123> yeah, guess what, when you zoom out your monitor does not change its size 12:02:40 <liq3> what are you even mentioning pixels? 12:02:49 <frosch123> you started with pixels 12:03:08 <liq3> I'm saying any sort of image manipulation is slow for a CPU. 12:03:22 <frosch123> the number of pixels to process it the same on every zoom level 12:03:33 <frosch123> but the number of sprites and tiles changes 12:03:38 <planetmaker> it really starts to develop certain traits of popcorn discussions 12:03:42 <liq3> That's not what I'm refering to. I mean things like depth sorting and scaling. 12:03:47 <liq3> haha. 12:04:12 <frosch123> liq3: for depth sorting you need sprites with depth information 12:04:14 <frosch123> which do not exist 12:04:25 <liq3> The only thing zooming out should change is what the game logic asks the renderer to draw. 12:04:29 <frosch123> as i mentioned earlier: zbuffers are on the list of things i doubt will ever work for ottd 12:04:45 <liq3> and the renderer should do be doing NO image manipulation on the CPU, it should be doing it all the GPU. 12:04:50 <planetmaker> liq3, and that's the only thing which changes: the amount of tiles which need querying 12:04:52 <frosch123> liq3: yeah, and guess what part in that takes so long? 12:05:21 <liq3> if OTTD used OpenGL, z buffers would work fine. 12:05:27 <frosch123> wrong 12:05:29 <liq3> since you just pass the Z coord of the sprite and OpenGL handles it. 12:05:39 <planetmaker> no... 12:05:40 <frosch123> being able to use zbuffers has preconditions 12:05:43 <liq3> no? 12:05:45 <frosch123> you need a z value for your sprite 12:05:52 <frosch123> or even within the sprite 12:05:55 <frosch123> but those do not exist 12:06:09 <liq3> yes the game logic has to figure out what z is. 12:06:21 <frosch123> great, so you saved nothing 12:06:21 <liq3> considering it's an isometric tile based game I can't imagine that's too hard. 12:06:26 <Eddi|zuHause> that's what the blitter does 12:06:39 <frosch123> if the gamelogic has to figure out the z position, it can just draw the sprites in that order 12:06:46 <frosch123> no usage of opengl at all 12:07:07 <liq3> "can just draw the sprites in that order" *shudders* 12:07:19 <frosch123> liq3: again wrong, sprite sorting is a non-well defined thing 12:07:37 <frosch123> there is proper algorithm for sprite sorting, because it is no proper problem in the first place 12:07:38 <Eddi|zuHause> the sprite sorter has so many errors, it's not funny 12:07:52 <frosch123> *no proper algorithm 12:08:30 <fonsinchen> The existance of vector math optimizations for blitters and sprite sorter tell me that there might be something to be gained from other forms of parallelization in that area 12:08:45 <peter1138> Is this still going on? :-) 12:09:24 <frosch123> https://www.tt-forums.net/download/file.php?id=75692 <- simple proof that sprite sorting will never work 12:10:07 <fonsinchen> I know that picture, but somehow we succeed in using sse for sprite sorting, right? 12:10:07 <frosch123> which is the reason why modern graphics use zbuffers, but that requires that's the images have z data 12:10:33 <liq3> frosch123: what? You'd give the blue one depth 0, green depth 1, and red gepth 2. OpenGL will draw it correctly. 12:10:37 <frosch123> fonsinchen: yes? but it is still serial, not parallel 12:10:51 <frosch123> liq3: keep on thinking :) 12:10:59 <planetmaker> liq3, look again ;) 12:11:00 <fonsinchen> It's implicitly parallel as it does vector math. We could try to shoehorn that part into opengl somehow. 12:11:22 <frosch123> fonsinchen: or you could use multiple cpu cores :) 12:11:26 <liq3> I don't know why it's drawn in RGB. It should be BGR 12:11:34 <frosch123> both run into the same parallelisation issues with ottd 12:11:41 <fonsinchen> Yes, but ultimately your GPU will have more cores than your CPU. 12:11:57 <fonsinchen> I'm not saying it's necessarily better, but it might be worth a try 12:12:02 <frosch123> but the gpu has very restrictive memory access 12:12:32 <fonsinchen> I know, but most of the time it has separate memory and runs semi-independent from the CPU 12:12:49 <fonsinchen> so while the GPU is doing the sprite sorting you could do something else on the CPU 12:13:21 <Eddi|zuHause> liq3: you cannot map non-transitive constructs onto a linear scale 12:13:25 <frosch123> [14:10] <liq3> frosch123: what? You'd give the blue one depth 0, green depth 1, and red gepth 2. OpenGL will draw it correctly. <- if you still haven't figure it out, your sequence draws the red box incorretly above the blue box 12:14:02 <liq3> what are you even trying to accomplish in that pic? 12:14:22 <liq3> can you link the tt thread? 12:14:24 <frosch123> that your "opengl will sort it correctly" is complete non-sense 12:14:34 <frosch123> opengl does not help you at all 12:14:36 <fonsinchen> liq3, openttd has stuff like that, sadly 12:14:37 <liq3> OpenGL will sort it in whatever order you tell it to. 12:14:52 <fonsinchen> You'd need a full 3d model to get that right. 12:14:53 <Eddi|zuHause> but none of these orders will produce this result 12:14:55 <frosch123> exactly, but figureing out the order 12:15:02 <Eddi|zuHause> because it's non-transitive 12:15:18 <liq3> What should be on top? 12:15:23 <frosch123> liq3: if you think the feature of opengl is that it draws the stuff it tells you to, then you are a lost case 12:15:27 <Eddi|zuHause> R->G, G->B but not R->B, it's B->R 12:15:36 <frosch123> you only use gpu power if the gpu figures out the order 12:15:43 <liq3> Eddi|zuHause: -> means? 12:16:00 <Eddi|zuHause> front->back 12:16:13 <liq3> so above -> below? 12:16:18 <fonsinchen> Actually we already have problems with that stuff right now. See FS#119 12:16:43 <fonsinchen> In some cases there just is no correct ordering of the sprites 12:16:49 <Eddi|zuHause> yes, somewhat 12:16:50 <peter1138> CPUs are bad at trivial math? Really? 12:17:04 <Eddi|zuHause> A->B => B must be drawn before A 12:17:17 <liq3> peter1138: yes. They're slow compared to GPUs. 12:17:30 <liq3> maybe "trivial" is the wrong word. 12:17:44 <frosch123> liq3: add 100 numbers, very simple, any cpu will out-perform a gpu 12:18:05 <liq3> frosch123: try drawing OpenTTD purely on CPU >.> 12:18:14 <liq3> you'll be lucky to get 1 FPS 12:18:21 <frosch123> that's what we are doing? 12:18:24 <liq3> not at all 12:18:24 <planetmaker> we get 30 fps? 12:18:29 <liq3> you're still using basic hardware acceleration afaik. 12:18:41 *** KWKdesign [~KWKdesign@pool-72-94-147-76.phlapa.fios.verizon.net] has quit [Ping timeout: 480 seconds] 12:18:48 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 12:18:59 <liq3> maybe i'm wrong. 12:19:00 <Eddi|zuHause> liq3: yes, and any "advanced" hardware acceleration is optimized for stuff we don't want to do. 12:19:18 *** KWKdesign [~KWKdesign@pool-72-94-147-76.phlapa.fios.verizon.net] has joined #openttd 12:19:22 <liq3> it's optimized for all gfx operations, including drawing a few thousand textured quads. 12:19:45 <liq3> since advanced stuff is basically just drawing a few hundred thousand textured quads anyway. It's just more, not more complex really. 12:20:38 <Eddi|zuHause> you probably haven't understood what a GPU actually is... 12:21:24 *** Klanticus [~quassel@179.234.189.113] has joined #openttd 12:21:31 <liq3> It's a processor optimized for doing lots of math instructions. 12:21:39 <liq3> CPUs are optimized for conditionals and such. 12:21:57 <Eddi|zuHause> no 12:22:04 <liq3> yes? 12:22:10 <Eddi|zuHause> GPU is optimized for doing lots of PARALLEL instructions 12:22:28 <Eddi|zuHause> CPU is optimized for doing lots of SEQUENTIAL instructions 12:22:35 <frosch123> a gpu is optimised for doing the _same_ operation on a _very_ limited number of input operands, in a vectorial form 12:22:46 <Eddi|zuHause> for any single math operation, the CPU will be faster than the GPU 12:22:58 <liq3> a GPU can execute 800x more instructions per clock cycle, compared to a GPU. 12:22:59 <liq3> CPU* 12:23:07 <liq3> GPU 800x more than CPU. 12:23:13 <frosch123> a gpu is good for adding 100 pairs of two numbers, a cpu is good for adding 200 numbers 12:23:23 <Eddi|zuHause> yes, but only if it's THE SAME operation on 800 SIMILAR sets of data 12:23:33 <liq3> Which is what gfx processing is. 12:23:35 <liq3> Huge amounts of math. 12:23:39 <frosch123> not in ottd 12:24:13 <liq3> Even in OTTD. The actual gfx calculations once it has the z depth and sprites, is figuring out sprite by sprite, pixel by pixel, what pixel to draw where. 12:24:20 <liq3> on the monitor. 12:24:31 <Eddi|zuHause> no 12:24:35 <liq3> when you have actual 3d gfx, it has to transform the 3d space to the monitor too, which is even more math. 12:24:40 <Eddi|zuHause> only sprite-by-sprite, not pixel-by-pixel 12:24:44 <frosch123> liq3: your statement "once it has the z depth" is about as smart as "electric power comes from a power socket in your wall" 12:24:48 <liq3> no, it does it pixel by pixel. :/ 12:25:11 <Eddi|zuHause> it probably does memmove and stuff 12:25:12 <fonsinchen> actually adding 100 numbers may be faster on your GPU, it can do 50, 25, 12, 6, 3, 2, 1 additions in parallel, leaving it with 7 steps, where a single threaded implementation would need 100 steps. 12:25:36 <frosch123> fonsinchen: that would require the gpu to have random access on the intermediate results 12:25:39 <frosch123> which it does not have 12:26:38 <frosch123> i tried to implement fft, but gpus just fail with chains of data dependencies 12:27:12 <liq3> fft? 12:27:22 <frosch123> fast fourier transformation 12:27:27 <fonsinchen> You can fix that by using vectors and shader programs in clever ways, but yes, it's a pain. 12:27:30 <liq3> btw, what forum thread was that red/green/blue pic from? 12:27:52 <frosch123> does not matter, all is said in the picture 12:27:58 <frosch123> the thread is about other stuff from the past 12:28:57 <frosch123> anyway, to end this discussion from my pov: gpu will only speed up things on a per-pixel level, which may help for bigger screens, but will never help for zoom-out 12:29:46 <liq3> lol. It will. 12:30:08 <liq3> Btw, there any resources to explain the gfx code? stuff is confusing. 12:30:20 <planetmaker> frosch123, there's the fftw, a nice c implementation. Fasted implementation I found, like 4 years ago 12:30:29 <planetmaker> but ofc totally w/o gpu :) 12:31:01 <planetmaker> http://www.fftw.org/ 12:31:20 <Eddi|zuHause> yay, finally we go back to off-topic :p 12:31:34 <planetmaker> :D 12:32:06 <peter1138> Maybe we should raytrace it... 12:32:08 <planetmaker> we could use fft to reduce the required data to draw by using it as a band-pass filter. Removing low and high frequencies from the screen output 12:32:19 <peter1138> heh 12:32:26 <frosch123> planetmaker: yeah, gpu are nice to reduce O(n^2) algorithms to O(n). but the cpu will still be better with a O(n*log n) algorithm, since the cpu speed easily beats the log n 12:34:35 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 12:36:16 <Eddi|zuHause> so matrix multiplication => GPU, matrix norm => CPU 12:36:56 <Eddi|zuHause> unless you want to do fancy stuff involving the spectral-norm :) 12:37:06 *** Klanticus [~quassel@179.234.189.113] has quit [Read error: Connection reset by peer] 12:41:22 *** Klanticus [~quassel@179.234.178.216] has joined #openttd 12:41:27 <Eddi|zuHause> is there a translation for "Gulaschkanone"? 12:41:53 <frosch123> to latin? 12:42:04 <Eddi|zuHause> to any language, really :() 12:42:22 <frosch123> leo has one 12:42:47 <Eddi|zuHause> specifically: does this device even exist outside germany? 12:42:56 <frosch123> but maybe not with same intone 12:43:45 <frosch123> Eddi|zuHause: no, because only germans are known for easing meat all day, though i think i saw some statistics that britains actually eat more :p 12:44:20 <frosch123> or is it because sausages do not contain any actual meat? 12:44:32 <Eddi|zuHause> well, you can get vegetarian soups out of a "Gulaschkanone" :) 12:45:26 <frosch123> anyway, leo says "mobile kitchen" in the civil sense, and "field kitchen" in the military sense 12:45:36 <Eddi|zuHause> frosch123: i think it was in iceland, where on the height of the horse-meat scandal they tested about a 100 meat products, and 2 of them did not contain any meat at all 12:46:37 <frosch123> Eddi|zuHause: some once sued a soup producer because of a meat poisoning, and the producer profed that there's no meat in the product, desprite of the name 12:47:08 <planetmaker> frosch123, I thought only eating meat was also South-American habit? (going by our Brazilian restaurant around the corner) 12:47:30 <frosch123> planetmaker: i don't think restaurants are representative 12:47:44 <planetmaker> doh. You destroy my world view :P 12:47:56 <Eddi|zuHause> planetmaker: there is no reasonable expectation that a "<country name> restaurant" serves dishes even remotely popular in <country name> 12:48:15 *** Pereba [~UserNick@177.40.221.106] has joined #openttd 12:48:31 <Eddi|zuHause> like you're more likely to find a Döner in berlin than in istanbul 12:48:52 <frosch123> http://de.wikipedia.org/wiki/Fleischkonsum <- on that table, germany is in position 21 12:50:17 <frosch123> funnily there is no link to an english version of that page 12:50:22 <frosch123> does that mean something? :p 12:50:47 <Eddi|zuHause> yes, it means that the original text was published in german 12:50:58 <Eddi|zuHause> and nobody bothered to translate it 12:51:21 <frosch123> yes, but i meant from a social pov 12:51:48 <frosch123> like germans trying to profe, that they are not eating sausages all day 12:52:09 <Eddi|zuHause> it may also mean that germany has more food-enthusiasts 12:52:38 <Eddi|zuHause> independent of whether they are pro-meat or anti-meat 12:53:13 <frosch123> haha, the text says "japanese eat noticeable few meat", i guess they did not consider fish :p 12:53:36 <__ln__> fish is fish, meat is meat 12:53:50 <frosch123> __ln__: what does wale count int? 12:54:08 <__ln__> a mushroom 12:54:36 <frosch123> ah, sorry, what about whale then? 12:54:43 <Eddi|zuHause> # badger, badger, badger, badger, mushroom, mushroom 12:56:05 <__ln__> frosch123: marshmallow 12:57:33 *** Klanticus_ [~quassel@179.234.178.216] has joined #openttd 12:59:38 <planetmaker> frosch123, when I lived in New Zealand, there was the saying that a balanced diet is a burger in the left hand and another burger in the right hand ;) 12:59:51 *** sla_ro|laptop [~sla.ro@89.121.131.100] has quit [Ping timeout: 480 seconds] 13:00:09 <Eddi|zuHause> that sounds reasonable :p 13:00:30 <frosch123> :) 13:00:44 *** Klanticus [~quassel@179.234.178.216] has quit [Ping timeout: 480 seconds] 13:03:03 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 13:08:02 * peter1138 ponders 13:08:21 <Eddi|zuHause> Pandas sure are cute 13:08:36 * peter1138 ponders RGB recolours. 13:09:02 * liq3 ponders why OpenTTD configure thinks I don't have liblzma 13:09:32 <Eddi|zuHause> because you need lzma2 13:09:42 <Eddi|zuHause> sometimes called xz 13:09:52 <blathijs> win 44 13:09:55 <blathijs> w00ps 13:09:55 <liq3> I installed xz. Still thinks I don't. 13:10:04 <planetmaker> xz >= 5 13:10:12 <Eddi|zuHause> and the -devel package 13:10:14 <planetmaker> or more so, xz-devel 13:10:15 *** Klanticus [~quassel@179.234.178.216] has joined #openttd 13:10:36 <liq3> ah that probably explains it. 13:10:44 <peter1138> apt-get builddep openttd :D 13:10:55 <liq3> Now to figure out how to upgrade ming/msys libraries. :< 13:10:56 <peter1138> build-dep, even. 13:10:59 <liq3> mingw* 13:11:03 <peter1138> oh you're using a silly os 13:11:12 <liq3> I am. Too lazy to install Linux or a VM 13:11:46 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 13:13:24 *** Klanticus_ [~quassel@179.234.178.216] has quit [Ping timeout: 480 seconds] 13:25:06 *** Celestar [~Celestar@p4FC54650.dip0.t-ipconnect.de] has joined #openttd 13:25:34 *** Celestar [~Celestar@p4FC54650.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 13:27:43 <Rubidium> liq3: but... it's more work to get MinGW in a state that is compiled OpenTTD than installing a Linux VM + OpenTTD build-deps 13:27:59 *** Celestar [~Celestar@p4FC54650.dip0.t-ipconnect.de] has joined #openttd 13:28:06 <planetmaker> quite so, yes 13:28:19 <liq3> Rubidium: I've already compiled it. Just LZMA is giving me trouble due to libtools bug. 13:28:42 <Rubidium> oh, Celestar returns ;) 13:28:54 <Rubidium> I was almost thinking he was avoiding me once again... 13:28:55 <Celestar> what? :P 13:29:06 <Celestar> nvidia fucked up their drivers again :/ 13:33:03 <Rubidium> welcome back then ;) 13:37:18 *** kiwibun [~smuxi@p5B37ED34.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 13:39:40 *** kiwibun [~smuxi@p5B37ED34.dip0.t-ipconnect.de] has joined #openttd 13:40:16 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 13:46:46 <liq3> yay fixed it. was missign pkg-config 13:50:51 *** theholyduck [~theholydu@172.245.30.36] has quit [Ping timeout: 480 seconds] 13:51:43 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 13:54:11 *** MTs-iPad [~MTs-iPad@008-086-128-083.dynamic.caiway.nl] has quit [Remote host closed the connection] 13:54:29 *** MTs-iPad [~MTs-iPad@008-086-128-083.dynamic.caiway.nl] has joined #openttd 13:56:15 *** MTsPony [~MTsPony@008-086-128-083.dynamic.caiway.nl] has joined #openttd 14:00:53 *** sla_ro|master [slamaster@95.76.27.245] has joined #openttd 14:03:56 *** shansen [~shansen@212.17.41.140] has joined #openttd 14:07:13 *** Klanticus [~quassel@179.234.178.216] has quit [Remote host closed the connection] 14:08:25 *** Klanticus [~quassel@179.234.178.216] has joined #openttd 14:20:11 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 14:21:33 *** kiwibun [~smuxi@p5B37ED34.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 14:22:53 *** oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has joined #openttd 14:33:22 *** kiwibun [~smuxi@p5B37ED34.dip0.t-ipconnect.de] has joined #openttd 14:37:10 *** InvokeStatic [~Invoke@c-24-11-157-247.hsd1.mi.comcast.net] has joined #openttd 14:44:12 <MTs-iPad> hey does anyone know how the different water color for toyland is created? doesnt seem to be a seperate sprite but more a recoloring of the temperate/artic 14:44:29 <MTs-iPad> (with original tt baseset) 14:45:01 *** Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd 14:45:04 *** mode/#openttd [+o Alberth] by ChanServ 14:45:23 <frosch123> MTs-iPad: different palette colours 14:45:29 <frosch123> check ttdviewer for an interactive demo 14:46:22 <frosch123> same palette indices, but different rgb values 14:46:51 <MTs-iPad> ah kk. i noticed by accident that ttdpatch (fish uk ltd) main menu with tropical background uses the same watercolor from toyland lol 14:47:48 <Eddi|zuHause> in TT, when you had palette animation disabled, you could play on mars with the earth water or on earth with the mars water 14:48:54 <frosch123> so mars was colonized into toyland? 14:59:27 <Alberth> we sent a few kids down there, and they painted the ground in checker board pattern 15:02:00 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 15:04:12 *** Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd 15:06:40 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Quit: Leaving] 15:24:45 *** theholyduck [~theholydu@172.245.30.36] has joined #openttd 15:25:17 *** kiwibun [~smuxi@p5B37ED34.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 15:28:36 *** TheMask96 [martijn@gluttony.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds] 15:28:48 *** Pikka [~Octomom@d58-106-24-83.rdl801.qld.optusnet.com.au] has joined #openttd 15:30:05 *** kiwibun [~smuxi@p5B37ED34.dip0.t-ipconnect.de] has joined #openttd 15:31:13 *** Pensacola [~quassel@h220149.upc-h.chello.nl] has joined #openttd 15:31:41 *** MTs-iPad [~MTs-iPad@008-086-128-083.dynamic.caiway.nl] has quit [Ping timeout: 480 seconds] 15:32:07 *** TheMask96 [martijn@lust.vhost.ne2000.nl] has joined #openttd 15:34:34 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 15:36:32 *** liq3 [~liq3@CPE-120-147-178-81.gdfw1.vic.bigpond.net.au] has quit [] 15:40:58 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 15:41:59 *** MTs-iPad [~MTs-iPad@008-086-128-083.dynamic.caiway.nl] has joined #openttd 15:43:21 *** DanMacK [~androirc@24.114.53.179] has joined #openttd 15:45:22 *** Progman [~progman@p57A18055.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 15:45:57 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Remote host closed the connection] 15:51:37 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 16:01:06 *** DanMacK [~androirc@24.114.53.179] has quit [Ping timeout: 480 seconds] 16:09:38 *** ArdaXi [~ardaxi@do.ardaxi.com] has quit [Quit: leaving] 16:20:06 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 16:23:01 *** Celestar [~Celestar@p4FC54650.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 16:31:23 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 16:42:44 *** MTsPony [~MTsPony@008-086-128-083.dynamic.caiway.nl] has quit [] 16:43:30 *** MTsPony [~MTsPony@008-086-128-083.dynamic.caiway.nl] has joined #openttd 16:56:39 *** glx [~glx@000128ec.user.oftc.net] has joined #openttd 16:56:42 *** mode/#openttd [+v glx] by ChanServ 16:57:43 <Alberth> hmm, no andy 16:58:04 <Alberth> does anyone know what "Foundry tram" means in Road Hog? 16:58:49 <Eddi|zuHause> would andy know the meaning of his names anymore, or did he already outwit himself? :p 16:59:26 <Eddi|zuHause> anyway, happy (wrong) reunification day everyone 16:59:53 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 17:04:00 *** gelignite [~gelignite@i528C3B49.versanet.de] has quit [Quit: http://bit.ly/nkczDT] 17:05:35 <Alberth> he won't know less than me about Foundry trams :) 17:08:15 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 17:13:02 *** kiwibun_ [~smuxi@p5B37EC0A.dip0.t-ipconnect.de] has joined #openttd 17:13:41 <Eddi|zuHause> extrapolating from the HEQS naming, it would be something that's related to the name of the original model 17:14:02 <Eddi|zuHause> or the location where the original operated 17:15:56 *** kiwibun [~smuxi@p5B37ED34.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 17:22:45 <Alberth> ok, guessed a translation, thanks 17:25:06 *** Wolf01 [~wolf01@host156-13-dynamic.20-79-r.retail.telecomitalia.it] has joined #openttd 17:25:35 <Wolf01> hello o/ 17:31:43 <Alberth> evenink :) 17:32:17 <Wolf01> I just installed the right ram on the new pc 17:32:52 <fjb> Moin 17:33:01 <Wolf01> it's like "feel the powwa" 17:33:09 *** Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has joined #openttd 17:33:23 <Alberth> now you can play OpenTTD the way it is supposed to :) 17:33:23 <Wolf01> http://media-live.icintracom.biz/catalog/product/cache/2/image/630x/5e06319eda06f020e43594a9c230972d/5/4/5421d3f76fdc3/Corsair-VENGEANCE-LPX-16GB-DDR4-2666MHZ-Corsair-31.jpg <- four of these weight more than the SSD 17:33:28 <Wolf01> yeah 17:34:11 <fjb> RAM speed shouldn't matter that much. RAM size is important. 17:35:33 <Wolf01> I know, but since my mobo supports DDR4, why not? 17:36:26 <Alberth> it needed a new desktop table, but alas :) 17:39:15 <Eddi|zuHause> i suppose the cooling elements are really heavy 17:40:15 <fjb> RAMs with heatspreaders should be avoided. Their purpose is noct to spread heat, it is to look cool and - most importantly - to disguise how slow the hidden chips really are. 17:40:45 <Eddi|zuHause> well you can just take them off :p 17:41:25 <fjb> But then you are landing on reallity, very hard. 17:41:51 <fjb> And taking them off can be very difficult. 17:42:51 <Pikka> where are you using this computer that you're worried about the weight of the RAM? the ISS? :P 17:46:35 <DorpsGek> Commit by translators :: r26949 /trunk/src/lang (5 files) (2014-10-03 17:46:24 UTC) 17:46:36 <DorpsGek> -Update from WebTranslator v3.0: 17:46:37 <DorpsGek> catalan - 2 changes by juanjo 17:46:38 <DorpsGek> english_US - 5 changes by Supercheese 17:46:39 <DorpsGek> brazilian_portuguese - 19 changes by Tucalipe 17:46:40 <DorpsGek> russian - 3 changes by Lone_Wolf 17:46:42 <DorpsGek> spanish - 2 changes by SilverSurferZzZ 17:52:25 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 17:52:41 <Pikka> uhoh 17:54:25 <Alberth> o/ 18:00:31 *** trendynick [~trendynic@86.127.135.30] has joined #openttd 18:00:53 *** kiwibun_ [~smuxi@p5B37EC0A.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 18:02:41 *** Supercheese [~Superchee@76.178.136.186] has joined #openttd 18:08:59 <andythenorth> o/ 18:09:26 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 18:12:54 <andythenorth> what hap Pikka ? 18:14:11 <Pikka> one loco to go 18:14:19 <Pikka> then I shall send you a grf for opinions (tm) 18:17:06 <frosch123> you can play sv in us english now 18:17:17 <frosch123> if you were interested :p 18:23:39 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 18:23:40 <andythenorth> awesome 18:23:50 <andythenorth> I want silicon inverse ally 18:23:52 <andythenorth> alley * 18:23:56 <andythenorth> silicon dispersed 18:24:07 <andythenorth> have to build multiple clusters 18:24:21 <andythenorth> probably not as good though 18:24:32 <andythenorth> SV makes the routes in one town insane 18:25:20 <frosch123> well, one could concat sv 18:25:48 <frosch123> when you finish one core, you try to impress some girl in a new town 18:26:19 <andythenorth> having had the idea, Iâm not sure itâs a good one :) 18:26:25 <frosch123> once you succeed with the second goal in the second town, you discover that the girl is not impressed at all; and so you decide to try with another in a third town 18:26:30 <andythenorth> SV is the best industry GS though 18:26:37 <frosch123> but, it is not gender neutral that way :) 18:26:54 <frosch123> hmm, ..., can i query company manager gender? 18:27:06 <andythenorth> youâd need to also query orientation 18:27:25 <peter1138> s/girl/love-interest/ 18:27:40 <frosch123> i could make it a query :) 18:27:51 <frosch123> then you can also try to impress a different gender in the next town 18:28:15 <peter1138> Pfft, randomise. It's only a game. 18:28:31 <Supercheese> but what if crazy folks ask for more than three genders? How would the combinations be handled? 18:28:36 <Supercheese> :P 18:31:15 <frosch123> it could pick the second town in an area, which is covered by your junctions :p 18:31:25 <frosch123> so you have to move them all to create space for industries :p 18:31:44 <Supercheese> ouch 18:33:19 <Supercheese> Ehm, trying to translate the tooltips for Exit Signals, but I have never used them 18:33:36 <Supercheese> "Behaves in the same way as a block signal but is necessary to trigger the correct color on entry & combo pre-signals" 18:33:46 *** Pensacola [~quassel@h220149.upc-h.chello.nl] has quit [Remote host closed the connection] 18:33:55 <Supercheese> Soo, if there weren't exit signals, entry/combo signals would not work properly? 18:34:05 <Pikka> "This is a ridiculous signal. Do not use it unless you have been transported back in time to 2005." 18:34:13 <Supercheese> Hah, I like it 18:34:40 <peter1138> :) 18:34:45 <frosch123> Supercheese: exit signals are input operands, entry signals are computed results from input operands 18:34:56 <Pikka> yes, put that 18:35:08 <peter1138> I prefer Pikka's text. 18:35:11 <planetmaker> Supercheese, you can (often) use only combo signals. But entry and exit are nice to separate signal chains 18:35:14 <frosch123> combo signals are both, computed from other inputs (exit or combo), and possible operands to other entry or combo 18:35:27 <Supercheese> This is why I have never used them :| 18:35:29 <andythenorth> just remove them 18:35:35 <andythenorth> translations go away 18:35:37 <andythenorth> eh? 18:35:40 <peter1138> Good idea. They're a BAD FEATURE. 18:35:41 <Supercheese> +1 18:35:58 <Supercheese> I can translate path signals just fine 18:35:59 <andythenorth> we should have a BAD FEATURE quota 18:36:05 <andythenorth> no bad features means no interest 18:36:17 <peter1138> oh fuck 18:36:19 <peter1138> dog farted :( 18:36:24 <andythenorth> grim 18:36:32 <frosch123> Pikka: but Supercheese is doing a latin translation, so it must be "unless you have been transported forward in time to 2005" 18:36:38 <Supercheese> haha 18:39:14 *** Jomann [~abchirk@p57A086B6.dip0.t-ipconnect.de] has joined #openttd 18:48:09 *** Pereba [~UserNick@177.40.221.106] has quit [Ping timeout: 480 seconds] 18:49:48 *** Pereba [~UserNick@179.181.230.110] has joined #openttd 18:49:50 <Supercheese> It's odd that semaphores still are referred to as "green" and "red" 18:50:44 <andythenorth> http://upload.wikimedia.org/wikipedia/commons/1/1b/Sishen-Saldanha_Iron_Ore_Train.jpg 18:50:49 <andythenorth> 342 wagon train 18:51:37 <frosch123> so you are lucky that they built a bridge for the road? instead of a crossing? 18:54:17 <peter1138> Supercheese, technically they can have lights... 18:54:27 <Supercheese> they do not in OTTD though 18:54:49 <Supercheese> not that it's ambiguous, just odd 18:54:56 <frosch123> opengfx bug report? :p 18:55:13 <Supercheese> "red" and "green" have been thoroughly engrained as "stop" and "go" in modern vernacular 18:55:49 <Supercheese> imagine if other colors were chosen... 18:56:28 <Wolf01> lime and purple 18:56:49 <Supercheese> would give entirely new meaning to limelight 18:56:58 <frosch123> some cultures invert shaking head with nodding 18:57:04 <Supercheese> O_o 18:57:21 <planetmaker> yeah... that's so very confusing 18:58:10 <frosch123> "nodding" is listed as "no" for bulgaria, albania, greece and india 18:58:35 <planetmaker> the same culture inverts male and female names ;) 18:58:44 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 18:58:46 <planetmaker> hm, also southern italy, no? 18:59:04 <frosch123> no, idea, i am only quoting wiki 18:59:16 <frosch123> and you can tell the wiki quality be reading texts you know about :p 18:59:41 <planetmaker> :) 19:04:21 <Supercheese> Huh, converting between electric block <-> electric path signals (etc.) costs nothing, but converting between semaphore <-> electric does 19:04:55 <Supercheese> not a bug, I just never noticed 19:05:28 <frosch123> the first thing i did after the addition of semaphores, was setting the intro date to 1492 19:06:01 <Supercheese> didn't TTDPatch first do semaphores? 19:06:04 <frosch123> resp. in ttdp it was just a "no" setting (iirc) 19:06:52 <frosch123> Supercheese: all those weird construction actions which are done with ctrl originate in ttdp :p 19:10:09 <Pikka> andythenorth: I'd forgotten what a PITA articulated vehicles with cargo capacity are :) 19:10:10 *** Celestar [~Celestar@p4FD6E80C.dip0.t-ipconnect.de] has joined #openttd 19:18:18 <andythenorth> they are 19:18:23 <andythenorth> I solved it all with code 19:19:02 <peter1138> smellestar 19:23:31 *** sla_ro|master [slamaster@95.76.27.245] has quit [] 19:24:45 <Pikka> you have a pm andy 19:26:21 <andythenorth> yay 19:26:22 <andythenorth> trainz 19:27:16 <Pikka> 70 trainz 19:27:19 <Pikka> in a fountain 19:27:40 <andythenorth> is it horses compatible? 19:27:44 * andythenorth looks 19:27:54 *** Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has quit [] 19:29:09 <Pikka> "compatible"? 19:29:16 <Pikka> horses are a bit cheaper :) 19:29:31 <Pikka> although this has the same price-halving parameter as 10cc 19:29:42 <andythenorth> nice SP liveries 19:29:46 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 19:29:51 <andythenorth> SF 19:29:53 * andythenorth means 19:30:10 <Pikka> ja 19:30:34 <Pikka> they were on player 3 in the olde nars, so you never saw them unless you played MP with at least 3 companies, or messed around with the parameter :) 19:30:34 <andythenorth> GFC6 is in canset I think 19:31:10 <Pikka> probably. I'm sure Dan has sprites somewhere 19:31:26 <andythenorth> setting company colours to white is best 19:32:30 <peter1138> hurr 19:32:37 <andythenorth> nice that the locos are grouped by mfr 19:32:40 <andythenorth> but also 70? 19:32:43 <andythenorth> :o 19:33:16 <Pikka> americans and their locos 19:33:38 <Pikka> it would have been more if I'd seperated and kept all the generations 19:34:01 <Pikka> I think the F is the only one I've kept two generations of. but it had 4 generations in NARS 19:34:11 <andythenorth> costs arenât far from IH 19:34:14 <Pikka> most of the diesels had two or three 19:34:16 <andythenorth> GP60 ~= Grid 19:35:41 <Pikka> 5 times the running cost though :P 19:38:25 <andythenorth> ha ha 19:38:28 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds] 19:38:30 <andythenorth> my engines are better 19:38:44 <andythenorth> easier to maintain, clearly 19:38:54 <Pikka> obv 19:39:03 <andythenorth> also huzzah 19:39:20 <andythenorth> also no buy menu text \o/ 19:39:29 <Pikka> yesssssssss 19:39:39 <Pikka> does it need it? 19:41:20 <andythenorth> I am -1 to buy menu text 19:41:28 <andythenorth> it breaks my compile :P 19:42:41 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 19:42:42 <planetmaker> P 19:45:09 *** Klanticus [~quassel@179.234.178.216] has quit [Remote host closed the connection] 19:47:46 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 19:51:05 *** FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has joined #openttd 19:53:55 <frosch123> i tried to look into speeding up compile, but ih/fish is too complicated :p 19:54:13 <frosch123> i would have to fetch the intermediate nml and split it up again :p 19:54:52 <frosch123> optimising nml would be fun, but optimising andy's template magic is not :p 19:55:31 <andythenorth> what would you want to split up? 19:55:37 <andythenorth> the templating can be restructured 19:55:41 <andythenorth> kind of the point :) 19:56:43 <frosch123> my "far" goal would be an nml file per vehicle, and "external" references for parameters 19:58:19 <frosch123> the near goal would be inserting cpickle in the main nml loop after each compile step, and trying to eliminate dependencies between items in early processing states 19:59:32 <andythenorth> nml file per vehicle is trivial to template 19:59:58 <andythenorth> in fact 20:00:02 <andythenorth> thatâs what IH is doing 20:01:19 <andythenorth> python -> templating -> nml file per vehicle -> (nmlc) nfo file per vehicle -> link (ugh) -> grfcodec -> grf 20:02:37 <andythenorth> itâs nearly functional, except that nmlc has no way to provide consistent string IDs 20:02:42 <andythenorth> so most text is game-overed 20:05:31 <frosch123> what was the packaging tool for python again? 20:06:07 <andythenorth> there are many 20:06:20 <andythenorth> you want to install something? 20:06:27 <frosch123> never mind 20:06:43 <andythenorth> fwiw, pip for package installation 20:06:54 *** Celestar [~Celestar@p4FD6E80C.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 20:07:09 <frosch123> the standard package manager knows chameleon meanwhile 20:07:11 <Alberth> https://docs.python.org/3/library/distribution.html you may want one that's standard 20:07:35 <Alberth> gn 20:07:50 <andythenorth> bye 20:07:51 <andythenorth> :) 20:08:00 *** Progman [~progman@p57A18055.dip0.t-ipconnect.de] has joined #openttd 20:08:31 *** Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd [] 20:09:53 <andythenorth> Pikka: I am naming things after http://www.aditnow.co.uk/list-uk-mines-quarries/?letter=c 20:09:56 <frosch123> markdown is next :p 20:10:01 <andythenorth> :P 20:10:13 <andythenorth> Pikka: you could have cabbishes 20:10:51 <frosch123> andythenorth: did you hardcode -j 15 somewhere? 20:10:58 <andythenorth> hmm 20:11:10 <andythenorth> you want your CPU back? 20:11:11 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 20:11:17 <frosch123> compiling iron-horse lags my other vms 20:11:24 <andythenorth> hang on 20:11:40 <frosch123> well, now it finished :p 20:11:41 <planetmaker> yes, the thing hard-codes cpu-hogging. I was once also fork-bombed by andy :P 20:11:55 <andythenorth> make install NO_MP=True 20:12:07 <andythenorth> I thought I defaulted it to True 20:12:08 <planetmaker> it should be NO_MP by default 20:12:20 <planetmaker> dunno what's default now, though 20:12:25 * andythenorth looks 20:13:03 <andythenorth> maybe it should also pick up the -j flag from make and pass it to python :P 20:13:10 <andythenorth> but first default 20:14:37 <andythenorth> I should rename the flag to USE_MP 20:16:13 *** trendynick [~trendynic@86.127.135.30] has quit [Ping timeout: 480 seconds] 20:18:42 *** theholyduck [~theholydu@172.245.30.36] has quit [Ping timeout: 480 seconds] 20:20:59 <andythenorth> pushed revised default 20:25:36 *** luaduck_zzz is now known as luaduck 20:30:06 *** theholyduck [~theholydu@172.245.30.36] has joined #openttd 20:31:16 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 20:38:54 <andythenorth> hmm 20:39:00 * andythenorth considers Iron Horses 20:39:14 <andythenorth> release 3 grfs, only grfid is different 20:40:26 <frosch123> iron-pony, iron-horse, iron-nag ? 20:40:47 <andythenorth> iron-mule 20:40:52 <andythenorth> iron-donkey 20:41:01 *** Yotson [~Yotson@2001:980:6ac8:1:2441:476c:3428:d35c] has quit [Quit: .] 20:41:01 <andythenorth> allows players to use multiple rosters in one game :P 20:41:46 <planetmaker> :-O build 1100 of IH! 20:42:13 <frosch123> how? there are only 910 revisions 20:42:23 <planetmaker> repeat build. probably manually 20:45:13 <andythenorth> hmm, rosters arenât necessarily compatible 20:45:16 <andythenorth> so that was a silly idea 20:45:25 <andythenorth> just the one grf then 20:51:47 *** trendynick [~trendynic@86.127.135.30] has joined #openttd 20:52:26 <Wolf01> isn't drag&drop brush available in map editor? 20:56:32 <Pikka> I don't know, isn't it? 20:58:07 <Wolf01> this game is so overwhelmed by hidden features that I can't understand if there's something or not 20:58:44 <frosch123> there was a series of patches for that, but they never made trunk 20:59:38 <Pikka> time to plan/code wogans. what joy. 20:59:39 <frosch123> http://www.tt-forums.net/viewtopic.php?t=35627 20:59:43 <Wolf01> I just found diagonal dynamite 21:00:12 <Pikka> andy: is a parameter for wogan capacity a good idea? do people not like long trains? 21:00:24 <frosch123> Wolf01: exactly that was the issue back then 21:00:43 <frosch123> ctrl was proposed for diagonal drag, but also for freeform drag :p 21:01:12 *** Jomann [~abchirk@p57A086B6.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 21:03:06 <Wolf01> I see 21:04:32 *** Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Ping timeout: 480 seconds] 21:05:41 *** Extrems [borgs@modemcable204.141-177-173.mc.videotron.ca] has quit [Ping timeout: 480 seconds] 21:12:16 *** gelignite [~gelignite@i528C3B49.versanet.de] has joined #openttd 21:14:34 *** FLHerne [~flh@dsl-217-155-24-22.zen.co.uk] has quit [Quit: There's a real world out here!] 21:18:44 *** Extrems [borgs@modemcable204.141-177-173.mc.videotron.ca] has joined #openttd 21:19:38 *** Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has joined #openttd 21:21:51 <andythenorth> Pikka: wagon capacity parameter is good feature 21:22:00 <andythenorth> all sets need some kind of cheating feature 21:22:09 <Pikka> eh 21:22:16 <Pikka> I've got the half-price parameter for that ;) 21:22:36 <andythenorth> Iron Horse has capacity: puny / marvellous / excessive 21:23:32 <andythenorth> hmm 21:23:46 <andythenorth> âexcessiveâ is actually less than RL in several cases 21:24:12 <peter1138> clearly a BAD FEATURE 21:24:48 <andythenorth> can change it in a running game 21:24:52 <andythenorth> well I can 21:24:54 <andythenorth> you canât 21:25:01 <andythenorth> would mess with AIs eh? 21:26:54 <andythenorth> Pikka: can you just finish up my flat car? https://dev.openttdcoop.org/projects/iron-horse/repository/entry/src/graphics/flat_car_brit_gen_3_template.png 21:26:59 <andythenorth> shading is BAD on the ends 21:27:27 <Pikka> nick all the olde NARS loads and suchlike? 21:28:58 <andythenorth> loads I have 21:29:00 <Pikka> and I know IH has the capacity parameter, that's why I asked :) 21:30:02 <andythenorth> https://c2.staticflickr.com/8/7281/8741628785_67d50135b5_z.jpg 21:30:07 <andythenorth> mine looks not realisms 21:30:25 <Pikka> needs more EZ and rendering 21:34:19 <peter1138> 16x zoom 64bpp 21:35:51 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 21:36:24 <Pikka> animated rivets for maximum realisms 21:36:25 <planetmaker> peter1138, 16x sprites would kill devzone server ;) 21:36:53 <planetmaker> heck, yeti already hit its quota when the automatic cleaning script for old builds didn't work ;) 21:37:23 <peter1138> :) 21:37:47 <planetmaker> it still uses as much space for builds as everything else combined :D 21:37:57 <planetmaker> s/else/other grf builds/ 21:41:56 *** luaduck is now known as luaduck_zzz 21:42:34 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 21:43:39 <andythenorth> will he OOM the game/ 21:43:41 <andythenorth> ? 21:44:16 <planetmaker> probably ;) 21:44:22 <planetmaker> and eventually 21:46:02 <andythenorth> is it bed time? 21:46:41 <planetmaker> in 15 minutes 21:47:04 <planetmaker> probably I won't finish redrawing monorail by then 21:47:19 <andythenorth> well 21:47:22 <andythenorth> maybe tomorrow 21:47:28 <andythenorth> also bye ;) 21:47:30 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 21:47:33 <planetmaker> maybe Sunday, but not tomorrow. Bye 22:15:14 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Remote host closed the connection] 22:17:21 *** gelignite [~gelignite@i528C3B49.versanet.de] has quit [Quit: http://bit.ly/nkczDT] 22:19:03 *** Defaultti [defaultti@lakka.kapsi.fi] has quit [Quit: Quitting.] 22:20:51 *** Defaultti [defaultti@lakka.kapsi.fi] has joined #openttd 22:28:41 <Wolf01> 'night 22:28:51 *** Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.] 22:37:02 *** Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd 22:38:42 <frosch123> night 22:38:45 *** frosch123 [~frosch@frnk-4d01df20.pool.mediaWays.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn] 22:59:15 *** HerzogDeXtEr [~flex@88.130.185.16] has quit [Read error: Connection reset by peer] 23:00:42 *** HerzogDeXtEr [~flex@88.130.185.16] has joined #openttd 23:02:51 *** trendynick [~trendynic@86.127.135.30] has quit [Remote host closed the connection] 23:03:21 *** Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has quit [] 23:08:02 *** [1]BB [~Bungee@cpc16-tilb8-2-0-cust158.20-1.cable.virginm.net] has joined #openttd 23:08:32 <[1]BB> Testing IRC... 23:08:41 <[1]BB> 1, 2, 1, 2... 23:09:44 <[1]BB> Hello? 23:10:43 <[1]BB> Test 23:11:17 *** [1]BB [~Bungee@cpc16-tilb8-2-0-cust158.20-1.cable.virginm.net] has left #openttd [] 23:14:28 *** shansen [~shansen@212.17.41.140] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzzâŠ] 23:14:51 *** fjb is now known as Guest423 23:14:53 *** fjb [~frank@000158aa.user.oftc.net] has joined #openttd 23:21:42 *** Guest423 [~frank@000158aa.user.oftc.net] has quit [Ping timeout: 480 seconds] 23:30:54 *** TomyLobo [~foo@91.65.115.103] has quit [Quit: Standby mode...] 23:39:30 *** Jinassi [~Jinassi@0001ec72.user.oftc.net] has left #openttd [] 23:44:58 <Eddi|zuHause> test failed... 23:46:42 <peter1138> So you (or rather, V453000) spend ages making 32bpp graphics, and then people want 8bpp instead... 23:53:00 *** kiwibun [~smuxi@p5B37EC0A.dip0.t-ipconnect.de] has joined #openttd 23:57:23 *** ToBeFree [ToBeFree@00019d36.user.oftc.net] has quit [Quit: Ping timeout: 1337 seconds]