IRC logs for #openttd on OFTC at 2021-02-24
⏴ go to previous day
00:03:41 <peter1138> There was PNG loading at some point, but it was removed for performance raisins.
00:21:53 <TrueBrain> LordAro: not far off my mockup, so yes, that are tabs I can het behind :D
00:25:12 *** Smedles has quit IRC (Ping timeout: 480 seconds)
00:27:13 *** Smedles has joined #openttd
00:36:09 *** gelignite has quit IRC (Quit: Stay safe!)
00:38:31 *** Smedles has quit IRC (Ping timeout: 480 seconds)
00:40:59 *** Smedles has joined #openttd
00:43:35 *** Compu has quit IRC (Remote host closed the connection)
00:47:16 *** FLHerne has quit IRC (Quit: Goodbye (ZNC disconnected))
00:48:27 *** FLHerne has joined #openttd
00:51:28 *** Extrems has quit IRC (Remote host closed the connection)
00:51:33 *** Extrems has joined #openttd
01:10:51 *** Smedles has quit IRC (Ping timeout: 480 seconds)
01:20:05 *** rptr has quit IRC (Ping timeout: 480 seconds)
01:25:39 *** Smedles has joined #openttd
01:26:15 *** Beerbelott has quit IRC (Quit: Leaving)
01:49:47 <Eddi|zuHause> so... i managed to sneak -flto=6 into the CXX_FLAGS, not sure if that was the "correct" way to do it though
01:51:43 <Eddi|zuHause> that just about cut the compile time in half
02:10:20 <supermop_Home> unfortunately eddi I am your only audience, so your feat is wasted on me
02:10:57 *** Tirili has quit IRC (Quit: Leaving)
02:22:10 *** rptr has quit IRC (Ping timeout: 480 seconds)
02:28:01 *** Smedles has quit IRC (Quit: No Ping reply in 180 seconds.)
02:28:14 *** Smedles has joined #openttd
02:57:44 *** Wuzzy has quit IRC (Quit: Wuzzy)
03:07:21 *** ChanServ sets mode: +v tokai
03:18:06 *** Smedles has quit IRC (Ping timeout: 480 seconds)
03:25:42 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:28:00 *** Smedles has joined #openttd
03:31:03 *** Wormnest has quit IRC (Quit: Leaving)
03:34:38 *** muffindrake3 has joined #openttd
03:36:28 *** muffindrake2 has quit IRC (Ping timeout: 480 seconds)
04:39:19 *** rptr has quit IRC (Remote host closed the connection)
05:35:40 <DorpsGek> [OpenTTD/OpenTTD] perezdidac updated pull request #8706: Feature: rail station class name filtering https://git.io/Jt9ev
05:48:47 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
05:48:54 *** WormnestAndroid has joined #openttd
06:21:27 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
06:21:43 *** WormnestAndroid has joined #openttd
07:08:41 *** tokai|noir has joined #openttd
07:08:41 *** ChanServ sets mode: +v tokai|noir
07:12:04 *** sla_ro|master has joined #openttd
07:15:30 *** didac has quit IRC (Remote host closed the connection)
07:15:47 *** tokai has quit IRC (Ping timeout: 480 seconds)
07:19:26 *** andythenorth has joined #openttd
08:00:45 <DorpsGek> [OpenTTD/OpenTTD] LordAro merged pull request #8739: Fix: vehicle-cursor size-limit did not account for the interface zoom level. https://git.io/Jt5Y1
08:01:17 *** HerzogDeXtEr has joined #openttd
08:18:19 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed issue #8632: Graph window - Markings of the periods on the graph are unreadable https://git.io/JtBxX
08:20:29 <LordAro> how long before PRs overtake issues? :p
08:20:52 <LordAro> or will we get flooded with issues from steam first? :p
08:21:21 <TrueBrain> oof .. lets hope not :P
08:23:02 <andythenorth> if we do, we can practice closing them
08:23:16 <andythenorth> closing issues is just a good habit, like daily exercise
08:26:34 <Wolf01> Meh, why am I so devastated today?
08:30:49 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain requested changes for pull request #8718: Change: [Actions] stop relying on external actions for trivial stuff, and rely on cmake tools to build, test and pack https://git.io/Jt5Xp
08:32:18 <TrueBrain> TIL, caching on GitHub Actions is more tricky than expected :D
08:35:27 <andythenorth> Wolf01 because virus?
08:50:58 <TrueBrain> okay, I fixed the issue that simulation can run slower because of drawing .. I now just don't draw if the simulation goes below 33fps
08:51:04 <TrueBrain> sounds like a good idea, not?
09:07:25 <TrueBrain> I always forget mutex' are a bit too optimized, and if they claim the mutex shortly after releasing it, threads won't context switch ..
09:26:45 <TrueBrain> funny how little impact threaded drawing now has :P
09:26:55 <TrueBrain> as in, I have a hard time finding a game where it differs
09:27:12 <TrueBrain> which kinda makes sense I guess, as it takes, what 0.15ms per frame
09:28:03 <LordAro> increase your refresh rate to 1440 :p
09:28:19 <TrueBrain> doesn't change anything about how much time a frame costs :)
09:28:38 <TrueBrain> remember that to draw something new, we need to run UpdateWindows with the lock on the gamestate
09:29:02 <TrueBrain> which is the function that takes most time
09:29:10 <TrueBrain> but cannot be done at the same time as GameLoop
09:29:50 <Wolf01> <andythenorth> Wolf01 because virus? <- we don't know, I'm waiting for more tests
09:30:05 <TrueBrain> I now have a game that looks something like this: GameLoop - 50ms, UpdateWindows - 10ms - Paint - 0.05ms
09:30:13 <TrueBrain> GameLoop and UpdateWindows cannot run at the same time
09:30:17 <TrueBrain> so best I can win is 0.05ms
09:30:22 <TrueBrain> at the cost of a thread-switch :P
09:30:54 <TrueBrain> we need to move stuff out of UpdateWindows, basically, the parts that don't need the lock on the game-state anymore
09:32:39 <TrueBrain> ah, no, found a game where Paint takes 5ms!
09:32:50 <TrueBrain> still almost no measurable difference in framerate, ofc :)
09:33:15 <TrueBrain> I had to switch to no-OpenGL to notice it :P
09:35:26 <TrueBrain> I can give up draw fps for simulation speed .. but where is the balance there :)
09:35:47 <TrueBrain> this game was running on 17 fps .. it is now at 6 fps, but the simulation went from 0.5x to 0.55x
09:37:07 <Timberwolf> Hm... on the one hand it's a 10% improvement, on the other that takes a "just about playable" framerate to slideshow.
09:37:35 <Timberwolf> At least, for modern eyes.
09:37:58 <LordAro> that does not sound like an improvement, really
09:38:09 <Timberwolf> Every so often I have a crack at playing some racing game from my youth and I can't believe how the framerates used to be considered "normal"
09:38:23 <TrueBrain> LordAro: that depends on your goal, I guess
09:38:53 <Timberwolf> Geoff Crammond's Formula One Grand Prix was 8fps on a low-end Amiga!
09:39:31 <Timberwolf> I never remember even noticing "frame rate" as a thing, although it did feel smoother on my 286 which could handle 11fps.
09:39:33 <TrueBrain> but so yeah, I can set a minimum draw fps, which only cannot be reached if the simulation dips below it
09:40:08 <TrueBrain> so simulations get priority basically, up to the point fps would drop below, say, 25fps? after that, they both go down
09:42:04 <Timberwolf> Crammond used the "draw the frame then wait until it's time to draw the next" approach, so you could set fps higher than your computer could handle and instead it slowed down time. (e.g. setting 25fps on a 286 gave you ~2.2s real time per second of game time). There was a bit of a controversy about world records being set using this.
09:42:05 <Wolf01> Timberwolf: you only recognize things when you know their name, I've read a study on the "discovery" of colours
09:42:33 <Timberwolf> Hm. Complication here: I think it's fine to dip below 25fps on a fully zoomed out view, but not when you're zoomed in and building stuff.
09:42:50 <TrueBrain> this is a lovely balancing act .. what wins from what :)
09:47:41 <TrueBrain> well, I can run ProGame5 at 1x simulation with my changes
09:47:45 <TrueBrain> just fps drops to ~20fps
09:47:53 <TrueBrain> means in multiplayer I would keep up
09:50:09 <TrueBrain> game runs at 28 frames/s simulation with master for me, and at 33 frames/s simulation with my patch .. at the cost of missing more frames :)
09:51:15 <TrueBrain> it is just a problem when GameLoop cannot do its job in 30ms .. something has to give
10:01:06 <peter1138> Trying to make a slow game run faster without reducing interactiveness is fun.
10:02:39 <peter1138> There was a change I tested that improved game tick performance by changing the order of vehicle ticks. Improved things for me, but slowed it down for others...
10:07:09 <TrueBrain> what is lovely, if you manage to deadlock the game-thread
10:07:14 <TrueBrain> at least it is 60fps!
10:22:15 <TrueBrain> awh, semaphores are c++20
10:22:23 <TrueBrain> can we change to c++20? :D
10:24:11 <_dp_> can't you just grab the implementation?
10:25:54 <LordAro> TrueBrain: i think you have to do a certain amount of compiler writing too
10:26:47 <TrueBrain> small effort for such a lovely construct!
10:27:28 <LordAro> apparently both libstdc++ & libc++ have implementations of it
10:27:52 <TrueBrain> I kinda need fibers, or cooperative multithreading
10:28:59 <TrueBrain> too bad there isn't an easy way to force a context switch
10:29:05 <TrueBrain> which sucks for different reasons
10:29:29 <TrueBrain> yield is just a suggestion
10:34:44 *** jjavaholic has quit IRC (Quit: Leaving)
10:41:25 *** gelignite has joined #openttd
10:53:08 *** rptr has quit IRC (Ping timeout: 480 seconds)
11:07:22 *** supermop_Home has quit IRC (Ping timeout: 480 seconds)
11:28:57 <TrueBrain> okay, I got most of this working now
11:29:08 <TrueBrain> I just have to split _realtime_tick to have a game-thread variant and a draw-thread variant
11:29:15 <TrueBrain> as otherwise they might behave weird :D
11:29:22 <TrueBrain> (read: that variable is not thread-safe atm)
11:29:30 <TrueBrain> I could also make it a std::atomic, I guess
11:29:36 <TrueBrain> but splitting it might be the proper thing to do
11:30:51 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #8738: Fix #8123: trams on half-tiles couldn't find depots https://git.io/Jt5dA
12:01:07 *** ChanServ sets mode: +v tokai
12:02:21 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8738: Fix #8123: trams on half-tiles couldn't find depots https://git.io/Jt5Yr
12:02:25 *** andythenorth has quit IRC (Quit: andythenorth)
12:03:16 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8738: Fix #8123: trams on half-tiles couldn't find depots https://git.io/Jt5Fj
12:04:27 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8738: Fix #8123: trams on half-tiles couldn't find depots https://git.io/Jt5Yr
12:07:56 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
12:15:00 <Timberwolf> There's the occasional bad offset, I tweaked a few of them to give the best compromise but I think there are a few size/angle combinations that are still "off" for longer vehicles.
12:15:47 <Timberwolf> They're autogenerated using a tool which sometimes gets it wrong. One of those things I've been meaning to look at to see if they can be improved in those cases.
12:24:54 <Timberwolf> I did play with that angle a while ago, but I might have ended up making a change which favoured generation of the shorter vehicle templates at the cost of making larger ones worse.
12:37:35 *** tokai|noir has joined #openttd
12:37:35 *** ChanServ sets mode: +v tokai|noir
12:44:22 *** tokai has quit IRC (Ping timeout: 480 seconds)
12:45:04 *** ChanServ sets mode: +v tokai
12:45:36 <TrueBrain> "unlock of unowned mutex"
12:45:40 <TrueBrain> that is a little bit sad :P
12:46:24 <Eddi|zuHause> multithreading is hard.
12:46:49 <TrueBrain> too bad it is not telling me clearly who is causing it :D
12:47:39 <TrueBrain> as it works on Linux of course, and Windows is failing :P
12:47:58 <TrueBrain> you know, a regular day in the office
12:49:10 <TrueBrain> somehow I doubt it is my code, as I use lock_guard :)
12:49:27 <TrueBrain> so what did I screw up that others parts are now confused :P
12:51:51 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
12:54:05 <TrueBrain> the minor differences in implementations, you got to love it :)
12:54:38 <peter1138> Euf, might put the heating up.
12:55:05 <peter1138> Thermostat says it's 21, my feet say it's freezing...
12:57:07 <Eddi|zuHause> that's because cold air floats to the bottom of the room
12:58:32 <peter1138> Is that like a ship wrecking floating on the bottom of an ocean?
12:58:59 <Eddi|zuHause> no, that's because of salt concentration
13:03:35 <TrueBrain> okay, this is funny .. with my PR, on Windows, with OpenGL without using threads, the mouse works, but the rest doesn't update :D
13:03:51 <TrueBrain> no clue why not .. works fine in non-OpenGL under the same circumstances :)
13:04:50 <TrueBrain> owh, and while Fast-Forwarding, I forgot that detail
13:05:07 <TrueBrain> seems if you don't yield the main thread, OpenGL doesn't update, or something ..
13:09:23 <TrueBrain> also happens on Linux, so yeah, OpenGL related
13:12:04 *** supermop_Home has joined #openttd
13:12:57 <FLHerne> supermop_Home: Is all this NML generated with some sort of script?
13:13:03 <FLHerne> Or are you just copy-pasting a lot? :p
13:13:22 <supermop_Home> type and copy paste
13:17:05 <supermop_Home> yes, it is pretty embarassing
13:55:31 <peter1138> I remember OpenGL is picky about threads. You should only ever call it from one thread.
13:55:44 <TrueBrain> we are only calling it from one thread
13:59:35 <TrueBrain> otherwise it indeed says boom real quick
14:00:10 *** WormnestAndroid has quit IRC (Remote host closed the connection)
14:00:23 *** WormnestAndroid has joined #openttd
14:03:10 <TrueBrain> that lovely moment you pick up your PR, put it aside, start from scratch to make decent commits out of it all :D
14:03:41 <peter1138> So many rewrites...
14:04:02 <TrueBrain> I am just copy/pasting the branch I put aside
14:04:09 <TrueBrain> just .. in more commits than one :D
14:04:25 <peter1138> Sometimes you need the complete picture before you know what the steps are.
14:05:09 <peter1138> Always a problem with development "How long will it take?" "I'll let you know once it's done."
14:07:53 <Eddi|zuHause> the problem is if there's a boss who says "i need this done by <date>"
14:08:15 <Eddi|zuHause> and then asks why it's not done yet
14:08:30 <Eddi|zuHause> but there are 5 dozen reasons, each contributing just a little bit of delay
14:13:18 <TrueBrain> seems typing is hard today .. ugh :P
14:33:11 *** gelignite has quit IRC (Quit: Stay safe!)
14:33:56 <Eddi|zuHause> now that we finally moved to the next millennium with OpenGL, what about Vulkan? :p
14:38:09 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #8741: Move GameLoop into a thread (and no longer run Paint in a thread) https://git.io/JtdUz
14:38:19 <TrueBrain> still draft ^^, but it is getting there :)
14:41:03 <TrueBrain> first step to keeping the UI responsive, even during map-gen
14:41:10 <TrueBrain> and I mean 60fps responsive, if we would like
14:43:48 <TrueBrain> and "offers" keep pouring in at info@
14:44:28 <TrueBrain> and most of them have this line: if you don't want email from me again, reply ... to my email
14:44:31 <TrueBrain> ... like .. fuck no
14:47:32 <FLHerne> supermop_Home: for context, I've been thinking about how to make NML source less stupidly verbose for the things that people actually use it for
14:48:04 <FLHerne> So having an example of a giant hand-written file, rather than andy and Eddi's giant generated files, is quite useful
14:48:11 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #8718: Change: [Actions] stop relying on external actions for trivial stuff, and rely on cmake tools to build, test and pack https://git.io/JtdTr
14:48:30 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8741: Move GameLoop into a thread (and no longer run Paint in a thread) https://git.io/JtdUz
14:49:00 <supermop_Home> FLHerne i try to come up with systems of nomenclature that makes sense to me, but i really should have better comments
14:49:12 <TrueBrain> sounds a lot safer indeed glx :)
14:55:43 <DorpsGek> [OpenTTD/OpenTTD] glx22 dismissed a review for pull request #8718: Change: [Actions] stop relying on external actions for trivial stuff, and rely on cmake tools to build, test and pack https://git.io/JtQDc
14:55:46 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #8718: Change: [Actions] stop relying on external actions for trivial stuff, and rely on cmake tools to build, test and pack https://git.io/Jt959
14:59:13 <glx> key: --vcpkg-x86 <-- hmm something is wrong
15:02:39 <supermop_Home> ugh still can't think of a better name than 'mop generic road vehicles'
15:22:13 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #8718: Change: [Actions] stop relying on external actions for trivial stuff, and rely on cmake tools to build, test and pack https://git.io/Jt959
15:24:57 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #8718: Change: [Actions] stop relying on external actions for trivial stuff, and rely on cmake tools to build, test and pack https://git.io/Jt959
15:30:41 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #8718: Change: [Actions] stop relying on external actions for trivial stuff, and rely on cmake tools to build, test and pack https://git.io/Jt959
15:42:29 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #8718: Change: [Actions] stop relying on external actions for trivial stuff, and rely on cmake tools to build, test and pack https://git.io/Jt959
15:44:22 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #8718: Change: [Actions] stop relying on external actions for trivial stuff, and rely on cmake tools to build, test and pack https://git.io/Jt959
15:46:50 *** Flygon has quit IRC (Read error: Connection reset by peer)
15:53:19 <Xaroth> hm, why-oh-why is it complaining about fontcache when building
16:03:14 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #8718: Change: [Actions] stop relying on external actions for trivial stuff, and rely on cmake tools to build, test and pack https://git.io/Jt959
16:03:21 <glx> should be the last one :)
16:33:39 *** Progman has joined #openttd
16:49:13 <TrueBrain> yippie, found my OpenGL issue :D That was silly ...
16:49:39 <glx> hehe I needed so many push for a simple change
16:51:11 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #8718: Change: [Actions] stop relying on external actions for trivial stuff, and rely on cmake tools to build, test and pack https://git.io/JtdZG
16:54:28 <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #8718: Change: [Actions] stop relying on external actions for trivial stuff, and rely on cmake tools to build, test and pack https://git.io/Jt959
16:54:43 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8741: Move GameLoop into a thread (and no longer run Paint in a thread) https://git.io/JtdUz
16:54:45 <TrueBrain> well, in my case I forgot to lock the video buffer when I was going to write to it :P
16:54:52 *** y2kboy23 has joined #openttd
16:55:13 <glx> didn't recheck release workflow, it should still work (if copy paste from CI didn't fail)
16:55:31 <TrueBrain> we will know in a few hours if you should have done that :P
16:57:45 <glx> one important thing, if first run of new image fails, caching is dead for all following runs
16:58:59 <glx> or only if cache save fails, anyway it's a reservation/lock issue from cache action
16:59:00 <TrueBrain> I did read caches invalidate after N days, but not sure if that is true when you use them :)
17:02:34 <TrueBrain> I like how unclear it is in OpenTTD what functions exactly write in the video buffer :)
17:02:44 <TrueBrain> trying to follow N functions throughout the code
17:04:07 <DorpsGek> [OpenTTD/website] LordAro opened pull request #191: Change: Make it clearer that macOS 11 is supported https://git.io/Jtdn8
17:05:08 *** Wormnest has joined #openttd
17:05:55 <DorpsGek> [OpenTTD/website] TrueBrain commented on pull request #191: Change: Make it clearer that macOS 11 is supported https://git.io/JtdnE
17:10:18 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8741: Move GameLoop into a thread (and no longer run Paint in a thread) https://git.io/JtdUz
17:12:24 <glx> cache worked (on your first run it had to rebuild because master was still running)
17:12:55 <glx> so yout PR has it's own cache
17:13:10 <TrueBrain> bah, screenshots now crash the game, grrrr
17:13:46 <TrueBrain> its hard to get all these buffers right, if you start inverting logic
17:44:09 <TrueBrain> weird, making a screenshot fails somewhere in libpng .. that is not what I expected :D
17:45:42 <TrueBrain> lets see if that problem exists in master ..
17:47:03 <TrueBrain> okay, it does .. I was hunting ghosts :P
17:48:51 <TrueBrain> something about my local setup
17:50:02 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8741: Move GameLoop into a thread (and no longer run Paint in a thread) https://git.io/JtdUz
17:51:54 *** gelignite has joined #openttd
17:53:37 <didac> hey there, anyone free to review 8706 and 8733 thanks!
17:55:02 *** nielsm has quit IRC (Ping timeout: 480 seconds)
17:55:26 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #8730: Codechange: [OpenGL] Load all OpenGL functions dynamically. https://git.io/JtdlD
17:58:45 <TrueBrain> so tempted to make some Javascript that can render GUIs from C++ code .. and possibly allow modifying it and generate C++ again ..
17:58:54 <TrueBrain> so tired of starting the game every time to find out it still doesn't look right :D
17:59:44 <TrueBrain> LordAro: your suggestion for manylinux images is still amazingly good .. working with those images is so much easier :D
18:02:50 <TrueBrain> hmm .. even with that OpenGL load dynamic patch, the Linux binary is linked against OpenGL
18:02:56 <TrueBrain> which is a world of hurt, as that drags in X11 too :P
18:03:17 <TrueBrain> how to find what caused that, hmm
18:09:25 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8730: Codechange: [OpenGL] Load all OpenGL functions dynamically. https://git.io/Jtd8h
18:30:26 *** andythenorth has joined #openttd
18:34:41 *** frosch123 has joined #openttd
18:52:23 *** Samu has quit IRC (Read error: Connection reset by peer)
19:10:57 *** qwebirc1034 has joined #openttd
19:17:21 *** qwebirc1034 has quit IRC (Remote host closed the connection)
19:26:54 <michi_cc> TrueBrain: That is a very good question which I don't remember at all anymore :) Maybe something with threaded drawing???? Or maybe L1200 is superfluous or L1552 simply wrong :D
19:27:14 <TrueBrain> I solved it in my PR correctly in that case :P
19:27:23 <TrueBrain> (I made everything like L1552)
19:27:33 <TrueBrain> I now guarantee the video buffer is locked during Paint, basically :)
19:27:55 <TrueBrain> for master it is not a problem, as the buffer is always locked during Paint
19:28:06 <TrueBrain> was mostly wondering if I missed something obvious; clearly I did not :D Tnx!
19:28:22 <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #8730: Codechange: [OpenGL] Load all OpenGL functions dynamically. https://git.io/Jtduf
19:29:27 <TrueBrain> so we just have to make it conditional for SDL ^^ :) Which gives an interesting question what to do with Windows + SDL, but that is not a supported situation anyway :P
19:40:57 *** Smedles has joined #openttd
19:47:35 *** _2TallTyler has joined #openttd
19:47:56 <Timberwolf> FLHerne: I found the source of your alignment issue with the passenger carriage, L10 and L11 vehicles disagree on the length of individual sections between the template generator and the set itself (which also explains the source of some weird logic specific to those lengths)
19:50:09 <michi_cc> TrueBrain: Is it guaranteed on Linux that you don't some special include path for the GL headers?
19:50:37 <TrueBrain> what do you mean, sorry?
19:51:02 <michi_cc> Isn't link_package also added include paths if necessary?
19:51:19 <michi_cc> We still need the header files, even if we don't link to the library.
19:51:27 <TrueBrain> hmm .. it did not return any warning :D
19:51:41 <TrueBrain> what header is used .. lets see
19:51:45 <michi_cc> Well, most Linux variants are probably going to have it in the default include path.
19:52:03 <michi_cc> I'm just wondering if there's any special variants out there.
19:52:07 <TrueBrain> ah, yes, it is in /usr/include
19:52:14 <TrueBrain> better link with only include-path in that case :)
19:55:39 <TrueBrain> yeah, the file comes from libgl-dev, so adding the include-path is indeed the minimal thing to do
19:55:45 <TrueBrain> I was hoping SDL would supply it :P
20:00:24 *** tokai|noir has joined #openttd
20:00:24 *** ChanServ sets mode: +v tokai|noir
20:07:18 *** tokai has quit IRC (Ping timeout: 480 seconds)
20:22:48 <glx> it should be possible to use OPENGL_INCLUDE_DIR only
20:29:46 <TrueBrain> not sure our link_package allows that currently
20:29:56 <TrueBrain> which might make it a bit tricky
20:34:02 <DorpsGek> [OpenTTD/OpenTTD] michicc opened pull request #8742: Fix #8734: [OpenGL] Apply palette remap to cursor sprites. https://git.io/JtdgJ
20:44:56 *** jottyfan has joined #openttd
20:48:06 *** andythenorth_ has joined #openttd
20:50:30 *** andythenorth_ has quit IRC ()
20:52:43 *** andythenorth has quit IRC (Ping timeout: 480 seconds)
20:52:55 *** jottyfan has quit IRC (Quit: jottyfan)
20:53:03 *** andythenorth has joined #openttd
20:58:37 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #8742: Fix #8734: [OpenGL] Apply palette remap to cursor sprites. https://git.io/JtdgD
20:58:38 <TrueBrain> you have been busy michi_cc :o
20:58:49 *** ChanServ sets mode: +v tokai
21:02:05 <andythenorth> lol I looked up how common thermal throttling is on my mac
21:02:23 <andythenorth> one of the top results explains that it's probably due to flash banner ads in news websites
21:02:32 <glx> haha I wanted to check if I broke nightly but "This scheduled workflow is disabled because there hasn't been activity in this repository for at least 60 days. "
21:02:38 * andythenorth will ignore that particular piece of FML internet
21:02:55 <andythenorth> also I won't be adding my own custom CPU heatsink
21:03:32 <andythenorth> TL;DR the CPU and GPU are 95W of thermal parts in a 90W enclosure
21:03:36 <andythenorth> guess how well that goes?
21:04:54 <TrueBrain> glx: really? Normally it emails about that ...
21:05:20 <glx> well it runs them, but they do nothing
21:05:23 <TrueBrain> well, they are enabled now
21:05:38 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
21:05:40 <TrueBrain> I know we have to do that every 2 months, but last time it send me an email it was about to disable them
21:05:42 <TrueBrain> annoying it doesn't
21:05:55 <TrueBrain> guess we need to make a ping/pong
21:07:11 <TrueBrain> lets see if the manual trigger still works
21:07:36 <_2TallTyler> Question: I'm having a go at groundhog year (#7938, but more thorough) and would like to add a bool is_looping_year which can be accessed from many places in the code. Where might be a good place to keep it? date_type.h?
21:08:17 <glx> would have been better to trigger eints first
21:08:28 <glx> well translations can wait a day
21:10:00 <TrueBrain> I did consider it for a sec, but I was too lazy to wait for 10+ minutes
21:10:29 <DorpsGek> [OpenTTD/OpenTTD] michicc merged pull request #8742: Fix #8734: [OpenGL] Apply palette remap to cursor sprites. https://git.io/JtdgJ
21:10:32 <DorpsGek> [OpenTTD/OpenTTD] michicc closed issue #8734: Vehicles not rendered in 2CC when dragged inside a depot https://git.io/Jt5JC
21:11:11 <glx> oups triggered too early ;)
21:11:27 <TrueBrain> there is no such thing!
21:11:58 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #8741: Move GameLoop into a thread (and no longer run Paint in a thread) https://git.io/Jtd2I
21:12:17 <glx> oh nice it picked up cache from master
21:12:40 <glx> it didn't do that when testing on my fork
21:13:08 <LordAro> _2TallTyler: date_something.h, but probably not "type"
21:13:22 <glx> well of course there wasn't cache in master, but it didn't use cache from CI in release workflow
21:13:29 <TrueBrain> frosch123: theoretically, you are right, but it is highly unlikely it will context switch like that :P
21:13:40 <TrueBrain> like ... I don't know if it even can :)
21:13:55 <frosch123> but does it recover?
21:14:10 <TrueBrain> next tick, it should
21:14:21 <_2TallTyler> LordAro: Perhaps date_func.h?
21:14:56 <TrueBrain> "So this thread alternates between locking game_state_mutex and wait_mutex, never both." <- can you explain a bit more what you mean?
21:15:00 <glx> hmm I could add macos vcpkg x64 as restore_keys, to speed up first run of new image
21:15:07 <frosch123> TrueBrain: what about using request_game_state_mutex to call std::this_thread::yield() or some sleep in the gamethread?
21:15:19 <TrueBrain> frosch123: ::yield is a "suggestion"
21:15:24 <TrueBrain> and heavily depends on your scheduler
21:15:53 <TrueBrain> and sleep means you are thread-switched for at least 6ms, on my machine .. which is really meh
21:16:28 <frosch123> ok, but first: do i understand the need for all that stuff? is it possible that the gamethread keeps on unlocking/locking the mutex before the drawthread wakes up from its lock?
21:16:56 <TrueBrain> yes; a mutex optimization on almost all OSes don't release a thread between mutex unlock/lock if you do it almost instantly
21:17:03 <TrueBrain> even if other threads requested a lock on the mutex
21:17:18 <TrueBrain> their argument: that makes parallelization faster, because no thread switch
21:17:33 <TrueBrain> that is why I kinda wanted a semaphore, as I am used to solve this resource starvation that way :P
21:18:00 <TrueBrain> basically, a mutex is not meant for cooperative scheduling
21:18:38 *** sla_ro|master has quit IRC ()
21:19:27 <TrueBrain> okay, after re-reading your idea a few times, I get what you mean; that is not you btw, that is me :)
21:19:39 <TrueBrain> not you = not on you
21:20:26 <TrueBrain> problem with that solution is that you wouldn't be able to draw while the gamethread is idling in sleep_for, I think
21:21:52 <_2TallTyler> LordAro: Or could I store it in date.cpp and include it where necessary by adding an extern to date_func.h? I'd like to behave like _cur_year.
21:21:57 <frosch123> TrueBrain: i extended my comment
21:22:14 <_2TallTyler> I'm a bit in over my head with scope across multiple files, and have never used extern
21:22:18 <TrueBrain> owh, not over the loop, just take it, gotcha
21:24:12 <TrueBrain> let me try that real quick
21:27:31 <TrueBrain> seems to work frosch123
21:27:49 <TrueBrain> will need to think it over more clearly in the morning to see if it holds up, but the idea stands :)
21:28:32 <TrueBrain> the yield only would be counter-productive. It already yielded because of the lock, if needed :)
21:30:18 <TrueBrain> it works nice: enter Paint, enter GameLoop, exit Paint, exit GameLoop
21:30:21 <TrueBrain> is what my debug statements tell me
21:30:22 *** jgx_ has quit IRC (Remote host closed the connection)
21:30:27 <frosch123> how would a semaphore help? is it more fair than a mutex?
21:30:45 <TrueBrain> your mutex now acts as a semaphore I think
21:31:10 <frosch123> i consider a "mutex" the same as a "semaphore with max=1"
21:31:36 <TrueBrain> so this should be the same as what I wanted to do
21:31:42 <TrueBrain> somehow ... I did not come up with that :P
21:31:57 <TrueBrain> took me for-ever to understand the difference between lock_guard and unique_lock
21:32:18 <TrueBrain> luckily we have StackOverflow :D
21:33:19 <frosch123> yes, no idea why they added both
21:34:06 <LordAro> _2TallTyler: i can never remember either, i just copy what's there :p
21:34:15 <LordAro> put it wherever, it can always be moved later
21:34:43 <frosch123> iirc boost has 3 similar lock guards, so you can confuse 5 in total :)
21:35:24 <TrueBrain> anyway, tnx frosch123 , much appreciated you thinking along with this :D
21:35:39 <TrueBrain> simpler is better :D
21:35:42 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8741: Move GameLoop into a thread (and no longer run Paint in a thread) https://git.io/JtdUz
21:35:51 <frosch123> it was easier to read than the opengl magic :)
21:36:24 <glx> ok I didn't break nightly build :)
21:36:25 <TrueBrain> this week I want to try to split UpdateWindows in 2 passes, see if that results any performance benefit (split in the part where you said: this doesn't influence game state :P)
21:37:08 <frosch123> TrueBrain: haha, i would be quite impressed if you manage than in one week :p
21:37:26 <TrueBrain> well, maybe I start with TIC/TOCing it
21:37:31 <TrueBrain> I mainly want to know if there is any benefit there
21:38:25 <frosch123> i wondered whether every window should have its own draw buffer, which are then composed later
21:38:50 <frosch123> but if you stack 100 extra-viewports on top of each other, that's quite a lot of memory
21:39:15 <frosch123> you can open a lot of windows in ottd, way more than i do on my regular desktop
21:40:42 <TrueBrain> I know there is a limit, at least, in TTD you could only open N
21:40:46 <TrueBrain> and it would start closing others
21:41:44 <frosch123> ottd has two configurable limits: one for non-sticky windows, one for sticky windows
21:43:36 <frosch123> hmm, maybe the limit for sticky windows is infinite
21:44:08 <frosch123> window_soft_limit defaults to 20, and is limited to 255
21:44:18 <frosch123> but sticky windows may stay open forever
21:44:53 <frosch123> oh, you can also disable the soft-limit by setting it to zero
21:45:55 <frosch123> well, i guess the alternative would be to have one draw-buffer per thread in some draw-thread pool
21:47:21 <frosch123> hmm, otoh, ViewportDrawer could become a member of each window with viewport, instead of a global one
21:47:25 <TrueBrain> got the colours right \o/
21:47:34 <frosch123> then the gameloop can fill that, and the guiloop can draw it whenever
21:47:56 <TrueBrain> I have to read up on that code to understand what it is doing
21:48:02 <TrueBrain> so far I had issues following what is calling who when :D
21:49:10 <TrueBrain> guess next I have to implement padding etc, see if I can render them on the right location
21:49:45 <TrueBrain> oops, forgot to rebase my PR
21:49:46 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #8741: Move GameLoop into a thread (and no longer run Paint in a thread) https://git.io/JtdUz
21:50:12 <TrueBrain> I like how small it is, tbh .. removing the old stuff was more lines :D
21:52:24 <TrueBrain> _dp_: it uses flex, yes .. so in theory
21:52:29 <TrueBrain> frosch123: well, exactly
21:53:10 <TrueBrain> I realised there was no way we were going to be able to do an UI redesign if we cannot change things on-the-fly and check how it feels/looks
21:53:15 <TrueBrain> doing that in C++ would make it dreadfully slow
21:53:30 <TrueBrain> so I am now just reading the C++ blob, and rendering it :P
21:53:42 <TrueBrain> so you can "live" change it
21:53:43 <_dp_> yeah, having html would be totally awesome
21:53:56 <TrueBrain> and the Widget system is decent enough to do it, so far at least
21:54:08 <TrueBrain> display: flex helps a lot
21:54:32 <_dp_> and will make gs gui possible as well
21:54:34 *** Samu has quit IRC (Quit: Leaving)
21:55:23 <glx> _dp_: it's not inside openttd, it's just an external js thing
21:56:04 <TrueBrain> sorry, I thought that was rather clear :)
21:56:16 <TrueBrain> I am not going to make an HTML renderer in OpenTTD :P
21:56:19 *** _2TallTyler has quit IRC (Quit: Page closed)
21:56:25 <glx> yeah we're not rewriting windows agian
21:56:39 <frosch123> TrueBrain: when you added 60fps in one week, everyone thought you would port the gui to qt :p
21:56:59 <TrueBrain> why on earth would I want to do that to myself? :P
21:57:01 <Xaroth> I still get nightmares from QML >_>
21:57:16 <TrueBrain> really, the widget system in OpenTTD is powerful enough, if you ask me
21:57:32 <TrueBrain> it is just shit to: change a widget, compile, start, click 4 windows, check result
21:57:52 <frosch123> yes, the widgets are fine. but the text rendering is lacking
21:57:58 <glx> well you could auto open window when testing
21:58:16 <frosch123> so many games have hyperlinks in texts, to get help or tooltips, to go to locations, ...
21:58:19 <TrueBrain> glx: often difficult .. loading a certain game, clicking a certain vehicle, opening orders .. for example
21:58:20 <_dp_> it's not that hard to do simplified html renderer :p
21:58:27 * _dp_ totally not doing that himself
21:58:39 <TrueBrain> _dp_: what problem would that solve, really :)
21:58:56 <glx> and it won't stay simplified
21:59:13 <TrueBrain> well, we could make a markup language for windows, that GS can compile on-the-fly :P
21:59:16 <TrueBrain> but even that .. oef
21:59:35 <glx> people will always want more html stuff, then css, then ...
21:59:46 <_dp_> if you make a language why not html? :p
21:59:46 <TrueBrain> for the current window system, the amount of commands are limited
21:59:53 <TrueBrain> so making a lexer for it would be easy
21:59:59 <TrueBrain> because HTML is not easy
22:00:08 <TrueBrain> and HTML does not implement our window system
22:00:16 *** tokai|noir has joined #openttd
22:00:16 *** ChanServ sets mode: +v tokai|noir
22:00:18 <TrueBrain> so that would require two things: parse HTML and make a new renderer
22:00:25 <TrueBrain> better to only parse something, and use the current renderer ;)
22:00:28 <_dp_> current window system is kinda borked btw
22:00:34 <_dp_> paddings are all wrong afaict
22:00:42 <TrueBrain> I haven't found anything really wrong
22:00:50 <TrueBrain> sure, it is limited, but that is not a bad thing
22:01:02 <_dp_> paddings don't scale and their calculation is all wrong
22:01:09 <TrueBrain> naming is a bit annoying .. there isn't really a clear indication when you have to use EndContainer, for example
22:01:35 <TrueBrain> even if that is true, that doesn't mean we should throw it away to add something else that will have problems :)
22:01:39 <_dp_> code duplication for draw/size as well...
22:01:42 <TrueBrain> that is the "oeh, shiny" problem :)
22:02:43 <_dp_> I kinda hoped there would be some ui libraries for that already
22:02:50 <_dp_> but didn't find anything decent
22:03:59 <_dp_> andythenorth, yeah, mb some of it
22:04:10 <_dp_> I'm not sure what exacly you mean there in some points
22:04:53 <_dp_> but basicaly pretty much all paddings are hardcoded and don't scale
22:05:18 <_dp_> and margins I guess as well, not that there is any difference in openttd xD
22:05:19 <Xaroth> I'm quite sure I know the answer, but in case I've overlooked something obvious; is there anything that keeps track of tiles that have been changed?
22:05:46 <andythenorth> _dp_ most of that issue I think is "this has changed and I don't know why"
22:05:52 <andythenorth> I closed it as 'meh' in the end :)
22:06:46 <frosch123> Xaroth: changed when? during gameloop? during command?
22:06:57 <andythenorth> the UI is not a ditch I want to die in :P
22:07:18 *** tokai has quit IRC (Ping timeout: 480 seconds)
22:07:45 <_dp_> andythenorth, I mostly just dealt with some ui code and not surprised there are ton of small ui issues with how it is
22:08:00 <TrueBrain> funny, our "padding" is HTML "margin" :D
22:08:03 <DorpsGek> [OpenTTD/OpenTTD] michicc updated pull request #8730: Codechange: [OpenGL] Load all OpenGL functions dynamically. https://git.io/JtQDe
22:08:07 <frosch123> the clear command is tracked during the clear-command itself, so it does not clear tiles twices (important when clearing multi-tile things)
22:08:38 <frosch123> coop had a patch to log when players did something on a tile, and then draw a map with color per player
22:08:41 <Xaroth> frosch123: I'm working on a thing for the admin port where it sends map data (tile type/owner) over the admin network
22:08:52 <frosch123> othweise, the tileloop changes every tile in 256 ticks
22:09:06 <TrueBrain> height is wrong .. hmm
22:09:28 <Xaroth> So I'm trying to figure out something not-that-intrusive that can notify when certain parts of the map have changed
22:10:47 <frosch123> MarkTileDirty() is the closest you can get
22:11:31 <frosch123> filter out clear land, sea and trees, and you may have a reasonable amount of data
22:12:19 <TrueBrain> hmm .. is there a font that is close to OpenGFX' font?
22:12:42 <frosch123> opengfx font was rendered from a real font iirc
22:12:43 <glx> tahoma is close to TTD font IIRC
22:13:07 <glx> and opengfx font is broken ;)
22:13:16 <TrueBrain> if I believe this channel, everything is broken :)
22:13:24 <frosch123> opengfx mono font is "liberation mono"
22:13:29 <_dp_> it's not that hard to figure map area from the network command
22:14:29 <TrueBrain> 12px Tamoha comes close enough for buttons it seems
22:15:08 <TrueBrain> owh, no, it is using a random font but not telling me
22:15:25 <Xaroth> _dp_: Thanks, will check where that leads me
22:20:14 <DorpsGek> [OpenTTD/OpenTTD] michicc updated pull request #8730: Codechange: [OpenGL] Load all OpenGL functions dynamically. https://git.io/JtQDe
22:21:14 <TrueBrain> michi_cc knows templates :D
22:22:36 *** Progman has quit IRC (Remote host closed the connection)
22:22:39 <frosch123> don't incentivate a template competition :p
22:24:16 <glx> that's readable template at least
22:24:41 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:25:05 <frosch123> it's also readable preprocessor code :)
22:25:18 <frosch123> preprocessor stuff can be worse than templates
22:25:50 *** ChanServ sets mode: +v tokai
22:29:36 <andythenorth> it's not a proper game until you've templated the preprocessor stuff, with python
22:29:53 * andythenorth tries to suppress that memory
22:31:22 <frosch123> andythenorth: i encountered people 20 years older than you, who ran piped m4 output into cpp, and used magic from both
22:32:23 <andythenorth> frosch123 did they learn no to? :)
22:32:31 <Eddi|zuHause> that's rail construction?
22:32:42 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
22:32:49 *** tyteen4a03 has quit IRC (Quit: Bleh?)
22:32:56 <andythenorth> I see dead people
22:32:59 <TrueBrain> less buttons than rail
22:33:02 <andythenorth> oh wait, we're in a different movie
22:33:04 <DorpsGek> [OpenTTD/OpenTTD] frosch123 approved pull request #8730: Codechange: [OpenGL] Load all OpenGL functions dynamically. https://git.io/JtdVz
22:33:09 <andythenorth> which movie is this?
22:33:11 <Eddi|zuHause> yeah, i counted the buttons, but was unsure
22:33:23 <Eddi|zuHause> so i did a 50/50 flip
22:33:25 <TrueBrain> michi_cc: do you want me to tackle to not load opengl.so for SDL? Or will you give that a spin?
22:34:15 <michi_cc> TrueBrain: I would have to setup SDL first, so you may gladly have a go at it :)
22:34:23 <TrueBrain> will do so this week :)
22:34:36 <frosch123> just random spam :)
22:35:12 <TrueBrain> michi_cc: gave making 40bpp-anim the default some more thought btw?
22:36:14 <michi_cc> Yeah, the performance stuff is just the driver telling us that it guess the usage wrong on the first go. Got no clue about the "Texture state usage warning", but I see all textures, so... :)
22:36:51 <michi_cc> TrueBrain: It's somewhat slower. Other than that, it's potato potato for me.
22:37:10 <TrueBrain> I think the transparency alone is worth it for many of our users
22:37:25 <TrueBrain> it is still a lot faster than non-OpenGL 32bpp :)
22:37:55 <TrueBrain> hmm, in fact it is even faster than the 8bpp :P
22:38:21 <TrueBrain> still can't wrap my head around that OpenGL can render a frame in 0.02ms
22:38:57 <TrueBrain> anyway, time to find my bed
22:41:41 <michi_cc> That 0.02ms is literally just driver submission call. Everything else happens either in the driver (potentially on other threads) and the GPU.
22:42:06 <glx> hmm if it's dynamically loaded on all platform, I think we should not link to opengl and use only includes at build time
22:42:50 <michi_cc> Win32 still needs the wgl* functions. But as opengl32.dll is a thing since windows 95, I woudn't class it as a problem.
22:51:05 <michi_cc> Okay, OSX also needs to link to its lib for the CGL (equivalent to wgl) functions. It's only SDL that doesn't need us to link the opengl libs.
22:52:53 *** andythenorth has quit IRC (Quit: andythenorth)
22:56:29 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
23:07:14 <glx> it should be possible to implement something similar to add_file CONDITION in link_package
23:21:53 *** gelignite has quit IRC (Quit: Stay safe!)
23:30:18 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:34:52 <DorpsGek> [OpenTTD/OpenTTD] michicc merged pull request #8730: Codechange: [OpenGL] Load all OpenGL functions dynamically. https://git.io/JtQDe
23:53:35 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8738: Fix #8123: trams on half-tiles couldn't find depots https://git.io/JtdKY
continue to next day ⏵
