IRC logs for #openttd on OFTC at 2020-01-04
⏴ go to previous day
00:00:46 <supermop_work_> then maybe beer
00:07:58 <Samu> well, it builds, but there's probably some bugs
00:13:43 <Samu> commit messages are much more readable too
00:14:39 *** andythenorth has left #openttd
00:15:24 <Samu> the only branch i was unable to add to this list was find-closest-reachable-ship-depot
00:15:49 <Samu> yapf has conflicts with the new multidock stuff
04:11:41 *** Wormnest has joined #openttd
06:01:14 *** ChanServ sets mode: +v tokai
09:07:42 *** Progman has joined #openttd
09:08:53 *** andythenorth has joined #openttd
09:17:04 <andythenorth> Horse Now Complete
09:18:33 <andythenorth> I had to delete my express EMUs though :(
09:20:56 <andythenorth> because OpenTTD is a very balanced game
09:21:27 <andythenorth> there are about 3 reasons, including 'really, enough trains'
09:21:37 <Pikka> that's a good reason I guess
09:21:41 <andythenorth> but the main problem is 'how fast should the mail EMU go?' :P
09:21:52 <andythenorth> and I can't be arsed to decide
09:22:19 <andythenorth> currently goes at freight train speed
09:22:35 <andythenorth> unless attached to a fast engine, then it goes faster
09:22:48 <Pikka> I made all my MUs refittable to mail, so... passenger speed I guess :)
09:25:21 <andythenorth> RL 100mph, Horse 87mph
09:25:39 <andythenorth> usually it's power creep, not a malus :)
09:26:48 *** sla_ro|master has joined #openttd
09:31:31 <andythenorth> oo NARS sprites :)
09:33:59 <Pikka> yep, not sure if they're useful or in the right style, but they exist, so... :)
09:34:10 <andythenorth> super helpful actually
09:34:20 <andythenorth> I have an irrational fear of drawing steam engines
09:34:36 <andythenorth> there's enough there to re-use if that's ok
09:34:57 <andythenorth> I don't reshade <->
09:35:01 <andythenorth> stopped a long time ago
09:35:08 <andythenorth> Simon Foster didn't either
09:35:25 <andythenorth> but only by paint bucket
10:21:14 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro requested changes for pull request #7817: Feature: Minimap screenshot https://git.io/JepBD
10:44:22 <andythenorth> nielsm: next, buttons that understand the vehicle tech tree :)
10: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
10:47:02 <nielsm> creating a cursor from a sprite is hard
10:59:40 <nielsm> and not less hard when I have almost no knowledge of getting the sprite pixel data
11: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
11:31:24 <andythenorth> so...vehicles get a 'more info' string? Accessible from buy menu and vehicle window?
11:31:32 <andythenorth> it opens a little window
11:32:38 <nielsm> I thought about thta the other day too, "extended description"
11:37:36 *** snail_UES_ has joined #openttd
11:43:45 <andythenorth> I want to do some stupid backstory for engines :)
11:43:50 <andythenorth> alternate history
11:43:54 <andythenorth> and some play tips
11:49:08 <andythenorth> but that could be in-game eh
11:49:15 * andythenorth wonders about a tech tree in-game :P
11:53:00 <nielsm> like "do you want highly specialised locos or do you want more general purpose" questions?
11: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
11:54:28 <andythenorth> something like that
11:54:29 <nielsm> one possibly interesting thing transport fever 2 allows in scenarios is (dynamic) build limits for certain vehicles
11:54:38 <andythenorth> I think it would have to depend on certain newgrfs
11:54:53 <nielsm> so you could make it impossible to just upgrade your entire fleet to the newest models all at once
11:55:09 <andythenorth> some Railroad Tycoon scenarios had 'choose your chief engineer' or 'choose your technology'
11:55:16 <andythenorth> and that affected tech tree
11:55:56 <andythenorth> it's only interesting in a goal-driven scenario I think, for sandbox it's not adding anything :
11:56:14 <nielsm> hmm, maybe in competitive multiplayer though?
11:56:41 <andythenorth> the tech tree is just a graph
11:57:23 <andythenorth> I had a version done with graphviz somewhere, but it's missing :)
11:57:41 <andythenorth> I already specify 'replacement vehicle ID' to work out expiry dates
11: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
11:57:50 <andythenorth> so with that, it's just working backwards to get the tree
11:58:02 <nielsm> all the trf2 campaign is fully of busywork like that
11:58:30 <andythenorth> I like the idea of freezing time, and unlocking engines by completing goals
11:58:36 <andythenorth> grind grind grind :P
11:59:56 <nielsm> :( I have no idea why my calls to the blitter are crashing
12:09:20 <nielsm> oh, uninited memory looks like it
12:09:36 <nielsm> adding a garbage value to a pointer will usually result in a garbage pointer
12:20:03 <nielsm> but it looks like calling the blitter is the wrong approach, and use GetRawSprite instead
12:20:19 <nielsm> (and GetSprite is useless since its format depends on the blitter)
12:34:08 <nielsm> hm no, GetRawSprite still feeds it through the blitter's encoder
12:40:06 <michi_cc> It allows to plug in a different sprite encoder if needed.
12:40:39 <michi_cc> Which I've been using to encode it as opengl texture.
12:50:28 <nielsm> hm yeah that probably makes the most sense really
12:50:45 <nielsm> just make an encoder that fills the windows dibsection bits directly
12:54:51 <nielsm> michi_cc: thanks for a clean commit that cherry-picks perfectly :)
12: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
12: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).
13:00:13 <michi_cc> Next 5 actually, you probably should remove unused cursors as the animated cursors will produce quite a lot of sprites.
13:29:47 <nielsm> argh why is MSVS so bad at keeping track of where the implementations of functions are
13:34:00 <michi_cc> You'd still have to skip the resize step though.
13:35:44 <nielsm> and really, I don't want the resize step for this patch either, since windows system cursors are limited to 48x48
13:36:10 <nielsm> or rather, I'll have to just discard the resized data again
13: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.
13:48:27 <michi_cc> E.g. the Autoroad cursor from openttdgui.png is 56x36 pixels large.
13:50:03 <nielsm> yeah... I have to do some weird stuff
14:01:09 <nielsm> uh wtf... this looks dangerously wrong?
14:01:39 <nielsm> struct Sprite consists of four fields with dimensions and offset, and then a pointer to byte data
14:01:53 <nielsm> the pointer to byte data is never initialised
14:02:16 <nielsm> but is just assumed to point to the extra memory allocated right behind it?
14:02:40 <nielsm> or am I totally misunderstanding what "byte foo[];" means?
14:09:08 <LordAro> nielsm: as a struct member it allocates an array as part of the struct, right?
14:09:26 <LordAro> if it's not a pointer
14:33:39 <nielsm> michi_cc: "C++ does not have flexible array members."
14:33:49 <nielsm> (well C++20 does, I think)
14:34:10 <nielsm> which is why all microsoft headers declares a member array of length 1
14:37:31 <nielsm> it looks like the code does compile as intended I see, but it's out of standard
14:47:04 <LordAro> nielsm: gcc does it, so gcc c++ gets it as well
14:55:02 <Pikka> approximately, andythenorth?
14:55:20 <Pikka> I thought brithorse was done? ;)
14:55:29 <andythenorth> something happened
14:56:20 <andythenorth> I figured out the fast EMUs :(
15:00:27 * andythenorth wonders if that train is in UKRS 2
15:01:00 *** frosch123 has joined #openttd
15:15:25 <Samu> how do I rebase up to a date?
15:15:48 <Samu> not the current one, but to something in the past
15:20:45 <nielsm> git rebase <revisionhash>
15:20:58 <nielsm> to stack the current branch on top of that hash
15: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
15:24:13 <nielsm> it's better than before
15:30:24 <LordAro> nielsm: ooi, what's the benefit of a native cursor?
15:30:56 <nielsm> moves even when the game is slow between frames
15:31:00 <nielsm> pretty much nothing else
15:31:07 <nielsm> it's probably not worth it at all
15:33:29 <nielsm> probably not going any further with it
15:37:09 <Pikka> not bad andythenorth :D
15:39:46 <Samu> i can't read through modules templates typedefs
15:40:05 <andythenorth> did we do daylength yet?
15:40:17 <andythenorth> by the time I've replaced all my trains, it's time to replace all my trains
15:40:29 <Samu> Feature: Multi-tile docks and docking points. conflicts with mine
15:40:30 <Samu> Fix #5713: Use pathfinder to find closest ship depot
15:41:46 <Samu> i dont know how to make it call the right module
15:44:13 <Samu> gonna try the rebase trick
15:56:28 <peter1138> Marylebone to Aylesbury for Dovetail's Train Simulator... £25 for the addon, and £36 for its dependency addons... I think not.
16:09:46 <Samu> I need a yapf code master
16:11:12 <Samu> class CYapfDestinationTileWaterT ruined my patch
16:11:23 <Samu> it now requires a destination tile which i don't have
16:11:37 <Samu> it's still searching for it
16:12:16 <Samu> it used to be class CYapfDestinationTileT
16:13:58 <Samu> i want it to call class CYapfDestinationAnyDepotShipT
16:14:14 <Samu> for computing estimates and checking if tile is a depot
16:14:28 <Samu> but it's using CYapfDestinationTileWaterT :(
16:15:29 <Samu> feels like my whole class CYapfDestinationAnyDepotShipT is unreachable, the breakdown in that code says it's not "linked"
16: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
16:18:44 <nielsm> the workaround is to do a complete rebuild
16: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
16: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
16: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
16:23:15 <Samu> nop, it's not a bug, it really isn't reachable (aka my code is a failure)
16: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
16:26:12 *** snail_UES_ has joined #openttd
16:26:15 <Samu> seems that i need to lend my code...
16:30:00 <Samu> wow, i think I solved it by accident
16:33:28 <Samu> I accidentally fixed it!
16:39:38 <LordAro> always nice when that happens
16:41:39 <Samu> problem is that I don't understand why it works
16:43:14 <LordAro> maybe you should try to understand it
16:43:32 <LordAro> otherwise you might find issues later
16:43:44 <LordAro> or indeed earlier, as a result of having understood it!
16:46:31 <Samu> i just changed line 330 in red to line 420 in green
16:47:47 <Samu> template, class, typedef, struct, it's all stuff that I don't yet comprehend
16:48:18 <LordAro> yapf is fairly difficult to understand for experienced programmers
16:50:54 <Samu> CYapfDestinationTileWaterT is still being called for cases where I'm not searching for closest ship depot, as I intended
16:51:30 <Samu> and CyapfDestinationAnyDepotShipT for depots
16:51:52 <Samu> CYapfDestinationTileT is still an incognita
16:53:43 <Samu> seems to be acting as a redirect
16:55:02 *** sla_ro|master has joined #openttd
16:55:05 <Samu> CYapfDestinationTileT redirects to either CYapfDestinationTileWaterT or CYapfDestinationAnyDepotShipT
17:15:22 <nielsm> should maybe turn up the heat a bit here, getting difficult to type right
17:25:13 *** Wormnest has joined #openttd
17:50:51 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh opened pull request #7898: Feature: Script API to change town rating of companies https://git.io/Jep2F
18:17:07 <LordAro> nielsm: feel like giving ^ a last look over?
18:19:15 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7898: Feature: Script API to change town rating of companies https://git.io/JepaR
18:19:47 <LordAro> also reviewing any of my other PRs :p
18:23:13 <nielsm> hmm... I think I made the change rating API available to AI too...
18:23:26 <nielsm> (it won't work but it shouldn't be there)
18: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
18:25:04 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7898: Feature: Script API to change town rating of companies https://git.io/Jep2F
18: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
18: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
18:41:37 <LordAro> nielsm: hmm, i would expect "@api game" to make it only available for game (something like `@api ai game` for both)
18:41:55 <nielsm> yeah me too, I'm not sure why it works like that
18:42:38 <LordAro> #notactuallyblamingTBpleasedontkickmeagain
18: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
18:46:15 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7898: Feature: Script API to change town rating of companies https://git.io/JepVO
18:57:49 *** snail_UES_ has joined #openttd
19:06:47 <nielsm> the second and third commit message are very long
19:06:53 <nielsm> but I don't want to squash it either
19:07:17 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh merged pull request #7898: Feature: Script API to change town rating of companies https://git.io/Jep2F
19:11:38 *** andythenorth has joined #openttd
19:14:41 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #7000: Some NewGRF variables concerning railtypes https://git.io/JepVp
19:45:48 <DorpsGek_III> - Update: Translations from eints (by translators)
19:51:50 <frosch123> nielsm: why does it need a memcpy? isn't a static_cast just fine?
20:01:10 *** floodious has joined #openttd
20: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
20: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
20:02:25 <frosch123> hold Ctrl when cloning
20:02:27 <nielsm> are you sure you're holding Ctrl?
20:02:38 <floodious> shouldn't that behavior be reversed?
20:02:47 <floodious> ctrl = copy, no ctrl = clone
20:03:09 <nielsm> that would be dangerous to do now after 10+ years
20:03:20 <floodious> weird decision if it requires ctrl to actually clone though
20:03:29 <frosch123> it's the same as when copying orders
20:03:39 <frosch123> no ctrl = copy, ctrl = share
20:04:12 <floodious> i guess that's a future issue for an improved keyboard/input configuration system
20:05:25 <frosch123> just remap caps lock to ctrl lock
20: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"
20:06:52 <floodious> so i was looking at making other GUI changes for myself by adding a group command like "share orders to group"
20:07:08 <floodious> anyway the ctrl thing answered my question there, so no worry
20:07:33 <frosch123> copy clone, share clone
20:07:51 <floodious> i'd call it "clone clone", since the shared order list is actually empty
20:07:56 <frosch123> copy clone is useful if you want the same train on a different route
20: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
20: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"
20: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
20:11:40 *** snail_UES_ has joined #openttd
20:11:56 <floodious> the DAW host Reaper is a good example of such a system
20:12:57 <floodious> bad example of good workflow in the configuration GUI though
20:15:48 <floodious> this is 20% complete
20: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
20: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
20:19:58 <floodious> i've also implemented water (oceans + lakes + rivers) = blue, and forest/plant density (moisture) = green layers from RGB
20: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
20:21:33 <nielsm> make sure old heightmaps still give the expected output :)
20:21:36 <floodious> i've got all the river + lake polygon measurements but have yet to write the code to decode/translate them
20:21:51 <floodious> yep of course a backward compatible mode would be part of it
20: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
20:23:11 <floodious> openttd doesn't handle realistic forests well, runs incredibly slow on 4kx
20:25:39 <floodious> looks nasty c-style
20:25:48 <floodious> but roughly similar ideas
20:26:05 <floodious> i need to finish my implementation and benchmark it, it'll likely be many times faster than the original code
20:26:44 <floodious> seems 2x already but hard to say... the "running tileloop" now takes 10x longer than any other step
20:28:24 *** Xaroth4 is now known as Xaroth
20:38:09 <floodious> that's all well and good, but i think the code is horribly convoluted and hard to read
20: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
20:40:04 <floodious> the idea of using n-colored paletted single layer PNG is horribly inefficient too
20:40:49 <floodious> i'm trying to eliminate some of the translation steps between real scientific datasets and the formats
20:42:17 <floodious> improved code should be smaller and easier to read, not larger and more convoluted
20: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
20: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
20:49:35 <floodious> heaps of issues, but the baseline "import scientific datasets including height + sea + lakes + rivers" is working well
20: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
20:55:35 <floodious> PNG is a nasty format that was obsolete before it began
21:07:53 <planetmaker> floodious, when speaking scenario description format, "processor friendly" is certainly the last thing to consider.
21:09:33 <planetmaker> (generally 'efficiency' in one-time operations is a thing to disregard unless you stray far into the domain of inefficient)
21:09:37 <nielsm> well when you're making a scenario, having a faster modify-test cycle is definitely better
21: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
21:10:16 <planetmaker> which depends more on an easy-to-use format for the user than "processor friendly format"
21:10:42 <floodious> i spend 99% of my time making tea ATM
21: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
21:12:13 <floodious> using bytes is crazy slow
21: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)
21:12:59 <nielsm> a format that requires special tooling to create is a huge negative
21: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.
21: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
21:14:28 <planetmaker> That would allow to import any colour-coded GIS data as well (e.g. height info)
21:15:26 <planetmaker> well, yes. But I don't see OpenTTD gaining an import for typical GIS data... TIFF... maybe, depends
21: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
21: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!)
21:16:47 <glx> I remember TrueBrain writing a tool to generate heightmap from scientific data
21: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
21:18:06 <floodious> like truncation, where TTD's format requires 0 = ocean, so x>0 needs to be truncated up to 1
21:18:20 <floodious> but graphical tools assume "black is black is black"
21:18:21 <planetmaker> There's two things, one OpenTTD, one not:
21: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.
21:19:15 <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
21:19:43 <floodious> tools are needed to go from the raw scientific data to the png, but that's a given really
21: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)
21:20:32 <floodious> database formats are probably the best for data like roads+rivers+cities+signs etc, using existing open-source libs
21:20:52 <floodious> since free tools to manage that data exist, and most of the source data is already in such a format
21: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
21:22:21 <floodious> 16-bit png solves all the steps of TIFF to 8-bit
21:22:42 <floodious> standard tools can losslessly convert 16-bit TIFF to 16-bit png and combine planes
21:23:30 <glx> the best thing to have, I think, is a generic image format with specific color data
21: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
21:24:28 <floodious> ASTER is in 16-bit TIFF
21:25:00 <glx> then you can have tools to convert a given format to the format supported but OpenTTD
21:25:18 <floodious> nope, open-ttd requires special steps
21:25:33 <floodious> such tools don't exist generally speaking, such as the ocean = 0 "black is black is black" issue i mentioned
21: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
21:26:52 <floodious> and openttd lacks definite standards, but ought to have some for "1 height unit" and "1 tile unit"
21:27:32 <floodious> such as "1 height unit = 20 meters"
21: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
21: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
21:30:11 <planetmaker> a tile is the length of a vehicle. And towns are separated 20 vehicle lengths
21:30:17 <floodious> that's true, but starting with a reasonable standard that approximately fits the existing scales would be a good idea
21:31:04 <glx> that's the job of an external tool for me
21:31:09 <andythenorth> what's the highest plausible heightmap RL?
21:31:42 <planetmaker> what's the height of a heigth map? max - min [in metres]?
21:31:52 <planetmaker> then probably my Marsian map :)
21:31:56 <floodious> ASTER data uses 10 meter units, for example
21:32:16 <planetmaker> from the depth of Hellas basin to the top of Olympus mons it's more than 20km height difference
21: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
21:33:00 <planetmaker> we will not standardize those values or set a value which we tell "use this"
21:33:13 <floodious> then you'll never get any improvements to anything related
21:33:23 <floodious> because it all starts with standardizing one unit, and building from that
21:33:38 <floodious> one unit = standardizes everything, in time
21:33:51 <glx> train scale != RV scale != boat scale != plane scale
21: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
21:34:10 <floodious> i'm not sure why you're extending this so extremes
21:34:37 <floodious> just having a rough "1 tile has no definite dimension, but is assumed to be approximately X"
21:34:38 <planetmaker> you're not the first person asking "what's the scale".
21:34:42 <floodious> guides other decisions
21:34:44 <planetmaker> And all those answers are correct
21:34:55 <planetmaker> And there's no way to make one correct and obsolete the others
21:35:05 <floodious> i know the scale is kids toyland, that's obvious when a train takes up the same size as a skyscraper
21:35:23 <planetmaker> yes. But then... how can you even define a scale?
21: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"
21: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
21:36:12 <glx> depending on the newgrf used, vehicles have different scales
21:36:21 <floodious> and the range includes all those dimensions
21:36:27 <floodious> giving a definite "min-max" scale
21:37:09 <floodious> even "1 ft to 1000 ft" makes design decisions way more easy
21:37:09 <planetmaker> well. One tile ranges from like 5m (vehicle scale) to 5km (landscape regions scale)
21:37:29 <planetmaker> so it varies by a factor of 1000
21:38:01 <floodious> so that ought to be documented, "approximately ..." and tables can be built to show examples of ranges and outliers
21: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
21:39:47 <planetmaker> not trains. Road vehicles :)
21:39:49 <floodious> 4096 x 5 = 20.48 km
21:40:01 <planetmaker> For trains... a tile probably is like 15...25 metres
21:40:24 <floodious> a standard gauge track is about 1.5 meters, plus the width of the foundation and keepers
21:40:33 <planetmaker> from the vehicle perspective. Yes, long. Wide... it's like 5m :P
21:40:36 <floodious> so 5 meters might be a good guess
21:41:22 <floodious> assuming it's in some flat california wasteland salt flats or whatever
21:41:29 <andythenorth> 8/8 is 32px is 60ft in my pixel world
21:41:33 <andythenorth> it's not very exact though
21:41:44 <andythenorth> (vehicle lengths)
21:41:53 <DorpsGek> planetmaker: Error: invalid syntax (<string>, line 1)
21:42:05 <glx> andythenorth: and other grf authors use their own different scale
21:42:05 <floodious> length is hard, since tiles are square and the proportions for width + length are so stretched
21:42:17 <floodious> that's why i'm focusing on known minimums
21:42:45 <Samu> max height, in openttd tileh is 255, and 0 is water
21:42:49 <floodious> a standard gauge train might be 3 meters, or 5 meters, or 12 meters wide
21:43:05 <floodious> hugely varied... i don't know enough to say but i've been on a few
21:44:23 <floodious> the legal limits in various regions might guide a bit
21:44:46 <floodious> "maximum US standard gauge car width" or similar
21:46:39 <andythenorth> glx: and ships and RVs are to a different scale
21:46:39 <DorpsGek> LordAro: Error: inm is not a valid unit.
21:46:40 <floodious> looks like 3 meters is a good guess
21:46:47 <andythenorth> it's all just like Lego City
21:46:51 <andythenorth> nothing is to scale
21:47:13 <floodious> so 3x18, what's the real length of a typical mid-century car?
21:47:14 <LordAro> and i still got it wrong the first time
21:47:33 <floodious> since the length is limited to something like 20 meters to deal with curves
21:47:38 <floodious> 18 might be spot on
21:48:10 <planetmaker> hehe @LordAro :) I knew that it could do it somehow... tyvm
21:48:38 <planetmaker> curves... are somewhat unrelatistic in OpenTTD :)
21:48:43 <planetmaker> especially for trains
21:48:45 <floodious> yeah, don't exist haha
21:49:03 <planetmaker> oh, for everything but trains they do exist :)
21:49:11 <planetmaker> at least visually
21: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
21:49:53 <floodious> and assuming a square tile is "stretched" according to direction of travel, due to the openttd space-time warp
21:50:21 <Samu> town directory is suddenly slow :(
21: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
21:50:37 <planetmaker> if you're not drawing graphics, you can savely ignore that
21:51:07 <planetmaker> the difference x or + directions is not that big
21:51:17 <floodious> i think it's pretty huge
21:51:25 <floodious> assuming realistic gauge it's nuts
21:51:32 <planetmaker> less than factor 1.5
21:51:44 <floodious> like 20 meter width to 200 km length
21: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
21:52:28 <Samu> guys, test this: create a 4096x4096 map with high number of towns, then open town list... it's slow!!!
21:52:43 <floodious> yeah everything is slow as heck, since the default generator is bugged
21:52:50 <glx> Samu: many strings to formal
21:52:55 <floodious> it creates way too many towns since it scales linearly
21:53:13 <floodious> and each time you increase by 2 (128, 256, 512) you're going by 4x towns
21:53:21 <Samu> it's not happening in 1.9.3
21:53:25 <glx> (and strings are not cached, so recreated on each draw)
21:53:41 <glx> yes, because 16 in/out cargos
21:54:07 <Samu> also 1.9.3 doesn't have a filter
21:54:11 <Samu> could it be the name filter?
21: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
21:56:11 <floodious> like using stl and boost stuff with known log(N) times
21:56:27 <floodious> rather than linearly iterating through the items
21:56:50 <Samu> do i report it as a bug?
21:56:51 <floodious> it's probably doing some foreach(town) { update(town, x); }
21:57:00 <glx> I think the slowest part is getting the max length
21:57:00 <floodious> not a bug, just lack of a feature to cope
21:57:48 <floodious> update(town, x) might have { foreach (town, t) { if (t != this_town) { ... } }
21:58:06 <glx> but it's not really a bug, just a poorly optimised window
21:58:32 <floodious> it probably needs to only iterate through the displayed towns, rather than updating all of them
21:58:43 <LordAro> i think idle speculation is useless
21:58:57 <floodious> well, reading the code i'd come back in an hour
21:59:10 <floodious> but it's definitely a (N^x) issue
21:59:54 <glx> but I think I probably noticed it when I updated the code to support 16 in/out
22:01:11 <Samu> indsutry window has some spikes
22:01:19 <Samu> 110 ms kind of noticeable
22:05:47 <Samu> industry directory has some noticeable spikes from time to time
22:06:35 <Samu> ok let me try the TICC/TOCC strategy, brb
22:10:51 <glx> town list is ressorted every 100 ticks it seems
22:11:41 <nielsm> that's something that could be threaded really
22:13:01 <glx> hmm but real rebuild is done only if needed
22:13:29 <glx> oh no, sorting is done each call
22:14:29 <glx> depending on the sorter that can be massive
22: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
22:14:52 <glx> for town names I guess it's not noticeable as order won't change
22:15:09 <glx> but for population it's different
22:15:46 <LordAro> floodious: when you're running at 30fps, ms scale is still quite slow :p
22:16:11 <planetmaker> the bane of RT processing :)
22:16:28 *** y2kboy23 has joined #openttd
22:16:44 <floodious> i work in audio/DSP, so ms scale is awful to me
22:16:51 <floodious> but, 60 fps = 16.666 ms
22:16:59 <floodious> if it takes 1ms, that's 1/16th time
22:17:11 <nielsm> the frame budget in ottd is 30 ms
22:17:27 <floodious> then it's 33.333 ms
22:17:32 <glx> 30ms for world simulation and window drawings
22:17:50 <planetmaker> basically *everything* :)I
22:18:06 <nielsm> no the budget is 30 ms
22:18:10 <nielsm> the framerate is 33.333
22:18:59 <floodious> anyway measuring the sort time max after 1000 attempts or so should give the actual time
22:19:45 <planetmaker> that exists as information window... niels wrote that :D
22:20:02 <glx> anyway 30ms is harder to do on a 4kx4k map
22:20:16 <nielsm> gfx_type.h defines MILLISECONDS_PER_TICK = 30
22:20:25 <nielsm> that's the basis for the game's timing
22:21:19 <planetmaker> which really is an odd number :) But nicely inconsumerable with everything else
22: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
22:21:53 <glx> Samu: debug or release build ?
22:22:08 <floodious> there is a significant cost but it's less than 4% of usual frame update for me
22:22:38 <floodious> 4 becomes 8 with the list open
22:24:57 <glx> (and framerate window has an effect on drawing time too IIRC)
22:25:25 <nielsm> yeah the framerate window itself is somewhat slow to paint
22: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
22:25:42 *** NGC3982 has joined #openttd
22:25:51 <nielsm> the console is absurdly slow to paint, when it has lots of text
22:26:08 *** gelignite has joined #openttd
22: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
22:29:30 <floodious> less than 4% of the total available processor time
22:30:01 <floodious> ... the 4 is just stupid, forget that
22:32:09 <Samu> ticc/tocc is not triggering the message, :(
22:35:37 <Samu> the problem doesn't seem to be there glx
22:37:00 <andythenorth> nielsm: did you see my video of window-shading the fps window? :)
22:39:02 <nielsm> andythenorth, don't remember it no
22:39:48 <andythenorth> quite interesting
22:43:29 <glx> indeed, but I'm not surprised
22:44:10 <glx> and "dynamic" text is slower
22:44:37 <andythenorth> when are the glyphs converted to bitmaps?
22:45:18 <glx> (and it somehow doesn't work correctly for zoomed GUI)
22:45:21 <Samu> dbg: [misc] [BuildSortIndustriesList] 913053 us [avg: 913053.0 us] - that's the spike I'm getting from time to time
22:46:27 <glx> begining of each month I guess
22:46:43 <Samu> no, i mean almost every game day
22:47:59 <floodious> can your tool measure peak?
22:48:13 <floodious> mean + min + max are usually useful
22:48:37 <andythenorth> if the FPS text was redrawn less aggressively, would there be benefit?
22:48:46 <glx> I think you should get a similar result for town directory
22:48:59 <floodious> FPS should be drawn minimally once per second, or at the measurement frequency
22:49:49 <floodious> drawing the same string 30 times doesn't make much sense
22:50:06 <floodious> strcmp is much faster than draw
22:50:06 <glx> I think everything is drawn each tick
22:50:49 <glx> but the screen itself is not always really redrawn
22:50:51 <floodious> if (time_delta >= wait_period && strcmp(last_string, new_string) != 0) { draw(new_string); last_string = new_string; }
22:51:14 <Samu> doesn't seem to be about drawing the string
22:51:38 <glx> BuildSortTownList Samu maybe
22:52:45 <Samu> even with the game paused, there's still calls to BuildSortIndustriesList
22:53:08 <floodious> triggered from GUI, not from game loop
22:57:25 <Samu> TICC TOCC is not available for town_gui.cpp, what's the include?
23:00:30 *** snail_UES_ has joined #openttd
23:00:40 <floodious> TownDirectoryWindow::BuildSortTownList() produces GUITownList towns{(size == 13142)} exactly the number displayed while generating the map
23: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)
23:06:30 <floodious> hover highlights are good
23:06:59 <floodious> that's a feature that was in win3 and i've always missed it in anything without it
23: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)
23:09:04 <floodious> talking about modern "UX design" philosophies where "ugly" highlights are a no-go
23:09:08 <floodious> pure insanity of course
23:09:26 <nielsm> hover highlight for menu item under mouse pointer was added in win95, was not in 3.1 and earlier
23:09:52 <glx> remember the nice hard to point buttons on win9x
23: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?)
23:10:34 <floodious> i still use windows with a 9x style and always have :)
23:11:31 <glx> start button was easy to miss too, because of the free space around it
23:13:16 <floodious> ah, the focus is keyboard driven in win3
23:13:46 <nielsm> you also get a highlight following the mouse if you click and hold a menu in win 3
23:15:01 <floodious> i've just tested it, not in the default win3 menus
23:15:42 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh opened pull request #7900: Add: Highlight item under mouse in file browser https://git.io/Jepid
23: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 ..."
23:17:15 <floodious> maybe he was the lead UX guy for win95
23: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
23:24:08 <glx> nielsm: there's no constant for PC_DARK_BLUE - 3 ?
23:24:28 <nielsm> glx I don't think so, but didn't look hard either
23:24:40 <LordAro> PC_NOT_QUITE_AS_DARK_BLUE
23:25:25 <nielsm> this is a terrible comment:
23:25:27 <nielsm> WID_SL_DRIVES_DIRECTORIES_LIST, ///< Drives list.
23:25:37 <nielsm> yes it does have drives, but it mainly has the files you're looking for
23:25:43 <nielsm> and directories to help you browse to the files
23:25:50 <nielsm> the constant name itself is also pretty bad
23:26:24 <glx> I think my first patch was for this window
23:26:39 <floodious> the list contains... there are so many names, folder entries? items?
23:26:47 <floodious> i think "folder items" is common
23:27:31 <LordAro> DRIVES_AND_DIRECTORIES
23: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
23:28:13 <nielsm> where you can pick drives, various game-relevant directories, and various system relevant directories
23:28:57 <nielsm> just not sure where to put it
23:29:19 <floodious> unix = links, current, parent, entries (directories, files, ...?)
23:29:20 <nielsm> above or below the filter textbox? next to the sorting buttons (replacing the home button maybe)?
23:29:44 <nielsm> directories should stay in the main files list imo
23:30:00 <nielsm> including the .. entry
23:30:02 <glx> static const uint8 PC_DARK_BLUE = 0x9D; ///< Dark blue palette colour.
23:30:02 <glx> static const uint8 PC_LIGHT_BLUE = 0x98; ///< Light blue palette colour.
23:30:11 <glx> so yes no constant it seems
23:30:31 <floodious> ideally you'd use dark-blue + 1/2 alpha or similar
23:30:46 <floodious> that would blend correctly with any color background
23:31:39 <nielsm> and yes my intention was actually a darker blue, not a lighter...
23:31:59 <nielsm> I should maybe consider sleeping
23:33:17 * andythenorth stays up too late
23:34:03 <andythenorth> oof how do I find out if the lead vehicle is flipped
23:34:06 <andythenorth> and can I be arsed? :P
23:34:57 <nielsm> okay 0x9D and 0x98 are part of different gradients
23:35:13 <floodious> the high nibble is color and low is shade, isn't it?
23:35:42 <floodious> ? == extern byte _colour_gradient[COLOUR_END][8];, 128 entries?
23:36:31 <floodious> so the low 3 bits = shade
23:36:49 <nielsm> not quite, see the palette image above
23:37:53 <floodious> so the hue/color table was maybe original intent or written by looking at the palette and trying to guess
23:38:00 <glx> the colours are not really ordered, but when there's a gradient (like company colours) they are contiguous
23:38:32 <nielsm> I'll make it PC_VERY_DARK_BLUE = 0x9A
23:38:36 <Samu> but it doesn't feel like it's every 100 ticks
23:38:59 <DorpsGek> LordAro: 1.35135135135
23:39:15 <Samu> yeah, it happens every frame
23:39:31 <Samu> called by w->OnHundredthTick
23:40:07 <Samu> seems to be measuring real time
23:40:09 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7900: Add: Highlight item under mouse in file browser https://git.io/Jepid
23:40:49 <Samu> and it takes 5 seconds in debug mode, that's how many ticks
23:40:55 *** snail_UES_ has joined #openttd
23:41:08 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7900: Add: Highlight item under mouse in file browser https://git.io/Jepid
23: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); });
23:47:25 <Samu> this takes 5500 ms in debug
23:47:40 <nielsm> yes microsoft's STL is slow in debug
23:47:56 <LordAro> debug build timings are not very interesting
23:47:57 <nielsm> you can turn iterator debugging off with something that I don't remember
23:47:57 <glx> and debug is never a good reference for timing
23: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
23:48:52 <nielsm> but STL isn't quicksort
23:48:52 <floodious> randomly sorted data is worth, nearly is better
23:49:01 <floodious> it isn't? i forget the defaults
23:49:24 <nielsm> it's a hybrid algorithm that also performs well on almost-sorted data
23:49:45 <nielsm> intro-sort I think it's called
23:49:45 <LordAro> STL can be whatever it wants to be, iirc
23:49:58 <floodious> stl::sort defaults to quicksort or heapsort depending on data
23:50:33 <floodious> it's just a minor variation, basically quicksort family
23: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
23:51:37 <frosch123> you should watch the cppcon talk on stupidsort
23: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
23:52:03 <nielsm> C++11 apparently requires an n log n algorithm? so quicksort is ruled out
23:52:25 <floodious> that's a bit irrelevant
23:52:25 <LordAro> pure quicksort, anyway
23: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
23:55:01 <floodious> that's the only way i can think to have a nearly-sorted input to speed up sorting
23:55:06 <floodious> otherwise impossible
23:55:38 <floodious> certain algorithms can dramatically outperform standard ones when you ensure the input is nearly sorted
23:56:31 <floodious> i think bubble sort works best on less than 15 items, then it pops
23:56:39 <floodious> or was it 12 or 11 or something
23:58:48 *** andythenorth has left #openttd
continue to next day ⏵
