IRC logs for #openttd on OFTC at 2022-02-10
⏴ go to previous day
00:07:00 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
00:34:30 *** WormnestAndroid has joined #openttd
01:34:22 *** magdalena[m] has quit IRC (Server closed connection)
01:34:25 *** magdalena[m] has joined #openttd
01:37:50 *** amal[m]1 has quit IRC (Server closed connection)
01:37:53 *** amal[m]1 has joined #openttd
01:38:06 *** linda[m] has quit IRC (Server closed connection)
01:38:10 *** linda[m] has joined #openttd
02:06:37 *** supermop_Home has joined #openttd
03:05:29 *** Wormnest has quit IRC (Quit: Leaving)
03:10:44 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:45:16 *** snail_UES_ has joined #openttd
04:10:18 *** Gustavo6046 has joined #openttd
04:17:31 *** Gustavo6046 has quit IRC (Quit: Leaving)
04:44:27 *** snail_UES_ has quit IRC (Quit: snail_UES_)
04:46:31 *** Gustavo6046 has joined #openttd
04:48:07 *** Gustavo6046 has quit IRC ()
04:48:21 *** Gustavo6046 has joined #openttd
05:06:32 *** OsteHovel has joined #openttd
05:55:27 *** Gustavo6046 has quit IRC (Quit: Leaving)
06:21:04 *** uhren has quit IRC (Ping timeout: 480 seconds)
06:41:33 *** uhren has quit IRC (Quit: Leaving)
07:18:02 *** cathartes has quit IRC (Quit: fly away)
07:31:10 *** andythenorth has joined #openttd
07:54:32 *** sla_ro|master has joined #openttd
08:09:47 *** Flygon has quit IRC (Ping timeout: 480 seconds)
08:10:29 *** _dp_ has quit IRC (Ping timeout: 480 seconds)
08:14:49 *** andythenorth has quit IRC (Quit: andythenorth)
08:22:51 *** andythenorth has joined #openttd
08:35:45 *** supermop_Home has quit IRC (Ping timeout: 480 seconds)
09:41:33 *** Gustavo6046 has joined #openttd
10:33:03 *** Smedles has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** APTX has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** pothyurf[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** christoph[m]12 has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** jeeg[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** ciet[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** milek7 has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** natalie[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** zzy2357[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** jlx_ has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** thelonelyellipsis[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** giords[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** blikjeham[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** karl[m]123456 has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** fiddeldibu[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** Timberwolf has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** einar[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** jeremy[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** leward[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** cacheerror[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** planetmaker has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** nolep[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** dude[m]1 has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** paulus[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** ircer[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** ad5twoknebor[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** yoltid[m] has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** eirc has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** fonsinchen has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** ericnoan has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** jedavies has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** Soni has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** KenjiE20 has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** orudge has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** Flygon has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:03 *** daspork has quit IRC (charon.oftc.net singleton.oftc.net)
10:33:17 *** pothyurf[m] has joined #openttd
10:33:17 *** christoph[m]12 has joined #openttd
10:33:17 *** jeeg[m] has joined #openttd
10:33:17 *** ciet[m] has joined #openttd
10:33:17 *** natalie[m] has joined #openttd
10:33:17 *** zzy2357[m] has joined #openttd
10:33:17 *** leward[m] has joined #openttd
10:33:17 *** jeremy[m] has joined #openttd
10:33:17 *** yoltid[m] has joined #openttd
10:33:17 *** fonsinchen has joined #openttd
10:33:17 *** planetmaker has joined #openttd
10:33:17 *** coherence.oftc.net sets mode: +ovov orudge orudge planetmaker planetmaker
10:33:17 *** ericnoan has joined #openttd
10:33:17 *** cacheerror[m] has joined #openttd
10:33:17 *** einar[m] has joined #openttd
10:33:17 *** KenjiE20 has joined #openttd
10:33:17 *** thelonelyellipsis[m] has joined #openttd
10:33:17 *** jedavies has joined #openttd
10:33:17 *** giords[m] has joined #openttd
10:33:17 *** blikjeham[m] has joined #openttd
10:33:17 *** karl[m]123456 has joined #openttd
10:33:17 *** nolep[m] has joined #openttd
10:33:17 *** fiddeldibu[m] has joined #openttd
10:33:17 *** dude[m]1 has joined #openttd
10:33:17 *** paulus[m] has joined #openttd
10:33:17 *** ircer[m] has joined #openttd
10:33:17 *** ad5twoknebor[m] has joined #openttd
10:33:17 *** Timberwolf has joined #openttd
10:33:17 *** Smedles has joined #openttd
10:33:17 *** daspork has joined #openttd
10:37:07 <peter1138> Mum, I'm staaaaaaarving!
11:11:03 * Gustavo6046 throws a NaN sandwich at peter1138
11:41:04 <Eddi|zuHause> you misspelled "nand switch"
12:00:15 *** WormnestAndroid has quit IRC (Read error: No route to host)
12:01:15 *** WormnestAndroid has joined #openttd
12:18:20 <peter1138> Avoided so far, to my knowledge.
12:37:36 <peter1138> I wonder if my phone warns me about sus texts. I had a phoney (hah) phone call that it warned me about once.
13:36:23 *** Gustavo6046 has quit IRC (Remote host closed the connection)
14:28:09 *** D-HUND is now known as debdog
14:42:10 <supermop_work> LordAro: here they just started sending everyone the tests
15:07:12 <nielsm> so I had a thought... which may not be new... but would it be possible to parallelise vehicle ticks (pathfinding etc) if the vehicle ticks were split into two: planning and execution. the planning step is only allowed to examine the world, and only allowed to touch some designated "planned action" fields on the vehicle being planned. the planning runs in parallel. the execution then runs in
15:07:12 <nielsm> serial, well-defined order, and performs the actions calculated for each vehicle
15:09:46 <nielsm> there might then be some cases where a vehicle might not executed the planned action, maybe? like trains crossing a signal will only do it if the planned action is still safe, and road vehicles on a level crossing that become reserved by a train just as the RV is about to enter the tile
15:10:47 <nielsm> like, track reservations for path signals, the train would plan which track it wants to reserve, and then in execution the trains get to actually reserve the track in order, and if a train can't execute the reservation it instead waits
15:11:21 <nielsm> I _think_ that would make it possible to run all the heavy work in parallel
15:16:08 <nielsm> it would probably change the simulation outcome in some situations, but it should still be deterministic as long as the planning step of a vehicle tick does not modify any world state
15:18:19 <Rubidium> I'm quite not sure waiting is the right solution. Why would two trains entering a (big) station and planning to use the same platform block one from entering another free platform? You would get sporadic bug reports of trains that, for no apparant reason, stop
15:19:10 <nielsm> yeah I'm thinking that maybe vehicles that fail their planned action should be put back in a queue for a second (and third etc) run at planning and execution
15:19:27 <nielsm> so it repeats until all vehicles are satisfied
15:22:29 <Rubidium> if you got the time and energy to try, it's definitely worth a try
15:23:22 <Rubidium> I'm quite interested to see how much the improvement you can get with that would be, but don't have the spare time to invest in such a project
15:47:37 *** Gustavo6046 has joined #openttd
16:22:49 *** Smedles has quit IRC (Ping timeout: 480 seconds)
16:22:58 *** Smedles has joined #openttd
16:24:10 *** frosch123 has joined #openttd
16:29:25 <frosch123> nielsm: my assumption is: the pathfinder is not that important, it uses a lot of caching, so parallized access is probably a nightmare. however stuff like "vehicle acceleraton" could be parallelized and runs way more often than pathfinders
16:30:02 <frosch123> also, newgrf stuff can be mostly parallelized, if you get rid of some global state that does not need to be global
16:30:29 <frosch123> hmm, i think tb has a roadmap somewhere for parallizing viewport draing
16:34:23 <TrueBrain> Did some attempts, gave lovely speeds up.. but also requires lot of refactoring to make it sane :D
16:45:10 <nielsm> ah right... newgrf is a danger point yeah
16:45:36 *** gelignite has joined #openttd
16:45:51 <frosch123> only the ottd implementation
16:46:07 <frosch123> it has some "static" in places that should be "thread_local"
16:56:49 *** Wormnest has joined #openttd
17:00:50 *** Gustavo6046 has quit IRC (Quit: Leaving)
17:00:57 *** Gustavo6046 has joined #openttd
17:01:49 *** Gustavo6046 has quit IRC ()
17:34:37 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
17:57:48 *** Kitrana1 has quit IRC (Read error: Connection reset by peer)
18:00:38 *** Kitrana has joined #openttd
18:09:47 *** andythenorth has quit IRC (Quit: andythenorth)
18:12:17 <nielsm> hmm, the newgrf execution stuff mostly isn't so bad actually, the big joker is persistent storage and its usage of a Pool type
18:15:56 <nielsm> and I'm thinking _current_company should be thread local too
18:20:09 <frosch123> there are very few places which are actually allowed to modify persistent storage
18:20:25 <frosch123> drawing certainly is not :)
18:20:36 *** Kitrana1 has joined #openttd
18:21:10 <frosch123> nor is vehicle movement
18:21:36 <TrueBrain> now I am curious what was up with viewport again .. hmm
18:21:58 *** jottyfan has joined #openttd
18:22:08 *** andythenorth has joined #openttd
18:22:29 <TrueBrain> I have too many local branches :D
18:23:31 <TrueBrain> ah, yes, I just added a massive queue in the viewport .. :D
18:26:42 *** Kitrana has quit IRC (Ping timeout: 480 seconds)
18:30:22 <TrueBrain> ah, and yes, it needed classification, as _vd is just an ugly hack ..
18:33:00 <frosch123> though "thread_local" always looked like a hack to me :)
18:33:51 <TrueBrain> very easy to screw up too :P
18:56:00 <TrueBrain> it might surprise everyone in here, but using memory you didn't initialize doesn't work
18:56:06 <TrueBrain> sadly, it takes a few minutes to figure out you are trying that :D
18:56:09 <TrueBrain> stupid compilers not telling me
19:02:55 <Rubidium> might require you to enable more warnings, or maybe something like -fsanitize=memory
19:05:03 <nielsm> frosch123 wow, the usage of that _temp_store is just ugly
19:06:14 <frosch123> it's zeroed before every grf call, but some results are read after the grf call
19:06:51 <frosch123> i do not remember whether it is actually memset, or whether there was some state how much memset was needed
19:07:04 <frosch123> iirc i measured what was faster, and it was measureable :/
19:14:15 <TrueBrain> I assume you memset A LOT :P
19:17:05 <nielsm> memset'ing a memory size known at compile time probably allows the compiler to generate much tighter code, so I can imagine that being the faster
19:18:39 <frosch123> so saving about 64MB of zeroing
19:19:56 <nielsm> that almost feels more like an insurance against newgrf authors trying to assume that the contents of temp registers stays around in specific ways between some callbacks
19:20:20 <frosch123> haha, yes that's why the zeroing was added :)
19:20:51 <frosch123> originally it was not reset, then grfauthors tried to pass data between callbacks, relying on the order ottd would execute callbacks etc
19:21:05 <frosch123> i added the zeroing to kill those attempts with fire
19:21:33 <frosch123> there was also one bug where one grf read an "uninitialised" register, so it's behavior changed when other grfs wrote to it :p
19:22:44 <Rubidium> if you're going to do the NewGRF stuff in parallel, you probably need to reset the temp storage for each iteration. Right? As different amount of cores might yield different orders in which things get processed
19:23:58 <frosch123> no? you only need to make _temp_storage thread_local (not necessarily with the key word)
19:24:20 *** andythenorth has quit IRC (Quit: andythenorth)
19:26:05 <nielsm> there's a bunch of places around the code calling action chains that reads the register contents back then, yeah. I'm wondering if it'd be nicer to have to query the spritegroup resolver object for the contents of the registers rather than invoking a global...
19:26:27 <Rubidium> but you *can* still pass information between callbacks (for 64k callbacks), so if I'm fine with it not working all the time... desync ensues if the newgrf calls are done in parallel and scheduling of the callbacks differs between clients
19:26:32 <frosch123> nielsm: yes, that sounds right
19:27:00 <frosch123> Rubidium: GetValue checks whether they were assigned, and returns 0
19:27:36 <Rubidium> so the memset is totally useless then?
19:29:18 <frosch123> Rubidium: the storage itself is not reset. only the "initialisation tracking" needs resettings when the "counter" is exceeded
19:29:25 <nielsm> I pushed another commit to my branch now, dealing with _temp_store
19:31:17 <frosch123> GetSpriteGroupTemporaryRegister is just GetRegister renamed?
19:31:39 <nielsm> because that name just rang too generic to me
19:32:24 <frosch123> can I bargain for "GetTemporaryRegister"?
19:32:59 <frosch123> the "SpriteGroup" confuses me :)
19:33:32 <peter1138> "SpriteGroup" is from old TTDPatch naming
19:34:03 <frosch123> the storage is not owned by the SpriteGroup. it is owned by the ResolverObject
19:34:57 <peter1138> Well the SpriteGroup is just an instruction on what to do.
19:35:36 <peter1138> And the basic TTD original one is the group of sprites depending on loading state, hence SpriteGroup.
19:35:36 <nielsm> you get your will :) renamed
19:36:28 <frosch123> peter1138: that thing is still called spite_group in NML :)
19:37:01 *** andythenorth has joined #openttd
19:37:28 <TrueBrain> holy crap, viewport.cpp really is one big mess
19:37:32 <TrueBrain> people just did what-ever in that file :P
19:38:00 <frosch123> i am sure it was improved at least 5 times :)
19:38:14 <TrueBrain> it is more ... it is all in 1 single file
19:38:23 <TrueBrain> and headers all over the place defining what is in there
19:38:42 <peter1138> frosch123, legacy eh
19:48:29 <andythenorth> people are talking here? :o
19:48:36 <andythenorth> and not even about infosec or lunch?
19:48:49 <peter1138> Well I did just have dinner?
19:49:13 <andythenorth> I am making carbonarra
19:49:17 <andythenorth> or however it's spelt
19:50:21 <TrueBrain> split away 1500 lines from viewport.cpp, and it is still 2000 lines :P
19:50:56 <peter1138> Maybe I should've cycled, but it's 3 deg C
19:51:25 <frosch123> andythenorth: italian or german carbonara?
19:51:37 <andythenorth> I only know italian kind I think
19:51:40 <andythenorth> the other kind is?
19:53:26 <frosch123> the italian one contains eggs. other ones contain cream and no eggs
19:53:40 <andythenorth> yeah ok so often in the UK it uses cream
19:53:48 <andythenorth> but the kind I'm making is eggs
19:59:09 <peter1138> As sure as eggs is eggs
20:00:37 <andythenorth> I've made scrambled-eggs-in-spaghetti
20:02:54 <frosch123> does it optimise this better in newer versions?
20:15:28 <glx> it's temporary and deleted before return
20:15:41 <frosch123> it gets worse when you know that it also allocated a pool slot there :)
20:16:01 <frosch123> bzt yes, purchase list is a mess
20:16:10 <nielsm> yeah for one it's the actually allocating in the pool and stuff
20:16:43 <nielsm> I discovered it because I tried making the Vehicle class abstract to see if I was missing anything somewhere
20:16:55 <glx> and it's the abstract one because it can be rail or road
20:23:45 <_dp_> hm, if it allocates in gui code, can't that desync the pool?
20:25:10 <frosch123> it also allocated in command test runs
20:25:33 <TrueBrain> (only last commit is interesting, rest is moving code)
20:25:58 <TrueBrain> does consume slightly more memory
20:27:46 <TrueBrain> what glitches differs from run to run, but is stable inside a run (so always the same tile, etc)
20:29:01 <TrueBrain> ah, _draw_bounding_boxes is faulty ..
20:29:14 <LordAro> "minor graphical glitches"
20:29:18 <TrueBrain> and _draw_dirty_blocks
20:29:23 <TrueBrain> that makes sense ..
20:29:53 <TrueBrain> fucking endless globals :P
20:30:33 <glx> remember the good old include file with all the gloabal vars
20:30:34 <frosch123> call them singletons :)
20:30:54 <TrueBrain> yeah, singletons access by "extern ..." :P
20:30:55 <frosch123> also, i have no idea in which thread the spritecache runs by now
20:31:10 <TrueBrain> the game doesn't have that many threads :P
20:32:35 <glx> I hope it's not in write to disk thread :)
20:44:26 <TrueBrain> AddressSanitizer: heap-use-after-free
20:45:20 <TrueBrain> GetSprite cannot be called from the drawing thread .. the irony
20:46:39 *** ChanServ sets mode: +v tokai
20:46:48 <frosch123> yeah, SpriteCache is an issue :) it ties into that fileio stuff and all that magic
20:47:06 <TrueBrain> he should have fixed that the last time he touched it :P :D
20:47:55 <TrueBrain> right, and I have to fix a DrawDirtyBlocks location, as otherwise it draws in the wrong place :D
20:48:04 <TrueBrain> so there is something going on there too :P
20:48:37 <glx> GetSprite in the wrong thread had a nice effect with apple touchbar IIRC
20:48:44 <frosch123> oh, the fileids no longer exist, so that's an improvement at least
20:49:19 <andythenorth> on the plus side, touchbar is consigned to history
20:50:10 <TrueBrain> now the question is .. what function do I add a mutex too to prevent it (for now) :P
20:50:59 <frosch123> GfxInitSpriteMem and GfxClearSpriteCache probably
20:51:24 <TrueBrain> in GetRawSprite causes a deadlock
20:51:28 <frosch123> though probably not inside them but in the places they are called from
20:52:38 <TrueBrain> in GfxClearSpriteCache does the trick
20:52:58 <TrueBrain> well, for most of the times :D
20:53:16 <frosch123> LoadSpriteTables is my best guess for now
20:54:12 <frosch123> GfxLoadSprites is even better
20:54:18 <frosch123> there is already bliter stuff there
20:54:24 <TrueBrain> yeah, but it happens on GetSprite
20:54:43 <TrueBrain> RandomAccessFile::ReadByte() /home/patric/projects/OpenTTD/OpenTTD/src/random_access_file.cpp:110
20:56:21 <TrueBrain> so GetSpriteCache entry is being closed while the thread switches
20:57:26 <TrueBrain> yeah, SpriteCache->file is being closed while it is still used
20:57:27 <glx> main thread manages the cache
20:57:37 <TrueBrain> "main" thread doesn't exist
20:57:44 <TrueBrain> we have a drawing thread, and a game thread :P
20:58:03 <TrueBrain> (as strictly seen, for most OSes, the main thread is the OS thread handling events .. :P)
20:58:10 *** ioangogo has quit IRC (Read error: Connection reset by peer)
20:58:21 *** ioangogo has joined #openttd
20:58:31 <glx> when loading or generating a new game
20:59:05 <TrueBrain> so in the end, GetSpriteCache is a bit the issue ... can I cheat .. hmm
20:59:30 <glx> and OSX was crashing because it wanted to draw on the touchbar too early
20:59:39 <frosch123> i think height/width/x_offs/y_offs is needed by both threads
21:00:01 <frosch123> while the actual sprite data could be exclusive to the drawing thread, if you ignore stuff like original mapgen :p
21:00:51 <TrueBrain> still not sure where it actually crashes ..
21:00:53 <TrueBrain> I am ingame already
21:01:08 <frosch123> i thought height/width/x_offs/y_offs would be read at start, and the spritecache would only handle the spritedata... but apparently i was wrong :)
21:01:33 <frosch123> TrueBrain: maybe you read two sprites at a time from the same file
21:01:39 <TrueBrain> it seems like the file is closed for some reason .. does it open a grf file for every sprite it doesn't know yet?
21:01:46 <frosch123> so both game and video thread fseek the same file handle
21:02:01 <TrueBrain> that doesn't result in a double-free attempt
21:02:04 <TrueBrain> or a use-after-free attempt
21:03:26 <TrueBrain> seems the RandomAccessFile is closed
21:03:35 <TrueBrain> that was the word I was looking for :P
21:06:33 <TrueBrain> I would think that if I am in-game, no more files are loaded, right?
21:08:19 <frosch123> i also think they remain open
21:08:38 <TrueBrain> that is what is confusing me about this :P
21:09:08 <frosch123> well, can you breakpoint the destructor? :)
21:09:41 <TrueBrain> lol, part of the issue is that Vehicle routines get the sprite to find the bounds :)
21:11:54 <TrueBrain> now ReusableBuffer<SpriteLoader::CommonPixel>::ZeroAllocate(unsigned long) keeps on crashing :D
21:12:39 *** ioangogo has quit IRC (Read error: Connection reset by peer)
21:12:51 *** ioangogo has joined #openttd
21:13:26 <TrueBrain> okay, added a recursive-mutex in GetRawSprite fixes it for now :P
21:13:40 <frosch123> how long does it take to crash? can you still measure some performance improvement? :p
21:13:52 <TrueBrain> with 32bpp, the difference is very clear :)
21:16:49 <TrueBrain> without, FF is ~300 fps
21:16:57 <TrueBrain> with, FF is about ~700 fps
21:17:10 <TrueBrain> graphical framerate in both cases is like 10fps .. because .. well .. I am rendering a lot of nasty shit :P
21:18:11 <TrueBrain> mind you that this is a debug build :P
21:18:58 <TrueBrain> dbg: [misc] [blitter] 9140312 us [avg: 91403.1 us]
21:19:03 <TrueBrain> 100ms offloaded from the game-thread :P
21:20:00 <TrueBrain> just ugly as fuck, with the mutexes :P
21:20:44 <glx> improvement should be visible when zoomed out
21:21:04 <TrueBrain> where do you think that number above comes from :D
21:23:13 <TrueBrain> so it really helps .. we just need to find a clean way to move the SpriteCache to the drawing thread :P
21:23:25 <TrueBrain> and passthrough the non-sprites in a clever way or something :)
21:25:13 <TrueBrain> it is funny how far apart the game-speed and draw-speed can get now, in very big games, without FF
21:25:33 <TrueBrain> DrawString is also not thread-safe :P
21:25:37 <TrueBrain> Layouter crashes from time to time
21:26:02 <TrueBrain> no clue why the draw-thread is doing layout stuff
21:26:21 <TrueBrain> Layouter::ReduceLineCache();
21:26:27 *** gelignite has quit IRC (Quit: Stay safe!)
21:26:31 <TrueBrain> well, that is easy to solve ;)
21:26:53 <TrueBrain> the other one is AfterLoadGame
21:27:07 <TrueBrain> runs UpdatePosition on signs, which causes the Layouter to be called
21:27:11 <glx> again game thread managing cache it doesn't really use
21:27:48 <TrueBrain> InitializeWindowsAndCaches is also called from game-thread
21:28:00 <TrueBrain> yeah ... finding all these places will be a bitch :D
21:28:27 <TrueBrain> we need to find a clever way to move them one by one, or something
21:29:52 <TrueBrain> AfterStationTileSetChange also calls Layouter
21:30:06 <TrueBrain> so I guess adding a mutex is the easiest way out :D :D
21:30:14 <glx> for station sign position yes
21:30:16 <TrueBrain> you get a mutex, and you get a mutex :P
21:30:24 <frosch123> we could add a "assert(this_thread::get_id == foobar)" to all functions :p then we know where they are called
21:30:50 <TrueBrain> honestly, some preprocessor that makes a heatmap of that wouldn't be the worst idea
21:30:56 <TrueBrain> just show which functions were active on what thread for a run
21:31:44 <TrueBrain> nielsm: so, 10 more minutes? :D
21:33:17 <nielsm> I think I may want to go to bed now, actually. have a doctor's appointment early tomorrow
21:33:57 <nielsm> but first, smoke test with a release build
21:36:34 * andythenorth always thinks bed, followed by 'just this thing'
21:36:39 <andythenorth> then 3 hours later
21:37:13 <nielsm> wow, 15 fps on wentbourne
21:38:47 <frosch123> is that good or bad?
21:41:01 <nielsm> and full speed on prozone 13
21:41:40 <LordAro> needs a test on an unmodified version to actually be meaningful :p
21:44:13 <nielsm> 12.1 might be a tad slower on wentbourne, and no difference (or better) on prozone 13
22:05:41 <nielsm> oh right... sleeping it was.
22:05:58 <nielsm> was just admiring how much work it's gong to be to untangle these movement controllers
22:06:38 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
22:07:23 *** sla_ro|master has quit IRC ()
22:14:00 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:46:07 *** andythenorth has quit IRC (Quit: andythenorth)
23:39:25 *** jottyfan has quit IRC (Quit: jottyfan)
23:49:47 *** ChanServ sets mode: +v peter1138
23:49:48 *** ChanServ sets mode: +v blathijs
continue to next day ⏵
