IRC logs for #openttd on OFTC at 2014-07-22
⏴ go to previous day
00:01:24 <MTsPony> Question, is there some file that dictates pathing for scripts? as soon as i copy my server to another folder in linux i get script errors
00:01:27 <MTsPony> bg: [script] dutch:121: warning: String name 'STR_CITYBUILDER_SS_TOWN2_NAME??' does not exist in master file
00:01:33 <MTsPony> script seems to work fine otherwise
00:24:45 <Eddi|zuHause> mixing / vs. \ maybe?
00:48:15 *** Hazzard has joined #openttd
00:56:10 <MTsPony> im not transitioning to windows :p
00:56:34 <MTsPony> is there anything indexed somewhere? like libs, scripts etc?
00:56:50 <MTsPony> or does the game just bluntly read all folders to see what exists?
00:57:05 <MTsPony> like grfs are indexed in openttd.cfg
01:01:10 <Eddi|zuHause> there is no index. on game startup, a number of folders (described in the readme) is scanned, most notably the current working directory and the ~/.openttd directory, and all script/grf/whatever files are detected
01:02:41 <Eddi|zuHause> what's in the openttd.cfg is not which grfs you have, but which ones should be activated in a new game
01:03:31 *** Flygon_ has joined #openttd
02:10:14 *** HerzogDeXtEr has joined #openttd
02:38:03 *** tokai|noir has joined #openttd
02:38:03 *** ChanServ sets mode: +v tokai|noir
03:01:16 *** KWKdesign has joined #openttd
04:02:54 *** retakker has joined #openttd
04:43:01 *** trendynick has joined #openttd
04:56:16 *** Eddi|zuHause has joined #openttd
05:35:11 *** Smedles_ has joined #openttd
05:43:27 *** sla_ro|master has joined #openttd
05:45:58 *** Smedles has joined #openttd
06:11:22 *** Smedles has joined #openttd
06:21:17 *** HerzogDeXtEr1 has joined #openttd
06:34:58 *** Smedles has joined #openttd
07:00:46 *** Smedles has joined #openttd
07:24:37 *** pthagnar has joined #openttd
08:03:22 <V453000> I figured out the yeti animation-only rendering :) for a simple test case at least
08:10:46 *** trendynick has joined #openttd
08:33:37 *** luaduck_zzz has joined #openttd
08:34:04 *** luaduck_zzz is now known as luaduck
10:04:12 *** shirish_ has joined #openttd
10:58:31 <LSky`> isnt this supposed to be in the scenario section of the forums?
11:03:08 <planetmaker> yeah, you're right, LSky` . I'll move it
11:04:41 <planetmaker> hm... that's in the Transport Tycoon section only. That's... not idea. I guess I have another suggestion for Owen :P
11:04:44 <V453000> why did the 32bpp section get merged btw? :D
11:06:21 <planetmaker> V453000, pointless to have it separate.
11:06:29 <planetmaker> it's nothing special with regard to development processes
11:06:41 <planetmaker> and its existence triggered people to believe it is
11:06:51 <peter1138> It is for TTDP players :D
11:07:50 <peter1138> I bet they still want PNGs
11:08:39 *** HerzogDeXtEr has joined #openttd
11:08:45 <LordAro> you must admit, the "new" way is more complicated that the way it was done
11:09:31 <V453000> defining 32bpp additional_sprites was nothing special tbh
11:09:58 <planetmaker> LordAro, not really. It's actually easier
11:10:31 <planetmaker> no need to count sprite numbers etc. I just add it to a NewGRF and I'm done
11:10:39 <planetmaker> no special naming either
11:10:52 <planetmaker> no special in any respect
11:11:03 <LordAro> easier? before all they had to do was dump the pngs into a tar file (which caused enough issues, typically enough). true, they've got to number the sprites, but no writing NFO/NML
11:11:20 <planetmaker> LordAro, and all name them correctly. And re-name them when you changed the grf it referred to
11:11:33 <LordAro> and this was largely before nml, iirc
11:11:38 <planetmaker> so 32bpp development was a BIG PITA really
11:12:10 <planetmaker> you needed an unmoving base. Which you usally don't have. Not even for the base set's extra grf
11:13:09 <V453000> yeti-base shall show them bastards! :P
11:13:56 <planetmaker> yeah... especially V's NewGRFs are no base at all. Constantly changing :P
11:14:06 <V453000> :P changed that a lot recently
11:14:48 <LordAro> and multi-hundred MB downloads :p
11:15:13 <V453000> hey, it is only 144 mb now :P
11:15:17 <V453000> zbase has 250 I believe
11:15:44 <LordAro> 250? was only 45 last i checked
11:16:21 <V453000> I downloaded it just once and upon discovering how awful it is I never bothered again really
11:17:18 <peter1138> Don't forget about setting the offsets for all those PNGs whenever you changed one...
11:17:31 <peter1138> And of course it sucked for performance.
11:19:41 <peter1138> V453000, thought about making a 8bpp version? ;)
11:20:13 <peter1138> I wonder, did the system to allow users to only download the bits of a NewGRF they need get implemented?
11:20:52 <V453000> you mean 8bpp version of yeti?
11:21:08 <peter1138> Errr.... yes, you should know I was looking at the thread...
11:21:09 <V453000> it does define 8bpp sprites, just overwrites them with 32bpp
11:21:19 <planetmaker> peter1138, OpenTTD would support it. But there's no means to download it from bananas
11:21:22 <V453000> and there is nothing to really be interested in
11:22:12 <V453000> k well now I see that you are looking at _the_ thread XD matterz it?
11:22:39 <V453000> regardless, making a lightweight version could be cute, but how/why
11:23:05 <V453000> + lightweight doesnt need to be 8bpp, 32bpp is fine if I remove extra zoom and animations
11:23:11 <planetmaker> V453000, OpenTTD considers NewGRFs equivalent when stripping them of anything which is not 8bpp 1x sprites
11:23:25 <peter1138> Hmm, true, it's x4 zoom that bloats it.
11:23:41 <planetmaker> and in principle one can strip the 'big' newgrfs of those extra sprites they provide and offer stripped versions for download, e.g. to save bandwidth
11:23:55 <V453000> didnt have a clue about that
11:24:27 <planetmaker> while grf format and openttd support it, there's no such interface yet in the game or bananas to select only certain bit depth or maximum zoom level for the sprites
11:24:36 <planetmaker> for your downloads from bananas
11:24:37 <V453000> so theoretically I can have a lightweight 8bpp version on the devzone that people could use if they cannot download the big one?
11:25:11 <peter1138> Of course, what computer doesn't support 32bpp these days...
11:25:13 <V453000> well lets see how many people will have stone age connection and complain that they cant download it
11:25:14 <planetmaker> grfstrip (part of grfcodec) gets you that grf
11:25:31 <V453000> aha, very nice so I dont even have to have 2 versions of the code
11:25:41 <planetmaker> no, of course not. That's the point :)
11:26:18 <planetmaker> authors create the version packed with everything. And that result can be stripped-down to the bit depths and zoom levels requested by a user
11:26:33 <planetmaker> it just misses an interface so that it's actually used
11:27:08 <planetmaker> there simply was no need so far either
11:27:19 <planetmaker> you might trigger that need :P
11:27:56 <V453000> Almost gives me a reason not to cheat on 8bpp images :D
11:28:13 <V453000> though lets see how successful my current masking method gets
11:28:19 <planetmaker> well.. cheat. Just do a cheap conversion 32bpp to 8bpp
11:28:31 <V453000> for most of the industries it reduces the size a ton
11:28:39 <V453000> I know, that is what I did :P
11:28:40 <Eddi|zuHause> try to avoid the magic blinking colours while doing that :p
11:28:46 <planetmaker> well then :) It's no cheat
11:29:06 <V453000> I rather meant missing animations in 8bpp yet loading that amount of sprites :P
11:29:16 <V453000> is 2048 sprites for 8bpp in such case
11:29:50 <planetmaker> they don't eat disk size really. It's the 4x 32bpp sprites which do :)
11:30:10 <planetmaker> they're 4*4 = 16 times bigger :)
11:30:42 <V453000> especially if you load each of them twice XD
11:30:42 <Eddi|zuHause> but 2048 times the same sprite doesn't really help, as the compression is per-sprite only, not over the whole grf
11:31:03 <V453000> that is why it is a cheat Eddi :P
11:31:18 <V453000> cause the strip cant strip that
11:31:34 <V453000> but hell, NUTS has idk, 60 000 sprites and people can download it
11:31:36 *** Supercheese has joined #openttd
11:32:15 <Eddi|zuHause> CETS probably has more
11:32:31 <V453000> CETS has empty boxes, not sprites :D
11:32:34 <Eddi|zuHause> and it doesn't even have liveries and cargo grapics yet
11:32:47 <Eddi|zuHause> but the boxes are coloured meanwhile
11:32:51 <Eddi|zuHause> not green anymore
11:33:49 <V453000> you might want to start drawing Eddi :P
11:34:51 <peter1138> I don't know what he looks like.
11:35:18 <planetmaker> Eddi|zuHause, cargo graphics can be stolen from NUTS ;)
11:35:47 <Eddi|zuHause> NUTS doesn't have turning angles :p
11:36:12 <V453000> I completely forgot you want to draw even that
11:36:26 <Eddi|zuHause> also, square pigs don't fit in my wagons
11:36:46 <planetmaker> apply a coordinate transform on them and they might
11:36:52 <V453000> boxes arent square? :P
11:37:12 <planetmaker> in spherical coordinates: no :P
11:37:45 <peter1138> Why doesn't 3D OpenTTD exist yet? :p
11:38:07 <Eddi|zuHause> train fever is in beta stage
11:40:07 <planetmaker> isn't TTT something like 3D OpenTTD?
11:40:31 <V453000> nothing is like openttd as far as I know :P
11:40:35 <Eddi|zuHause> but that was never even properly released
11:40:40 <V453000> /me doesnt know very far though
11:41:33 <Eddi|zuHause> what was released was an early beta version, and then it died a painful legal death
11:49:31 *** KWKdesign has joined #openttd
12:02:16 *** KWKdesign has joined #openttd
12:27:07 *** Flygon_ has joined #openttd
12:38:38 *** Hazzard_ has joined #openttd
12:54:21 *** sla_ro|master has joined #openttd
13:49:26 *** LadyHawk has joined #openttd
13:50:03 *** LadyHawk is now known as Guest3485
14:18:01 *** KWKdesign has joined #openttd
15:22:43 *** SylvieLorxu has joined #openttd
15:23:50 *** sla_ro|master has joined #openttd
15:42:07 *** Pensacola has joined #openttd
15:47:02 *** matthew has joined #openttd
15:47:23 *** matthew is now known as Guest3500
15:49:25 *** ZirconiumX has joined #openttd
15:50:54 *** montalvo has joined #openttd
15:56:48 * ZirconiumX is slightly confused about how flyspray still has an open bug report for OpenTTD 0.4.7
16:03:07 <LordAro> probably because it hasn't been fixed :P
16:03:29 <LordAro> and actually, it's a feature request, which are largely ignored anyway :p
16:03:36 <ZirconiumX> Or it's so old they simply don't care.
16:04:45 <LordAro> was the oldest until a few months ago
16:04:51 *** TheMask96 has joined #openttd
16:27:11 <ZirconiumX> I'm not entirely sure if there is much point to fs 127
16:29:35 <LordAro> probably not a lot of point to any <3000
16:29:36 <ZirconiumX> If only there was a way of voting to close an FS
16:31:49 <Eddi|zuHause> nobody of power ever listened to votes
16:33:21 <V453000> you cannot force anybody to do anything, not even votes can :P it is open source
16:36:56 <ZirconiumX> And also free software.
16:37:00 <Eddi|zuHause> you cannot make a particular horse drink, but of 100 horses, you can easily make a majority drink
16:37:23 <ZirconiumX> I suppose you'd end up with a Down's paradox.
16:37:39 <Eddi|zuHause> the first is called psychology and the second is called sociology
16:38:37 *** Klanticus has joined #openttd
16:39:28 <ZirconiumX> But having ancient FS bugs from 8 years ago does nothing useful.
16:40:13 <Rubidium> though... the problem here is more that fixing things is less glamourous than making something fancy
16:40:30 <ZirconiumX> Has to be done though.
16:40:49 <Eddi|zuHause> that's why it's still open
16:41:27 <Eddi|zuHause> because technically it is something that might be fixed at some point. if someone is really bored
16:41:31 <ZirconiumX> seems to be the oldest bug report.
17:12:02 <Eddi|zuHause> k10temp-pci-00c3 temp1: +37.0°C <--- how do i find out where this sensor is?
17:12:27 <ZirconiumX> Though I'd guess K10temp refers to the builtin processors
17:12:55 <Eddi|zuHause> Rubidium: that doesn't really tell me the physical location?
17:13:12 <Rubidium> might give you a clue
17:13:26 <ZirconiumX> Rubidium: can confirm this does not work
17:16:07 <ZirconiumX> "This driver permits reading of the internal temperature sensor of AMD
17:16:09 <ZirconiumX> Family 10h/11h/12h/14h/15h/16h processors."
17:17:10 <ZirconiumX> 18:11 < ZirconiumX> Though I'd guess K10temp refers to the builtin processors
17:24:00 <Eddi|zuHause> but that mens the cpu is 10-20°C colder than the rest of the computer
17:24:17 <LordAro> i could've sworn that temperature sensor referred to the GPU
17:24:32 <LordAro> do you have an AMD/ATI graphics card?
17:24:33 *** frosch123 has joined #openttd
17:24:42 <Eddi|zuHause> gpu makes way more sense
17:24:53 <LordAro> (i have a similar sensor, but it shows up as 0°C :L )
17:25:55 <Eddi|zuHause> i also have it8720-isa-0228: temp1: +47.0°C, temp2: +48.0°C, temp3: +55.0°C
17:26:47 <Eddi|zuHause> those are apparently on the mainboard, but i have no clue where
17:27:46 <Eddi|zuHause> and yes, i have an ATI card. a builtin one that i don't use and a PCI-E one.
17:29:40 *** Pensacola has joined #openttd
17:31:00 * LordAro got a new cpu cooler/fan recently. it's wonderful
17:34:22 <Eddi|zuHause> there's pwm for making things quieter, but that usually makes it hotter :)
17:34:22 <frosch123> is there a system call to explode a computer?
17:36:31 *** KenjiE20 has joined #openttd
17:36:33 <LordAro> Rubidium, i may well be misremembering, i'm away from my desktop at the moment
17:36:46 <frosch123> is it a feature that realisitic acceleration cannot handle 1 000 000 hp? :p
17:37:09 <Rubidium> Eddi|zuHause: read the indented part of the link I just gave to LordAro
17:37:59 <LordAro> certainly, the `sensors` reading for my graphics card shows up as 0°C
17:39:48 <Eddi|zuHause> so it's not an actual °C but a "if this reaches 70, you better get cover"
17:40:08 <Eddi|zuHause> why do they call it °C then?
17:40:43 <Rubidium> because sensors forces that postfix?
17:46:40 <DorpsGek> Commit by translators :: r26701 /trunk/src/lang (3 files) (2014-07-22 17:46:30 UTC)
17:46:41 <DorpsGek> -Update from WebTranslator v3.0:
17:46:42 <DorpsGek> traditional_chinese - 1 changes by siu238X
17:46:43 <DorpsGek> hungarian - 31 changes by Brumi
17:46:44 <DorpsGek> norwegian_bokmal - 1 changes by
17:46:45 <DorpsGek> polish - 4 changes by McZapkie
17:48:37 <frosch123> the yeti thread is interesting :) V uses a completely different tool chain than i would use, but the results works nevertheless :)
17:56:02 *** Progman has joined #openttd
18:13:48 <Rubidium> frosch123: FS#6067 smells like an overflow
18:19:12 *** LadyHawk has joined #openttd
18:19:20 <frosch123> yup, if not a desync on 64bit :p
18:19:45 <frosch123> but well, 100k hp is not particulary interesting
18:35:23 <Rubidium> won't it use the same int type?
18:35:38 <Rubidium> otherwise... we'd have much more desyncs I'd say
18:35:42 <frosch123> also for intermediate computations?
18:36:15 <peter1138> You might need some quite hefty track for that though...
18:36:47 <peter1138> (Or implement RA for ships...)
18:37:58 <Rubidium> the code's even littered with uint32 and byte
18:38:11 <frosch123> yes, but i have no idea what happens if you do "a * 1000 / 1000"
18:38:27 <frosch123> the result will be 32bit, but what about "a * 1000" ?
18:38:35 <Rubidium> max_te gets a max_te *= 10000
18:38:59 <frosch123> oh, i didn't look into details of the acceleration code
18:39:15 <frosch123> i only wondered in general whether those computations are not implementation specfic
18:42:32 <Rubidium> max value for 'power' = (sum of part powers) * 746 * 18
18:42:41 <Rubidium> @calc 2**31 / 161517
18:42:41 <DorpsGek> Rubidium: 13295.7128228
18:44:04 <Rubidium> what's the theoretical maximum power?
18:44:32 <frosch123> 64k per vehicle, 128 vehicles, 128 articulated parts per vehicle
18:44:52 <frosch123> hmm, though i guess only the front part can add power
18:45:41 <Rubidium> there's a GetPower that prevents articulated parts
18:46:11 <Rubidium> and a GetPoweredPartPower which uses the VRF_POWERED_WAGON flag
18:46:37 <Rubidium> that's not the 1 million the bug reporter is talking about
18:47:15 <Rubidium> I would've guessed (naively) at 64*2*8 * 64k
18:47:46 <Rubidium> hmm... I'm stupid... 8.3 million > 1 million
18:48:05 <Rubidium> anyhow... 128*128*64k < 2**31
18:48:28 <Rubidium> however, multiplying by 13428 doesn't fit
18:49:33 <frosch123> @calc log(13428 * 128 * 65536, 2)
18:49:33 <DorpsGek> frosch123: 36.7129568217
18:50:13 <frosch123> yeah, factor 64 too much
18:51:27 *** George|2 has joined #openttd
18:51:27 *** George is now known as Guest3525
18:51:27 *** George|2 is now known as George
18:53:32 <Rubidium> @calc 65535*128*746*18
18:53:32 <DorpsGek> Rubidium: 112640509440
18:54:56 <Eddi|zuHause> <frosch123> the result will be 32bit, but what about "a * 1000" ? <-- in C(++), int32*int32 = int32, which i find stupid, because every CPU on this planet outputs 64 bits...
18:55:22 <Eddi|zuHause> well, every USEFUL cpu
18:55:46 <frosch123> you do not consider mmx, sse, ... and friends useful? :p
18:57:16 <Eddi|zuHause> NO! the world must forever be stuck with the i386 command set
19:06:20 *** oskari89 has joined #openttd
19:17:37 <frosch123> @calc log(65535*128*746,2)
19:17:37 <DorpsGek> frosch123: 32.5430098063
19:18:26 <frosch123> + int64 power = this->gcache.cached_power * 746; <- i guess that shuold be (int64)cached_power * 746ll
19:18:48 <Rubidium> one cast should be enough
19:19:16 <Rubidium> or the 746ll I'd say
19:20:50 <Rubidium> the patch definitely improves the performance of that train
19:22:32 <frosch123> area * this->gcache.cached_air_drag <- according to your comments that also exceeds int32
19:22:40 <frosch123> so i would expect it to need casts as well
19:23:32 <Rubidium> 28*~5000 doesn't, the speed**2 would make it overflow and I made speed int64
19:23:55 <Rubidium> so the ~100k gets promoted to int64 by speed
19:30:48 *** Klanticus_ has joined #openttd
19:32:02 <Rubidium> oh, I reckon limiting the acceleration to int32 isn't a big problem, right? ;)
19:33:13 <frosch123> how many seconds does it need to reach lightspeed at that acceleration?
19:33:34 <frosch123> i.e. when is the acceleration code not realistic enough?
19:36:12 <frosch123> i like how wiki liss approximate and "exact" values :p
19:37:20 <frosch123> we should use "planck length per planck time" to measure light speed
19:37:41 <frosch123> it's the most suitable one for a good approximation
19:39:29 *** b_jonas has joined #openttd
19:39:33 <planetmaker> totally. Gives us good reason to argue for vehicle quantum effects, too ;)
19:40:38 <planetmaker> though I learnt today that they're really planning to measure (and then actually define) current on a single-electron basis
19:41:31 <Rubidium> quantum effects smells like floating point to me (waveform functions and such)
19:41:49 <frosch123> yeah, quantum effects desync all the time
19:41:52 <planetmaker> nah. It boils it down to ints again, to yes or no :)
19:42:33 <frosch123> though maybe every client can simulate all potential desync states, so they are in sync again
19:46:16 <DorpsGek> Commit by rubidium :: r26702 /trunk/src (ground_vehicle.cpp ground_vehicle.hpp) (2014-07-22 19:46:10 UTC)
19:46:17 <DorpsGek> -Fix [FS#6067]: integer overflows in acceleration code causing either too low acceleration or too large acceleration
19:48:28 <Rubidium> why are journalist so dump?
19:49:07 <frosch123> else they wouldn't be journalists?
19:49:16 <frosch123> same about teachers
19:50:24 <Rubidium> asking someone doing identification based on DNA (in case of the MH17) whether they'd do the identification for the non-Dutch victims too...
19:51:03 <Rubidium> (as if the victims have a tag with their nationality)
19:51:21 <planetmaker> they actually might have... in their wallets in their trousers
19:51:36 <frosch123> then you do not need the dna thingie
19:52:11 <planetmaker> yeah. And I wonder how someone would want to identify me by my DNA? They would have to break into my flat for comparison or so
19:52:20 <planetmaker> hopefully at least :P
19:52:25 *** George is now known as Guest3530
19:52:34 <frosch123> planetmaker: siblings and nsa recordings
19:53:49 <Rubidium> planetmaker: I'd reckon the next of kin of you would be able to provide them with something
19:55:08 <frosch123> and in the worst case it may also be the key to what pieces belong to the same puzzle :/
20:09:07 <michi_cc> Rubidium: Your commit changes the power factor from 746 to 74611, but I can't see any divisor changed to match. Sure this is right?
20:09:42 <frosch123> michi_cc: fix your font :p
20:11:13 <michi_cc> Ah, ll :) Well, seems the browser doesn't feature an intelligent font chooser.
21:08:26 *** FLHerne has joined #openttd
21:38:08 <NGC3982> Can someone remind me; Why arent we running OpenTTD servers of RPI's?
21:39:35 <frosch123> for the same reason why you do not run your cellphone with one
21:40:21 <FLHerne> NGC3982: Because Pis are aargh slow
21:40:58 <NGC3982> I fail to see how they lack the processing power for dedicated servers.
21:41:18 <NGC3982> Although, this has been discussed. I just can't remember why it wasn't the best of ideas.
21:41:20 <FLHerne> And if servers aren't CPU-limited (which they sometimes are on sane hardware, let alone Pentium-300 analogues) they're network-limited
21:41:34 <frosch123> what makes you think servers would need less power?
21:41:56 <FLHerne> And Pi networking is on the USB bus, and tends to cause total hangs in case of continuous max throughput
21:42:26 <FLHerne> The server uses as much CPU as the client, barring blitting
21:42:48 <MTsPony> try again with 15 companies and 1000+ trains and some CB script and 20/30 GRF's ;)
21:43:24 <MTsPony> even a i7 4.5GHz gets as high as 60-70% on the process (tho in a vm so there might be some overhead)
21:43:32 <frosch123> ah, true, gamescript even add to the power :p
21:43:51 <frosch123> though usually it is not much
21:44:05 <frosch123> likely blitting is more than gs
21:44:15 <frosch123> MTsPony: they cannot really do much
21:44:31 <MTsPony> its another 5-10% of the cpu, on a 4K x 4K map with 'only' 100 cities/towns
21:44:38 <frosch123> if they want to do stuff, they have to run commands, which have strong limits
21:46:25 <MTsPony> still, 1000 ships, 1000 trains, some 1000 road vehs etc last time on my server, load is pretty bad ass, even on my intel compiled binary which already reduced cpu usage by a whole load lol
21:46:45 <MTsPony> with all the fancy tricks, resolution at 1,1, all fancy stuff off server side, load on corner of the map, etc etc
21:47:07 <frosch123> resolution shouldn't have any effect since 0.6 :p
21:47:12 <MTsPony> 4k x 4k map, pretty hefty :o way more then client side load :D
21:47:35 <MTsPony> better safe then sorry
21:48:17 <frosch123> haha, you can always recognize the dutch guys
21:48:59 *** FLHerne has joined #openttd
21:49:23 <frosch123> only dutch guys do the then/than thing :)
21:51:11 <MTsPony> i thouht that was purely brittish :p
21:57:53 <NGC3982> < FLHerne> The server uses as much CPU as the client, barring blitting
21:58:28 <NGC3982> My i5 can't handle my own 4096^2 server i run on a P4 Ubuntu server.
21:58:34 <FLHerne> NGC3982: Well, and sprite-sorting and whatever
21:58:41 <NGC3982> What don't i understand.
22:18:46 <peter1138> Yeah, a Pi sucks for OpenTTD.
22:19:21 <NGC3982> Too bad. It would be optimal.
22:19:34 <peter1138> Something too slow would be optimal. Right.
22:20:02 <NGC3982> Of course you understand what i mean
22:20:14 <NGC3982> A small open source based system running a small open source based game.
22:21:22 <peter1138> Is Pi open source now?
22:21:33 <NGC3982> I guess the Pi itself is not
22:21:40 <peter1138> The graphics chipset was rather closed up previously. Maybe that's fixed.
22:21:44 <NGC3982> But everything about it is similar to everything about you guys.
22:22:36 <peter1138> It's a small underpowered machine that runs Linux. There's loads of them around, called home routers.
22:22:52 <NGC3982> Are you comparing the Raspberry Pi to a router?
22:22:53 <peter1138> The Pi is quite a nice machine running RISC OS, though.
22:23:00 <peter1138> No, routers are generally more useful.
22:23:06 <FLHerne> NGC3982: OTTD is quite a long way from 'small', in code or hw requirements
22:23:34 <NGC3982> I still don't understand the fact that the server uses the same amount of CPU as the client.
22:23:43 <NGC3982> Since that is not what i experience.
22:23:47 <FLHerne> NGC3982: My router is faster than a first-gen Pi, and you can get ones with more RAM
22:23:50 <peter1138> Because it has to do exactly the same processing as a client.
22:24:13 <FLHerne> Also, it doesn't hang under network load (which would be daft in a router but is somehow acceptable if it's a hobby thing)
22:24:17 <peter1138> Routers generally have much faster networking than a Pi does.
22:24:28 <__ln__> someone said Pi is really good for very few other things besides playing video/media, and by a strange coincidence playing video/media is exactly what the chipset used by Pi is meant for.
22:25:01 <peter1138> Yes, but it's not very good for that, because the user interface to select your media is horribly slow.
22:25:07 <NGC3982> How come i can run my five (huge) servers with no issue on an old P4, and my i5 struggle with one of them?
22:25:36 <peter1138> What's the clockspeed of each?
22:26:05 <NGC3982> I do think my P4 is somewhere around 3GHz, and the i5 is a ..480M, perhaps?
22:26:23 <NGC3982> Wait, the P4 is single-core, i guess..
22:26:36 <peter1138> What speed does a 480M run at?
22:27:03 <peter1138> M implies mobile, so probably quite slow.
22:27:08 <NGC3982> 2,66GHz, according to their website.
22:27:26 <NGC3982> But i have no idea how to translate that into "per core", since that seems to make a difference for OpenTTD.
22:27:57 <peter1138> Each core can run at 2.66 GHz.
22:28:15 <NGC3982> Well, that explains it.
22:29:20 <peter1138> It's possible your i5 is running in a power saving mode.
22:29:23 *** bdavenport has joined #openttd
22:30:24 <FLHerne> NGC3982: OTTD doesn't multithread very well (autosaving, linkgraph calculation - is rendering threaded?)
22:32:58 <peter1138> But an i5 at 2.66 GHz should easily compete with a P4 at 3 GHz, regardless of multiple cores.
22:37:42 <FLHerne> I don't think the IPC difference is that dramatic, and if his P4 is just running a headless server with no rendering and not much other overhead
continue to next day ⏵