IRC logs for #openttd on OFTC at 2024-02-24
⏴ go to previous day
00:02:52 <peter1138> Silly clangd adding includes all over the place :/
00:04:29 <talltyler> Oh LordAro already approved
00:04:41 <peter1138> Damn it, another forced-death-on-exit map 😦
00:08:16 <_glx_> peter1138: that's why I rename my folder when testing
00:10:08 <LordAro> talltyler: just as well you did, i've just spent 4 hours in a pub
00:13:24 <peter1138> _glx_: I did, and then I was just about to rename it back, but removed the wrong one.
00:14:12 <_zephyris> LordAro: Someone has to test the beer!
00:15:01 <peter1138> Never mind, wasn't anything too important in it.
00:19:31 <_zephyris> Ship pathfinder blog post looks good for tomorrow
00:19:47 <_zephyris> Does it need a Steam image?
00:20:42 <peter1138> Hmm, github API timeouts :S
00:33:36 <peter1138> Starting OpenTTD with "xinit openttd" is pretty hardcore.
00:40:12 <ajmiles> I've just realised the second plane in the main menu is the plane's shadow, but drawn as if its a normal plane. Duh
02:11:23 <talltyler> `SHADE_LIGHTEREST` 😄
02:43:21 <_rei4122> xarick: Hmm... It does not occur here.
02:45:11 *** herms has quit IRC (Ping timeout: 480 seconds)
02:50:36 *** Wormnest has quit IRC (Quit: Leaving)
02:55:30 *** gelignite has quit IRC (Ping timeout: 480 seconds)
03:30:22 <ajmiles> Does the 8-bit anim buffer serve any purpose beyond being an optimisation? I wrote the GPU blitter initially with a 4 channel `dst` and a 1 channel `anim` buffer, but having colour encoded only the anim buffer and 0 in the dst buffer means I can't alpha blend onto the colour already laid down (as it isn't there)
03:31:09 <ajmiles> I'm wondering whether I should just get rid of the anim buffer and just deal with 32-bit dst and always convert/remap `m` to a full colour at every opportunity.
03:32:50 <ajmiles> If its only purpose was to make a CPU blitter faster, and I don't care about that, then maybe I should just rid of it.
03:58:41 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:00:57 *** gnu_jj_ has joined #openttd
04:04:20 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
04:16:10 *** Leopold___ has joined #openttd
04:21:16 *** Leopold_ has quit IRC (Ping timeout: 480 seconds)
05:55:39 *** geli has quit IRC (Quit: Stay safe!)
06:02:00 *** Leopold has joined #openttd
06:02:09 *** Leopold___ has quit IRC (Remote host closed the connection)
06:07:37 *** Leopold has quit IRC (Remote host closed the connection)
06:08:44 *** Leopold has joined #openttd
06:46:22 *** Leopold has joined #openttd
07:10:44 *** HerzogDeXtEr has joined #openttd
07:33:14 <ajmiles> I got scrolling working 99%. I had to implement the ScrollBuffer part of the blitter, but there's still something not quite right. When I scroll near industries, it's like there's a little portal around them that scrolls on a delay, and I'm not sure what that is yet, hopefully I can figure that out after sleep. But definitely improving. Having a mouse cursor even if it's streaky on the screen
07:49:04 <reldred> Rectangular, like 3x1 aspect ratio? It's probably something to do with the industry viewport
07:50:00 <reldred> Oooh no, that's a very different shape
08:10:11 *** zero2474 has joined #openttd
08:10:11 <zero2474> Newbie question: If I make some changes in only one source file, do I have to build the whole project or is there a way to just patch the changes to already built project in the build directory ?
08:15:44 *** Extrems` has joined #openttd
08:16:32 *** dwfreed_ has joined #openttd
08:18:42 *** Extrems has quit IRC (resistance.oftc.net weber.oftc.net)
08:18:42 *** esselfe has quit IRC (resistance.oftc.net weber.oftc.net)
08:18:42 *** dwfreed has quit IRC (resistance.oftc.net weber.oftc.net)
08:18:42 *** Extrems` is now known as Extrems
08:20:04 <reldred> If you're using something like VS Code that's pretty much exactly what it does.
08:20:32 <reldred> Don't know about other build systems
08:20:46 <reldred> Try it without doing a make clean and see what happens.
09:03:49 <andythenorth> hmm this "faster" is not faster enough
09:04:32 <andythenorth> ok STORE_TEMP is expensive in nml
09:05:12 <merni> zero2474: If you're building on Linux using cmake, once you build the first time later builds will just compile the changes
09:05:15 <andythenorth> I was diligently initialising 20 registers to a safe null value before writing to 20 **or fewer** of them with actual values
09:05:28 <andythenorth> but per variant, that's really expensive in nml processing time
09:05:36 <merni> Unless you change a lang file or some other things that trigger a full recompile
09:05:55 <andythenorth> hmm 8MB of nml removed, and 1s of compile time
09:16:07 <kuhnovic> Do I need to do anything for the blog post, or is it good to go?
09:19:37 <truebrain> Update the time plz 🙂
09:20:14 <truebrain> Owh, and we need to fix you an image for posting on Steam / socials
09:20:53 <truebrain> Maybe you can look _zephyris in the eyes while blinking pretty
09:28:26 <_zephyris> Hmm, maybe a ship maze?
09:28:45 <_zephyris> I know it's not actually very beneficial for that case, but visually good.
09:29:24 <kuhnovic> The only case where the ship pathfinder really shines is larges maps, but that doesn't make for a great screenshot
09:29:44 <kuhnovic> A ship maze with lots of ships would be nice
09:36:21 <andythenorth> ok Horse compile averaging 27s not 34s now
09:36:27 <andythenorth> that stupid palette check though 😛
09:37:02 <andythenorth> 1.4s of complete waste that I can't prevent nmlc doing
09:37:51 <zero2474> merni: not the lang files, I'm trying to export the vehicle's timetable.
09:37:51 <zero2474> But every test build was taking around ~24mins.
09:38:40 <zero2474> im doing cmake build for RelWithDebInfo.
09:39:06 <merni> Hm, yeah... release builds are slower
09:39:12 <zero2474> oh wait is debug or release more than enough !
09:39:44 <merni> debug builds are slow but fine for testing
09:39:53 <zero2474> ah I see I didn't explored the build options lol.
09:43:45 <andythenorth> ach can't just drop the palette check for nmlc
09:44:06 <andythenorth> it requires a palette for action 14, and it infers it from the spritesheets
09:44:44 <andythenorth> we know that the palette situation is generally a bit stupid 😛
09:44:49 <andythenorth> maybe we can do something better here
09:49:08 <andythenorth> not available to nml authors
09:50:52 <reldred> you can't be trusted with that much power
09:53:44 <andythenorth> my grfs set that option flag as "DEFAULT"
09:54:16 <andythenorth> which nml treats as DOS palette
09:55:20 <andythenorth> they're not even nice links
09:55:56 <andythenorth> maybe I can expose that to an arg
09:57:41 <andythenorth> the logic in the following lines hurts my small brain though
09:57:57 <_zephyris> Silly but suitable?
09:58:41 <kuhnovic> Silly and I love it!
10:02:20 <andythenorth> what does `skip_sprite_processing &= outputfile.skip_sprite_checks()` do?
10:03:02 <andythenorth> is that a bool incremental assignment?
10:04:48 <truebrain> it does `skip_sprite_processing = skip_sprite_processing & outputfile.skip_sprite_checks()`
10:04:59 <truebrain> now if we make a truth-table, we know what it does
10:05:22 <truebrain> ```true = true & true
10:05:22 <truebrain> true = true & false
10:05:22 <truebrain> true = false & true
10:05:22 <truebrain> false = false & false
10:06:46 <kuhnovic> _zephyris: Looks great!
10:17:52 <truebrain> don't forget to attach it to the news post 🙂
10:24:54 <kuhnovic> truebrain: How do I do that? Can I even do that :P?
10:25:12 <truebrain> pretty sure you are capable of dragging images in a reply and posting that, yes
10:26:21 <michi_cc[d]> Did we decide on the order for the remaining posts yet? And will Tyler remeber the daylength one? 🙂
10:26:36 <kuhnovic> You overestimate me TrueBrain 😉
10:26:42 <truebrain> talltyler: keeps dodging that question 😛
10:27:30 <michi_cc[d]> Any further comments on my sausage post? I'd like to make an imgainary checkmark on that one 🙂
10:28:20 <truebrain> won't be posted for at least another 2 weeks 😛
10:30:35 <kuhnovic> Not bad after 3 hours of sleep 😆
10:30:50 <truebrain> must have been very hard, drag and dropping those files
10:31:54 <truebrain> guess we might as well publish the post while we are fiddling with it
10:34:39 <kuhnovic> It was a marathon, but I'm glad I did it
10:36:55 <truebrain> bah; can't add an image after posting on Discord
10:38:20 <andythenorth> hoping someone takes pity on my nml patch 😛
10:38:34 <truebrain> haha @ _zephyris , nice 🙂
10:38:36 <michi_cc[d]> Made a reddit post.
10:39:29 <truebrain> still can't believe you cannot add/modify an image after you posted something
10:39:34 <truebrain> you can alter the whole text, but not the image
10:42:27 <kuhnovic> Oh well, now I got two announcements 🎉
11:32:12 <xarick> merge 11862 so that my AI becomes happy 🙂
11:33:28 <xarick> oh, 11862 is the issue, I mean 12156
11:37:00 <kuhnovic> Needs a developer review first
11:37:20 <kuhnovic> I only pretended to have that authority by commenting 😛
12:11:10 <xarick> it's not even hidden from the random pool choice of AIs
12:13:26 <peter1138> What does it do....
12:13:48 <xarick> places signs on every industry, that's all
12:14:08 <xarick> and removes when they close
12:15:11 <peter1138> I suggest not downloading it 🙂
12:16:30 <xarick> there should be a rule or a scanning done on these scripts for what they can do
12:17:30 <xarick> if AIVehicle.BuildVehicle is not present... tag it as "unfit" or whatever, I dunno, it's just ... me
12:17:53 <peter1138> Modification moderation
12:18:36 <peter1138> talltyler: Glad you read it 🙂
12:19:08 <xarick> showing what it can do, on a quick glance
12:22:07 <xarick> nevermind, just venting
12:22:22 <kuhnovic> Lets make xarick happy
12:27:26 <xarick> choochoo made a fix to something but didn't fix the ERR_UNKNOWN when building road connected to a bridge
12:28:01 <xarick> or maybe the fix needs to come from the OpenTTD side
12:28:38 *** D-HUND is now known as debdog
12:31:29 <xarick> trying to pick from a list of 500 "smiles" one that reflects my mood...
12:37:08 *** gelignite has joined #openttd
12:46:28 <_glx_> truebrain: Middle ones feels very wrong
12:47:01 <peter1138> TrueBrain wrote it for |= not &= 🙂
12:47:15 <truebrain> Clearly wasn't awake
12:47:40 <peter1138> You were just testing us.
13:04:46 <talltyler> peter1138: I'll even review it later, but last night was not a good critical-thinking hour 🙂
13:18:04 <peter1138> That is related to vague questions I asked on here a few weeks ago about lightness/brightness/shades 😄
13:19:16 <xarick> the problem of ship going back and forth is due to using non-pathfinder distances combined with pathfinder distances
13:21:25 <xarick> it's still a birds view type of distance while pathfinder distance is the one that has the ultimate say
13:50:41 <peter1138> I was looking at that thinking... how would a static_cast here work... then I realised i was thinking of static_assert, haha.
13:53:08 <talltyler> Is C++ up to four different meanings for the word `static` depending on where it's used? 🙂
13:53:43 <talltyler> Only four that I know of 😛
13:54:12 <peter1138> Also `& 0xF` is a bit less meaningful than `% COLOUR_END`
13:56:30 <frosch123> oh dear... i received my public transport ticket id card: it features my name, but the photo of someone else :p
13:57:44 <peter1138> talltyler: also I'm not really show how/if those shade values should be documented.
13:58:02 <peter1138> `SHADE_NORMAL, ///< Normal shade` is kinda redundant.
13:58:59 <peter1138> I guess it should be, for consistency.
13:59:24 <peter1138> Huh, COLOUR_ is not documented either. Hmm.
14:00:07 <truebrain> frosch123: Eeeeuuuuhhhh ... scary
14:01:17 <talltyler> `Red: The colour of roses`
14:01:17 <talltyler> `Blue: The colour of violets`
14:01:34 <peter1138> COLOUR_PURPLE, ///< Pikkabird.
14:02:15 <talltyler> `COLOUR_ORANGE, ///< Like COLOUR_YELLOW, but it hurts your eyes`
14:02:21 <talltyler> Maybe that's just me
14:02:31 <peter1138> > Not actually orange.
14:02:55 <truebrain> `COLOUR_RED, ///< The colour as perceived by human eyes at around 700nm`
14:03:38 <talltyler> Documentation by Skynet, I like it
14:04:44 <truebrain> The difference between a dogmatic approach to documentation and a pragmatic approach to documentation; some things really do not need further explanation 🙂
14:05:23 <talltyler> Oh, and I am working on my timekeeping blog post 🙂
14:05:46 <talltyler> Although next week is social integration according to the teaser at the end of today's post, so I have some time 🙂
14:05:50 <truebrain> so what will be the order ... social integration is next .. what did you want after michi_cc[d] ?I forgot 🙂
14:05:57 <truebrain> talltyler: but you keep saying that 😛
14:06:34 <talltyler> I made it possible to slow down or pause time, I have every right to apply that to real life too! 😛
14:06:38 *** Leopold has quit IRC (Remote host closed the connection)
14:07:13 *** Leopold has joined #openttd
14:07:30 <truebrain> haha, I was about to suggest the same 😛
14:07:36 <talltyler> Too slow by seconds
14:09:08 <talltyler> Anyway, truebrain asked me to put some information about time in the Help & Manuals button... what should go in there? Why does that get bundled with the game instead of being on the Wiki like other game info?
14:09:44 <talltyler> And would it be better as an expanded helptext on the Timekeeping Units setting?
14:10:28 <truebrain> pretty sure I was just revoicing a mention of someone else, but .. 😛
14:11:24 <peter1138> Well, I don't think that's my PR failing the annotations :S
14:11:50 <truebrain> sounds like github is just having a bit of issues 🙂
14:12:41 <truebrain> talltyler: I don't think you can fit a good detailed explanation in the helptext 😛
14:13:09 <truebrain> but we do need to document somewhere what is influenced and what is not
14:13:19 <truebrain> as people will try to figure it out on their own, and will document it wrongly
14:13:26 <truebrain> so for all I care, you make a wiki page detailing how it works
14:13:34 <peter1138> I think this end boss is too hard for me 😦
14:14:19 <truebrain> did you try the "re-run jobs" button? Didn't that fix it?
14:15:40 <truebrain> it is a really odd warning; one that should really be temporary
14:16:04 <peter1138> Should be but it was happening last night too.
14:16:37 <truebrain> seems you did a re-run of only the failed runs yesterday?
14:16:52 <truebrain> that is not going to fix anything
14:17:00 <truebrain> as the warning is in a run that succeeded
14:17:03 <truebrain> so you need to rerun the full set
14:17:17 <truebrain> (the issue with warnings .. they are not failures)
14:17:32 <peter1138> Oh, I did the wrong rerun just now, yes.
14:17:42 <truebrain> owh, I say yesterday, but that is in US time I see
14:17:53 <truebrain> the timestamps on GitHub are weird
14:17:56 <peter1138> Yesterday I did a rerun of one of the successful-but-failed tasks, but not the other one, so it wouldn't've updated.
14:18:35 <truebrain> ah, no, times do make sense, just with reruns it gets a bit odd where to look for the actual time, lol
14:19:15 <truebrain> So yeah, a "re-run all" should fix that failure 🙂
14:19:28 <truebrain> bit wasteful in CPU-terms, but ... warnings 😦
14:24:05 <kuhnovic> xarick: That's not the problem. The problem is that the depot is in range when doing the initial search. The ship then plans a path to the depot, enters a tile from where the depot is no longer in range. This would happen with true distances as well. After my changes the ship picks a depot and doesn't search for a new one as long as that depot exists.
14:24:11 <truebrain> michi_cc[d]: so I guess we order it like: social -> daylength -> survey -> sausage? Which means talltyler has 2 more weeks to get the blog done and proof-read. Is that doable, you think?
14:25:18 <truebrain> then a weekend nothing, to go into a full release on a monday, I guess
14:30:43 <xarick> I don't think it would happen with true distances (aka low level pathfinder costs), because it has more information of ship's current position like direction, tile, trackdirs, while distancesquare ignores any of that.
14:31:30 <xarick> if it found a path the first time, then it is already accounting for all possible ship movements to the next tiles
14:31:53 <xarick> so next day, it would still keep on finding the same path
14:40:09 <_glx_> not if it's at the limit
14:42:27 <_glx_> firefox has hard time to open the log for #12163
14:44:04 <xarick> if the cost goes past the limit the first time it is called, then there is no path found, but if the cost is within the limit, then I am like 95% sure it will stick to that path in the next days. Costs can only decrease from that point on.
14:44:35 <_glx_> but the limit is always in distance, not cost
14:47:34 <xarick> what distance are you referring to? The distance is the max pathfinder cost.
14:50:46 <michi_cc[d]> truebrain: Sounds good to me at least 🙂
14:50:50 <truebrain> _glx_: lol, yes, many errors 😛
14:51:15 <_glx_> dunno I still can't see them
14:51:26 <michi_cc[d]> You could switch daylength and survey if needed. Daylength is probably kinda the "big" feature.
14:51:53 <truebrain> I wanted to do it last, for that reason 😛
14:52:48 <truebrain> _glx_: seeing them doesn't really help. But of issues with all kinds of various stuff related to types not found, redeclared, etc etc
14:53:15 <truebrain> `‘underlying_type’ is not a member of ‘std’`, `unused parameter ‘m1’ [-Wunused-parameter]`, etc etc
14:53:27 <michi_cc[d]> Well, I'm not sad or angry if my sausage post is moved around. My think was just to not interrupt the feature diaries with some random non-feature one (that isn't really specific to OTTD 14).
14:53:56 <truebrain> I get that reasoning
14:54:17 <truebrain> guess it will depend on what is done next week, when the social is being posted 😛
14:54:33 <truebrain> _glx_: there is no stdafx.h include in the new cpp file
14:54:34 <talltyler> I wonder if we could do the sausage post on the 20th anniversary of OpenTTD?
14:54:36 <truebrain> that is where things go wrong 🙂
14:54:58 <_glx_> yeah, but strange only dedicated build is affected 🙂
14:55:04 <truebrain> talltyler: Rb suggested to do the survey post on that date
14:55:16 <truebrain> _glx_: dedicated runs without PCH
14:55:24 <truebrain> (to ensure we can still build without PCH)
14:55:56 <truebrain> talltyler: / michi_cc[d] : honestly, I don't think our readers care about any order of posts, neither what date it happens on 🙂 So it is mostly for us, what we like / enjoy 🙂
14:56:15 <xarick> using distancesquare from current ship position to depot as a max pathfinder cost is the problem. It is telling the pathfinder to search a path to the provided depot destination which is in range from a bird's eye perspective
14:56:25 <truebrain> _glx_: related, the header file is not added to the CMakeLists 🙂
15:01:49 <kuhnovic> xarick: That would only work if the fincClosestDepot function would actually return the entire path to the depot. Right now finding the closest depot and finding the path to the depot are two separate things. As long as you have that then there's a risk of the ship "losing sight" of the depot.
15:02:36 <kuhnovic> But IMO it makes much more sense to remember what depot you are heading for once you have found it
15:03:19 <xarick> that may not work if the terrain changes meanwhile
15:03:51 <_glx_> doing PF run just to find an hypothetical auto service depot seems too much
15:04:43 <xarick> automatic service at depot seems to be done this way for all vehicle types
15:04:59 <_glx_> but they are not in free space
15:05:13 <kuhnovic> _glx_: It wouldn't be an issue if the PF was fast enough
15:05:32 <xarick> it's fast, it's under a limit
15:06:33 <xarick> or used to be 20 tiles
15:06:47 <_glx_> 20 tiles in water is a lot of possible paths
15:07:25 <kuhnovic> Ships also check for service every economy day, which roughly amounts to once for each tile for typical ship speeds. Seems excessive to me.
15:07:52 <xarick> that's how automatic service works 🙂
15:08:50 <xarick> if you check the other vehicle types, it does the same
15:09:07 <_glx_> yes but their paths are more limited
15:09:20 <kuhnovic> The regular low level PF is to slow for this at this point. I have a patch with a BFS search and some tricks to avoid checking which trackdirs are available, which is relatively heavy when doing it for lots of tiles. It is a lot faster, but needs further testing.
15:10:14 <_glx_> every new water tile opens 3 new possible ways
15:10:47 <kuhnovic> xarick: This is something I do need to look at a bit closer. That might be a problem for #12170
15:11:35 <_glx_> and it's the reason why buoys were needed, the number of nodes can go very high very quick
15:11:45 <xarick> i don't think it's slow at such low limits, such as ~20 tiles equivalent of costs it doesn't even need to use the high level pathfinder, too short of a distance, it would use the low level pathfinder
15:12:11 <kuhnovic> _glx_: Yup, but you can check at the tile level instead of exit dir level. A tile can only have one piece of water, not more. That's actually one of the reasons that water regions are possible.
15:12:40 <_glx_> final PF cost might be small, but the number of paths to test and discard can be huge
15:13:34 <kuhnovic> My BFS search is tile based, so only 25% of what yapf would use.
15:14:04 <_glx_> with a specific implementation yes, I'm talking general low level
15:14:30 <kuhnovic> Yes, many symmetric paths. It grows exponentially
15:16:06 *** nielsm has quit IRC (Ping timeout: 480 seconds)
15:17:51 <xarick> 20 tiles worth of distance:
15:17:58 <xarick> are you saying this is slow?
15:19:26 <_glx_> especially if it's done very often
15:19:46 <kuhnovic> _glx_: Just to make sure we're talking about the same thing here: you don't have to do a PF run for each depot. A* without heuristic can be used to expand until a depot is found, or bail out if there are no more nodes within a certain search distance. Same for BFS.
15:21:48 <_glx_> specific implementation optimised for the depot search yes, but I don't think it was Xarick's intention here 🙂
15:22:06 <kuhnovic> The reason I went for a BFS is that you can just treat each tile as 1 extra distance traveled. No need to keep nodes sorted, no keeping parents. Much more lightweight compared to A*, but only relevant if you don't know where your target is. And it has other drawbacks, there is no silver bullet.
15:23:09 <kuhnovic> _glx_: Hehe no, I think he once implemented a for-all-depots-run-low-level-PF. Granted, that was in a draft PR.
15:24:44 <xarick> it's still a valid approach, it's functional in my view, but it was done in 1 go, instead of multiple commits, and that's why I shied away
15:25:25 <_glx_> it works yes, but it's very expensive
15:25:45 <xarick> expensive for large distances, but not for this situation
15:27:23 <xarick> Kuhnovic avoids the large distances by imposing a max distance
15:28:19 <xarick> I made no such restrictions 😦
15:30:37 <kuhnovic> IMO it makes no sense for ships to look for a depot on the other side of the map if they need to service. In the past there was an unofficial limit for this, which was YAPF hitting the node limit haha
15:31:43 <kuhnovic> The high level pathfinder is fast enough to search the entire map for depots if you wanted it to
15:33:43 <kuhnovic> Your solution is a O(n) one: you need to do a PF run for every depot. The computational burden grows linearly with the number of depots. That's what you want to avoid.
15:36:12 <xarick> the method you're referring is the part where it finds a region with multiple depots?
15:37:08 <xarick> I can remove that part if it's really what I must do
15:37:24 <xarick> I was trying to make it accurate
15:37:45 <kuhnovic> xarick: I'm referring to running a PF for each depot
15:38:32 <truebrain> (And yes talltyler , I know I put it on Discord, but I also know it wasn't my text 😛 )
15:38:33 <xarick> it doesn't run a PF for each depot, it runs a low level PF for each entry point the region is accessed to whatever depot it finds
15:38:50 <merni> truebrain: I think I was at least partially responsible :P
15:38:53 <xarick> which at that time, we know it exists
15:38:55 <kuhnovic> It's a balancing act between accuracy and performance. And it's not trivial, otherwise it would have been done already 😁
15:39:16 <kuhnovic> (gotta go now, more PF talk later!)
15:39:26 <truebrain> merni: It is just funny .. if he can blame me, he does, otherwise it is "someone I wouldn't mention" .. I see a clear pattern 😛
15:40:10 <merni> looks like nielsmh was the one who first introduced the idea of vehicle movement there though... I am guilt-free :P
15:40:36 <truebrain> And that is the most important thing!
15:41:19 <truebrain> If something goes wrong and you are smiling .. you have someone else to blame!
15:43:31 *** urdh has quit IRC (Ping timeout: 480 seconds)
16:16:01 <LordAro> i blame truebrain for the thing going wrong
16:16:12 <LordAro> whatever the thing is, i can't tell from scrollback
16:19:15 <Eddi|zuHause> it is usually a safe bet to do that.
16:19:51 <Eddi|zuHause> i think they're talking about #12172?
16:29:30 <truebrain> LordAro: I love you too
16:30:21 *** SigHunter has joined #openttd
16:30:30 <talltyler> truebrain: That's because you're the CEO of OpenTTD, right? 😛
16:30:56 <talltyler> (I am not trying to establish or follow a pattern, to be clear 🙂 )
16:36:31 <talltyler> Hmm, I wonder where in this blog post I should mention cargo production scaling...
16:36:51 <talltyler> It is really separate from "make time go slower" but is one of the other things people like about Daylength
16:37:24 <merni> it is not "make time go slower" but "make <X> go slower" where X is factories
16:37:28 <talltyler> Maybe I will mention it right after I mention Daylength
16:38:06 <peter1138> Something crashed, probably GPU drivers :S
16:39:44 *** Wormnest has joined #openttd
16:41:30 <peter1138> I misread Timekeeping as Beekeeping....
16:42:51 <truebrain> talltyler: Just make it its own section? 🙂
16:54:41 <andythenorth> oh I failed on black as well
16:56:34 <andythenorth> _glx_: if I've understood nml main.py correctly, my patch should only be skipping palette validation, so `--no-palette-validation` might be appropriate arg name?
16:58:54 <peter1138> There we go, I social-media'd the blog post.
16:59:01 <peter1138> (Didn't get around to it for the others, sorry!)
17:04:45 <andythenorth> ok so if I don't blacken nml/main.py the checks fail
17:05:07 <andythenorth> but if I do blacken it, I get a large diff on lines that having nothing to do with my PR, which won't be approved
17:05:16 <andythenorth> marvin moment? 🙂
17:05:35 <peter1138> Due to a blacken update?
17:05:51 <andythenorth> I think nml is only selectively blackened or something
17:06:22 <peter1138> Might be worth a separate PR to just rerun blacken.
17:07:01 <andythenorth> I *believe* that some of it is deliberately not blackened, to preserve formatting
17:07:23 <merni> I thought the whole point of black was to not think about formatting
17:08:10 <andythenorth> it is, but I remember nml has exceptions somewhere
17:09:21 <andythenorth> ok I have `black, 24.2.0`
17:10:49 <andythenorth> black has no arg to specify the black version, do I need to pip downgrade maybe?
17:12:35 <andythenorth> hmm still a giant diff with 23.1
17:13:11 <truebrain> set your linelength 🙂
17:14:20 <truebrain> lol @ talltyler ; Time Lord .. lol
17:19:14 <_glx_> you can also just run `make black` 🙂
17:23:07 <andythenorth> I've got in a bit of a squeeze with nmlc
17:23:19 <andythenorth> I have grfs that now want to use nmlc built from multiple PRs
17:23:36 <andythenorth> I guess I could merge them all into some branch
17:28:05 <_glx_> it's easy to make errors in python
17:30:24 <andythenorth> oh 🙂 I thought find-and-replace had got those in my editor sorry
17:45:10 <ajmiles> ajmiles: peter1138 What's your view on this?
17:45:41 <ajmiles> I see there are blitters without 'anim', but I don't know if they're visually deficient in some way or just slower than the 40b ones?
17:47:36 <peter1138> They don't support palette animation.
17:48:30 <peter1138> Palette animation can be turned on and off. When doing all the blitting in software there's a minor improvement to not handling the palette animation buffer when palette animation is turned off.
17:49:19 <ajmiles> And sorry for the basic questions, but how does palette animation manifest in the game? If a blitter doesn't support doing it, what looks different?
17:49:55 <truebrain> the seas are static
17:49:57 <truebrain> instead of animated
17:50:06 <truebrain> one of the easiest to observe
17:50:36 <truebrain> just start the game in your non-development video driver and enable/disable animation in-game 🙂
17:51:06 <peter1138> Hmm, video compression hides it a bit.
17:51:23 <truebrain> seeing it in-game yourself is best to understand what it is, honestly 🙂
17:51:49 <peter1138> When you know what you're looking for 🙂
17:51:53 <ajmiles> OK, let me take some of the anim blitters out the list and have a look now I know what I'm looking for!
17:52:24 <peter1138> This option turns it on & off.
18:00:01 <xarick> I feel so sad to undo so much of the work I had accomplished
18:00:23 <ajmiles> Looks like I've managed to get it working for only some runway lights... somehow
18:01:51 <truebrain> lol, mouse artifacts ... I have seen that way too often 🙂
18:02:18 <ajmiles> My implementation of DrawMouseCursor doesn't capture and restore what's under the mouse right now
18:02:33 <peter1138> That happens when the tile is redrawn -- it's use the current state of the palette animation, but not actually doing palette animation.
18:02:53 <xarick> this was just a rebase
18:03:20 <ajmiles> peter1138: Yeah, I'm going to have to find where palette animation is "done" to understand what I've missed
18:03:58 <peter1138> When copying the backbuffer to screen you probably need a shader to handle the 8bpp anim buffer there.
18:05:02 <ajmiles> I have what I thought was a copy of the OpenGL shaders for the end of frame draw. It runs in 3 modes MODE_REMAP, MODE_PALETTE and MODE_PROGRMA
18:05:50 <truebrain> OpenGL uses shaders for that, `remap_program` if I remember correctly
18:05:53 <truebrain> it is applied every frame
18:07:23 <ajmiles> But that's not actually animating the anim buffer, that's just remapping it to RGB. I think what I must be missing is the action taken to update the anim buffer with the new 'm' value for animating things like the lights
18:07:38 <peter1138> The anim buffer isn't updated.
18:07:54 <peter1138> The rgb value that m maps to is altered.
18:08:49 <ajmiles> That's the 256 entry palette I call palette?
18:08:51 <truebrain> the 8bpp days, where that was the cheapest way to animate stuff 😄
18:10:13 <peter1138> I'm a bit confused by the idea of shader modes at this point.
18:10:36 <peter1138> Don't you have different shaders for doing different things?
18:10:43 <ajmiles> That was just my way to collapse 3 shaders into 1
18:11:06 <ajmiles> The shader is short enough that there was no need to compile 3 different versions and pick which one to use
18:12:12 <peter1138> What is frameIndex here?
18:12:18 <ajmiles> Just when it's an even or odd frame
18:13:13 <ajmiles> The CPU writes directly to the current frame's palette without copying it over to the GPU. So the CPU writes to one copy and the GPU reads from the other, so it just ping pongs every other frame
18:13:37 <peter1138> Okay, so concurrency safety.
18:14:17 <ajmiles> At a sufficient level of zoom, it works
18:14:34 <truebrain> it just appears to work 😉
18:14:45 <peter1138> And is this shader a separate part of the process from blitting sprites?
18:14:52 <peter1138> (Because it should be)
18:15:03 <ajmiles> Yes, it's the final event of the frame
18:15:17 <ajmiles> That palette applies to everything on the screen at the end of the frame
18:15:34 <truebrain> from what I can see from your animations, the sea is not animating
18:15:46 <truebrain> so most likely parts of the airport are just redrawn often enough to give the illusion of animation
18:15:53 <truebrain> but it is not actual the palette animation we are talking about
18:16:27 <peter1138> The two stages of palette animation 😄
18:16:40 <peter1138> Initial drawing and then updating.
18:16:42 <ajmiles> BlitterParams 'bp' comes with its own 'remap' array each time a sprite is drawn. Is that a different remap (and remap array) to what happens at the end of the frame?
18:16:53 <ajmiles> Right now I do nothing to respect the BlitterParams' remap
18:16:54 <truebrain> so just so we are talking the same story: every frame a few indexes of our palette are updated with new RGB values; so the index into the palette remains the same, but the actual colour changes
18:17:04 <peter1138> Yes, that is it a different remap.
18:17:12 <ajmiles> And is it relevant to the sea animating?
18:17:22 <truebrain> that is what is the "Full animation" thing is doing
18:17:44 <peter1138> That remap is for doing things like making vehicles appear company coloured.
18:17:57 <peter1138> (Along with lots of other uses)
18:18:10 <peter1138> But the ignoring that remap shouldn't affect palette animation.
18:18:15 <ajmiles> So the sea animates by virtue of the end-of-frame palette changing what RGB the anim buffer maps to?
18:18:37 <peter1138> As do the yellow lights on the airport.
18:18:39 <ajmiles> How do you animate the sea without everything else in the world that shares the sea's anim buffer values changing as well?
18:18:55 <truebrain> it doesn't; that palette index is going to change, whether you want to or not
18:19:02 <peter1138> The rotating radar(?) dish is of course not palette animation, and that is probably affecting why it appears to work.
18:19:05 <truebrain> so only images that want the animation, use that "colour" (read: palette index)
18:19:24 <peter1138> Yeah, all those palette indices are reserved for animation 🙂
18:19:37 <truebrain> sometimes NewGRF authors fuck up and think it is a static colour, and use it for their train or what-ever
18:19:44 <truebrain> resulting in funny animations 🙂
18:19:49 <ajmiles> OK, so if some part of a building shared the sea's anim value, that part of a building would be the same colour as the sea - but in practice, they probably don't?
18:19:50 <peter1138> Anything above 215 iirc.
18:20:28 <peter1138> Yes. It would animate as well. Like the water fountain in towns.
18:21:04 <truebrain> all this is called "animation buffer" in our blitters / video drivers, but often referred to as palette animation
18:21:18 <truebrain> (and unrelated to the remap mentioned earlier, although this also "remaps" colours .. confusing, not? 😄 )
18:21:46 <ajmiles> The 'remap' mentioned earlier remaps anim buffer values to other anim buffer values IIRC
18:22:07 <frosch123> ajmiles: yes, some buildings have pools on their roof, and they will use the same animated water colours
18:22:09 <truebrain> not only the anim buffer 🙂
18:22:13 <peter1138> Imagine an ancient graphics card which actually supported 8bpp mode with a palette. Back then, the palette was animated simply by changing the palette values, and the graphics card would automatically output the new values without anything else changing in memory.
18:22:44 <ajmiles> OK, maybe then my palette isn't updating every frame as it should
18:22:55 <peter1138> ajmiles: Also yes, although I have a patch for that 😄
18:23:05 <truebrain> OpenGL uses a texture for it, which is loaded by a shader and applied on every pixel
18:23:16 <truebrain> this texture is updated whenever the "anim buffer" is updated
18:23:29 <ajmiles> Yeah, I saw the Texture1D in there and opted to use a buffer instead
18:23:49 <rau117> ajmiles: Blue airport buildings, but red airport name?
18:24:00 <truebrain> and yes, this is a really ancient way of approaching all this, but that shows how old the game is 🙂
18:24:10 <truebrain> If we would rewrite this all, nobody would do it like this 😛
18:24:33 <ajmiles> rau117: ~~Bug~~Feature!
18:24:46 <truebrain> that btw is the other remapping not being applied, I assumed 🙂
18:25:21 <truebrain> yeah, default company colours are blue; I always forget what the default colour is 🙂
18:25:26 <ajmiles> Right. That one I *know* I'm not doing yet. Need to figure out the best way to get a 256-entry array over to the shader that I presume can potentially change with every sprite drawn
18:25:47 <ajmiles> Although presumably only the ones using the BlitterMode with 'REMAP' in the name
18:25:51 <peter1138> The game itself treats these 256-entry arrays as sprites too.
18:26:00 <peter1138> That might be a guide on how to proceed.
18:26:17 <ajmiles> Are they fully dynamic, or loaded like an asset?
18:26:43 <peter1138> (Well, not just like sprites, but they have SpriteIDs and are included in the spritecache)
18:26:45 <truebrain> btw, `ReleaseAnimBuffer` is used by OpenGL to know it has to rework the animation texture
18:26:49 <peter1138> They are loaded like an asset.
18:27:07 <peter1138> If you have remap "776" it is always the same remap.
18:27:38 <peter1138> (And I also have patches to dynamically create these, but it's still treated like an asset)
18:27:42 <ajmiles> I'm already handling the loading of all sprites and creating textures for each one at every zoom level, so I've probably inadvertantly already got them available
18:28:23 <peter1138> Probably not, they are handled differently lower down, and they don't have dimensions or offsets of course.
18:29:59 <peter1138> So when blitting with a remap you'd need to do palette[remap[sprite.m]] instead of palette[sprite.m]
18:30:04 <_glx_> truebrain: CHIPS blinking cows
18:31:12 <truebrain> and with animation it becomes `palette[anim[remap[sprite.m]]]` I guess? 😄
18:31:48 <ajmiles> You've reminded me of another question I had. Then I handle the encoding of sprites, some come through with only 1 valid zoom level (the first one), the other zooms are 0xCC or some other fill pattern depending on DEBUG/RELEASE and I'm not clear on how to know which ones to process
18:31:49 <truebrain> hmm, can't even write that like that
18:32:03 <ajmiles> 16384 was just my hack to pick up on the invalid size and worry about something else
18:32:11 <peter1138> all zoom levels should be valid.
18:32:17 <ajmiles> This is a font though
18:32:30 <peter1138> Ah, okay, if it's a font, then only the first zoom level is used.
18:32:46 <_glx_> 0xCC means initialised value in DEBUG
18:33:22 <peter1138> 32bpp_optimized.cpp:309 handles this case for the sprite encoder.
18:33:40 <peter1138> For now you could do the same.
18:33:57 <peter1138> However with hardware blitting the pre-scaling is most redundant.
18:34:09 <peter1138> So how the sprites get passed to the encoder should be changed.
18:34:22 <peter1138> (Funnily enough, by fractional scaling patch does that in a way that might be suitable)
18:35:14 <DorpsGek> - Update: Translations from eints (by translators)
18:35:16 <truebrain> You are going to hit "Error: too many branches", one of these days 😛
18:35:26 <ajmiles> Are sprites always authored at ZOOM_LEVEL_NORMAL and every other zoom level is a nearest neighbour rescaling?
18:35:26 <peter1138> I don't think that's a thing :p
18:35:54 <peter1138> Most common is ZOOM_LVL_OUT_4X, which is the original 1x zoom.
18:36:16 <_glx_> (yeah we have weird numbering)
18:36:35 <peter1138> The game prescales everything up because we were a bit silly and didn't want to complicate the blitters with pixel doubling on the fly...
18:36:40 <truebrain> and I guess a NewGRF author can make some zoom-levels look totally different from others, if they like? More detail etc?
18:37:25 <peter1138> With hardware scaling it's possible to still use those but not fabricate anything.
18:37:28 <ajmiles> At some point I imagine I'll want to load only the levels that the sprite author has authored and have the hardware point filter magnify any levels more zoomed-in that the most zoomed in level provided
18:37:30 <_glx_> that's why zooming looks ugly when you mix non EZ with EZ
18:38:01 <peter1138> Did I ever push the fractional sprite scaling anywhere...
18:38:32 <truebrain> I just keep reading it as "easy" 😛
18:40:59 <_zephyris> If only they were EZ to draw
18:45:32 <peter1138> Remember that day we dropped PNG support 😄
18:45:37 <ajmiles> Yeah, not seeing much animation going on in this palette
18:47:07 <j_n> good to see mouse cursor is working (kind of)
18:47:28 <ajmiles> Just having something to be able to click with is a relief...
18:48:27 <xarick> I need costs! there's no way around it
18:48:34 <xarick> the high level pathfinder needs to return costs
19:02:38 *** Leopold has quit IRC (Remote host closed the connection)
19:05:13 <ajmiles> 1 step forward, 1 step back
19:07:17 <truebrain> hmm, animation ..... 🙂
19:07:57 *** Leopold_ has joined #openttd
19:39:22 <ajmiles> OK, fixed all that nonsense. Palette animation works correctly and nothing smears
19:39:56 *** Leopold_ has quit IRC (Remote host closed the connection)
19:40:39 *** Leopold_ has joined #openttd
19:42:22 <ajmiles> Trying to comply with how a blitter is expected to work isn't straightforward. Last night I was trying to implement the `ScrollBuffer` functionality which I assume is there to just move the dst/anim contents around rather than having to reblit the entire screen
19:43:36 <ajmiles> I came up with a way to do in-place scrolling of those buffers on the GPU, but I've got some shearing which is probably my fault but I can't rule out the possibility that I've scrolled properly but then the relevant parts of the screen weren't repainted correctly
19:44:17 <ajmiles> Oh yes, that was what I was going to ask. ScrollBuffer takes many of its arguments by reference like there's an expectation that the blitter is going to modify them and pass back new values, but it wasn't clear how?
19:47:33 <peter1138> Seems to be that ScrollBuffer may scroll something other than requested, and so the parameters are updated so that MakeDirty() can be called correctly.
19:48:06 <ajmiles> Yeah that's how it seemed, though I couldn't understand why a blitter would scroll something other than what it was asked to
19:48:24 <peter1138> Might explain the glitches though.
19:48:26 <ajmiles> If you're given a box and told to scroll it N pixels, well, that area is dirty now
19:49:04 <ajmiles> What's bugging me is that the shearing only seems to occur on/around towns and industries, not on the terrain
19:49:39 <peter1138> Might be related to tiles that update at the same tile.
19:49:51 <peter1138> Well, not "same" time, but straight after.
19:51:08 <ajmiles> So, maybe I made a faulty assumption. Any sprite blit requests I buffer up and deal with at the end of the frame, whereas ScrollBuffer I issue when asked to. So if the order of operations is:
19:51:08 <ajmiles> 1) [Draw a load of sprites]
19:51:08 <ajmiles> I'll have that backwards
19:51:32 <ajmiles> If the order of operations can be: 1) Draw some sprites, 2) Scroll, 3) Draw more sprites. I'm even more wrong/screwed
19:52:30 <peter1138> I'm not sure on that either 🙂
19:53:00 <peter1138> I would assume the scroll is done, and then the tiles that were obscured should now be drawn, after the scroll is complete.
20:01:20 <ajmiles> Looks like there's 3 scrolls too, split into Left, Middle and Right corresponding to where the little status bar is at the bottom of the screen
20:07:32 <peter1138> So it's possible we could use separate buffers for each window, and then scrolling only ever moves the whole viewport.
20:07:38 <peter1138> I also... have a patch for that.
20:08:28 <ajmiles> It had crossed my mind to ask for a mode that redraws the whole screen every frame
20:08:49 <ajmiles> Forget about dirty rects, scrolling etc. Just do what any normal game would do and start afresh each frame
20:09:26 <peter1138> Any normal 3D game, yes.
20:09:57 <ajmiles> And any 2D ones built this side of the invention of GPU acceleration 😄
20:10:03 <peter1138> You can do that. But it could be quite slow.
20:10:36 <peter1138> Game state is not organised in a way that is organised for graphical display.
20:10:42 <ajmiles> I'd like to work within the parameters of the way the game works right now though, at least where feasible
20:11:47 <peter1138> Especially when zoomed out, there is a LOT of game state to process.
20:13:18 <peter1138> Framerate drops from 170fps to 10fps if I redraw the whole screen every frame 🙂
20:14:05 <ajmiles> But how much of that extra 94ms is spent actually blitting it all - a cost that could be near-zero to the CPU in this world?
20:14:19 <ajmiles> (not a question I'm looking for an answer to)
20:14:55 <peter1138> For each tile visible that game executes a function that that checks how the tile should be drawn.
20:15:35 <peter1138> This will look up the state of the tile, work out what it is, look up tile layouts and add sprites to draw.
20:16:24 <peter1138> It will also check for vehicles on each tile, query what they should look like, and add those sprites to draw.
20:16:50 <peter1138> And then it needs to sort all those sprites into the correct order for drawing.
20:17:00 <peter1138> (That might be doable with Z-buffer with GPU acceleration)
20:17:24 <peter1138> And then it draws the sprites, loading on demand if necessary, etc etc.
20:17:29 <peter1138> There's quite a lot to do 🙂
20:17:31 <ajmiles> Heh, yes, also crossed my mind. I don't use one right now, but there's enough Z values in a 32bpp ZBuffer to give every sprite its own Z if we wanted
20:18:36 <peter1138> Ctrl-I will (with the existing blitters at least) highlight which screen areas are being drawn.
20:20:21 <peter1138> (That doesn't necessarily match the tiles that are being queried though)
20:21:10 <peter1138> Modern games would remember the drawing state between frames, perhaps in chunks.
20:23:27 <peter1138> e.g. send a list of sprites and positions for a small region into a buffer, and then just have 1 call to draw that buffer.
20:23:41 <peter1138> If any tile in that buffer changes state, then the buffer is updated.
20:24:09 <peter1138> The future eh... such magic.
20:24:36 <_glx_> it's partly done that way, but with CPU blitting
20:25:01 <_glx_> only changed stuff is repaint
20:25:12 <peter1138> No, that's a completely different approach 🙂
20:25:16 <ajmiles> GPUs... they'll never catch on.
20:25:51 <peter1138> nVidia is pivoting to this AI bullshit. Gaming GPU is barely anything to them now.
20:26:20 <ajmiles> Yep. Leaving AMD to play catchup
20:27:44 <andythenorth> ajmiles: just blame FIRS for that, it's the cause of most OpenTTD problems 🙂
20:28:02 <ajmiles> Name names. Who do I send the bill to? 😄
20:28:12 <andythenorth> especially FIRS GS
20:29:44 <_glx_> oh and I think the blue on the buildings is not supposed to stay blue 🙂
20:30:02 <peter1138> That's just recolouring not being implemented yet
20:30:25 <xarick> testing cool stuff again
20:30:30 <ajmiles> It's next on my list after the shearing/scrolling doesn't look awful
20:30:45 <_glx_> this industry is a good test case for both recolour and anim 🙂
20:55:57 <kamnet> So since I've missed the development, how fast can ships go now?
21:06:37 <xarick> I have a hard time believing this...
21:08:26 <peter1138> kamnet: Ekranoplans
21:11:01 <xarick> well, it's debloated and using the same leash as Kuhnovic's, but still... I didn't expect it to be faster
21:12:16 <kamnet> And I just now saw Zephery's announcement. My list of things I'm never going to get around to doing keeps growing shorter 🙂
21:13:12 <xarick> I need to verify ships are really finding their depots
21:15:35 <_glx_> it's fast but does nothing ?
21:15:38 <xarick> must multiply by YAPF_TILE_COST
21:17:01 <_zephyris> kamnet: Something like 20,000 mph I think... Word for speed in mph*3.2. I wonder if something would break if you actually coded that.
21:17:03 <xarick> YAPF_TILE_LENGTH i mean
21:17:36 <_zephyris> And acceleration can be 255 times normal ship acceleration!
21:17:55 <xarick> Kuhnovic uses distance based on number of tiles, I use the pathfinder distance, and that's 100 per tile
21:20:18 <xarick> a max cost of 80, that would mean... less than a tile, lol
21:22:10 *** dwfreed_ is now known as dwfreed
21:26:15 <peter1138> Instant deceleration 😄
21:30:41 <xarick> ships seem to be finding depots, but 80.... I mean, my AI uses a depot right in the middle of a route, and some routes are ~200 tiles appart
21:30:52 <xarick> I don't think all my ships can find depots
21:31:24 <xarick> 80 is less than 100... hmm
21:32:23 <xarick> do i have to use buoys because of that limited range?
21:34:04 <peter1138> xarick: as long as it passes near the depot enroute it should find it, no?
21:35:24 <xarick> no, because it's coming from the orderlist
21:35:49 <xarick> when it leaves the docks, it calculates nearest depot with a limit of 80
21:35:52 <peter1138> Oh, go to nearest depot order rather than just finding a depot.
21:36:40 <peter1138> Stupid question but could a go to nearest depot order cache a depot?
21:37:24 <peter1138> Hmm, when to invalidate a cache might be a problem.
21:37:26 <xarick> if it was an automated order, it would be ... _settings_game.pf.yapf.maximum_go_to_depot_penalty / YAPF_TILE_LENGTH
21:37:34 <_glx_> would be simpler to make a fixed depot order 🙂
21:38:26 <peter1138> Anyway, isn't the new high level pathfinder designed to make path finding quicker... I'm missing something.
21:38:43 <xarick> yeah, that's what I thought! no buoys needed!
21:39:03 <xarick> to find closest ship depot?
21:39:08 <_glx_> it is for proper destinations, but "closest depot" is not a real destination
21:40:13 <michi_cc[d]> ajmiles: Late to the game here 🙂 Are you basically collapsing blitter and video driver?
21:40:21 <_glx_> and for now we don't really have a fast PF specialised in depot search on water
21:40:55 <peter1138> Store the nearest reachable depot on the map 😉
21:40:56 <michi_cc[d]> The current OpenGL video driver is part of a two step process, and it might or might not make sense to keep it like that. Absolutely not sure which approach is better though 🙂
21:41:22 <xarick> I could use a proper destination indeed, but that just means it's no longer doing a ClosestShipDepot call, it's going to do a normal pf call
21:41:25 <peter1138> Store the nearest reachable depot for each region.
21:41:55 <_glx_> nearest depends on where you enter 🙂
21:42:07 <michi_cc[d]> Current rendering process: Draw to to offscreen framebuffer, render FB to onscreen, applying palette mapping and overlaying mouse cursor sprite.
21:42:10 <ajmiles> michi_cc[d]: I'm not sure if collapsing them is necessary what I'd call it as the concept of "Blitter" and "VideoDriver" still exist, but certainly the VideoDriver is taking on all the responsibility of blitting. The blitter just passes along requests to the video driver
21:42:56 <ajmiles> VideoDriver now has functions like `EnqueueDrawRect` and `EnqueueBlitSprite` which take similar parameters to `blitter->[those functions];`
21:43:12 <michi_cc[d]> My personal feel is that unless you want to rewrite a lot more of the drawing code, having a framebuffer/texture in between fits a lot better to the assumed drawing model
21:43:33 <michi_cc[d]> Like the stuff where you can apply a palette remap (not animation) to a screen rect.
21:44:19 <ajmiles> It's still very much a two stage process in the sense that I'm blitting to "off screen" dst/anim and then compositing with palette remapping as a final step to the swap chain
21:44:44 <xarick> let me try now with an unlimited leash, brb
21:44:45 <michi_cc[d]> I even though about basically doing a compositing window manager and render each window to its own offscreen texture. Not really coded anything for that as _cur_dpi is very global and I had no mood to try to untangle that 🙂
21:45:08 <peter1138> I have a patch for that 😉
21:45:23 <_jgr_> I've done a bit of work on making various rendering-related thigns less global
21:45:30 <_glx_> if we can have windows non continuously calling DrawString 😉
21:45:44 <peter1138> That was my plan, yeah.
21:45:50 <_jgr_> I'm doing sprite sorting and blitting in separate threads
21:46:00 <peter1138> I didn't get as far as rewriting how dirtying works though, so it's slow.
21:46:07 <_glx_> because DrawString is super slow
21:46:10 <michi_cc[d]> ajmiles: Current drawing code assumes a persistent back buffer. Whether that is a good fit for a fully accelerated blitter is left as an excerise to the reader 😛
21:46:50 <michi_cc[d]> peter1138: If you can find it somewhere, I'd love to have a look at it.
21:47:01 <ajmiles> dst/anim are persistent, although why would the back buffer need to remain persistent?
21:47:10 <peter1138> It's only a couple of weeks old, should be able to 🙂
21:47:41 <michi_cc[d]> Well back buffer for the OpenGL video driver means the offscreen texture. For some other blitters it might be the real window surface.
21:47:51 <_glx_> peter1138: that's the old thing, you should now say "I have a branch for that" 😉
21:48:26 <michi_cc[d]> But if you have a persistent buffer, you should at least be able to use the same mouse cursor drawing as the opengl video driver so you don't need to do any screen restoring.
21:49:03 <ajmiles> Yeah, I think I looked at it and decided I'd need to go around and setup the whole cursor cache thing
21:50:07 <peter1138> ^ Very much WIP, of course. Surprisingly little change.
21:50:11 <michi_cc[d]> Well, if you already create textures in the blitter, you can probably just get that from the blitter for the cursor. The OpenGL cursor cache is just because the blitters are not storing the sprites as an OpenGL texture.
21:50:37 <peter1138> But marking things dirty does not do the right thing, it still goes via screen blocks.
21:51:45 <peter1138> Oh, looks like I only touched 32bpp_base, that would explain the lack of much code 🙂
21:52:20 <peter1138> Heh, and debug code in there for another issue.
21:53:07 <peter1138> Also the buffer allocation would need to be rewritten to actually use GPU buffers if that would become a thing.
21:54:33 <michi_cc[d]> Yeah, it needs a compositor class. Default implementation would just hand out memory blocks and do software copying. OpenGL/GPU video driver would override that to hand out offscreen textures per surface.
21:55:55 <peter1138> Also blitter calls should probably take a surface, with any coordinates passed as parameters, instead of using this award "rely on a random pointer being correct" method.
21:56:04 <ajmiles> OK, I've validated my fear that scrolling and drawing sprites are interleaved. It scrolls the left third of the screen, then renders sprites there. Then the middle third, then draw sprites there. Then finally the right side and the sprites there.
21:56:24 <ajmiles> That probably explains a lot of the shearing I'm seeing
21:56:34 <peter1138> Getting the correct pitch would be simpler that way.
21:57:42 <xarick> there are 70k ships in this savegame
21:57:56 <xarick> and i dunno how many ship depots
21:58:04 <peter1138> Have you tried any non-worst-case scenarios?
21:58:42 <peter1138> Things that seem very slow with your extreme cases are often quite acceptable in normal games.
21:59:24 <xarick> I got a save for that, a simple 1 depot, 1 ship on a 4k map
21:59:35 <peter1138> I mean a normal save, not just one 🙂
21:59:42 <peter1138> 4k map is not very representative either.
22:00:06 <michi_cc[d]> ajmiles: Don't look at the newspaper window then 🙂 It draws everything and then uses GfxFillRect to overlay a anim/palette remap onto it that is special-coded in the 32bpp blitters to also affect RGB colors.
22:00:33 <michi_cc[d]> And all that just so you can have a year-appropriate bw newspaper image 🙂
22:00:44 <xarick> i also have a small map 64x64 with multiple depots
22:00:56 <ajmiles> Working newspaper is so far down the list of things to get working right now :awesome:
22:01:06 <xarick> 1 ship, but it's a maze like tiny 64x64 map
22:01:59 <peter1138> xarick: I just download a Reddit Server 1 game 🙂
22:02:22 <xarick> oh, is that how you get your test samples 🙂
22:02:34 <peter1138> Hmm, okay, Current one isn't very good for ships. 😦
22:02:56 <peter1138> There's Wentbourne of course. And that 4kx4k save of yours that I lost.
22:03:19 <xarick> oh, wentbourne needs to switch breakdowns on
22:05:10 <xarick> oh actually no need to enable breakdowns
22:05:48 <peter1138> I also test with smaller maps (e.g. 512x512) with some AIs.
22:06:00 <peter1138> Not exactly how players play, but...
22:06:42 <xarick> waiting for 1000 calls
22:07:12 <xarick> > [2024-02-24 22:06:59] dbg: [misc:0] [FindClosestReachableShipDepot, 1000] 81388 us [avg: 81.4 us]
22:07:12 <xarick> > [2024-02-24 22:06:59] dbg: [misc:0] [FindClosestShipDepot, 1000] 203579 us [avg: 203.6 us]
22:07:27 <xarick> this is with the unlimited range
22:07:47 <xarick> not sure if that's cheating
22:07:52 <xarick> since it favours my approach
22:09:07 <peter1138> What's the default range 80?
22:09:30 <peter1138> You could measure the performance of that too.
22:09:34 <xarick> 80 for his, 8000 equivalent for mine
22:10:11 <peter1138> And perhaps count how many result in no depot, because of the range limit.
22:10:23 <xarick> oh, that I'm not sure how to do
22:13:45 <ajmiles> OK, got it. Interleaving scrolls and sprite drawing fixed the shearing around towns/industries.
22:14:10 <ajmiles> Ah sorry, didn't realise it picked that up
22:14:47 <peter1138> Open a window in the middle of the screen and scroll the viewport behind it. That's another good test of it.
22:15:28 <peter1138> Your "left third, middle third, right third" corresponds to the toolbar/statusbar.
22:24:18 <peter1138> Yup, that's the one.
22:27:09 <ajmiles> Unless of course you try and draw a line...
22:27:58 <ajmiles> This is where I find out you want *diagonal* lines as well as vertical/horizontal ones
22:30:33 <peter1138> A vertical/horizontal line is just a rectangle 😉
22:31:09 <ajmiles> Can we not just have the players turn their head until the diagonal line is vertical?
22:31:32 <peter1138> But for lines you should be able to just draw... a line?
22:31:46 <peter1138> Or at least a pair of triangles...
22:32:11 <peter1138> Just needs to be done in the right colour 🙂
22:32:14 <ajmiles> Is there a prescribed pattern for line rasterisation that matters? Does it have to match what today's blitters do exactly, or is a GPU line primitive close enough?
22:32:49 <peter1138> GPU line primitive should be fine I think./
22:33:12 <peter1138> Nobody is expecting a pixelized line .
22:33:30 <michi_cc[d]> Diagonals lines are graphs and the link graph overlay I think. Don't think anyone would notice a different there.
22:33:49 <peter1138> Also: the current line drawing code is broken for even-width vertical/horizontal lines. They are not used much.
22:34:27 <michi_cc[d]> I think the bigger problem for GPU line primitves is that you want different thicknesses.
22:34:52 <ajmiles> Yeah, I just spotted the 'width' parameter...
22:34:59 <ajmiles> Two triangles it'll have to be
22:36:05 <ajmiles> Although in the interest of getting to the things that matter the most, I will probably just single pixel wide line prim everything for now
22:36:37 <ajmiles> I need to tackle the fact that alpha blending isn't going to work
22:37:43 <ajmiles> Oh, I've remembered one other question I had. Sprites can have RGBAM channels - do any need all 5? If so, I'll need to split RGBA off from M when that happens
22:38:18 <michi_cc[d]> Yes, the M channel can be used to apply e.g. a company color remap to a RGB pixel.
22:38:39 <michi_cc[d]> It is allowed at least.
22:38:47 <michi_cc[d]> No idea if anybody *used* it.
22:38:55 <peter1138> If it's possible, it's used.
22:40:21 <michi_cc[d]> But I don't think any of the 32bpp blitters actually handle that correctly in all cases as they resolve the M when doing alpha blending, so any further palette animation will not affect the pixel anymore.
22:40:28 <peter1138> There's also some weird blending possible that ends up darkening the remapped pixel.
22:40:49 <michi_cc[d]> 40bpp blitter is a bit different as it won't resolve the M channel until the video driver gets to it.
22:41:16 <ajmiles> I'm largely modelling what I'm doing after 40bpp-anim
22:42:00 <peter1138> Water slopes use palette animation along with darkening via the RGB parts to get darker/brighter palette animation.
22:44:01 <peter1138> It's magic which I didn't think worked, but it does 😄
22:44:19 <peter1138> (But it's not alpha channel)
22:45:56 <ajmiles> And in OpenTTD terminology, CRASH_REMAP refers literally to crashed vehicles?
22:46:13 <_glx_> it remaps with grey scale
22:46:26 <_glx_> primarily for crashed vehicles
22:46:26 <peter1138> Yes, it's a special case to draw crashed vehicles in a all dark grey.
22:46:33 <michi_cc[d]> Yeah, there's two different things. RGB can always be used to "tune" the M color (i.e. that shader blend formula) and still keep the palette animation.
22:46:58 <peter1138> (In original 8bpp mode that just a regular palette remap, but they don't work with 32bpp sprites, so we added the special case)
22:47:36 <_glx_> yeah in 8bpp you just change the RGB value for a given index
22:47:47 <michi_cc[d]> It can also be used to apply a M -> M remap (for stuff like company colours). That one happens at blitting time and is fixed. This remap can also be on a partially transparent pixel.
22:48:23 <peter1138> The contortions we've done to continue supporting the mostly 8bpp graphics 😄
22:48:40 <michi_cc[d]> So alpha blending with M is a blitter things, and palette animations a video driver thing where there is no more alpha.
22:50:01 <michi_cc[d]> The one limitation of the 32bpp blitters is that if you apply alpha blending to a M color, it will be converted to RGB and you loose the possibility to later do palette animation. The 40bpp blitters keeps the M as long as possible.
22:50:13 <michi_cc[d]> Water slopes are opaque, so this limitation does not apply.
22:51:09 <ajmiles> That was the mistake I made earlier today when the water animation wasn't working. As I was going through it, I saw less and less need for the anim buffer at all, I could just resolve M to RGB at blit-time and deal only with DST.
22:51:32 <ajmiles> Alas, the water was then static because it had an M of 0 and a valid RGB in DST
22:52:22 <ajmiles> So 'anim' is back and retained as long as it is for the 40bpp blitter
22:52:51 <ajmiles> But any hope I had that I could alpha blend is now gone, I can't alpha blend onto colours that are represent only as dst=0, anim=m
22:53:34 <ajmiles> It's almost like there's a reason there isn't already a GPU blitter
22:54:24 <peter1138> Maybe resolve M to RGB at blit-time as well? Then you can alpha blend onto that.
22:55:04 <ajmiles> How do I then decide whether to respect RGB or M at the end?
22:56:09 <michi_cc[d]> If there's an M, the current opengl shader apply the remap, which is basically something close to "take colour from M and lightness from RGB".
22:56:52 <michi_cc[d]> Well, not really lightness or value (i.e. HSV/HSL), but something similar.
22:56:55 <_glx_> IIRC M typically contains company colours and company colours 2
23:02:36 <xarick> mediocre debugging skills!
23:04:15 <xarick> what explanation do i have for this...
23:06:10 <xarick> one possibility is cost of curves
23:07:00 <xarick> tile costs, turn costs, aqueduct costs, everything is accounted for in that 8000
23:09:33 <xarick> need to test with unlimited range
23:15:10 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:16:33 <xarick> not sure why I tested this...
23:22:03 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:23:41 <xarick> my bed is waiting for me, cyas goodnight
23:44:44 *** tokai|noir has joined #openttd
23:44:44 *** ChanServ sets mode: +v tokai|noir
23:51:36 *** tokai has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵
