IRC logs for #openttd on OFTC at 2021-02-16
⏴ go to previous day
00:09:06 *** andythenorth has quit IRC (Quit: andythenorth)
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 (Quit: Leaving)
02:15:15 *** TrueBrain has quit IRC (Ping timeout: 480 seconds)
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:23 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on pull request #8603: Feature: Object class selection string filtering https://git.io/JtXbg
03:34:22 *** debdog has quit IRC (Ping timeout: 480 seconds)
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 (Remote host closed the connection)
05:39:53 *** WormnestAndroid has joined #openttd
05:46:51 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
05:47:05 *** WormnestAndroid has joined #openttd
06:07:32 *** snail_UES_ has quit IRC (Quit: snail_UES_)
07:22:25 *** andythenorth has joined #openttd
07:42:52 <andythenorth> validate my existence!
07:43:01 * andythenorth hasn't been outside enough
07:43:05 *** yoyo[m] has left #openttd (User left)
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: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 (Quit: andythenorth)
08:12:57 *** HerzogDeXtEr has joined #openttd
08:13:28 *** andythenorth has joined #openttd
08:46:58 *** supermop_Home has quit IRC (Ping timeout: 480 seconds)
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:12:19 <FLHerne> I did, then I forgot all the things I wanted to do
10:17:05 *** jottyfan has joined #openttd
10:19:07 <andythenorth> lol @ mac ffwd 22x in a well established running game
10:19:33 <andythenorth> oh it's pushing 28x if I move to the map edge
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 (Remote host closed the connection)
11:34:01 *** WormnestAndroid has joined #openttd
11:44:48 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
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:37 <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: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: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: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 (Read error: Connection reset by peer)
12:55:07 *** WormnestAndroid has joined #openttd
12:56:49 *** Greyfur has joined #openttd
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: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: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: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: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:58:17 *** Extrems has joined #openttd
13:58:56 *** snail_UES_ has joined #openttd
14:01:08 <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: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: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 <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: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: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:33 <TrueBrain> so those NewGRFs would be bad
14:29:39 <TrueBrain> also depends how many viewports are open on them
14:29:43 <TrueBrain> okay, so that shouldn't be an issue
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 (Quit: andythenorth)
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: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: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: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: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: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 (Quit: A toaster's basically a soldering iron designed to toast bread)
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:36 <LordAro> if i remember, i'll test it out on actual-Linux tonight for you
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: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 (Quit: andythenorth)
16:24:53 <Eddi|zuHause> TrueBrain: FFWD speed increases from ca. x3.5 to x4.5 on this large semi-busy map
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:43:17 <Wolf01> glx: found the solution for the settings assert?
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: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: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: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: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: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 <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: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: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: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: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:41:02 <TrueBrain> owh, sorry, totally missed what you meant to say there nielsm
17:41:13 *** Progman has quit IRC (Remote host closed the connection)
17:41:26 <TrueBrain> I need a bit more breadcrumbs than that
17:41:47 <TrueBrain> as in, which clock?
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: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: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: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:45 <andythenorth> eh, wrong text input :P
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: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: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:53 <LordAro> what was it running as before?
17:54:20 <nielsm> does this mean windows will no longer run slightly slower in singleplayer compared to SDL and mac?
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: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: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:57:09 <LordAro> not a TT/TTD issue then? :p
17:57:17 <TrueBrain> really don't know :)
17:57:27 <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:58:00 <nielsm> I'm thinking TT on DOS probably timed to screen refresh
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:42 <glx> std::chrono should work for macOS too ;)
17:59:55 <TrueBrain> I have not looked at how the driver does ticks
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: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:33 <DorpsGek> [OpenTTD/BaNaNaS] frosch123 opened pull request #83: Change: migrate OpenTTD user Dante123 to GitHub user Flame1869 https://git.io/Jt16w
18:01:51 <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:39 <TrueBrain> names felt like they matched
18:02:42 <TrueBrain> duno .. Dante .. Flame .. I get it
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: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: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: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:10:30 <_dp_> whatever you do make sure it uses steady clock :p
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:28 <TrueBrain> well, video drivers detect this btw
18:14:38 <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:39 <_dp_> why does high_resolution_clock even exist?
18:17:56 <_dp_> might've as well named it some_random_clock
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: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 (Quit: andythenorth)
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:41 <glx> hrc is highest precision, that's all
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: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: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:57 <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: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: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:17 <DorpsGek> - Update: Translations from eints (by translators)
19:05:10 <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: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: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: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:46 <TrueBrain> so you could still do "last timestamp - first timestamp", but there might be invalid datapoints in there
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: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: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: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: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: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: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:45 <TrueBrain> another off-by-one?
19:47:47 <frosch123> didn't you just fix one obiwan?
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:50:08 <TrueBrain> and change the default to 60fps for GUI? :)
19:50:59 <frosch123> wasn't the mouse already drawn faster?
19:51:16 <frosch123> what else does matter? dragging windows?
19:52:02 <DorpsGek> TrueBrain: 166.66666666666666
19:52:20 <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:14 <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:41 <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: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: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:19:07 <TrueBrain> estimated cost of repaying your loan is 0 :D
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:13 <frosch123> sure, when github works again
20:26:13 <andythenorth> I forgot to have beer
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 (Quit: jottyfan)
20:30:04 <TrueBrain> doesn't remove the confusion LordAro ;)
20:30:18 <LordAro> bootstrap_but_not_that_bootstrap
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: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: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:48 <frosch123> my simulation rate seems to be continuous above 33.33
20:58:13 <TrueBrain> with the PR of my other branch?
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: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: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: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:53 <frosch123> oh, video-performance is different on fast-forward
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:51 <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: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: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: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: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: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: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: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: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: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 (Ping timeout: 480 seconds)
21:38:33 <TrueBrain> there is indeed code to just try to catch up
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: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: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: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: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:22 <LordAro> frosch123: a new guy appeared a few weeks ago
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: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: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: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: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: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: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: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: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:20 <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:36 <TrueBrain> I just mean: don't worry about money
22:08:54 <frosch123> i think money is important for new players
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: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: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: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:32:50 *** Progman has quit IRC (Remote host closed the connection)
22:36:16 *** jottyfan has joined #openttd
22:41:16 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
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 (Quit: Once again the world is quick to bury me.)
23:25:57 *** gelignite has quit IRC (Quit: Stay safe!)
23:32:05 *** andythenorth has quit IRC (Quit: andythenorth)
23:42:23 *** sla_ro|master has quit IRC ()
23:45:24 *** Con_TheGranny has joined #openttd
23:45:54 <Con_TheGranny> Where can I report a FIRS bug?
continue to next day ⏵
