IRC logs for #openttd on OFTC at 2011-12-31
⏴ go to previous day
00:09:21 <saua> Do I really need to have X-installed for be able to use the dedicated server?
00:10:51 <glx> no, but you must compile yourself in this case
00:13:11 <saua> i tried that, still needed a graphics set so I figured it also needed X?
00:13:38 <glx> graphics set is a different thing
00:13:55 <glx> they contain more than graphics
00:14:08 <planetmaker> saua: the graphics sets contain also height maps needed for the terrain generator
00:32:28 *** fjb|tab has joined #openttd
01:00:06 *** Adambean has joined #openttd
01:42:27 *** LordPixaII has joined #openttd
01:51:15 *** LordPixaII has joined #openttd
01:55:21 *** Progman has joined #openttd
01:55:44 *** LordPixaII has joined #openttd
02:00:31 *** LordPixaII has joined #openttd
02:06:24 *** LordPixaII has joined #openttd
02:25:08 *** LordPixaII has joined #openttd
02:28:14 *** JoeyJo0 has joined #openttd
02:40:51 *** LordPixaII has joined #openttd
02:50:38 *** LordPixaII has joined #openttd
03:00:24 *** LordPixaII has joined #openttd
03:10:11 *** LordPixaII has joined #openttd
03:20:11 *** LordPixaII has joined #openttd
03:26:48 *** LordPixaII has joined #openttd
03:36:18 *** LordPixaII has joined #openttd
04:04:22 *** LordPixaII has joined #openttd
04:20:04 *** LordPixaII has joined #openttd
04:30:06 *** LordPixaII has joined #openttd
04:50:48 *** collinp has joined #openttd
05:56:19 *** Eddi|zuHause has joined #openttd
08:30:52 *** DayDreamer has joined #openttd
08:36:15 *** Scuddles has joined #openttd
08:50:49 *** Alberth has joined #openttd
08:50:49 *** ChanServ sets mode: +o Alberth
08:53:54 <peter1138> planetmaker, how many people use the original generator? :)
08:57:34 *** andythenorth has joined #openttd
09:08:56 *** Chris_Booth has joined #openttd
09:14:56 <andythenorth> mornington crescent
09:30:42 *** |Jeroen| has joined #openttd
09:36:25 *** TGYoshi has joined #openttd
09:54:38 *** Guest22060 is now known as Mark
09:54:58 *** Progman has joined #openttd
10:08:23 <CIA-6> OpenTTD: rubidium * r23690 /trunk/src/window.cpp: -Fix: massive typo ;)
10:09:52 <encoded> why does your cia page not contain a link to a diff or something?
10:10:36 <Terkhen> check the topic of this IRC channel
10:11:11 <Rubidium> encoded: because whatever the CIA does is unsourced, or in wikipedia speak: "citation needed"
10:11:31 <Rubidium> e.g. the WMD in Iraq ;)
10:11:48 *** JVassie_ has joined #openttd
10:19:48 *** sla_ro|master has joined #openttd
10:21:05 <Eddi|zuHause> in german we say "aus für gewöhnlich gut informierten Kreisen" when we want to hide the actual source :p
10:27:21 <lordnokon> my wish for the new year, is to have my own personal programmer to make me newgrf's 100 euro's per custom grf
10:30:37 <andythenorth> add one order of magnitude to the amount and I'll consider it
10:30:44 <andythenorth> still GPL though - so no warranty
10:30:49 <andythenorth> and no customer service
10:31:08 <Alberth> andythenorth: change-requests == a new custom grf :)
10:31:27 <andythenorth> money will be divided as follows: 30% openttd / coop; 30% charity; 30% lego
10:40:39 <Alberth> what makes you think andy is not?
10:41:44 <planetmaker> moin andythenorth :-)
10:41:50 <planetmaker> you forgot 10% rattle :-P
10:42:00 <andythenorth> lordnokon: I am serious
10:42:11 <Terkhen> and given that andy is one of the few who can both draw and code he's one of your few options if you want to keep things small :)
10:42:12 <andythenorth> you just need 9 other people who also pay €100
10:42:21 <andythenorth> what grf do you need
10:42:26 <Ammler> andythenorth: only 30% lego, then you need a lot money :-)
10:42:30 <Ammler> lego is damn expensive
10:42:42 <planetmaker> Ammler: you get the Imperial shuttle for 150€
10:42:57 <planetmaker> so... "just" a few 100€ contracts ;-)
10:44:09 <Alberth> lordnokon: or you need about 10 custom grfs :)
10:46:03 <lordnokon> ill even go 5000 euro, for the programmer, who can resolve the problem of openttd slowing down the more vehicles you have, because if there is something that pee's me off when playing opentdd is that, and thats playing on a system with 16cores, 96gb memory, and running 3 way sli with ssd drive
10:46:37 <andythenorth> lordnokon: trade in your computer
10:46:42 <andythenorth> you'll get a better effect
10:46:58 <TrueBrain> impossible to ever solve that more vehicles make the game go slower
10:46:58 <andythenorth> your computer is completely unsuited to openttd
10:47:07 <TrueBrain> more == slower, always, no matter what, no matter where :P
10:47:49 <planetmaker> TrueBrain: if you set a limit, make the computation steps big enough (tick length = 2 minutes), then more vehicles will not slow things down by a long shot ;-)
10:47:50 <Terkhen> and for making OpenTTD multicore you would need more than that... for example I don't have the time for such a huge project
10:47:58 <lordnokon> with so many clever people (programmers) out there i refuse to except that answer
10:47:59 <planetmaker> I'm not talking about playability, though ;-)
10:48:12 <Terkhen> programmers that have other things to do too :)
10:48:22 <TrueBrain> planetmaker: on which ever level, it always slows down a tiny bit :)
10:48:25 <TrueBrain> either because of cache-time
10:48:37 <Terkhen> and you can't change more == slower, you can just make it a bit better
10:48:39 <andythenorth> lordnokon: you just need a better computer
10:48:48 <Alberth> lordnokon: multi-core implies losing multi-player
10:48:55 <TrueBrain> planetmaker: but I guess it depends how you define "slowing down" ;)
10:49:03 <TrueBrain> I of course talk about CPU ticks ;)
10:49:10 <TrueBrain> you talk about real-time ;)
10:49:12 <planetmaker> yeah, I talked game ticks :-)
10:49:41 <TrueBrain> so even if we write such patch, and want to get the 5000 euro, he can always say: no no :P
10:50:02 <lordnokon> i want to be able to play 5000 of each bloody vehicle :p
10:50:13 <planetmaker> nah, we just need the contract "openttd does not slow down with max vehicle setting".
10:50:22 <planetmaker> we just make a special edition ;-)
10:50:23 <Terkhen> lordnokon: OpenTTD only uses a single core, therefore the other 15 do not help at all
10:50:26 <lordnokon> ill demote that money to the main openttd.org account
10:50:29 <planetmaker> which is snake-openttd or so
10:50:37 <Terkhen> you need a computer with a single core that is more powerful
10:51:07 <Alberth> lordnokon: 5000 of each vehicle, wtf ?
10:51:12 <Terkhen> you should not enter that money into the account until one of us agrees to code that :P
10:51:29 <lordnokon> getting a single core cpu is hardly possible these days
10:51:36 <planetmaker> Terkhen: of course he should. We accept donations ;-)
10:51:37 <Alberth> as long as I don't have to promise a working result :p
10:51:46 <lordnokon> yes why have the option of playing so many vechiles then if you cant?
10:51:59 <Terkhen> lordnokon: the limit is configurable
10:52:03 <planetmaker> lordnokon: why would we limit it to a level where it will work?
10:52:04 <Terkhen> by default it is set to lower, sane values
10:52:30 <lordnokon> yes i know that, but why have it in the first place he you wont be able to use it to its max
10:52:32 <planetmaker> and 5000 is for the people with ueber-computers or those who don't mind a lag
10:52:52 <Terkhen> we don't limit freedom, you can try if you want to :)
10:52:54 <planetmaker> lordnokon: do you honestly suggest that we should limit it to, say 1000 vehicles?
10:53:17 <andythenorth> so there are about 27 ships in FISH....
10:53:21 <planetmaker> for no reason other than insufficiently fast hardware?
10:53:23 <DorpsGek> andythenorth: 135000
10:54:18 *** Devroush has joined #openttd
10:54:45 <Terkhen> I had a game once with about 4000 road vehicles, and almost no vehicles of the other types
10:54:55 <Terkhen> if the limit was set to 1000 it would not have been possible
10:55:02 <CIA-6> OpenTTD: truebrain * r23691 /trunk/src/network/network_gui.cpp: -Fix: signed/unsigned issues, causing asserts for some languages in relation to the serverlist
10:55:25 <andythenorth> lordnokon: what should the limit be? :)
10:57:33 <TrueBrain> btw, when talking about threading we always consider trains. But we can thread RVs, ships and planes, not?
10:57:42 <TrueBrain> trains need to reserve paths, which is much harder
10:57:47 <TrueBrain> but RVs dont really care about other RVs :P
10:58:28 <andythenorth> multi-threaded ships?
10:58:36 <TrueBrain> overtaking is done on a local level
10:58:45 <TrueBrain> RVs rather go through eachother than collide :P
10:59:16 <TrueBrain> and ships are even obviouser about collision :D
10:59:30 <Alberth> until we get RV-wagons :p
11:00:11 <Rubidium> yeah, start by threading the aircraft pathfinding and see how much that speed "up" the game
11:00:14 <TrueBrain> and planes ... no clue if planes have collision detection :P
11:00:17 <andythenorth> nobody's doing rv-wagons :D
11:00:34 <planetmaker> TrueBrain: not entirely. trains and RV interact at level crossings
11:00:34 <TrueBrain> Rubidium: what would your guestimate be on that?
11:00:50 <TrueBrain> planetmaker: well, RVs do with the level crossing tile
11:00:54 <planetmaker> ships and planes would work in parallel to those two. Except loading
11:01:06 <TrueBrain> there is no bi-directional interaction between those 2, if I remember correctly :)
11:01:06 <Rubidium> TrueBrain: it gets worse
11:01:14 <TrueBrain> Rubidium: reasoning?
11:01:24 <planetmaker> loading at stations ;-)
11:01:50 <TrueBrain> well, pathfinding for planes is not really pathfinding :P
11:01:58 <TrueBrain> I guess ships is a better example :)
11:01:59 <Rubidium> TrueBrain: aircraft pathfinding is roughly: determine angle to destination, round to nearest 45 degrees and *go*
11:02:17 <TrueBrain> yeah; you are just being mean :P
11:02:55 <TrueBrain> those things in the water :P
11:03:19 <planetmaker> could work in parallel except interaction at stations and of course terraforming. But that applies to all
11:03:31 <TrueBrain> the PF is not called at stations I would hope :D
11:04:13 <Rubidium> no, but... if it arrives at the station it does some station stuff
11:04:26 *** fjb|tab is now known as Guest22282
11:04:26 *** fjb|tab has joined #openttd
11:04:27 <Rubidium> which is basically called from the path follower
11:04:44 <Rubidium> oh darn it... the path follower can't be async
11:05:10 <Rubidium> it moves vehicles, thus updates the 'where is vehicle X' cache
11:05:22 <TrueBrain> the pathfinder itself can still run
11:05:31 <TrueBrain> the cache update has to be done afterwards
11:05:52 <Rubidium> unless it's a fast ship going multiple units a tick. Then it would move, pathfind, move in a single tick
11:06:41 <Rubidium> instead of pathfind, move
11:06:43 <TrueBrain> move for ships is cheap; the pathfinder is mostly the one that can take forever (at least, it can scan all the water tiles on the map I guess, minus one :P)
11:06:55 <TrueBrain> so it would be just a matter of splitting the moving, and th epathfinding
11:07:16 <Alberth> would it make sense to order ship path-finding by destination?
11:07:39 <TrueBrain> Alberth: what do you mean?
11:08:06 <Alberth> if you have 2 ships for the same destination, do them together, so you can re-use computed distances
11:08:27 <Rubidium> I think it'd be even faster/more efficient if you were to just insert virtual pathfinding waypoints and always go straight from waypoint to waypoint
11:08:28 <TrueBrain> only works if they are at the same tile I guess?
11:08:54 <Rubidium> together with some meta information at those nodes you should be able to reduce the amount of pathfinding significantly
11:09:03 <TrueBrain> Rubidium: CPU vs memory :D
11:10:32 <Rubidium> but multicore CPUs are most efficient when doing lots of computing on little memory
11:11:21 <TrueBrain> and for RV I guess a similar story holds (in many ways I guess)
11:11:23 <Rubidium> doing pathfinding on the map requires randomly accessing loads and loads of memory
11:11:33 <TrueBrain> but it always comes down to, in the end, trains consume the most CPU on large games :P
11:11:58 <Rubidium> TrueBrain: true-ish, but RVs do have a much more limited amount of infrastructure (graph wise)
11:12:06 <TrueBrain> so they are much faster
11:12:13 <TrueBrain> so threading that would give insignificant benefits I guess
11:12:26 <TrueBrain> RVs mostly move very locally
11:12:54 <TrueBrain> and there it would be easier to just cache the path from station A to station B, and reuse it I guess :P
11:12:59 <Rubidium> likewise ships with well placed buoys can be very efficient
11:14:08 <TrueBrain> but, I guess if someone really would like to add threads, that would be a good starting point
11:14:09 <CIA-6> OpenTTD: rubidium * r23692 /trunk/src/network/network_gui.cpp: -Fix: use smallest_x of your children only when you let the children update it
11:14:16 <TrueBrain> doesn't help with trains (at all), but meh :P
11:16:28 <andythenorth> can ships auto-bouy?
11:17:39 *** [1]Mark has joined #openttd
11:17:39 *** Mark is now known as Guest22283
11:17:39 *** [1]Mark is now known as Mark
11:19:34 <TrueBrain> andythenorth: basically what Rubidium suggested ;)
11:23:47 <andythenorth> can the game place bouys on map gen?
11:24:42 <TrueBrain> if we tell it to, why not? :)
11:26:20 <andythenorth> can we then pathfind once to bouys when setting orders?
11:26:24 <andythenorth> inserting the bouys?
11:26:45 <andythenorth> would also solve the incredibly boring 'set bouys for the way back' bit of orders
11:26:55 <TrueBrain> I dont see why not; the pathfinder can get a very nice bonus for using bouys, and then add them as silent orders
11:27:32 <andythenorth> it's possible the pathfinder could screw up and choose bouys either side of a piece of land
11:27:37 <andythenorth> also - terraforming....
11:28:08 <TrueBrain> it has to revalidate once in a while of course
11:28:31 <Alberth> and getting loads of bouys close together
11:28:34 <TrueBrain> but short (Straight) legs are easy to validate
11:30:35 *** valhallasw has joined #openttd
11:49:17 *** tokai|mdlx has joined #openttd
12:26:16 *** andythenorth has joined #openttd
12:30:24 <Jogio> hmm, I come back another time
12:32:10 *** andythenorth has joined #openttd
12:33:39 *** andythenorth has joined #openttd
12:35:39 *** andythenorth is now known as Guest22291
12:35:39 *** andythenorth has joined #openttd
12:40:52 *** Brianetta has joined #openttd
12:43:22 <TrueBrain> lol; guess he only has eye for me :D:D
12:48:11 <michi_cc> Rubidium: You can't even thread the ship ticks without splitting off effect generation.
12:49:00 <TrueBrain> oeh, can I join? :D
12:51:07 <andythenorth> effect generation...
12:51:17 <andythenorth> reminds me of something
12:52:17 <TrueBrain> but you dont know what yet :P
12:52:47 <TrueBrain> reminds me of something
12:52:48 <andythenorth> there's a FS for it, but my DNS won't resolve :P
12:55:36 <andythenorth> I will pay €5,000 for it
12:55:46 <andythenorth> (subject to terms) :P
12:59:09 *** nazcafan has joined #openttd
12:59:58 <nazcafan> I am trying run the 32bpp mode, to no avail for noz
13:01:07 <nazcafan> I have edited the line to blitter = 32bpp-simple in the openttd.cfg file
13:01:36 <nazcafan> and added a data dir in my docs/openTTD/
13:01:43 <nazcafan> pasted a couple of tar files in there
13:02:08 <nazcafan> I don't see any difference and the line gets changed by the program into blitter = "32bpp-simple"
13:02:38 <nazcafan> (the program adds double quotes)
13:02:54 <nazcafan> did I forget anything?
13:03:47 <Terkhen> hmm... sounds right at first glance but I have not used 32bpp for a long time
13:04:07 <Rubidium> what version of OpenTTD are you using?
13:04:15 <Rubidium> and where did you get the 32bpp graphic tars from?
13:05:58 <nazcafan> and the version seems to be 1.1.4
13:06:44 <Rubidium> nazcafan: you need the original Transport Tycoon Deluxe graphics for those
13:07:25 <Rubidium> and even then quite a few won't work due to utter ancientness
13:07:33 <TrueBrain> we need some method to put them in GRFs .... if only someone had written something like that (/me looks at michi_cc :D) :D:D :)
13:07:39 <nazcafan> Rubidium: can't use the the free version?
13:07:46 <SmatZ> nazcafan: prefer 32bpp-anim or 32bpp-optimized, they are faster, and less buggy (32bpp-simple has problems with transparency, iirc)
13:08:14 <michi_cc> TrueBrain: Make our resident quaking export come back :p
13:08:45 <Rubidium> TrueBrain: putting them in GRFs doesn't really help here, as you can't easily add stuff to the original graphics
13:09:05 <TrueBrain> Rubidium: in a GRF they can take over 8bpp like ogfx does, not?
13:09:08 <Rubidium> nazcafan: no, those graphics were 'coded' before the free graphics were developed and as such they are not coded to support them as well
13:10:03 <Rubidium> TrueBrain: yes, but then you're as good/bad off writing an action A sprite replacement with seperate 32bpp pngs next to it
13:10:22 <TrueBrain> which goes in a grf, not? :)
13:10:32 <TrueBrain> well, the pngs dont have to
13:10:35 <TrueBrain> but my point is exactly that
13:10:41 <TrueBrain> 1 file you can download and then it "just works"
13:10:44 <michi_cc> With 32bpp in GRF, someone™ could simply fork OpenGFX and slowly start adding 32bpp sprites.
13:10:48 <TrueBrain> no matching another 3rdparty 8bpp set
13:10:58 <nazcafan> ah, in that case, I may just forget about 32bpp for a while; seems too much of a hassle for now
13:11:40 *** fjb|tab has joined #openttd
13:13:02 <TrueBrain> michi_cc: would there really be a need to fork it? Cant' you just load 2 GRFs, 1 ogfx, the other overwriting them with 32bpp sprites?
13:13:06 <TrueBrain> or would that conflict too much?
13:13:39 <Rubidium> TrueBrain: you can't override sprites of another NewGRF
13:13:51 <michi_cc> I though about creating a real base set that you can select in the game options.
13:15:01 <michi_cc> The "surplus" 8bpp sprites wouldn't matter compared with how big a full set of 32bpp extra zoom graphics would be.
13:15:06 <Rubidium> but I think the "best" solution to getting it all working would be the 32bpp graphics in the GRF and OpenGFX making two builds: a small (stable) 8bpp version, and a larger (currently experimental/unfinished) 8bpp + 32bpp version
13:15:23 <TrueBrain> michi_cc: very very true
13:15:36 <planetmaker> michi_cc: a 'real' base set imho makes most sense
13:16:05 <planetmaker> as otherwise 8bpp authors get bug reports about stuff broken by bad 32bpp stuff thrown on top (been there, seen that)
13:16:20 <Rubidium> the above just needs a param to NML to not export the 32bpp graphics for the simple set
13:16:21 <andythenorth> frosch had some ideas on [yxyz]
13:16:23 <planetmaker> thus I agree with Rubidium
13:17:10 <planetmaker> I guess we can add this 2nd build relatively easily, Rubidium
13:17:28 <planetmaker> we could do that even via gcc with #ifdef
13:20:04 <michi_cc> And a third variant for 8bpp extra zoom? :p
13:20:05 <Rubidium> doing it in NML would be more durable I'd say; especially as you don't need to copy code around for it to be used in other sets
13:20:33 <planetmaker> of course, that's preferential
13:20:50 <planetmaker> michi_cc: well... I'll be happy to start including EZ sprites... but that'll be a LOOOONG walk, I fear
13:20:52 *** vargadanis has joined #openttd
13:21:10 <TrueBrain> well, we have seen that the 32bpp -> 8bpp gives very good results
13:21:36 <TrueBrain> so maybe you end up with a 32bpp base set, which generates into EZ 32bpp, 8bpp (normal) and 8bpp EZ :P
13:21:55 <TrueBrain> would be a lovely uniform set :D
13:27:07 <TrueBrain> wow, callgrind can analyze cache hits/misses on line-by-line base ....
13:30:20 <michi_cc> callgrind is awsome, but sloooooooooow :)
13:30:33 <TrueBrain> it simulates it, no wonder :D
13:30:43 <TrueBrain> I used to work on a FPGA, there the hardware does this shit for you
13:30:45 <TrueBrain> now that is fast :D
13:31:11 <michi_cc> ItsS the only tool I know though that can do profiling on assembly instruction level.
13:31:37 <TrueBrain> I mostly used gprof; so when you talked about this yesterday, and now reading the manual .. I am truly amased what it can track :P
13:31:45 <TrueBrain> of course it 'estimates' how a real computer works
13:32:33 <michi_cc> Yeah, callgrind is for analysing algorithms bascially, not for finding out how to tune your program to the newest Core 785XXY Pro 45K :)
13:32:58 <TrueBrain> I like how it can start recording when you enter a certain function
13:33:16 <TrueBrain> makes me wonder if the graph you showed, if that 50% is really 50% CPU time of the whole application, or only of that tree :P
13:34:48 <michi_cc> I'm not totally sure, but I think I set it to show percentage of total time. The other numbers are 'times called', where you can see I simulated 500 ticks.
13:35:20 <michi_cc> If it was relative time the root node (StateGameLoop() in that graph) would have 100%.
13:35:51 <TrueBrain> so it really is insane much :D
13:36:16 <michi_cc> And children bewlow 0.5% or so absolute time are trimmed.
13:37:24 <michi_cc> The profiled save game is a bit of a worst case scenario though, because it has *a lot* cargo in transport and at stations.
13:37:58 <TrueBrain> a good scenario is a worst case :)
13:38:03 <TrueBrain> an empty map is the best case, but not really helping ;)
13:39:25 <TrueBrain> still compiling KCacheGrid ... from what I read, many things dont work from CLI .. but I have a XFCE based Linux machine :P
13:39:29 <TrueBrain> takes a bit of time (Gentoo :P)
13:42:52 <saua> Hi, on the front page it says that openttd 1.2 beta includes game scripts, are there any documentation on how to write theese?
13:45:17 <Rubidium> saua: basically like AIs, and there is a bit about that on the wiki. Whether something has been written about writing game scripts I don't know
13:45:25 <planetmaker> get some examples. And read the api specs on nogo.openttd.org
13:45:38 <planetmaker> examples = via online content download
13:52:56 <CIA-6> OpenTTD: rubidium * r23693 /trunk/src/saveload/afterload.cpp: -Fix [FS#4859]: hardcode the original defaults for loading old savegames if they could totally mess with the game's behaviour
13:57:11 <CIA-6> OpenTTD: rubidium * r23694 /trunk/src/saveload/afterload.cpp: -Fix (rprev): somehow compilers didn't understand what I meant...
14:15:21 *** HerzogDeXtEr has joined #openttd
14:56:42 <CIA-6> OpenTTD: rubidium * r23695 /trunk/src/ (lang/english.txt screenshot.cpp screenshot.h toolbar_gui.cpp): -Fix/Feature [FS#4916]: make a distinction between fully zoomed in and default zoomed in screenshots
15:02:16 <CIA-6> OpenTTD: rubidium * r23696 /trunk/src/toolbar_gui.cpp: -Fix (r23695): 5 <-> 6... today is not my day
15:02:45 <TrueBrain> Rubidium: I hope next year is your year :D
15:19:07 *** Biolunar has joined #openttd
15:19:31 *** DayDreamer has left #openttd
15:22:12 *** fjb|tab is now known as Guest22304
15:22:12 *** fjb|tab has joined #openttd
15:40:36 <kais58> is there anything relativly simple that needs doing to openttd? I can code to an acceptable standard in java and know my way around code though never messed with a large project such as this?
15:43:14 <Alberth> there is no list of simple things to do, but you could browse the flyspray bugtracker for open problems
15:43:59 <Alberth> but the best is usually something that you like to change
15:44:45 <Alberth> also, it depends on what kind of thing you like
15:45:19 <Alberth> ie GUI stuff, of deep path finder stuff
15:54:04 <Rubidium> kais58: if you're on OSX then there are many OSX specific bugs to be fixed, otherwise the "easy" tasks are basically limited to documenting stuff
15:54:55 <kais58> afraid not, never used any Mac really
15:55:02 *** Adambean has joined #openttd
15:58:20 <Elukka> kais58 sounds familiar
15:58:47 <kais58> so you are that elukka
16:00:52 <Elukka> i wanted to do some stuff too so i ended up making pixels
16:01:50 <lordnokon> have a wonderful new years eve people enjoy it
16:04:04 <kais58> yeah, I heard some people complaining about one of them being one pixel too long/short :D
16:07:23 <Elukka> yeah but a compromise was reached :P
16:07:55 <kais58> the changed it by half a pixel? :D
16:09:21 <Elukka> wanna draw some trains? :P there's a lot to do
16:12:13 <kais58> but no thanks, I'm at the stage where the profesional programmers I know don't scream in horror at the code I've written anymore, so I'll stick to trying that ;)
16:14:13 <Elukka> hm. i'm sure someone needs something coded
16:15:07 <andythenorth> kais58: either browse flyspray - or existing patches in the development forum
16:15:13 <andythenorth> or play the game, then find something that bugs you :P
16:15:42 <Elukka> can you figure out cargo destinations like yacd without killing the cpu :(
16:16:21 <kais58> elukka, that's easy, get a beefier cpu :D
16:17:18 <Elukka> it's a single threaded game with software rendering
16:17:30 <Elukka> someone was working on an opengl graphics engine
16:17:53 <Elukka> it'd be awesome to just have an opengl graphics engine with a locked camera that rendered existing sprites as flat textures
16:18:00 <Elukka> the game would look the same but ought to run a lot better
16:18:55 <Elukka> because you have a humongous processing unit in your computer that's devoted to running graphics
16:18:57 <Rubidium> does it support thousands of different textures?
16:19:17 <Elukka> with openttd it's not being used for anything
16:20:43 <Elukka> if your cpu is capable of rendering the game (while doing everything else too) then it follows it would run better if graphics were offloaded to the gpu
16:21:00 <Rubidium> do you know what OpenGL does and what its limitations are?
16:21:22 <Elukka> it's a graphics API, like directx
16:22:08 <Elukka> seems extremely unlikely to me it would have some hard limit on textures
16:23:21 <kais58> if it does I imagine it's more than what you need, I know it can certainly render massive images
16:23:33 <kais58> wait openttd is software rendered?
16:24:20 <Rubidium> also... OpenTTD's world isn't like the real world;
16:24:49 <Rubidium> for example, a train is 8 high. Then the catenary (lines) are added on top of that, and then the catenary poles
16:24:55 <Elukka> the gpu is sitting there doing nothing and the cpu doing graphics doesn't do any good for cpu heavy patches like cargo destinations
16:24:55 <Rubidium> over that comes the bridge
16:25:21 <Rubidium> interestingly the top of the bridge level is 8 above the previous height level
16:25:41 <Rubidium> similar things happen with tunnels (where it's even worse)
16:28:05 <Rubidium> what's especially interesting are recolouring sprites
16:30:58 <Elukka> not sure how that's an issue either
16:31:33 <Rubidium> what I remember with the previous opengl attempts was that they ran into many limitations
16:31:42 <Elukka> someone did make the game run on an opengl engine, though it had rudimentary placeholder graphics and i'm not sure how functional it is
16:31:50 *** JoeyJo0 has joined #openttd
16:36:49 * andythenorth knows not much about OpenGL
16:37:11 <andythenorth> but guesses it's best for rendering into a 3 dimensional space
16:37:16 <andythenorth> not a dimetric projection
16:37:23 <Rubidium> reading back there seem to be issues with sprites not being a power of two in size
16:37:29 <Elukka> i think most modern 2D games use 3D engines because it's that much more efficient
16:37:47 <Elukka> can't you have them be a power of two in size and simply have alpha channel for the empty area
16:38:28 <andythenorth> it would take a lot of work to sort out those sprites
16:38:38 <andythenorth> assume top left locked?
16:38:55 <Rubidium> but you have to do it in the code that 'generates' these sprites
16:39:05 <Elukka> yeah there'd have to be some sorting of the sprites
16:39:11 <Elukka> but nothing as huge as opengfx since you could still use the same art
16:39:53 <Rubidium> oh yes... no partial updates
16:40:21 <Rubidium> so we need to send the whole screen every time, instead of only the bits that changed
16:40:36 <Elukka> yup. our computers have a very powerful gpu in them made for just that, though
16:40:54 <Elukka> actually i'm guessing even integrated gpus are better at it than the cpu
16:41:06 <Rubidium> Elukka: but OpenTTD needs to 'render' the windows before passing it to the GPU
16:42:45 <Rubidium> imagine you have the 'toolbar' window opened
16:43:03 <Rubidium> then OpenTTD needs to determine what button to draw where exactly, how big it is and where to draw the lines
16:43:14 <Rubidium> all this information then needs to be passed to the GPU to do the actual drawing
16:44:17 <Rubidium> oh, and let me quote the first lines of the post about someone that made a opengl blitter:
16:44:24 <Rubidium> "Here comes a hardware-assisted OpenGL blitter for OpenTTD!
16:44:25 <Rubidium> Why not hardware-'accelerated' you say? Because it's not necessarily faster"
16:45:24 <Elukka> i'm not sure what hardware-assisted means exactly, but surely it's a lot faster than no hardware rendering at all
16:45:45 <Rubidium> have you completely NOT read the second line?
16:46:00 <TWerkhoven[l]> not if the cpu needs to do more work to get stuff ready for the hw-assisted bit
16:46:24 <Elukka> but openttd isn't a special case, and hardware rendering is more efficient for every other game
16:46:50 <Elukka> yes, rubidium, he says hardware accelerated isn't necessarily faster than hardware assisted, whatever that means
16:47:00 <Elukka> he doesn't say not using hardware at all if faster than using it
16:47:36 <Rubidium> Elukka: he says he calls it "hardware-assisted" because he can't call it "hardware-accelarated" because it does NOT necessarily accelarate it
16:48:03 <Rubidium> if the person that wrote the OpenGL "blitter" says it's not faster, then who are you to claim it is?
16:48:58 <Elukka> can you link to where he's saying it? it doesn't seem to me that he's saying software rendering is faster (which it isn't in any game)
16:49:06 <Elukka> hard to say without context, though
16:49:10 <kais58> he does say it is much faster
16:50:02 <Rubidium> I don't understand you anymore, or English...
16:50:32 <andythenorth> it took years for Photoshop to acquire (minimal) OpenGL acceleration, and that's flakey
16:50:42 <Elukka> photoshop is an image editor, not a game
16:50:49 <Elukka> okay, the way i read the quote is that he said "here's a hardware-assisted blitter, it's not really hardware-accelerated but that wouldn't necessarily be faster than this"
16:51:06 <Elukka> it doesn't seem to me to say "here's a hardware-assisted blitter, i can't call it hardware accelerated because it's actually slower than software rendering'
16:51:23 <andythenorth> how is it different? hmm. z index is different in photoshop
16:51:43 <Rubidium> Elukka: that's not what he meant: "here is an opengl blitter that I cannot call hardware accelerated because it is not necessarily faster"
16:51:55 <Elukka> well, could you link it?
16:52:00 <Elukka> as i said it's hard to get it without context
16:53:34 <Elukka> he isn't saying his blitter is slower than the current software rendering near as i can tell
16:54:10 <Elukka> he says his geforce 7600 gt made the game run at 700 fps with the 32 bit animated palette!
16:54:14 <Elukka> sounds a heck of a lot faster to me
16:54:20 <Rubidium> yes, he isn't saying it is slower, but he is saying it isn't necessarily faster
16:54:24 <Rubidium> Elukka: and what are 700 fps?
16:55:01 <Elukka> he says whether it's faster depends on your computer, and also that it's a fairly experimental implementation
16:55:25 <Elukka> that 700 fps is the gpu finding it absolutely trivial to draw the game's graphics, and they're not bogging down the cpu
16:55:49 <Rubidium> it's easy to 'fake' FPS
16:56:18 <Elukka> are you saying he's faking his results
16:56:32 <Elukka> it does not mean time steps are going hundreds of times faster, because the cpu handles that
16:56:36 <Rubidium> no, I'm saying that FPS is ambiguous
16:56:39 <Elukka> it means, however, that it does not need to handle the graphics
16:56:48 <Elukka> and the gpu finds the graphics extremely easy to draw because it's what it's built for
16:57:19 <Rubidium> but lovely the GPU can draw the frame in 1/700ths of a second, but how much time is spent with sending the data to the GPU?
16:57:41 <Elukka> almost certainly a fraction of the time the cpu would require to draw it
16:57:47 <Elukka> as i said, it works like this in every other game
16:58:24 <Elukka> it's easier to send data to them to have them draw stuff than it is to have the cpu do it
16:59:44 <Elukka> by 'every game' i mean it's a general truth that it's easier to send data to the gpu, and this is why gpus are a huge industry and why everyone has one in their computer
17:00:26 <Rubidium> it's not easier if the game hasn't been developed to use it
17:00:27 <andythenorth> how much stuff actually gets drawn? not a lot
17:00:56 <Elukka> erm. all the sprites in the entire screen
17:00:57 * andythenorth suspects drawing is not the slow part
17:01:01 <Rubidium> as I mentioned earlier... OpenTTD uses tricks w.r.t. perspective that you can't model in the opengl world
17:01:14 <TWerkhoven[l]> openttd runs fine on a singlecore 1.6GHz laptop-cpu, the limiting factor is pathfinding which saturates cpu
17:01:15 <Rubidium> so OpenTTD *still* has to do the sprite sorting and such
17:01:29 <andythenorth> composing the scene is probably significantly slower than drawing it
17:01:38 <Elukka> you make it use the same projection, you use the same sprites, you place them the same way
17:01:39 <Rubidium> but I'll see how many redraws the 32bpp-anim blitter can do in a newly started game
17:01:56 <TWerkhoven[l]> it uses virtually no cpu at all if all there are few to none vehicles
17:02:29 <Rubidium> and the sprite sorting is the expensive bit in OpenTTD (that's O(n^3), where n is the number of visible sprites)
17:03:54 <Rubidium> hmm... 32bpp-anim with animation enabled goes up to a mere 5000 FPS with an empty map and fast forward
17:04:39 <Rubidium> paused it does 'only' 900 FPS, but that's because of the 1ms sleeping (which gets disabled with fast forward)
17:04:51 <kais58> is it not possible to offload pathfinding to another thread?
17:05:12 <Rubidium> at the cost of multiplayer
17:05:16 <Elukka> i think that's one of the things that's possible yet difficult
17:05:37 <kais58> why at the cost of multiplayer?
17:05:59 <andythenorth> Rubidium: need a topic item for this :)
17:06:01 <Rubidium> because then the order in which vehicles more differs on the different clients/server
17:06:17 <andythenorth> it's a valid question, but asked twice daily... :P
17:07:44 *** TomyLobo2 has joined #openttd
17:09:40 <Rubidium> oh boy... that version of OpenTTD is "trolly" old ;(
17:12:57 <andythenorth> new year will consist of baby nursing for me
17:13:36 *** TomyLobo2 is now known as TomyLobo
17:21:38 <Rubidium> with the same method of 'reproduction' in r14405
17:22:33 <Rubidium> sdl + 32bpp-anim -> ~500-700 FPS, sdlgl + opengl -> ~60 FPS
17:23:17 <kais58> does it not go over 60 fps at all?
17:23:29 <Rubidium> basic idea: every 1000 ticks = ms print the counter and reset the counter to 0
17:23:55 <Elukka> yeah, that limits it to your monitor's refresh rate
17:24:58 <Rubidium> more interesting is that with current trunk sdl + 32bpp-anim gives ~900 FPS, and ~5000 FPS in fast forward (yes, SmatZ and others have improved its performance significantly)
17:25:07 * Rubidium has no clue how to turn off vsync
17:25:36 <kais58> depends on how it's enabled, maybe nivdia control panel/catalyst control centre?
17:26:50 <Rubidium> I don't have that crappy driver
17:27:29 <kais58> opengl menu in control panel then
17:30:40 <Rubidium> okay... glxgears jumped from ~60 to ~1400 FPS, but for the GL thing in OpenTTD it didn't do much at all
17:32:25 <Rubidium> it's telling me that it that the vblank mode has been changed just like when starting glxgears, so I assume that it worked right
17:39:24 <Alberth> the x is somewhat rare but random TLAs are quite often used in conversations :)
17:55:52 *** andythenorth has joined #openttd
17:57:33 *** Chris_Booth has joined #openttd
17:59:51 *** LordPixaII has joined #openttd
18:05:06 *** LordPixaII has joined #openttd
18:15:09 *** LordPixaII has joined #openttd
18:26:54 <peter1138> my blitter did partial updates
18:27:04 <peter1138> but it wasn't too efficient
18:27:36 <peter1138> problem with ottd is so much game state changes things cosmetically every tick
18:28:01 <peter1138> if you used display lists to hold a chunk of landscape, you'd have to update each one every tick
18:28:26 <peter1138> if you use display lists for each tile, you need x*y of them :S
18:30:05 <Terkhen> time to go with the family, happy new year everyone :)
18:34:38 *** Markavian has joined #openttd
18:41:20 <andythenorth> nothing says 'new year' like a release :)
18:43:58 *** Progman has joined #openttd
18:45:57 <CIA-6> OpenTTD: translators * r23697 /trunk/src/lang/ (11 files): (log message trimmed)
18:45:57 <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
18:45:57 <CIA-6> OpenTTD: belarusian - 1 changes by Wowanxm
18:45:57 <CIA-6> OpenTTD: czech - 2 changes by SmatZ
18:45:57 <CIA-6> OpenTTD: dutch - 1 changes by Yexo
18:45:58 <CIA-6> OpenTTD: english_US - 13 changes by Rubidium
18:45:58 <CIA-6> OpenTTD: french - 2 changes by glx
18:50:04 <Alberth> andy in about an hour we have a fresh nightly release :p
18:51:43 <Rubidium> more like half an hour ;)
18:51:52 <Rubidium> the build + public takes less than 20 minutes
18:52:11 * andythenorth is trading in new year for child maintenance
18:52:14 <Alberth> such a fast service nowadays :)
18:52:16 <andythenorth> new year is over-rated anyway
19:26:13 <appe_> there is a setting i hate.
19:26:50 <appe_> the let's-allow-trains-to-break-down-alot option.
19:36:19 <appe_> "hi there, im a happy little BROKEN DOWN coal train. ill be happy to BROKEN DOWN get your coal from destination A to BROKEN DOWN destination B!"
19:37:19 <Alberth> that's why you have to pick a reliable engine, and have enough depots for servicing
19:38:55 <andythenorth> or just turn off breakdowns :P
19:38:55 <andythenorth> appe_: what is this non-issue you're moaning about ? :)
19:50:49 *** JVassie has joined #openttd
20:14:35 *** valhallasw has joined #openttd
20:31:01 <andythenorth> I should release a new FIRS?
20:49:37 <Alberth> besides, as father you should be old enough to decide for yourself :)
20:55:51 *** Markavian` has joined #openttd
21:04:19 <Rubidium> Alberth: yeah, only nobodies are here ;)
21:04:46 <Rubidium> andythenorth: ofcourse you should release, but at 00:00 UTC ;)
21:05:01 <andythenorth> who stays up that late? :o
21:05:46 <Rubidium> what? aren't you forced to do that due to the noise outside?
21:06:01 <andythenorth> not in deepest surburbia
21:06:09 <andythenorth> maybe if I was at home in the city :P
21:35:57 *** LordPixaII has joined #openttd
22:03:56 *** JVassie has joined #openttd
22:24:41 <jonty-comp> whee, the yogscast are playing openttd over new years
22:37:30 *** andythenorth has joined #openttd
22:41:07 <__ln__> zomg, happy birthday €uro!
22:42:41 <Sacro> So my new year's eve sat watching yogscast play openttd
22:44:00 *** encoded has joined #openttd
22:45:06 <andythenorth> xUSSR set on bananas looks nice
22:55:10 <peter1138> are they playing it again?
22:56:49 <andythenorth> new FIRS time :)
22:57:02 <andythenorth> done, done, onto the next one...
22:57:14 <andythenorth> can /me complete BANDIT before 2012?
22:57:30 <Rubidium> still 13 hours to go ;)
22:58:19 <andythenorth> I'll have to code really fast :P
22:58:25 <andythenorth> mostly templated though
22:59:14 <andythenorth> no FIRS downloads
22:59:20 <andythenorth> what is everyone doing? :o
23:00:06 <Rubidium> lies andythenorth! ;)
23:00:24 <andythenorth> well that's better
23:00:38 <andythenorth> my work here is done then :)
23:02:26 <peter1138> ah, can't talk on there
23:02:37 <peter1138> gotta purchase a subscription
23:04:11 <Mazur> Happy nwe beer, everyone!
23:12:52 <Elukka> well i'm making pixels
23:12:55 <Elukka> andy, what's changed in firs?
23:13:12 <andythenorth> just tweaked a few buildings
23:23:33 <Rubidium> true, the differences between 0.7.0 and the previous version are minimal at best
23:24:22 <Rubidium> only a bit of readme tweaking and changing the minimum (compatible) versions ;)
23:43:26 *** Zeknurn has joined #openttd
23:53:37 *** supermop_ has joined #openttd
continue to next day ⏵
