Log for #openttd on 4th January 2020:
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
07:18:37  <DorpsGek_III> [OpenTTD/OpenTTD] telk5093 commented on pull request #7817: Feature: Minimap screenshot
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>
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>
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
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
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
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 might give some cursour inspiration.
11:19:09  <michi_cc> And as the preparation step.
11:19:38  <michi_cc> Ah, and 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> 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>
11:35:19  <nielsm> ._.
11:36:31  <LordAro> nielsm: perfection.
11:39:52  <michi_cc> nielsm: I've missed 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 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:
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>
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:
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
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
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?
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...
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>
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>
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)
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)
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)
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)
15:23:45  <Samu> [img]
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>
15:45:29  <Samu> sec, these lines are highlithed
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!
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
16:50:51  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh opened pull request #7898: Feature: Script API to change town rating of companies
16:57:14  <DorpsGek_III> [OpenTTD/OpenTTD] telk5093 commented on pull request #7817: Feature: Minimap screenshot
17:16:50  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7817: Feature: Minimap screenshot
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
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
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
17:25:04  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7898: Feature: Script API to change town rating of companies
17:35:23  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh approved pull request #7884: Fix #6667: Also recalculate bridge costs for 'spectated' AI companies
17:41:18  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh approved pull request #7894: Fix #7587: Crash when loading saves with waypoints with invalid locations
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.
17:46:14  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7898: Feature: Script API to change town rating of companies
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
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
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
18:16:46  *** snail_UES_ has quit IRC
18:32:46  <Samu> uploaded LuDiAI AfterFix 13
18:32:56  <NGC3982> oh im still here
18:33:03  <Samu> minor fixes only
18:40:41  <Samu> changelog
18:45:48  <DorpsGek_III> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
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:
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:
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>
19:28:01  <andythenorth>
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>
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>
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 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]
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] - 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> 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
21:05:47  <Samu> industry directory has some noticeable spikes from time to time
21:06:00  <glx> for indstry directory is mostly because
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>
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
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
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:
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
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:
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: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>
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
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
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> "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>
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...
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>
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)

Powered by YARRSTE version: svn-trunk