Log for #openttd on 19th May 2021:
Times are UTC Toggle Colours
00:48:59  *** bkilm[m] has quit IRC
00:59:41  *** tokai|noir has joined #openttd
00:59:41  *** ChanServ sets mode: +v tokai|noir
01:06:19  *** tokai has quit IRC
01:15:25  *** tokai has joined #openttd
01:15:25  *** ChanServ sets mode: +v tokai
01:22:21  *** tokai|noir has quit IRC
01:59:59  *** Wormnest has quit IRC
02:18:54  *** tokai|noir has joined #openttd
02:18:54  *** ChanServ sets mode: +v tokai|noir
02:25:41  *** tokai has quit IRC
02:40:23  *** debdog has joined #openttd
02:43:43  *** D-HUND has quit IRC
02:57:18  *** glx has quit IRC
02:58:42  *** Flygon has joined #openttd
05:06:30  *** tokai has joined #openttd
05:06:30  *** ChanServ sets mode: +v tokai
05:13:13  *** tokai|noir has quit IRC
05:42:29  *** FLHerne has quit IRC
05:57:01  *** tokai|noir has joined #openttd
05:57:01  *** ChanServ sets mode: +v tokai|noir
06:03:53  *** tokai has quit IRC
06:04:07  <DorpsGek> [OpenTTD/OpenTTD] lambodhar opened issue #9281: Company Takeover Maths not correct.
06:10:26  <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #9281: Company Takeover Maths not correct.
06:40:02  *** HerzogDeXtEr has joined #openttd
06:50:24  *** sla_ro|master has joined #openttd
07:50:14  <peter1138> Morn
07:52:06  *** andythenorth has joined #openttd
07:59:12  *** andythenorth has quit IRC
08:03:52  *** FLHerne has joined #openttd
08:06:48  <peter1138> Le Chunk's Revenge.
08:07:15  <peter1138> Favourite past-time: using 4x zoom to see what isn't scaled.
08:08:04  *** andythenorth has joined #openttd
08:10:08  <peter1138> ScaleGUITrad(andythenorth)
08:10:22  <andythenorth> uuf
08:13:23  <peter1138> Super-chunky at 4x. 8x zoom?
08:13:27  <LordAro> *UUF
08:14:09  <LordAro> or perhaps, UUF
08:15:19  <peter1138> :D
08:19:00  <peter1138>
08:19:15  <andythenorth> so proper
08:19:24  <andythenorth> pls can haz now?
08:19:24  <peter1138> 4x works on 4K
08:19:36  <LordAro> can't even tell it's scaled
08:19:50  <andythenorth> what resolution is that even?
08:20:08  <LordAro> oh, zoom on the industry window viewport, i suppose
08:20:54  <andythenorth> lol, just discovered a probably-not-snake-oil explanation of why my mac is soooooo slow
08:20:55  <peter1138> andythenorth, 3840x2160.
08:20:58  <andythenorth> involving the Chrome updater
08:21:27  <peter1138> Now, with a scalable font, it would be nice, but no scalable font quite matches the bitmap font dimensions.
08:23:28  <peter1138> Hmm, the 1px drop shadow becomes a bit feint.
08:23:30  <peter1138> faint.
08:28:49  <andythenorth> release is when?
08:28:57  * andythenorth too eager
08:30:07  <peter1138> More work to do.
08:31:19  <peter1138> I cheated on button sprites by ignoring offsets. Makes all the window decorations line up properly, but some of the toolbar icons are not right. The lorry button...
08:35:46  <LordAro> ah yeah
08:37:09  *** andythenorth has quit IRC
08:50:20  <peter1138> In fact that lorry is not right at its normal location, but it doesn't look out of place.
08:50:43  <LordAro> i certainly didn't notice it until you pointed it out
08:50:52  <LordAro> but it's been a while since i played with original graphics
08:51:50  <peter1138> I loaded up old versions a lot, as our GUI has been a mess for quite some time.
08:52:14  <LordAro> the scrollbar arrows are probably the most noticable
08:52:25  <peter1138> Only 3 zoom levels, eh?
08:52:53  <LordAro> call up Linus for a 16k setup that you can test 8x zoom on :p
08:53:07  <peter1138> I'm already using DSR to test 4k :D
08:53:23  <LordAro> ha
08:54:05  <peter1138> It also really highlights a bug in OpenGL. Flickers all over the place like it's drawing partially rendered screen areas.
08:54:12  <Rubidium> I'd call NHK for that ;)
08:55:56  <Rubidium> though we ought to fix the sound then, as stereo on a 22:2 setup might be a bit underwhelming
08:56:11  <LordAro> hahaha
08:58:00  <Rubidium> oh, bugger... that's "only" 8K
08:58:23  <Rubidium> I was quite impressed by it in early 2008 though
08:58:57  <peter1138> I actually had a patch for ambisonics...
08:59:03  <orudge> "OPENTTD DISTRIBUTION LTD has 2 total employees across all of its locations and generates 0,057 in sales (USD). (Employees and Sales figures are modelled)."
08:59:07  <orudge> That's some impressive modelling... :/
08:59:56  <peter1138> If only, eh?
09:00:39  <LordAro> lots of games have UI that doesn't scale well :)
09:01:11  <LordAro> (civ 5 at ~14:15)
09:02:38  <peter1138> I love that we do scale, but everyone complains because 1x is too small and 2x is too large...
09:03:09  <peter1138> (Most screens these days are larger than 2x 640x480, so... whatever)
09:05:11  <peter1138> I'd like non-integer sprite scaling too, but I have no idea how to go about that given we pre-scale everything.
09:06:01  <peter1138> My arbitrary scaling works to a point, it's fine for window decorations and buttons, but it falls apart when drawing vehicle sprites in windows.
09:06:43  <peter1138> That might be a case for handling those cases separately to use the 1x/2x/4x scaling system instead of arbitrary, though.
09:06:45  <FLHerne> orudge: modelled based on...what?
09:09:28  <peter1138> LordAro, (not mine fortunately)
09:09:54  <LordAro> ouch
09:10:22  <LordAro> i suppose you could probably manage to at least get home after replacing the tube
09:10:34  <LordAro> wouldn't want to keep riding on it though..
09:11:37  <peter1138> Yeah...
09:12:34  <peter1138>
09:14:01  <LordAro> nothing like a good lipo fire
09:14:12  <LordAro> there's hundreds of the things that have popped up in York
09:16:40  <TrueBrain> orudge: it did make me wonder what you are holding back from us :P
09:19:21  <orudge> TrueBrain: hah, if I was somehow making 0K a year from OpenTTD, that would be quite impressive :D
09:19:50  <TrueBrain> so you are the other Microsoft Store entry :P
09:19:51  <TrueBrain> :P :P :P
09:20:12  <TrueBrain> well, if we charged  on Steam, that might have been true honestly
09:20:25  <TrueBrain> anyway, just happy to read they accepted your info and now want a call with you
09:20:26  <TrueBrain> PROGRESS
09:20:31  <orudge> but yes, what their modelling is based on, who knows - the company hasn't filed any accounts yet, having only existed for a few months, with about £10 in the bank :p
09:20:35  <orudge> but yes
09:20:38  <orudge> we are slowly getting there
09:20:50  <orudge> I ordered a certificate for 3 years so we don't have to go through this for another few years :p
09:21:09  *** Samu has joined #openttd
09:21:40  *** felix has quit IRC
09:24:10  <TrueBrain> orudge: smart :)
09:24:24  <TrueBrain> right .. going to switch the first repo (TrueWiki) to "main" as default branch
09:24:27  <TrueBrain> let's see what breaks
09:29:04  <peter1138> michi_cc, is it somehow possible for the OpenGL buffer to be rendered to screen part way through the game drawing to it?
09:30:29  <TrueBrain> peter1138: SwapBuffers is done only every draw-tick
09:30:40  <TrueBrain> so assuming OpenGL honors that, it shouldn't be possible
09:31:02  <orudge> TrueBrain: ah, just saw your messages from last night now :p I think the CN has to be the company name. That or somebody could change their own legal name to "OpenTTD" and we do it under their name, any volunteers? :P
09:31:21  <TrueBrain> orudge: :D Well, as they mention it explicit as: "is this correct"
09:31:28  <TrueBrain> I was thinking, maybe there is some wiggleroom
09:32:19  <orudge> I'll see what they say when they phone
09:32:40  <TrueBrain> and if it is not possible, it is okay; we should just mention it on the download page this to be the case
09:33:18  *** felix has joined #openttd
09:33:24  <peter1138> I am definitely seeing partial draws in some instances.
09:34:05  *** tokai has joined #openttd
09:34:05  *** ChanServ sets mode: +v tokai
09:35:12  <TrueBrain> peter1138: on a very high resolution, or?
09:35:29  <TrueBrain> and is it tearing or partial draws?
09:36:25  <peter1138> Seems any resolution, but high resolution is more noticable. Partial draws.
09:36:51  <TrueBrain> does it also happen without OpenGL?
09:36:57  <peter1138> Nope
09:37:26  <TrueBrain> some GPUs have this mode where they create frames that don't exist if the game doesn't keep up; that enabled by any chance?
09:38:06  <peter1138> Hmm, I've only ever seen that in VR. I wonder
09:38:26  <TrueBrain> without it VR would be a disaster :P
09:38:26  *** WormnestAndroid has quit IRC
09:38:39  *** WormnestAndroid has joined #openttd
09:39:26  <TrueBrain> either way, I do not know the OpenGL implementation well enough to state that it really is drawing in the right buffer .. but SwapBuffer strongly suggests no partial image should become visible before all drawing is done :D
09:39:51  <TrueBrain> does reducing the in-game refresh rate help or make it worse? Similar for increasing it?
09:40:52  <TrueBrain> and of course it might also be our own drawing code being wrong :)
09:40:54  *** tokai|noir has quit IRC
09:49:21  <peter1138> Seems to have an effect. At 30 I don't see it, above that I do.
09:49:59  <peter1138> Also, must be in fullscreen mode, and I think vsync needs to be on. Not sure if that is the only time it occurs, or it's just more likely to occur.
09:51:00  <TrueBrain> hmm .. fullscreen ... the pain of anyones existance
09:51:09  <TrueBrain> replace with borderless windowed you say? :D
09:52:03  <TrueBrain> I can only speculate of the problem .. like fullscreen not having a double-buffer (which would be odd, but who knows)
09:52:38  <peter1138> I don't think that would explain partial draws
09:52:39  <peter1138> Oh!
09:52:50  <peter1138> When I saw partial, I mean like mid-way through drawing a window.
09:53:06  <peter1138> Sometimes parts of it will flick back to the window background, because it hasn't drawn the text on top yet.
09:53:18  <peter1138> Which seems to me to be impossible except it's happening.
09:53:27  <TrueBrain> well, if there is no double-buffer
09:53:33  <TrueBrain> that is the result I expect
09:53:41  <TrueBrain> at some point the GPU sends it to the display
09:53:46  <TrueBrain> which can be half-way through our rendering code
09:54:16  <peter1138> But can it? Can the GPU render our persistent buffer without being asked to?
09:54:31  <TrueBrain> that is the part of "I can only speculate" :P
09:55:17  <TrueBrain> back in the 90s, when we didn't have double-buffers etc, those things were common
09:55:19  <TrueBrain> it just reminds me of it :)
09:55:19  <peter1138> Cool, when it's at 4x DSR (5120x2880) even the main viewport suffers.
09:56:13  <TrueBrain> you could add a bunch of sleeps in the window drawing code, see if that makes it worse
09:57:03  <TrueBrain> <- places like this, sleep before it for 100ms or something
09:57:11  <TrueBrain> should make the drawing incredibly slow, and the fps drop
09:57:16  <TrueBrain> if it shows even more partials
09:57:26  <TrueBrain> it indicates we are drawing in a buffer the GPU decides to render for real :P
09:57:32  <TrueBrain> for what-ever reason
09:57:56  <peter1138> I wonder if windowed-mode is implicitly buffered due to all the window management stuff going on, and then fullscreen bypasses that.
09:58:23  <TrueBrain> we have PFD_DOUBLEBUFFER enabled
09:58:32  <TrueBrain> so I doubt it really is double-buffering .. but it looks similar
09:59:32  <peter1138> aH, WE DO. hMM.
10:00:03  <TrueBrain> but just because the window itself is in double-buffer mode
10:00:06  <TrueBrain> doesn't mean OpenGL is :P
10:00:52  <TrueBrain> but my knowledge in this is really dated .. we used to have to do glDrawBuffer(GL_BACK)
10:01:07  <peter1138> Afaik you have to tell OpenGL to draw anything otherwise it doesn't.
10:01:12  <peter1138> Which makes this odd.
10:01:49  <TrueBrain> but yeah, that is the point I have to hand it over to michi_cc :)
10:02:46  <peter1138> Hmm, win32:no_threads?
10:03:25  <TrueBrain> you can try :) Just disables the game-thread
10:03:41  <TrueBrain> should make zero difference, so worth a try :P
10:04:49  <peter1138> Ok. What if I told you it fixes it?
10:06:28  <TrueBrain> that would somewhat scare me :D
10:07:13  <TrueBrain> all the drawing should be done in the draw-thread (which is the main-thread)
10:07:23  <peter1138> I'll rephrase it then. Disabling threads fixes it.
10:10:20  <TrueBrain> does it happen for specific windows?
10:10:50  <peter1138> Can be any, or the main viewport, some are more easily noticable.
10:11:30  <TrueBrain> can you move a few lines of code for me:
10:11:31  <TrueBrain>
10:11:37  <TrueBrain> those 2 calls, can you move them inside the scope just above
10:11:44  <TrueBrain> (so the game-state is locked while they are being executed)
10:11:56  <TrueBrain> it gives horrible performance btw, but that is not the point :D
10:12:58  <peter1138> Still flickers
10:13:07  <TrueBrain> next one: can you move the LockVideoBuffer inside the mutex?
10:14:00  <TrueBrain> as in, reverting
10:15:00  <peter1138> Still flickers. If anything it's actually more noticable.
10:15:30  <TrueBrain> and, maybe not unexpected, as last: move the UnlockVideoBuffer inside too
10:15:36  <TrueBrain> so all 4 are done inside the lock
10:15:47  <TrueBrain> as that should make it identical to no_threads :D
10:15:51  <TrueBrain> should/would/could :P
10:16:42  <peter1138> Scanning NewGRFs is very slow now :D
10:17:18  <TrueBrain> lol
10:17:23  <TrueBrain> have less NewGRFs :P
10:17:35  <peter1138> Simulation rate is terrible too, nice.
10:18:00  <TrueBrain> increase your refresh-rate :P
10:18:41  <peter1138> Still flickers but less noticable now.
10:18:51  <TrueBrain> now that is very weird ..
10:18:57  <TrueBrain> as the two threads now run in lockstep
10:19:01  <peter1138> And reducing refresh-rate to improves game performance.
10:19:31  <TrueBrain> well, this is the moment I would need to be able to reproduce it to find out what is going on exactly .. which is a bit difficult for me atm :D
10:22:26  <TrueBrain> hmm .. the one thing I can speculate, that Paint() triggers an async move of the videobuffer, but before it is fully done, another draw-tick is executed trashing the video buffer before it gets to the GPU or something
10:22:49  <TrueBrain> and that it is a timing issue
10:23:04  <TrueBrain> would explain why you see it less on lower refresh-rates
10:24:06  <TrueBrain> LockVideoBuffer() doesn't stall if there is already an active lock
10:24:16  <TrueBrain> which allows that flow to happen
10:24:23  <TrueBrain> I just would consider it crazy unlikely, looking at the code :P
10:25:39  <TrueBrain> would only be an issue with persistent mapping, I guess
10:26:23  <TrueBrain> can you revery any changes and manually disable persistent_mapping_supported ?
10:31:54  <peter1138> Seems to stop it, but performance is terrible. Hmm.
10:32:26  <TrueBrain> only draw-fps I assume?
10:32:26  <peter1138> Let's get rid of exclusive fullscreen mode :D
10:32:47  <TrueBrain> well, if the problem is what I suspect it is, it can also happen in any other mode
10:33:11  <peter1138> My fps seems to drop down to about 40 fps, but I think that's an average, becuase it's very "lumpy". The mouse cursor does not more smoothly, etc.
10:33:15  <TrueBrain> basically, we are quick enough that we reuse a buffer before the GPU is done with it :P
10:33:42  <TrueBrain> but this is something I need michi_cc for to fill in some gaps in my knowledge :D
10:33:49  <peter1138> I thought all the window updating happened in that lock though.
10:33:53  <TrueBrain> it does
10:34:11  <TrueBrain> but imagine this: we get GPU buffer A, we write it in, and tell the GPU: now go draw it
10:34:19  <TrueBrain> next draw-tick, we ask for a GPU buffer, it is persistent, we get A again
10:34:22  <TrueBrain> we start writing in it
10:34:27  <TrueBrain> but waaaiittt a moment, the GPU wasn't done with it yet
10:34:42  <TrueBrain> no clue if that is the case, but the code suggests a flow that would allow that to happen
10:34:54  <peter1138> Okay, so it's not OpenGL redrawing the buffer, it's OpenGL _still_ drawing the buffer...
10:34:56  <TrueBrain> I don't know if persistent buffers guard for that
10:35:50  <peter1138> Yet it only seems to manifest in full screen with v-sync. I guess both those just making the timing more likely to occur, rather than affect it.
10:35:53  <TrueBrain> but especially on high resolutions I can fully imagine the GPU needing more time to send all data :P
10:36:14  <TrueBrain> yeah, especially with vsync .. we get the buffer really early in the draw-tick
10:36:23  <TrueBrain> but again, I know too little about persistent buffers
10:36:28  <TrueBrain> so I am heavily speculating here
10:37:16  <TrueBrain> I guess we should park this till "the expert" arrives, before I say more stuff that is wildly speculative :D :D
10:37:59  <peter1138> Basically... it's bypassing double-buffering...
10:38:10  <peter1138> So, two, persistent buffers and alternate between them...
10:38:24  <TrueBrain> I am sure OpenGL has this problem solved, if this is even the problem
10:49:27  <TrueBrain> oof, trying to understand GitHub GraphQL, but it is hard
10:50:36  <peter1138> "Yes, you need to do explicit synchronization. Even though you coherently mapped the buffer, you still cannot change the values in it while OpenGL might be reading from them. You must wait until after the last call that reads from that data before writing to it again. And the only ways that OpenGL has to wait for it to get finished is either glFinish or glClientWaitSync."
10:51:23  <TrueBrain> we have a few glClientWaitSync
10:52:46  <TrueBrain> we just .... delete it in ReleaseVideoBuffer
10:52:48  <TrueBrain> that feels weird
10:53:31  <TrueBrain> well, I don't understand enough of this stuff to give any helpful advise :D
11:04:35  *** andythenorth has joined #openttd
11:06:15  <peter1138> Deleted branch master (was 95a7291a).
11:06:16  <peter1138> Hah
11:10:56  <TrueBrain> Who needs master anyway
11:11:23  *** sla_ro|master has quit IRC
11:13:53  <peter1138> Isn't it.
11:15:07  *** WormnestAndroid has quit IRC
11:16:23  *** tokai|noir has joined #openttd
11:16:23  *** ChanServ sets mode: +v tokai|noir
11:17:04  *** WormnestAndroid has joined #openttd
11:17:06  <andythenorth> probably time to discuss lunch soon?
11:18:23  <Timberwolf> Ooh, yes.
11:18:34  <Timberwolf> I have one more lunchworth of houmous in the fridge.
11:20:58  <peter1138> I need to just stop eating.
11:22:23  <milek7>
11:22:30  <milek7> this is the glitch discussed or another one?
11:22:53  *** tokai has quit IRC
11:29:32  <peter1138> Same one.
11:30:46  <peter1138> Also rendering windows into separate buffers might be nice. Self-compositing...
11:30:57  *** andythenorth has left #openttd
11:41:44  <TrueBrain> peter1138: you are not the first to suggest that :D
11:41:49  <TrueBrain> it would also speed up the game a lot
11:42:06  <peter1138> I don't know about a lot. But it would reduce unnecessary redraws.
11:42:30  <TrueBrain> well, ofc, "a lot" is subjective, as it depends on the game and your actions :P
11:42:52  <TrueBrain> but the drawing code often redraws now without any good reason if we had separate buffers per window
11:43:09  *** andythenorth has joined #openttd
11:43:15  <andythenorth> cheese on toast again?
11:43:34  <TrueBrain> I wonder how difficult it really is
11:44:08  <andythenorth> cheese on toast?
11:44:10  <peter1138> I noticed that redrawing the framerate window seems to redraw bits of the viewport around the edges too.
11:44:11  <andythenorth> really easy
11:44:52  <peter1138> TrueBrain, easier if you don't try to cater for both doing it and not doing it :)
11:45:31  <TrueBrain> peter1138: I noticed in more places that what is marked "dirty" isn't always correct
11:45:48  <TrueBrain> also that viewports tend to redraw even if they are fully covered by other windows
11:45:55  <TrueBrain> but I haven't looked into any of that
11:46:11  <TrueBrain> I was more interested in making the viewport code threaded .. which is very doable
11:46:20  <TrueBrain> and gives a nice performance boost with certain NewGRFs :D
11:46:26  <peter1138> Hmm.
11:46:29  <TrueBrain> just the code is horrible and first needs a refactor :P
11:46:38  <TrueBrain> "its a class but not really, so just a lot of functions and globals"
11:46:58  <andythenorth> train window, Iron Horse 2 :P
11:47:00  <andythenorth> enough said
11:47:07  <peter1138> It would be nice if the OpenGL blitter actually used OpenGL to blit, and then use it for "free" scaling, without having everything pre-scaled.
11:47:28  <TrueBrain> does it allow scaling 1.1?
11:47:31  <TrueBrain> 1.1x?
11:47:43  <peter1138> OpenGL can do any scaling, yes.
11:47:54  <TrueBrain> cool
11:48:15  <peter1138> Usually at funny angles as well.
11:48:34  <peter1138> But, that way rules out compatibility with non-OpenGL, so...
11:48:42  <peter1138> (Or D3D)
11:49:00  <peter1138> Unless we can rewrite the blitter system to scale while drawing instead as well.
11:50:58  <TrueBrain> in general I would assume the way forward is moving more blitter stuff to the drawing code
11:51:03  <TrueBrain> which for OpenGL could be its backend
11:52:10  <peter1138> We draw lines pixel by pixel. OpenGL should be able to improve on that.
11:52:22  <peter1138> That function is even offloaded to the blitter, so it could be done.
11:53:55  <peter1138> DrawRect is pixel by pixel too.
11:54:34  <milek7> does GetUpdateRect makes any sense in fullscreen?
11:55:05  <milek7> or it's just gonna return some junk rectangle
11:55:17  <peter1138> Yes?
11:55:33  <peter1138> WHy would it be junk?
11:56:46  <milek7> it talks about windows, and in exclusive fullscreen there isn't really a window to draw to...
11:57:59  <milek7>
11:58:09  <peter1138> The whole screen is a window.
11:58:47  <milek7> can you check with this?
11:59:04  *** tokai has joined #openttd
11:59:04  *** ChanServ sets mode: +v tokai
11:59:15  <peter1138> Also GetUpdateRect is called on a WM_PAINT event, so by definition there is a rect to update...
12:01:33  <milek7> using WM_PAINT at all is questionable too ;p
12:01:55  <peter1138> No it's not?
12:05:59  *** tokai|noir has quit IRC
12:11:31  <milek7> from what I can tell WM_PAINT is sent when surface is invalidated
12:12:10  <milek7> there's no guarantee it will sent in a loop
12:14:42  <milek7> ah ok, it only sets dirty area
12:15:36  <andythenorth> ok lunch happened
12:15:40  <andythenorth> now coffee?
12:17:10  <milek7> but I still think it might be invalid in fullscreen
12:18:32  *** glx has joined #openttd
12:18:32  *** ChanServ sets mode: +v glx
12:22:04  <SpComb> after lunch comes... coffee, and then leaving work?
12:25:01  <glx> oh cert expired 3 days ago
12:25:02  <andythenorth> lol?
12:25:08  * andythenorth never leaves work
12:28:18  <LordAro> oop, freenode really kicking off now
12:28:39  <FLHerne> In the finest tradition of IRC networks
12:28:53  <andythenorth> switching to discord when?
12:29:04  <peter1138> We're not freenode, so...
12:29:16  <andythenorth> peter1138 if only you were on discord :P
12:29:18  <andythenorth> imagine
12:29:21  <andythenorth> we could even talk there
12:29:27  <peter1138> That would be terrible.
12:29:27  <andythenorth> with pictures
12:29:32  <andythenorth> terrible pictures
12:29:41  <peter1138> I'd do nothing but troll about chunky bevels and removing block signals...
12:29:59  <_dp_> "free" scaling usually looks like shit, you need to mind pixel borders when scaling stuff
12:30:56  <milek7> ok, it might be unrelated to wm_paint, but something is broken with dirty regions
12:31:34  *** andythenorth has quit IRC
12:32:12  <milek7>
12:33:00  <milek7> that seems to fix it
12:33:16  <milek7> though I don't know exactly *why*
12:33:50  <milek7> michi_cc:
12:59:11  <V453000> If I really wanted to improve how OpenTTD looks in the eyes of the public, hypothetically how would you go about it? Making pull requests for ogfx? Pushing directly to ogfx? Working on a different base set and one day ask to make it default? Is ogfx locked in and unacceptable to be changed?
12:59:52  <glx> udpates to ogfx are welcome :)
13:00:26  <glx> via pull requests
13:00:40  <Timberwolf> I guess it's the question of "in the style of ogfx" or, perhaps more cynically, "in the style of the best ogfx sprites"
13:01:07  <Timberwolf> There's quite a bit in OGFX which could do with some love, town buildings particularly.
13:01:14  <V453000> I'd certainly have a lot of things closer to original TTD style
13:01:43  <glx> IIRC some tunnel tiles have a missing pixel
13:02:18  <V453000> missing pixel is just a technical fix, I'm more talking about the overall quality of the visual style
13:02:59  <glx> but I usually use original graphics, I'm lost in GUI with ogfx :)
13:03:47  <peter1138> ^
13:04:17  <V453000> well, yeah, me too. But the new players generally only see opengfx, and a large part of them has no idea anything like TTD graphics is even a thing
13:05:21  <glx> many players even use zbase
13:05:27  <glx> I can't understand
13:05:43  <V453000> yeah, well that's next level
13:07:49  <V453000> The highest chance for me to actually complete anything (not soon obviously but eventually), is an alternate base set I guess, which would be what could come out of BRIX some day. There are some things in BRIX that I don't think would be accepted (like the signals), simply because it's too abstract. I'd change those I guess. I'll just keep going with that regardless, but the thought of one day having a better default graphics set than opengfx s
13:07:51  <V453000> goal
13:08:44  <V453000> Most of the upcoming new additions to BRIX will in fact probably be heavily inspired by TTD sprites, in a similar way OpenGFX is inspired by them
13:08:51  <V453000> so those should be pretty compatible
13:09:40  <V453000> but yeah, all dreams and promises :)
13:11:08  <peter1138> New players are all "more is better"
13:11:19  *** tokai|noir has joined #openttd
13:11:19  *** ChanServ sets mode: +v tokai|noir
13:11:45  <peter1138> So they find the largest 32bpp base set, try to add every single NewGRF (which are not EZ so don't mix well), and they assume that 4096x4096 is the best map size to play.
13:12:10  <V453000> :D
13:13:50  <Timberwolf> It'd be nice to have a few more basesets.
13:14:12  <LordAro> zbase & abase need properly merging
13:14:25  <LordAro> but yeah, the amount of people that use it is disappointing really
13:14:28  <Timberwolf> I notice a lot of screenshots with a lot of quite flat-shaded newgrfs, that's a style which could do with its own baseset.
13:14:40  <LordAro> aiui, zeph only ever meant for it to be a "first draft" attempt at a 32bpp base set
13:15:14  <Timberwolf> Yeah, that's what I recall - it was back when we had people spending weeks on a single house.
13:15:28  <glx> main issue with extra zoom is most newgrf don't have it
13:15:43  <glx> so the result is just ugly
13:15:48  <Timberwolf> Nobody does it consistently either.
13:16:14  <Timberwolf> z/aBase != CZTR != Timberwolf != UKRS3 != NUTS/BRIX
13:16:19  <Timberwolf> (who have I forgotten?)
13:16:24  <V453000> That's why a base set, even if it has x4 zoom, must look right even at x1, and be kind of compatible with 8bpp work
13:16:40  <V453000> I think BRIX is in the right direction in that regard, and I think that's really, really important
13:18:14  *** tokai has quit IRC
13:21:47  <V453000> has pikka said anything about UKRS3?
13:26:21  *** ioangogo has joined #openttd
13:33:32  <peter1138> Probably something about it being bad.
13:33:53  <V453000> :d
13:34:18  <DorpsGek> [OpenTTD/nml] glx22 approved pull request #208: Clean up language definitions
13:37:14  <DorpsGek> [OpenTTD/OpenTTD] lambodhar commented on issue #9281: Company Takeover Maths not correct.
13:39:08  <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #9281: Company Takeover Maths not correct.
13:43:36  <DorpsGek> [OpenTTD/OpenTTD] lambodhar commented on issue #9281: Company Takeover Maths not correct.
13:49:12  <DorpsGek> [OpenTTD/OpenTTD] lambodhar commented on issue #9281: Company Takeover Maths not correct.
13:51:36  *** nielsm has joined #openttd
13:58:13  <peter1138> So should we settle on one style of progress bar?
14:01:49  *** jottyfan has joined #openttd
14:08:24  *** sla_ro|master has joined #openttd
14:11:01  *** urdh has quit IRC
15:00:49  *** jottyfan has quit IRC
15:07:35  *** Speeder_ has joined #openttd
15:15:08  *** Speeder has quit IRC
15:23:34  *** Progman has joined #openttd
15:55:05  <Speeder_> people  here saw the freenode implosion drama?
15:55:21  <LordAro> of course
15:55:22  <Speeder_> one of the issues was seemly owner of freenode accusing freenode admins of wanting to merge with this server (OFTC)
15:55:41  <LordAro> i've not seen that one
15:56:21  <Speeder_> one of the quitting staff mentioned it
15:56:44  <Speeder_> seemly freenode was working on their own server software
15:56:47  <peter1138> Unlikely. They would probably be suggesting to use OFTC instead of libera if that was true
15:56:59  <Speeder_> freenode owner then accused them of making their own software to a llow them to merge with OFTC
15:57:10  <LordAro> regardless... so what?
15:57:17  <Speeder_> found it funny
15:57:24  <Speeder_> makes no sense
15:57:35  <Speeder_> I assume freenode owner is delusional or something
15:57:49  <Speeder_> OFTC is open source only no? would never merge with freenode.
15:57:55  <LordAro> the (now ex) staff certainly seem to think so
15:58:04  <Rubidium> so we left freenode "just" in time ;)
15:58:13  <LordAro> they're also pretty pissed about the "owner" bit of it
15:58:41  <Speeder_> I mean... how you can own stuff that is not yours?
15:58:57  <Speeder_> freenode servers belong to  various random organizations that join the network voluntarily, how you own that?
15:59:13  <LordAro> by owning (or at least having control of) the domain
16:00:10  *** andythenorth has joined #openttd
16:00:12  <andythenorth> "finally, nml might be fast" :P
16:00:25  <peter1138> Rewritten in C#?
16:00:55  <Rubidium> rewrite it in VHDL to make it really fast
16:01:13  <Rubidium> only the compile times for VHDL are probably horrendous
16:01:54  <TrueBrain> oops, seems the wiki crashed today .. "stderr: 'fatal: write error: No space left on device"
16:01:57  <TrueBrain> that isn't good ..
16:02:03  <TrueBrain> I wonder why the disk is full :P
16:02:04  <peter1138> Oops
16:02:18  <Rubidium> or the ramdisk /tmp?
16:02:33  <TrueBrain> seems nobody noticed wiki is 502'ing, but what-ever :P
16:02:36  <andythenorth> did a webcrawler come by and recursively follow 'create page'?
16:02:37  <andythenorth> :P
16:03:52  *** Wormnest has joined #openttd
16:06:25  <peter1138> Ooh, a bit of UI that changes size if chunky bevels are enabled, how rare.
16:06:57  <FLHerne> Speeder_: He's definitely delusional, I chatted with him for a while
16:07:02  <DorpsGek> [OpenTTD/team] Widor1844 opened issue #220: [et_EE] Translator access request
16:07:11  <FLHerne> Or possibly malicious in a big-lie sort of way
16:07:23  <FLHerne> Certainly none of his claims make any sense
16:07:58  <Speeder_> I can believe that
16:08:35  <TrueBrain> it seems docker logs filled up the disks .. lol .. all storage on those machines is temporary
16:08:41  <TrueBrain> but docker logs seems to not rotate
16:08:44  <TrueBrain> which is .. odd :P
16:09:05  <TrueBrain> well, the best solution, as it goes with all of these things .. just spin up new machines and kill the old
16:09:06  <andythenorth> V453000 ask Pikka in discord @davidd
16:09:08  <TrueBrain> storage issues solved!
16:09:51  <V453000> OH :)
16:10:11  <andythenorth> TrueBrain such cattle
16:11:14  <TrueBrain> might as well upgrade them while doing it .. takes a bit of time to send the new config .. :)
16:15:40  <TrueBrain> euhm .. found another issue .. for some reason a staging image was send to production .. how ... does that happen :P
16:16:19  <peter1138> Hi!
16:16:49  <TrueBrain> ah, master -> main, seems to have confused some scripts :D
16:17:59  <TrueBrain> that is also what triggered the initial "disk is full" problem, lol
16:18:03  <TrueBrain> that makes sense .. :)
16:18:22  <TrueBrain> I confused a sentry alert for "just on staging" ... didn't spot it also triggered on production
16:18:39  <TrueBrain> just 526 in the last 4 hours
16:19:12  <andythenorth> "GitHub is gradually renaming the default branch of our own repositories from master to main"
16:19:18  <andythenorth> or we could have gone with 'default'
16:19:19  <andythenorth> :P
16:19:40  * andythenorth reading articles about renaming default branches
16:20:05  <andythenorth> "default", it would be like mercurial never died :)
16:21:33  <LordAro> "trunk", clearly
16:22:30  <TrueBrain> right, reverted production back to non-staging image .. that should fix a lot of things :P
16:22:36  <Rubidium> shouldn't default link to the version people should be using by default, e.g. the last release?
16:23:42  <TrueBrain> took me way too long to spot this problem .. lol .. I should pay more attention to sentry :( Sorry :)
16:23:48  <LordAro> perl5 uses "blead"
16:23:53  <TrueBrain> but our wiki is back :)
16:24:06  *** andythenorth has left #openttd
16:24:51  <TrueBrain> and while at it, all services will cycle now to remove the old EC2 instances :)
16:25:28  <TrueBrain>
16:25:36  <TrueBrain> picture or it didn't happen :P
16:26:02  *** DorpsGek has quit IRC
16:26:22  *** DorpsGek has joined #openttd
16:26:22  *** ChanServ sets mode: +o DorpsGek
16:26:57  <TrueBrain> at least, found the first issue with renaming "master" to "main" :)
16:28:06  <TrueBrain> well, everything is happily doing its job again .. going to close this incident now, tnx Sentry, sorry for not paying sufficient attention to you :)
16:46:05  *** gelignite has joined #openttd
16:47:11  *** tokai has joined #openttd
16:47:11  *** ChanServ sets mode: +v tokai
16:54:06  *** tokai|noir has quit IRC
16:58:04  *** Wolf01 has joined #openttd
17:00:29  *** urdh has joined #openttd
17:04:08  <Speeder_> <<< link to whre I saw OFTC mentioned
17:05:07  <Speeder_> I wonder what happens if you rename main back to master
17:11:57  *** urdh_ has joined #openttd
17:16:46  *** urdh has quit IRC
17:16:46  *** urdh_ is now known as urdh
17:23:24  *** andythenorth has joined #openttd
17:34:03  * peter1138 gives up with docker for now
17:34:25  <peter1138> Speeder_, it's illegal
17:40:18  <Speeder_> as in... github doesn't allow, at all, projects with master as the master branch?
17:40:51  <peter1138> It's illegal.
17:40:59  <TrueBrain> punishable by law, not?
17:41:04  <peter1138> Yes
17:41:12  <TrueBrain> makes sense
17:41:25  <andythenorth> frigging cookies ruining my evening
17:41:28  <andythenorth> I hate the internet
17:42:05  <TrueBrain> switch to cakes?
17:43:37  <peter1138> Switch to Yorkie bars.
17:43:41  <peter1138> Cos they're ... chunky
17:43:54  <andythenorth> trying to figure out why Vimeo is setting a cookie
17:44:01  <andythenorth> why do I have to waste my life on this shit?
17:44:36  <TrueBrain> I think andythenorth is in need of a hug!
17:44:41  <andythenorth> not allowed
17:44:45  <Speeder_> how it would be punishable by law?
17:44:51  <andythenorth> I have gone from an 8.5/10 to a 3/10 right now
17:45:06  <Speeder_> whose laws in first place?
17:49:50  <andythenorth> now at 2/10
17:50:32  <peter1138> THE law.
17:50:44  <andythenorth> 1.5/10
17:50:52  <andythenorth> vimeo just logged me out because I cleared the cookies
17:50:56  <andythenorth> to see what cookies it sets
17:51:48  <peter1138> I should stop being a lazy bum and go out on my bicycle. But I'm a lazy bum, so...
17:52:14  <TrueBrain> GraphQL is difficult, bah
17:53:54  <V453000> the what XD all of my projects have master as main branch, it was the default and some of the repositories I started pretty recently so it's still the default or it had to change really recently
17:54:01  <V453000> so punishable by law my ass
17:54:08  <V453000> also, that's stupid
17:54:27  <V453000> whitelist/blacklist, fine, but master is just an exaggerration
17:55:35  <TrueBrain> "really recently" depends on your frame of reference ;) But:
17:55:40  <TrueBrain> and I think you forgot your chillpill there :)
17:55:53  <andythenorth> it's just words, and if words cause trouble, change the words
17:56:08  <V453000> I maybe haven't started a repository after oct 2020 :)
17:56:19  <TrueBrain> as I said, it depends on your frame of reference :)
17:56:25  <V453000> yeah :)
17:56:28  <TrueBrain> "really recently" for you could be 4 years ago
17:56:32  <TrueBrain> for me it would be last week :P
17:56:37  <V453000> sure
17:56:40  <TrueBrain> :D
17:56:45  <andythenorth> ok I am now at 5/10 I found the dnt=1 param for vimeo
17:56:52  <andythenorth> fucker is still setting a cookie sometimes I think
17:57:05  <andythenorth> why is there no option for "I pay you for a business account, so just comply with the fucking law"
17:57:25  <andythenorth> are there spare chillpills?
17:57:31  <andythenorth> or does V453000 need them all?
17:57:47  <V453000> I don't have anything against main, in fact I think it's better. But making it punishable by law to force people to rename their branches, is just downright too much.
17:57:52  <TrueBrain> not sure; he might just need to fix his sarcasm detector .. dunno :P
17:58:24  <TrueBrain> owh V453000 .... please don't believe everything you read in a chat channel :)
17:58:29  <TrueBrain> bad for your blood pressure :)
17:58:36  *** frosch123 has joined #openttd
17:58:41  <V453000> blood is still frozen, but ok XD
17:58:49  <V453000> XD
17:58:54  <V453000> I will see myself out
17:58:59  <TrueBrain> nah, stay :)
17:59:23  <V453000> to obey or not when the master said to not believe everything I read in chat
17:59:26  <V453000> is the question
17:59:50  *** Flygon has quit IRC
17:59:53  <TrueBrain> but just for the record, you just experienced a wooosh moment :)
18:00:06  <V453000> woosh?
18:00:18  <TrueBrain> you don't do reddit? Awh :)
18:00:35  <V453000> only factorio reddit, which I gather is far from "the full experience"
18:00:51  <TrueBrain> there is a subreddit with all kind of posts with people who missed a punchline
18:00:55  <TrueBrain> and continued as if it was serious
18:01:04  <V453000> aha
18:01:27  <TrueBrain> like can you imagine a law defining how git branch names have to be called? That would be absolutely epic :)
18:02:06  <V453000> I can 100% imagine that, with the pace at which world is going
18:02:38  <TrueBrain> I would love to see that law pass all the countries in the world
18:02:43  <TrueBrain> in fact, I would pay to sit in those meetings :D
18:02:47  <TrueBrain> "wtf is git?"
18:02:53  <TrueBrain> and someone explaining it
18:02:54  <TrueBrain> LOL
18:02:55  <TrueBrain> just imagine :D
18:03:00  <V453000> well, github for instance is probably not an international company :)
18:03:05  <V453000> you only need 1 country
18:03:22  <TrueBrain> fine, I would like to see this being handled in the Senate of the US
18:03:37  <TrueBrain> someone explaining git to nitwits, that would just be awesome
18:03:44  <V453000> I don't think they'd need to care
18:03:57  <TrueBrain> I mostly think you are overthinking this :)
18:03:58  <V453000> "word X is being used, pass law"
18:04:15  <V453000> Probably yes, but also I'd not be surprised if not so much
18:04:46  <TrueBrain> "From this day forth, nobody shall use the word 'master' in any context"
18:04:58  <TrueBrain> a true masterpiece
18:05:00  <V453000> totally wouldn't be surprised :)
18:06:06  <milek7> wouldn't fly with 1st amendment, probably
18:08:03  <TrueBrain> hmm .. can you use the result of a GraphQL inside the query itself
18:08:04  <TrueBrain> hmm
18:11:24  <andythenorth> why is Vimeo's iframe trying to access my page?
18:11:42  <andythenorth> triggers some same-origin blocker
18:11:48  <andythenorth> the internet really is fucked
18:11:52  <andythenorth> let's make games instead
18:16:41  <Rubidium> TrueBrain: should be about at the level of the Senate of the US I think ;)
18:18:12  <andythenorth> seems vimeo closed the same origin issue as "cannot happen, fix your website"
18:18:13  <michi_cc> TrueBrain: OpenGL should not randomly update the drawing texture from our buffer, except of course if the driver borkes on the glClientWaitSync for persistent buffers (or is otherwise lying when it says it can do coherent persistent mapping).
18:18:15  <andythenorth> gr8
18:18:20  <TrueBrain> awh, you need to be identified for GraphQL endpoint, meh
18:18:34  <michi_cc> TrueBrain: And yes, GL sync options are one time deals, which is why they are deleted and a new one created.
18:18:45  <michi_cc> s/options/objects/
18:18:51  <TrueBrain> michi_cc: lolz .. I expected another design there :D
18:20:01  <michi_cc> A sync object is literally a token that is put into the GPU command stream by which the driver can see when the command stream is done up to that point. Reusing tokens would have all kinds of funny issues to deal with.
18:20:23  <andythenorth> why the fuck is vimeo trying to get out of the iframe?
18:20:31  * andythenorth may be in the wrong channel here :)
18:20:39  <TrueBrain> michi_cc: ah, well, that is clever
18:20:53  <TrueBrain> the naming is a bit confusion, but knowing that, that makes sense :)
18:22:23  <andythenorth> hmm maybe it's because vimeo is restricted to only allow embedding on specific domains
18:22:42  <andythenorth> maybe it needs to access the parent frame headers for that
18:22:44  <TrueBrain> andythenorth: let's be real .. we are all in the wrong channel here :)
18:22:52  <TrueBrain> but, at least we are  not on freenode :P
18:22:59  <andythenorth> I worry there is no 'correct' channel for me :P
18:23:06  <andythenorth> still 3/10 on 'am I ok' here
18:23:24  <andythenorth> I would be 8/10 if I could put down this internet shit and draw boats
18:23:45  <Timberwolf> Well yes. It turns out that's universally difficult (sample size n = 2)
18:24:32  <Timberwolf> Actually the main problem now is I messed with the renderer and what should be a simple job of running the other sets through it has turned into me being ANNOYED BY EVERYTHING and needing to fix it.
18:25:05  <TrueBrain> michi_cc: the thing I can imagine what goes wrong from what peter1138 is seeing, is this line:
18:25:06  <TrueBrain>
18:25:11  <andythenorth> issue only manifests in Safari so far
18:25:13  <TrueBrain> it is only called when update_rect is not empty
18:25:15  <TrueBrain> which SHOULD be true
18:25:20  <andythenorth> maybe I file it under 'not my problem' for tonight
18:25:24  <TrueBrain> but I can imagine not all our drawing code is "correct"
18:25:31  <TrueBrain> and some might draw in the video buffer despite not updating the drawing rect
18:25:38  <TrueBrain> normally this should not result in an update to the screen, ofc
18:25:45  <TrueBrain> and as such, goes completely unnoticed
18:25:46  <V453000> update_rectal ... you are taking that FIRS fork seriously after all
18:25:51  <TrueBrain> but .. it might be what he is seeing?
18:27:21  <frosch123> V453000: about ogfx: i guess everyone would welcome better gui sprites. however terrain sprites and other essential landscape sprites are in-style with ogfx+landscape and other newgrf. so if you want to change these style-defining sprites, better make a separate vBase :)
18:27:41  <andythenorth> Timberwolf boat sprites or it's not proven
18:27:47  <TrueBrain> in that case moving the statement out of the IsEmptyRect should fix the issue peter1138
18:28:07  <frosch123> V453000: also, if you do gui sprites, also do them in 2x or even 4x zoom :p
18:28:09  *** gelignite has quit IRC
18:28:42  <michi_cc> TrueBrain: No, I don't think that is the issue. The OpenGL pixel flow is like this: buffer object -> texture -> back buffer. Each step is a separate memory buffer. The buffer object is always the same as OTTD only redraws changes, no matter if mapped persistently once or each frame.
18:29:07  <TrueBrain> michi_cc: you only do the sync-stuff when the dirty-rect was not empty
18:29:13  <TrueBrain> but what if we change pixels
18:29:19  <TrueBrain> and still say the dirty-rect is empty?
18:29:33  <michi_cc> TrueBrain: The buffer to texture upload only happens then the update_rect is not empty. If we don't call _glTexSubImage2D, the texture that is drawn to the back buffer is not modified at all.
18:29:45  *** Strom has joined #openttd
18:29:45  <milek7> I posted before
18:29:52  <milek7>
18:30:10  <milek7> this solve the issue for me, but I'm not sure why
18:30:35  <TrueBrain> michi_cc: to be clear, I know little about OpenGL, so I am just speculating: GetVideoBuffer() always returns the same pointer, if I understand you correctly, with persistent buffering, right?
18:30:44  * andythenorth gives up on trying to make the internet work
18:30:58  <michi_cc> milek7: If that solves the issue, something in the driver is not synchronizing correctly.
18:31:01  <TrueBrain> so if the flow is like this: GetVideoBuffer -> we change the buffer but don't mention dirty-rect is changed -> ReleaseVideoBuffer
18:31:07  <TrueBrain> what does the GPU do?
18:31:27  <michi_cc> The GL sync protectects to _glTexSubImage2D call, if we don't call _glTexSubImage2D, there is nothing to sync with.
18:31:32  <milek7> TrueBrain: it will draw old frame
18:31:47  <michi_cc> Still draw the texture that was not updated by OTTD.
18:31:49  <TrueBrain> michi_cc: so the GPU doesn't do anything with the buffer until TexSubImage2D is called?
18:32:01  <TrueBrain> it isn't trying to do smart tricks or anything there?
18:32:43  <TrueBrain> (sorry, I am a total noob with modern OpenGL .. I once fiddled with it in the 2000s, so this might be stupid questions :P)
18:32:50  <michi_cc> TrueBrain: Yes, the rendering call will draw the *texture* to the screen. _glTexSubImage2D will update the texture from our buffer object which is where the blitter paints to.
18:33:23  <TrueBrain> my simplistic mind would think: the GPU gave us a buffer to draw in, and if you draw the texture, it just reuses that buffer as you shouldn't be touching it anyway
18:33:34  <TrueBrain> optimizations and shit :D
18:33:40  <TrueBrain> okay, tnx michi_cc :)
18:33:47  <michi_cc> TrueBrain: Id the driver is doing dirty tricks, it would be out-of-spec. It's not impossible, 10 FPS more in Fortnite will generally be much more important than being completely in spec.
18:34:29  <TrueBrain> well, if milek7's patch fixes peter1138's problem, it does give the illusion of this
18:34:39  <TrueBrain> I cannot help to see his problem as a double-buffer-not-working :P
18:34:43  <TrueBrain> but I might be stuck on that idea :D
18:35:12  <TrueBrain> either way, it would lean on the notion we change the buffer without changing the dirty rect
18:35:13  <milek7> well it solves my glitching problem, not sure if peter is the same thing or another one
18:35:15  <TrueBrain> which would be wrong anyway
18:37:58  <TrueBrain> guess it would be easy to test the hypothesis, by just trashing the buffer and not doing any _glTexSubImage2D
18:38:01  <TrueBrain> that should have zero impact
18:39:50  <peter1138> It definitely feels like the pixel buffer is being updated while it's being drawn.
18:42:00  <TrueBrain> <- I would say, add an "} else { memset(this->vid_buffer, 0, 1000); }" or something
18:42:15  <peter1138> milek7's change actually makes things far worse for me.
18:42:28  <TrueBrain> worse? Now that is even more interesting :D
18:43:36  <TrueBrain> I knew OpenGL was a bit of a mess with drivers etc .. never in my life I expected it to be this much of a mess :D
18:45:25  <TrueBrain> peter1138: how much Hz are your screens?
18:45:30  <michi_cc> Any real game engine (be it Unity, Unreal Engine or whatever) will have a significant list of GPU/driver/version specific alternate rendering paths (and not just for OpenGL, for D3D as well).
18:45:31  <peter1138> 60
18:45:36  <TrueBrain> @calc 1000 / 60
18:45:36  <DorpsGek> TrueBrain: 16.666666666666668
18:45:52  <peter1138> Also this goes away with threading disabled.
18:45:52  <TrueBrain> peter1138: what happens if you change the 10000000 to twice that value?
18:46:07  *** HerzogDeXtEr has quit IRC
18:46:53  <peter1138> What is this magic number?
18:46:57  <TrueBrain> timeout
18:46:58  <milek7> oh..
18:46:59  <TrueBrain> at 10msec atm
18:47:02  <peter1138> I've not tried the memset either.
18:47:07  <TrueBrain> nah, forget the memset
18:47:09  <TrueBrain> it is stupid
18:48:36  <milek7> yeah, 10ms is far too low
18:48:59  <TrueBrain> no need in jumping any gun; it might just be perfectly fine :)
18:49:19  <TrueBrain> only if vsync influences the time it takes to be done with the buffer, it matters, I would guess
18:50:31  <peter1138> Seems to improve it.
18:50:37  <TrueBrain> improve, or fix?
18:50:47  <michi_cc> Might be possible depending on how the driver implements the buffer swapping. It's probably only now an issue that we have the separate game thread, when OpenGL was initially only single threaded, it was very unlikely to hit.
18:51:05  <TrueBrain> michi_cc: yeah, it really feels like a timing issue
18:51:22  <michi_cc> peter1138: You would need to change L1177 as well, and just crank it up even more.
18:51:40  <TrueBrain> and we never assumes enabling vsync was something we would allow
18:51:51  <TrueBrain> (as it initial was a "expert" option only :P)
18:51:59  <TrueBrain> but vsync is weird, I have noticed
18:52:06  <TrueBrain> and totally messes up draw-ticks :D
18:52:08  <michi_cc> Timeout is a bit what is worse: any kind of graphical glitch or game stutter.
18:52:37  <TrueBrain> now I think about it .. with vsync enabled, maybe we shouldn't have draw-ticks, but just let the GPU pump the draw-thread
18:53:36  <TrueBrain> would mean adaptive stuff also starts to work
18:53:46  <TrueBrain> (G-Sync / FreeSync)
18:54:05  <peter1138> Running at 4x DSR and it's not instantly glitching, so...
18:54:16  <peter1138> 5120x2880
18:54:35  <TrueBrain> yeah, okay, so vsync means in your case it blocks on the wait-for-sync command, I would speculate
18:54:48  <TrueBrain> you could TICC/TOCC it to confirm, I would guess
18:55:13  <peter1138> Isn't that the point of vsync? :D
18:55:14  <TrueBrain> michi_cc: maybe the value should be 1000 / refresh_rate?
18:55:27  <TrueBrain> peter1138: fair point
18:55:33  <TrueBrain> never really looked into what blocked, honestly
18:55:36  <V453000> frosch123: does that essentially mean that OpenGFX is The base set for OpenTTD, and it should preferably stay that way?
18:55:46  <milek7> vsync can block on any gl call
18:56:22  <TrueBrain> michi_cc: well, maybe twice the refresh-rate
18:56:49  <michi_cc> TrueBrain: Just make it 100000000, if that timeout actually hits, the GPU is useless anyway :)
18:57:00  <peter1138> V453000, not for me, I never use any of the OGFX+ stuff so don't see any relevance.
18:57:12  <peter1138> michi_cc, 2080ti ;)
18:57:17  <frosch123> V453000: i don't consider it "the" baseset. it's "a" baseset, with a style.
18:57:22  <V453000> sure
18:57:26  <michi_cc> Oh, and for G-Sync/FreeSync, you are usually supposed to have vsync *disabled*.
18:57:35  <frosch123> some years ago, someone tried to turn ogfx+trains into an entirely different 32bpp trainset
18:57:46  <TrueBrain> michi_cc: fair point; it is meant the other way around
18:57:47  <frosch123> V453000: most newbies use zbase, don't they?
18:57:50  *** felix has quit IRC
18:57:52  <TrueBrain> if we are slow, displays adept
18:57:53  <michi_cc> peter1138: Yeah, but if the texture upload takes 100ms, something is misusing the GPU.
18:57:58  <V453000> I'm just asking, I don't have anything right now, as you well know :) but the idea of making the official versions of OpenTTD look better, would be a great goal for me to one day perhaps achieve
18:58:00  <frosch123> even beginner tutorials explain how to install zbase as the first thing
18:58:02  *** felix has joined #openttd
18:58:11  <V453000> wow, really?
18:58:14  <TrueBrain> anyway, guess we isolated the problem at least :P
18:58:19  <V453000> I'd expect OpenGFX would still be the vast majority
18:58:24  <peter1138> michi_cc, yeah, I guess Linus and his 16K video wall is misusing it :D
18:58:38  <TrueBrain> V453000: it is auto-installed on Steam install :P
18:58:56  <peter1138> V453000, as i said... 32bpp EZ everything, 4096x4096 maps... sheesh
18:58:58  <V453000> zbase is auto installed?
18:58:59  <V453000> holy shit
18:59:04  <TrueBrain> no, OpenGFX
18:59:06  <V453000> right
18:59:11  <V453000> that's what I assumed
18:59:18  <TrueBrain> sorry :P I should be more specific in those sentences :D
18:59:22  <milek7> michi_cc: it's not the texture upload, but vsync that can block anywhere
18:59:27  <V453000> I just didn't understand your sarcasm, is all
18:59:30  <V453000> G_G
18:59:32  <peter1138> I wonder if this timing issue is what caused that black-bars issue.
18:59:39  <TrueBrain> V453000: you just have been away too long :P
18:59:58  <V453000> I don't think I have anything to say against that :)
19:00:01  <TrueBrain> but auto-installing zBase is not a bad idea honestly
19:00:02  <frosch123> V453000: <- from the most active openttd-let's player
19:00:07  <TrueBrain> if someone can merge abase/zbase, that is worth a talk
19:00:10  <V453000> it's a horrible idea TrueBrain
19:00:18  <TrueBrain> it saves us a lot of bandwidth :P :P
19:00:45  <TrueBrain> btw, installing it next to OpenGFX, I meant
19:00:50  <TrueBrain> so people can select zBase after Steam install
19:00:51  <frosch123> V453000: so anyway, if you want a baseset with an entire different look, then make a separate baseset. it can still become the pre-installed baseset
19:00:58  <frosch123> esp. since truebrain wants to bundle a tramset anway
19:01:00  <peter1138> Okay, possibly the initial glitch I saw with it doubled was ... when switching to 5120x2880 fullscreen, every other window on the system gets shuffled and moved about, and that can take time.
19:01:05  <TrueBrain> frosch123: YES! TRAMSET!
19:01:25  <peter1138> V453000, make a good version and have that the default ;)
19:01:33  <andythenorth> TrueBrain I like how it saves the bandwidth
19:01:37  <V453000> frosch123: yeah, I believe that is the reasonable way to go about it
19:01:40  <andythenorth> by downloading it with the client :P
19:01:45  <andythenorth> Steam pays? o_O
19:01:46  <TrueBrain> V453000: if you can fix rivers to show when they go uphill/downhill, I will use your set, no matter what :P
19:01:53  <V453000> I basically just wanted to hear what's the general thoughts you guys have on this
19:01:56  <TrueBrain> for context
19:01:59  <andythenorth> just make a river grf TrueBrain
19:01:59  <V453000> haha
19:02:07  <andythenorth> game is moddable in content
19:02:09  <TrueBrain> it is really bad in OpenGFX :(
19:02:23  <frosch123> water cycle has no shades :)
19:02:33  <V453000> I will use that sentence against you one day TrueBrain
19:02:36  <frosch123> so it's difficult to make give the slopes different shades
19:02:45  <TrueBrain> V453000: deal :)
19:02:54  <andythenorth> frosch123 there are spare palette entries :P
19:03:12  <andythenorth> 32bpp conversion, 512 colour default palette
19:03:33  <TrueBrain> frosch123: <- it is a "solved" problem :P
19:03:35  <TrueBrain> just not in OpenGFX :D
19:03:36  <andythenorth> also 8 company colours
19:08:14  <V453000> well, ETA 2030
19:08:16  <V453000> XD
19:09:28  <TrueBrain> when was OpenGFX created? :P
19:09:31  <TrueBrain> 2007?
19:09:36  <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
19:09:37  <DorpsGek>   - Update: Translations from eints (by translators)
19:09:37  <TrueBrain> so that is before it doubles in age
19:11:07  <V453000> it's been fucking 14 years?!
19:11:10  <V453000> omg
19:11:11  <V453000> XD
19:11:29  <TrueBrain> yeah ... it is a harsh realisation, I know :P
19:11:35  <TrueBrain> but I honestly don't know when OpenGFX was created
19:11:37  <TrueBrain> I just guessed
19:13:29  <peter1138> There's a thread from 2008 at least
19:13:39  <TrueBrain> release(tagName: \\"1.2.2\\") { \
19:13:42  <TrueBrain> I hear you like escaping
19:14:01  <peter1138> That means OpenGFX is older than TTD was when OpenTTD was started.
19:15:18  <V453000> by quite a bit it sounds like
19:15:53  <peter1138> " I'm really amazed how good it looks, but I have to admit, there is that problem I have: it' way too dark. It felt as if it was right before night comes in."
19:16:10  <peter1138> Belugas' comment on the first page. Yes, yes it is.
19:20:24  <Wolf01> Wow, it's a V!
19:30:27  <peter1138> TrueBrain, michi_cc, milek7, yeah, increasing that timeout does fix it.
19:31:00  <TrueBrain> okay, so it is a double-buffer violation of sorts after all \o/ :D
19:32:28  <Timberwolf> Now tempted to play that "what was OpenGFX's current age when OpenGFX was started" game.
19:32:39  <Timberwolf> Looks like, of all things... Transport Tycoon Deluxe.
19:33:40  <peter1138> About that, yes.
19:38:08  <peter1138> Gods I really don't like OpenGFX :/
19:39:47  <andythenorth> some do, some don't :)
19:40:02  <peter1138> It's miles better than [az]Base though.
19:41:49  <peter1138> Also weird, it has 2x GUI sprites for normal rail but not electric rail.
19:42:06  <peter1138> Oh, except autorail.
19:43:36  <DorpsGek> [OpenTTD/OpenTTD] michicc opened pull request #9282: Fix: [OpenGL] Increase timeout when waiting for the GPU to be done with the drawing buffer.
19:43:50  <michi_cc> TrueBrain: Feel free to make some "intelligent" wait timeout if you want :D
19:44:20  <peter1138> Maybe I should test zBase with chunky bevels.
19:44:24  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9282: Fix: [OpenGL] Increase timeout when waiting for the GPU to be done with the drawing buffer.
19:44:33  <TrueBrain> michi_cc: meh; #care
19:45:05  <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #9282: Fix: [OpenGL] Increase timeout when waiting for the GPU to be done with the drawing buffer.
19:45:22  <peter1138> I don't think it needs to be clever. Is it possible to have no timeout at all?
19:45:38  <TrueBrain> michi_cc: I did like the comment; just still made me count zeros :P
19:45:45  <peter1138> Like, if times out waiting for a sync, what is meant to happen?
19:45:53  <TrueBrain> BOOM!
19:46:01  <TrueBrain> you could check the result value, and see if the timeout did hit btw
19:46:04  <michi_cc> Well, some timeout means you can at least exit normally instead of via task manager if the driver fucks up.
19:46:18  <michi_cc> Also, a single glitched frame isn't the end of the world.
19:48:19  <TrueBrain> indeed
19:49:32  <peter1138> abase vehicle sprites are way too big.
19:50:03  *** Strom has quit IRC
19:50:45  *** Strom has joined #openttd
19:59:02  <TrueBrain> Been experimenting with generating changelogs based on Pull Requests of the commits between the last tag and the new release:
19:59:28  <TrueBrain> so the title of the Pull Request is what is added to the changelog
19:59:44  <TrueBrain> GitHub allows reverse lookup of commit to Pull Request
20:00:53  <TrueBrain> means we wouldn't have to manually create changelogs :P
20:01:04  <TrueBrain> you can mark with labels when PRs should not be mentioned in changelogs and everything
20:07:06  <TrueBrain> (got a bit annoyed of having to do this myself :P)
20:10:31  <frosch123> no editing on mobile devices :)
20:13:14  <TrueBrain> haven't tested honestly :P
20:13:19  <TrueBrain> but fair, I should change the PR title to fix that :D
20:13:31  <TrueBrain> so much easier, decoupling commit messages from what an user sees
20:14:07  <frosch123> haha, so tuning the changelog is then done by editing PR titles long after merge? :p
20:14:36  <TrueBrain> hopefully of course it is done during the merge, but yes, there are those that need better wording :)
20:14:54  <TrueBrain> ugh, I struggle with the "mobile support"
20:14:59  <TrueBrain> it is not like TrueWiki can run on a mobile
20:15:05  <TrueBrain> but you can use the website better on mobile
20:15:10  <frosch123> anyway, i assumed that editing on mobile makes no sense, so the mobile layout would not bother special-casing it.
20:15:44  <frosch123> i just found the wording funny: it said what did do, and then kind of obviously left out what it did not do
20:15:56  <TrueBrain> "Add: Better layout on mobile devices"
20:15:58  <TrueBrain> seems to be better :P
20:16:06  <TrueBrain> as it did .. somewhat work before :P
20:20:31  *** jottyfan has joined #openttd
20:21:09  *** Tulitoma1tti is now known as Tulitomaatti
20:23:03  *** HerzogDeXtEr has joined #openttd
20:44:16  <TrueBrain> right, lets see how much I like generating changelogs based on pull-requests :P
20:44:37  <TrueBrain> feels like it changes doing all the work at once to doing small bits of work often while merging
20:44:42  <TrueBrain> +vs
20:45:18  <TrueBrain> so, tomorrow I fix some common code we have for GitHub Actions to understand "main" as staging too
20:45:30  <TrueBrain> and move some common code we have to that repo, so we are not copy/pasting as much as we do now
20:46:58  <TrueBrain> (Read: commit-checker and annotation-checker)
20:54:43  *** tokai|noir has joined #openttd
20:54:43  *** ChanServ sets mode: +v tokai|noir
20:56:24  *** Samu has quit IRC
21:01:31  *** tokai has quit IRC
21:06:50  <glx> [22:47:01] <TrueBrain> (Read: commit-checker and annotation-checker) <-- oh right this can go in a composite action I guess
21:16:37  <TrueBrain> Yeah, but I was more thinking about a simple normal action, like the set we already have
21:17:15  <glx> commit checker can be a composite I think, but annotation check needs more
21:17:29  <glx> with the different API calls
21:19:28  *** Wolf01 has quit IRC
21:20:32  <TrueBrain> We already have the NodeJS framework for it
21:20:53  <TrueBrain> I will fiddle a bit with it tomorrow
21:21:59  <TrueBrain>
21:22:22  *** frosch123 has quit IRC
21:22:51  <glx> yes octokit/request-action used in workflow can be replace by octokits in the action itself
21:23:48  <andythenorth> glad I'm not on the chromium project
21:24:09  <andythenorth> hunting around for performance issues that allegedly happen when your binary is installed but not running
21:25:32  *** iSoSyS has joined #openttd
21:26:58  *** nielsm has quit IRC
21:44:59  *** andythenorth has quit IRC
21:55:24  *** sla_ro|master has quit IRC
22:20:33  *** Beerbelott has joined #openttd
22:24:19  *** Progman has quit IRC
22:48:12  *** tokai has joined #openttd
22:48:12  *** ChanServ sets mode: +v tokai
22:55:04  *** tokai|noir has quit IRC
22:58:06  *** tokai|noir has joined #openttd
22:58:06  *** ChanServ sets mode: +v tokai|noir
23:05:04  *** tokai has quit IRC
23:29:00  *** iSoSyS has quit IRC

Powered by YARRSTE version: svn-trunk