IRC logs for #openttd on OFTC at 2014-10-03
⏴ go to previous day
00:09:30 *** Hazzard has joined #openttd
00:52:08 *** SHOTbyGUN 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.
03:30:59 *** KWKdesign has joined #openttd
04:56:19 *** Eddi|zuHause has joined #openttd
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: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:57:06 <liq3> Rubidium: I've been poking around the code... Any hints where OpenTTD does depth sorting?
06:07:39 *** theholyduck has joined #openttd
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:18:41 <liq3> OpenGL can use all the current sprites just fine...
06:30:33 <Supercheese> all the German terms are so fun to say
06:47:48 *** Flygon_ has joined #openttd
07:01:04 *** Myhorta has joined #openttd
07:18:53 *** Progman has joined #openttd
07:33:37 *** kiwibun has joined #openttd
08:14:31 *** Celestar has joined #openttd
09:06:57 *** gelignite has joined #openttd
09:12:13 <NGC3982> I'm trying to locally use my server
09:12:19 <NGC3982> I have like a minute of latency over wifi
09:15:11 <liq3> you connected locally right?
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:21:41 *** Jinassi has joined #openttd
09:29:53 *** Eddi|zuHause2 has joined #openttd
09:36:46 *** TomyLobo has joined #openttd
09:48:02 *** sla_ro|laptop 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: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:59 <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:37 <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:39 <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:16 <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:27 <peter1138> Back in 2008 it was still easier to use the now-deprecated paletted texture extension.
10:56:45 <liq3> peter1138: I'd tell you what the difference is, but I'm still trying to figure out the gfx code :<
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:10 <peter1138> partial scene drawing HAS been done with opengl
11:01:48 <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:53 <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:14 <liq3> Well, anyone with a computer from the past 10 years can probably run OpenGL with better performance than the current blitters.
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:23 <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:11:44 <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 has joined #openttd
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: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: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:53 <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:23 <liq3> CPUs are REALLY SLOW at handling graphics compared to GPUs.
11:50:50 <frosch123> gpu are fast at very specific tasks
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:41 <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: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:58 <liq3> Checking what's in the view point is extremely simple and fast. :/
11:57:09 <liq3> Especially since it's just quads.
11:57:11 <planetmaker> it's not *what*. But *how*
11:57:20 <frosch123> liq3: how do you draw a station?
11:57:36 <liq3> How do I draw a station, or OpenTTD?
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: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 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:59 <frosch123> when zooming out the number pixels stays the same
12:02:03 <frosch123> but the number of tiles increases
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:04:11 <frosch123> liq3: for depth sorting you need sprites with depth information
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:30 <liq3> since you just pass the Z coord of the sprite and OpenGL handles it.
12:05:39 <frosch123> being able to use zbuffers has preconditions
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:45 <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:44 <peter1138> Is this still going on? :-)
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:34 <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:10:59 <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:56 <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:48 <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:03 <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: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: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: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:43 <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:30 <liq3> you're still using basic hardware acceleration afaik.
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 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: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: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: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: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: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:30:08 <liq3> Btw, there any resources to explain the gfx code? stuff is confusing.
12:30:19 <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:20 <Eddi|zuHause> yay, finally we go back to off-topic :p
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: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: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:41:22 *** Klanticus has joined #openttd
12:41:28 <Eddi|zuHause> is there a translation for "Gulaschkanone"?
12:42:04 <Eddi|zuHause> to any language, really :()
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:05 <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:31 <Eddi|zuHause> like you're more likely to find a Döner in berlin than in istanbul
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: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_ 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 ;)
13:00:09 <Eddi|zuHause> that sounds reasonable :p
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:55 <liq3> I installed xz. Still thinks I don't.
13:10:12 <Eddi|zuHause> and the -devel package
13:10:14 <planetmaker> or more so, xz-devel
13:10:15 *** Klanticus has joined #openttd
13:10:36 <liq3> ah that probably explains it.
13:10:43 <peter1138> apt-get builddep openttd :D
13:10:55 <liq3> Now to figure out how to upgrade ming/msys libraries. :<
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:25:06 *** Celestar has joined #openttd
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:19 <liq3> Rubidium: I've already compiled it. Just LZMA is giving me trouble due to libtools bug.
13:28:43 <Rubidium> oh, Celestar returns ;)
13:28:54 <Rubidium> I was almost thinking he was avoiding me once again...
13:29:06 <Celestar> nvidia fucked up their drivers again :/
13:33:03 <Rubidium> welcome back then ;)
13:39:40 *** kiwibun has joined #openttd
13:46:46 <liq3> yay fixed it. was missign pkg-config
13:54:29 *** MTs-iPad has joined #openttd
13:56:15 *** MTsPony has joined #openttd
14:00:53 *** sla_ro|master has joined #openttd
14:03:56 *** shansen has joined #openttd
14:08:25 *** Klanticus has joined #openttd
14:22:53 *** oskari89 has joined #openttd
14:33:22 *** kiwibun has joined #openttd
14:37:11 *** 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 has joined #openttd
14:45:01 *** ChanServ sets mode: +o Alberth
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:49 <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:26 <Alberth> we sent a few kids down there, and they painted the ground in checker board pattern
15:04:12 *** Hazzard has joined #openttd
15:24:45 *** theholyduck has joined #openttd
15:30:05 *** kiwibun has joined #openttd
15:31:13 *** Pensacola has joined #openttd
15:32:07 *** TheMask96 has joined #openttd
15:40:58 *** Myhorta has joined #openttd
15:41:59 *** MTs-iPad has joined #openttd
15:43:21 *** DanMacK has joined #openttd
16:43:30 *** MTsPony has joined #openttd
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
17:05:35 <Alberth> he won't know less than me about Foundry trams :)
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:22:44 <Alberth> ok, guessed a translation, thanks
17:32:17 <Wolf01> I just installed the right ram on the new pc
17:33:01 <Wolf01> it's like "feel the powwa"
17:33:23 <Alberth> now you can play OpenTTD the way it is supposed to :)
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:50 <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:41 <DorpsGek> spanish - 2 changes by SilverSurferZzZ
17:52:25 *** andythenorth has joined #openttd
18:00:31 *** trendynick has joined #openttd
18:02:41 *** Supercheese has joined #openttd
18:12:54 <andythenorth> what hap Pikka ?
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:50 <andythenorth> I want silicon inverse ally
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:53 <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: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: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:55 <Supercheese> Soo, if there weren't exit signals, entry/combo signals would not work properly?
18:34:04 <Pikka> "This is a ridiculous signal. Do not use it unless you have been transported back in time to 2005."
18:34:45 <frosch123> Supercheese: exit signals are input operands, entry signals are computed results from input operands
18:35:07 <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:40 <peter1138> Good idea. They're a BAD FEATURE.
18:35:59 <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: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:49:50 <Supercheese> It's odd that semaphores still are referred to as "green" and "red"
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:49 <Supercheese> would give entirely new meaning to limelight
18:56:58 <frosch123> some cultures invert shaking head with nodding
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
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:51 <frosch123> Supercheese: all those weird construction actions which are done with ctrl originate in ttdp :p
19:10:08 <Pikka> andythenorth: I'd forgotten what a PITA articulated vehicles with cargo capacity are :)
19:10:09 *** Celestar has joined #openttd
19:18:23 <andythenorth> I solved it all with code
19:27:40 <andythenorth> is it horses 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:30:33 <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:33 <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:37 <andythenorth> nice that the locos are grouped by mfr
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:35:41 <Pikka> 5 times the running cost though :P
19:38:29 <andythenorth> my engines are better
19:38:44 <andythenorth> easier to maintain, clearly
19:39:19 <andythenorth> also no buy menu text \o/
19:41:20 <andythenorth> I am -1 to buy menu text
19:41:28 <andythenorth> it breaks my compile :P
19:47:46 *** Myhorta has joined #openttd
19:51:04 *** 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:12 <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
20:00:01 <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:36 <andythenorth> it’s nearly functional, except that nmlc has no way to provide consistent string IDs
20:02:41 <andythenorth> so most text is game-overed
20:05:31 <frosch123> what was the packaging tool for python again?
20:06:20 <andythenorth> you want to install something?
20:06:43 <andythenorth> fwiw, pip for package installation
20:07:09 <frosch123> the standard package manager knows chameleon meanwhile
20:08:00 *** Progman has joined #openttd
20:09:56 <frosch123> markdown is next :p
20:10:13 <andythenorth> Pikka: you could have cabbishes
20:10:51 <frosch123> andythenorth: did you hardcode -j 15 somewhere?
20:11:10 <andythenorth> you want your CPU back?
20:11:16 <frosch123> compiling iron-horse lags my other vms
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:19 <planetmaker> dunno what's default now, though
20:13:02 <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:36 <andythenorth> I should rename the flag to USE_MP
20:20:59 <andythenorth> pushed revised default
20:25:36 *** luaduck_zzz is now known as luaduck
20:30:06 *** theholyduck has joined #openttd
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: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:24 <andythenorth> just the one grf then
20:51:47 *** trendynick 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:43 <Wolf01> I just found diagonal dynamite
21:00:11 <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:12:16 *** gelignite has joined #openttd
21:18:44 *** Extrems 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:16 <Pikka> I've got the half-price parameter for that ;)
21:22:36 <andythenorth> Iron Horse has capacity: puny / marvellous / excessive
21:23:46 <andythenorth> ‘excessive’ is actually less than RL in several cases
21:24:11 <peter1138> clearly a BAD FEATURE
21:24:48 <andythenorth> can change it in a running game
21:25:01 <andythenorth> would mess with AIs eh?
21:26:59 <andythenorth> shading is BAD on the ends
21:27:26 <Pikka> nick all the olde NARS loads and suchlike?
21:29:00 <Pikka> and I know IH has the capacity parameter, that's why I asked :)
21:30:07 <andythenorth> mine looks not realisms
21:30:25 <Pikka> needs more EZ and rendering
21:36:24 <Pikka> animated rivets for maximum realisms
21:36:24 <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:47 <planetmaker> it still uses as much space for builds as everything else combined :D
21:37:56 <planetmaker> s/else/other grf builds/
21:41:56 *** luaduck is now known as luaduck_zzz
21:43:39 <andythenorth> will he OOM the game/
21:47:04 <planetmaker> probably I won't finish redrawing monorail by then
21:47:33 <planetmaker> maybe Sunday, but not tomorrow. Bye
22:20:51 *** Defaultti has joined #openttd
22:37:02 *** Hazzard has joined #openttd
23:00:42 *** HerzogDeXtEr has joined #openttd
23:14:51 *** fjb is now known as Guest423
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
continue to next day ⏵
