Log for #openttd on 3rd October 2014:
Times are UTC Toggle Colours
00:05:27  *** TomyLobo [~foo@] has quit [Quit: Standby mode...]
00:09:30  *** Hazzard [] has joined #openttd
00:16:16  *** Hazzard_ [] has quit [Ping timeout: 480 seconds]
00:26:37  *** DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
00:27:22  *** Myhorta [] has quit [Remote host closed the connection]
00:42:53  *** DabuYu [DabuYu@] has joined #openttd
00:52:08  *** SHOTbyGUN [] has joined #openttd
00:58:21  *** Flygon [] has joined #openttd
01:09:06  *** Flygon [] has quit [Ping timeout: 480 seconds]
01:11:21  *** DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
01:15:42  *** Flygon [] has joined #openttd
01:33:14  *** DabuYu [DabuYu@] has joined #openttd
01:39:20  *** liq3 [] has joined #openttd
01:39:24  *** shansen [~shansen@] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz
01:42:02  *** glx [] has quit [Quit: Bye]
02:01:28  *** Pokka [] has joined #openttd
02:02:58  *** Pikka [] has quit [Ping timeout: 480 seconds]
02:09:34  *** DDR [] has joined #openttd
02:20:46  *** liq3 [] has quit []
02:22:16  *** liq3 [] 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_ [] has quit [Read error: Operation timed out]
02:58:11  *** Djohaal [~Djohaal@] has quit [Read error: Connection reset by peer]
03:08:36  *** DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
03:08:41  *** HerzogDeXtEr [] has quit [Quit: Leaving.]
03:09:56  *** Pokka [] has quit [Quit: Leaving]
03:30:16  *** George [~George@] has quit [Ping timeout: 480 seconds]
03:30:21  *** KWKdesign [] has quit [Ping timeout: 480 seconds]
03:30:40  *** George [~George@] has joined #openttd
03:30:59  *** KWKdesign [] has joined #openttd
03:34:44  *** DabuYu [DabuYu@] has joined #openttd
04:12:11  *** Pereba [~UserNick@] has quit [Quit: I'm a happy AdiIRC user! Get it here:]
04:27:59  *** MTsPony [] has quit [Ping timeout: 480 seconds]
04:35:51  *** DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
04:48:44  *** DabuYu [DabuYu@] has joined #openttd
04:56:01  *** Eddi|zuHause [] has quit []
04:56:19  *** Eddi|zuHause [] has joined #openttd
05:03:58  *** Jomann [] has joined #openttd
05:32:42  <__ln__>
05:41:00  *** Hazzard [] 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@] 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 [] 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@] 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 [] has quit [Remote host closed the connection]
06:25:48  *** DabuYu [DabuYu@] 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:
06:30:33  <Supercheese> all the German terms are so fun to say
06:34:38  *** George [~George@] has quit [Ping timeout: 480 seconds]
06:37:21  *** George [~George@] has joined #openttd
06:37:48  *** DabuYu [DabuYu@] has joined #openttd
06:46:11  <planetmaker> he, nice :)
06:47:48  *** Flygon_ [] has joined #openttd
06:54:16  *** Flygon [] has quit [Ping timeout: 480 seconds]
07:01:04  *** Myhorta [] has joined #openttd
07:06:18  *** DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
07:18:53  *** Progman [] has joined #openttd
07:30:52  *** DabuYu [DabuYu@] has joined #openttd
07:33:37  *** kiwibun [] has joined #openttd
07:59:21  *** DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
08:14:31  *** Celestar [] has joined #openttd
08:25:03  *** DabuYu [DabuYu@] has joined #openttd
08:26:54  *** Celestar [] has quit [Quit: Leaving.]
08:57:34  *** DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
09:00:06  *** Myhorta [] has quit [Ping timeout: 480 seconds]
09:00:48  <argoneus> mornink
09:05:31  *** DabuYu [DabuYu@] has joined #openttd
09:06:57  *** gelignite [] 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 [] 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 [] has joined #openttd
09:29:53  *** Eddi|zuHause2 [] has joined #openttd
09:34:01  *** DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
09:34:16  *** Eddi|zuHause [] has quit [Ping timeout: 480 seconds]
09:36:46  *** TomyLobo [~foo@] has joined #openttd
09:41:20  *** DabuYu [DabuYu@] 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 [] has joined #openttd
10:09:46  *** DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
10:19:05  *** DabuYu [DabuYu@] 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>
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> 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 [] 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@] has quit [Ping timeout: 480 seconds]
11:38:21  *** Supercheese [~Superchee@] 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@] 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> 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@] 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> <- 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 [] has quit [Ping timeout: 480 seconds]
12:18:48  *** DabuYu [DabuYu@] 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 [] 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@] 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>
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@] 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@] has quit [Read error: Connection reset by peer]
12:41:22  *** Klanticus [~quassel@] 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@] 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> <- 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@] 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 [] has quit [Ping timeout: 480 seconds]
13:00:09  <Eddi|zuHause> that sounds reasonable :p
13:00:30  <frosch123> :)
13:00:44  *** Klanticus [~quassel@] has quit [Ping timeout: 480 seconds]
13:03:03  *** DabuYu [DabuYu@] 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@] 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@] has joined #openttd
13:13:24  *** Klanticus_ [~quassel@] has quit [Ping timeout: 480 seconds]
13:25:06  *** Celestar [] has joined #openttd
13:25:34  *** Celestar [] 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 [] 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 [] has quit [Remote host closed the connection]
13:39:40  *** kiwibun [] has joined #openttd
13:40:16  *** DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
13:46:46  <liq3> yay fixed it. was missign pkg-config
13:50:51  *** theholyduck [~theholydu@] has quit [Ping timeout: 480 seconds]
13:51:43  *** DabuYu [DabuYu@] has joined #openttd
13:54:11  *** MTs-iPad [] has quit [Remote host closed the connection]
13:54:29  *** MTs-iPad [] has joined #openttd
13:56:15  *** MTsPony [] has joined #openttd
14:00:53  *** sla_ro|master [slamaster@] has joined #openttd
14:03:56  *** shansen [~shansen@] has joined #openttd
14:07:13  *** Klanticus [~quassel@] has quit [Remote host closed the connection]
14:08:25  *** Klanticus [~quassel@] has joined #openttd
14:20:11  *** DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
14:21:33  *** kiwibun [] has quit [Ping timeout: 480 seconds]
14:22:53  *** oskari89 [] has joined #openttd
14:33:22  *** kiwibun [] has joined #openttd
14:37:10  *** InvokeStatic [] 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@] has joined #openttd
15:04:12  *** Hazzard [] has joined #openttd
15:06:40  *** Myhorta [] has quit [Quit: Leaving]
15:24:45  *** theholyduck [~theholydu@] has joined #openttd
15:25:17  *** kiwibun [] has quit [Ping timeout: 480 seconds]
15:28:36  *** TheMask96 [] has quit [Ping timeout: 480 seconds]
15:28:48  *** Pikka [] has joined #openttd
15:30:05  *** kiwibun [] has joined #openttd
15:31:13  *** Pensacola [] has joined #openttd
15:31:41  *** MTs-iPad [] has quit [Ping timeout: 480 seconds]
15:32:07  *** TheMask96 [] has joined #openttd
15:34:34  *** DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
15:36:32  *** liq3 [] has quit []
15:40:58  *** Myhorta [] has joined #openttd
15:41:59  *** MTs-iPad [] has joined #openttd
15:43:21  *** DanMacK [~androirc@] has joined #openttd
15:45:22  *** Progman [] has quit [Remote host closed the connection]
15:45:57  *** Myhorta [] has quit [Remote host closed the connection]
15:51:37  *** DabuYu [DabuYu@] has joined #openttd
16:01:06  *** DanMacK [~androirc@] has quit [Ping timeout: 480 seconds]
16:09:38  *** ArdaXi [] has quit [Quit: leaving]
16:20:06  *** DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
16:23:01  *** Celestar [] has quit [Quit: Leaving.]
16:31:23  *** DabuYu [DabuYu@] has joined #openttd
16:42:44  *** MTsPony [] has quit []
16:43:30  *** MTsPony [] has joined #openttd
16:56:39  *** glx [] 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@] has quit [Ping timeout: 480 seconds]
17:04:00  *** gelignite [] has quit [Quit:]
17:05:35  <Alberth> he won't know less than me about Foundry trams :)
17:08:15  *** DabuYu [DabuYu@] has joined #openttd
17:13:02  *** kiwibun_ [] 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 [] has quit [Ping timeout: 480 seconds]
17:22:45  <Alberth> ok, guessed a translation, thanks
17:25:06  *** Wolf01 [] 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 [] has joined #openttd
17:33:23  <Alberth> now you can play OpenTTD the way it is supposed to :)
17:33:23  <Wolf01> <- 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 [] has joined #openttd
17:52:41  <Pikka> uhoh
17:54:25  <Alberth> o/
18:00:31  *** trendynick [~trendynic@] has joined #openttd
18:00:53  *** kiwibun_ [] has quit [Ping timeout: 480 seconds]
18:02:41  *** Supercheese [~Superchee@] has joined #openttd
18:08:59  <andythenorth> o/
18:09:26  *** DabuYu [DabuYu@] 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@] 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 [] 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 [] has joined #openttd
18:48:09  *** Pereba [~UserNick@] has quit [Ping timeout: 480 seconds]
18:49:48  *** Pereba [~UserNick@] has joined #openttd
18:49:50  <Supercheese> It's odd that semaphores still are referred to as "green" and "red"
18:50:44  <andythenorth>
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 [] 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 [] 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@] 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 [] 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@] 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 [] 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@] has joined #openttd
19:42:42  <planetmaker> P
19:45:09  *** Klanticus [~quassel@] has quit [Remote host closed the connection]
19:47:46  *** Myhorta [] has joined #openttd
19:51:05  *** FLHerne [] 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 [] has quit [Quit: Leaving.]
20:07:09  <frosch123> the standard package manager knows chameleon meanwhile
20:07:11  <Alberth>    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 [] 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
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@] 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@] has quit [Ping timeout: 480 seconds]
20:18:42  *** theholyduck [~theholydu@] 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@] has joined #openttd
20:31:16  *** DabuYu [DabuYu@] 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@] 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>
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 [] has quit [Remote host closed the connection]
21:03:06  <Wolf01> I see
21:04:32  *** Hazzard [] has quit [Ping timeout: 480 seconds]
21:05:41  *** Extrems [] has quit [Ping timeout: 480 seconds]
21:12:16  *** gelignite [] has joined #openttd
21:14:34  *** FLHerne [] has quit [Quit: There's a real world out here!]
21:18:44  *** Extrems [] has joined #openttd
21:19:38  *** Brumi [] 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?
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>
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@] 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@] 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 [] has quit [Quit: andythenorth]
21:47:33  <planetmaker> maybe Sunday, but not tomorrow. Bye
22:15:14  *** Myhorta [] has quit [Remote host closed the connection]
22:17:21  *** gelignite [] has quit [Quit:]
22:19:03  *** Defaultti [] has quit [Quit: Quitting.]
22:20:51  *** Defaultti [] has joined #openttd
22:28:41  <Wolf01> 'night
22:28:51  *** Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
22:37:02  *** Hazzard [] has joined #openttd
22:38:42  <frosch123> night
22:38:45  *** frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
22:59:15  *** HerzogDeXtEr [~flex@] has quit [Read error: Connection reset by peer]
23:00:42  *** HerzogDeXtEr [~flex@] has joined #openttd
23:02:51  *** trendynick [~trendynic@] has quit [Remote host closed the connection]
23:03:21  *** Brumi [] has quit []
23:08:02  *** [1]BB [] 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 [] has left #openttd []
23:14:28  *** shansen [~shansen@] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz
23:14:51  *** fjb is now known as Guest423
23:14:53  *** fjb [] has joined #openttd
23:21:42  *** Guest423 [] has quit [Ping timeout: 480 seconds]
23:30:54  *** TomyLobo [~foo@] has quit [Quit: Standby mode...]
23:39:30  *** Jinassi [] 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 [] has joined #openttd
23:57:23  *** ToBeFree [] has quit [Quit: Ping timeout: 1337 seconds]

Powered by YARRSTE version: svn-trunk