Times are UTC Toggle Colours
00:10:40 *** Wolf01 has quit IRC 00:15:01 *** Pikka has joined #openttd 00:55:54 *** snail_UES_ has quit IRC 01:03:04 *** nielsm has quit IRC 01:37:07 *** m1cr0man has quit IRC 01:53:17 *** Progman has quit IRC 03:11:41 *** Wormnest has joined #openttd 03:24:46 *** Wormnest has quit IRC 03:58:14 *** debdog has joined #openttd 04:01:37 *** D-HUND has quit IRC 04:19:54 *** glx has quit IRC 05:01:14 *** tokai has joined #openttd 05:01:14 *** ChanServ sets mode: +v tokai 05:08:04 *** tokai|noir has quit IRC 07:02:19 <DorpsGek_III> [OpenTTD/OpenTTD] telk5093 updated pull request #7817: Feature: Minimap screenshot https://git.io/JegRL 07:18:37 <DorpsGek_III> [OpenTTD/OpenTTD] telk5093 commented on pull request #7817: Feature: Minimap screenshot https://git.io/Jep4z 08:05:42 *** Pikka has quit IRC 08:07:42 *** Progman has joined #openttd 08:08:53 *** andythenorth has joined #openttd 08:10:26 <andythenorth> o/ 08:11:56 *** Pikka has joined #openttd 08:12:15 <andythenorth> zounds 08:15:31 <andythenorth> Pikka: o/ 08:15:38 <Pikka> o/ 08:17:00 <andythenorth> I did a Deltic 08:17:04 <andythenorth> Horse Now Complete 08:17:05 <andythenorth> https://dev.openttdcoop.org/attachments/download/9593/deltic.png 08:17:35 <Pikka> oh dear 08:17:42 <Pikka> such teldic 08:18:33 <andythenorth> I had to delete my express EMUs though :( 08:19:11 <Pikka> why? 08:20:34 <andythenorth> https://dev.openttdcoop.org/attachments/download/9591/sunshine-coast.png 08:20:46 <andythenorth> 'balancing' 08:20:56 <andythenorth> because OpenTTD is a very balanced game 08:21:02 <Pikka> it is 08:21:27 <andythenorth> there are about 3 reasons, including 'really, enough trains' 08:21:37 <Pikka> that's a good reason I guess 08:21:41 <andythenorth> but the main problem is 'how fast should the mail EMU go?' :P 08:21:52 <andythenorth> and I can't be arsed to decide 08:22:09 <Pikka> hmmm 08:22:19 <andythenorth> currently goes at freight train speed 08:22:35 <andythenorth> unless attached to a fast engine, then it goes faster 08:22:48 <Pikka> I made all my MUs refittable to mail, so... passenger speed I guess :) 08:25:02 <andythenorth> let's see https://en.wikipedia.org/wiki/British_Rail_Class_325 08:25:21 <andythenorth> RL 100mph, Horse 87mph 08:25:39 <andythenorth> usually it's power creep, not a malus :) 08:26:48 *** sla_ro|master has joined #openttd 08:31:31 <andythenorth> oo NARS sprites :) 08:32:51 <andythenorth> GG1-Deltic! 08:33:59 <Pikka> yep, not sure if they're useful or in the right style, but they exist, so... :) 08:34:10 <andythenorth> super helpful actually 08:34:20 <andythenorth> I have an irrational fear of drawing steam engines 08:34:36 <andythenorth> there's enough there to re-use if that's ok 08:34:57 <andythenorth> I don't reshade <-> 08:35:01 <andythenorth> stopped a long time ago 08:35:08 <Pikka> cool beans :) 08:35:08 <andythenorth> Simon Foster didn't either 08:35:15 <andythenorth> I reshade \ / 08:35:25 <andythenorth> but only by paint bucket 08:56:54 *** Mazur has joined #openttd 09:21:14 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro requested changes for pull request #7817: Feature: Minimap screenshot https://git.io/JepBD 09:34:12 *** nielsm has joined #openttd 09:44:22 <andythenorth> nielsm: next, buttons that understand the vehicle tech tree :) 09:44:24 <andythenorth> also hi 09:44:33 <nielsm> morning 09:46:50 <nielsm> I spent too many hours of the night trying to make hardware/system mouse cursors on windows, and it does not work 09:47:02 <nielsm> creating a cursor from a sprite is hard 09:50:55 <andythenorth> oof :) 09:59:40 <nielsm> and not less hard when I have almost no knowledge of getting the sprite pixel data 10:00:22 <nielsm> and the really hard thing is that I want to know about the full transparency data, not just blit it onto somewhere 10:31:24 <andythenorth> so...vehicles get a 'more info' string? Accessible from buy menu and vehicle window? 10:31:32 <andythenorth> it opens a little window 10:32:38 <nielsm> I thought about thta the other day too, "extended description" 10:37:36 *** snail_UES_ has joined #openttd 10:43:45 <andythenorth> I want to do some stupid backstory for engines :) 10:43:50 <andythenorth> alternate history 10:43:54 <andythenorth> and some play tips 10:49:05 <andythenorth> the docs have some basic play tips https://firs-test-1.s3.eu-west-2.amazonaws.com/iron-horse/docs/html/tech_tree_table.html 10:49:08 <andythenorth> but that could be in-game eh 10:49:16 * andythenorth wonders about a tech tree in-game :P 10:53:00 <nielsm> like "do you want highly specialised locos or do you want more general purpose" questions? 10:53:32 <nielsm> so you can get a 150 mph but weak steamer along with a 50 mph super powerful steamer, or you can get a 90 mph decently powerful steamer 10:54:25 *** snail_UES_ has quit IRC 10:54:28 <andythenorth> something like that 10:54:29 <nielsm> one possibly interesting thing transport fever 2 allows in scenarios is (dynamic) build limits for certain vehicles 10:54:38 <andythenorth> I think it would have to depend on certain newgrfs 10:54:53 <nielsm> so you could make it impossible to just upgrade your entire fleet to the newest models all at once 10:55:09 <andythenorth> some Railroad Tycoon scenarios had 'choose your chief engineer' or 'choose your technology' 10:55:16 <andythenorth> and that affected tech tree 10:55:56 <andythenorth> it's only interesting in a goal-driven scenario I think, for sandbox it's not adding anything : 10:55:57 <andythenorth> :) 10:56:14 <nielsm> hmm, maybe in competitive multiplayer though? 10:56:18 <andythenorth> yes 10:56:41 <andythenorth> the tech tree is just a graph 10:57:23 <andythenorth> I had a version done with graphviz somewhere, but it's missing :) 10:57:41 <andythenorth> I already specify 'replacement vehicle ID' to work out expiry dates 10:57:48 <nielsm> one of the transport fever 2 scenarios has you "train drivers" for road vehicles, keep some buses and trucks running around an empty track of road to slowly raise your limit of road vehicles ownable 10:57:50 <andythenorth> so with that, it's just working backwards to get the tree 10:58:02 <nielsm> all the trf2 campaign is fully of busywork like that 10:58:08 <andythenorth> hmm :) 10:58:30 <andythenorth> I like the idea of freezing time, and unlocking engines by completing goals 10:58:36 <andythenorth> grind grind grind :P 10:59:56 <nielsm> :( I have no idea why my calls to the blitter are crashing 11:09:20 <nielsm> oh, uninited memory looks like it 11:09:36 <nielsm> adding a garbage value to a pointer will usually result in a garbage pointer 11:16:48 *** Mazur has quit IRC 11:18:17 <michi_cc> nielsm: Won't help by itself, but https://github.com/michicc/OpenTTD/commit/05d5766d37c3461833f41acbad6439da9b223664 might give some cursour inspiration. 11:19:09 <michi_cc> And https://github.com/michicc/OpenTTD/commit/6e4d9e60734e574feef64f37c964c49df0f94ac7 as the preparation step. 11:19:38 <michi_cc> Ah, and https://github.com/michicc/OpenTTD/commit/c06893fbdfd7ce93aa4f08e1700a65c08294047b as well. 11:19:45 <nielsm> so much... 11:20:03 <nielsm> but it looks like calling the blitter is the wrong approach, and use GetRawSprite instead 11:20:19 <nielsm> (and GetSprite is useless since its format depends on the blitter) 11:20:58 <michi_cc> https://github.com/michicc/OpenTTD/commit/05d5766d37c3461833f41acbad6439da9b223664#diff-1834df39089c4efe0c2d57796cbfaa67R791 is my function. 11:24:18 *** Flygon has quit IRC 11:25:50 *** Flygon has joined #openttd 11:34:08 <nielsm> hm no, GetRawSprite still feeds it through the blitter's encoder 11:35:17 <nielsm> https://0x0.st/znNz.png 11:35:19 <nielsm> ._. 11:36:31 <LordAro> nielsm: perfection. 11:39:52 <michi_cc> nielsm: I've missed https://github.com/michicc/OpenTTD/commit/ccb5efa6a0af685c113b6986832decb9db2060c9 in the list of prepare commits. 11:40:06 <michi_cc> It allows to plug in a different sprite encoder if needed. 11:40:39 <michi_cc> Which I've been using to encode it as opengl texture. 11:41:21 <michi_cc> Or basically https://github.com/michicc/OpenTTD/commits/opengl from the "Add: [OpenGL] Accelerated mouse cursor drawing." commit back ~8 commits. 11:50:28 <nielsm> hm yeah that probably makes the most sense really 11:50:45 <nielsm> just make an encoder that fills the windows dibsection bits directly 11:54:51 <nielsm> michi_cc: thanks for a clean commit that cherry-picks perfectly :) 11:56:42 <michi_cc> That opengl branch is supposed to both compile and work at any point, and I've tried to split the commits cleanly. Seems I mostly managed :p 11:58:47 <michi_cc> nielsm: You probably want the next four commits as well (except maybe the alignment one, but I've not looked at windows cursor code in detail). 12:00:13 <michi_cc> Next 5 actually, you probably should remove unused cursors as the animated cursors will produce quite a lot of sprites. 12:29:47 <nielsm> argh why is MSVS so bad at keeping track of where the implementations of functions are 12:30:22 <nielsm> for the code browsing 12:32:45 <nielsm> michi_cc: a candidate for cleaning up with those commits too: https://github.com/OpenTTD/OpenTTD/blob/master/src/spritecache.cpp#L428-L438 12:34:00 <michi_cc> You'd still have to skip the resize step though. 12:35:14 <nielsm> hm yes 12:35:44 <nielsm> and really, I don't want the resize step for this patch either, since windows system cursors are limited to 48x48 12:36:10 <nielsm> or rather, I'll have to just discard the resized data again 12:47:50 <michi_cc> nielsm: I think even the default TTD cursors can be bigger than 48x48 (not to mention BigGUI etc), so I think you are out of luck anyway. 12:48:27 <michi_cc> E.g. the Autoroad cursor from openttdgui.png is 56x36 pixels large. 12:50:03 <nielsm> yeah... I have to do some weird stuff 12:50:17 <nielsm> switching on the fly 12:57:58 *** Heiki has quit IRC 12:58:04 *** Heiki has joined #openttd 13:01:09 <nielsm> uh wtf... this looks dangerously wrong? 13:01:09 <nielsm> https://github.com/OpenTTD/OpenTTD/blob/e7922cd078837567ca5fb2c82a585fdada71f2b8/src/blitter/32bpp_simple.cpp#L123 13:01:39 <nielsm> struct Sprite consists of four fields with dimensions and offset, and then a pointer to byte data 13:01:53 <nielsm> the pointer to byte data is never initialised 13:02:16 <nielsm> but is just assumed to point to the extra memory allocated right behind it? 13:02:40 <nielsm> or am I totally misunderstanding what "byte foo[];" means? 13:09:08 <LordAro> nielsm: as a struct member it allocates an array as part of the struct, right? 13:09:26 <LordAro> if it's not a pointer 13:15:13 <michi_cc> nielsm: https://en.wikipedia.org/wiki/Flexible_array_member 13:27:21 *** Samu has joined #openttd 13:33:39 <Samu> hi 13:33:39 <nielsm> michi_cc: "C++ does not have flexible array members." 13:33:49 <nielsm> (well C++20 does, I think) 13:34:10 <nielsm> which is why all microsoft headers declares a member array of length 1 13:35:01 <nielsm> such as https://docs.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapinfo 13:37:31 <nielsm> it looks like the code does compile as intended I see, but it's out of standard 13:47:04 <LordAro> nielsm: gcc does it, so gcc c++ gets it as well 13:50:41 <andythenorth> how to draw this shape in 1x zoom eh? :P https://www.bloodandcustard.com/442_files/image002.jpg 13:55:02 <Pikka> approximately, andythenorth? 13:55:20 <Pikka> I thought brithorse was done? ;) 13:55:29 <andythenorth> something happened 13:56:20 <andythenorth> I figured out the fast EMUs :( 14:00:27 * andythenorth wonders if that train is in UKRS 2 14:01:00 *** frosch123 has joined #openttd 14:01:25 <andythenorth> nope :) 14:10:08 <andythenorth> Pikka: train 144? https://dev.openttdcoop.org/attachments/download/9594/olympix.png 14:15:25 <Samu> how do I rebase up to a date? 14:15:48 <Samu> not the current one, but to something in the past 14:20:45 <nielsm> git rebase <revisionhash> 14:20:58 <nielsm> to stack the current branch on top of that hash 14:21:28 <nielsm> sometimes you need to do more complex stuff, like indicating that start and end of the revision range you want to rebase 14:24:10 <nielsm> hmm, well... https://0x0.st/znTq.png 14:24:13 <nielsm> it's better than before 14:26:14 *** Wolf01 has joined #openttd 14:29:27 <LordAro> :D 14:30:24 <LordAro> nielsm: ooi, what's the benefit of a native cursor? 14:30:56 <nielsm> moves even when the game is slow between frames 14:31:00 <nielsm> pretty much nothing else 14:31:07 <nielsm> it's probably not worth it at all 14:31:43 <LordAro> i see 14:33:24 <nielsm> https://github.com/OpenTTD/OpenTTD/compare/master...nielsmh:win32-syscursor 14:33:29 <nielsm> probably not going any further with it 14:37:09 <Pikka> not bad andythenorth :D 14:37:23 <Pikka> so many horse 14:39:45 <andythenorth> fancy 14:39:46 <Samu> i can't read through modules templates typedefs 14:40:05 <andythenorth> did we do daylength yet? 14:40:17 <andythenorth> by the time I've replaced all my trains, it's time to replace all my trains 14:40:29 <Samu> Feature: Multi-tile docks and docking points. conflicts with mine 14:40:30 <Samu> Fix #5713: Use pathfinder to find closest ship depot 14:41:46 <Samu> i dont know how to make it call the right module 14:42:38 <Samu> https://github.com/OpenTTD/OpenTTD/commits/master/src/pathfinder/yapf/yapf_ship.cpp 14:44:13 <Samu> gonna try the rebase trick 14:46:34 *** Mazur has joined #openttd 14:47:53 *** Flygon has quit IRC 14:56:28 <peter1138> Marylebone to Aylesbury for Dovetail's Train Simulator... £25 for the addon, and £36 for its dependency addons... I think not. 15:06:27 <andythenorth> oof 15:09:46 <Samu> I need a yapf code master 15:09:52 <Samu> is it peter1138? 15:11:12 <Samu> class CYapfDestinationTileWaterT ruined my patch 15:11:23 <Samu> it now requires a destination tile which i don't have 15:11:37 <Samu> it's still searching for it 15:12:16 <Samu> it used to be class CYapfDestinationTileT 15:13:58 <Samu> i want it to call class CYapfDestinationAnyDepotShipT 15:14:14 <Samu> for computing estimates and checking if tile is a depot 15:14:28 <Samu> but it's using CYapfDestinationTileWaterT :( 15:14:36 <Samu> I'm not sure what to do 15:15:29 <Samu> feels like my whole class CYapfDestinationAnyDepotShipT is unreachable, the breakdown in that code says it's not "linked" 15:15:40 <Samu> a breakpoint* 15:18:39 <nielsm> that's the bug I also told you about the other day, something visual studio's partial rebuilds break and gets all the browsing/symbols wrong 15:18:44 <nielsm> the workaround is to do a complete rebuild 15:19:14 <Samu> ok, let me try 15:19:18 <DorpsGek_III> [OpenTTD/OpenTTD] aljowen opened issue #7897: Can't insert new order... Vehicle can't go to that station (Maglev Train) https://git.io/JepgJ 15:22:10 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7897: Can't insert new order... Vehicle can't go to that station (Maglev Train) https://git.io/JepgJ 15:22:10 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh closed issue #7897: Can't insert new order... Vehicle can't go to that station (Maglev Train) https://git.io/JepgJ 15:22:25 <andythenorth> strikes again 15:23:15 <Samu> nop, it's not a bug, it really isn't reachable (aka my code is a failure) 15:23:33 <DorpsGek_III> [OpenTTD/OpenTTD] aljowen commented on issue #7897: Can't insert new order... Vehicle can't go to that station (Maglev Train) https://git.io/JepgJ 15:23:45 <Samu> [img]https://i.imgur.com/3qEzRU5.png 15:26:12 *** snail_UES_ has joined #openttd 15:26:15 <Samu> seems that i need to lend my code... 15:30:00 <Samu> wow, i think I solved it by accident 15:30:04 <Samu> let me confirm 15:33:28 <Samu> I accidentally fixed it! 15:33:35 <Samu> yeah! :) 15:39:38 <LordAro> always nice when that happens 15:41:39 <Samu> problem is that I don't understand why it works 15:41:43 <Samu> but im happy 15:43:14 <LordAro> maybe you should try to understand it 15:43:32 <LordAro> otherwise you might find issues later 15:43:44 <LordAro> or indeed earlier, as a result of having understood it! 15:43:53 <Samu> https://github.com/OpenTTD/OpenTTD/compare/master...SamuXarick:find-closest-reachable-ship-depot?expand=1 15:45:29 <Samu> sec, these lines are highlithed https://github.com/OpenTTD/OpenTTD/compare/master...SamuXarick:find-closest-reachable-ship-depot?expand=1#diff-eb49f6e078e86d571fa58dbaa9d63316R403-R431 15:46:14 *** andythenorth has quit IRC 15:46:31 <Samu> i just changed line 330 in red to line 420 in green 15:46:37 <Samu> now it's linked 15:47:47 <Samu> template, class, typedef, struct, it's all stuff that I don't yet comprehend 15:48:00 <LordAro> ah, yapf stuff 15:48:18 <LordAro> yapf is fairly difficult to understand for experienced programmers 15:50:54 <Samu> CYapfDestinationTileWaterT is still being called for cases where I'm not searching for closest ship depot, as I intended 15:51:30 <Samu> and CyapfDestinationAnyDepotShipT for depots 15:51:52 <Samu> CYapfDestinationTileT is still an incognita 15:52:07 <Samu> but it saved my arse 15:53:21 *** sla_ro|master has quit IRC 15:53:43 <Samu> seems to be acting as a redirect 15:55:02 *** sla_ro|master has joined #openttd 15:55:05 <Samu> CYapfDestinationTileT redirects to either CYapfDestinationTileWaterT or CYapfDestinationAnyDepotShipT 16:01:37 *** Mazur has quit IRC 16:09:08 *** Pikka has quit IRC 16:15:00 <nielsm> DoCommandFlag flafs 16:15:02 <nielsm> flaf 16:15:22 <nielsm> should maybe turn up the heat a bit here, getting difficult to type right 16:20:38 <Samu> SamuPatchPack with everything! https://pastebin.com/raw/rHhjtaY5 16:20:43 <Samu> so happy! 16:25:13 *** Wormnest has joined #openttd 16:43:58 *** snail_UES_ has quit IRC 16:48:07 <DorpsGek_III> [OpenTTD/OpenTTD] telk5093 updated pull request #7817: Feature: Minimap screenshot https://git.io/JegRL 16:50:51 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh opened pull request #7898: Feature: Script API to change town rating of companies https://git.io/Jep2F 16:57:14 <DorpsGek_III> [OpenTTD/OpenTTD] telk5093 commented on pull request #7817: Feature: Minimap screenshot https://git.io/JepaI 17:16:50 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7817: Feature: Minimap screenshot https://git.io/Jepa4 17:17:07 <LordAro> nielsm: feel like giving ^ a last look over? 17:19:15 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7898: Feature: Script API to change town rating of companies https://git.io/JepaR 17:19:47 <LordAro> also reviewing any of my other PRs :p 17:21:41 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh merged pull request #7817: Feature: Minimap screenshot https://git.io/JegRL 17:23:13 <nielsm> hmm... I think I made the change rating API available to AI too... 17:23:26 <nielsm> (it won't work but it shouldn't be there) 17:25:04 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh dismissed a review for pull request #7898: Feature: Script API to change town rating of companies https://git.io/JepaR 17:25:04 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7898: Feature: Script API to change town rating of companies https://git.io/Jep2F 17:35:23 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh approved pull request #7884: Fix #6667: Also recalculate bridge costs for 'spectated' AI companies https://git.io/Jepa9 17:41:18 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh approved pull request #7894: Fix #7587: Crash when loading saves with waypoints with invalid locations https://git.io/JepVI 17:41:37 <LordAro> nielsm: hmm, i would expect "@api game" to make it only available for game (something like `@api ai game` for both) 17:41:40 <LordAro> ah well 17:41:55 <nielsm> yeah me too, I'm not sure why it works like that 17:42:08 <LordAro> #blameTB 17:42:38 <LordAro> #notactuallyblamingTBpleasedontkickmeagain 17:42:38 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh merged pull request #7852: Feature: Show the name of the NewGRF in the build vehicle window. https://git.io/JeMKL 17:46:14 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7898: Feature: Script API to change town rating of companies https://git.io/JepVO 17:55:41 *** glx has joined #openttd 17:55:41 *** ChanServ sets mode: +v glx 17:57:49 *** snail_UES_ has joined #openttd 18:06:35 <nielsm> slightly wary of merging https://github.com/OpenTTD/OpenTTD/pull/7843 18:06:47 <nielsm> the second and third commit message are very long 18:06:53 <nielsm> but I don't want to squash it either 18:07:17 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh merged pull request #7898: Feature: Script API to change town rating of companies https://git.io/Jep2F 18:11:38 *** andythenorth has joined #openttd 18:12:37 <andythenorth> yo 18:14:41 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #7000: Some NewGRF variables concerning railtypes https://git.io/JepVp 18:16:46 *** snail_UES_ has quit IRC 18:32:46 <Samu> uploaded LuDiAI AfterFix 13 https://bananas.openttd.org/en/ai/ 18:32:56 <NGC3982> oh im still here 18:33:03 <Samu> minor fixes only 18:40:41 <Samu> changelog https://github.com/SamuXarick/LuDiAI-AfterFix/blob/master/changelog.txt#L4 18:45:48 <DorpsGek_III> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://git.io/JepwW 18:45:48 <DorpsGek_III> - Update: Translations from eints (by translators) 18:51:50 <frosch123> nielsm: why does it need a memcpy? isn't a static_cast just fine? 18:52:23 *** y2kboy23 has quit IRC 19:01:10 *** floodious has joined #openttd 19:01:38 <nielsm> I have no idea where but I just feel like I've been bitten by a signed/unsigned cast having implicit truncation of out of range values, and I'm probably wrong 19:02:04 <floodious> issue I've noticed: when a vehicle is cloned with shared orders, the orders are duplicated rather than the new clone being added to the shared orders list 19:02:25 <frosch123> hold Ctrl when cloning 19:02:27 <nielsm> are you sure you're holding Ctrl? 19:02:38 <floodious> shouldn't that behavior be reversed? 19:02:47 <floodious> ctrl = copy, no ctrl = clone 19:03:09 <nielsm> that would be dangerous to do now after 10+ years 19:03:20 <floodious> weird decision if it requires ctrl to actually clone though 19:03:29 <frosch123> it's the same as when copying orders 19:03:39 <frosch123> no ctrl = copy, ctrl = share 19:04:12 <floodious> i guess that's a future issue for an improved keyboard/input configuration system 19:05:25 <frosch123> just remap caps lock to ctrl lock 19:06:15 <floodious> those are "prevent the problem", while with a saved game it's a question of "solve a problem with 1000s of vehicles without manually changing 1000s of order lists: 7 clicks = 8000 clicks" 19:06:52 <floodious> so i was looking at making other GUI changes for myself by adding a group command like "share orders to group" 19:07:08 <floodious> anyway the ctrl thing answered my question there, so no worry 19:07:19 <floodious> "clone != clone" 19:07:33 <frosch123> copy clone, share clone 19:07:51 <floodious> i'd call it "clone clone", since the shared order list is actually empty 19:07:55 <frosch123> copy clone is useful if you want the same train on a different route 19:07:59 <floodious> yep 19:08:51 <nielsm> honestly, most of the time when I use copy rather than shared-clone, I'd rather have the copy start out with a blank orders list 19:09:40 <floodious> it all ends up being issues of much greater complexity, that are probably solved by some more adaptable user configuration of input/commands, but that's distant future stuff, not "next release" 19:11:24 <floodious> some games/tools use a scripting system internally and the user can custom configure interface elements, so each "skin widget" triggers a script function, and each can be either a built-in standard function or custom user function 19:11:40 *** snail_UES_ has joined #openttd 19:11:56 <floodious> the DAW host Reaper is a good example of such a system 19:12:57 <floodious> bad example of good workflow in the configuration GUI though 19:15:42 <floodious> i've been working on improving/modernizing the heightmap.cpp code: https://pastebin.com/2CUP69F4 19:15:48 <floodious> this is 20% complete 19:18:04 <LordAro> intriguing 19:18:31 <LordAro> but, well, change for change's sake isn't usually accepted - there'll need to be some improvement in some way or another 19:19:22 <floodious> i still need to improve the interpolation from ZOH (nearest = zero order hold) to some windowed sampling (for decimation) including cropping (no "zoom"), but it already works quite well with 16-bit input from NASA satellite data and such 19:19:39 <LordAro> :) 19:19:58 <floodious> i've also implemented water (oceans + lakes + rivers) = blue, and forest/plant density (moisture) = green layers from RGB 19:21:01 <floodious> but my NASA dataset doesn't yet include proper plant density since that's a bit more complex to extract, the data is usually in arc-GIS formats instead of simple TIFF bitmaps... although it works great with my faked slope-based data 19:21:33 <nielsm> make sure old heightmaps still give the expected output :) 19:21:36 <floodious> i've got all the river + lake polygon measurements but have yet to write the code to decode/translate them 19:21:51 <floodious> yep of course a backward compatible mode would be part of it 19:22:08 *** HerzogDeXtEr has quit IRC 19:22:47 <floodious> so far i've gotten "semi-realistic" looking forests though which is really cool, speciation based on altitude and such although all numbers haphazardly pulled from the ass 19:22:57 <nielsm> also take a look at this if you haven't seen it: https://github.com/OpenTTD/OpenTTD/pull/7664 19:23:11 <floodious> openttd doesn't handle realistic forests well, runs incredibly slow on 4kx 19:25:39 <floodious> looks nasty c-style 19:25:48 <floodious> but roughly similar ideas 19:26:05 <floodious> i need to finish my implementation and benchmark it, it'll likely be many times faster than the original code 19:26:44 <floodious> seems 2x already but hard to say... the "running tileloop" now takes 10x longer than any other step 19:27:54 <andythenorth> https://wiki.openttd.org/Terkhen/Scenario_format 19:28:01 <andythenorth> https://www.tt-forums.net/viewtopic.php?t=61140 19:28:04 <andythenorth> FYI 19:28:24 *** Xaroth4 is now known as Xaroth 19:38:09 <floodious> that's all well and good, but i think the code is horribly convoluted and hard to read 19:39:14 <floodious> the rough ideas are simple enough and basically align with what i'm doing, but openttd doesn't have any real specification for landscape/climate based on real standards or known real species 19:40:04 <floodious> the idea of using n-colored paletted single layer PNG is horribly inefficient too 19:40:49 <floodious> i'm trying to eliminate some of the translation steps between real scientific datasets and the formats 19:42:17 <floodious> improved code should be smaller and easier to read, not larger and more convoluted 19:47:45 <floodious> polygon/vector based datasets don't align well with the grid-based system in openttd, so being able to accurately interpolate and produce good results is essential... diagonals are only 1/8th of 360 19:48:22 <floodious> i haven't even gotten to the point where i can decode datasets including roads/buildings let alone try to make them appear in any reasonable way 19:49:35 <floodious> heaps of issues, but the baseline "import scientific datasets including height + sea + lakes + rivers" is working well 19:55:19 <floodious> for efficiency, generally RLE + or plain raw bitmap + LZMA2 does a way better job than png, and it's more processor efficient too assuming the decoder has enough memory for the dictionaries 19:55:35 <floodious> PNG is a nasty format that was obsolete before it began 20:07:53 <planetmaker> floodious, when speaking scenario description format, "processor friendly" is certainly the last thing to consider. 20:09:33 <planetmaker> (generally 'efficiency' in one-time operations is a thing to disregard unless you stray far into the domain of inefficient) 20:09:37 <nielsm> well when you're making a scenario, having a faster modify-test cycle is definitely better 20:09:47 <planetmaker> ^^^ yep 20:10:14 <floodious> the current code requires an obscene amount of process time, plus size is an issue due to bandwidth concerns... if it's possible to reduce and get the same results with shorter + more readable/maintainable code, it's a given 20:10:16 <planetmaker> which depends more on an easy-to-use format for the user than "processor friendly format" 20:10:42 <floodious> i spend 99% of my time making tea ATM 20:12:03 <floodious> i was thinking some interlaced format might speed things up, since modern CPUs have massive burst bandwidth for wide words, such as transferring/modifying using SSE instructions 20:12:13 <floodious> using bytes is crazy slow 20:12:58 <floodious> but using SSE intrinsics would obviously make the code far less portable, so their use would need to be dynamic (via template) 20:12:59 <nielsm> a format that requires special tooling to create is a huge negative 20:14:00 <planetmaker> I envision the scenario editor to swallow some form of "sketches" which any person can create with any somewhat decent drawing programme. 20:14:24 <floodious> well, usual datasets come in TIFF (for scientific data) with LZW+deflate compression and formats like arcGIS or SQLlite which are proprietary and difficult to decode without using the proprietary libs 20:14:28 <planetmaker> That would allow to import any colour-coded GIS data as well (e.g. height info) 20:15:26 <planetmaker> well, yes. But I don't see OpenTTD gaining an import for typical GIS data... TIFF... maybe, depends 20:16:01 <floodious> TIFF is hard too, it already has libpng which is enough, but external tools are needed to translate from the 16-bit data formats to 8-bit internally... that's why i've added 16-bit png import 20:16:40 <floodious> but using 16-bit data is fairly inefficient when the heights are 10s of meters, so the highest point around here is only around 200 (fits in 8-bits!) 20:16:47 <glx> I remember TrueBrain writing a tool to generate heightmap from scientific data 20:17:33 <floodious> the problem with external tools is they're designed for graphics, not scientific data with accuracy in mind... so you end up with really weird decisions 20:18:06 <floodious> like truncation, where TTD's format requires 0 = ocean, so x>0 needs to be truncated up to 1 20:18:20 <floodious> but graphical tools assume "black is black is black" 20:18:21 <planetmaker> There's two things, one OpenTTD, one not: 20:18:51 <planetmaker> OpenTTD needs some way to import / create scenarios or maps in a somewhat reasonable manner, describing the single items on a map. 20:19:14 <floodious> well i posted my code that imports the 16-bit data directly already, and so from a 2 mb file i get an accurate 10k heightmap with no external tools in between 20:19:43 <floodious> tools are needed to go from the raw scientific data to the png, but that's a given really 20:20:21 <planetmaker> What it does not need to cater for, is importing 3D data, and other scientific GIS data as there's a *very wide* plethora of formats... and in science you always write dedicated import functions for each separate dataset (from my experience) 20:20:32 <floodious> database formats are probably the best for data like roads+rivers+cities+signs etc, using existing open-source libs 20:20:52 <floodious> since free tools to manage that data exist, and most of the source data is already in such a format 20:20:59 <planetmaker> so that's a thing very hard to generalize - even when the general data format is agreed upon, it's still to individual to make a one-import fits many 20:22:21 <floodious> 16-bit png solves all the steps of TIFF to 8-bit 20:22:42 <floodious> standard tools can losslessly convert 16-bit TIFF to 16-bit png and combine planes 20:23:30 <glx> the best thing to have, I think, is a generic image format with specific color data 20:23:31 *** snail_UES_ has quit IRC 20:23:35 <floodious> going from vector data for height (does such a thing even exist? i've never seen it) to a grid-based raster format would obviously be up to the individual 20:24:28 <floodious> ASTER is in 16-bit TIFF 20:24:31 <floodious> for example 20:24:52 <floodious> https://asterweb.jpl.nasa.gov/ 20:25:00 <glx> then you can have tools to convert a given format to the format supported but OpenTTD 20:25:18 <floodious> nope, open-ttd requires special steps 20:25:18 <glx> *by 20:25:33 <floodious> such tools don't exist generally speaking, such as the ocean = 0 "black is black is black" issue i mentioned 20:26:14 <floodious> and mapping height ranges from accurate source data to ranges that are reasonable at fixed grid spacing in openttd maps... for example a 255 height requires a 512x512 area, minimally 20:26:52 <floodious> and openttd lacks definite standards, but ought to have some for "1 height unit" and "1 tile unit" 20:27:32 <floodious> such as "1 height unit = 20 meters" 20:28:47 <floodious> when calculating slope + mass + energy for hill climbing for example, having definitive units would make it much easier to automatically fill all the other numbers 20:29:45 <planetmaker> No, those standards are not missing and even cannot exist :) It's not a photo-realistic game and scale depends on what stuff you look at 20:30:11 <planetmaker> a tile is the length of a vehicle. And towns are separated 20 vehicle lengths 20:30:17 <floodious> that's true, but starting with a reasonable standard that approximately fits the existing scales would be a good idea 20:31:04 <glx> that's the job of an external tool for me 20:31:09 <andythenorth> what's the highest plausible heightmap RL? 20:31:42 <planetmaker> what's the height of a heigth map? max - min [in metres]? 20:31:52 <planetmaker> then probably my Marsian map :) 20:31:56 <floodious> ASTER data uses 10 meter units, for example 20:32:16 <planetmaker> from the depth of Hellas basin to the top of Olympus mons it's more than 20km height difference 20:32:33 <floodious> but openttd currently assumes widely differing values... for example the width of a track is 1.5 meters, while the width of a tile is more like 100 meters or more 20:33:00 <planetmaker> we will not standardize those values or set a value which we tell "use this" 20:33:13 <floodious> then you'll never get any improvements to anything related 20:33:23 <floodious> because it all starts with standardizing one unit, and building from that 20:33:38 <floodious> one unit = standardizes everything, in time 20:33:51 <glx> train scale != RV scale != boat scale != plane scale 20:33:56 <planetmaker> If you want a game with realistic scales, it's a different game and would amout to a complete re-write from scratch 20:34:10 <floodious> i'm not sure why you're extending this so extremes 20:34:17 <floodious> to 20:34:37 <floodious> just having a rough "1 tile has no definite dimension, but is assumed to be approximately X" 20:34:38 <planetmaker> you're not the first person asking "what's the scale". 20:34:42 <floodious> guides other decisions 20:34:44 <planetmaker> And all those answers are correct 20:34:55 <planetmaker> And there's no way to make one correct and obsolete the others 20:35:05 <floodious> i know the scale is kids toyland, that's obvious when a train takes up the same size as a skyscraper 20:35:23 <planetmaker> yes. But then... how can you even define a scale? 20:35:43 <floodious> but, even the largest building has a finite size, as does a train, so you can create a range of scale like "1 meter to 100 meters" 20:36:02 <planetmaker> You can define a scale roughtly for trains. another for RV. Another for house,s another for industries, another for planes, another for ships. And landscape tiles... impossible really as everything moves on it 20:36:12 <glx> depending on the newgrf used, vehicles have different scales 20:36:20 <floodious> and the range includes all those dimensions 20:36:27 <floodious> giving a definite "min-max" scale 20:37:09 <floodious> even "1 ft to 1000 ft" makes design decisions way more easy 20:37:09 <planetmaker> well. One tile ranges from like 5m (vehicle scale) to 5km (landscape regions scale) 20:37:29 <planetmaker> so it varies by a factor of 1000 20:38:01 <floodious> so that ought to be documented, "approximately ..." and tables can be built to show examples of ranges and outliers 20:39:19 <floodious> given 5 meters for trains, which is ... a tiny, but roughly accurate width for a track + foundation i guess in the smallest situations in real life 20:39:47 <planetmaker> not trains. Road vehicles :) 20:39:49 <floodious> 4096 x 5 = 20.48 km 20:40:01 <planetmaker> For trains... a tile probably is like 15...25 metres 20:40:18 <glx> long, not wide :) 20:40:24 <floodious> a standard gauge track is about 1.5 meters, plus the width of the foundation and keepers 20:40:33 <planetmaker> from the vehicle perspective. Yes, long. Wide... it's like 5m :P 20:40:36 <floodious> so 5 meters might be a good guess 20:40:46 <floodious> minimum 20:41:20 <Samu> i see chat is busy 20:41:22 <floodious> assuming it's in some flat california wasteland salt flats or whatever 20:41:29 <andythenorth> 8/8 is 32px is 60ft in my pixel world 20:41:33 <andythenorth> it's not very exact though 20:41:44 <andythenorth> (vehicle lengths) 20:41:53 <planetmaker> @calc 60ft in m 20:41:53 <DorpsGek> planetmaker: Error: invalid syntax (<string>, line 1) 20:41:56 <planetmaker> hm :| 20:42:05 <glx> andythenorth: and other grf authors use their own different scale 20:42:05 <floodious> length is hard, since tiles are square and the proportions for width + length are so stretched 20:42:16 <floodious> that's why i'm focusing on known minimums 20:42:39 <glx> there's really no rules 20:42:45 <Samu> max height, in openttd tileh is 255, and 0 is water 20:42:49 <floodious> a standard gauge train might be 3 meters, or 5 meters, or 12 meters wide 20:43:05 <floodious> hugely varied... i don't know enough to say but i've been on a few 20:44:23 <floodious> the legal limits in various regions might guide a bit 20:44:46 <floodious> "maximum US standard gauge car width" or similar 20:46:16 <floodious> https://en.wikipedia.org/wiki/Loading_gauge 20:46:39 <andythenorth> glx: and ships and RVs are to a different scale 20:46:39 <LordAro> @convert 60 ft in m 20:46:39 <DorpsGek> LordAro: Error: inm is not a valid unit. 20:46:40 <floodious> looks like 3 meters is a good guess 20:46:47 <LordAro> @convert 60 ft to m 20:46:47 <andythenorth> it's all just like Lego City 20:46:47 <DorpsGek> LordAro: 18.288 20:46:51 <andythenorth> nothing is to scale 20:46:52 <planetmaker> ha! :) 20:47:02 <LordAro> planetmaker: i have https://github.com/ProgVal/Limnoria/blob/master/plugins/Math/plugin.py#L234 open :p 20:47:02 <andythenorth> all the lolz 20:47:13 <floodious> so 3x18, what's the real length of a typical mid-century car? 20:47:14 <LordAro> and i still got it wrong the first time 20:47:33 <floodious> since the length is limited to something like 20 meters to deal with curves 20:47:38 <floodious> 18 might be spot on 20:48:10 <planetmaker> hehe @LordAro :) I knew that it could do it somehow... tyvm 20:48:38 <planetmaker> curves... are somewhat unrelatistic in OpenTTD :) 20:48:43 <planetmaker> especially for trains 20:48:45 <floodious> yeah, don't exist haha 20:49:03 <planetmaker> oh, for everything but trains they do exist :) 20:49:11 <planetmaker> at least visually 20:49:15 <floodious> but what i'm saying is a good reasonable basis for units of measure does exist, at least in min and max ranges 20:49:16 <planetmaker> on the ground 20:49:53 <floodious> and assuming a square tile is "stretched" according to direction of travel, due to the openttd space-time warp 20:50:21 <Samu> town directory is suddenly slow :( 20:50:22 <floodious> since light speed is so much lower, and the warping of a train traveling upon the track actually also warps the track and landscape itself 20:50:37 <planetmaker> if you're not drawing graphics, you can savely ignore that 20:51:07 <planetmaker> the difference x or + directions is not that big 20:51:17 <floodious> i think it's pretty huge 20:51:25 <floodious> assuming realistic gauge it's nuts 20:51:32 <planetmaker> less than factor 1.5 20:51:44 <floodious> like 20 meter width to 200 km length 20:52:16 <floodious> i mean min/max, such as the width of a rail and train vs. the length traveled upon the rail in a tile 20:52:28 <Samu> guys, test this: create a 4096x4096 map with high number of towns, then open town list... it's slow!!! 20:52:43 <floodious> yeah everything is slow as heck, since the default generator is bugged 20:52:50 <glx> Samu: many strings to formal 20:52:54 <glx> *format 20:52:54 <floodious> it creates way too many towns since it scales linearly 20:53:13 <floodious> and each time you increase by 2 (128, 256, 512) you're going by 4x towns 20:53:21 <Samu> it's not happening in 1.9.3 20:53:23 <floodious> 16, 256, etc 20:53:25 <glx> (and strings are not cached, so recreated on each draw) 20:53:26 <Samu> only in 1.10.0-beta2 20:53:41 <glx> yes, because 16 in/out cargos 20:53:50 <glx> strings are more complex 20:54:07 <Samu> also 1.9.3 doesn't have a filter 20:54:11 <Samu> could it be the name filter? 20:54:18 <glx> filter is new 20:55:50 <floodious> Samu; i suspect the algorithms used in the code have either linear or worse scaling, while to solve the exponential growth in number of towns you'd need to use a log(N) algo 20:56:10 <Samu> [img]https://i.imgur.com/ulHElEY.png 20:56:11 <floodious> like using stl and boost stuff with known log(N) times 20:56:20 <Samu> 600 ms, 2 fps :( 20:56:27 <floodious> rather than linearly iterating through the items 20:56:50 <Samu> do i report it as a bug? 20:56:51 <floodious> it's probably doing some foreach(town) { update(town, x); } 20:57:00 <glx> I think the slowest part is getting the max length 20:57:00 <floodious> not a bug, just lack of a feature to cope 20:57:08 <floodious> an issue for sure 20:57:48 <floodious> update(town, x) might have { foreach (town, t) { if (t != this_town) { ... } } 20:57:55 <Samu> [img]https://i.imgur.com/JUYNmAU.png - the same generated settings but in 1.9.3 20:57:56 <floodious> means (N^2) timing 20:58:02 <Samu> no problems 20:58:06 <glx> but it's not really a bug, just a poorly optimised window 20:58:32 <floodious> it probably needs to only iterate through the displayed towns, rather than updating all of them 20:58:43 <LordAro> i think idle speculation is useless 20:58:57 <floodious> well, reading the code i'd come back in an hour 20:59:10 <floodious> but it's definitely a (N^x) issue 20:59:54 <glx> but I think I probably noticed it when I updated the code to support 16 in/out 21:01:11 <Samu> indsutry window has some spikes 21:01:19 <Samu> 110 ms kind of noticeable 21:01:23 <Samu> interesting 21:02:14 <LordAro> https://github.com/OpenTTD/OpenTTD/blob/master/src/town_gui.cpp#L670 there do seem to be a few extra loops than necessary, on brief glance 21:04:47 <DorpsGek_III> [OpenTTD/OpenTTD] SamuXarick opened issue #7899: Slow framerates with town list window https://git.io/JepK9 21:05:47 <Samu> industry directory has some noticeable spikes from time to time 21:06:00 <glx> for indstry directory is mostly because https://github.com/OpenTTD/OpenTTD/blob/7be9c28037eeea718ea5b49aeb223a57a6c5c383/src/industry_gui.cpp#L1317-L1330 21:06:12 <glx> I think 21:06:35 <Samu> ok let me try the TICC/TOCC strategy, brb 21:10:51 <glx> town list is ressorted every 100 ticks it seems 21:11:41 <nielsm> that's something that could be threaded really 21:13:01 <glx> hmm but real rebuild is done only if needed 21:13:29 <glx> oh no, sorting is done each call 21:14:29 <glx> depending on the sorter that can be massive 21:14:38 <floodious> 13312 towns = very high, 4k (?), even with so many, sorting a list of indices by looking up parameters from those indices should be ms scale 21:14:52 <glx> for town names I guess it's not noticeable as order won't change 21:15:09 <glx> but for population it's different 21:15:46 <LordAro> floodious: when you're running at 30fps, ms scale is still quite slow :p 21:16:11 <planetmaker> the bane of RT processing :) 21:16:28 *** y2kboy23 has joined #openttd 21:16:44 <floodious> i work in audio/DSP, so ms scale is awful to me 21:16:51 <floodious> but, 60 fps = 16.666 ms 21:16:59 <floodious> if it takes 1ms, that's 1/16th time 21:17:11 <nielsm> the frame budget in ottd is 30 ms 21:17:27 <floodious> then it's 33.333 ms 21:17:32 <glx> 30ms for world simulation and window drawings 21:17:38 <glx> and AI, and GS 21:17:50 <planetmaker> basically *everything* :)I 21:17:54 <floodious> 1/30*1000 21:18:06 <nielsm> no the budget is 30 ms 21:18:10 <nielsm> the framerate is 33.333 21:18:20 <floodious> so 3.333~ padding? 21:18:44 <nielsm> read what I'm writing 21:18:59 <floodious> anyway measuring the sort time max after 1000 attempts or so should give the actual time 21:19:45 <planetmaker> that exists as information window... niels wrote that :D 21:20:02 <glx> anyway 30ms is harder to do on a 4kx4k map 21:20:16 <nielsm> gfx_type.h defines MILLISECONDS_PER_TICK = 30 21:20:25 <nielsm> that's the basis for the game's timing 21:20:41 <glx> and a day is 74 ticks :) 21:21:19 <planetmaker> which really is an odd number :) But nicely inconsumerable with everything else 21:21:21 <floodious> on my system loading the window initially requires about 1.5 seconds with towns = 13312, but afterward it's fine. so definitely a regression or something different than standard config since i cloned the repo 21:21:53 <glx> Samu: debug or release build ? 21:21:56 *** NGC3982 has quit IRC 21:21:59 <Samu> release 21:22:08 <floodious> there is a significant cost but it's less than 4% of usual frame update for me 21:22:09 <Samu> it was 1.10.0-beta2 21:22:38 <floodious> 4 becomes 8 with the list open 21:22:48 <floodious> idle time 21:24:57 <glx> (and framerate window has an effect on drawing time too IIRC) 21:25:25 <nielsm> yeah the framerate window itself is somewhat slow to paint 21:25:32 <floodious> i'm using an external profiler, but i can't really trust the accuracy... just can say certainly the window being open does cost something, but not a huge amount 21:25:42 *** NGC3982 has joined #openttd 21:25:51 <nielsm> the console is absurdly slow to paint, when it has lots of text 21:26:08 *** gelignite has joined #openttd 21:29:15 <floodious> i said "less than 4%", that's confusing... i mean it nearly doubles the draw time being open, but it's less than double 21:29:30 <floodious> less than 4% of the total available processor time 21:30:01 <floodious> ... the 4 is just stupid, forget that 21:31:56 *** gelignite has quit IRC 21:32:09 <Samu> ticc/tocc is not triggering the message, :( 21:32:20 <Samu> must be doing it wrong 21:35:37 <Samu> the problem doesn't seem to be there glx 21:37:00 <andythenorth> nielsm: did you see my video of window-shading the fps window? :) 21:39:02 <nielsm> andythenorth, don't remember it no 21:39:43 <andythenorth> https://dev.openttdcoop.org/attachments/download/9560/fps-windowshade.m4v 21:39:48 <andythenorth> quite interesting 21:43:29 <glx> indeed, but I'm not surprised 21:43:54 <nielsm> drawing text is slow 21:44:10 <glx> and "dynamic" text is slower 21:44:37 <andythenorth> when are the glyphs converted to bitmaps? 21:44:46 <glx> on load 21:45:18 <glx> (and it somehow doesn't work correctly for zoomed GUI) 21:45:21 <Samu> dbg: [misc] [BuildSortIndustriesList] 913053 us [avg: 913053.0 us] - that's the spike I'm getting from time to time 21:46:27 <glx> begining of each month I guess 21:46:32 <glx> when production changes 21:46:43 <Samu> no, i mean almost every game day 21:47:50 <glx> oh every 100 ticks then 21:47:59 <floodious> can your tool measure peak? 21:48:11 <glx> it's a basic tic/toc 21:48:13 <floodious> mean + min + max are usually useful 21:48:37 <andythenorth> if the FPS text was redrawn less aggressively, would there be benefit? 21:48:46 <glx> I think you should get a similar result for town directory 21:48:59 <floodious> FPS should be drawn minimally once per second, or at the measurement frequency 21:49:49 <floodious> drawing the same string 30 times doesn't make much sense 21:50:06 <floodious> strcmp is much faster than draw 21:50:06 <glx> I think everything is drawn each tick 21:50:49 <glx> but the screen itself is not always really redrawn 21:50:51 <floodious> if (time_delta >= wait_period && strcmp(last_string, new_string) != 0) { draw(new_string); last_string = new_string; } 21:51:14 <Samu> doesn't seem to be about drawing the string 21:51:38 <glx> BuildSortTownList Samu maybe 21:52:45 <Samu> even with the game paused, there's still calls to BuildSortIndustriesList 21:52:57 <DorpsGek_III> [OpenTTD/OpenTTD] James103 commented on issue #7899: Slow framerates with town list window https://git.io/JepK9 21:53:08 <floodious> triggered from GUI, not from game loop 21:54:29 <DorpsGek_III> [OpenTTD/OpenTTD] SamuXarick commented on issue #7899: Slow framerates with town list window https://git.io/JepK9 21:57:25 <Samu> TICC TOCC is not available for town_gui.cpp, what's the include? 22:00:30 <nielsm> debug something 22:00:31 *** snail_UES_ has joined #openttd 22:00:40 <floodious> TownDirectoryWindow::BuildSortTownList() produces GUITownList towns{(size == 13142)} exactly the number displayed while generating the map 22:04:20 *** sla_ro|master has quit IRC 22:05:23 <nielsm> next silly feature: https://0x0.st/znBN.mp4 22:05:48 <nielsm> (people keep complaining about hitting the wrong things on the file list so I want to help them see where they're pointing at) 22:06:30 <floodious> hover highlights are good 22:06:59 <floodious> that's a feature that was in win3 and i've always missed it in anything without it 22:08:21 <LordAro> nielsm: nice! 22:08:30 <LordAro> not silly at all 22:08:37 <floodious> back in the day there would have been one programmer who worked on things like that on the os level, and i remember reading about the guy who worked for microsoft doing rough workflow studies by timing people with a stop watch and taking notes... frequency of missed clicks is reduced to near zero, and time spent navigating menus drops by more than 50% (IIRC) 22:09:04 <floodious> talking about modern "UX design" philosophies where "ugly" highlights are a no-go 22:09:08 <floodious> pure insanity of course 22:09:26 <nielsm> hover highlight for menu item under mouse pointer was added in win95, was not in 3.1 and earlier 22:09:52 <glx> remember the nice hard to point buttons on win9x 22:10:08 <floodious> i wasn't sure when i typed it, i can't remember... i think it was in certain software, i read the article a long time ago (2008?) 22:10:34 <floodious> i still use windows with a 9x style and always have :) 22:11:30 <glx> start button was easy to miss too, because of the free space around it 22:13:16 <floodious> ah, the focus is keyboard driven in win3 22:13:21 <floodious> no hover 22:13:46 <nielsm> you also get a highlight following the mouse if you click and hold a menu in win 3 22:13:48 <nielsm> iirc 22:15:01 <floodious> i've just tested it, not in the default win3 menus 22:15:42 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh opened pull request #7900: Add: Highlight item under mouse in file browser https://git.io/Jepid 22:15:52 <floodious> certain software may have implemented it though, i think i recall something like that "but X had it and I really noticed the improvement in timing, so I had people sit down and attempt certain tasks I created for them and timed them with a stop-watch ..." 22:16:48 <floodious> win3.11 program manager menu: https://i.imgur.com/Y4n35Kw.png 22:17:15 <floodious> maybe he was the lead UX guy for win95 22:22:58 <floodious> i wonder why, i never wrote code in the early 90s for win3, but i suspect maybe you couldn't get mouse-move messages if the button wasn't held 22:24:08 <glx> nielsm: there's no constant for PC_DARK_BLUE - 3 ? 22:24:28 <nielsm> glx I don't think so, but didn't look hard either 22:24:40 <LordAro> PC_NOT_QUITE_AS_DARK_BLUE 22:25:25 <nielsm> this is a terrible comment: 22:25:27 <nielsm> WID_SL_DRIVES_DIRECTORIES_LIST, ///< Drives list. 22:25:37 <nielsm> yes it does have drives, but it mainly has the files you're looking for 22:25:43 <nielsm> and directories to help you browse to the files 22:25:50 <nielsm> the constant name itself is also pretty bad 22:26:24 <glx> I think my first patch was for this window 22:26:39 <floodious> the list contains... there are so many names, folder entries? items? 22:26:45 <glx> or related to it 22:26:47 <floodious> i think "folder items" is common 22:27:31 <LordAro> DRIVES_AND_DIRECTORIES 22:27:50 <nielsm> the change I really want to make here is remove the drive letters from the list (on windows, and probably os/2 if that still works) and then put in a "jump to location" dropdown 22:28:13 <nielsm> where you can pick drives, various game-relevant directories, and various system relevant directories 22:28:57 <nielsm> just not sure where to put it 22:29:19 <floodious> unix = links, current, parent, entries (directories, files, ...?) 22:29:20 <nielsm> above or below the filter textbox? next to the sorting buttons (replacing the home button maybe)? 22:29:44 <nielsm> directories should stay in the main files list imo 22:30:00 <nielsm> including the .. entry 22:30:02 <glx> static const uint8 PC_DARK_BLUE = 0x9D; ///< Dark blue palette colour. 22:30:02 <glx> static const uint8 PC_LIGHT_BLUE = 0x98; ///< Light blue palette colour. 22:30:11 <glx> so yes no constant it seems 22:30:23 <glx> PC_MIDDLE_BLUE :) 22:30:31 <floodious> ideally you'd use dark-blue + 1/2 alpha or similar 22:30:46 <floodious> that would blend correctly with any color background 22:30:49 <glx> we're in paletted world 22:30:53 <floodious> except dark blue 22:31:39 <nielsm> and yes my intention was actually a darker blue, not a lighter... 22:31:59 <nielsm> I should maybe consider sleeping 22:33:11 <andythenorth> mmm sleep 22:33:17 * andythenorth stays up too late 22:34:03 <andythenorth> oof how do I find out if the lead vehicle is flipped 22:34:06 <andythenorth> and can I be arsed? :P 22:34:57 <nielsm> okay 0x9D and 0x98 are part of different gradients 22:35:03 <nielsm> https://newgrf-specs.tt-wiki.net/wiki/File:TTD_Palettes.png 22:35:13 <floodious> the high nibble is color and low is shade, isn't it? 22:35:22 <floodious> or 22:35:42 <floodious> ? == extern byte _colour_gradient[COLOUR_END][8];, 128 entries? 22:36:31 <floodious> so the low 3 bits = shade 22:36:39 <glx> indeed 0x9A is darker 22:36:49 <nielsm> not quite, see the palette image above 22:36:53 <nielsm> @ floodious 22:37:53 <floodious> so the hue/color table was maybe original intent or written by looking at the palette and trying to guess 22:38:00 <glx> the colours are not really ordered, but when there's a gradient (like company colours) they are contiguous 22:38:20 <Samu> w->OnHundredthTick(); 22:38:31 <glx> every 100 ticks :) 22:38:32 <nielsm> I'll make it PC_VERY_DARK_BLUE = 0x9A 22:38:36 <Samu> but it doesn't feel like it's every 100 ticks 22:38:58 <LordAro> @calc 100/74 22:38:59 <DorpsGek> LordAro: 1.35135135135 22:39:08 <LordAro> ^ number of days 22:39:15 <Samu> yeah, it happens every frame 22:39:31 <Samu> called by w->OnHundredthTick 22:39:38 <LordAro> seems unlikely 22:39:52 <Samu> it is 22:40:07 <Samu> seems to be measuring real time 22:40:09 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7900: Add: Highlight item under mouse in file browser https://git.io/Jepid 22:40:17 <Samu> not in-game tim 22:40:49 <Samu> and it takes 5 seconds in debug mode, that's how many ticks 22:40:55 *** snail_UES_ has joined #openttd 22:41:08 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7900: Add: Highlight item under mouse in file browser https://git.io/Jepid 22:47:12 <Samu> std::sort(std::vector<T>::begin(), std::vector<T>::end(), [&](const T &a, const T &b) { return desc ? compare(b, a) : compare(a, b); }); 22:47:25 <Samu> this takes 5500 ms in debug 22:47:38 <glx> it's sorting the list 22:47:40 <nielsm> yes microsoft's STL is slow in debug 22:47:47 <nielsm> very slow 22:47:56 <LordAro> debug build timings are not very interesting 22:47:57 <nielsm> you can turn iterator debugging off with something that I don't remember 22:47:57 <glx> and debug is never a good reference for timing 22:48:37 <floodious> quicksort performs poorly on specific types of data, but best/worst can't be improved very much without a lot of complexity, so it is what it is 22:48:52 <nielsm> but STL isn't quicksort 22:48:52 <floodious> randomly sorted data is worth, nearly is better 22:48:58 *** Pikka has joined #openttd 22:49:00 <floodious> it isn't? i forget the defaults 22:49:24 <nielsm> it's a hybrid algorithm that also performs well on almost-sorted data 22:49:45 <nielsm> intro-sort I think it's called 22:49:45 <LordAro> STL can be whatever it wants to be, iirc 22:49:50 <LordAro> technically speaking 22:49:58 <floodious> stl::sort defaults to quicksort or heapsort depending on data 22:50:33 <floodious> it's just a minor variation, basically quicksort family 22:50:53 <LordAro> https://en.cppreference.com/w/cpp/algorithm/sort "O(N·log(N)), where N = std::distance(first, last) comparisons." 22:51:09 <floodious> so it performs best with nearly sorted data... so when it's possible to sort once and keep the order, then sort again with updated values, that'll outperform a "from scratch" resort 22:51:37 <frosch123> you should watch the cppcon talk on stupidsort 22:51:58 *** syr has quit IRC 22:51:58 <floodious> so the sort would work on an index list like int index[towns], and re-sort that list from the town data rather than starting from scratch each time 22:52:00 <floodious> it might be faster 22:52:03 <nielsm> C++11 apparently requires an n log n algorithm? so quicksort is ruled out 22:52:24 <floodious> that's a bit irrelevant 22:52:25 <LordAro> pure quicksort, anyway 22:52:27 *** syr has joined #openttd 22:53:39 <floodious> index[towns] could be std::vector<int> and resize as needed when the size changes, triggering a resort from scratch (when a new town is added?), or more complicated it could insert the new town but would need to be available to all town creation functions 22:55:01 <floodious> that's the only way i can think to have a nearly-sorted input to speed up sorting 22:55:06 <floodious> otherwise impossible 22:55:38 <floodious> certain algorithms can dramatically outperform standard ones when you ensure the input is nearly sorted 22:56:15 <LordAro> bubble sort! 22:56:31 <floodious> i think bubble sort works best on less than 15 items, then it pops 22:56:39 <floodious> or was it 12 or 11 or something 22:58:47 <andythenorth> oof bed 22:58:48 *** andythenorth has left #openttd 23:00:31 *** frosch123 has quit IRC 23:00:50 <Samu> Name Total CPU [unit, %] Self CPU [unit, %] 23:00:50 <Samu> || - std::_Partition_by_median_guess_unchecked<Town const * *,std::_Ref_fn<`GUIList<Town const *,char const *>::Sort'::`9'::<lambda_1> > > 3677 (63,70%) 6 (0,10%) 23:00:59 <Samu> Name Total CPU [unit, %] Self CPU [unit, %] 23:00:59 <Samu> || - std::_Insertion_sort_unchecked<Town const * *,std::_Ref_fn<`GUIList<Town const *,char const *>::Sort'::`9'::<lambda_1> > > 1974 (34,20%) 1 (0,02%) 23:01:10 <Samu> Name Total CPU [unit, %] Self CPU [unit, %] 23:01:10 <Samu> || - std::_Debug_lt_pred<std::_Ref_fn<`GUIList<Town const *,char const *>::Sort'::`9'::<lambda_1> > &,Town const * &,Town const * &,0> 4701 (81,44%) 10 (0,17%) 23:01:17 <Samu> the 3 that took most time 23:01:37 <LordAro> stop measuring debug 23:01:42 <Samu> :( 23:02:37 <floodious> yeah the debug version also includes various sanity checks and is dramatically slower... a "better" algorithm can sometimes suddenly be worse when optimization is enabled since the "better" algo is less possible to optimize 23:02:50 <floodious> never profile debug code, ever ever ever 23:03:03 <floodious> assert(_NDEBUG) 23:03:38 <LordAro> also just the optimisations the compiler can do in general 23:04:14 <Samu> w->OnHundredthTick doesn't feel like it's on every 100 ticks, but every 1 tick 23:04:26 <floodious> does it reset the reference? 23:04:34 <LordAro> Samu: well look at the code, work it out 23:04:36 <floodious> reference/count/etc 23:04:43 <LordAro> random statements here aren't helping 23:05:00 <LordAro> it certainly *should* be every 100 ticks 23:05:25 <Samu> what ticks, real time ticks? 23:06:19 <FLHerne> ? 23:06:36 <Samu> how is it measuring the ticks? 23:06:40 <glx> game ticks 23:06:51 <Samu> doesn't look like that 23:06:57 <floodious> virtual void Window::OnHundredthTick() {} /* Called once every 100 (game) ticks. */ 23:07:23 <Samu> when game is paused, then yeah, it seems to be every 100 ticks 23:07:32 <floodious> it's a virtual function, so ensure the particular override[s] are functioning correctly (calling parent?) 23:07:35 <Samu> when it's running, it's doing every frame 23:07:45 <Samu> and it takes those said 5500 ms 23:07:57 <floodious> which object is w? 23:08:06 <Samu> the towngui window 23:08:21 <floodious> TownDirectoryWindow? 23:08:46 <Samu> openttd.exe!TownDirectoryWindow::OnHundredthTick() Line 959 23:08:46 <Samu> at D:\OpenTTD\OpenTTD GitHub\OpenTTD\src\town_gui.cpp(959) 23:09:09 <LordAro> not something i can replicate - the loop definitely calls OnHundredthTick (for every window) every 100 ticks 23:09:19 <floodious> other implementations don't seem to do anything fancy 23:09:47 <floodious> they all get called from the same sources which are responsible for the interval... which is at... 23:10:19 <LordAro> yeah, putting in a print at 959 still only results in an output every 100 ticks 23:10:48 <LordAro> so i don't know what you've done Samu, but it's either Windows only (exceedingly unlikely), or you've broken it in some way 23:11:05 <Samu> i put TICC/TOCC 23:11:14 <Samu> nothing else 23:11:39 <floodious> openttd_main(argc, argv) > VideoDriver_Win32::MainLoop() > UpdateWindows() > TownDirectoryWindow::OnHundredthTick() 23:12:05 <floodious> UpdateWindows() seems the only caller 23:12:36 <floodious> window.cpp ln 3179 23:12:47 <Samu> https://i.imgur.com/BZdDrYt.png 23:12:53 <Samu> and the debug.h 23:13:14 <floodious> it's using milliseconds realtime 23:13:16 <floodious> not using game ticks 23:13:33 <floodious> so if the measured game speed or framerate drops, it might call more often since the same actual time has passed 23:13:49 <LordAro> Samu: that is not OnHundredthTick 23:13:50 <floodious> static uint32 last_realtime_tick = _realtime_tick; uint delta_ms = _realtime_tick - last_realtime_tick; last_realtime_tick = _realtime_tick; 23:14:00 <floodious> opps why did i paste that 23:14:02 <LordAro> that is BuildSortTownList, which among other things, is called by OnPaint 23:14:14 <LordAro> so yeah, that function is called every tick 23:14:43 <Samu> OnPaint? never once I got it being called by the OnPaint 23:15:03 <Samu> it's always onHundrethTick, which is strage 23:15:27 <LordAro> hmm, OnPaint is guarded by an if 23:15:29 <LordAro> but still 23:15:37 <floodious> the bug is here: hundredth_timer.SetInterval(3000); // Historical reason: 100 * MILLISECONDS_PER_TICK 23:15:40 <floodious> it assumes 30 fps 23:15:44 <floodious> it's a constant 23:15:51 <floodious> it does not adapt to varied frame rate 23:16:12 <floodious> the slower the frame rate, the more it gets called per frame 23:16:16 <glx> oh nice spot 23:16:36 <glx> and more calls increase slow down 23:16:44 <LordAro> ah 23:16:45 <floodious> exponential bubble 23:16:58 <LordAro> something that got missed when GUI was split from gameloop 23:17:03 <Samu> forgive me i couldn't explain miself 23:17:13 <LordAro> or perhaps intentional, and the town directory window is doing The Wrong Thing 23:17:17 <LordAro> can't remember 23:17:28 <floodious> so we just need to fill the value instead of from the constant, re-compute every N frames (1000?) from the min FPS counter value 23:17:48 <Samu> seems u guys got this now, guess I'm off to bed 23:17:55 <Samu> take care 23:18:14 <floodious> or whatever... ten seconds = 3000 frames 23:18:26 <floodious> just use ten seconds then 23:18:32 *** Samu has quit IRC 23:19:57 <glx> window_timer.SetInterval(MILLISECONDS_PER_TICK); <-- this one may be wrong when everything is slower 23:20:26 <floodious> if it's still constant, it's still wrong 23:20:43 <glx> but it's less visible, it just set windows dirty 23:21:33 <floodious> GUI updates need to either happen: 1) in real-time factors, once per frame at most (limiting) or 2) upon only required updates, like if a string changes you _must_ mark it dirty to redraw on the next frame, or else immediately if it can't be updated based upon dirty state 23:21:37 <floodious> so a constant is the problem 23:21:55 <floodious> can't be a constant, must be computed from actual time, and limited to once per graphical redraw 23:22:15 <floodious> no point updating the status of a pure GUI element multiple times per screen update 23:22:34 <floodious> except in cases where there are side-effects, which ought to be moved elsewhere in the code 23:24:08 <floodious> set dirty is ... usually inherently once per frame, but it depends what is being redundantly re-set as dirty 23:24:44 <floodious> if the cost is even "bool dirty = true", multiply that by a billion and you have a problem 23:37:54 *** Wolf01 has quit IRC 23:41:25 <floodious> if as i said the factor were updated every ten seconds, that would set the worst-case recovery time from a low FPS event 23:41:33 <floodious> so it's probably better to use more like 100 ms or similar 23:41:59 <floodious> then if FPS is measured as 1/100th FPS for an instant, it'll only delay redraw 100 ms 23:43:07 <floodious> it should also be clamped both ways: only one update per frame (never until redraw finishes) and at some maximum rate set by the user such as 30 FPS or whatever 23:43:31 <floodious> otherwise the same problem exists when FPS runs too high, CPU time requirements build proportionately or worse 23:47:54 <nielsm> uh... are you imagining the thing runs on a separate thread? 23:48:07 <nielsm> because it does not, the entire UI is synchronous with the game code 23:48:19 <nielsm> when the UI is drawing, the game is not running behind it 23:49:17 <nielsm> how about this addition... https://0x0.st/znMo.png 23:49:27 <glx> on the driver side it's threaded IIRC 23:50:22 <nielsm> well, the server does not show GUI :P 23:52:55 <nielsm> https://github.com/nielsmh/OpenTTD/compare/fios-hover...nielsmh:fios-moredrives 23:53:04 <nielsm> probably won't PR that as-is 23:53:37 <nielsm> (especially since I don't know the full consequences of the windows version defs change)