Back to Home / #openttd / 2011 / 11 / Prev Day | Next Day
#openttd IRC Logs for 2011-11-20

---Logopened Sun Nov 20 00:00:58 2011
00:56-!-Eddi|zuHause [] has quit [Remote host closed the connection]
00:56-!-Eddi|zuHause [] has joined #openttd
01:22-!-Adambean [] has quit [Quit: Gone fishing]
01:53-!-andythenorth [] has joined #openttd
02:14-!-andythenorth [] has quit [Quit: andythenorth]
02:33-!-andythenorth [] has joined #openttd
02:37-!-DayDreamer [] has joined #openttd
02:40-!-sla_ro|master [~slaco@] has joined #openttd
02:55-!-SmatZ- is now known as SmatZ
02:56-!-|Terkhen| is now known as Terkhen
02:56<Terkhen>good morning
03:03<Rubidium>moin Terkhen
03:08<CIA-6>OpenTTD: rubidium * r23271 /trunk/src/ (fontcache.cpp fontcache.h openttd.cpp strings.cpp): -Codechange: don't repeatedly initialise and free the freetype library
03:14-!-Kurimus [] has joined #openttd
03:14-!-Pulec [] has joined #openttd
03:29-!-Devroush [] has joined #openttd
03:52*andythenorth needs rack trams
03:52<andythenorth>RoadTypes :P
03:53<Rubidium> <- OpenTTD in mono ;)
03:56<Rubidium>(mini)moni ;)
03:57<Terkhen>nice :)
03:57<Terkhen>hi planetmaker
03:58<@planetmaker>looks very nice
04:07<@peter1138>andythenorth, maybe you should delve into the code some time ;)
04:14-!-snack2 [] has joined #openttd
04:23-!-JVassie [~James@] has joined #openttd
04:24-!-Progman [] has joined #openttd
04:25-!-Alberth [] has joined #openttd
04:25-!-mode/#openttd [+o Alberth] by ChanServ
04:30-!-Neon [] has joined #openttd
04:32<andythenorth>peter1138: I started once...
04:33<andythenorth>got quite stuck quite soon
04:33*andythenorth is not short of other distractions :P
04:50-!-pjpe [] has quit [Quit: ajax IRC Client]
04:52-!-Arafangion [] has quit [Read error: Connection reset by peer]
04:58-!-Arafangion [] has joined #openttd
05:05-!-Cybertinus [] has joined #openttd
05:07-!-mahmoud [] has joined #openttd
05:34-!-snack2 [] has quit []
05:35-!-DDR [~chatzilla@] has joined #openttd
05:44-!-DDR [~chatzilla@] has quit [Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928224508]]
05:46-!-TGYoshi [~TGYoshi@] has joined #openttd
06:11-!-MNIM [] has quit [Remote host closed the connection]
06:15<Eddi|zuHause># 1 Extended offline Completed without error 00% 1082 -
06:15-!-hanf [] has joined #openttd
06:21*andythenorth wonders if articulated vehicles can build articulated vehicles...
06:22-!-Wolf01 [] has joined #openttd
06:27<@peter1138>andythenorth, no, obviously :)
06:27<andythenorth>empiricism agrees with you :P
06:27*andythenorth will have to write some actual code
06:34-!-APTX_ [] has quit [Ping timeout: 480 seconds]
06:50<CIA-6>OpenTTD: rubidium * r23272 /trunk/src/ (gfx.cpp gfx_func.h): -Codechange: pass the initial font size to DrawString and friends
06:52<CIA-6>OpenTTD: rubidium * r23273 /trunk/src/ (5 files): -Codechange: allow passing a MissingGlyphSearcher to CheckForMissingGlyphs (default to the language pack strings)
06:52-!-Elukka [] has quit []
06:56<CIA-6>OpenTTD: rubidium * r23274 /trunk/src/ (5 files in 2 dirs): -Add: internal support for a monospaced sprite font
06:59<CIA-6>OpenTTD: rubidium * r23275 /trunk/src/ (fontcache.cpp fontcache.h openttd.cpp strings.cpp): -Codechange: allow loading of the monospace (freetype) font at another moment than the other fonts
07:00<andythenorth>if a template has more #ifdef than nfo, is it a template any more?
07:00<+michi_cc>Eddi|zuHause: How much of CETS do I "break" with ?
07:01<Eddi|zuHause>hm... let me check
07:01<CIA-6>OpenTTD: rubidium * r23276 /trunk/src/ (strings.cpp strings_func.h): -Codechange: add the answer for the question whether we're looking for monospace fonts in the searcher
07:02<CIA-6>OpenTTD: rubidium * r23277 /trunk/src/fontcache.cpp: -Codechange: fallback font support for fontcache
07:02<Eddi|zuHause>michi_cc: if it "breaks" too much, could it be grfv8 only?
07:03<+michi_cc>No, because it isn't at all about NewGRFs but about OpenTTD internals (that are unfortunately exposed at some places).
07:04<CIA-6>OpenTTD: rubidium * r23278 /trunk/ (8 files in 2 dirs): -Add: monospaced sprite font with the same characters as the normal font
07:10<CIA-6>OpenTTD: rubidium * r23279 /trunk/src/fontcache.cpp: -Codechange: try to prevent slanted and skinny fonts with fontconfig. This should generally make the fallback choice better legible
07:13*andythenorth tries to insert one extra vehicle into trams
07:13<andythenorth>(articulated engine)
07:14<andythenorth>this is stunningly complicated without splitting off a new template :P
07:23<Eddi|zuHause>michi_cc: i think the movement of shorter wagons is better, but the longer wagons need some reviewing
07:25<Eddi|zuHause>michi_cc: and i think the glitches near slopes got bigger
07:26<andythenorth>Eddi|zuHause: I need to convert the tram wagons to count from rear of consist when handling change of properties etc :O
07:27<Eddi|zuHause>andythenorth: what for?
07:27<andythenorth>I think it's the easiest way to handle having 1 or 2 locomotives
07:27<andythenorth>which I'm currently trying to implement
07:27<andythenorth>or I could split templates, but that's bad for maintainability :P
07:30<+michi_cc>Eddi|zuHause: Yes, the result of var 62 will be slightly different with the patch. But as 62 is recent, CETS is the only GRF actively using it I'd guess, so not that much of a problem.
07:30<+michi_cc>It does fix that trains with an indicated length of 1.0 use more than one tile in stations for example.
07:30<Eddi|zuHause>michi_cc: i think the russians may be using it
07:30<CIA-6>OpenTTD: rubidium * r23280 /branches/1.1/ (7 files in 5 dirs): [1.1] -Prepare: 1.1.4-RC1
07:30<andythenorth>in russia, var uses you
07:31<@planetmaker>een then, their code isn't old either, Eddi|zuHause
07:31<+michi_cc>62, not 45?
07:31<Eddi|zuHause>michi_cc: judgin from recent discussion in nml thread, i think so.
07:31<+michi_cc>var 45 isn't affected by that change, it's only 62, which is only ~6 week old.
07:32<Eddi|zuHause>michi_cc: but what i mean is that the sprite sorter now more often does The Wrong Thing (tm) near slopes
07:32<+michi_cc>And if they really use it it's an argument to commit that stuff as fast as possible before anybody else starts using it.
07:32<Eddi|zuHause>at least it appears to me like that
07:33<+michi_cc>In general or for CETS vehicles?
07:34<Eddi|zuHause>i don't have any general vehicles
07:35<CIA-6>OpenTTD: rubidium * r23281 /tags/1.1.4-RC1/ (. src/os/windows/ src/ -Release: 1.1.4-RC1
07:37<+michi_cc>That's probably because the bounding boxes now have the proper length and not 7/8 for every vehicle. So if CETS somehow relied on the longer bounding box to resolve the graphics better this would be different now (Side note: this only applies to the diagonal directions, the bounding box for the other directions is and was always 3x3 regardless of length or orientation).
07:38<Eddi|zuHause>yeah... i'll need to think about that...
07:39*andythenorth ignores idea of articulated tram locomotive :P
07:40<andythenorth>solved that differently
07:44-!-pugi [] has joined #openttd
07:47-!-Zuu_ [] has joined #openttd
07:47-!-frosch123 [] has joined #openttd
07:49-!-hanf [] has quit [Read error: Connection reset by peer]
07:52-!-DayDreamer [] has quit [Quit: Leaving.]
07:59-!-Brianetta [] has joined #openttd
08:15-!-KritiK [] has joined #openttd
08:29<Xaroth>frosch123: up again with heq
08:29<Xaroth>i'll leave it in your good hands
08:29<Xaroth>tb has rcon power if needed.
08:29<@planetmaker>fish and av8?
08:30<Xaroth>not atm
08:30<Xaroth>gotta run, already late
08:30<frosch123>there is still only dutch trams set :s
08:31*planetmaker starts to create a map
08:32<Xaroth>i'll fix it when I'm back.
08:33<Rubidium>frosch123: just download some NewGRFs using rcon
08:34*frosch123 is having fun reading the nogo topic :)
08:34<frosch123>some did some awesome research :)
08:44-!-TomyLobo2 [] has joined #openttd
08:46<@planetmaker>hm... do I need the script during generation? Or how does that work?
08:47<@Yexo>you need it when playing the game
08:47<@Yexo>afaik the script can't save any state in the savegame yet
08:47<frosch123>does nogo just always use the script, or does it already store it in the save?
08:47<frosch123>(like ais)
08:47<@Yexo>I haven't seen code yet to store it in the savegame
08:50-!-TomyLobo [] has quit [Ping timeout: 480 seconds]
08:50-!-TomyLobo2 is now known as TomyLobo
08:52-!-HerzogDeXtEr1 [~Flex@] has joined #openttd
08:54-!-APTX [] has joined #openttd
08:57-!-HerzogDeXtEr [] has quit [Ping timeout: 480 seconds]
08:58<@planetmaker> <-- Xaroth
09:02<@planetmaker>slight update... missed the station NewGRFs
09:07<frosch123>Xaroth is gone
09:08<frosch123>we have to start our own server :p
09:09<@planetmaker>I could fire-up the dev server
09:14*andythenorth should hang out and watch :)
09:22-!-Biolunar_ [] has quit [Quit: All your IRC are belong to us!]
09:22-!-Zuu_ [] has quit [Ping timeout: 480 seconds]
09:23-!-snack2 [] has joined #openttd
09:33-!-glx [glx@2a01:e35:2f59:c7c0:158d:8bda:662a:17f0] has joined #openttd
09:33-!-mode/#openttd [+v glx] by ChanServ
09:39<CIA-6>OpenTTD: frosch * r23282 /trunk/src/ (group_cmd.cpp group_gui.cpp): -Fix [FS#4844] (r23212): CmdRemoveAllVehiclesGroup() was not passed the vehicle type in all cases, but the type is actually not needed.
09:46-!-pugi [] has quit [Ping timeout: 480 seconds]
09:47-!-pugi [] has joined #openttd
09:50<andythenorth>how do I provide smoke for a locomotive with two chimneys?
09:51<Xaroth>planetmaker: if you wnt i can give you access to the machine
09:51<Xaroth>so you can change whatever is needed
09:51-!-Adambean [] has joined #openttd
09:53<Eddi|zuHause>andythenorth: by implementing NewSmoke :p
09:53<andythenorth>what's the spec?
10:06-!-Mazur [] has quit [Remote host closed the connection]
10:08-!-Mazur [] has joined #openttd
10:09-!-Brianetta [] has quit [Quit: Tschüß]
10:17<CIA-6>OpenTTD: rubidium * r23283 /trunk/src/newgrf.cpp: -Fix: [NewGRF] Prevent against writing data for unknown fonts
10:21-!-Eddi|zuHause [] has quit [Read error: No route to host]
10:21-!-Eddi|zuHause [] has joined #openttd
10:25-!-ptr [] has joined #openttd
10:29-!-ptr [] has quit []
10:31-!-Maarten1 [] has joined #openttd
10:39<CIA-6>OpenTTD: rubidium * r23284 /trunk/src/water_cmd.cpp: -Fix [FS#4845]: Pathfinders go haywire when you build a lock over a ship going perpendicular to the axis of the new lock
10:41-!-KritiK_ [] has joined #openttd
10:45-!-KritiK [] has quit [Ping timeout: 480 seconds]
10:46-!-KritiK_ is now known as KritiK
11:00-!-perk11 [~perk11@] has joined #openttd
11:03-!-snack2 [] has quit []
11:11-!-Pulec [] has quit []
11:29<TrueBrain>there, published a new version of NoGo. It now detects scripts, instead of trying to open one :P It still has to be called 'test', but that are minor details ;)
11:29<TrueBrain>Xaroth / planetmaker ^^ :P
11:29<@planetmaker>oi :-)
11:33-!-perk11 [~perk11@] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
11:36-!-Pixa [~pixa@] has joined #openttd
11:37-!-TWerkhoven[l] [] has joined #openttd
11:37<frosch123>so, can we get a server with the game pm prepared?
11:38<TrueBrain>Xaroth is at the movies
11:38<TrueBrain>you will have to wait till he is back I am afraid :)
11:38<frosch123>then i continue trolling :)
11:38<@planetmaker>my autopilot fails for me. I could of course just start the server without
11:45-!-Zuu [] has joined #openttd
11:57<TrueBrain>shit, forgot to fix the bug where on pause, the growth updates are not getting through
11:57<TrueBrain>bah :P
11:58<frosch123>set the right setting then
11:59<frosch123>but, did you actually post new binaries? just fix it now :p
11:59<TrueBrain>fixed; I guess I can put the CF to work again yeah .. why not :)
11:59<Zuu>There are binaries of today on finger.
12:03<TrueBrain>compiling new version then
12:04<frosch123>i guess toyland would be quite an annoying challenge
12:05<frosch123>it has this nasty effect that small house accept sweets, while big houses accept fizzy drinks
12:05<frosch123>so, if the town growths, it stops accepting sweets iirc
12:07<TrueBrain>wrong channel :D
12:08<TrueBrain>now that my friends is a huge: FAIL :D
12:10-!-panna is now known as virrpanna
12:14<andythenorth>so...if you have LH drive set, HEQS is just going to look dumb
12:20<Eddi|zuHause>you can certainly duplicate the sprites with different offsets for LH drive
12:20*planetmaker wondered what Lufthansa had to do with this... :-P
12:21<Eddi|zuHause>if you had nml, you could do this calculation in the template
12:24<z-MaTRiX>Eddi|zuHause<< actively hiding errors from users ;)
12:25<z-MaTRiX>though there are anomalies
12:25<z-MaTRiX>the'd need to not report, or double buffer the results to not show anything
12:27<andythenorth>can we have a cb for offsets?
12:27<andythenorth>then I can do the calculation
12:30<Eddi|zuHause>maybe during graphics callback, one of the 0x100+ registers could contain an offset-adjustment
12:32<andythenorth>shame cpp can't do arithmetic
12:32<frosch123>m4 !
12:33<z-MaTRiX>asm can do anything
12:34<frosch123>you first have to invent a preprocessor called "asm" to give that line any sense
12:35<z-MaTRiX>FASM has one
12:35<z-MaTRiX>and it compiles itself in 0.1 seconds
12:43-!-Progman_ [] has joined #openttd
12:45<@Alberth>andythenorth: use a proper macro processor, like m4
12:46<andythenorth>tbh, there's no gain from doing the arithmetic on the fly
12:46<andythenorth>if every RV needs custom offsets for left-hand-drive-side, then I should just make more action 1s
12:46<andythenorth>although it's twice the number of realsprites to make :(
12:47-!-Progman [] has quit [Ping timeout: 480 seconds]
12:47-!-Progman_ is now known as Progman
13:02-!-valhallasw [] has joined #openttd
13:15-!-DayDreamer [] has joined #openttd
13:16<andythenorth>TrueBrain: can scripts be bound to a specific map? i.e. mostly specific towns
13:16<andythenorth>can / will / is it a good idea /s
13:17<frosch123>you an
13:17<Zuu>It might be a good idea to allow a scenario to bind to a specific goal script.
13:17<TrueBrain>savegames will store the script they used to run with
13:17<frosch123>a scenario will bind a goal script just like ais
13:17<frosch123>and scripts can read town names
13:18<frosch123>so, unless you rename the towns, it should be fine :p
13:18<frosch123>though the script could actualy catch the townid on start, before you rename it :p
13:18<andythenorth>or bind to the id :P
13:19<andythenorth>presumably bundling a newgrf + a script is insane?
13:20<frosch123>industries are quite a newgrf derivate, not much a script can do about their production
13:20<andythenorth>cases would be things like industry closure, which have proven unsolvable
13:20<andythenorth>in newgrf
13:20<Zuu>Probably not, but it depends on if scripts are going to be available as AIs on bananas and thus should be general purpose enough to survive any map.
13:20<Zuu>probably not too insane*
13:20<TrueBrain>I think a script should be able to 'suggest' newgrfs too, with which it works best
13:20<frosch123>i was wondering whether it makes sense to load multiple scripts at once
13:21<Eddi|zuHause>Zuu: you can make a script unavailable for general download, only as a dependency for the scenario
13:21<Eddi|zuHause>frosch123: i do think so
13:21<frosch123>i.e. one for the gameplay, and one for the statistics and admin stuff
13:21<TrueBrain>frosch123: for now, we limit it to one
13:21<TrueBrain>mostly because the implementation becomes so much easier ;)
13:21<frosch123>TrueBrain: sure for now :)
13:21<Eddi|zuHause>one may be too limited
13:21<andythenorth>frosch123: how would they interact? Should a script be able to import another script? Sounds ...explodey :)
13:21<TrueBrain>solving the implementation issue to allow more can be very tricky ;)
13:22<andythenorth>in some respects, FIRS is doing things that are perhaps not best done in newgrf - industry clustering, open dates, and such
13:22<frosch123>maybe since scripts are easy enough, we can just say: you have to combine the source
13:22<frosch123>makes it easier for us: no conflicts
13:22<andythenorth>possibly even some of the placement things - snowline, towns etc should not be in newgrf
13:22<TrueBrain>libraries :P
13:22<frosch123>yeah, the statistics stuff would suit a library
13:23<andythenorth>industry handling library
13:23<TrueBrain>but having 2 scripts active at the same time can be tricky, as you need to be sure they do not collide in settings etc ;)
13:23<TrueBrain>so yeah, via libraries or what-ever is much easier :)
13:24<Eddi|zuHause>hm, ok.
13:24<Zuu>An interesting problem is if all current libraries will need to have a duplicate eddition that uses Goal* instead of AI* or if OpenTTD can handle that.
13:24*andythenorth plots a FIRS library :P
13:24<Eddi|zuHause>must teach the script authors properly
13:24<TrueBrain>Zuu: there are no current libraries that are useful to Goal :)
13:24<Xaroth>TrueBrain: so I should compile new version?
13:24<andythenorth>hmm...could grfs specify certain libraries are needed via action 14? Again, could be explodey...
13:25<TrueBrain>Xaroth: yes please :)
13:25<Xaroth>righty-o then
13:25<TrueBrain>and hurry, we want to play :P
13:25<Zuu>hehe :-)
13:25<andythenorth>what are the game rules? I haven't played MP for ages...
13:25<andythenorth>I'm no good at hardcore coop styles :P
13:25<Xaroth>andythenorth: don't be a dick.
13:25<Xaroth>one rule to rule them all
13:25<@planetmaker>which server, TrueBrain?
13:26<andythenorth>Xaroth: last time I played MP I wasn't too good at that :(
13:26<@planetmaker>and revision?
13:26<andythenorth>I annoyed everyone else with my routes :P
13:26<Xaroth>recompiling new version
13:26<andythenorth>we should go all out, test NoGo, YAIM + YACD :P
13:26<andythenorth>with FIRS tip
13:26<Eddi|zuHause>"wine: could not find the Wine loader" <-- wth did i do wrong?
13:27<@planetmaker>Xaroth: which hash?
13:27<Xaroth>no idea yet :P
13:27<Xaroth>still compiling
13:28<@planetmaker>Will the OpenTTD CF compile, too?
13:28<@planetmaker>For lazy people?
13:28<Xaroth>knowing tb, yes
13:28<Eddi|zuHause>mäh... i guess i should really finally try to figure out a real windows install...
13:28<TrueBrain>the CF has been done for hours already
13:28<andythenorth>shame there's no way to distribute nightly grfs on bananas easily
13:29<z-MaTRiX>Eddi|zuHause<< dd? :)
13:29<TrueBrain>planetmaker: latest :P
13:29<Zuu>the CF build is also now available through OTTDAU for the lazy people :-)
13:29<@planetmaker>oh... a refresh works wonders ;-)
13:29<z-MaTRiX>my win98 install was 1 minutes 30 seconds fdrom a cd in 1998
13:29-!-Devroush [] has quit [Ping timeout: 480 seconds]
13:30*andythenorth lost the binary server
13:30*andythenorth found it
13:30<Eddi|zuHause>z-MaTRiX: let me express my doubts that win98 runs CivV or HeroesVI
13:31<z-MaTRiX>never heard ot those ;<
13:31<z-MaTRiX>btw i had xp too
13:31<z-MaTRiX>but after a full ntfs fail i installed linux
13:33<Xaroth>#1 is running
13:33<Xaroth>WITH heqs this time
13:33<@planetmaker>Xaroth: I prepared a savegame
13:33<frosch123>Xaroth: use pm's save?
13:33<Xaroth>whats so special about the savegame?
13:34<@planetmaker>it has a usable newgrf config
13:34<Xaroth>and which newgrf might that be?
13:35<@planetmaker>some bananas newgrfs, like ogfx+airports, ogfx+industries, brazilian townnames to macht tropical climate, ISR, CHIPS, av8, heqs, fish, TRS
13:35<frosch123>isn't that damn ugly?
13:35<@planetmaker>tropical refurbishment set
13:35<TrueBrain>why not save the newgrf, and give that to him? So he can also generate new maps etc?
13:35<@planetmaker>like we had before
13:35<andythenorth>where is the filter widget on multiplayer window?
13:35<frosch123>oh, i thought town renewal set
13:35<frosch123>but that is ttrs :)
13:36<Xaroth>planetmaker: I prefer randomly generated maps, so the server can just re-set itself over and over again
13:36<Xaroth>.. and it won't break when tb (again) breaks saves :P
13:36<@planetmaker>Xaroth: it's randomly generated...
13:36<TrueBrain>planetmaker: he wants to run it for more than one map ;)
13:36-!-JGR [] has joined #openttd
13:36-!-Illegal_Alien [] has joined #openttd
13:36<CIA-6>OpenTTD: rubidium * r23285 /trunk/src/network/network_content_gui.cpp: -Fix: scanning of content after download didn't work
13:36<@planetmaker>ja, my god. grab the save, make a newgrf preset and save that
13:37<@planetmaker>one _can_ make it complicated
13:37<TrueBrain>yes; you can also give the preset :D
13:37<Xaroth>like providing a save instead of info, yes
13:37<TrueBrain>works two ways, complications :D
13:37<@planetmaker>19:33 planetmaker:
13:38<Xaroth>i want info, not a save :P
13:38<TrueBrain>planetmaker: you seriously don't get that a savegame is just a one time thing? In the order of: giving a fish instead of learning to fish? :)
13:38<frosch123>tb: there is no better way to specify grfs than using a savegame
13:38<Rubidium>TrueBrain: but giving you a set of (unreadable) instructions doesn't work either
13:38<TrueBrain>hihi: why dont we make newgrf presets uploadable to BaNaNaS? :D
13:38<frosch123>it also contains the md5sums and all settings
13:39<@planetmaker>TrueBrain: and the parameters set...
13:39<Xaroth>av8 1.81 or 2.0
13:39<TrueBrain>a newgrf set should do that too, wouldn't it? Anyway, it is a clumpsy way of sharing settings ...
13:39<@planetmaker>... load the damn savegame
13:39<TrueBrain>I had that issue earlier when I asked you about some good settings a few weeks ago :)
13:39<Eddi|zuHause>hm... what linux tool can mount .wim files?
13:40<TrueBrain>would it be hard to make some kind of file which loads the preset like as with a savegame?
13:40<TrueBrain>including parameters etc?
13:40<TrueBrain>so you can easily share such (obvously complex) information?
13:40<Rubidium>we should go from filenames in the config to grfid_md5sum = params I guess
13:41<Rubidium>then you can easily copy it between versions of OpenTTD, *and*... you can possibly download it with bananas when it's on there
13:41<@planetmaker>but that doesn't give you the parameters
13:41<TrueBrain>newgrfs became too complex :D
13:42<@planetmaker>nor the landscape which I made sure fits our purpose
13:42<@planetmaker>they're dead easy
13:42<@planetmaker>load and use...
13:42<Eddi|zuHause>Rubidium: but that still does not solve updating grfs from bananas
13:42<TrueBrain>yet you have a hard time giving the information to someone else :D
13:42<TrueBrain>so 'dead' easy is not thw word I would use ;)
13:42<@planetmaker>because you don't want the info
13:42<@planetmaker>I gave you all you can want
13:42<TrueBrain>see my point?
13:42<Eddi|zuHause>Rubidium: if i update a grf, it should be updated in all presets
13:42<@planetmaker>load. save. re-use
13:42<@planetmaker>no better way THAN a savegame
13:42<TrueBrain>planetmaker: you can keep repeating that, but clearly we (As users) want more than just that :)
13:43<@planetmaker>so, no, I don't see the point
13:43<TrueBrain>so clearly there is a gap here between what you can supply, and we want to get
13:43<@planetmaker>I just see that I spend like looking for a good landscape and stuff for... nothing
13:43<Xaroth>nogo1 is running
13:43<@planetmaker>because of "I want to do it my way"
13:43<Xaroth>with the specified newgrf
13:43<TrueBrain>planetmaker: it is not about a single map; it is about a server running for a few weeks
13:43<@planetmaker>Xaroth: parameter for industries?
13:43<TrueBrain>your map is not sufficient for that
13:43<Xaroth>copied from your save
13:43<Xaroth>= 16 1 3 4 1 1 1 1 1 1 3 1 1 1 1 1
13:44<@planetmaker>dunno the numbers. Configuration ingame rulez
13:44<Xaroth>frosch will be chuffed, no swedish rail o_O
13:44<frosch123>another point why savegames are supiriour to any text info
13:44<@planetmaker>Xaroth: in tropical climate they're not that much of an advantage
13:44<frosch123>Xaroth: why? pm pushed that
13:45<@planetmaker>and mostly I forgot them, but doesn't matter too much
13:45<Xaroth>frosch123: because they weren't in the preset in the save
13:45<Xaroth>so don't look at me.
13:45<CIA-6>OpenTTD: translators * r23286 /trunk/src/lang/ (croatian.txt unfinished/basque.txt welsh.txt):
13:45<CIA-6>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-6>OpenTTD: basque - 1 changes by Thadah
13:45<CIA-6>OpenTTD: croatian - 8 changes by VoyagerOne
13:45<CIA-6>OpenTTD: welsh - 4 changes by kazzie
13:45*andythenorth ponders
13:46<andythenorth>could I disable HEQS if game drive side is left?
13:47<frosch123>andythenorth: there is at least one another set, giving a warning "this set is supposed to be used with rhs driving"
13:50<andythenorth>but not disabling?
13:51<frosch123>no, not so harsh :p
13:52-!-TWerkhoven [] has quit [Quit: He who can look into the future, has a brighter future to look into]
13:52<frosch123>TrueBrain: fix nogo
13:53<TrueBrain>(playing a dog :D)
13:53<frosch123>the towns show no goal again
13:53<TrueBrain>I am playing Saints Row Third
13:53<TrueBrain>I really have to quit that game? :(
13:54<andythenorth>I should update the newgrf wiki to indicate that offsets need to be different for LH drive and RH drive
13:54<andythenorth>what's a good way to explain that?
13:54<frosch123>enable the bounding boxes and make a screenshot?
13:56<andythenorth>do I miss the flag for drive side here?
13:56<andythenorth>I know there's a global varaction 2 for it
13:56<frosch123>there is only that var
13:56<frosch123>why should there be also a flag?
13:57<andythenorth>I want to use action 7 for it
13:57<frosch123>where's the problem?
13:58<andythenorth>there isn't, I misunderstand action 7 :)
13:58*andythenorth is wondering if an offset fix can be scripted by the devzone makefile
13:59<Xaroth>right, nogo #1 is running
13:59<andythenorth>is the required delta for the offset deterministic across all vehicles that have same length reduction?
14:00<@planetmaker>so... one company or many?
14:01-!-TWerkhoven [] has joined #openttd
14:01<Eddi|zuHause>nobody actually solved the payment in IS yet...
14:01<TrueBrain>Rubidium: tbh, if only you could Export and Import prsets, which do it via md5, it would be sufficient I think ;)
14:01<andythenorth>meh, version mismatch :P
14:01<Eddi|zuHause> <andythenorth> is the required delta for the offset deterministic across all vehicles that have same length reduction? <-- i guess so
14:02<XeryusTC>oh, OTTDAU is already updated for NoGo :D
14:03<TrueBrain>Zuu is that awesome yeah
14:03<Xaroth>Yexo: potatoe potatoe :)
14:04<TrueBrain>Xaroth: not really; his URL is better
14:04*XeryusTC will try to get the El Kinky Negro Party to do some NoGo :o
14:04<TrueBrain>goes via the load balancer
14:04<Zuu>XeryusTC: Yep, why download manually instead of "just" updating it :-)
14:04<Xaroth>right, i'll keep that in mind
14:04*XeryusTC hands Zuu a free beer
14:05<Zuu>thanks, but I got quite some beers yesterday night and doesn't really want a beer today :-)
14:05<Eddi|zuHause>anybody has an idea about 3D-acceleration in combination with libvirt/kvm?
14:06<CIA-6>OpenTTD: rubidium * r23287 /trunk/src/table/misc_settings.ini: -Fix (r23274): mono_size is a better name than large_mono for the size variable in the configuration file
14:07<andythenorth>anybody like awk or some such, and want to help fix HEQS? :| :D :P
14:08<andythenorth>or python
14:08<Xaroth>I like python, but i'm too busy working on my admin-port lib.
14:09<CIA-6>OpenTTD: rubidium * r23288 /trunk/src/newgrf_gui.cpp: -Feature: use the monospace font for the NewGRF text windows
14:12-!-ptr [] has joined #openttd
14:19<Eddi|zuHause>ah... great... "this rescue/install DVD will only run flawlessly on HP systems. [cancel]"
14:19<Eddi|zuHause>fuck everybody!
14:21<Eddi|zuHause>of course it tells that _after_ letting me wait to copy 5GB of data
14:21<TrueBrain>Eddi|zuHause: that would take you a long time :(
14:25<Eddi|zuHause>i hate days when nothing works...
14:27<Eddi|zuHause>i have a game that doesn't run which ran before. i have a game that doesn't run and needs a wine patch. i have a wine patch that makes a game run but doesn't apply. i have a wine compile that doesn't run even without patch. i have a windows-install-cd which doesn't install
14:27<__ln__>could be worse, it could rain
14:30-!-ptr [] has quit [Quit: Zzzzzz]
14:31-!-ptr [] has joined #openttd
14:31<Xaroth>up again.
14:31-!-ptr [] has quit []
14:33-!-Devroush [] has joined #openttd
14:34<@planetmaker> <-- Xaroth
14:35<Xaroth>planetmaker: let me load it on the server
14:35<Xaroth>it's on the server, will use it at some point
14:35<@planetmaker>it's the current savegame minus all trains
14:36<@planetmaker>at some point it's pointless
14:36<@planetmaker>either now or scrap it
14:36<@planetmaker>but I guess I'll never provide a savegame anymore
14:36<@planetmaker>seems pointless
14:37<Xaroth>it also seems a bit pointless to have half a dozen people constantly reconnect and whatnot
14:37<Xaroth>but if you want, you can have rcon access
14:38<@planetmaker>no, I don't
14:38<TrueBrain>lol, planetmaker, you just loaded the game in SP and reloaded it on the seed, or?
14:38<TrueBrain>kinda like that approach :D
14:38<@planetmaker>I fixed the trainset
14:38<@planetmaker>so that the game can be continued
14:38<@planetmaker>save -> fix in SP -> load back on server
14:38<TrueBrain>I have to remember that :D
14:38<@planetmaker>standard procedure
14:39<TrueBrain>hehe; you have played too many games :D:D (a positive thing)
14:39<@planetmaker>nah, but I care for the game being played on my servers
14:41<TrueBrain>it is also the way you build etc :)
14:55-!-HerzogDeXtEr1 [~Flex@] has quit [Read error: Connection reset by peer]
14:56-!-HerzogDeXtEr [~Flex@] has joined #openttd
14:58-!-DayDreamer1 [] has joined #openttd
15:02-!-DayDreamer [] has quit [Ping timeout: 480 seconds]
15:19-!-Elukka [] has joined #openttd
15:27-!-Maarten1 [] has quit [Ping timeout: 480 seconds]
15:30-!-DDR [~chatzilla@] has joined #openttd
15:39-!-Kurimus [] has quit []
16:02-!-DayDreamer1 [] has left #openttd []
16:09-!-valhallasw [] has quit [Read error: Connection reset by peer]
16:13-!-valhallasw [] has joined #openttd
16:16-!-Alberth [] has left #openttd []
16:29-!-frosch123 [] has quit [Remote host closed the connection]
16:30<XeryusTC>planetmaker: do you have skype?
16:40<Terkhen>good night
16:46-!-Brianetta [] has joined #openttd
17:03-!-Illegal_Alien [] has quit [Quit: HydraIRC -> <- It'll be on slashdot one day...]
17:04-!-hanf [] has joined #openttd
17:16-!-andythenorth [] has quit [Quit: andythenorth]
17:24<TrueBrain>XeryusTC: OpenTTD needs a TS (Mumble?) server! Skype is for pussies :P
17:25<XeryusTC>TrueBrain: i'm recording skype
17:25-!-ptr [] has joined #openttd
17:26-!-valhallasw [] has quit [Quit: leaving]
17:28-!-Zuu [] has quit [Ping timeout: 480 seconds]
17:29<XeryusTC>making a let's play ;)
17:29<XeryusTC>i'm kind of into recording OpenTTD atm
17:33-!-welshdragon [] has joined #openttd
17:35-!-mahmoud [] has quit [Ping timeout: 480 seconds]
17:36-!-Prof_Frink [] has joined #openttd
17:42-!-TGYoshi [~TGYoshi@] has quit [Quit: Poof]
17:46<z-MaTRiX>what does openttd use for accurate timing?
17:47<Arafangion>z-MaTRiX: openttd has accurate timing?
17:47<z-MaTRiX>donno :)
17:47<z-MaTRiX>framerate limit or game timebase?
17:50<Arafangion>I'm sure it uses something... I was questioning your claim that it was "accurate timing".
17:51<z-MaTRiX>i believe gettimeofday() is our best option for now
17:52<z-MaTRiX>since rdtsc is unstable on most cpus
17:53<Arafangion>And this matters... how?
17:54<z-MaTRiX>well i'm coding and was interested
17:54-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
17:54<Arafangion>Fair enough. :)
17:54<z-MaTRiX>and instead of digging through all the openttd sources, was thinking about i may ask the developers
17:54<z-MaTRiX>maybe they know
17:58<TrueBrain>well, you started off with the assumption OpenTTD has one
17:58<TrueBrain>no clue what makes you think it does :)
17:59<z-MaTRiX>btw SDL has a SDL_GetTicks
17:59<z-MaTRiX>that should be millisecond resolution
17:59<TrueBrain>and this matters ... how?
17:59<TrueBrain>(hihi, sorry to steal your line Arafangion :D)
17:59<z-MaTRiX>well for measuring fps a timer is needed
18:00<TrueBrain>lol .. fps for OpenTTD .. that would be useful?
18:00<+michi_cc>For Windows QueryPerformanceCounter() is likely your best bet.
18:00<z-MaTRiX>or updating the screen accurately timed
18:00<TrueBrain>wihch game would want to update its screen accurately?
18:00<z-MaTRiX>im on linux
18:00<z-MaTRiX>TrueBrain<< welll if i do animation i'd like it to go on constant rate
18:01<TrueBrain>which is totally unrelated to screen updates
18:01<TrueBrain>and, for that matter, to OpenTTD
18:01<z-MaTRiX>ok well in openttd animation is not a real issue
18:01<z-MaTRiX>thats mor elike some slideshow
18:02<TrueBrain>I wonder what patch you are making that adds slideshows to OpenTTD
18:03<z-MaTRiX>well how about an animation for the background of the console window? or options menu?
18:03<z-MaTRiX>like some moving fractals
18:03<Arafangion>TrueBrain: You're welcome to it. :)
18:04<TrueBrain>z-MaTRiX: sounds like a welcome improvement to OpenTTD ........ NOT (hihi, I just Boratted you :D:D)
18:04<TrueBrain>sorry, that was not nice :)
18:04<TrueBrain>I can't imagine something like that to be useful; but feel free to make us a patch and proof us wrong :)
18:04<z-MaTRiX>ok maybe not :)
18:05<z-MaTRiX>just to say something
18:05<z-MaTRiX>its one thing that bothers me though
18:05<z-MaTRiX>the good-old ttd in dos has much higher animation speed
18:06<z-MaTRiX>i guess its related to the SDL_Flip framerate limit
18:06<TrueBrain>you sure about that?
18:07<z-MaTRiX>i'm somewhat sure if the video rendering would be a seperate thread, it would result in an instant speed-up
18:07<TrueBrain>haha; that is just a lie :)
18:07<TrueBrain>but how would that help animation speed?
18:07<TrueBrain>I promise you, on the fastest machine you can find, OpenTTD will still run on the same speed as a new created map does
18:08<z-MaTRiX>if the display function introduces an unwanted delay every refresh, then it cannot result in smooth animation
18:08<Arafangion>TrueBrain: On my machine, actually, OPenTTD is much faster in multiplayer mode than it is in a single-player mode.
18:08<TrueBrain>where do you see non-smooth animation in OpenTTD
18:08<TrueBrain>Arafangion: lol; that is ... very ... weird :)
18:08<Arafangion>TrueBrain: If the architecture was multithreaded, it would run faster. Then again, I run on an Atom D525 system.
18:09<z-MaTRiX>TrueBrain<< like when i click a maglev, and make the viewfinder follow it
18:09<TrueBrain>the assumption anything would run faster threaded, is a lie :)
18:09<JGR>Multithreading would just move the bottleneck elsewhere, and make coding a nightmare
18:09<TrueBrain>it is not a magic powder you can drip over software
18:09<Arafangion>JGR: I'll agree with that.
18:09<TrueBrain>z-MaTRiX: is that animation?
18:09<TrueBrain>animation is the sea you see animating
18:09<TrueBrain>(hence the word: animation)
18:10<z-MaTRiX>click the fast forward at top left
18:10<z-MaTRiX>i was thinking about that
18:10<z-MaTRiX>time goes slow compared to the dos ttd
18:10<TrueBrain>increase the speed of the whole game?
18:10<TrueBrain>no, it should be near identical
18:10<TrueBrain>else someone fucked up something 8 years ago
18:10<TrueBrain>or your DOS emulator is bad, that is also an option
18:10<z-MaTRiX>or i dont have good-enough hardware ...
18:10<@Yexo>z-MaTRiX: and how are you comparing to dos ttd?
18:11<XeryusTC>planetmaker: it may actually not have recorded voice because of some fubar mess up :o
18:11<Arafangion>z-MaTRiX: Move your map so that the far right corner is the only part that's visible... And disable the fancy graphics so that the water is not moving, and compare performance.
18:11<TrueBrain>XeryusTC: lolz .....
18:11<z-MaTRiX>Yexo<< ok i know the whole thing differs
18:11<XeryusTC>because it did record what i did before server reset xD
18:11<z-MaTRiX>resolution is larger too
18:11<XeryusTC>but the long 3 hour conversation is not on my hdd it seems xD
18:11<TrueBrain>z-MaTRiX: well, your 'idea' of the speed of TTD (DOS) might be widly different then the reality
18:12<TrueBrain>it happens a lot to people .. they remember old games differently than they really are
18:12<TrueBrain>install DOSBox, install TTD, and play it. Then compare.
18:12<TrueBrain>(without fast-forward, of course)
18:12<z-MaTRiX>done that
18:12<TrueBrain>now press .. I think F3 in DOSBox
18:12<TrueBrain>that is funny :D
18:12<TrueBrain>or was it F5 ..
18:12<Arafangion>z-MaTRiX's linux system may will have crappy graphics.
18:12<z-MaTRiX>i was talking about fast forward
18:12<TrueBrain>okay, z-MaTRiX, that is something you cannot compare in any sane way :D
18:13<TrueBrain>that is so silly, and has absolutely nothing to do with timing (accurate or not :))
18:13<@Yexo>but dos ttd doesn't even have fast forward, right?
18:13<z-MaTRiX>not timing
18:13<z-MaTRiX>its a different question
18:13<TrueBrain>huh? Where did you change the question?
18:13<TrueBrain>[00:05] <z-MaTRiX> the good-old ttd in dos has much higher animation speed
18:13<z-MaTRiX>that should only demonstrate the botleneck caused by displaying
18:13<Arafangion>Yexo: It does.
18:13<TrueBrain>that sounds like we are talking about timing ..
18:13<TrueBrain>owh, so fast forward is limited by the display, in speed?
18:14<z-MaTRiX>i believe
18:14<TrueBrain>and you know this .. how?
18:14<TrueBrain>a magic bird told you, or did you do any profiling?
18:14<@Yexo>TrueBrain: the magic bird of course
18:14<z-MaTRiX>well i just started to use SDL too
18:14<@Yexo>z-MaTRiX has yet to start looking at the source code
18:14<TrueBrain>I thought I shot down that bird a while ago ...
18:14<z-MaTRiX>and the birds were telling it
18:14<@Yexo>yet he knows everything about why it's limited in speed
18:14<TrueBrain>z-MaTRiX: a piece of advise ... don't come with lies in this channel. They often die fast. Unless you can proof something is true, sure, feel free
18:14<TrueBrain>but what you just said is just gibberish
18:15<Arafangion>Hilariously, the reason is because OPenTTD makes bad decisions in code that gets the current time of day.
18:15<z-MaTRiX>ok well im on it
18:15<z-MaTRiX>currently doing testing and fps meter
18:15<Arafangion>z-MaTRiX: What makes you think the fps is indicative?
18:15<TrueBrain>so come back AFTER you have data, instead of 'guessing' before you do
18:15<TrueBrain>next you are going to tell us we should use voxels, as they are epic!
18:16*Arafangion ... must resist... talking about voxels...
18:16<z-MaTRiX>i was not complaining
18:16<z-MaTRiX>i was asking
18:16<TrueBrain>no, but you are telling lies about the game
18:16<TrueBrain>not in a question. You were stating
18:16<TrueBrain>[00:13] <TrueBrain> owh, so fast forward is limited by the display, in speed?
18:16<TrueBrain>[00:14] <z-MaTRiX> yes
18:16<TrueBrain>that is not asking
18:16<TrueBrain>that is saying you know something
18:16<z-MaTRiX>i believe i did only reply to questions
18:16<TrueBrain>asking is good. Lying is not.
18:17*Arafangion rushes off to work.
18:17<TrueBrain>Arafangion: have a nice working day
18:17<TrueBrain>it is 0017 here .. lolz
18:17<TrueBrain>means you are ... East of me! :P
18:17<z-MaTRiX>[001417] TrueBrain it is 0017 here .. lolz
18:17-!-pjpe [] has joined #openttd
18:17<TrueBrain>Aussie :)
18:18<TrueBrain>you can't go much further :P
18:18<Arafangion>:) And with that, I must take my leave. :)
18:18<TrueBrain>cya :)
18:21<z-MaTRiX>im currently working on an sdl example program that does asynchronous display update
18:21<z-MaTRiX>and comparing it to one that does not have it
18:24-!-TWerkhoven[l] [] has quit [Remote host closed the connection]
18:24<z-MaTRiX>but since SDL_Flip is synchronized to vertical retrace, and SDL is not thread-safe, i guess the SDL_Flip will introduce a random forced delay in the mainloop
18:25<z-MaTRiX>so putting the SDL dusplay update into a seperate thread/process will increase performance in all cases,
18:25<JGR>You generally do not want a loop to run continuously with no delays
18:25<z-MaTRiX>but at minimum, i can have a core function that runs at 10kHz while updating screen data at 60Hz
18:26<JGR>If eeking out extra performance is that critical, investigate triple buffering
18:26<TrueBrain>it is a bold statement, to say it will increase performance in _all_ cases
18:26<TrueBrain>I know plenty in which it wouldn't
18:26<TrueBrain>threads still aren't the holy cure
18:27<z-MaTRiX>until you want to run the display on the second core :)
18:27<JGR>It's not as simple as that
18:28-!-Cybertinus [] has quit [Remote host closed the connection]
18:28<TrueBrain>switching threads is very expensive, so are mutexes ... there is so much more to it then 'just adding threads to make it faster'
18:28<JGR>Generally, for any useful display drawing function, it will need to access some data which is periodically modified by the "main" code
18:28<TrueBrain>if it was so simple to increase performance of _all_ applications by threading it, tiw ould be done much more
18:28<z-MaTRiX>JGR<< yes
18:29<TrueBrain>in many cases it in fact slows down an application, if you are threading the display code ..
18:29<z-MaTRiX>TrueBrain<< i don't care if its not simple, just coding
18:29<TrueBrain>I am just complaining on your statements of 'all' and stuff like that :)
18:29<z-MaTRiX>well i could do a process and have shared memory communication
18:29<TrueBrain>shared memory requires a lock
18:30<TrueBrain>which means the main thread freezes during display updates
18:30<JGR>shared memory would be even worse
18:30-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
18:30<TrueBrain>which makes them fibers
18:30<z-MaTRiX>but i can use threads too...
18:30<TrueBrain>which is juse a useless context switch
18:30<JGR>Process swicthes are even more expensive than thread switches
18:30<TrueBrain>JGR: lol, I missed he said processes, that is even worse yeah :D
18:31<TrueBrain>an inter-process-lock, hehe :D
18:31<z-MaTRiX>now google will find this log on it
18:31<TrueBrain>communication is fine, we have shit for that
18:31<TrueBrain>OpenMP, OpenMPI, you name it
18:31<TrueBrain>locks ... ieuw ....
18:31<JGR>Having locks is better than having horrendous rae condition issues
18:31<TrueBrain>hmm, OpenMP is in fact threading :P
18:32<TrueBrain>JGR: haha, for that you have locks, yes :)
18:32<TrueBrain>but they are very expensive :)
18:32<TrueBrain>and in result, performance will degrade ;)
18:32<z-MaTRiX>and if i just pipe the display data into the display process?
18:33<z-MaTRiX>what will cause performance degradation?
18:33<TrueBrain>'display data'?
18:33<TrueBrain>is that the prepared display, pixel by pixel?
18:33<TrueBrain>as then you can just write it to the video memory directly, much faster
18:33<z-MaTRiX>display command, or the whole buffer.
18:33<JGR>That will cause horrendous performance slowdowns
18:33<TrueBrain>otherwise, ^^
18:34<JGR>Piped data is buffered, marshalled, etc by the OS and that takes time and context switches
18:34<TrueBrain>not to start about locks to avoid race conditions, bus-uses, cache-polution, ...
18:34<JGR>I really don't see the problem with the wait in the loop, in the original question
18:35<TrueBrain>JGR: which original question? :)
18:35<JGR>[23:24:14] <z-MaTRiX> but since SDL_Flip is synchronized to vertical retrace, and SDL is not thread-safe, i guess the SDL_Flip will introduce a random forced delay in the mainloop
18:35<TrueBrain>ah ;)
18:36<TrueBrain>in general, how long does displaying really take?
18:36<TrueBrain>1% of the application? 2?
18:36<JGR>A wait here implies that neither buffer is ready to be written to, and hence there's nothing to do anyway
18:36<TrueBrain>so even if you thread it perfectly, the gain is to be noticed :)
18:37<TrueBrain>on another approach, if you want performance of your display, you don't use SDL :D
18:37<TrueBrain>it has so many compatability layers, ugh
18:37<z-MaTRiX>TrueBrain<< so you say it would have no benefits to have a continuously rolling mainloop, and a parallel snapshotting display thred?
18:37*JGR is unfamiliar with SDL, to be honest
18:37<TrueBrain>z-MaTRiX: for OpenTTD, I am very sure it won't help you
18:37<TrueBrain>in general, it rarely does
18:38<TrueBrain>as you need to lock down the main thread to access information to build your display
18:38<TrueBrain>and those things are expensive like fuck
18:38<z-MaTRiX>no i dont want to lock down my mainloop
18:38<TrueBrain>JGR: SDL is a combination of layers to make it to work on all platforms. This costs a lot of performance :)
18:38<TrueBrain>z-MaTRiX: you have no choice; else you get race conditions, which are worse
18:38<JGR>@ z-MaTRiX, the majority of the main loop would be spent modifying the map/vehicle/etc arrays
18:39<+glx>TrueBrain: and may add some limits too
18:39<TrueBrain>you cannot have a write in any area the display is trying to display, while it is displaying
18:39<JGR>You can't reliably use those same arrays for drawing, when they're being modified
18:39<TrueBrain>JGR: hence the locks ;)
18:39<TrueBrain>there are some achitectures which introduce CoW in memory, which do allow it
18:39<TrueBrain>but that is just really advanced fancy state-of-the-art shit, no user has ;)
18:40<JGR>Those are generally quite trivial structures, and tend to involve things like CAS operations
18:40<z-MaTRiX>TrueBrain<< i was thinking about double buffering...
18:40<JGR>Which are also a bit nasty
18:40<z-MaTRiX>rendering in a buffer
18:40<z-MaTRiX>and then flip that
18:40<TrueBrain>JGR: yup ;)
18:40<TrueBrain>z-MaTRiX: double buffering is commonly used, yes
18:40<@Yexo>z-MaTRiX: before you render you need to know which sprites to render
18:40<TrueBrain>but that is to avoid the user seeing a screen being drawn
18:41<@Yexo>I think that part is way more expensive than the actual rendering
18:41<TrueBrain>but what Yexo says: you are talking about improving a piece of code that takes no time to execute in the first place
18:41<+glx>even dune 2 used double buffering at that time
18:41<JGR>The main point of double-buffering is to have the buffer ready and waiting, as the re-trace occurs, to avoid screen-tearing
18:42<TrueBrain>JGR: to avoid partial screens, yeah
18:42<TrueBrain>can't remember a game which did not do double buffering tbh
18:43<TrueBrain>Alleycat even did ...
18:43<+glx>pong ?
18:43<JGR>Some do triple, but I'm not sure how common that is these days
18:43<TrueBrain>these days it is all not that important anymore
18:43<TrueBrain>3D graphics is another can of shit :D
18:43<TrueBrain>(which is what is used these days ;))
18:43<TrueBrain>AA 8x draws the screen many times for 1 screen :P
18:44<JGR>The strategy seems to be to just let the card handle it
18:44<TrueBrain>(hihi, now I am pushing it, I know :D)
18:44<TrueBrain>nowedays you send: screen-done-building
18:44<TrueBrain>and it does the swapping for you
18:45*JGR has not done graphical coding for ages
18:45<TrueBrain>but okay; the topic was threading the display part
18:45<TrueBrain>then it heavily depends what you consider 'the display part'
18:45<TrueBrain>in general, there is very little to gain there
18:46<TrueBrain>unless you are doing some high-value up-scaling :P
18:46<TrueBrain>but then you should be caching :D
18:46<JGR>It makes sense if the front end and back end aren't really doing the same thing at all
18:46<TrueBrain>JGR: but when does that happen?
18:46<TrueBrain>well, webservers do, of course
18:46<+glx>progress bar ;)
18:46<TrueBrain>a webserver is strictly seen the perfect example of threading the display
18:46<TrueBrain>server sends it to the client, which renders it in its own thread
18:47<z-MaTRiX>i don't get it why are you against multithreading
18:47<TrueBrain>but I am pretty sure that is not what z-MaTRiX is looking for :)
18:47<z-MaTRiX>there is more and more cores in the cpus
18:47<JGR>@ z-MaTRiX, I've written multithreaded code, it's not trivial
18:47<Xaroth>z-MaTRiX: multithreading is a myth
18:47<TrueBrain>z-MaTRiX: who said anyone was against?
18:47<+glx>openttd is multithreaded :)
18:47<z-MaTRiX>you are telling it would not be any improvement.
18:47<JGR>Multithreading is useful for parrallelisable algorithms
18:47<TrueBrain>we are just telling you that it is very unlikely you get a gain by threading the display. But for sure it is not _the_ cure in _all_ cases
18:47<+glx>but only where it's possible
18:48-!-Brianetta [] has quit [Quit: Tschüß]
18:48-!-Brianetta [] has joined #openttd
18:48<z-MaTRiX>The drawing function, and the screen flip function can be threaded too
18:48<JGR>No, they can't we just explained that
18:48<TrueBrain>well, clearly we cannot convince you with words, so I wish you the best of luck making it :D
18:48<TrueBrain>I am not telling you you shouldnt
18:48<TrueBrain>I am just telling you it is unrealistic to expect any improvement
18:48<z-MaTRiX>ahm ok :)
18:49<TrueBrain>and I am very alergic to statements like: "will increase performance in all cases,"
18:49<z-MaTRiX>well its better than 640kB will be enough for everything ;>
18:50<TrueBrain>which Bill Gates btw never said
18:50<+glx>IIRC multithreading experiments were done in openttd, the result was big slow down for single core for a very low improvement for multicore
18:50<TrueBrain>glx: I remember the same :D So it has to be true :P
18:50<TrueBrain>I see posibilities in YAPF to thread ... in Cargodest and stuff .. but in very restrictive ways :)
18:51<z-MaTRiX>well things can be done various ways
18:51<JGR>Hmm, even that is a bit dubious IMO
18:51<z-MaTRiX>a circle's points can be calculated in parallel using 256 processors
18:51<TrueBrain>caching often gives a better improvement (at the expensive of memory)
18:52<TrueBrain>and where in OpenTTD do we do such math?
18:52-!-Swissfan91 [] has joined #openttd
18:52<z-MaTRiX>didnt say that
18:52<+glx>we don't even use floats
18:52<TrueBrain>I calculated the coming and going of weather by using over 100 machines with each 16 cores ...
18:52<JGR>I seem to recall that a previous attempt at improving OpenTTD's performance focused on caching things like height data for each tile corner
18:52<TrueBrain>sure, threading can be very useful. But it doesn't apply to OpenTTD :)
18:52<JGR>I forget where I read that though
18:53<Swissfan91>hi everyone
18:53<TrueBrain>JGR: most of the imrpvoements in OpenTTD come from caching :)
18:53<TrueBrain>or better hash functions :)
18:53-!-TWerkhoven [] has quit [Quit: He who can look into the future, has a brighter future to look into]
18:53-!-KritiK [] has quit [Quit: Leaving]
18:53<TrueBrain>or just the plain old: improve the algorithm :)
18:53<TrueBrain>hello Swissfan91 :)
18:53<TrueBrain>JGR: some O(N**2) to O(N) goes a long way ;)
18:53<+glx>and then we added a VM for AIs ;)
18:53<JGR>Indeed ^^
18:54<TrueBrain>now _those_ can be threaded .... with a lot of work :D
18:54<JGR>Surely the AIs don't have that big an impact?
18:54<TrueBrain>typical example of closely guarded input/output :)
18:54<@Yexo>JGR: they have a very big impact
18:54<TrueBrain>JGR: lolz; they do :D
18:54<JGR>Oh well, I always play without them :P
18:54<TrueBrain>on my machine, 16 AIs can take up to 500ms per tick :D
18:54<TrueBrain>(where a tick normally is 30ms, because of a Sleep of 30ms :P)
18:55<TrueBrain>then again, I did alter the settings a bit :D:D
18:55<z-MaTRiX>or a multithreaded pathfinder ?
18:55<+glx>you increased opcode limit TrueBrain ?
18:55<TrueBrain>glx: :D:D
18:55<Swissfan91>can anyone code NewObjects here?
18:56<TrueBrain>z-MaTRiX: there are posibilities there; just VERY limited once. And all tests so far ahve been very negative in result (and by people who know a lot about threading)
18:56<@Yexo>z-MaTRiX: can't do that as long as every vehicle depends on on the pathfinding results of all previous vehicles
18:56<JGR>Presumably the current OpenTTD AIs work better than the originals, given that they chew that many more cycles?
18:56<@Yexo>JGR: a lot better
18:56<JGR>I've never used the OTTD AI, I must admit
18:56<@Yexo>and a lot more versatile
18:56<TrueBrain>JGR: well, those two are strictly not in relation of course :)
18:56<TrueBrain>but they are much more fun :)
18:57<+glx>and they don't cheat
18:57<TrueBrain>more cycles does not imply better :D
18:57<JGR>Well, I'd hope that the extra cycles were doing *something* useful :P
18:57<@Yexo>depending a lot upon the map type, but I've seen games were very good human players didn't have it easy to beat an AI
18:57<TrueBrain>just they no longer randomly terraform and shit :D
18:57<Xaroth>and hax
18:58<JGR>Hmm, sounds promising
18:58<TrueBrain>and now we are introducing NoGo, a script VM for goals in the game :P
18:58<TrueBrain>even more cycles wasted :P
18:59<JGR>As long as you can turn it off, it's not a problem
18:59<@Yexo>TrueBrain: what was the reason the threading for AIs was removed?
18:59<z-MaTRiX>and what is your opinion of removing the scripting engine from openttd and coding everything in C?
18:59<TrueBrain>Yexo: data-access
18:59<TrueBrain>Yexo: OTTD2SQ
18:59<TrueBrain>Yexo: _current_company
18:59<TrueBrain>want more? :D
18:59<@Yexo>nah,that's enough :)
18:59<+glx>OTTD2SQ is a nasty one :)
18:59<TrueBrain>OpenTTD is not ready for threads like that. But for sur eit is possible, we have shown that :D
19:00<+glx>though if strdup it's result it's ok
19:00<JGR>That one of the landscape arrays?
19:00<TrueBrain>z-MaTRiX: possible; just not userfriendly :)
19:00<TrueBrain>glx: but not 2 threads can do it at the same time ;)
19:00<TrueBrain>so mutexes ;)
19:00<+glx>and deadlock risks
19:00<@Yexo>z-MaTRiX: when NoAI started you could chose between squirrel and C++ for AIs
19:00<z-MaTRiX>deadlocks are your friend
19:00<TrueBrain>strictly, you can still do an AI in C++ :)
19:01<@Yexo>but than we got rid of threads for AIs and the C++ option was no longer viable
19:01<TrueBrain>just nobody can play it :P
19:01<@Yexo>you could run it as client in a multiplayer game
19:02<XeryusTC>gn TrueBrain and Xaroth ;)
19:02<TrueBrain>night XeryusTC :)
19:02<Xaroth>nn XeryusTC
19:03<TrueBrain>Yexo: but if we attach _current_company to the thread storage, make OTTD2SQ part of the instance, lock the main thread and run all AIs at the same time, caching their DoCommands ... it _should_ be possible to massively paralise them :P
19:03<TrueBrain>the API is pretty much contained
19:03<@Yexo>there are quite some calls to openttd core, we'd have to check each of those very carefullly
19:03<+glx>yeah remove globals :)
19:03<TrueBrain>those are only read calls
19:03<TrueBrain>so those are safe
19:03<TrueBrain>as the main thread is standing still
19:04<+glx>globals are bad and should be exterminated :)
19:04<TrueBrain>and 2 AIs reading the same peice of memory .. well .. nobody cares :)
19:04<TrueBrain>and all write commands are done via DoCommands, so fully contained in a (local) queue
19:04<+glx>as safe as MP
19:05<TrueBrain>exactly ;)
19:05<@Yexo>one problem might be that you can't even do a DoCommand while the other AIs are reading stuff
19:05<TrueBrain>that is why I know there is no writing outside DoCommands :P
19:05<@Yexo>I mean not even in TestMode
19:05<TrueBrain>Yexo: you do not execute the DoCommand :)
19:05<TrueBrain>why not?
19:05<TrueBrain>it is also just reading of facts
19:05<@Yexo>because I think some commands do and undo stuff in test mode
19:05<TrueBrain>those would be bad
19:05<+glx>like a player thinking what to do based on what he saw
19:05<TrueBrain>and I realise, one other case
19:06<TrueBrain>where there is global temporary variable ;)
19:06-!-welshdragon [] has quit [Quit: welshdragon]
19:06<TrueBrain>(we have more variants of static varaibles used in functions :P)
19:06<@Yexo>which is?
19:06<TrueBrain>I wonder if things like _cmd_text still exist
19:07<@Yexo>not with that name
19:07<+glx>I think it has been replaced
19:07<TrueBrain>I think it was now part of the DoCommand structure
19:07<TrueBrain>which makes it safe again :)
19:07<TrueBrain>but yeah, Yexo, you might be right there are a few places that will cause issues :)
19:07<TrueBrain>but at least, because it is tightly contained, those are findable :)
19:08<@Yexo>yes, that's true :)
19:08<TrueBrain>so, making AIs threadable is not unthinkable
19:08<TrueBrain>now in terms of performance gain ... I dunno
19:08<TrueBrain>there will be some, in corner cases ... like with 16 AIs ..
19:09<TrueBrain>I am afraid the locking and switching in fact hurts performance in most use-cases :P
19:09<@Yexo>yes, I think so too
19:09<Swissfan91>is there a template for drawing railway station tiles? how do I know how much of a gap to leave for the track?
19:10<@Yexo>never measured anything, but I think the major part of AI time is not spend executing squirrel code but executing test commands
19:10<+glx>station tiles need at least 2 parts
19:10<TrueBrain>Yexo: after NoGo, I might profile those things a bit, to get a visual image of what is going on
19:10-!-Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
19:10<TrueBrain>I am just very curious what takes most time
19:10<TrueBrain>I cant imagine it is Squirrel, as it performed very well during tests
19:10<@Yexo>Swissfan91: did you see ?
19:13<Swissfan91>ah yes, thanks Yexo :)
19:14<Swissfan91>i just have so many ideas - hence the NewObjects, Towns, Industries and now stations :P
19:15-!-sla_ro|master [~slaco@] has quit []
19:20-!-Adambean [] has quit [Quit: Gone fishing]
19:22<Swissfan91>so i need two completely seperate sprites? or in the same sprite sheet? are there any example station sprite sheets floating around i can see?
19:23<z-MaTRiX>they say sprite is cool but i prefer mineral water instead ;/
19:24<Pinkbeast>Swiss> I would do it as two separate sprites in the same sheet, each of which occupies the relevant half of the area.
19:25<Swissfan91>ok, cool.
19:26<@Yexo>Swissfan91: they need to be two separate sprites
19:26<@Yexo>whether or not those are in the same file is completely up to you
19:26<Swissfan91>ah, ok.
19:26<Swissfan91>on an unrelated note - does anyone know if its possible to have a 1x2 newobject tile that is 1 down slope tile and 1 flat tile?
19:26<@Yexo> <- not sure if that does help you, but it's a station newgrf
19:26<Pinkbeast>Well, putting them in two files just lets them get separated from each other.
19:26-!-ptr [] has quit [Quit: Zzzzzz]
19:26<@Yexo>yes, that's possible
19:27<Swissfan91>i sense a 'but' coming :)
19:27<@Yexo>no but
19:27<@Yexo>it's just possible :)
19:28<+glx>some industries do that
19:28<@Yexo>industries are not objects though
19:28<+glx>you just need to do the right callbacks I think
19:29<@Yexo>yep (whereas with industries I don't think you'd need any callbacks at all)
19:29<+glx>remember ECS tourist stuff ?
19:29<+glx>it uses callbacks to analyse terrain (and reject construction)
19:30<Swissfan91>I see. I was thinking of a ski jump, like
19:30<Swissfan91>excuse the link.
19:30-!-Progman [] has quit [Remote host closed the connection]
19:30<@Yexo>that you don't need any callbacks doesn't mean you can't use them for additional checks
19:31<z-MaTRiX>Swissfan91<< according to your google session, you search many porn sites
19:33*Pinkbeast blinks like that was a little out of left field
19:35<Swissfan91>i'm sorry? O.o
19:36<z-MaTRiX>was a tracking spyware comment, you know, google plays bigbrother with you :)
19:36<Swissfan91>man, i'm confused.
19:37*z-MaTRiX playz Sylver - Confused
19:39<z-MaTRiX>i have an ai 9000, should i go for the ati x550 ?
19:48-!-Swissfan91 [] has quit []
20:13-!-enr1x [] has quit [Quit: leaving]
20:19-!-hanf^ [] has joined #openttd
20:24-!-Klaus__ [] has joined #openttd
20:26-!-hanf [] has quit [Ping timeout: 480 seconds]
20:29-!-hanf^ [] has quit [Ping timeout: 480 seconds]
20:54-!-Klaus__ [] has quit [Quit: Leaving]
20:55-!-JGR [] has quit [Quit: quit]
21:06<Xaroth>nn planetmaker :P
21:06<@planetmaker>night :-)
21:06<Xaroth>you said you were going well over an hour ago :P
21:17-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
22:10-!-Devroush [] has quit []
22:11-!-anonvocis [~Marlon@] has joined #openttd
22:11-!-glx [glx@2a01:e35:2f59:c7c0:158d:8bda:662a:17f0] has quit [Quit: bye]
22:22<Eddi|zuHause><Yexo> one problem might be that you can't even do a DoCommand while the other AIs are reading stuff <-- how about issuing a DoCommand will immediately end the AI's tick? results will then be ready at the next tick
22:25-!-rhaeder [] has joined #openttd
22:31-!-rhaeder1 [] has quit [Ping timeout: 480 seconds]
22:49-!-Brianetta [] has quit [Quit: Tschüß]
23:14-!-Kurimus [] has joined #openttd
---Logclosed Mon Nov 21 00:00:03 2011