Back to Home / #openttd / 2021 / 02 / Prev Day | Next Day
#openttd IRC Logs for 2021-02-24

---Logopened Wed Feb 24 00:00:52 2021
00:35<@DorpsGek>[OpenTTD/OpenTTD] perezdidac updated pull request #8706: Feature: rail station class name filtering https://git.io/Jt9ev
00:48-!-WormnestAndroid [~WormnestA@35.136.189.95] has quit [Ping timeout: 480 seconds]
00:48-!-WormnestAndroid [~WormnestA@172.58.168.130] has joined #openttd
00:48-!-WormnestAndroid is "WormnestAndroid" on #openttd
01:05-!-rptr [~rptr@2a00:801:44b:5fb3:b852:cfd3:ade7:f24f] has quit []
01:05-!-rptr [~rptr@2a00:801:44b:5fb3:b852:cfd3:ade7:f24f] has joined #openttd
01:05-!-rptr is "morbidgirl" on #rust #realraum #publiclab #packaging #oftc #linux #dfri_se #debian-next #debian #C #openttd
01:21-!-WormnestAndroid [~WormnestA@172.58.168.130] has quit [Ping timeout: 480 seconds]
01:21-!-WormnestAndroid [~WormnestA@35.136.189.95] has joined #openttd
01:21-!-WormnestAndroid is "WormnestAndroid" on #openttd
02:08-!-tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd
02:08-!-tokai|noir is "Christian Rosentreter" on #openttd
02:08-!-mode/#openttd [+v tokai|noir] by ChanServ
02:12-!-sla_ro|master [~sla.ro@89.136.179.137] has joined #openttd
02:12-!-sla_ro|master is "slamaster" on @#sla #openttd
02:15-!-didac [~oftc-webi@c-67-168-111-57.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
02:15-!-tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
02:19-!-andythenorth [~andytheno@cpc87165-aztw31-2-0-cust40.18-1.cable.virginm.net] has joined #openttd
02:19-!-andythenorth is "andythenorth" on #openttd
03:00-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has joined #openttd
03:00-!-Wolf01 is "Wolf01" on #openttd
03:00<@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
03:01-!-HerzogDeXtEr [~farci@146.52.11.16] has joined #openttd
03:01-!-HerzogDeXtEr is "purple" on #openttd
03:06<@DorpsGek>[OpenTTD/OpenTTD] LordAro approved pull request #8732: Change: Improve graph period markings https://git.io/Jt5Pc
03:06-!-rptr [~rptr@2a00:801:44b:5fb3:b852:cfd3:ade7:f24f] has quit []
03:18<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8732: Change: Improve graph period markings https://git.io/Jt5Xe
03:18<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain closed issue #8632: Graph window - Markings of the periods on the graph are unreadable https://git.io/JtBxX
03:18<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain merged pull request #8732: Change: Improve graph period markings https://git.io/JtQjQ
03:18<TrueBrain>90 issues
03:18<TrueBrain>owh yeah
03:20<LordAro>how long before PRs overtake issues? :p
03:20<LordAro>or will we get flooded with issues from steam first? :p
03:21<TrueBrain>oof .. lets hope not :P
03:23<andythenorth>if we do, we can practice closing them
03:23<andythenorth>closing issues is just a good habit, like daily exercise
03:26<Wolf01>:)
03:26<Wolf01>Meh, why am I so devastated today?
03:30<LordAro>:(
03:30<@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
03:32<TrueBrain>TIL, caching on GitHub Actions is more tricky than expected :D
03:35<andythenorth>Wolf01 because virus?
03:50<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
03:51<TrueBrain>sounds like a good idea, not?
04:07<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 ..
04:07<TrueBrain>sadddd
04:12-!-rptr [~rptr@2a00:801:44b:5fb3:b852:cfd3:ade7:f24f] has joined #openttd
04:12-!-rptr is "morbidgirl" on #rust #realraum #publiclab #packaging #oftc #linux #dfri_se #debian-next #debian #C #openttd
04:26<TrueBrain>funny how little impact threaded drawing now has :P
04:26<TrueBrain>as in, I have a hard time finding a game where it differs
04:27<TrueBrain>which kinda makes sense I guess, as it takes, what 0.15ms per frame
04:28<LordAro>increase your refresh rate to 1440 :p
04:28<TrueBrain>doesn't change anything about how much time a frame costs :)
04:28<LordAro>true
04:28<LordAro>try progame5 :)
04:28<TrueBrain>remember that to draw something new, we need to run UpdateWindows with the lock on the gamestate
04:29<TrueBrain>which is the function that takes most time
04:29<TrueBrain>but cannot be done at the same time as GameLoop
04:29<TrueBrain>progame5?
04:29<Wolf01><andythenorth> Wolf01 because virus? <- we don't know, I'm waiting for more tests
04:30<TrueBrain>I now have a game that looks something like this: GameLoop - 50ms, UpdateWindows - 10ms - Paint - 0.05ms
04:30<TrueBrain>GameLoop and UpdateWindows cannot run at the same time
04:30<TrueBrain>so best I can win is 0.05ms
04:30<TrueBrain>at the cost of a thread-switch :P
04:30<TrueBrain>we need to move stuff out of UpdateWindows, basically, the parts that don't need the lock on the game-state anymore
04:32<TrueBrain>ah, no, found a game where Paint takes 5ms!
04:32<TrueBrain>still almost no measurable difference in framerate, ofc :)
04:33<TrueBrain>I had to switch to no-OpenGL to notice it :P
04:35<TrueBrain>I can give up draw fps for simulation speed .. but where is the balance there :)
04:35<TrueBrain>this game was running on 17 fps .. it is now at 6 fps, but the simulation went from 0.5x to 0.55x
04:37<Timberwolf>Hm... on the one hand it's a 10% improvement, on the other that takes a "just about playable" framerate to slideshow.
04:37<Timberwolf>At least, for modern eyes.
04:37<LordAro>that does not sound like an improvement, really
04:38<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"
04:38<TrueBrain>LordAro: that depends on your goal, I guess
04:38<LordAro>https://wiki.openttdcoop.org/ProZone:Archive_-_Games_1_-_10
04:38<Timberwolf>Geoff Crammond's Formula One Grand Prix was 8fps on a low-end Amiga!
04:39<Timberwolf>I never remember even noticing "frame rate" as a thing, although it did feel smoother on my 286 which could handle 11fps.
04:39<TrueBrain>but so yeah, I can set a minimum draw fps, which only cannot be reached if the simulation dips below it
04:40<TrueBrain>so simulations get priority basically, up to the point fps would drop below, say, 25fps? after that, they both go down
04:42<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.
04:42<Wolf01>Timberwolf: you only recognize things when you know their name, I've read a study on the "discovery" of colours
04:42<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.
04:42<TrueBrain>this is a lovely balancing act .. what wins from what :)
04:47<TrueBrain>well, I can run ProGame5 at 1x simulation with my changes
04:47<TrueBrain>just fps drops to ~20fps
04:47<TrueBrain>means in multiplayer I would keep up
04:50<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 :)
04:51<TrueBrain>it is just a problem when GameLoop cannot do its job in 30ms .. something has to give
05:01<@peter1138>Trying to make a slow game run faster without reducing interactiveness is fun.
05:02<@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...
05:04<andythenorth>limit trains!
05:04<andythenorth>remove newgrf!
05:04*andythenorth unhelpful sorry
05:07<TrueBrain>what is lovely, if you manage to deadlock the game-thread
05:07<TrueBrain>at least it is 60fps!
05:22<TrueBrain>awh, semaphores are c++20
05:22<TrueBrain>that is annoying
05:22<TrueBrain>can we change to c++20? :D
05:24<_dp_>can't you just grab the implementation?
05:25<LordAro>TrueBrain: i think you have to do a certain amount of compiler writing too
05:26<TrueBrain>small effort for such a lovely construct!
05:27<LordAro>apparently both libstdc++ & libc++ have implementations of it
05:27<TrueBrain>I kinda need fibers, or cooperative multithreading
05:28<LordAro>boost fibers!
05:28<TrueBrain>yeah, no
05:28<LordAro>good response :p
05:28<TrueBrain>too bad there isn't an easy way to force a context switch
05:29<TrueBrain>besides sleeping
05:29<TrueBrain>which sucks for different reasons
05:29<TrueBrain>yield is just a suggestion
05:34-!-jjavaholic [~jjavaholi@2a00:23c6:9508:e601:8d11:5425:637b:40f2] has quit [Quit: Leaving]
05:41-!-gelignite [~gelignite@55d44adf.access.ecotel.net] has joined #openttd
05:41-!-gelignite is "realname" on #llvm #openttd
05:53-!-rptr [~rptr@2a00:801:44b:5fb3:b852:cfd3:ade7:f24f] has quit [Ping timeout: 480 seconds]
06:03-!-Samu [~Ricardo@po1-84-91-251-215.netvisao.pt] has joined #openttd
06:03-!-Samu is "realname" on #openttd
06:07-!-supermop_Home [~user@pool-72-80-18-36.nycmny.fios.verizon.net] has quit [Ping timeout: 480 seconds]
06:28<TrueBrain>okay, I got most of this working now
06:29<TrueBrain>I just have to split _realtime_tick to have a game-thread variant and a draw-thread variant
06:29<TrueBrain>as otherwise they might behave weird :D
06:29<TrueBrain>(read: that variable is not thread-safe atm)
06:29<TrueBrain>I could also make it a std::atomic, I guess
06:29<TrueBrain>but splitting it might be the proper thing to do
06:30<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on pull request #8738: Fix #8123: trams on half-tiles couldn't find depots https://git.io/Jt5dA
07:01-!-tokai [~tokai@00012860.user.oftc.net] has joined #openttd
07:01-!-tokai is "Christian Rosentreter" on #openttd
07:01-!-mode/#openttd [+v tokai] by ChanServ
07:02<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain updated pull request #8738: Fix #8123: trams on half-tiles couldn't find depots https://git.io/Jt5Yr
07:02-!-andythenorth [~andytheno@cpc87165-aztw31-2-0-cust40.18-1.cable.virginm.net] has quit [Quit: andythenorth]
07:03<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8738: Fix #8123: trams on half-tiles couldn't find depots https://git.io/Jt5Fj
07:04<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain updated pull request #8738: Fix #8123: trams on half-tiles couldn't find depots https://git.io/Jt5Yr
07:07-!-tokai|noir [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
07:10<FLHerne>Timberwolf: Is this offset expected? Some angles look much more aligned than others https://www.flherne.uk/files/timberwolf_carriage_offset.png
07:15<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.
07:15<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.
07:18<FLHerne>Ok
07:24<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.
07:37-!-tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd
07:37-!-tokai|noir is "Christian Rosentreter" on #openttd
07:37-!-mode/#openttd [+v tokai|noir] by ChanServ
07:44-!-tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
07:45-!-tokai [~tokai@00012860.user.oftc.net] has joined #openttd
07:45-!-tokai is "Christian Rosentreter" on #openttd
07:45-!-mode/#openttd [+v tokai] by ChanServ
07:45<TrueBrain>"unlock of unowned mutex"
07:45<TrueBrain>that is a little bit sad :P
07:46<Eddi|zuHause>multithreading is hard.
07:46<TrueBrain>too bad it is not telling me clearly who is causing it :D
07:47<TrueBrain>as it works on Linux of course, and Windows is failing :P
07:47<TrueBrain>you know, a regular day in the office
07:49<TrueBrain>somehow I doubt it is my code, as I use lock_guard :)
07:49<TrueBrain>so what did I screw up that others parts are now confused :P
07:51-!-tokai|noir [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
07:54<TrueBrain>the minor differences in implementations, you got to love it :)
07:54<@peter1138>Euf, might put the heating up.
07:55<@peter1138>Thermostat says it's 21, my feet say it's freezing...
07:57<Eddi|zuHause>that's because cold air floats to the bottom of the room
07:58<@peter1138>Is that like a ship wrecking floating on the bottom of an ocean?
07:58<@peter1138>-ing
07:58<Eddi|zuHause>no, that's because of salt concentration
08:03<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
08:03<TrueBrain>no clue why not .. works fine in non-OpenGL under the same circumstances :)
08:04<TrueBrain>owh, and while Fast-Forwarding, I forgot that detail
08:05<TrueBrain>seems if you don't yield the main thread, OpenGL doesn't update, or something ..
08:09<TrueBrain>also happens on Linux, so yeah, OpenGL related
08:12-!-supermop_Home [~user@pool-72-80-18-36.nycmny.fios.verizon.net] has joined #openttd
08:12-!-supermop_Home is "Guest" on #openttd
08:12<supermop_Home>hi
08:12<FLHerne>Hi
08:12<FLHerne>supermop_Home: Is all this NML generated with some sort of script?
08:13<FLHerne>Or are you just copy-pasting a lot? :p
08:13<supermop_Home>type and copy paste
08:13<FLHerne>Hm, ok
08:17<supermop_Home>yes, it is pretty embarassing
08:55<@peter1138>I remember OpenGL is picky about threads. You should only ever call it from one thread.
08:55<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain opened pull request #8740: More code cleanups in video drivers https://git.io/Jtdvc
08:55<TrueBrain>we are only calling it from one thread
08:55<@peter1138>K
08:59<TrueBrain>otherwise it indeed says boom real quick
09:00-!-WormnestAndroid [~WormnestA@35.136.189.95] has quit [Remote host closed the connection]
09:00-!-WormnestAndroid [~WormnestA@35.136.189.95] has joined #openttd
09:00-!-WormnestAndroid is "WormnestAndroid" on #openttd
09:03<TrueBrain>that lovely moment you pick up your PR, put it aside, start from scratch to make decent commits out of it all :D
09:03<@peter1138>NewStations
09:03<@peter1138>So many rewrites...
09:04<TrueBrain>I am just copy/pasting the branch I put aside
09:04<TrueBrain>just .. in more commits than one :D
09:04<@peter1138>Yup.
09:04<@peter1138>Sometimes you need the complete picture before you know what the steps are.
09:05<@peter1138>Always a problem with development "How long will it take?" "I'll let you know once it's done."
09:07<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain updated pull request #8740: More code cleanups in video drivers https://git.io/Jtdvc
09:07<Eddi|zuHause>the problem is if there's a boss who says "i need this done by <date>"
09:08<Eddi|zuHause>and then asks why it's not done yet
09:08<Eddi|zuHause>but there are 5 dozen reasons, each contributing just a little bit of delay
09:10-!-glx [glx@000128ec.user.oftc.net] has joined #openttd
09:10-!-glx is "Loïc GUILLOUX" on #openttd
09:10-!-mode/#openttd [+v glx] by ChanServ
09:13<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain updated pull request #8740: More code cleanups in video drivers https://git.io/Jtdvc
09:13<TrueBrain>seems typing is hard today .. ugh :P
09:25-!-nielsm [~nielsm@188-181-82-243-cable.dk.customer.tdc.net] has joined #openttd
09:25-!-nielsm is "Niels Martin Hansen" on #openttd
09:33-!-gelignite [~gelignite@55d44adf.access.ecotel.net] has quit [Quit: Stay safe!]
09:33<Eddi|zuHause>now that we finally moved to the next millennium with OpenGL, what about Vulkan? :p
09:38<@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
09:38<TrueBrain>still draft ^^, but it is getting there :)
09:41<TrueBrain>first step to keeping the UI responsive, even during map-gen
09:41<TrueBrain>and I mean 60fps responsive, if we would like
09:43<TrueBrain>and "offers" keep pouring in at info@
09:44<TrueBrain>and most of them have this line: if you don't want email from me again, reply ... to my email
09:44<TrueBrain>... like .. fuck no
09:47<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
09:48<FLHerne>So having an example of a giant hand-written file, rather than andy and Eddi's giant generated files, is quite useful
09:48<@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
09:48<@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
09:49<supermop_Home>FLHerne i try to come up with systems of nomenclature that makes sense to me, but i really should have better comments
09:49<TrueBrain>sounds a lot safer indeed glx :)
09:55<@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
09:55<@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
09:59<+glx>key: --vcpkg-x86 <-- hmm something is wrong
10:02<supermop_Home>ugh still can't think of a better name than 'mop generic road vehicles'
10: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
10:24<@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
10:30<@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
10:42<@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
10:44<@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
10:44<+glx>sorry for the spam :)
10:46-!-Flygon [~Flygon@2001:44b8:411e:4e00:80f5:feaa:2e16:991f] has quit [Read error: Connection reset by peer]
10:53<Xaroth>hm, why-oh-why is it complaining about fontcache when building
11:03<@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
11:03<+glx>should be the last one :)
11:33-!-Progman [~progman@p57a2b25f.dip0.t-ipconnect.de] has joined #openttd
11:33-!-Progman is "Peter Henschel" on #openttdcoop.dev #openttd
11:39<@DorpsGek>[OpenTTD/team] kustridaren opened issue #143: [sv_SE] Translator access request https://git.io/JtdG4
11:49<TrueBrain>yippie, found my OpenGL issue :D That was silly ...
11:49<+glx>hehe I needed so many push for a simple change
11:51<@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
11:51-!-y2kboy23 [~y2kboy23@ip72-201-94-215.ph.ph.cox.net] has quit [Quit: ZNC - https://znc.in]
11:54<@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
11:54<@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
11:54<TrueBrain>well, in my case I forgot to lock the video buffer when I was going to write to it :P
11:54-!-y2kboy23 [~y2kboy23@ip72-201-94-215.ph.ph.cox.net] has joined #openttd
11:54-!-y2kboy23 is "Got ZNC?" on #openttd
11:55<+glx>didn't recheck release workflow, it should still work (if copy paste from CI didn't fail)
11:55<TrueBrain>we will know in a few hours if you should have done that :P
11:57<+glx>one important thing, if first run of new image fails, caching is dead for all following runs
11:58<+glx>or only if cache save fails, anyway it's a reservation/lock issue from cache action
11:59<TrueBrain>I did read caches invalidate after N days, but not sure if that is true when you use them :)
12:02<TrueBrain>I like how unclear it is in OpenTTD what functions exactly write in the video buffer :)
12:02<TrueBrain>trying to follow N functions throughout the code
12:03<Eddi|zuHause>refactoring! :)
12:04<@DorpsGek>[OpenTTD/website] LordAro opened pull request #191: Change: Make it clearer that macOS 11 is supported https://git.io/Jtdn8
12:05-!-Wormnest [~Wormnest@35.136.189.95] has joined #openttd
12:05-!-Wormnest is "Wormnest" on #openttd
12:05<@DorpsGek>[OpenTTD/website] TrueBrain commented on pull request #191: Change: Make it clearer that macOS 11 is supported https://git.io/JtdnE
12:10<@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
12:12<+glx>cache worked (on your first run it had to rebuild because master was still running)
12:12<TrueBrain>:D
12:12<+glx>so yout PR has it's own cache
12:13<+glx>*your
12:13<TrueBrain>bah, screenshots now crash the game, grrrr
12:13<TrueBrain>its hard to get all these buffers right, if you start inverting logic
12:18<TrueBrain>michi_cc: do you happen to know why https://github.com/OpenTTD/OpenTTD/blob/master/src/video/win32_v.cpp#L1200 does check for a nullptr of screen_dst, but https://github.com/OpenTTD/OpenTTD/blob/master/src/video/win32_v.cpp#L1522 does not?
12:44<TrueBrain>weird, making a screenshot fails somewhere in libpng .. that is not what I expected :D
12:45<TrueBrain>lets see if that problem exists in master ..
12:47<TrueBrain>okay, it does .. I was hunting ghosts :P
12:48<TrueBrain>something about my local setup
12:50<@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
12:51-!-gelignite [~gelignite@55d44adf.access.ecotel.net] has joined #openttd
12:51-!-gelignite is "realname" on #llvm #openttd
12:53-!-didac [~oftc-webi@c-67-168-111-57.hsd1.wa.comcast.net] has joined #openttd
12:53-!-didac is "OFTC WebIRC Client" on #openttd
12:53<didac>hey there, anyone free to review 8706 and 8733 thanks!
12:55-!-nielsm [~nielsm@188-181-82-243-cable.dk.customer.tdc.net] has quit [Ping timeout: 480 seconds]
12:55<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on pull request #8730: Codechange: [OpenGL] Load all OpenGL functions dynamically. https://git.io/JtdlD
12:58-!-Wuzzy [~Wuzzy@0001b11e.user.oftc.net] has joined #openttd
12:58-!-Wuzzy is "Wuzzy" on #openttd
12:58<TrueBrain>so tempted to make some Javascript that can render GUIs from C++ code .. and possibly allow modifying it and generate C++ again ..
12:58<TrueBrain>so tired of starting the game every time to find out it still doesn't look right :D
12:59<TrueBrain>LordAro: your suggestion for manylinux images is still amazingly good .. working with those images is so much easier :D
13:02<TrueBrain>hmm .. even with that OpenGL load dynamic patch, the Linux binary is linked against OpenGL
13:02<TrueBrain>which is a world of hurt, as that drags in X11 too :P
13:03<TrueBrain>how to find what caused that, hmm
13:03<LordAro>:)
13:09<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8730: Codechange: [OpenGL] Load all OpenGL functions dynamically. https://git.io/Jtd8h
13:30-!-andythenorth [~andytheno@cpc87165-aztw31-2-0-cust40.18-1.cable.virginm.net] has joined #openttd
13:30-!-andythenorth is "andythenorth" on #openttd
13:31<andythenorth>yo
13:32<TrueBrain>yo yo yooo
13:34-!-frosch123 [~frosch@00013ce7.user.oftc.net] has joined #openttd
13:34-!-frosch123 is "frosch" on #openttd
13:52-!-Samu [~Ricardo@po1-84-91-251-215.netvisao.pt] has quit [Read error: Connection reset by peer]
13:54-!-iSoSyS [~iSoSyS@ff2-84-90-95-208.netvisao.pt] has joined #openttd
13:54-!-iSoSyS is "realname" on #/r/openttd #openttd
14:10-!-qwebirc1034 [~oftc-webi@2a00:f41:86e:9e78:9e75:4735:569e:4c34] has joined #openttd
14:10-!-qwebirc1034 is "OFTC WebIRC Client" on #openttd
14:17-!-qwebirc1034 [~oftc-webi@2a00:f41:86e:9e78:9e75:4735:569e:4c34] has quit [Remote host closed the connection]
14:24-!-Smedles [~quassel@61-245-148-167.3df594.adl.nbn.aussiebb.net] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
14:26<+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
14:27<TrueBrain>okay, good :)
14:27<TrueBrain>I solved it in my PR correctly in that case :P
14:27<TrueBrain>(I made everything like L1552)
14:27<TrueBrain>I now guarantee the video buffer is locked during Paint, basically :)
14:27<TrueBrain>for master it is not a problem, as the buffer is always locked during Paint
14:28<TrueBrain>was mostly wondering if I missed something obvious; clearly I did not :D Tnx!
14:28<@DorpsGek>[OpenTTD/OpenTTD] michicc commented on pull request #8730: Codechange: [OpenGL] Load all OpenGL functions dynamically. https://git.io/Jtduf
14:29<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
14:34-!-Samu [~Ricardo@po1-84-91-251-215.netvisao.pt] has joined #openttd
14:34-!-Samu is "realname" on #openttd
14:37-!-iSoSyS [~iSoSyS@ff2-84-90-95-208.netvisao.pt] has quit []
14:40-!-Smedles [~quassel@2403-5800-5100-f00-b7eb-2251-2cf1-3dbb.ip6.aussiebb.net] has joined #openttd
14:40-!-Smedles is "Paul Smedley" on #openttd
14:47-!-_2TallTyler [~oftc-webi@151.203.115.35] has joined #openttd
14:47-!-_2TallTyler is "OFTC WebIRC Client" on #openttd
14:47<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)
14:50<+michi_cc>TrueBrain: Is it guaranteed on Linux that you don't some special include path for the GL headers?
14:50<TrueBrain>what do you mean, sorry?
14:51<+michi_cc>Isn't link_package also added include paths if necessary?
14:51<+michi_cc>We still need the header files, even if we don't link to the library.
14:51<TrueBrain>hmm .. it did not return any warning :D
14:51<TrueBrain>what header is used .. lets see
14:51<+michi_cc>Well, most Linux variants are probably going to have it in the default include path.
14:52<+michi_cc>I'm just wondering if there's any special variants out there.
14:52<TrueBrain>ah, yes, it is in /usr/include
14:52<TrueBrain>no clue
14:52<TrueBrain>better link with only include-path in that case :)
14:55<TrueBrain>yeah, the file comes from libgl-dev, so adding the include-path is indeed the minimal thing to do
14:55<TrueBrain>I was hoping SDL would supply it :P
14:55<TrueBrain>but no
15:00-!-tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd
15:00-!-tokai|noir is "Christian Rosentreter" on #openttd
15:00-!-mode/#openttd [+v tokai|noir] by ChanServ
15:07-!-tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
15:22<+glx>it should be possible to use OPENGL_INCLUDE_DIR only
15:29<TrueBrain>not sure our link_package allows that currently
15:29<TrueBrain>which might make it a bit tricky
15:29<+glx>it doesn't
15:34<@DorpsGek>[OpenTTD/OpenTTD] michicc opened pull request #8742: Fix #8734: [OpenGL] Apply palette remap to cursor sprites. https://git.io/JtdgJ
15:40<@DorpsGek>[OpenTTD/OpenTTD] michicc approved pull request #8740: More code cleanups in video drivers https://git.io/Jtdg3
15:44-!-jottyfan [~Thunderbi@x4db709e8.dyn.telefonica.de] has joined #openttd
15:44-!-jottyfan is "jottyfan" on #openttd
15:48-!-andythenorth_ [~andytheno@cpc87165-aztw31-2-0-cust40.18-1.cable.virginm.net] has joined #openttd
15:48-!-andythenorth_ is "andythenorth" on #openttd
15:50-!-andythenorth_ [~andytheno@cpc87165-aztw31-2-0-cust40.18-1.cable.virginm.net] has quit []
15:52-!-andythenorth [~andytheno@cpc87165-aztw31-2-0-cust40.18-1.cable.virginm.net] has quit [Ping timeout: 480 seconds]
15:52-!-jottyfan [~Thunderbi@x4db709e8.dyn.telefonica.de] has quit [Quit: jottyfan]
15:53-!-andythenorth [~andytheno@cpc87165-aztw31-2-0-cust40.18-1.cable.virginm.net] has joined #openttd
15:53-!-andythenorth is "andythenorth" on #openttd
15:57<TrueBrain>https://pasteboard.co/JPTbfgc.png <- seems I can parse the basics
15:58<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain approved pull request #8742: Fix #8734: [OpenGL] Apply palette remap to cursor sprites. https://git.io/JtdgD
15:58<TrueBrain>you have been busy michi_cc :o
15:58-!-tokai [~tokai@00012860.user.oftc.net] has joined #openttd
15:58-!-tokai is "Christian Rosentreter" on #openttd
15:58-!-mode/#openttd [+v tokai] by ChanServ
15:58<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain merged pull request #8740: More code cleanups in video drivers https://git.io/Jtdvc
16:02<andythenorth>lol I looked up how common thermal throttling is on my mac
16:02<andythenorth>one of the top results explains that it's probably due to flash banner ads in news websites
16:02<+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. "
16:02*andythenorth will ignore that particular piece of FML internet
16:02<andythenorth>also I won't be adding my own custom CPU heatsink
16:03<andythenorth>TL;DR the CPU and GPU are 95W of thermal parts in a 90W enclosure
16:03<andythenorth>guess how well that goes?
16:04<TrueBrain>glx: really? Normally it emails about that ...
16:04<+glx>same for EINTS
16:05<+glx>well it runs them, but they do nothing
16:05<TrueBrain>well, they are enabled now
16:05-!-tokai|noir [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
16:05<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
16:05<TrueBrain>annoying it doesn't
16:05<TrueBrain>guess we need to make a ping/pong
16:07<TrueBrain>lets see if the manual trigger still works
16:07<TrueBrain>seems so
16:07<_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?
16:08<+glx>would have been better to trigger eints first
16:08<+glx>well translations can wait a day
16:09<TrueBrain>exactly
16:10<TrueBrain>I did consider it for a sec, but I was too lazy to wait for 10+ minutes
16:10<@DorpsGek>[OpenTTD/OpenTTD] michicc merged pull request #8742: Fix #8734: [OpenGL] Apply palette remap to cursor sprites. https://git.io/JtdgJ
16:10<@DorpsGek>[OpenTTD/OpenTTD] michicc closed issue #8734: Vehicles not rendered in 2CC when dragged inside a depot https://git.io/Jt5JC
16:11<+glx>oups triggered too early ;)
16:11<TrueBrain>there is no such thing!
16:11<TrueBrain>:D
16:11<@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
16:12<+glx>oh nice it picked up cache from master
16:12<+glx>it didn't do that when testing on my fork
16:13<LordAro>_2TallTyler: date_something.h, but probably not "type"
16:13<+glx>well of course there wasn't cache in master, but it didn't use cache from CI in release workflow
16:13<TrueBrain>frosch123: theoretically, you are right, but it is highly unlikely it will context switch like that :P
16:13<TrueBrain>like ... I don't know if it even can :)
16:13<frosch123>but does it recover?
16:14<TrueBrain>next tick, it should
16:14<_2TallTyler>LordAro: Perhaps date_func.h?
16:14<LordAro>possibly, yeah
16:14<TrueBrain>"So this thread alternates between locking game_state_mutex and wait_mutex, never both." <- can you explain a bit more what you mean?
16:15<+glx>hmm I could add macos vcpkg x64 as restore_keys, to speed up first run of new image
16:15<frosch123>TrueBrain: what about using request_game_state_mutex to call std::this_thread::yield() or some sleep in the gamethread?
16:15<TrueBrain>frosch123: ::yield is a "suggestion"
16:15<TrueBrain>and heavily depends on your scheduler
16:15<TrueBrain>read: useless
16:15<TrueBrain>and sleep means you are thread-switched for at least 6ms, on my machine .. which is really meh
16:16<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?
16:16<TrueBrain>yes; a mutex optimization on almost all OSes don't release a thread between mutex unlock/lock if you do it almost instantly
16:17<TrueBrain>even if other threads requested a lock on the mutex
16:17<TrueBrain>their argument: that makes parallelization faster, because no thread switch
16:17<TrueBrain>that is why I kinda wanted a semaphore, as I am used to solve this resource starvation that way :P
16:18<TrueBrain>basically, a mutex is not meant for cooperative scheduling
16:18-!-sla_ro|master [~sla.ro@89.136.179.137] has quit []
16:19<TrueBrain>okay, after re-reading your idea a few times, I get what you mean; that is not you btw, that is me :)
16:19<TrueBrain>not you = not on you
16:20<TrueBrain>problem with that solution is that you wouldn't be able to draw while the gamethread is idling in sleep_for, I think
16:21<TrueBrain>(or paused, even)
16:21<_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.
16:21<frosch123>TrueBrain: i extended my comment
16:22<_2TallTyler>I'm a bit in over my head with scope across multiple files, and have never used extern
16:22<TrueBrain>owh, not over the loop, just take it, gotcha
16:24<TrueBrain>let me try that real quick
16:26<@DorpsGek>[OpenTTD/team] frosch123 commented on issue #143: [sv_SE] Translator access request https://git.io/JtdG4
16:27<TrueBrain>seems to work frosch123
16:27<TrueBrain>will need to think it over more clearly in the morning to see if it holds up, but the idea stands :)
16:28<TrueBrain>the yield only would be counter-productive. It already yielded because of the lock, if needed :)
16:30<TrueBrain>it works nice: enter Paint, enter GameLoop, exit Paint, exit GameLoop
16:30<TrueBrain>is what my debug statements tell me
16:30-!-jgx_ [~jgx@66.160.130.41] has quit [Remote host closed the connection]
16:30<frosch123>how would a semaphore help? is it more fair than a mutex?
16:30-!-jgx_ [~jgx@66.160.130.41] has joined #openttd
16:30-!-jgx_ is "realname" on #openttd
16:30<TrueBrain>your mutex now acts as a semaphore I think
16:31<TrueBrain>(one with 1 token)
16:31<frosch123>i consider a "mutex" the same as a "semaphore with max=1"
16:31<TrueBrain>so this should be the same as what I wanted to do
16:31<TrueBrain>somehow ... I did not come up with that :P
16:31<TrueBrain>took me for-ever to understand the difference between lock_guard and unique_lock
16:32<TrueBrain>luckily we have StackOverflow :D
16:32-!-rptr [~rptr@2a00:801:44b:5fb3:b852:cfd3:ade7:f24f] has joined #openttd
16:32-!-rptr is "morbidgirl" on #openttd #C #debian #debian-next #dfri_se #linux #oftc #packaging #publiclab #realraum #rust
16:33<frosch123>yes, no idea why they added both
16:34<LordAro>_2TallTyler: i can never remember either, i just copy what's there :p
16:34<LordAro>put it wherever, it can always be moved later
16:34<_2TallTyler>Will do. Thanks.
16:34<frosch123>iirc boost has 3 similar lock guards, so you can confuse 5 in total :)
16:34<TrueBrain>joy!
16:35<TrueBrain>anyway, tnx frosch123 , much appreciated you thinking along with this :D
16:35<TrueBrain>simpler is better :D
16:35<@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:35<frosch123>it was easier to read than the opengl magic :)
16:35<TrueBrain>haha :D
16:36<+glx>ok I didn't break nightly build :)
16:36<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)
16:36<TrueBrain>glx: w00p!
16:37<frosch123>TrueBrain: haha, i would be quite impressed if you manage than in one week :p
16:37<TrueBrain>well, maybe I start with TIC/TOCing it
16:37<TrueBrain>I mainly want to know if there is any benefit there
16:38<frosch123>i wondered whether every window should have its own draw buffer, which are then composed later
16:38<frosch123>but if you stack 100 extra-viewports on top of each other, that's quite a lot of memory
16:39<frosch123>you can open a lot of windows in ottd, way more than i do on my regular desktop
16:40<TrueBrain>I know there is a limit, at least, in TTD you could only open N
16:40<TrueBrain>and it would start closing others
16:40<TrueBrain>really annoying :D
16:41<frosch123>ottd has two configurable limits: one for non-sticky windows, one for sticky windows
16:43<frosch123>hmm, maybe the limit for sticky windows is infinite
16:44<frosch123>window_soft_limit defaults to 20, and is limited to 255
16:44<frosch123>but sticky windows may stay open forever
16:44<frosch123>oh, you can also disable the soft-limit by setting it to zero
16:45<TrueBrain>haha
16:45<frosch123>well, i guess the alternative would be to have one draw-buffer per thread in some draw-thread pool
16:46<TrueBrain>https://pasteboard.co/JPTvoYL.png <- HTML rendering of intro screen :D
16:47<frosch123>hmm, otoh, ViewportDrawer could become a member of each window with viewport, instead of a global one
16:47<TrueBrain>got the colours right \o/
16:47<frosch123>then the gameloop can fill that, and the guiloop can draw it whenever
16:47<TrueBrain>I have to read up on that code to understand what it is doing
16:48<TrueBrain>so far I had issues following what is calling who when :D
16:49<TrueBrain>guess next I have to implement padding etc, see if I can render them on the right location
16:49<TrueBrain>oops, forgot to rebase my PR
16:49<@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:49<TrueBrain>that is better
16:50<TrueBrain>I like how small it is, tbh .. removing the old stuff was more lines :D
16:52<frosch123>TrueBrain: https://bugs.openttd.org/task/5147/getfile/8380/start_up_game_v2.html#LOAD_SCENARIO_EDITOR_GAME_START <- hackalittlebit did a lot of interactive mockups some years ago
16:52<_dp_>TrueBrain, wow
16:52<_dp_>does it flexbox? xD
16:52<TrueBrain>_dp_: it uses flex, yes .. so in theory
16:52<TrueBrain>frosch123: well, exactly
16:53<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
16:53<TrueBrain>doing that in C++ would make it dreadfully slow
16:53<TrueBrain>so I am now just reading the C++ blob, and rendering it :P
16:53<TrueBrain>so you can "live" change it
16:53<_dp_>yeah, having html would be totally awesome
16:53<TrueBrain>and the Widget system is decent enough to do it, so far at least
16:54<TrueBrain>display: flex helps a lot
16:54<_dp_>and will make gs gui possible as well
16:54-!-Samu [~Ricardo@po1-84-91-251-215.netvisao.pt] has quit [Quit: Leaving]
16:54<TrueBrain>why you say so?
16:55<+glx>_dp_: it's not inside openttd, it's just an external js thing
16:55<_dp_>oh, bummer :/
16:56<TrueBrain>sorry, I thought that was rather clear :)
16:56<TrueBrain>I am not going to make an HTML renderer in OpenTTD :P
16:56-!-_2TallTyler [~oftc-webi@151.203.115.35] has quit [Quit: Page closed]
16:56<+glx>yeah we're not rewriting windows agian
16:56<+glx>*again
16:56<frosch123>TrueBrain: when you added 60fps in one week, everyone thought you would port the gui to qt :p
16:56<TrueBrain>why on earth would I want to do that to myself? :P
16:57<Xaroth>I still get nightmares from QML >_>
16:57<TrueBrain>really, the widget system in OpenTTD is powerful enough, if you ask me
16:57<TrueBrain>it is just shit to: change a widget, compile, start, click 4 windows, check result
16:57<TrueBrain>that .... no :P
16:57<frosch123>yes, the widgets are fine. but the text rendering is lacking
16:57<+glx>well you could auto open window when testing
16:58<frosch123>so many games have hyperlinks in texts, to get help or tooltips, to go to locations, ...
16:58<TrueBrain>glx: often difficult .. loading a certain game, clicking a certain vehicle, opening orders .. for example
16:58<_dp_>it's not that hard to do simplified html renderer :p
16:58*_dp_ totally not doing that himself
16:58<TrueBrain>_dp_: what problem would that solve, really :)
16:58<+glx>and it won't stay simplified
16:58<_dp_>gs ui? :p
16:59<TrueBrain>well, we could make a markup language for windows, that GS can compile on-the-fly :P
16:59<TrueBrain>but even that .. oef
16:59<+glx>people will always want more html stuff, then css, then ...
16:59<_dp_>if you make a language why not html? :p
16:59<TrueBrain>for the current window system, the amount of commands are limited
16:59<TrueBrain>so making a lexer for it would be easy
16:59<TrueBrain>because HTML is not easy
17:00<TrueBrain>and HTML does not implement our window system
17:00-!-tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd
17:00-!-tokai|noir is "Christian Rosentreter" on #openttd
17:00-!-mode/#openttd [+v tokai|noir] by ChanServ
17:00<TrueBrain>so that would require two things: parse HTML and make a new renderer
17:00<TrueBrain>better to only parse something, and use the current renderer ;)
17:00<_dp_>current window system is kinda borked btw
17:00<_dp_>paddings are all wrong afaict
17:00<TrueBrain>I haven't found anything really wrong
17:00<TrueBrain>sure, it is limited, but that is not a bad thing
17:01<_dp_>paddings don't scale and their calculation is all wrong
17:01<TrueBrain>naming is a bit annoying .. there isn't really a clear indication when you have to use EndContainer, for example
17:01<TrueBrain>even if that is true, that doesn't mean we should throw it away to add something else that will have problems :)
17:01<_dp_>code duplication for draw/size as well...
17:01<TrueBrain>that is the "oeh, shiny" problem :)
17:02<_dp_>I kinda hoped there would be some ui libraries for that already
17:02<_dp_>but didn't find anything decent
17:03<andythenorth>_dp_ is that related to? https://github.com/OpenTTD/OpenTTD/issues/7599
17:03<_dp_>andythenorth, yeah, mb some of it
17:04<_dp_>I'm not sure what exacly you mean there in some points
17:04<_dp_>but basicaly pretty much all paddings are hardcoded and don't scale
17:05<_dp_>and margins I guess as well, not that there is any difference in openttd xD
17:05<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?
17:05<andythenorth>_dp_ most of that issue I think is "this has changed and I don't know why"
17:05<andythenorth>I closed it as 'meh' in the end :)
17:06<frosch123>Xaroth: changed when? during gameloop? during command?
17:06<andythenorth>the UI is not a ditch I want to die in :P
17:07<Xaroth>both
17:07-!-tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
17:07<_dp_>andythenorth, I mostly just dealt with some ui code and not surprised there are ton of small ui issues with how it is
17:08<TrueBrain>funny, our "padding" is HTML "margin" :D
17:08<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #8730: Codechange: [OpenGL] Load all OpenGL functions dynamically. https://git.io/JtQDe
17:08<frosch123>the clear command is tracked during the clear-command itself, so it does not clear tiles twices (important when clearing multi-tile things)
17:08<_dp_>TrueBrain, it's both
17:08<TrueBrain>https://pasteboard.co/JPTE7sX.png things are on the right place now :D
17:08<frosch123>coop had a patch to log when players did something on a tile, and then draw a map with color per player
17:08<Xaroth>frosch123: I'm working on a thing for the admin port where it sends map data (tile type/owner) over the admin network
17:08<frosch123>othweise, the tileloop changes every tile in 256 ticks
17:09<TrueBrain>height is wrong .. hmm
17:09<Xaroth>So I'm trying to figure out something not-that-intrusive that can notify when certain parts of the map have changed
17:10<frosch123>MarkTileDirty() is the closest you can get
17:11<frosch123>filter out clear land, sea and trees, and you may have a reasonable amount of data
17:12<TrueBrain>hmm .. is there a font that is close to OpenGFX' font?
17:12<frosch123>opengfx font was rendered from a real font iirc
17:12<+glx>tahoma is close to TTD font IIRC
17:13<+glx>and opengfx font is broken ;)
17:13<TrueBrain>if I believe this channel, everything is broken :)
17:13<frosch123>opengfx mono font is "liberation mono"
17:13<_dp_>it's not that hard to figure map area from the network command
17:14<TrueBrain>12px Tamoha comes close enough for buttons it seems
17:14<_dp_>https://pastebin.com/buwYBgrd
17:15<TrueBrain>owh, no, it is using a random font but not telling me
17:15<TrueBrain>lol
17:15<TrueBrain>silly Firefx
17:15<Xaroth>_dp_: Thanks, will check where that leads me
17:16<TrueBrain>https://pasteboard.co/JPTHkiM.png good enough
17:20<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #8730: Codechange: [OpenGL] Load all OpenGL functions dynamically. https://git.io/JtQDe
17:21<TrueBrain>michi_cc knows templates :D
17:22-!-Progman [~progman@p57a2b25f.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
17:22<frosch123>don't incentivate a template competition :p
17:22<TrueBrain>awh :(
17:24<+glx>that's readable template at least
17:24-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.]
17:25<frosch123>it's also readable preprocessor code :)
17:25<frosch123>preprocessor stuff can be worse than templates
17:25-!-tokai [~tokai@00012860.user.oftc.net] has joined #openttd
17:25-!-tokai is "Christian Rosentreter" on #openttd
17:25-!-mode/#openttd [+v tokai] by ChanServ
17:28-!-rptr [~rptr@2a00:801:44b:5fb3:b852:cfd3:ade7:f24f] has quit []
17:29<andythenorth>it's not a proper game until you've templated the preprocessor stuff, with python
17:29*andythenorth tries to suppress that memory
17:30<TrueBrain>tnx for https://grf.farm/misc/company_colour_indexes.html andythenorth , it is really useful :)
17:31<frosch123>andythenorth: i encountered people 20 years older than you, who ran piped m4 output into cpp, and used magic from both
17:31<TrueBrain>https://pasteboard.co/JPTNzYi.png <- guess which GUI that is :P Guess next I should get the pngs to use :)
17:32<+glx>transparency
17:32<TrueBrain>nope
17:32<andythenorth>frosch123 did they learn no to? :)
17:32<Eddi|zuHause>that's rail construction?
17:32<TrueBrain>almost, but no
17:32-!-tokai|noir [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
17:32<+glx>I can see a bridge
17:32<Eddi|zuHause>then road
17:32-!-tyteen4a03 [~tyteen4a0@00018d47.user.oftc.net] has quit [Quit: Bleh?]
17:32<TrueBrain>yup
17:32<andythenorth>I see dead people
17:32<TrueBrain>less buttons than rail
17:33<andythenorth>oh wait, we're in a different movie
17:33<@DorpsGek>[OpenTTD/OpenTTD] frosch123 approved pull request #8730: Codechange: [OpenGL] Load all OpenGL functions dynamically. https://git.io/JtdVz
17:33<andythenorth>which movie is this?
17:33<Eddi|zuHause>yeah, i counted the buttons, but was unsure
17:33<Eddi|zuHause>so i did a 50/50 flip
17:33<TrueBrain>michi_cc: do you want me to tackle to not load opengl.so for SDL? Or will you give that a spin?
17:34<+michi_cc>TrueBrain: I would have to setup SDL first, so you may gladly have a go at it :)
17:34<TrueBrain>will do so this week :)
17:34<frosch123>michi_cc: https://dpaste.org/XUWm <- i guess nothing of interest
17:34<frosch123>just random spam :)
17:35<TrueBrain>michi_cc: gave making 40bpp-anim the default some more thought btw?
17:36<+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... :)
17:36<+michi_cc>TrueBrain: It's somewhat slower. Other than that, it's potato potato for me.
17:37<TrueBrain>I think the transparency alone is worth it for many of our users
17:37<TrueBrain>it is still a lot faster than non-OpenGL 32bpp :)
17:37<TrueBrain>hmm, in fact it is even faster than the 8bpp :P
17:38<TrueBrain>still can't wrap my head around that OpenGL can render a frame in 0.02ms
17:38<TrueBrain>anyway, time to find my bed
17: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.
17:42<+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
17:42<+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.
17:51<+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.
17:52-!-andythenorth [~andytheno@cpc87165-aztw31-2-0-cust40.18-1.cable.virginm.net] has quit [Quit: andythenorth]
17:56-!-frosch123 [~frosch@00013ce7.user.oftc.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
18:06-!-rptr [~rptr@2a00:801:44b:5fb3:b852:cfd3:ade7:f24f] has joined #openttd
18:06-!-rptr is "morbidgirl" on #moocows #rust #realraum #publiclab #packaging #oftc #linux #dfri_se #debian-next #debian #C #openttd
18:07<+glx>it should be possible to implement something similar to add_file CONDITION in link_package
18:21-!-gelignite [~gelignite@55d44adf.access.ecotel.net] has quit [Quit: Stay safe!]
18:30-!-HerzogDeXtEr [~farci@146.52.11.16] has quit [Read error: Connection reset by peer]
18:34<@DorpsGek>[OpenTTD/OpenTTD] michicc opened pull request #8743: Change: Default to a 32bpp blitter. https://git.io/Jtdoj
18:34<@DorpsGek>[OpenTTD/OpenTTD] michicc merged pull request #8730: Codechange: [OpenGL] Load all OpenGL functions dynamically. https://git.io/JtQDe
18:53<@DorpsGek>[OpenTTD/OpenTTD] LordAro approved pull request #8738: Fix #8123: trams on half-tiles couldn't find depots https://git.io/JtdKY
19:22<@peter1138>^B is ... one way to tell that OpenGL is in use.
19:22<+glx>https://github.com/OpenTTD/OpenTTD/compare/master...glx22:opengl_link <-- quick and dirty test
19:31<@peter1138>Oh, bounding boxes are solid white with a 32bpp set. Translucent with 8bpp.
19:31<_dp_>so... what happens if company that client is joining disappears while he's downloading the map?
19:31<_dp_>or, even better, was replaced with another one?
19:32<+glx>hmm it joins the new one ?
19:33<_dp_>that is if id is not reused and it can create one...
19:36<@DorpsGek>[OpenTTD/OpenTTD] glx22 commented on pull request #8743: Change: Default to a 32bpp blitter. https://git.io/Jtd6f
19:41<@peter1138>"Apparently, the looks of 32bpp blitters are superior." is there even a difference if not using 32bpp graphics?
19:42<_dp_>font antialiasing, stuff transparency
20:05-!-Flygon [~Flygon@2001:44b8:411e:4e00:dd5c:9a65:a0b7:e521] has joined #openttd
20:05-!-Flygon is "Flygon" on #openttd
20:25-!-Taede [~T@neurotic.nurionis.co.uk] has quit [Quit: He who can look into the future, has a brighter future to look into]
20:25-!-ZirconiumX [~Zirconium@62.ip-51-89-164.eu] has quit []
20:25-!-Exec [~me@execthts.net] has quit [Quit: No Ping reply in 120 seconds.]
20:26-!-Taede [~T@neurotic.nurionis.co.uk] has joined #openttd
20:26-!-Taede is "Taede Werkhoven" on #openttd #oftc @#Turbulent #supybot @#Soapy #openttdcoop.nightly #openttdcoop.dev #/r/openttd
20:27-!-ZirconiumX [~Zirconium@62.ip-51-89-164.eu] has joined #openttd
20:27-!-ZirconiumX is "<3 you Tasos" on #openttd #llvm #/r/openttd
20:27-!-Exec [~me@execthts.net] has joined #openttd
20:27-!-Exec is "Exec" on #openttd
20:31-!-reldred [sid472373@id-472373.highgate.irccloud.com] has quit [Remote host closed the connection]
20:32-!-reldred [sid472373@id-472373.highgate.irccloud.com] has joined #openttd
20:32-!-reldred is "reldred" on #openttd
21:06-!-glx [glx@000128ec.user.oftc.net] has quit []
21:40-!-Wuzzy [~Wuzzy@0001b11e.user.oftc.net] has quit [Quit: Wuzzy]
22:10-!-Wormnest [~Wormnest@35.136.189.95] has quit [Quit: Leaving]
22:12-!-tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd
22:12-!-tokai|noir is "Christian Rosentreter" on #openttd
22:12-!-mode/#openttd [+v tokai|noir] by ChanServ
22:19-!-tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
22:21-!-D-HUND [~debdog@2a00:79c0:641:ae00:7a24:afff:fe8a:d04d] has joined #openttd
22:21-!-D-HUND is "Wowbagger" on #openttd
22:24-!-debdog [~debdog@2a00:79c0:660:4d00:7a24:afff:fe8a:d04d] has quit [Ping timeout: 480 seconds]
22:34-!-muffindrake4 [~muffindra@p200300cdd7124e00a3eae7cd5efa8662.dip0.t-ipconnect.de] has joined #openttd
22:34-!-muffindrake4 is "muffindrake" on #debian-next #openttd
22:36-!-muffindrake3 [~muffindra@p200300cdd7159a00a43df9ee2616525a.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]
22:52-!-rptr [~rptr@2a00:801:44b:5fb3:b852:cfd3:ade7:f24f] has quit []
22:58-!-rptr [~rptr@2a00:801:44b:5fb3:b852:cfd3:ade7:f24f] has joined #openttd
22:58-!-rptr is "morbidgirl" on #moocows #rust #realraum #publiclab #packaging #oftc #linux #dfri_se #debian-next #debian #C #openttd
23:00-!-didac [~oftc-webi@c-67-168-111-57.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
23:32-!-rptr [~rptr@2a00:801:44b:5fb3:b852:cfd3:ade7:f24f] has quit [Remote host closed the connection]
23:32-!-rptr [~rptr@2a00:801:44b:5fb3:b852:cfd3:ade7:f24f] has joined #openttd
23:32-!-rptr is "morbidgirl" on #openttd #C #debian #debian-next #dfri_se #linux #oftc #packaging #publiclab #realraum #rust #moocows #llvm
---Logclosed Thu Feb 25 00:00:54 2021