Times are UTC Toggle Colours
00:09:05 *** andythenorth has quit IRC 00:23:53 <DorpsGek> [OpenTTD/OpenTTD] LC-Zorg commented on issue #8594: NRT - Pathfinder doesn't consider speed limits when calculating a route https://git.io/JtqIG 00:34:24 <supermop_Home> that looks complicated 00:35:26 <supermop_Home> i'll be down for any system that enforces a low speedlimit for dirt roads - except for rally cars which get to go 100mph 01:14:39 *** Wormnest_ has quit IRC 02:15:15 *** TrueBrain has quit IRC 02:16:30 *** TrueBrain has joined #openttd 02:17:53 <DorpsGek> [OpenTTD/OpenTTD] perezdidac updated pull request #8603: Feature: Object class selection string filtering https://git.io/Jts3i 02:18:49 <DorpsGek> [OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering https://git.io/JtXFQ 02:19:22 <DorpsGek> [OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering https://git.io/JtXF7 02:19:40 <DorpsGek> [OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering https://git.io/JtXF5 02:19:50 <DorpsGek> [OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering https://git.io/JtXFF 02:19:55 <DorpsGek> [OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering https://git.io/JtXFb 02:20:08 <DorpsGek> [OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering https://git.io/JtXFA 02:20:30 <DorpsGek> [OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering https://git.io/JtXFx 02:20:35 <DorpsGek> [OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering https://git.io/JtXFj 02:32:12 *** Flygon has joined #openttd 02:32:23 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on pull request #8603: Feature: Object class selection string filtering https://git.io/JtXbg 03:24:30 <DorpsGek> [OpenTTD/OpenTTD] joestringer opened pull request #8679: Fix: [Cygwin] Fix missing uint definition https://git.io/JtXAu 03:31:00 *** D-HUND has joined #openttd 03:34:22 *** debdog has quit IRC 03:37:46 <DorpsGek> [OpenTTD/OpenTTD] joestringer updated pull request #8679: Fix: [Cygwin] Fix missing uint definition https://git.io/JtXAu 04:57:47 *** D-HUND is now known as debdog 05:38:39 *** WormnestAndroid has quit IRC 05:39:53 *** WormnestAndroid has joined #openttd 05:46:50 *** WormnestAndroid has quit IRC 05:47:05 *** WormnestAndroid has joined #openttd 06:07:32 *** snail_UES_ has quit IRC 07:22:25 *** andythenorth has joined #openttd 07:42:46 <andythenorth> yo 07:42:52 <andythenorth> validate my existence! 07:43:01 * andythenorth hasn't been outside enough 07:43:05 *** yoyo[m] has left #openttd 07:43:43 <Eddi|zuHause> does this "outside" still exist? feels like a completely mythical place nowadays 07:47:42 *** sla_ro|master has joined #openttd 08:00:43 <andythenorth> I can see it 08:00:58 <andythenorth> I think it's just a DLC pack though 08:01:02 <andythenorth> maybe can be swapped 08:10:30 *** andythenorth has quit IRC 08:12:57 *** HerzogDeXtEr has joined #openttd 08:13:28 *** andythenorth has joined #openttd 08:46:58 *** supermop_Home has quit IRC 09:16:48 *** argoneus has quit IRC 09:18:27 *** argoneus has joined #openttd 09:23:50 *** jottyfan has joined #openttd 09:56:43 <FLHerne> andythenorth: Your existence is good! You are responsible for most of my favourite grfs, and finding many stupid problems in NML :p 09:59:15 <andythenorth> does that create a meta-game? 09:59:21 <andythenorth> you seem to have got quite into NML :) 10:07:35 *** iSoSyS has joined #openttd 10:12:19 <FLHerne> I did, then I forgot all the things I wanted to do 10:12:23 <FLHerne> + 10:14:20 <andythenorth> ha 10:17:05 *** jottyfan has joined #openttd 10:19:07 <andythenorth> lol @ mac ffwd 22x in a well established running game 10:19:10 <andythenorth> this is new 10:19:33 <andythenorth> oh it's pushing 28x if I move to the map edge 10:24:45 <LordAro> nice. 10:29:11 *** iSoSyS has quit IRC 10:51:27 <andythenorth> it's funny how much opening the train window kills FPS 10:52:04 <andythenorth> dumps FFWD speed to 5x from ~28x 10:52:27 <andythenorth> could it be all those Iron Horse pseudo-variables I wrote? o_O 10:53:29 *** jjavaholic has joined #openttd 11:01:53 * Timberwolf waves the "used so many switch chains you had to change sprite resolving" badge. 11:32:26 <Timberwolf> Blue & Co is getting up to a fair old number of trains now, although I imagine it'll drop a bit as vehicle capacities and speeds improve through 1920s-1960s. 11:33:38 <Timberwolf> Don't think I'm anywhere near the point of LugnutsK-style, "well, looks like I've now built more trains than my computer can handle" yet. 11:33:48 *** WormnestAndroid has quit IRC 11:34:01 *** WormnestAndroid has joined #openttd 11:42:22 *** nielsm has joined #openttd 11:44:48 *** WormnestAndroid has quit IRC 11:45:06 *** WormnestAndroid has joined #openttd 11:47:06 <andythenorth> anyone remember the issues with random_switch? 11:47:21 <andythenorth> frosch reminds me occasionally to not use it, and pick the bits instead 11:47:36 <andythenorth> discord contrib. is having issues with random_switch and PARENT 11:48:06 <andythenorth> I couldn't get that to work as expected ever, and wrote my own code to pick bits 11:48:21 <andythenorth> but multiple other discord contribs assert that it works fine 11:50:51 <FLHerne> andythenorth: With what nml version? frosch fixed it in master, but I don't think there's a release with it 11:50:54 <FLHerne> https://github.com/OpenTTD/nml/commit/f1d73af1ec6110ebc80e30336d918694684e0e50 11:51:21 <andythenorth> thanks, might be relevant 11:51:59 <FLHerne> Probably should be a release, but there's so much churn that '0.5.4' feels like a lie 11:54:06 <Timberwolf> I vaguely recall having a similar issue, not sure how I solved it (or even which set...) 11:56:38 <Timberwolf> OK, so Timberwolf's Roads does the same thing, uses `random_bits` because I couldn't get `random_switch` to work. 11:57:35 <Timberwolf> Probably separate to the PARENT/SELF issues, though? 11:57:53 <andythenorth> probably 11:58:08 <andythenorth> ultimately random_switch is magic 11:58:13 <andythenorth> and getbits is explicit 11:58:37 <andythenorth> less guessing with the non-magic 12:00:42 <Timberwolf> I'm not that consistent, I use `random_switch` for the trams having random vans vs. flatbeds in Road Vehicles, although there I want the opposite of what Greyfur wants (individual sections of articulated vehicle being independent) 12:01:04 <Timberwolf> I suspect that's me being about 3-4 years younger when I wrote that switchblock. 12:01:14 <Timberwolf> My tolerance for magic is definitely lowering with age :) 12:03:14 *** Wolf01 has joined #openttd 12:18:43 <andythenorth> seems I use random_switch for cargo selection, with triggers 12:33:31 <orudge> Hm, running OpenTTD from Steam on Apple Silicon results in the Intel 'version' of the binary being executed, rather than the ARM version 12:33:39 <orudge> I wonder if Valve can fix that one day 12:54:50 *** WormnestAndroid has quit IRC 12:55:07 *** WormnestAndroid has joined #openttd 12:56:49 *** Greyfur has joined #openttd 12:57:25 <Greyfur> Hi all 13:13:26 <andythenorth> hi 13:33:26 <nielsm> orudge: not possible to lipo them together and distribute just one binary? or does steam somehow override that? 13:33:56 <nielsm> (possibly steam only exists in intel version still and because of that it causes subprocesses to also be intel?) 13:37:20 <nielsm> or might it be possible to hack it by making a trampoline of sorts, if the intel binary determines it's running on M1 hardware and the M1 binary is available, relaunch that instead 13:39:01 <LordAro> i feel like that's on Steam to fix, not us 13:39:13 <orudge> nielsm: It's the new behaviour of macOS, to keep the architecture 'sticky' when launching subprocesses by default 13:39:37 <orudge> We do distribute a universal binary 13:39:40 <nielsm> does steam overlay exist/work on mac? 13:39:41 <orudge> and yes, it's a Steam issue to fix really 13:39:52 <nielsm> because that might be a possible explanation 13:39:55 <orudge> I think so 13:40:26 <orudge> OpenTTD performance is still very good even when emulated on the Mac 13:42:07 <TrueBrain> is it emulation? Or more something like transcoding? :D 13:45:20 <nielsm> I'm guessing a kind of JIT translation, with some assumptions that the code is well-behaved (no self modifying code and such) 13:48:40 <TrueBrain> wow, I can increase the speed of FastForward by a fact 5 or so ... by not drawing every single frame when FF 13:49:21 <TrueBrain> (testing on SDL) 13:49:59 <LordAro> https://en.wikipedia.org/wiki/Rosetta_(software)#Rosetta_2 etc 13:51:00 <TrueBrain> in the FPS window, we have "Simulation rate", which I guess is the speed GameLoop is called 13:51:12 <TrueBrain> but what calculates "Graphics framerate"? 13:52:21 <nielsm> the video driver 13:52:41 <nielsm> it measures time betweet draw calls 13:53:04 <nielsm> if you grep for it you'll find a measurement point inserted in every video driver 13:53:29 <TrueBrain> it measures the time between every PFE_VIDEO call, you mean? 13:53:34 <andythenorth> oof naptime :| 13:53:37 <nielsm> yes 13:53:42 <TrueBrain> tnx 13:56:44 <TrueBrain> hmm .. I changed to code to only Paint every 33ms, but the Graphics framerate is a lot higher .. I wonder what causes that .. 13:57:35 <nielsm> do you enter the draw function and then early-exit if the rate is too high? 13:57:47 <TrueBrain> no 13:57:49 <TrueBrain> I don't call it 13:58:13 *** Extrems has quit IRC 13:58:17 *** Extrems has joined #openttd 13:58:56 *** snail_UES_ has joined #openttd 14:00:17 <TrueBrain> ah, fixed it 14:01:07 <TrueBrain> I now often hit 9999 frames/s on FF :D 14:01:11 <TrueBrain> that is a lot better :D 14:02:10 <TrueBrain> next question .. can I draw the game at 60fps while keeping the simulation lower ... I think I can :) 14:02:29 <nielsm> it should be possible yes 14:02:42 <nielsm> well... maybe 14:02:45 <TrueBrain> "draw_lock" in SDL is a bit weird .. it feels like it is unused :P 14:02:53 <nielsm> at least move the mouse around and update the screen 14:03:11 <TrueBrain> nielsm: sorry, the question was a bit rhetorical :P 14:03:12 <nielsm> but you can't draw GUI since that needs to update in the game loop 14:05:46 <TrueBrain> owh, draw_lock and _draw_mutex are friends, okay, that makes a bit more sense 14:08:21 <TrueBrain> okay, running the GUI at 60fps 14:08:23 <TrueBrain> now that feels a lot smoother 14:13:07 <TrueBrain> lol, okay, SDL can't keep up at 60fps when fast forwarding :D 14:14:06 *** supermop_Home_ has joined #openttd 14:14:19 <DorpsGek> [OpenTTD/team] LouisDeconinck opened issue #141: [nl_NL] Translator access request https://git.io/Jt145 14:15:31 <TrueBrain> nielsm: what part of the GUI updates in the GameLoop btw? 14:17:11 <nielsm> everything, I'm pretty sure 14:17:47 <nielsm> and GUI drawing isn't thread safe, if you tried drawing the GUI on another thread than the game loop is running it would be touching inconsistent game state 14:18:03 <TrueBrain> ofc, but I am not talking about threads :) 14:18:18 <TrueBrain> but you mean the drawing of the windows specifically, I guess? 14:18:26 <TrueBrain> (sorry, things something get a bit lost in translation, so just double checking :D) 14:18:33 <nielsm> I think part of the game loop is visiting every window and telling it to update 14:18:57 <nielsm> and if a window has something to update it marks a region of itself dirty, causing it to be painted later 14:21:06 <TrueBrain> I am ofc mostly interesting in window position changes 14:21:14 <TrueBrain> but that is tight into the mouse events handler 14:21:29 <TrueBrain> which is done in InputLoop 14:21:32 <TrueBrain> which is done via GameLoop 14:21:46 <nielsm> yes moving a window involves redrawing the screen in various places, and redrawing the screen involves looking at game state 14:22:25 <supermop_Home_> good morning 14:22:25 <nielsm> you'd need to rework the entire windowing system to be layered instead of clippping region updates for it to be realistic 14:22:26 <TrueBrain> okay, I can do that at 60fps too, it seems .. lets see .. how far can I push this :P 14:22:41 <TrueBrain> I do not see why that would be the case? 14:22:50 <nielsm> (layered window system: every window has its own private surface to paint, and the window manager overlays the windows as a post processing) 14:23:10 <TrueBrain> I can just run InputLoop more often, not? :) 14:23:29 <nielsm> no 14:24:09 <nielsm> if I move a window a bit and that uncovers part of the terrain, that uncovered terrain needs to be painted. that terrain might contain a vehicle from a newgrf, and to draw that vehicle you need to invoke a callback 14:24:20 <nielsm> and now you're deep into touching game state 14:24:41 <nielsm> actually I'm not sure what you're doing 14:24:57 <TrueBrain> yes, I think you are filling in a lot of blanks :P 14:25:01 <nielsm> is this the case where the game is running at full speed with time to spare? 14:25:24 <TrueBrain> does it matter if I call the NewGRF callbacks, say, twice a tick? Does that do anything bad? 14:25:40 <nielsm> because when I think of decoupling GUI updates from game updates I think of improving the case where the game is running at reduced speed 14:25:41 <TrueBrain> (just to give me an idea how weird NewGRF is :D) 14:26:07 <TrueBrain> I am pretty much doing the reverse, but mostly, I am a bit exploring why our video drivers are the way they are 14:26:14 <TrueBrain> as they are a bit different from most other games I know :) 14:26:35 <TrueBrain> and surprisingly, most of our code is already split between deltas and game-ticks 14:26:42 <TrueBrain> which is a lot better than what I remember from 2007 :P 14:27:07 <TrueBrain> the only big unknown to me, is NewGRFs 14:28:25 <TrueBrain> which brings me to my main question: if I would to call, just to give a random example, call the "draw" NewGRF callbacks 4 times a tick, would that change anything bad? 14:28:30 <nielsm> if you want to handle the case where the game is running at full speed (game loop completes in e.g. 20 ms or less) and just let the GUI update faster using the spare cycles on the main thread, then yes I think you should be able to run the input loop and painting loop multiple times between game updates 14:29:03 <nielsm> uh I think it's possible to make badly behaved NewGRFs that could be assuming they only get called once per tick and change behaviour 14:29:13 <TrueBrain> so that would be an issue 14:29:14 <TrueBrain> hmm 14:29:19 <nielsm> but I think that might also cause them to change behaviour depending on whether the vehicle is on screen or not 14:29:29 <TrueBrain> yeah, it would 14:29:33 <TrueBrain> so those NewGRFs would be bad 14:29:39 <TrueBrain> also depends how many viewports are open on them 14:29:40 <TrueBrain> etc etc 14:29:43 <TrueBrain> okay, so that shouldn't be an issue 14:29:44 <TrueBrain> goo 14:29:45 <TrueBrain> d 14:29:57 <TrueBrain> basically, what I noticed in our video drivers: we run "draw" in thread, and gameloop in mainthread 14:30:10 <TrueBrain> which is a bit against most advices, which say: handle events + draw in main thread, and do the rest in another thread 14:30:29 <TrueBrain> there is where my adventure of the day started 14:30:56 <TrueBrain> that made me realise, currently, if you FF, the game also draws every frame 14:31:04 <TrueBrain> like .. why would it need to draw at 200 frames/s 14:31:09 <TrueBrain> so I decoupled that 14:31:13 <TrueBrain> which works better than I expected 14:31:19 <TrueBrain> and it always draws at 33 frames/s 14:31:22 <TrueBrain> giving much more time to do FF 14:31:32 <TrueBrain> now the next step .. I have 140Hz monitors 14:31:40 <TrueBrain> and doing cursor movement at 30fps is really annoying to me 14:31:43 <TrueBrain> can I do that at 140fps? 14:31:49 <TrueBrain> turns out: yes, yes you can 14:31:59 <TrueBrain> and now I am doing window movement at 140fps too 14:33:59 <TrueBrain> next, see if I can change the CSleep(1) to hit our deadlines a bit better 14:36:21 <TrueBrain> this combined with OpenGL gives a crazy good result 14:53:48 *** andythenorth has quit IRC 14:54:12 *** andythenorth has joined #openttd 14:54:20 <TrueBrain> oeh, another quick-win: do not sleep if you are already taking too long to process a frame .. that should improve the speed of huge games 14:54:27 <TrueBrain> those are, ironically, faster when FF is on 14:54:38 <_dp_> TrueBrain, btw, mb you can figure out what's wrong with #8219 while you're at it ;) 14:55:35 <TrueBrain> what I am doing might possibly resolve that :P 14:57:55 <TrueBrain> it might nott :P 14:58:27 <TrueBrain> hmm ... should I make screen refresh configurable .. force it to 30? 60? 144? :D 14:58:39 <TrueBrain> it has an impact on gamespeed 15:14:55 <LordAro> TrueBrain: nice 15:25:17 <TrueBrain> despite now drawing at 144fps, fast-forward is still quicker than without my patches :D That is funny 15:26:10 <TrueBrain> and the amount of frames/s is a lot more stable :) 15:26:44 <TrueBrain> but that is no surprise once you know that CSleep(1) takes ~6ms 15:27:00 <orudge> TrueBrain: can you detect the monitor refresh rate? Though documentation I've seen suggests that may not be entirely reliable... 15:27:10 <TrueBrain> exactly that :) 15:27:43 <TrueBrain> I think that setting it to 60fps is a modern approach which works for most games 15:27:52 <TrueBrain> and a huge improvement over our current 30 :D 15:28:48 <TrueBrain> too bad our game runs every 30ms, and you kinda want to refresh screens every 33ms (or 16ms) 15:31:03 <_dp_> daylength or riot! :p 15:31:15 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #8680: Several improvements to SDL2 video driver https://git.io/Jt1ur 15:31:24 <TrueBrain> nielsm: I would love your input on ^^ if you have some spare time 15:32:51 <TrueBrain> I love how the CI fails on lines not mine :P 15:33:13 <TrueBrain> owh, no, just on the wrong commit 15:33:15 <TrueBrain> fine 15:33:52 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8680: Several improvements to SDL2 video driver https://git.io/Jt1ur 15:34:18 <TrueBrain> Eddi|zuHause: if my memory serves me correct, you machine has a bit of issues to gain good fast-forward speeds, right? Would you mind checking if ^^ is an improvement for you or not? 15:37:18 *** Flygon has quit IRC 15:39:54 <TrueBrain> funny, Win32 was already capped on fps for graphics, as it is done via WM_PAINT :) 15:48:34 <TrueBrain> performance gain there with the same tricks is a lot less :) 15:49:20 <LordAro> TrueBrain: ooh 15:49:36 <LordAro> if i remember, i'll test it out on actual-Linux tonight for you 15:49:49 <TrueBrain> sweet :) 15:49:55 <TrueBrain> on SDL, this should really be noticeable 15:50:06 <LordAro> that is some silly amount of speedups though 15:50:22 <LordAro> you're reducing the impact of adding opengl support :p 15:50:26 <TrueBrain> it does reduce the amount of speedup the OpenGL branch gives :) 15:50:27 <TrueBrain> yes :) 15:50:30 <LordAro> haha 15:50:54 <TrueBrain> owh, the same tricks on Win32 driver work against it, as WM_PAINT is on another interval 15:51:01 <TrueBrain> that gives a very ugly result 15:56:56 <TrueBrain> which is rather annoying, as it makes FF there too a lot faster .. but as the drawing is out-of-sync, it drops to ~20fps, instead of 30 :P 16:01:32 <TrueBrain> funny, my screens are running at 144Hz, but WM_PAINT only runs at 60Hz 16:04:58 *** Progman has joined #openttd 16:15:52 *** andythenorth has quit IRC 16:24:53 <Eddi|zuHause> TrueBrain: FFWD speed increases from ca. x3.5 to x4.5 on this large semi-busy map 16:25:07 <TrueBrain> good 16:25:09 <TrueBrain> tnx :) 16:30:41 *** andythenorth has joined #openttd 16:33:00 <Wolf01> I remember the old FFWD where the game didn't draw anything when minimised and if you forgot FFWD enabled when you returned to the game a century passed in no time :D 16:36:29 *** glx has joined #openttd 16:36:29 *** ChanServ sets mode: +v glx 16:42:03 <TrueBrain> @calc 1000 / 16 16:42:03 <DorpsGek> TrueBrain: 62.5 16:43:17 <Wolf01> glx: found the solution for the settings assert? 16:43:34 <glx> we have 2 versions :) 16:43:43 <Wolf01> Yeah :D 16:43:54 <glx> #8677 and #8678 16:44:26 <Wolf01> Shit, I can't read anymore from the bed... 16:46:04 *** Wormnest has joined #openttd 16:46:48 <FLHerne> TrueBrain: Would things actually break if a tick was made 10% slower? 16:47:15 <FLHerne> (on all clients, or multiplayer certainly would) 16:48:38 <nielsm> you mean increasing the tick length to 33 ms? 16:48:39 <glx> in theory everything should still work with a slower tick 16:48:49 <nielsm> that shouldn't really change anything 16:49:09 <nielsm> since the game already works fine when ticks take longer due to a complex game world 16:49:36 <glx> as long as ticks are synchronised in multiplayer there's no issue 16:49:46 <LordAro> TrueBrain: might be worth adding FFWD modes other than "as fast as possible" at this point 16:49:54 <nielsm> in multiplayer the server controls the tick speed anyway 16:50:06 <glx> indeed 16:50:10 <nielsm> the clients run at the speed of the server, if a client can't keep up with the server then that client eventually gets kicked 16:59:59 <andythenorth> bloody newgrfs eh 17:00:02 * andythenorth reading back 17:07:07 <Wolf01> Nice, I pressed the suspension button by mistake and I didn't even get disconnected 17:14:01 <Timberwolf> andythenorth: delete everything other than Action A for 1.12? 17:14:06 <andythenorth> maybe 17:14:27 <andythenorth> pre-computed values for graphics chain :P 17:14:49 <andythenorth> you get 16 angles, re-triggered in stations and depots 17:15:04 * andythenorth wonders if newgrf actually has any effect on FPS 17:15:37 <andythenorth> $someone could profile the mad Horse things 17:17:15 <Timberwolf> It can get pretty extreme, 1.10 you can only have about 300 or so Timberwolfean trains of reasonable length in a game because the sprite resolving takes so long. 17:18:02 <Timberwolf> Maybe that's optimisable, I never really looked to see if there's a quicker way to do things in the set. 17:19:19 <TrueBrain> FLHerne: biggest issue is all the people that "calculated" game-time to real-time, I guess .. not sure if that is an issue :) 17:20:20 <Timberwolf> 1.11 is much better, although I suspect you still hit a # of trains limit earlier than with vanilla vehicles or a newgrf with shorter switch chains. 17:20:33 <nielsm> nothing depends on that, all time specifications in-game are in days/months/years 17:20:51 <FLHerne> andythenorth: What is the intention of all this stuff in FIRS? It seems crazy https://dpaste.com/AWQ9G5JJF 17:21:18 <glx> andythenorth: newgrf (especially complex varact2 chains) have effects on game loop speed 17:21:22 <TrueBrain> FLHerne: so some articles on the wiki etc would be wrong, if such change would be made .. biggest "problem" I can think of :P 17:21:28 <FLHerne> Some of them are entirely duplicates except for hide_sprite 17:21:48 <nielsm> my didn't-get-very-far game speed patch concept would change it so some game elements are measured in real time (e.g. industry production measured in items per minute) while other parts are measured in calendar time 17:22:06 <nielsm> and calendar time progression is decoupled from economy time progression 17:22:55 <FLHerne> (NML makes things worse by generating huge amounts of pessimal NFO because it's stupid, but I don't understand why it's like this to start with) 17:23:09 <TrueBrain> owh, lovely, on windows, a sleep() returns just before it expires .. on linux just after .. 17:23:15 <TrueBrain> ugh .. I hate randomness between OSes :P 17:23:52 <glx> TrueBrain: on windows it depends on timer resolution ;) 17:24:06 <glx> but we "fixed" that 17:24:18 <TrueBrain> not really what I mean, at least, I think we are talking about two different things 17:24:28 <TrueBrain> GetTickCount(); Sleep(10); GetTickCount(); 17:24:36 <TrueBrain> on linux, the time between those 2 tick counts is >= 10 17:24:42 <TrueBrain> on windows, I get values like 8 and 9 too 17:24:46 <glx> ah the call 17:24:46 <andythenorth> FLHerne that stuff dates from the conversion of FIRS to nml by y*xo etc, I suspect it was done to test the nml spec 17:24:47 <TrueBrain> which is ... mildly annoying 17:26:30 <andythenorth> FLHerne it has been on my agenda to get rid of it, because I suspect it increases compile time 17:26:42 <andythenorth> but when I test (by commenting it out) I think it's not very significant 17:26:52 <andythenorth> been a while since I tried 17:27:27 <andythenorth> did I proceduralise any of it yet? :P 17:27:34 <FLHerne> Some of it, I think 17:27:41 <FLHerne> It only makes it more incomprehensible 17:27:44 <andythenorth> glx but can you measure the effect? :P 17:28:03 <TrueBrain> glx: well, you were right, it has to do with resolution .. GetTickCount has a shit-resolution 17:28:10 <andythenorth> FLHerne can you tell what it's actually doing, or should I expand on that? :) 17:28:24 <TrueBrain> between 10 and 16ms resolution 17:28:28 <TrueBrain> that is .. garbage 17:28:34 <FLHerne> I think I understand 17:28:44 <glx> there's a high resolution tick function IIRC 17:28:57 <FLHerne> But my understanding would never lead me to even consider writing it this way, so it might be wrong :p 17:28:59 <LordAro> well there must be something else that other games use 17:29:04 <TrueBrain> I cannot believe we depend on that ticker ... 17:29:20 <andythenorth> FLHerne I wouldn't write it this way, it's a particular approach to code, it's probably better than mine TBH :P 17:29:23 <LordAro> what with 144Hz & 240Hz monitors and so on 17:29:36 <andythenorth> anything written by actual programmers, I tend to defer to them, unless I can measure the results as slower 17:30:19 <andythenorth> most of it is snowline and desert tile visibility (or not) 17:30:41 <andythenorth> I don't know how many of the design choices were driven by the use of CPP templating, where there are no loops 17:30:48 <andythenorth> (or none that I discovered) 17:31:08 <andythenorth> tends towards templates with all the cases written out, and then bools 17:32:15 <TrueBrain> SDL uses QueryPerformanceCounter. If they use it, it is good enough for me! 17:37:12 <glx> timeGetTime should work https://randomascii.wordpress.com/2013/05/09/timegettime-versus-gettickcount/ 17:37:17 <TrueBrain> 5ms resolution 17:37:21 <TrueBrain> at best 17:37:51 <TrueBrain> https://docs.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timegettime 17:38:02 <TrueBrain> "The default precision of the timeGetTime function can be five milliseconds or more, depending on the machine." 17:38:07 <TrueBrain> no clue if it is influences by the timeBegin thingy 17:38:09 <glx> doc is "wrong" according to the article 17:38:29 <TrueBrain> .... why am I not surprised 17:38:30 <TrueBrain> not even slightly 17:38:31 <glx> "The documentation does a poor job of explaining the differences between these functions. It doesn’t make it clear whether they have the same zero point, and it is unnecessarily obscure about the differences. However, it does give some hints. In particular, if we assume that GetTickCount is not affected by both GetSystemTimeAdjustment and by timeBeginPeriod, and if we also assume that timeGetTime 17:38:32 <TrueBrain> okay, let me test :P 17:38:43 <nielsm> the C++ <chrono> implementation in VC++ uses QueryPerformanceCounter 17:38:49 <glx> is affected by these functions then we have something to work with." 17:39:10 <TrueBrain> meh, using the SDL one combines both 17:39:19 <TrueBrain> uses QueryPerformanceCounter if possible, otherwise uses timeGetTime(() 17:40:33 <glx> of course the article is form 2013, so maybe things changed since 17:40:35 <nielsm> just use <chrono> 17:40:46 <LordAro> ^ 17:41:02 <TrueBrain> owh, sorry, totally missed what you meant to say there nielsm 17:41:13 *** Progman has quit IRC 17:41:25 <TrueBrain> I need a bit more breadcrumbs than that 17:41:47 <TrueBrain> as in, which clock? 17:41:55 <nielsm> https://github.com/OpenTTD/OpenTTD/blob/master/src/framerate_gui.cpp#L219 17:42:02 <TrueBrain> as I do not really want the high-resolution honestly 17:42:09 <TrueBrain> but 16ms is the other end of the spectrum :P 17:42:22 <TrueBrain> so does that matter? 17:42:26 <TrueBrain> can I use system_clock as well? 17:42:30 <TrueBrain> is there a performance thingy involved? 17:42:53 <nielsm> system_clock is not guaranteed to be monotonous 17:43:02 <nielsm> and may have poor resolution 17:43:12 <TrueBrain> so just use high-res and be done with it? 17:43:38 *** frosch123 has joined #openttd 17:43:39 <nielsm> if you want millisecond resolution without unpredictable quantization from the OS then the high-res timer is your only real choice 17:44:00 *** Wuzzy has joined #openttd 17:44:08 <TrueBrain> k, tnx :) 17:45:10 <glx> I think you can easily compare using GetTickCount() and timeGetTime() with a small change in openttd source 17:45:42 *** jottyfan has joined #openttd 17:46:51 <Wuzzy> This PR is still ready for review: https://github.com/OpenTTD/OpenSFX/pull/14 17:47:11 <Wuzzy> Dumb question: Do you think I should go ahead and also delete the translations for the OpenSFX description (since it was updated)? 17:47:49 <Wuzzy> or would this better be reserved for a separate PR? 17:47:49 *** jottyfan has quit IRC 17:48:06 <TrueBrain> okay, well, that explained why Sleep() was early, but also why it was capped at ~60Hz ... now it is running much more smooth :D w00p 17:48:28 <LordAro> woop 17:48:36 <andythenorth> you 17:48:45 <andythenorth> eh, wrong text input :P 17:48:50 <LordAro> me 17:48:56 <TrueBrain> EVERYBODY 17:49:03 <andythenorth> that's supposed to get me youtube in chrome 17:49:33 <TrueBrain> I cannot believe I just spend an hour only to find out the timer resolution was the issue 17:49:36 <TrueBrain> grrr 17:50:19 <TrueBrain> right, this brings an equally nice improvement to win32 now 17:50:22 <glx> yeah GetTickCount uses the default 15.625ms 17:50:48 <glx> and it's not modifiable as I understand 17:52:05 <TrueBrain> glx: either way, using std stuff is better anyway 17:52:14 *** gelignite has joined #openttd 17:52:20 <glx> true, as it's the same for all 17:52:50 <TrueBrain> https://user-images.githubusercontent.com/1663690/108101868-23989f00-7088-11eb-9d27-5a0dffedb7c2.png 17:53:09 <glx> nice 17:53:37 <TrueBrain> I think I switch to microsecond instead of millisecond for deltas, as that 62 instead of 60 annoys me :P 17:53:38 <LordAro> nice 17:53:53 <LordAro> what was it running as before? 17:54:08 <glx> 33.57 17:54:20 <nielsm> does this mean windows will no longer run slightly slower in singleplayer compared to SDL and mac? 17:54:31 <TrueBrain> nielsm: yes 17:54:34 <TrueBrain> did not realise that yet 17:54:39 <TrueBrain> but that was exactly the issue with win32 17:54:42 <TrueBrain> how long did that hunt us? 17:55:10 <nielsm> I made a report about it when I first saw it after implementing the framerate window 17:55:16 <TrueBrain> I remember 17:55:18 <nielsm> but didn't really try to diagnose it further 17:55:29 <TrueBrain> I also remember that I couldn't really think of a reason for that happening 17:55:32 <TrueBrain> now we know 17:55:38 <TrueBrain> Windows being crappy in timer resolutions :D 17:55:54 <glx> it has so many different timers 17:56:00 <LordAro> so how many years has that been an issue? 17:56:02 <TrueBrain> the other thing I would like to fix, but I wonder if it is worth it: we now schedule the next frame for CURRENT_TIME + TIME_BETWEEN_FRAMES 17:56:14 <TrueBrain> I would like to change this to LAST_TIME_IT_RUN + TIME_BETWEEN_FRAMES 17:56:22 <TrueBrain> + some logic for when a run takes longer than a frame allows 17:56:41 <TrueBrain> that should smooth things a bit more 17:56:45 <TrueBrain> is that worth it? 17:56:55 <TrueBrain> @calc 2021-2004 17:56:55 <DorpsGek> TrueBrain: 17 17:56:58 <TrueBrain> LordAro: ^^ :P 17:57:05 <LordAro> ^^ 17:57:09 <LordAro> not a TT/TTD issue then? :p 17:57:17 <TrueBrain> really don't know :) 17:57:26 <TrueBrain> I am just bluffing here, with the 17 years 17:57:32 <LordAro> or maybe at that point it becomes a linux issue for running faster than TT did :p 17:57:43 <glx> windows TTD probably used GetTickCount() too 17:57:57 <glx> as it was the usual way 17:58:00 <nielsm> I'm thinking TT on DOS probably timed to screen refresh 17:58:00 <glx> I think 17:58:32 <TrueBrain> anyway, main reason for me to change the scheduling, is that if there is a spike in a few frames, because of autosave, it feels weirdly laggy for a bit of time 17:58:48 <glx> yeah on DOS using vblank to sync is typical 17:59:10 <TrueBrain> so changing from CURRENT_TIME + to LAST_TIME + should mitigate that a bit 17:59:15 <TrueBrain> but every driver would need the same logic 17:59:20 <TrueBrain> I wonder if we should abstract it a bit .. hmm 17:59:22 <TrueBrain> macOS 17:59:24 <TrueBrain> nevermind :P 17:59:42 <glx> std::chrono should work for macOS too ;) 17:59:55 <TrueBrain> I have not looked at how the driver does ticks 17:59:57 <TrueBrain> I am scared :) 18:00:13 <LordAro> if onely someone had rewritten it recently and was very familiar with how it works 18:00:16 <TrueBrain> owh, it is identical to the others 18:00:17 <TrueBrain> pfew 18:00:37 <TrueBrain> okay, so first, lets make them all use std::chrono 18:00:41 <TrueBrain> that should make things a bit cleaner 18:01:31 <TrueBrain> means I can remove CSleep too :D 18:01:34 <DorpsGek> [OpenTTD/BaNaNaS] frosch123 opened pull request #83: Change: migrate OpenTTD user Dante123 to GitHub user Flame1869 https://git.io/Jt16w 18:01:52 <DorpsGek> [OpenTTD/BaNaNaS] TrueBrain approved pull request #83: Change: migrate OpenTTD user Dante123 to GitHub user Flame1869 https://git.io/Jt16o 18:02:30 <DorpsGek> [OpenTTD/BaNaNaS] TrueBrain merged pull request #83: Change: migrate OpenTTD user Dante123 to GitHub user Flame1869 https://git.io/Jt16w 18:02:38 <TrueBrain> names felt like they matched 18:02:42 <TrueBrain> duno .. Dante .. Flame .. I get it 18:03:14 <LordAro> haha 18:04:11 <frosch123> my dutch skill would not have recognised "dante" as "flame" 18:04:37 <glx> dante -> inferno -> flame, logical link I can see 18:04:46 <TrueBrain> what has Dutch have to do with it? 18:05:01 <LordAro> Dante was Italian :p 18:05:03 <TrueBrain> has = does, damn, that english :P 18:05:21 <TrueBrain> hmm .. sleeping for 1271309502 milliseconds 18:05:23 <TrueBrain> this will take a while 18:05:43 <glx> little underflow ? 18:05:52 <TrueBrain> just a little bit 18:05:54 <TrueBrain> nothing to worry about 18:06:11 <TrueBrain> I need to find out how std::chrono works, it seems :D 18:06:23 <TrueBrain> doing A - B with TimingMeasurement is a bad idea, as it turns out 18:06:42 <frosch123> std::chrono works well with stackoverlfow 18:06:59 <TrueBrain> not being lazy works too :D 18:07:22 <TrueBrain> frosch123: https://github.com/OpenTTD/OpenTTD/pull/8680 <- you would know .. is it safe to change the rate of UpdateWindows like this? 18:07:28 <TrueBrain> (it can be faster or slower than normal) 18:09:07 <glx> std::chrono::now() and some math should work I think 18:09:28 <glx> well std::chrono::high_resolution_clock::now() 18:09:35 <glx> I forgot a part 18:10:30 <_dp_> whatever you do make sure it uses steady clock :p 18:13:03 <glx> notes in https://en.cppreference.com/w/cpp/chrono/high_resolution_clock recommend to not use high_resolution_clock as it's implementation dependant 18:13:08 <TrueBrain> hmm, changing the way it schedules the next tick to draw on, changes little to smooth stuff over .. too bad 18:13:27 <TrueBrain> glx: the link nielsm gave has a nice comment about why it is okay in our case 18:14:01 <glx> well for gcc it can go backward 18:14:23 <TrueBrain> hmm .. that would be bad 18:14:27 <glx> it's ok for fps window 18:14:28 <TrueBrain> well, video drivers detect this btw 18:14:39 <glx> but maybe not for gameloop 18:14:47 <frosch123> TrueBrain: there is some magic interaction between inputloop and updatewindows, but it looks like you don'T change that 18:14:59 <TrueBrain> frosch123: yeah .. I had to move both :D 18:16:02 <TrueBrain> glx: well, valid point, honestly 18:16:08 <TrueBrain> and steady_clock on Windows has a high-enough resolution, it seems 18:17:00 <LordAro> a long time ago i wrote a thing which used hrc if it was steady, steady_clock otherwise 18:17:02 <glx> high_resolution is an alias of steady for windows implementation (as I read in the notes) 18:17:14 <TrueBrain> lol 18:17:39 <_dp_> why does high_resolution_clock even exist? 18:17:56 <_dp_> might've as well named it some_random_clock 18:18:13 <LordAro> it has its uses 18:18:39 <glx> because it's the highest resolution for the implementation, but it's implementation dependant 18:19:04 <TrueBrain> weird, I am now hitting a consistent 34.33 frames/s 18:19:10 <glx> on windows, system clock resolution is bad 18:19:11 <TrueBrain> which is 1 frame too much :P 18:19:34 <LordAro> using steadyclock_t = typename std::conditional<std::chrono::high_resolution_clock::is_steady, std::chrono::high_resolution_clock, std::chrono::steady_clock>::type; 18:19:37 <LordAro> there 18:20:07 <TrueBrain> would you prefer I use that ? :D 18:20:17 <LordAro> idk, i'm just saying it's an option :p 18:21:04 <_dp_> LordAro, that makes even less sense 18:21:17 <_dp_> if hrclock is steady why would steady clock has less precision? 18:22:07 <LordAro> because steady clock *must* be steady 18:22:20 <LordAro> if hrc is not steady, use the one that is defined to be so 18:22:25 <LordAro> i feel like you're misreading it 18:22:32 <TrueBrain> hmm .. I run code 60 times a second, but the framerate GUI says 60.98 18:22:39 <TrueBrain> I can accept being slightly slower 18:22:43 <TrueBrain> but slightly faster? 18:24:54 <_dp_> LordAro, yeah, but how is it different from just using steady_clock? 18:25:05 <_dp_> if hrc is stable why would steady_clock not use hrc? 18:25:41 <glx> hrc can be a different steady clock than steady clock 18:25:42 <nielsm> in microsoft's stdlib steady_clock and high_resolution_clock are the same implementation 18:26:13 <nielsm> but yes depending on implementation details like that is wrong, technically 18:27:20 <glx> and on some implementation (like gcc stdc++ lib it's system_clock and not steady) 18:27:43 <TrueBrain> found a bug in the framerate window :) 18:27:48 <TrueBrain> it counts the first point twice :P 18:27:51 <nielsm> I guess, high_resolution_clock could on some platforms be implemented in a way that makes it unpredictable across physical CPU's? 18:27:54 <TrueBrain> now I am hitting 60fps :D \o/ 18:28:18 <_dp_> well, yeah, it can be but I don't see any point for any implementation to have 2 different steady clocks :p 18:28:23 <TrueBrain> and simulation 33.33 fps :D 18:29:39 *** andythenorth has quit IRC 18:30:58 <frosch123> _dp_: there are games with 6 types of signals, why complain about 2 steady clocks? 18:32:13 <_dp_> frosch123, why not complain about both clocks and signals? :p 18:32:24 *** andythenorth has joined #openttd 18:32:31 <_dp_> I complained about signals yesterday :p 18:33:41 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened pull request #8681: Fix: Autorenew failure advice due to bad refit being shown to all companies https://git.io/Jt1P3 18:33:44 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #8682: Fix: framerate window showed a slightly higher rate than actually measured https://git.io/Jt1Ps 18:33:53 <TrueBrain> I hope you all enjoy my proza :) 18:33:58 <_dp_> oh, and btw, what's even the point of having unstable hrc? 18:34:08 <_dp_> to measure some nonsense with high precision? :p 18:34:23 <glx> yes, it's the spec 18:34:41 <glx> hrc is highest precision, that's all 18:35:34 <TrueBrain> https://user-images.githubusercontent.com/1663690/108106346-1e3e5300-708e-11eb-9036-f0184d3ed7e9.png 18:35:35 <TrueBrain> :D 18:35:44 <frosch123> _dp_: as nielsm already said. there are per-cpu-core clocks, that differ between cores 18:35:56 <frosch123> and with some instruction scheduling also between instructions 18:36:27 <nielsm> yes, but the OS that ottd runs on tend to do magic to give you a steady high-res clock regardless 18:36:28 <_dp_> glx, that spec allows hrc to be an alias of random generator :p 18:36:30 <frosch123> use a 80486 if you want something simpler 18:36:41 <Wolf01> I found that instead of using "potato potato" you can just use "Ghoughpteighbteau Ghoughpteighbteau" 18:37:08 <nielsm> just like they tend to do magic to ensure a CPU throttled down doesn't change timer resolution 18:37:49 <nielsm> or well, it does change resolution, probably, but not wallclock-rate-of-increment 18:39:48 <TrueBrain> funny, framerate window measures just slightly too often to make the value smooth 18:39:55 <TrueBrain> it bounces between 59.98 and 60.02 now :D 18:40:25 <TrueBrain> and it changes so often you cannot really see that :P 18:40:43 <nielsm> by measuring we are changing the measured value 18:41:27 <TrueBrain> it doesn't help that it is drawing the framerate window twice as often :P 18:41:44 <glx> hehe 18:42:28 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #8677: Fix #8676: Revert a2c3197f4 and unconditionally load settings "early" https://git.io/Jt1PD 18:42:36 <frosch123> reviewing the same fix twice :p 18:42:46 <glx> not exactly the same 18:42:52 <glx> (except the revert) 18:44:16 <glx> so your vote would go to the other PR 18:44:35 <glx> (I like the "minimal" flag version BTW) 18:44:45 <frosch123> i am still reading the other one 18:44:52 <frosch123> i started with the first one :p 18:45:44 <TrueBrain> owh, it was my mistake framerate window was updating waaayyyy too fast :D 18:46:04 <frosch123> oh, but i think michi_cc's version breaks the thing, that i commented on in glx's version 18:46:53 <frosch123> no, it doesn't 18:46:58 <glx> minimal settings are loaded only once 18:47:20 <glx> that's why I commented about newgrf count 18:47:21 <frosch123> we should find a better name for "minimal" :p 18:47:39 <TrueBrain> haha, yes 18:47:53 <TrueBrain> I btw also need refresh-rate to be "minimal" .. the first few frames I don't have the value now :D 18:48:19 <LordAro> TrueBrain: i got a message yesterday along the lines of "got MHz & kHz mixed up, so ended up generating 45M interrupts persecond" is this what you've done here? :p 18:49:11 <TrueBrain> LordAro: nnoooooo....... I might have changed the clock to microsecond, and might not have divided by 1000 for realtime_tick, causing all delta_ms based calculations to go bananas ... euh ... so yes, yes, I did that :P 18:52:52 <LordAro> TrueBrain: :D 18:58:33 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #8678: Fix #8676: GUI-visible settings may not be part of misc settings. https://git.io/Jt1XA 18:58:44 *** Progman has joined #openttd 18:58:54 <frosch123> glx: i guess i also prefer michi_cc's version. sorry :) 19:01:16 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://git.io/Jt11T 19:01:17 <DorpsGek> - Update: Translations from eints (by translators) 19:05:09 <TrueBrain> std::chrono wraps, on most platforms, after 292 years 19:05:16 <TrueBrain> something to check for, or can I ignore this? :D 19:05:51 <frosch123> write a letter for your grand-grand-children 19:06:02 <nielsm> I don't think anyone have played OTTD for that long yet 19:07:51 <frosch123> ottd turns 17 this year, time to start with the drivers license 19:08:15 <frosch123> no longer stopping vehicles in the middle of the road 19:09:11 *** Ttech has joined #openttd 19:10:34 <nielsm> could add an option that moves road vehicles to a parallel dimension where they are still visible but can't collide with trains 19:13:05 <frosch123> does GetRate() really work? 19:13:18 <TrueBrain> hmm .. I don't get std::chrono it seems :D "A >= B" is false, but A - B is negative ... 19:13:21 <frosch123> i have no idea what it tries to do... 19:13:45 <TrueBrain> frosch123: 1 divided by (the average of the bucket) 19:14:06 <TrueBrain> so sum of the bucket divided by the count == average, 1 / average == rate 19:16:29 <frosch123> is there a relation between "timestamps" and "durations"? 19:17:16 <frosch123> prev_index and next_index are just as magical to me 19:17:16 <TrueBrain> timestamp A2 - timestamp A1 == duration between A1 and A2 19:17:30 <TrueBrain> maybe nielsm should review the PR :P 19:17:48 <frosch123> apparently there are invalid durations 19:18:08 <frosch123> if there were not, you could just (last timestamp) - (first timestamp), and no loop needed 19:18:28 <TrueBrain> that is what the comment suggest, yes 19:18:34 <TrueBrain> that some bins can have invalid values 19:18:35 <frosch123> but if there are invalid durations... what are the timestamps about? 19:18:57 <frosch123> i agree, nielsm should review it :) 19:19:04 <TrueBrain> but now you are asking questions I cannot answer :) I just found a logic error that the bucket-sum had a count+1 :) 19:19:43 <nielsm> I'd need to dust off my build environment, it's very crusty by now 19:20:07 <TrueBrain> review doesn't need a way to build stuff :P 19:20:41 <frosch123> TrueBrain: yes, but you include new timestamps into the list. you could also do total += durations[point]. but i have no idea whether there is a difference 19:21:08 <TrueBrain> frosch123: the first iteration of that loop adds 0 to total 19:21:09 <TrueBrain> and 1 to count 19:21:14 <TrueBrain> this is what I correct 19:21:25 <TrueBrain> no clue if it is the right way to do that, but .. this is the fix I went with :P 19:21:57 <TrueBrain> your fix suggests the other way around, add the first point and add 1 to count 19:22:08 <TrueBrain> which is similar, I guess .. I just couldn't find how to get that duration :) 19:22:30 <TrueBrain> in the end, this is based on 512 values .. so 1 more or less, I don't care :P 19:24:10 <frosch123> i found the doxygen comments to the variables 19:24:43 <frosch123> no idea why both "next_index" and "prev_index" are needed, when they always differ by 1. but now i can start to read that function :p 19:25:13 <TrueBrain> owh, duration in this context is most likely something different than I was expecting 19:25:18 <LordAro> doxygen comments were useful? :o 19:25:19 <TrueBrain> well, I did not really try to understand the function honestly :) 19:25:55 <TrueBrain> but I guess "duration" could mean how long it took, where "timestamp" is when it happened .. and now we want the duration between the timestamps, which is equal or higher than the duration of the point :P 19:25:58 <TrueBrain> yes, this is not confusing :D 19:26:00 <TrueBrain> sorry :P 19:26:02 <frosch123> duration seems to be "time for function X", but timestamps is start of each frame 19:26:20 <TrueBrain> yeah, okay, my mistake, sorry :) I assumed something different there 19:26:23 <TrueBrain> that makes sense 19:26:46 <TrueBrain> so you could still do "last timestamp - first timestamp", but there might be invalid datapoints in there 19:26:49 <TrueBrain> hence the loop 19:27:04 <TrueBrain> who knew that an off-by-one could be so much brain-effort :P 19:29:20 <frosch123> last_point is still a valid index, right? 19:30:05 <TrueBrain> no clue 19:30:47 <TrueBrain> it mostly doesn't get there, as it bails out at 1 second 19:31:11 <TrueBrain> but it seems to never read the value at last_point 19:31:12 <frosch123> well, if there are no valid points, you sum all of them 19:31:23 <frosch123> so that counterbalances that :p 19:31:32 <TrueBrain> so I do not know how the bucket wraps 19:31:37 <TrueBrain> if last_point == point when full 19:31:55 <TrueBrain> what does doxygen comment say for num_valid? :) 19:32:32 <frosch123> ah, i found AddPause 19:32:50 * Timberwolf has been doing some digging in boxes. https://photos.app.goo.gl/BPFp9ipKYwPKYJPS9 19:32:57 <TrueBrain> (and again, I just realised: "last" is set to "point", but "point" is not changed when starting the while, and it is using "last" to calculate the time between timestamps, so the first iteration it makes a boo-boo) 19:33:03 <frosch123> that gives some relation between timestamps and durations 19:33:11 <TrueBrain> I did not have to understand the function at all for that :) 19:34:29 <TrueBrain> the other solution is to extend the if for INVALID_DURATION with "point != this->prev_index", and not initialize "last" 19:34:45 <TrueBrain> saves 3 lines of code! 19:35:25 <frosch123> it just annoys me that this code seems to be way more complicated than it should be :) 19:35:47 <TrueBrain> you do you :) 19:36:00 <frosch123> these separate prev_index and next_index, that have a difference of 1 in most cases, except on wrap-around and on first start 19:36:07 <frosch123> they do not make it easier :) 19:36:44 <frosch123> but well, i assume you would have noticed if it crashes or show non-sense when opening the window the first time :) 19:36:52 <DorpsGek> [OpenTTD/OpenTTD] frosch123 approved pull request #8682: Fix: framerate window showed a slightly higher rate than actually measured https://git.io/Jt1Mr 19:37:09 <TrueBrain> on opening, or when the game starts? 19:37:14 <TrueBrain> as it opens, but I cannot check when the game starts :P 19:37:17 <frosch123> i just hope my bank does not run code like that 19:37:35 <LordAro> spoiler: it does 19:38:02 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #8682: Fix: framerate window showed a slightly higher rate than actually measured https://git.io/Jt1Ps 19:38:13 <frosch123> lol, most "num_valid++" do a clmap to NUM_FRAMERATE_POINTS. except one 19:38:19 <TrueBrain> hmm .. I do not get why std::chrono is not doing what I assumed it would 19:38:22 <frosch123> is that a buffer overflow? 19:38:28 <TrueBrain> how can A >= B be false, and A - B be negative? 19:40:25 <frosch123> volatile :) 19:40:36 <Timberwolf> Token "Megarail, 1960 was an enormous network, the most impressive thing I'd ever seen done in the game... oh": https://i.imgur.com/wIbwiQD.png 19:40:45 <frosch123> deprecate "volatile"! 19:41:29 <LordAro> some sort of weird type coercion? 19:42:04 <TrueBrain> auto cur_ticks = std::chrono::steady_clock::now(); 19:42:13 <TrueBrain> auto next_game_tick = cur_ticks; 19:42:20 <TrueBrain> next_game_tick += std::chrono::milliseconds(MILLISECONDS_PER_TICK) 19:42:26 <TrueBrain> if (cur_ticks >= next_game_tick) 19:42:32 <TrueBrain> those are all sensible statements, not? 19:43:07 <TrueBrain> bit annoyed by the lack of examples I can find :P 19:43:25 <TrueBrain> what annoys me most, it works for next_draw_tick, but not for next_game_tick :P 19:43:55 <TrueBrain> owh, I know why 19:43:56 <TrueBrain> lol 19:43:59 <TrueBrain> llalalalaaaaaaaaaaaaa 19:44:05 <TrueBrain> now() doesn't return a primitive ... oops 19:45:10 <TrueBrain> hmm, no, that is nto the issue 19:45:23 <TrueBrain> I don't understand C++ :( Such a harsh realisation :P 19:46:03 <frosch123> usually i do differences of timestamps, and compare them to durations 19:46:12 <frosch123> the other way around sounds troublesome 19:46:14 <TrueBrain> yippie, found it \o/ 19:46:26 <frosch123> i think the unterlying unit can be a double 19:46:42 <frosch123> so it's possible that A + eps = A 19:46:57 <TrueBrain> in this case I was just being an idiot 19:47:05 <TrueBrain> https://pasteboard.co/JOFh23Z.png 19:47:07 <TrueBrain> look at that :D 19:47:18 <frosch123> fake 19:47:31 <frosch123> why 0.99x ? 19:47:36 <TrueBrain> shrug 19:47:45 <TrueBrain> another off-by-one? 19:47:47 <frosch123> didn't you just fix one obiwan? 19:48:34 <TrueBrain> no, rounding issue 19:48:39 <TrueBrain> it was not exactly 33.333333333 19:48:48 <LordAro> if (speed == "0.99") speed = 1.0 19:48:50 <TrueBrain> so 33.339 or something :) 19:48:51 <LordAro> fixed. 19:49:39 <TrueBrain> but about https://github.com/OpenTTD/OpenTTD/pull/8680, is that something that we want/like? Should I build this for all video drivers? 19:50:08 <TrueBrain> and change the default to 60fps for GUI? :) 19:50:59 <frosch123> wasn't the mouse already drawn faster? 19:51:11 <TrueBrain> yes, it was 19:51:13 <TrueBrain> ish 19:51:15 <frosch123> what else does matter? dragging windows? 19:51:26 <TrueBrain> yup 19:52:02 <TrueBrain> @calc 1000/6 19:52:02 <DorpsGek> TrueBrain: 166.66666666666666 19:52:19 <frosch123> did you do (1) on an empty map? 19:52:39 <TrueBrain> frosch123: the fps values, yes 19:53:26 <TrueBrain> this is why OpenGL also showed a great improvement 19:53:34 <TrueBrain> because we just draw a silly amount with FF 19:55:12 <frosch123> does it change anything on a map with 100 vehicles? 19:55:17 <TrueBrain> but 1) improves performance on any map where the game-tick takes less than 30ms - time of video output :) 19:55:41 <TrueBrain> for SDL, video output is 5ms 19:55:51 <TrueBrain> so any game with a game-tick of less than 25ms runs faster in FF with this PR 19:56:09 <frosch123> it reads like FF will mostly run faster when it was already running fast 19:56:13 <TrueBrain> so yes, 100 vehicles is most likely well below 25ms :) 19:56:29 <TrueBrain> it makes better use of the free time for FF 19:56:44 <TrueBrain> so even if FF was only 3.5x, it now becomes 4.5x (as Eddi|zuHause said earlier tonight) 19:58:12 <TrueBrain> basically, we do as little GUI stuff as possible during FF, which of course helps FF :) Up till the point a game-tick takes so much time the draw-tick is called always anyway 19:58:55 <TrueBrain> owh, that onlyhappens if a game-tick takes more than 30ms with draw-threads ofc 19:59:00 <TrueBrain> so even more games will benefit from this 19:59:42 <TrueBrain> but yes, as soon as FF doesn't help, this PR doesn't do anything anymore either 19:59:51 <TrueBrain> and the faster FF was, the faster it becomes 20:02:23 <frosch123> do you know why ticks are sometimes compared with < and sometimes with SDL_TICKS_PASSED ? 20:02:31 <TrueBrain> I have no idea 20:02:36 <TrueBrain> I am going to replace it all with std::chrono 20:02:41 <TrueBrain> so soon that will be a thing of the past 20:02:55 <frosch123> good, then i don't have to understand the ticks :) 20:03:23 <TrueBrain> I now did the Win32 driver; looks a lot better :D 20:08:07 <michi_cc> TrueBrain: Late to the party here: Isn't there some Random() accessible to NewGRF? If yes, you can't randomly (hehe) re-do ticks. 20:08:20 <michi_cc> And according to https://en.cppreference.com/w/cpp/chrono/high_resolution_clock using the HRC is just bad. 20:08:26 <TrueBrain> michi_cc: I was thinking about that, but that would mean that any vehicle that is in the viewport would also break 20:08:42 <TrueBrain> yes, you are late to the party there ;) Already using std::chrono::steady_clock :) 20:09:59 *** jottyfan has joined #openttd 20:10:30 <frosch123> michi_cc: do you know how precise std::condition_variable::wait_until/wait_for is? 20:11:15 <frosch123> currently there is a unlock-sleep-lock combo in the video driver. but condition_variable::wait+timeout would do the same 20:11:27 <nielsm> won't those essentially depend on the underlying implementation? 20:12:05 <TrueBrain> the sleep is mostly the yield btw 20:12:16 <TrueBrain> as otherwise we are just spinlocking anyway 20:13:54 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #8680: Several improvements to SDL2 video driver https://git.io/Jt1ym 20:14:03 <frosch123> well, those are the two things that looked weird to me 20:14:30 <TrueBrain> but otherwise this does sound like a good idea to you? 20:17:05 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #8680: Several improvements to SDL2 video driver https://git.io/Jt1y0 20:17:05 <frosch123> three 20:19:07 <TrueBrain> estimated cost of repaying your loan is 0 :D 20:20:17 <supermop_Home_> nice day here 20:20:32 <supermop_Home_> but all the snow on the ground has become gross 20:20:50 <frosch123> TrueBrain: i think those changes only make sense with opengl, when drawing is fast 20:21:05 <TrueBrain> for me without OpenGL this is already a huge improvement :) 20:21:10 <TrueBrain> not sure how you link it to OpenGL? 20:21:15 <michi_cc> frosch123: No idea how precise they are supposed to be. Condition variables are tricky though, as they can have spurious wakeups (i.e. always use the wait function that takes a predicated). 20:21:16 <frosch123> when drawing is slow, you skip the "only draw mouse" trick, so it becomes worse, doesn't it? 20:21:19 <TrueBrain> (Drawing is already done in a thread, mind you) 20:21:54 <TrueBrain> the "only draw mouse" trick is a weird trick, that is very unpredictable :) 20:22:02 <TrueBrain> especially with knowing the sleep is ~6ms 20:22:07 <frosch123> michi_cc: yes, but spurious wakeups are no problem here 20:22:43 <michi_cc> TrueBrain: std::chrono really is weird sometimes. A few weeks ago, I posted an OSX patch here that used chrono istead of the gettimeofday. It was apparently a lot worse on timing :( 20:23:00 <TrueBrain> michi_cc: yeah, I suspected we had to evaluated it per OS :) 20:23:08 <TrueBrain> on Windows and Linux it is pretty spot-on now 20:24:07 <TrueBrain> frosch123: but given you use Linux, it would be valuable if you test out my PR vs master, especially with refresh_rate set to 60 and not 20:24:11 <TrueBrain> see if you notice a difference 20:26:10 <andythenorth> OMGG 20:26:13 <frosch123> sure, when github works again 20:26:13 <andythenorth> I forgot to have beer 20:26:55 <TrueBrain> https://github.com/TrueBrain/OpenTTD/tree/video-performance has an SDL version based on std::chrono 20:27:00 <TrueBrain> if you like you can test that :) 20:28:16 <TrueBrain> anyway, frosch123 , I was a bit puzzling what the old DrawMouse thingy did and what I do now: the old one did "something" above 30fps 20:28:27 <TrueBrain> but it was unpredictable 20:28:35 <TrueBrain> with my PR, it hits 60fps or 144fps consistent 20:28:38 <TrueBrain> as it demands time for it 20:28:40 <michi_cc> frosch123: For #8678, bootstrap or maybe startup as a word? 20:28:42 <TrueBrain> instead of "if there is any room" 20:28:45 <TrueBrain> that is the biggest difference :) 20:29:05 <TrueBrain> I would avoid "bootstrap", as it is already claimed for another part of OpenTTD :) 20:29:38 *** jottyfan has quit IRC 20:29:45 <LordAro> bootstrap_settings 20:29:51 <LordAro> :p 20:30:04 <TrueBrain> doesn't remove the confusion LordAro ;) 20:30:18 <LordAro> bootstrap_but_not_that_bootstrap 20:30:25 <TrueBrain> now we are talking 20:30:53 <_dp_> bootstrapish :p 20:30:55 <TrueBrain> https://github.com/OpenTTD/OpenTTD/blob/master/src/video/sdl_v.cpp#L717 vs https://github.com/OpenTTD/OpenTTD/blob/master/src/video/win32_v.cpp#L1195 20:30:57 <TrueBrain> similar, but different 20:31:12 <TrueBrain> else condition triggers on different moments 20:32:42 <frosch123> michi_cc: both are fine :) 20:33:24 <frosch123> just as long as it is nothing that implies "minimal" or "optional" or similar 20:34:31 <frosch123> https://github.com/sba1/adtools/pull/78/files <- haha, what a fix :) 20:34:46 <TrueBrain> ooooppppsssss 20:34:52 <TrueBrain> that is evil 20:36:17 <LordAro> ouch 20:38:28 <TrueBrain> frosch123: regarding _realtime_tick, I wonder if we shouldn't just change that all into std::chrono 20:38:33 <TrueBrain> and just decouple it from the videodriver 20:38:51 <DorpsGek> [OpenTTD/OpenTTD] michicc updated pull request #8678: Fix #8676: GUI-visible settings may not be part of misc settings. https://git.io/JtX9t 20:38:54 <TrueBrain> as it seems that all places just expect it to give "milliseconds since start" 20:40:42 <TrueBrain> I might make a PR for that tomorrow, just to see how it looks 20:41:47 <TrueBrain> hmm ... should I do SDL1-driver too .. or shall we just let it rot? 20:42:35 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #8680: Several improvements to SDL2 video driver https://git.io/Jt1Sd 20:44:06 <TrueBrain> why does a dedicated server execute UpdateWindows()? 20:45:11 <frosch123> there is a coment in updatewindows about that 20:45:46 <frosch123> updatewindows receives some events from the gameloop, and it needs to flush those queues 20:45:56 <TrueBrain> tnx 20:47:22 <frosch123> the simulation rate fluctuates a lot :p 20:47:34 <frosch123> between 2000 and 3000 in my testgame 20:48:04 <TrueBrain> if you have autosave on, it is even worse :) 20:48:13 <TrueBrain> but also check non-FF :) 20:52:37 <frosch123> what should i watch out for on non-FF? 20:52:57 <TrueBrain> set refresh-rate to 60fps, see if your simulation hit 33.33, and graphics hit 60 20:53:02 <TrueBrain> and see if it feels smoother than master 20:53:31 <TrueBrain> [gui]\nrefresh_rate = 60, in openttd.cfg :) 20:54:20 <TrueBrain> it should be a lot smoother, as it allows some frames to miss targets, for the next ones to catch up 20:57:15 <frosch123> i used the console 20:57:48 <frosch123> my simulation rate seems to be continuous above 33.33 20:58:00 <frosch123> mostly 33.9-43.2 20:58:05 <frosch123> 33.9-34.2 20:58:13 <TrueBrain> with the PR of my other branch? 20:58:28 <frosch123> no, just 8680 20:58:34 <TrueBrain> yeah, it doesn't contain the fix I made for that :) 20:58:40 <TrueBrain> that triggered the framerate window fix :P 20:58:48 <TrueBrain> you can try my other branch, that has that fix included :) 20:59:00 <frosch123> graphics is 61.6 to 63.0 20:59:27 <TrueBrain> you can also rebase to upstream master 20:59:36 <TrueBrain> that should stabilize that number a lot :D 20:59:58 <frosch123> oh, when i scroll, draw rate drops to 48, but also simulation rate drops to 29 20:59:58 <TrueBrain> but if you wouldn't mind testing myother brach, I would appreciate that .. as that uses std::chrono 21:00:08 <TrueBrain> new sprites is expensive :) 21:01:40 <frosch123> yes, but the higher draw rate blocks the simulation rate? 21:01:43 <frosch123> (not sure) 21:02:16 <TrueBrain> one way to find out: set refresh-rate to 10 :) 21:02:46 <TrueBrain> drawing should happen in a thread, so that shouldn't influence it 21:03:28 <TrueBrain> owh, the min-value is 30 21:03:31 <TrueBrain> so you cannot set it to 10 :D 21:03:33 <TrueBrain> let me fix that .. 21:03:41 <TrueBrain> hmm .. do we want to allow that 21:03:45 <TrueBrain> guess that is a bad idea to allow :P 21:04:40 <TrueBrain> anyway, for me, fully zoomed out on a map, simulation stays the same no matter what refresh_rate I use .. but it never gets above 40 fps :D Total lack of CPU time :D 21:05:00 <frosch123> the video-performance gets closer to 33.33 and 60.00 21:05:14 <TrueBrain> nice :D 21:05:48 <TrueBrain> okay, the drawing does indeed influence the simulation speed at a certain point 21:05:55 <TrueBrain> this is something OpenGL for sure will help with :D 21:06:58 <frosch123> hmm, setting fresh_rate to 30 always draws in yelllow 21:07:07 <frosch123> hmm, oh, i think you wrote that in the PR 21:07:14 <TrueBrain> yes, part of the TODO :) 21:07:23 <TrueBrain> didn't want to figure that out till I knew this could be accepted in master :) 21:07:48 <frosch123> scroll-earthquake on zoomed out drops to 16 fps :p 21:07:58 <TrueBrain> also with master, I assume :P 21:08:06 <frosch123> likely 21:08:53 <frosch123> oh, video-performance is different on fast-forward 21:09:00 <TrueBrain> better/worse? 21:09:01 <frosch123> it is affected a lot by the zoom level 21:09:29 <frosch123> zoom out, simulation rate drops to 150 or less 21:09:57 <frosch123> let's recheck sdl-performance 21:10:03 <TrueBrain> I think even master does that :P 21:11:02 <TrueBrain> okay, the coloring of the fps is a fixed value 21:11:08 <TrueBrain> making that dynamic will be fun :P 21:11:24 <frosch123> hmm, the numbers are too unstable to compare 21:11:48 <frosch123> sdl-performance started with 300 fps on zoomed-out ff, but now dropped to 150 as well 21:12:02 <TrueBrain> I think master does too; there is just a lot to do :P 21:12:53 <frosch123> increading refresh_rate hurts it even more 21:13:00 <TrueBrain> that makes sense :) 21:13:40 <TrueBrain> at least, I assume that locking the draw thread requires it to be done first 21:13:50 <TrueBrain> so the longer drawing takes, I assume, the more it pushes out simulation too 21:13:55 <frosch123> oh, yeah, my thoughts were wrong 21:14:02 <TrueBrain> we can optimize towards one or the other btw 21:14:07 <TrueBrain> which one has priority 21:14:27 <frosch123> i guess it works as long as simulation rate is bigger than graphics rate in FF 21:14:37 <TrueBrain> yup 21:14:48 <TrueBrain> drawing has to be done before gameloop can begin, I would assume 21:15:02 <TrueBrain> this is where OpenGL branch comes in btw 21:15:15 <frosch123> there is still too much drawing inside the gameloop :) 21:15:28 <TrueBrain> if there is anything else we can take out, let me know :) 21:15:28 <frosch123> the spritecache stuff does not need to be in the gameloop, but it is 21:15:37 <TrueBrain> I am just happy I can do 1000x on SDL now :P (instead of 200) 21:16:03 <frosch123> i think all the blitter action is done inside the gameloop 21:16:20 <frosch123> if you could instead create a queue of sprites to draw in the gameloop 21:16:30 <frosch123> all the blitting and spriteloading can be done outside 21:16:33 <TrueBrain> what I will do, is clean up the PR, make it to work for all drivers, and get that in master; after that, spend some time on checking what we can move to draw-ticks 21:16:48 <frosch123> problem is that there are more drawing commands than just sprites 21:17:00 <frosch123> smallmap even does putpixel :p 21:17:04 <TrueBrain> my main problem is that NewGRFs can do weird shit :D 21:17:26 <frosch123> newgrf don't hook into the drawing 21:17:37 <TrueBrain> but drawing calls NewGRFs, not? 21:17:50 <nielsm> imagine if there was a cheap and easy to to transform the game state into something snapshottable, so one game loop can work on simulating a new game state, while GUI updates can keep reading the old game state 21:18:03 <TrueBrain> nielsm: I have been wondering about that, yes :) 21:18:14 <frosch123> TrueBrain: the gameloop hooks into newgrf. the drawing does not really 21:18:14 <TrueBrain> well, not snapshot, I was just thinking of making a cheap copy at the end of the GameLoop :P 21:18:22 <TrueBrain> frosch123: well, that is good news to me :D 21:18:42 <TrueBrain> nielsm: biggest issue I have found, is that our game state is a bit all over the place :P 21:19:42 <nielsm> frosch123: how does selection of vehicle and industry tile sprites work? does every vehicle on the map always get queried for their sprite every tick, or only those being drawn? what if the same vehicle is drawn in multiple places on screen (e.g. view windows) 21:19:56 <frosch123> TrueBrain: if you take ViewportDoDraw(), everything after "DrawTextEffects" does not need to be in the gameloop 21:20:12 <nielsm> because as far as I understand, that does involve calling into NewGRF to select the sprite for drawing 21:20:28 <frosch123> nielsm: yes, but that is no different to walking the tiles on the map, to read them 21:20:39 <frosch123> both access the gamestate 21:20:40 <nielsm> unless that gets cached somewhere 21:20:43 <TrueBrain> frosch123: that is a lot ... 21:21:00 <frosch123> but once you know which spritenumber to draw, you do not have to ask the gamestate or any newgrf for the indivudal pixels 21:21:20 <frosch123> currently the gameloop does everything 21:21:48 <nielsm> does the Vehicle class have a cache for "selected sprites for drawing" currently? 21:22:07 <frosch123> 1. iterate over the map 2. resolve sprites for each tile and vehicle (possibly involving newgrf) 3. load missing sprites from disk. 4. blit all the sprites into our video buffer 21:22:36 <frosch123> 3 and 4 could be done outside the gameloop, if you could somehow queue all the drawing operations 21:23:00 <frosch123> nielsm: it does, but the Vehicle class is gamestate as well 21:23:09 <frosch123> you cannot access that outside the gameloop 21:23:18 <frosch123> the vehicle could just be sold/destroyed while drawing 21:23:22 <nielsm> can the user potentially scroll the map or otherwise uncover stuff that wasn't visible in the last iteration of the gameloop, and thus may not have a sprite determined, between game loop iterations? 21:23:55 <frosch123> the input loop is currently part of the gameloop as well 21:24:02 <frosch123> you cannot scroll without the gameloop 21:24:06 <TrueBrain> not with my PR :P 21:24:10 <nielsm> okay so you'd essentially need to store the entire screen as a bunch of draw commands? 21:24:47 <glx> michi_cc: seems search and replace failed ;) 21:24:52 <frosch123> yes. the gameloop has to handle drawing on a "draw sprite X" or "draw rectangle" level. 21:24:59 <frosch123> but it does not have to wait for the pixels 21:25:23 <DorpsGek> [OpenTTD/OpenTTD] michicc updated pull request #8678: Fix #8676: GUI-visible settings may not be part of misc settings. https://git.io/JtX9t 21:26:07 <nielsm> it might be a good idea to convert the window system to layered, in the longer run 21:26:14 <TrueBrain> who is called Draw on all the Windows .. damn, that is hard to find :P 21:26:31 <nielsm> so windows can be moved around and reordered without needing to draw new pixels 21:27:01 <frosch123> TrueBrain: DrawOverlappedWindowForAll() 21:27:47 <TrueBrain> ah, via OnPaint 21:27:57 <TrueBrain> I like how it goes from Draw to Paint to Draw :D 21:28:21 <frosch123> there was in a draw in the naming vote 21:29:10 <frosch123> hmm, i do not play ottd often enough 21:29:18 <nielsm> gn 21:29:27 <frosch123> when something is weird, i do not know whether it has always been like that 21:29:40 <TrueBrain> hmm .. DrawOverlappedWindowForAll is called via UpdateWindows 21:30:09 <TrueBrain> frosch123: I have the same issue :P 21:30:13 <TrueBrain> night nielsm 21:30:22 <frosch123> currently i am confused by the load-game window 21:30:35 <TrueBrain> okay, so with my PR already moves UpdateWindows to being called not every frame on FF 21:30:49 <frosch123> when i load a game from intro screen. i select a game to load, click load, and then the window closes 21:30:59 <glx> frosch123: switch to LTR language, it's worse ;) 21:31:13 <frosch123> and then there is a split second of confusion, where you are back at the intro screen, before it switches to the loaded game 21:31:26 <TrueBrain> yeah, these kind of timings are a bit off in many places 21:31:29 <frosch123> glx: i use LTR all the time 21:31:33 <TrueBrain> the GUI feedback is not always that pleasent 21:31:39 <TrueBrain> but most of them are easy fixes honestly 21:31:47 <glx> oh I mean RTL 21:32:02 <TrueBrain> frosch123: do I translate you correctly, that you say that a lot of the drawing stuff can be done in the drawing thread? 21:32:28 <frosch123> yes, but it's a lot more work than moving 20 loc :p 21:32:32 <TrueBrain> yeah 21:32:39 <TrueBrain> and it won't help the zoom-out case you just had 21:32:50 <TrueBrain> as when it is done, is not that important in those cases 21:32:59 <TrueBrain> (as the game-tick takes less than the draw-tick) 21:33:47 <frosch123> this "high draw rate slows down simulation rate" annoys me :p 21:33:57 <TrueBrain> really not much we can do about it 21:34:01 <frosch123> can we skip frames when the simulation rate drops below 33? 21:34:02 <TrueBrain> simulation has to wait for drawing to be complete 21:34:27 <TrueBrain> and that is one of the biggest design flaws in OpenTTD, one that modern games approach different: normally you run a gameloop based on a delta :) 21:34:56 <TrueBrain> but yes, now we split drawing from gameloop a bit 21:35:01 <TrueBrain> we can set priorities 21:35:06 <TrueBrain> do we want framerate to suffer 21:35:08 <TrueBrain> or simulation 21:35:11 <frosch123> haha, also a lot of modern games are fps locked 21:35:14 <TrueBrain> my problem: not sure which one is worse :P 21:35:37 <TrueBrain> going below 30fps is really annoying 21:35:46 <TrueBrain> RPGs make fps always suffer 21:35:52 <TrueBrain> aRPGs, sorry 21:35:53 <frosch123> in fast-forward gameloop can suffer. in normal speed, drawing should suffer 21:35:59 <frosch123> so you can easier keep up with servers? 21:36:17 <TrueBrain> yeah, for sure it is possible 21:36:20 <frosch123> hmm, though, wasn't there some other thing to catch up with servers? 21:36:22 <TrueBrain> we can even set a lower-limit 21:36:24 <TrueBrain> like, never below 10fps 21:36:45 <TrueBrain> on join, you can catch up with servers 21:36:48 <TrueBrain> after join .. not sure? 21:36:51 <TrueBrain> might be added later 21:37:16 <frosch123> i remember there was some "skip drawing when lagging behind" 21:37:23 *** nielsm has quit IRC 21:38:33 <TrueBrain> there is indeed code to just try to catch up 21:39:24 <TrueBrain> https://github.com/OpenTTD/OpenTTD/blob/master/src/network/network.cpp#L998 21:40:12 <TrueBrain> nevertheless, your point stands: drawing can cause clients to get less time for gameloop 21:40:17 <TrueBrain> making them hit that while more and more often 21:40:24 <TrueBrain> which can be avoided by having a dynamic refresh rate 21:40:50 <frosch123> ah, the catching up is done inside the gameloop :) 21:40:59 <TrueBrain> it is not the most prettiest code :P 21:41:44 <TrueBrain> anyway, now I also added code that doesn't do next_tick = cur_ticks + N 21:41:47 <TrueBrain> but instead does next_tick += N 21:41:59 <TrueBrain> it is easy to detect when deadlines aren't being made 21:42:03 <TrueBrain> and make drawing suffer because of it 21:43:23 <TrueBrain> many small things to fiddle with to make the game feel a bit more smooth 21:43:56 <TrueBrain> tomorrow I first change realtime-ticks to std::chrono .. that should clean up a lot of code nicely 21:44:06 <TrueBrain> port my PR to all other drivers .. get macOS to work so I can test it .. 21:44:23 <TrueBrain> after that, dive a bit into the things we talked about the last hour :D 21:44:46 <andythenorth> 'get macOS to work' :) 21:44:48 <andythenorth> generally? 21:45:00 * andythenorth has Apple grump today, had to restart my computer 21:45:09 <TrueBrain> I think our macOS build works fine for .. 50% of the mac users? :D 21:45:10 <andythenorth> since when did a mac ever need restarted? 21:45:30 <andythenorth> the 50% who have working macs TrueBrain and not paperweights sold as 'it just works' :D 21:45:39 <TrueBrain> but I am pretty sure that if I apply my work on the mac driver, your FF speed will improve too :) 21:45:42 * andythenorth such grumpy old man 21:46:11 * andythenorth should try the FFWD on the m1 21:46:33 <frosch123> ffwd it out of the window? 21:46:58 <TrueBrain> I like the idea LordAro suggested, change FF into "x2, x4, x8, AS FAST AS YOU CAN" 21:46:59 <TrueBrain> or something 21:47:13 <TrueBrain> as with my PR + OpenGL PR, FF is too fast to be useful :P 21:47:17 <andythenorth> that might actually be legit 21:47:19 <TrueBrain> we are creating new issues :D 21:47:26 <michi_cc> TrueBrain: https://gist.github.com/michicc/2536e5d15bd268cde4d365205a6f61ff magically looses frame time on OSX. 21:47:30 <andythenorth> I mostly use FFWD to test things like vehicle costs, or industry production 21:47:36 <frosch123> TrueBrain: please test that with a real savegame first :p 21:47:40 <LordAro> TrueBrain: https://github.com/FreeRCT/FreeRCT/pull/168 you're behind the times :p 21:47:43 <andythenorth> *too* fast is not actually so good :D 21:47:48 <TrueBrain> frosch123: I have real savegames in the mix :) 21:47:56 <frosch123> people will complani when their game runs slower than 4x 21:48:16 <TrueBrain> but on empty maps, FF is now silly 21:48:36 <frosch123> people also want x0.5 sometimes 21:48:39 <TrueBrain> 1 sec ~ 1 gamemonth 21:48:41 <frosch123> even though it's ugly 21:49:04 <frosch123> but yt can also play videos in slow mode 21:49:13 <TrueBrain> LordAro: I assumed you stole it from somewhere, the idea :P :P 21:49:51 <frosch123> oh, freerct still exists? 21:50:03 <frosch123> i read so much about openrct 21:50:08 <LordAro> TrueBrain: :p 21:50:22 <LordAro> frosch123: a new guy appeared a few weeks ago 21:50:33 <TrueBrain> michi_cc: if you apply some of my love to that function instead? Does that improve the situation? https://github.com/TrueBrain/OpenTTD/commit/63d19205a7dfd04ef482f5ada9e6df70cc85cb37#diff-6910266f2f33e0ec6795c2785fa7b02f7d8e98cef59e0c69f116fe6067d4243dL293 21:50:35 <LordAro> Alberth has been reviewing things, i've just been leaving it alone 21:50:50 <frosch123> LordAro: i am impressed by the unicode × 21:50:57 <LordAro> haha 21:51:04 <TrueBrain> michi_cc: mostly, instead of doing next = cur_ticks + N, doing next += N 21:51:25 <TrueBrain> michi_cc: wait, no, nevermind 21:51:32 <TrueBrain> more interesting: how precise is that clock 21:51:50 <TrueBrain> so printing cur_ticks - next_ticks 21:52:14 <TrueBrain> DEBUG(misc, 0, "%d", std::chrono::duration_cast<std::chrono::milliseconds>(cur_ticks - next_tick).count()) 21:52:16 <TrueBrain> or something 21:52:24 <frosch123> damn, when you recognise people online... 21:52:26 <TrueBrain> on Windows, this was ~9ms :P 21:52:34 <frosch123> i knew that nickname from widelands :) 21:53:09 <frosch123> widelands and openttd have quite some overlap for some reason 21:53:31 <frosch123> not in code, but in people 21:53:57 <TrueBrain> michi_cc: and ofc, is std::chrono::high_resolution_clock better? :D 21:54:15 <TrueBrain> instead of asking you all these things, I will setup my macOS VM tomorrow so I can check it out myself :) 21:54:31 <TrueBrain> frosch123: what is widelands? 21:54:35 <TrueBrain> (lol, sorry, really no idea) 21:54:53 <TrueBrain> ah, a settlers 21:55:02 <frosch123> settlers2 21:55:18 <frosch123> not a clone, but similar/extended gameplay 21:55:35 <michi_cc> It seems a lot less consistent than the gettimeofday used currently, even if the anecdotal internet comments all seem to say it uses mach system time, which is the most precise you can get. 21:55:37 * LordAro has never really done settlers 21:55:41 <LordAro> had some settlers3 21:55:46 <frosch123> their project leader is out gaelic translator, or used to be 21:55:56 <TrueBrain> wow, that is a lot of commits (widelands) 21:56:12 <frosch123> LordAro: settlers3+ is no settlers :) just like rct3 is no rct1/2 21:56:30 <TrueBrain> michi_cc: weird 21:56:44 <frosch123> settlers1 is pretty unique. settlers2 is considered the best version, though i prefer 1 in some parts 21:56:50 <frosch123> mostly for its weirdness 21:56:59 <TrueBrain> I really liked both games 21:57:05 <TrueBrain> played Settlers 3 for a short moment .. 21:57:54 <TrueBrain> wauw, widelands is on top of their issues/PRs 21:58:36 <frosch123> widelands is a lot of c++ and boost, it takes some time to compile :) 21:59:03 <frosch123> they are new to git, they used to use bazaar 21:59:16 <frosch123> the only time i used bazaar for anything :p 21:59:26 <frosch123> i think their graphics are still in bazaar, not sure 21:59:40 <TrueBrain> anyway, it seems 1.11 will be the release of video-driver improvements .. this can either fail hilarious, or be the best thing evah :D 22:00:56 <LordAro> frosch123: i wouldn't know :p 22:01:16 <LordAro> frosch123: but i was always impressed that the cut down trees actually fell over and the workers made paths in the terrain 22:01:25 <LordAro> i was quite young :p 22:01:37 <LordAro> (and came from an AoEII "background") 22:01:56 <frosch123> i played settlers1 until i hit the unit limit 22:02:17 <frosch123> probably 32k or 64k 22:02:32 <TrueBrain> https://steamcommunity.com/app/1536610/discussions/0/4763089742395168378/ 22:02:37 <TrueBrain> just for the feel-good-feeling 22:02:42 <frosch123> warehouses only displayed ">999", i have no idea how much they actually counted 22:03:57 <TrueBrain> "Wishlist Additions 16,361" 22:03:59 <frosch123> TrueBrain: the most weird part of ottd is that it is not good at the things it is meant to 22:04:09 <TrueBrain> like? 22:04:40 <frosch123> it claims to be about running a business, but money is the most boring part 22:04:54 <TrueBrain> yeah ... last few weeks I came to terms that OpenTTD is just a sandbox 22:05:03 <TrueBrain> thinking it is anything more is just pointless :P 22:05:40 <frosch123> in vanialla-ttd the simulation is also super weird, like original acceleration 22:06:06 <TrueBrain> Maximum daily peak concurrent users 1 22:06:13 <TrueBrain> Median time played 3 minutes 22:06:52 <frosch123> i probably won't find that review again.. but it described very nicely how ottd is a great game, but in none of the places where it was intended to be 22:07:11 <TrueBrain> I can understand that opinion indeed :) 22:07:19 <TrueBrain> I think if you remove money, not many people notice 22:07:30 <TrueBrain> so instead of removing inflation, or changing economy, lets remove money completely! 22:07:49 <TrueBrain> an official "sandbox" mode is honestly not the worst idea 22:08:02 <frosch123> there is the money cheat 22:08:12 <TrueBrain> just remove all money-related windows and things 22:08:20 <frosch123> "sandbox" requests are usally about "remove town authority", allow flattening the map 22:08:26 <frosch123> i don't support that :p 22:08:29 <TrueBrain> no 22:08:36 <TrueBrain> I just mean: don't worry about money 22:08:37 <TrueBrain> like, at all 22:08:54 <frosch123> i think money is important for new players 22:09:02 <TrueBrain> hence a mode :) 22:09:19 <TrueBrain> first few tries someone should understand that a coal train is the only viable start :P 22:09:30 <TrueBrain> you cannot miss that experience 22:09:37 <_dp_> you can make money matter! :p 22:09:47 <frosch123> no, you can't 22:10:04 <TrueBrain> and why I say a sandbox mode vs money cheat .. a cheat feels like it is against the game, how it is meant to be played 22:10:13 <TrueBrain> a sandbox mode makes it clear: this is fine, you go ahead now 22:10:15 <frosch123> money is the only resource in ottd. income will always be mostly exponential 22:10:19 <TrueBrain> accepting your identity etc etc :D 22:10:27 <_dp_> frosch123, it does on citymania 22:10:39 <TrueBrain> haha: collect steel to build rails 22:10:44 <TrueBrain> lets make this into a new game :D 22:10:44 <frosch123> so the only thing money does it limit your building speed in early game 22:11:14 <TrueBrain> I cannot remember a moment I had to FF to get money after the first few years, no 22:11:24 <TrueBrain> even when you get maglev, you can basically just upgrade everything 22:11:26 <TrueBrain> and still have money 22:12:02 <_dp_> in good citybuilder any spare money goes into funding town or industries 22:12:35 <frosch123> hmm, that guy on steam: with "ttd upgrade" they mean ttdp, right :p 22:12:44 <TrueBrain> I would guess so :) 22:12:58 <TrueBrain> I have to say, the first person on Steam Community didn't make a good impression of what Steam has to offer 22:13:03 <TrueBrain> but after that, it is pretty okay 22:13:10 <_dp_> btw, would be nice to be able to add more resources to the game 22:13:11 <TrueBrain> the bad is not as much present as the good 22:13:14 <_dp_> kinda like mashinky doeos 22:13:21 <TrueBrain> _dp_: Cargo and GS :) 22:13:55 <TrueBrain> right, time to get some zzzzzz 22:15:01 <_dp_> cargo is quite specific resource 22:15:15 <_dp_> like, you can't just give cargo to a company for example 22:15:18 <frosch123> what resouced does machinsky have? 22:15:49 <_dp_> I don't remember exactly, some kind of coal coin, steel coin and such 22:16:44 <_dp_> it's more about being able to add whatever suits gs then some particular set of resources 22:17:19 <frosch123> i thought you meant stuff like terraforming credits or "landmass" 22:17:36 <_dp_> yeah, that can be too 22:17:43 <_dp_> terra credits kinda exist already 22:17:46 <frosch123> you can only lower land if you raise it somewhere else, and vice versa 22:17:53 <frosch123> distance costs :p 22:18:02 <_dp_> but smth like rail credits would be interesting 22:21:52 <_dp_> ideally it would be up to gs to decide how resource is used 22:21:59 <_dp_> openttd just have to add some ui support 22:27:56 <frosch123> ah, TrueBrain is gone. so i can approve a belgian as dutch translator :p 22:28:11 <DorpsGek> [OpenTTD/team] frosch123 commented on issue #141: [nl_NL] Translator access request https://git.io/Jt145 22:32:50 *** Progman has quit IRC 22:33:26 <TrueBrain> Evil 22:34:33 <LordAro> :D 22:36:16 *** jottyfan has joined #openttd 22:40:52 *** jottyfan has quit IRC 22:41:16 *** frosch123 has quit IRC 22:48:42 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #8681: Fix: Autorenew failure advice due to bad refit being shown to all companies https://git.io/Jt1Ff 23:06:01 *** Wolf01 has quit IRC 23:25:57 *** gelignite has quit IRC 23:31:59 <andythenorth> nap! 23:32:05 *** andythenorth has quit IRC 23:42:23 *** sla_ro|master has quit IRC 23:44:37 *** glx has quit IRC 23:45:24 *** Con_TheGranny has joined #openttd 23:45:54 <Con_TheGranny> Where can I report a FIRS bug?