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. https://git.io/JsVIj 06:10:26 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #9281: Company Takeover Maths not correct. https://git.io/JsVIj 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> https://user-images.githubusercontent.com/639850/118779694-371ff580-b883-11eb-92be-719dc2d7fc01.png 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> https://www.youtube.com/watch?v=Toft6fMvByA 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, https://i.imgur.com/AO0hw10.jpg (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> https://www.facebook.com/jorg.sand/posts/10223213180985355 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> https://github.com/OpenTTD/OpenTTD/blob/master/src/widget.cpp#L277 <- 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> https://github.com/OpenTTD/OpenTTD/blob/master/src/video/video_driver.cpp#L155 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 https://github.com/OpenTTD/OpenTTD/commit/20762f9117c8dfbc5cc72771926563b4893592c0 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> https://milek7.pl/.stuff/ottdglitch.mp4 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> https://gist.github.com/Milek7/59264f56d96e5ac4b29c972e7b7ba4ec 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 openttdoop.org 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> https://gist.github.com/Milek7/07fff2b2760c5f42ce21f297261bbe6e 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 https://git.io/Jsw2I 13:37:14 <DorpsGek> [OpenTTD/OpenTTD] lambodhar commented on issue #9281: Company Takeover Maths not correct. https://git.io/JsVIj 13:39:08 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #9281: Company Takeover Maths not correct. https://git.io/JsVIj 13:43:36 <DorpsGek> [OpenTTD/OpenTTD] lambodhar commented on issue #9281: Company Takeover Maths not correct. https://git.io/JsVIj 13:49:12 <DorpsGek> [OpenTTD/OpenTTD] lambodhar commented on issue #9281: Company Takeover Maths not correct. https://git.io/JsVIj 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 freenode.net domain 16:00:10 *** andythenorth has joined #openttd 16:00:12 <andythenorth> "finally, nml might be fast" :P https://www.theregister.com/2021/05/19/faster_python_mark_shannon_author/ 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 https://git.io/JsrUq 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> https://user-images.githubusercontent.com/1663690/118848991-9146a800-b8cf-11eb-8d6e-5d2fe8d0fc7e.png 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_> https://gist.github.com/aaronmdjones/1a9a93ded5b7d162c3f58bdd66b8f491 <<< 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: https://github.blog/changelog/2020-10-01-the-default-branch-for-newly-created-repositories-is-now-main/ 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:48 <V453000> ITS SUPPOSED TO BE A DISCUSSION 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:28 <TrueBrain> REMOVE IT FROM THE DICTONARY 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: https://www.youtube.com/watch?v=5Q7omG_9RkI 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> https://github.com/OpenTTD/OpenTTD/blob/master/src/video/opengl.cpp#L1228 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> https://gist.github.com/Milek7/07fff2b2760c5f42ce21f297261bbe6e 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> https://github.com/OpenTTD/OpenTTD/blob/master/src/video/opengl.cpp#L1230 <- 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 https://github.com/OpenTTD/OpenTTD/blob/master/src/video/opengl.cpp#L1153 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: https://www.youtube.com/watch?v=CMXFMjZu8j8 <- 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> https://github.com/OpenTTD/OpenTTD/issues/9031 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: https://user-images.githubusercontent.com/1734660/114570432-1ce86b80-9c76-11eb-95e9-a1f36174ec6d.png <- 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 https://git.io/Jsr6w 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. https://git.io/JsrDx 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. https://git.io/JsryL 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. https://git.io/JsryZ 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: https://gist.github.com/TrueBrain/836ea1549214fc87fe822cb4b40077af 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> https://github.com/OpenTTD/actions 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 https://bugs.chromium.org/p/chromium/issues/detail?id=1158402 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