Back to Home / #openttd / 2014 / 10 / Prev Day | Next Day
#openttd IRC Logs for 2014-10-03

---Logopened Fri Oct 03 00:00:36 2014
00:12-!-Pereba [~UserNick@] has quit [Quit: I'm a happy AdiIRC user! Get it here:]
00:27-!-MTsPony [] has quit [Ping timeout: 480 seconds]
00:35-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
00:48-!-DabuYu [DabuYu@] has joined #openttd
00:56-!-Eddi|zuHause [] has quit []
00:56-!-Eddi|zuHause [] has joined #openttd
01:03-!-Jomann [] has joined #openttd
01:41-!-Hazzard [] has quit [Read error: Connection reset by peer]
01:49<@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
01:50<liq3>Rubidium: I'm not thinking of 3d OGL at all, just 2d OGL.
01:51<@Rubidium>oh, and isn't there a limit on the number of sprites you can keep "in memory" for GL?
01:51<liq3>Don't know.
01:51-!-theholyduck [~theholydu@] has quit [Ping timeout: 480 seconds]
01:51<@Rubidium>AFAIK you were fairly likely to hit that limit rather soon
01:52<@Rubidium>unless you were starting to do all kinds of tricky stuff merging sprites into one "sprite" and using some cropping methods
01:52<liq3>I was thinking of just textured surfaces.
01:56-!-DDR [] has quit [Ping timeout: 480 seconds]
01:57<liq3>Rubidium: I've been poking around the code... Any hints where OpenTTD does depth sorting?
02:07-!-theholyduck [~theholydu@] has joined #openttd
02:15<@planetmaker>the base game has over 6000 sprites. If you play with NewGRFs you easily have several 10k sprites
02:16<liq3>You don't need to use point sprites. Textured quads would work fine.
02:16<@planetmaker>yes, we can write another game, indeed
02:16<@planetmaker>and throw away all graphics which we have
02:18<liq3>OpenGL can use all the current sprites just fine...
02:20-!-Jomann [] has quit [Remote host closed the connection]
02:25-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
02:27<Supercheese>Jeez, this is one heck of a specific dictionary of terms, and in 6 languages no less:
02:30<Supercheese>all the German terms are so fun to say
02:34-!-George [~George@] has quit [Ping timeout: 480 seconds]
02:37-!-George [~George@] has joined #openttd
02:37-!-DabuYu [DabuYu@] has joined #openttd
02:46<@planetmaker>he, nice :)
02:47-!-Flygon_ [] has joined #openttd
02:54-!-Flygon [] has quit [Ping timeout: 480 seconds]
03:01-!-Myhorta [] has joined #openttd
03:06-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
03:18-!-Progman [] has joined #openttd
03:30-!-DabuYu [DabuYu@] has joined #openttd
03:33-!-kiwibun [] has joined #openttd
03:59-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
04:14-!-Celestar [] has joined #openttd
04:25-!-DabuYu [DabuYu@] has joined #openttd
04:26-!-Celestar [] has quit [Quit: Leaving.]
04:57-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
05:00-!-Myhorta [] has quit [Ping timeout: 480 seconds]
05:05-!-DabuYu [DabuYu@] has joined #openttd
05:06-!-gelignite [] has joined #openttd
05:12<NGC3982>Bah, i don't get it
05:12<NGC3982>I'm trying to locally use my server
05:12<NGC3982>I have like a minute of latency over wifi
05:15<liq3>you connected locally right?
05:17<NGC3982>It's something with OpenTTD and my wifi
05:17<NGC3982>Using wired or something else works great
05:17-!-frosch123 [] has joined #openttd
05:17<NGC3982>The thing is, the wifi is not that bad for most other things
05:18<NGC3982>I get roughly 1MB of data transfer speed, and i can't seem to notice any lag while surfing the web.
05:19<frosch123>__ln__ is featured in today's xkcd!
05:21-!-Jinassi [] has joined #openttd
05:29-!-Eddi|zuHause2 [] has joined #openttd
05:34-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
05:34-!-Eddi|zuHause [] has quit [Ping timeout: 480 seconds]
05:36-!-TomyLobo [~foo@] has joined #openttd
05:41-!-DabuYu [DabuYu@] has joined #openttd
05:46-!-Yotson [~Yotson@2001:980:6ac8:1:2441:476c:3428:d35c] has joined #openttd
05:48-!-sla_ro|laptop [] has joined #openttd
06:09-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
06:19-!-DabuYu [DabuYu@] has joined #openttd
06:40<fonsinchen>You can use the OpenGL texture memory as cache for the base texture memory
06:41<fonsinchen>Most of the time you're not using all those 100000 sprites at the same time
06:41<fonsinchen>If I get bored I might take a stab at that ...
06:41<fonsinchen>... so probably never
06:42<argoneus>fonsinchen: you live a happy life
06:42<argoneus>if you are never bored
06:42<@planetmaker>fonsinchen, a usual game might not have all 6000+ sprites form a base set at the same time, but suprisingly many
06:42<@peter1138>I wonder what the difference is between "just an opengl blitter" and "a proper opengl implementation"
06:42<fonsinchen>I'm not so sure. If I was bored more often I might be doing more stuff like that.
06:42<argoneus>I wish I did coding when I was bored
06:43<argoneus>usually I just play starcraft or openttd
06:43<argoneus>(so most of the time)
06:43<fonsinchen>Actually that thing on the forums also includes an OpenGL graphics driver
06:43<@planetmaker>I'll recon a third or half of them are used at any time
06:43<fonsinchen>I did have a look at it recently and it seems like a good starting point for further experiments.
06:44<@peter1138>What thing on the forums?
06:44<@planetmaker>there's an ancient opengl blitter / driver somewhere. 2 years or so, ago?
06:44<@peter1138>only 2 years ago?
06:44<@peter1138>mine is 6 :)
06:45<@planetmaker>:) timporal memory is fuzzy
06:45<fonsinchen>look in the last pages to get the update I did ages ago.
06:45<@peter1138>basically you need to rewrite quite a lot of stuff to get decent performance
06:46<fonsinchen>First you need to get it do all the corner cases of sprite sorting and stuff correctly
06:47<fonsinchen>Then you have to figure out why it's slow on some hardware/software combinations
06:47<fonsinchen>Mind that it was quite a bit faster than the other blitters and graphics drivers on some configurations
06:48<@peter1138>Main problem with mine was when zoomed out.
06:48<@peter1138>Oh and some problem with loading sprites in another thread.
06:48<fonsinchen>The texture memory and its handling of it may indeed have something to do with that ...
06:49<fonsinchen>But even if we ended up with something that performs better on just some identifiable subset of configurations that would already be great.
06:49<@peter1138>Basically the problem is we have no many GetSprite() calls that are only concerned with the size of the sprite
06:50<@peter1138>Some of those get called during landscape generation
06:50<@peter1138>OpenGL didn't grok multiple threads, back then.
06:50-!-Eddi|zuHause2 is now known as Eddi|zuHause
06:50<fonsinchen>It can still have its problems, but there are drivers that handle that quite well by now.
06:50<Eddi|zuHause><Supercheese> all the German terms are so fun to say <- like "Sternschnuppe"?
06:50<@peter1138>At least we should be able to use shaders to do all the colour remapping.
06:51<@peter1138>Back in 2008 it was still easier to use the now-deprecated paletted texture extension.
06:56<liq3>peter1138: I'd tell you what the difference is, but I'm still trying to figure out the gfx code :<
06:57<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.
06:57<liq3>It usually redraws the entire framebuffer every frame.
06:57<@peter1138>Yes. that's what I said the other day.
06:58<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.
06:59<liq3>Also, OpenTTD's gfx code is confusing as hell. :<
06:59<@peter1138>There are ways to make it more opengl-like, but they basically require replacing a good chunk of ottd
07:00<liq3>Yes. Stuff like SetDirty would be completely unnecessary with OpenGL.
07:01<@peter1138>partial scene drawing HAS been done with opengl
07:01<liq3>Yeh I'm sure it has.
07:01<@peter1138>i believe simcity 4 does it
07:01<liq3>Hrm, I mean, I suppose you could setup partial scene redrawing with OpenGL too.
07:02<liq3>Sorry, redrawing the whole scene isn't necessary at all with OpenGL. just how I learned to do it.
07:02<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...
07:03<liq3>Yeh, that's probably what I'd do if I implemented OpenGL.
07:03<liq3>Since you'd want to keep the current blitters for compatibility.... I imagine
07:03<@peter1138>There'd be a lot of people asking for their money back if not.
07:04<@planetmaker>full refund! guaranteed
07:04<Eddi|zuHause>we don't have that kind of money
07:04<liq3>Well, anyone with a computer from the past 10 years can probably run OpenGL with better performance than the current blitters.
07:04<@planetmaker>really. Proof it
07:04<liq3>That'd require me to implement OpenGL. No thanks. :P
07:04<@planetmaker>in openttd operation that is
07:05<@planetmaker>otherwise it's basically only empty words and void claims
07:05<@planetmaker>and quickly getting boring, tbh
07:05<Eddi|zuHause>liq3: does that include android phones and raspberry pis?
07:05<liq3>Eddi|zuHause: I have no idea.
07:05<Eddi|zuHause>then don't throw around that kind of allegations
07:06<Eddi|zuHause>maybe i want to run an openttd server on my fritzbox :p
07:06<Eddi|zuHause>(that's probably going to be horrible :p)
07:08<liq3>Phones don't really count as computers. They have awful GPUs :<
07:09<@peter1138>But ottd runs on them.
07:11<liq3>oh my bad... Wow Phone GPUs are powerful.
07:11<liq3> compared to old GPUs.
07:11<liq3>Based on benchmarks, I imagine yes even phones would be faster. :p
07:13<Eddi|zuHause>under the assumption that you can create an opengl implementation that would be faster in the first place
07:13<liq3>That's a well founded assumption.
07:13<Eddi|zuHause>which i have not even seen a hint of plausibility for
07:13<liq3>What part. That I can implement one or that a proper OpenGL implementation would be faster?
07:13<@peter1138>Judging by your previous statements I don't think you should be assuming anything.
07:14-!-Myhorta [] has joined #openttd
07:14<Eddi|zuHause>either of those
07:14<Eddi|zuHause>not that there can be an implementation, nor that you could actually produce it
07:15<@peter1138>Heh, iPod touch 4th gen has a retina display... but only 24MB video ram.
07:16<@peter1138>256MB ram though, which is plenty for a standard blitter, although i wouldn't like to try 4x zoom.
07:17<@peter1138>But hey, that's 4 years old.
07:22<NGC3982>So.. It would play OpenTTD?
07:22<NGC3982>Or did i just correlate because location.
07:23<Eddi|zuHause>it wouldn't, because there is no app store entry for openttd
07:29-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
07:38-!-Supercheese [~Superchee@] has quit [Ping timeout: 480 seconds]
07:41<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
07:41<frosch123>you need to find an opengl feature which ottd can benefit at least somewhat from
07:42<fonsinchen>That opengl blitter on the forums was faster for certain high-end GPUs of 2008 (?) if you didn't zoom out too much
07:43<fonsinchen>I guess those things can only have gotten better
07:43<Eddi|zuHause>but "zoom out" was the whole cause of the discussion
07:43<frosch123>fonsinchen: but ottd also got better without opengl, we now have a drawing thread
07:43<frosch123>so, whatever you gained with waiting for transfering data, is now gone
07:44<fonsinchen>As I said: I'm pretty sure there is potential for improvement in the OpenGL blitter, too.
07:45<fonsinchen>But, of course it would be a lot of work to figure out the details
07:45<frosch123>anyway, when i think of opengl i think of texture atlases, texture scaling, mipmapping, shaders and zbuffers
07:46<frosch123>shaders would have been nice for palette animation
07:46<fonsinchen>Going forward I guess our model of doing graphics so far will run into more and more problems on more and more devices.
07:46<frosch123>texture atlasses are likely hell of complicated
07:46<fonsinchen>So we should eventually come up with something
07:46<frosch123>i do not see how openttd could ever use texture scaling, mipmapping and zbuffers
07:46<fonsinchen>sure, it isn't trivial. But you don't have to use all opengl features from the start
07:48<frosch123>maybe, but i actually think you will gain a lot more by utilizing more cpu cores than the gpu
07:49<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
07: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
07:50<frosch123>but you can also do that with the cpu, which i beleive fits ottd a lot better
07:50-!-DabuYu [DabuYu@] has joined #openttd
07:50<liq3>CPUs are REALLY SLOW at handling graphics compared to GPUs.
07:50<frosch123>liq3: wrong
07:50<frosch123>gpu are fast at very specific tasks
07:50<liq3> graphics.
07:51<frosch123>and i doubt ottd graphics are part of that
07:51<frosch123>anything that derivates from the standard gpu flow, is way slower
07:52<frosch123>gpu algorithms are trivial compared to what cpus can do
07:52<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
07:52<liq3>Yes. Because graphics is mostly just huge amounts of 'trivial' math, which CPUs are bad at and GPUs are designed for.
07:52<frosch123>driving the parallelisation into non-sense
07:53<@planetmaker>liq3, openttd graphics are not just 'trivial maths'. they require lookup on the map array and state of the objects
07:53<@planetmaker>otherwise you can't decide what to draw
07:53<liq3>openttd graphics are extremely simple compared to like Starcraft 2.... :<
07:54<frosch123>liq3: exactly, that's why gpu give no benefit
07:54<frosch123>you can only safe time, if there is time in the processing
07:54<frosch123>ottd will fail to utilizie gpu exactly because the graphics are so simple
07:55<liq3>And yet the graphics still manage to lag modern CPUs.
07:55<@planetmaker>no... the game does. not the graphics
07:55<liq3>it lags more when I zoom out. it's the gfx.
07:55<frosch123>none of the processings that are perfomed fast by gpu, are used by gpu
07:55<liq3>Well, it's both. Zooming out increases the gfx, and gives less time to the game logic.
07:56<frosch123>liq3: again wrong
07:56<frosch123>it's not the graphics that lag
07:56<frosch123>it's the loop-up in the game state and deciding what to draw
07:56<frosch123>which will never be done on the gpu
07:56<frosch123>it can be parallelized in theory, but requires restructing in the newgrf processor
07:56<liq3>Checking what's in the view point is extremely simple and fast. :/
07:57<liq3>view port*.
07:57<frosch123>liq3: again wrong
07:57<liq3>Especially since it's just quads.
07:57<@planetmaker>it's not *what*. But *how*
07:57<frosch123>liq3: how do you draw a station?
07:57<liq3>How do I draw a station, or OpenTTD?
07:57<@planetmaker>or a train?
07:58<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
07:58<frosch123>it's the same for all tiles
07:58<frosch123>a tile is no single fixed sprite
07:58<frosch123>it's a sequence of sprites, which first needs to be determined
07:58<liq3>ugh procedural programming. >.>
07:58<frosch123>the drawing is a piece of cake afterwards
07:59<liq3>frosch123: that's still incredibly simple.
07:59<liq3>you know, for a CPU
07:59<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
08:00-!-HerzogDeXtEr [~flex@] has joined #openttd
08:01<frosch123>whatever, as said before: gpus are good to draw starcraft-style graphics
08:01<liq3>frosch123: the method you described is just a series of if statements. It's really fast for a CPU.
08:01<frosch123>but that has nothing to do with openttd
08:01<liq3>Slow part is doing ANY sort of pixel manipulation.
08:01<frosch123>liq3: again wrong
08:01<frosch123>when zooming out the number pixels stays the same
08:02<frosch123>but the number of tiles increases
08:02<frosch123>yeah, guess what, when you zoom out your monitor does not change its size
08:02<liq3>what are you even mentioning pixels?
08:02<frosch123>you started with pixels
08:03<liq3>I'm saying any sort of image manipulation is slow for a CPU.
08:03<frosch123>the number of pixels to process it the same on every zoom level
08:03<frosch123>but the number of sprites and tiles changes
08:03<@planetmaker>it really starts to develop certain traits of popcorn discussions
08:03<liq3>That's not what I'm refering to. I mean things like depth sorting and scaling.
08:04<frosch123>liq3: for depth sorting you need sprites with depth information
08:04<frosch123>which do not exist
08:04<liq3>The only thing zooming out should change is what the game logic asks the renderer to draw.
08:04<frosch123>as i mentioned earlier: zbuffers are on the list of things i doubt will ever work for ottd
08:04<liq3>and the renderer should do be doing NO image manipulation on the CPU, it should be doing it all the GPU.
08:04<@planetmaker>liq3, and that's the only thing which changes: the amount of tiles which need querying
08:04<frosch123>liq3: yeah, and guess what part in that takes so long?
08:05<liq3>if OTTD used OpenGL, z buffers would work fine.
08:05<liq3>since you just pass the Z coord of the sprite and OpenGL handles it.
08:05<frosch123>being able to use zbuffers has preconditions
08:05<frosch123>you need a z value for your sprite
08:05<frosch123>or even within the sprite
08:05<frosch123>but those do not exist
08:06<liq3>yes the game logic has to figure out what z is.
08:06<frosch123>great, so you saved nothing
08:06<liq3>considering it's an isometric tile based game I can't imagine that's too hard.
08:06<Eddi|zuHause>that's what the blitter does
08:06<frosch123>if the gamelogic has to figure out the z position, it can just draw the sprites in that order
08:06<frosch123>no usage of opengl at all
08:07<liq3>"can just draw the sprites in that order" *shudders*
08:07<frosch123>liq3: again wrong, sprite sorting is a non-well defined thing
08:07<frosch123>there is proper algorithm for sprite sorting, because it is no proper problem in the first place
08:07<Eddi|zuHause>the sprite sorter has so many errors, it's not funny
08:07<frosch123>*no proper algorithm
08:08<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
08:08<@peter1138>Is this still going on? :-)
08:09<frosch123> <- simple proof that sprite sorting will never work
08:10<fonsinchen>I know that picture, but somehow we succeed in using sse for sprite sorting, right?
08:10<frosch123>which is the reason why modern graphics use zbuffers, but that requires that's the images have z data
08:10<liq3>frosch123: what? You'd give the blue one depth 0, green depth 1, and red gepth 2. OpenGL will draw it correctly.
08:10<frosch123>fonsinchen: yes? but it is still serial, not parallel
08:10<frosch123>liq3: keep on thinking :)
08:10<@planetmaker>liq3, look again ;)
08:10<fonsinchen>It's implicitly parallel as it does vector math. We could try to shoehorn that part into opengl somehow.
08:11<frosch123>fonsinchen: or you could use multiple cpu cores :)
08:11<liq3>I don't know why it's drawn in RGB. It should be BGR
08:11<frosch123>both run into the same parallelisation issues with ottd
08:11<fonsinchen>Yes, but ultimately your GPU will have more cores than your CPU.
08:11<fonsinchen>I'm not saying it's necessarily better, but it might be worth a try
08:12<frosch123>but the gpu has very restrictive memory access
08:12<fonsinchen>I know, but most of the time it has separate memory and runs semi-independent from the CPU
08:12<fonsinchen>so while the GPU is doing the sprite sorting you could do something else on the CPU
08:13<Eddi|zuHause>liq3: you cannot map non-transitive constructs onto a linear scale
08:13<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
08:14<liq3>what are you even trying to accomplish in that pic?
08:14<liq3>can you link the tt thread?
08:14<frosch123>that your "opengl will sort it correctly" is complete non-sense
08:14<frosch123>opengl does not help you at all
08:14<fonsinchen>liq3, openttd has stuff like that, sadly
08:14<liq3>OpenGL will sort it in whatever order you tell it to.
08:14<fonsinchen>You'd need a full 3d model to get that right.
08:14<Eddi|zuHause>but none of these orders will produce this result
08:14<frosch123>exactly, but figureing out the order
08:15<Eddi|zuHause>because it's non-transitive
08:15<liq3>What should be on top?
08:15<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
08:15<Eddi|zuHause>R->G, G->B but not R->B, it's B->R
08:15<frosch123>you only use gpu power if the gpu figures out the order
08:15<liq3>Eddi|zuHause: -> means?
08:16<liq3>so above -> below?
08:16<fonsinchen>Actually we already have problems with that stuff right now. See FS#119
08:16<fonsinchen>In some cases there just is no correct ordering of the sprites
08:16<Eddi|zuHause>yes, somewhat
08:16<@peter1138>CPUs are bad at trivial math? Really?
08:17<Eddi|zuHause>A->B => B must be drawn before A
08:17<liq3>peter1138: yes. They're slow compared to GPUs.
08:17<liq3>maybe "trivial" is the wrong word.
08:17<frosch123>liq3: add 100 numbers, very simple, any cpu will out-perform a gpu
08:18<liq3>frosch123: try drawing OpenTTD purely on CPU >.>
08:18<liq3>you'll be lucky to get 1 FPS
08:18<frosch123>that's what we are doing?
08:18<liq3>not at all
08:18<@planetmaker>we get 30 fps?
08:18<liq3>you're still using basic hardware acceleration afaik.
08:18-!-KWKdesign [] has quit [Ping timeout: 480 seconds]
08:18-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
08:18<liq3>maybe i'm wrong.
08:19<Eddi|zuHause>liq3: yes, and any "advanced" hardware acceleration is optimized for stuff we don't want to do.
08:19-!-KWKdesign [] has joined #openttd
08:19<liq3>it's optimized for all gfx operations, including drawing a few thousand textured quads.
08:19<liq3>since advanced stuff is basically just drawing a few hundred thousand textured quads anyway. It's just more, not more complex really.
08:20<Eddi|zuHause>you probably haven't understood what a GPU actually is...
08:21-!-Klanticus [~quassel@] has joined #openttd
08:21<liq3>It's a processor optimized for doing lots of math instructions.
08:21<liq3>CPUs are optimized for conditionals and such.
08:22<Eddi|zuHause>GPU is optimized for doing lots of PARALLEL instructions
08:22<Eddi|zuHause>CPU is optimized for doing lots of SEQUENTIAL instructions
08:22<frosch123>a gpu is optimised for doing the _same_ operation on a _very_ limited number of input operands, in a vectorial form
08:22<Eddi|zuHause>for any single math operation, the CPU will be faster than the GPU
08:22<liq3>a GPU can execute 800x more instructions per clock cycle, compared to a GPU.
08:23<liq3>GPU 800x more than CPU.
08:23<frosch123>a gpu is good for adding 100 pairs of two numbers, a cpu is good for adding 200 numbers
08:23<Eddi|zuHause>yes, but only if it's THE SAME operation on 800 SIMILAR sets of data
08:23<liq3>Which is what gfx processing is.
08:23<liq3>Huge amounts of math.
08:23<frosch123>not in ottd
08:24<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.
08:24<liq3>on the monitor.
08:24<liq3>when you have actual 3d gfx, it has to transform the 3d space to the monitor too, which is even more math.
08:24<Eddi|zuHause>only sprite-by-sprite, not pixel-by-pixel
08:24<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"
08:24<liq3>no, it does it pixel by pixel. :/
08:25<Eddi|zuHause>it probably does memmove and stuff
08:25<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.
08:25<frosch123>fonsinchen: that would require the gpu to have random access on the intermediate results
08:25<frosch123>which it does not have
08:26<frosch123>i tried to implement fft, but gpus just fail with chains of data dependencies
08:27<frosch123>fast fourier transformation
08:27<fonsinchen>You can fix that by using vectors and shader programs in clever ways, but yes, it's a pain.
08:27<liq3>btw, what forum thread was that red/green/blue pic from?
08:27<frosch123>does not matter, all is said in the picture
08:27<frosch123>the thread is about other stuff from the past
08:28<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
08:29<liq3>lol. It will.
08:30<liq3>Btw, there any resources to explain the gfx code? stuff is confusing.
08:30<@planetmaker>frosch123, there's the fftw, a nice c implementation. Fasted implementation I found, like 4 years ago
08:30<@planetmaker>but ofc totally w/o gpu :)
08:31<Eddi|zuHause>yay, finally we go back to off-topic :p
08:32<@peter1138>Maybe we should raytrace it...
08:32<@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
08:32<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
08:34-!-DabuYu [DabuYu@] has joined #openttd
08:36<Eddi|zuHause>so matrix multiplication => GPU, matrix norm => CPU
08:36<Eddi|zuHause>unless you want to do fancy stuff involving the spectral-norm :)
08:37-!-Klanticus [~quassel@] has quit [Read error: Connection reset by peer]
08:41-!-Klanticus [~quassel@] has joined #openttd
08:41<Eddi|zuHause>is there a translation for "Gulaschkanone"?
08:41<frosch123>to latin?
08:42<Eddi|zuHause>to any language, really :()
08:42<frosch123>leo has one
08:42<Eddi|zuHause>specifically: does this device even exist outside germany?
08:42<frosch123>but maybe not with same intone
08:43<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
08:44<frosch123>or is it because sausages do not contain any actual meat?
08:44<Eddi|zuHause>well, you can get vegetarian soups out of a "Gulaschkanone" :)
08:45<frosch123>anyway, leo says "mobile kitchen" in the civil sense, and "field kitchen" in the military sense
08:45<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
08:46<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
08:47<@planetmaker>frosch123, I thought only eating meat was also South-American habit? (going by our Brazilian restaurant around the corner)
08:47<frosch123>planetmaker: i don't think restaurants are representative
08:47<@planetmaker>doh. You destroy my world view :P
08:47<Eddi|zuHause>planetmaker: there is no reasonable expectation that a "<country name> restaurant" serves dishes even remotely popular in <country name>
08:48-!-Pereba [~UserNick@] has joined #openttd
08:48<Eddi|zuHause>like you're more likely to find a Döner in berlin than in istanbul
08:48<frosch123> <- on that table, germany is in position 21
08:50<frosch123>funnily there is no link to an english version of that page
08:50<frosch123>does that mean something? :p
08:50<Eddi|zuHause>yes, it means that the original text was published in german
08:50<Eddi|zuHause>and nobody bothered to translate it
08:51<frosch123>yes, but i meant from a social pov
08:51<frosch123>like germans trying to profe, that they are not eating sausages all day
08:52<Eddi|zuHause>it may also mean that germany has more food-enthusiasts
08:52<Eddi|zuHause>independent of whether they are pro-meat or anti-meat
08:53<frosch123>haha, the text says "japanese eat noticeable few meat", i guess they did not consider fish :p
08:53<__ln__>fish is fish, meat is meat
08:53<frosch123>__ln__: what does wale count int?
08:54<__ln__>a mushroom
08:54<frosch123>ah, sorry, what about whale then?
08:54<Eddi|zuHause># badger, badger, badger, badger, mushroom, mushroom
08:56<__ln__>frosch123: marshmallow
08:57-!-Klanticus_ [~quassel@] has joined #openttd
08:59<@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 ;)
08:59-!-sla_ro|laptop [] has quit [Ping timeout: 480 seconds]
09:00<Eddi|zuHause>that sounds reasonable :p
09:00-!-Klanticus [~quassel@] has quit [Ping timeout: 480 seconds]
09:03-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
09:08*peter1138 ponders
09:08<Eddi|zuHause>Pandas sure are cute
09:08*peter1138 ponders RGB recolours.
09:09*liq3 ponders why OpenTTD configure thinks I don't have liblzma
09:09<Eddi|zuHause>because you need lzma2
09:09<Eddi|zuHause>sometimes called xz
09:09<blathijs>win 44
09:09<liq3>I installed xz. Still thinks I don't.
09:10<@planetmaker>xz >= 5
09:10<Eddi|zuHause>and the -devel package
09:10<@planetmaker>or more so, xz-devel
09:10-!-Klanticus [~quassel@] has joined #openttd
09:10<liq3>ah that probably explains it.
09:10<@peter1138>apt-get builddep openttd :D
09:10<liq3>Now to figure out how to upgrade ming/msys libraries. :<
09:10<@peter1138>build-dep, even.
09:11<@peter1138>oh you're using a silly os
09:11<liq3>I am. Too lazy to install Linux or a VM
09:11-!-DabuYu [DabuYu@] has joined #openttd
09:13-!-Klanticus_ [~quassel@] has quit [Ping timeout: 480 seconds]
09:25-!-Celestar [] has joined #openttd
09:25-!-Celestar [] has quit [Remote host closed the connection]
09:27<@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
09:27-!-Celestar [] has joined #openttd
09:28<@planetmaker>quite so, yes
09:28<liq3>Rubidium: I've already compiled it. Just LZMA is giving me trouble due to libtools bug.
09:28<@Rubidium>oh, Celestar returns ;)
09:28<@Rubidium>I was almost thinking he was avoiding me once again...
09:28<Celestar>what? :P
09:29<Celestar>nvidia fucked up their drivers again :/
09:33<@Rubidium>welcome back then ;)
09:37-!-kiwibun [] has quit [Remote host closed the connection]
09:39-!-kiwibun [] has joined #openttd
09:40-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
09:46<liq3>yay fixed it. was missign pkg-config
09:50-!-theholyduck [~theholydu@] has quit [Ping timeout: 480 seconds]
09:51-!-DabuYu [DabuYu@] has joined #openttd
09:54-!-MTs-iPad [] has quit [Remote host closed the connection]
09:54-!-MTs-iPad [] has joined #openttd
09:56-!-MTsPony [] has joined #openttd
10:00-!-sla_ro|master [slamaster@] has joined #openttd
10:03-!-shansen [~shansen@] has joined #openttd
10:07-!-Klanticus [~quassel@] has quit [Remote host closed the connection]
10:08-!-Klanticus [~quassel@] has joined #openttd
10:20-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
10:21-!-kiwibun [] has quit [Ping timeout: 480 seconds]
10:22-!-oskari89 [] has joined #openttd
10:33-!-kiwibun [] has joined #openttd
10:37-!-InvokeStatic [] has joined #openttd
10:44<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
10:44<MTs-iPad>(with original tt baseset)
10:45-!-Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
10:45-!-mode/#openttd [+o Alberth] by ChanServ
10:45<frosch123>MTs-iPad: different palette colours
10:45<frosch123>check ttdviewer for an interactive demo
10:46<frosch123>same palette indices, but different rgb values
10:46<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
10:47<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
10:48<frosch123>so mars was colonized into toyland?
10:59<@Alberth>we sent a few kids down there, and they painted the ground in checker board pattern
11:02-!-DabuYu [DabuYu@] has joined #openttd
11:04-!-Hazzard [] has joined #openttd
11:06-!-Myhorta [] has quit [Quit: Leaving]
11:24-!-theholyduck [~theholydu@] has joined #openttd
11:25-!-kiwibun [] has quit [Ping timeout: 480 seconds]
11:28-!-TheMask96 [] has quit [Ping timeout: 480 seconds]
11:28-!-Pikka [] has joined #openttd
11:30-!-kiwibun [] has joined #openttd
11:31-!-Pensacola [] has joined #openttd
11:31-!-MTs-iPad [] has quit [Ping timeout: 480 seconds]
11:32-!-TheMask96 [] has joined #openttd
11:34-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
11:36-!-liq3 [] has quit []
11:40-!-Myhorta [] has joined #openttd
11:41-!-MTs-iPad [] has joined #openttd
11:43-!-DanMacK [~androirc@] has joined #openttd
11:45-!-Progman [] has quit [Remote host closed the connection]
11:45-!-Myhorta [] has quit [Remote host closed the connection]
11:51-!-DabuYu [DabuYu@] has joined #openttd
12:01-!-DanMacK [~androirc@] has quit [Ping timeout: 480 seconds]
12:09-!-ArdaXi [] has quit [Quit: leaving]
12:20-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
12:23-!-Celestar [] has quit [Quit: Leaving.]
12:31-!-DabuYu [DabuYu@] has joined #openttd
12:42-!-MTsPony [] has quit []
12:43-!-MTsPony [] has joined #openttd
12:56-!-glx [] has joined #openttd
12:56-!-mode/#openttd [+v glx] by ChanServ
12:57<@Alberth>hmm, no andy
12:58<@Alberth>does anyone know what "Foundry tram" means in Road Hog?
12:58<Eddi|zuHause>would andy know the meaning of his names anymore, or did he already outwit himself? :p
12:59<Eddi|zuHause>anyway, happy (wrong) reunification day everyone
12:59-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
13:04-!-gelignite [] has quit [Quit:]
13:05<@Alberth>he won't know less than me about Foundry trams :)
13:08-!-DabuYu [DabuYu@] has joined #openttd
13:13-!-kiwibun_ [] has joined #openttd
13:13<Eddi|zuHause>extrapolating from the HEQS naming, it would be something that's related to the name of the original model
13:14<Eddi|zuHause>or the location where the original operated
13:15-!-kiwibun [] has quit [Ping timeout: 480 seconds]
13:22<@Alberth>ok, guessed a translation, thanks
13:25-!-Wolf01 [] has joined #openttd
13:25<Wolf01>hello o/
13:31<@Alberth>evenink :)
13:32<Wolf01>I just installed the right ram on the new pc
13:33<Wolf01>it's like "feel the powwa"
13:33-!-Brumi [] has joined #openttd
13:33<@Alberth>now you can play OpenTTD the way it is supposed to :)
13:33<Wolf01> <- four of these weight more than the SSD
13:34<fjb>RAM speed shouldn't matter that much. RAM size is important.
13:35<Wolf01>I know, but since my mobo supports DDR4, why not?
13:36<@Alberth>it needed a new desktop table, but alas :)
13:39<Eddi|zuHause>i suppose the cooling elements are really heavy
13:40<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.
13:40<Eddi|zuHause>well you can just take them off :p
13:41<fjb>But then you are landing on reallity, very hard.
13:41<fjb>And taking them off can be very difficult.
13:42<Pikka>where are you using this computer that you're worried about the weight of the RAM? the ISS? :P
13:46<@DorpsGek>Commit by translators :: r26949 /trunk/src/lang (5 files) (2014-10-03 17:46:24 UTC)
13:46<@DorpsGek>-Update from WebTranslator v3.0:
13:46<@DorpsGek>catalan - 2 changes by juanjo
13:46<@DorpsGek>english_US - 5 changes by Supercheese
13:46<@DorpsGek>brazilian_portuguese - 19 changes by Tucalipe
13:46<@DorpsGek>russian - 3 changes by Lone_Wolf
13:46<@DorpsGek>spanish - 2 changes by SilverSurferZzZ
13:52-!-andythenorth [] has joined #openttd
14:00-!-trendynick [~trendynic@] has joined #openttd
14:00-!-kiwibun_ [] has quit [Ping timeout: 480 seconds]
14:02-!-Supercheese [~Superchee@] has joined #openttd
14:09-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
14:12<andythenorth>what hap Pikka ?
14:14<Pikka>one loco to go
14:14<Pikka>then I shall send you a grf for opinions (tm)
14:17<frosch123>you can play sv in us english now
14:17<frosch123>if you were interested :p
14:23-!-DabuYu [DabuYu@] has joined #openttd
14:23<andythenorth>I want silicon inverse ally
14:23<andythenorth>alley *
14:23<andythenorth>silicon dispersed
14:24<andythenorth>have to build multiple clusters
14:24<andythenorth>probably not as good though
14:24<andythenorth>SV makes the routes in one town insane
14:25<frosch123>well, one could concat sv
14:25<frosch123>when you finish one core, you try to impress some girl in a new town
14:26<andythenorth>having had the idea, I’m not sure it’s a good one :)
14:26<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
14:26<andythenorth>SV is the best industry GS though
14:26<frosch123>but, it is not gender neutral that way :)
14:26<frosch123>hmm, ..., can i query company manager gender?
14:27<andythenorth>you’d need to also query orientation
14:27<frosch123>i could make it a query :)
14:27<frosch123>then you can also try to impress a different gender in the next town
14:28<@peter1138>Pfft, randomise. It's only a game.
14:28<Supercheese>but what if crazy folks ask for more than three genders? How would the combinations be handled?
14:31<frosch123>it could pick the second town in an area, which is covered by your junctions :p
14:31<frosch123>so you have to move them all to create space for industries :p
14:33<Supercheese>Ehm, trying to translate the tooltips for Exit Signals, but I have never used them
14:33<Supercheese>"Behaves in the same way as a block signal but is necessary to trigger the correct color on entry & combo pre-signals"
14:33-!-Pensacola [] has quit [Remote host closed the connection]
14:33<Supercheese>Soo, if there weren't exit signals, entry/combo signals would not work properly?
14:34<Pikka>"This is a ridiculous signal. Do not use it unless you have been transported back in time to 2005."
14:34<Supercheese>Hah, I like it
14:34<frosch123>Supercheese: exit signals are input operands, entry signals are computed results from input operands
14:34<Pikka>yes, put that
14:35<@peter1138>I prefer Pikka's text.
14:35<@planetmaker>Supercheese, you can (often) use only combo signals. But entry and exit are nice to separate signal chains
14:35<frosch123>combo signals are both, computed from other inputs (exit or combo), and possible operands to other entry or combo
14:35<Supercheese>This is why I have never used them :|
14:35<andythenorth>just remove them
14:35<andythenorth>translations go away
14:35<@peter1138>Good idea. They're a BAD FEATURE.
14:35<Supercheese>I can translate path signals just fine
14:35<andythenorth>we should have a BAD FEATURE quota
14:36<andythenorth>no bad features means no interest
14:36<@peter1138>oh fuck
14:36<@peter1138>dog farted :(
14:36<frosch123>Pikka: but Supercheese is doing a latin translation, so it must be "unless you have been transported forward in time to 2005"
14:39-!-Jomann [] has joined #openttd
14:48-!-Pereba [~UserNick@] has quit [Ping timeout: 480 seconds]
14:49-!-Pereba [~UserNick@] has joined #openttd
14:49<Supercheese>It's odd that semaphores still are referred to as "green" and "red"
14:50<andythenorth>342 wagon train
14:51<frosch123>so you are lucky that they built a bridge for the road? instead of a crossing?
14:54<@peter1138>Supercheese, technically they can have lights...
14:54<Supercheese>they do not in OTTD though
14:54<Supercheese>not that it's ambiguous, just odd
14:54<frosch123>opengfx bug report? :p
14:55<Supercheese>"red" and "green" have been thoroughly engrained as "stop" and "go" in modern vernacular
14:55<Supercheese>imagine if other colors were chosen...
14:56<Wolf01>lime and purple
14:56<Supercheese>would give entirely new meaning to limelight
14:56<frosch123>some cultures invert shaking head with nodding
14:57<@planetmaker>yeah... that's so very confusing
14:58<frosch123>"nodding" is listed as "no" for bulgaria, albania, greece and india
14:58<@planetmaker>the same culture inverts male and female names ;)
14:58-!-Myhorta [] has joined #openttd
14:58<@planetmaker>hm, also southern italy, no?
14:59<frosch123>no, idea, i am only quoting wiki
14:59<frosch123>and you can tell the wiki quality be reading texts you know about :p
15:04<Supercheese>Huh, converting between electric block <-> electric path signals (etc.) costs nothing, but converting between semaphore <-> electric does
15:04<Supercheese>not a bug, I just never noticed
15:05<frosch123>the first thing i did after the addition of semaphores, was setting the intro date to 1492
15:06<Supercheese>didn't TTDPatch first do semaphores?
15:06<frosch123>resp. in ttdp it was just a "no" setting (iirc)
15:06<frosch123>Supercheese: all those weird construction actions which are done with ctrl originate in ttdp :p
15:10<Pikka>andythenorth: I'd forgotten what a PITA articulated vehicles with cargo capacity are :)
15:10-!-Celestar [] has joined #openttd
15:18<andythenorth>they are
15:18<andythenorth>I solved it all with code
15:23-!-sla_ro|master [slamaster@] has quit []
15:24<Pikka>you have a pm andy
15:27<Pikka>70 trainz
15:27<Pikka>in a fountain
15:27<andythenorth>is it horses compatible?
15:27*andythenorth looks
15:27-!-Brumi [] has quit []
15:29<Pikka>horses are a bit cheaper :)
15:29<Pikka>although this has the same price-halving parameter as 10cc
15:29<andythenorth>nice SP liveries
15:29-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
15:29*andythenorth means
15:30<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 :)
15:30<andythenorth>GFC6 is in canset I think
15:31<Pikka>probably. I'm sure Dan has sprites somewhere
15:31<andythenorth>setting company colours to white is best
15:32<andythenorth>nice that the locos are grouped by mfr
15:32<andythenorth>but also 70?
15:33<Pikka>americans and their locos
15:33<Pikka>it would have been more if I'd seperated and kept all the generations
15:34<Pikka>I think the F is the only one I've kept two generations of. but it had 4 generations in NARS
15:34<andythenorth>costs aren’t far from IH
15:34<Pikka>most of the diesels had two or three
15:34<andythenorth>GP60 ~= Grid
15:35<Pikka>5 times the running cost though :P
15:38<andythenorth>ha ha
15:38-!-Myhorta [] has quit [Ping timeout: 480 seconds]
15:38<andythenorth>my engines are better
15:38<andythenorth>easier to maintain, clearly
15:39<andythenorth>also huzzah
15:39<andythenorth>also no buy menu text \o/
15:39<Pikka>does it need it?
15:41<andythenorth>I am -1 to buy menu text
15:41<andythenorth>it breaks my compile :P
15:42-!-DabuYu [DabuYu@] has joined #openttd
15:45-!-Klanticus [~quassel@] has quit [Remote host closed the connection]
15:47-!-Myhorta [] has joined #openttd
15:51-!-FLHerne [] has joined #openttd
15:53<frosch123>i tried to look into speeding up compile, but ih/fish is too complicated :p
15:54<frosch123>i would have to fetch the intermediate nml and split it up again :p
15:54<frosch123>optimising nml would be fun, but optimising andy's template magic is not :p
15:55<andythenorth>what would you want to split up?
15:55<andythenorth>the templating can be restructured
15:55<andythenorth>kind of the point :)
15:56<frosch123>my "far" goal would be an nml file per vehicle, and "external" references for parameters
15:58<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
15:59<andythenorth>nml file per vehicle is trivial to template
15:59<andythenorth>in fact
16:00<andythenorth>that’s what IH is doing
16:01<andythenorth>python -> templating -> nml file per vehicle -> (nmlc) nfo file per vehicle -> link (ugh) -> grfcodec -> grf
16:02<andythenorth>it’s nearly functional, except that nmlc has no way to provide consistent string IDs
16:02<andythenorth>so most text is game-overed
16:05<frosch123>what was the packaging tool for python again?
16:06<andythenorth>there are many
16:06<andythenorth>you want to install something?
16:06<frosch123>never mind
16:06<andythenorth>fwiw, pip for package installation
16:06-!-Celestar [] has quit [Quit: Leaving.]
16:07<frosch123>the standard package manager knows chameleon meanwhile
16:07<@Alberth> you may want one that's standard
16:08-!-Progman [] has joined #openttd
16:08-!-Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd []
16:09<andythenorth>Pikka: I am naming things after
16:09<frosch123>markdown is next :p
16:10<andythenorth>Pikka: you could have cabbishes
16:10<frosch123>andythenorth: did you hardcode -j 15 somewhere?
16:11<andythenorth>you want your CPU back?
16:11-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
16:11<frosch123>compiling iron-horse lags my other vms
16:11<andythenorth>hang on
16:11<frosch123>well, now it finished :p
16:11<@planetmaker>yes, the thing hard-codes cpu-hogging. I was once also fork-bombed by andy :P
16:11<andythenorth>make install NO_MP=True
16:12<andythenorth>I thought I defaulted it to True
16:12<@planetmaker>it should be NO_MP by default
16:12<@planetmaker>dunno what's default now, though
16:12*andythenorth looks
16:13<andythenorth>maybe it should also pick up the -j flag from make and pass it to python :P
16:13<andythenorth>but first default
16:14<andythenorth>I should rename the flag to USE_MP
16:16-!-trendynick [~trendynic@] has quit [Ping timeout: 480 seconds]
16:18-!-theholyduck [~theholydu@] has quit [Ping timeout: 480 seconds]
16:20<andythenorth>pushed revised default
16:25-!-luaduck_zzz is now known as luaduck
16:30-!-theholyduck [~theholydu@] has joined #openttd
16:31-!-DabuYu [DabuYu@] has joined #openttd
16:39*andythenorth considers Iron Horses
16:39<andythenorth>release 3 grfs, only grfid is different
16:40<frosch123>iron-pony, iron-horse, iron-nag ?
16:41-!-Yotson [~Yotson@2001:980:6ac8:1:2441:476c:3428:d35c] has quit [Quit: .]
16:41<andythenorth>allows players to use multiple rosters in one game :P
16:41<@planetmaker>:-O build 1100 of IH!
16:42<frosch123>how? there are only 910 revisions
16:42<@planetmaker>repeat build. probably manually
16:45<andythenorth>hmm, rosters aren’t necessarily compatible
16:45<andythenorth>so that was a silly idea
16:45<andythenorth>just the one grf then
16:51-!-trendynick [~trendynic@] has joined #openttd
16:52<Wolf01>isn't drag&drop brush available in map editor?
16:56<Pikka>I don't know, isn't it?
16:58<Wolf01>this game is so overwhelmed by hidden features that I can't understand if there's something or not
16:58<frosch123>there was a series of patches for that, but they never made trunk
16:59<Pikka>time to plan/code wogans. what joy.
16:59<Wolf01>I just found diagonal dynamite
17:00<Pikka>andy: is a parameter for wogan capacity a good idea? do people not like long trains?
17:00<frosch123>Wolf01: exactly that was the issue back then
17:00<frosch123>ctrl was proposed for diagonal drag, but also for freeform drag :p
17:01-!-Jomann [] has quit [Remote host closed the connection]
17:03<Wolf01>I see
17:04-!-Hazzard [] has quit [Ping timeout: 480 seconds]
17:05-!-Extrems [] has quit [Ping timeout: 480 seconds]
17:12-!-gelignite [] has joined #openttd
17:14-!-FLHerne [] has quit [Quit: There's a real world out here!]
17:18-!-Extrems [] has joined #openttd
17:19-!-Brumi [] has joined #openttd
17:21<andythenorth>Pikka: wagon capacity parameter is good feature
17:22<andythenorth>all sets need some kind of cheating feature
17:22<Pikka>I've got the half-price parameter for that ;)
17:22<andythenorth>Iron Horse has capacity: puny / marvellous / excessive
17:23<andythenorth>‘excessive’ is actually less than RL in several cases
17:24<@peter1138>clearly a BAD FEATURE
17:24<andythenorth>can change it in a running game
17:24<andythenorth>well I can
17:24<andythenorth>you can’t
17:25<andythenorth>would mess with AIs eh?
17:26<andythenorth>Pikka: can you just finish up my flat car?
17:26<andythenorth>shading is BAD on the ends
17:27<Pikka>nick all the olde NARS loads and suchlike?
17:28<andythenorth>loads I have
17:29<Pikka>and I know IH has the capacity parameter, that's why I asked :)
17:30<andythenorth>mine looks not realisms
17:30<Pikka>needs more EZ and rendering
17:34<@peter1138>16x zoom 64bpp
17:35-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
17:36<Pikka>animated rivets for maximum realisms
17:36<@planetmaker>peter1138, 16x sprites would kill devzone server ;)
17:36<@planetmaker>heck, yeti already hit its quota when the automatic cleaning script for old builds didn't work ;)
17:37<@planetmaker>it still uses as much space for builds as everything else combined :D
17:37<@planetmaker>s/else/other grf builds/
17:41-!-luaduck is now known as luaduck_zzz
17:42-!-DabuYu [DabuYu@] has joined #openttd
17:43<andythenorth>will he OOM the game/
17:44<@planetmaker>probably ;)
17:44<@planetmaker>and eventually
17:46<andythenorth>is it bed time?
17:46<@planetmaker>in 15 minutes
17:47<@planetmaker>probably I won't finish redrawing monorail by then
17:47<andythenorth>maybe tomorrow
17:47<andythenorth>also bye ;)
17:47-!-andythenorth [] has quit [Quit: andythenorth]
17:47<@planetmaker>maybe Sunday, but not tomorrow. Bye
18:15-!-Myhorta [] has quit [Remote host closed the connection]
18:17-!-gelignite [] has quit [Quit:]
18:19-!-Defaultti [] has quit [Quit: Quitting.]
18:20-!-Defaultti [] has joined #openttd
18:28-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
18:37-!-Hazzard [] has joined #openttd
18:38-!-frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
18:59-!-HerzogDeXtEr [~flex@] has quit [Read error: Connection reset by peer]
19:00-!-HerzogDeXtEr [~flex@] has joined #openttd
19:02-!-trendynick [~trendynic@] has quit [Remote host closed the connection]
19:03-!-Brumi [] has quit []
19:08-!-[1]BB [] has joined #openttd
19:08<[1]BB>Testing IRC...
19:08<[1]BB>1, 2, 1, 2...
19:11-!-[1]BB [] has left #openttd []
19:14-!-shansen [~shansen@] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
19:14-!-fjb is now known as Guest423
19:14-!-fjb [] has joined #openttd
19:21-!-Guest423 [] has quit [Ping timeout: 480 seconds]
19:30-!-TomyLobo [~foo@] has quit [Quit: Standby mode...]
19:39-!-Jinassi [] has left #openttd []
19:44<Eddi|zuHause>test failed...
19:46<@peter1138>So you (or rather, V453000) spend ages making 32bpp graphics, and then people want 8bpp instead...
19:53-!-kiwibun [] has joined #openttd
19:57-!-ToBeFree [] has quit [Quit: Ping timeout: 1337 seconds]
20:03<Eddi|zuHause><Pikka> andythenorth: I'd forgotten what a PITA articulated vehicles with cargo capacity are :) <-- i have no problem with that. just make sure that each part that should have different capacity should use a different vehicle id instead of magic capacity callbacks...
20:04<Pikka>well, yeah
20:05<Pikka>otoh you just set the capacity to total capacity / vehicle parts
20:05<Pikka>but it also means you have to build the articulate in the buy menu to get the correct capacity :)
20:05<Eddi|zuHause>which is weird if they are not integer-dividable
20:06<Pikka>but they are :)
20:06<Eddi|zuHause>sometimes they're not
20:06<Pikka>no, they always are :P
20:06<Eddi|zuHause>like all my articulated vehicles have 3 (or multiples thereof) parts, but next to none of my capacities are dividable by 3
20:07<Eddi|zuHause>well, almost all
20:07<Eddi|zuHause>but the ones that are not are usually steam engines, which have no capacity
20:08-!-liq3 [] has joined #openttd
20:10-!-Progman [] has quit [Remote host closed the connection]
20:16-!-kiwibun [] has quit [Ping timeout: 480 seconds]
20:46-!-oskari89 [] has quit []
20:47-!-glx [] has quit [Remote host closed the connection]
20:48-!-glx [~glx@2a01:e35:2f59:c7c0:288c:966a:109:24db] has joined #openttd
20:48-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
20:55-!-DabuYu [DabuYu@] has joined #openttd
20:58-!-Flygon [] has joined #openttd
21:00-!-MTs-iPad [] has quit [Remote host closed the connection]
21:00-!-MTs-iPad [] has joined #openttd
21:05-!-Flygon_ [] has quit [Ping timeout: 480 seconds]
21:09-!-Flygon_ [] has joined #openttd
21:16-!-Flygon [] has quit [Ping timeout: 480 seconds]
21:22-!-HerzogDeXtEr [~flex@] has quit [Quit: Leaving.]
21:24-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
21:28-!-luaduck_zzz is now known as luaduck
21:47-!-DabuYu [DabuYu@] has joined #openttd
22:15-!-theholyduck [~theholydu@] has quit [Ping timeout: 480 seconds]
22:23-!-KWKdesign [] has quit [Ping timeout: 480 seconds]
22:23-!-KWKdesign [] has joined #openttd
22:35-!-glx [] has quit [Quit: Bye]
22:36-!-luaduck is now known as luaduck_zzz
22:40-!-Hazzard_ [] has joined #openttd
22:41-!-Flygon_ [] has quit [Read error: Connection reset by peer]
22:41-!-Flygon_ [] has joined #openttd
22:41-!-rambo [] has joined #openttd
22:42-!-rambo is now known as Guest434
22:43-!-Pokka [] has joined #openttd
22:45-!-Wing_ [] has joined #openttd
22:47-!-TheMask96- [] has joined #openttd
22:47-!-Netsplit <-> quits: zeknurn, Hazzard, Pikka, EyeMWing, jrambo, TheMask96
22:48-!-Netsplit over, joins: zeknurn
22:52-!-theholyduck [~theholydu@] has joined #openttd
23:05-!-Hazzard_ [] has quit [Ping timeout: 480 seconds]
23:21-!-DabuYu [DabuYu@] has quit [Ping timeout: 480 seconds]
23:26-!-DabuYu [DabuYu@] has joined #openttd
23:36-!-Pereba [~UserNick@] has quit [Quit: AdiIRC >>>>>>> abyss >>>>>>>>>>>>>>>>>>>>> other irc clients. (]
---Logclosed Sat Oct 04 00:00:38 2014