IRC logs for #openttd on OFTC at 2023-12-22
โด go to previous day
00:46:58 <talltyler> Re: breakdowns, the PR factors in actual travel time including waiting at signals and breakdowns, so it would space out vehicles based on the rolling average of the travel time. So yes, I would call that breakdown-friendly
00:47:59 <talltyler> The current PR does not include an AI spec extension to enable or disable autoseparation but it could be added in a separate PR
01:07:42 <talltyler> Fragile rail networks break themselves ๐
01:11:05 <talltyler> Good morning! You fixed it! ๐
01:11:09 <emperorjake> there I think I fixed it
02:34:10 *** thelounge345 has joined #openttd
02:44:54 *** Wormnest has quit IRC (Quit: Leaving)
02:45:42 <talltyler> (Iโm bored at my in-laws for the holidays :P)
03:49:46 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
06:03:35 *** TinoDidriksen has quit IRC (Read error: Connection reset by peer)
06:03:53 *** TinoDidriksen has joined #openttd
06:04:33 *** TinoDidriksen is now known as Guest11399
06:23:55 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:30:38 *** ChanServ sets mode: +v tokai
07:37:21 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
08:37:45 <andythenorth> do we have any way to place houses, or do I need to roundtrip to the scenario editor?
08:38:05 <andythenorth> town only had 2 buildings, and I placed a statue and an industry that replaces houses ๐
08:38:35 <merni> try "fund town growth"?
08:38:37 <peter1138> Set up a bus service in the village, that'll make it grow.
08:41:09 <truebrain> ^^ happens when I don't understand the motivation of a PR. You get a big wall of text ๐
08:43:56 <andythenorth> merni: nah, does nothing, growth rate is probably 0 if popn. is 0
08:44:06 <andythenorth> peter1138: such bus
08:44:18 <peter1138> I mean, I do have a patch for 32 colours, but they were still palette colours, so nothing really distinct.
08:44:32 <peter1138> And of course the legendary RGB colours, which is probaby old enough to vote now.
08:44:41 <truebrain> drop 8bpp? ๐ ๐
08:44:54 <truebrain> the lack of constrast of most of these "extra" colours is just painful
08:45:05 <peter1138> I think even without the restrictions of a palette there's still only so many constrasting colours.
08:45:32 <andythenorth> a 256 colour palette would have covered most things IMHO ๐
08:45:38 <truebrain> but our UI colouring scheme currently makes it even worse ๐
08:45:55 <truebrain> anyway, I think giving priority to a few high-constrast colours is an excellent idea
08:47:10 <andythenorth> our DOS palette is only 244 colours, plus there are some entries for animated cycles that are almost identical to non-animated colours ๐
08:47:38 <truebrain> no, the argument peter1138 makes, rightfully, is that no matter your palette, there are only so many company colours you can use that have a high constrast with each other
08:47:49 <truebrain> so even in that world, prioritizing those that stand out to each other is a good move
08:48:11 <truebrain> but as I wrote in my reply, the motivation of that PR is rather unclear to me
08:48:41 <truebrain> to me, it removes something that helps players, so I am puzzled ๐
08:49:26 <peter1138> git rebase master redo-rgbcc
08:49:50 <truebrain> and another rabbit hole he goes!
08:49:58 <peter1138> Last commit in that branch, 3rd Jan 2023, first commit, 27th Jan 2013.
08:50:32 <peter1138> I have so many unfinished tings.
08:51:02 <truebrain> you get those unexpected gems like "32bpp -> 8bpp" ๐
08:51:26 <truebrain> we keep voting against that idea ๐
08:51:37 <reldred> make people unreasonably mad
08:51:42 <emperorjake> What we need is the RGB CC patch
08:51:56 <emperorjake> And a randomise colour button
08:51:57 <reldred> rgbcc would be nice yes
08:52:29 <truebrain> we should allow donations on patches of peter1138, so we can see what is popular ๐
08:52:49 <peter1138> Did you see my last update to that patch? Unexpected turn: supporting 8bpp transparency remaps in 32bpp mode.
08:53:23 <emperorjake> I think adding a random CC button would be a fairly easy and useful addition, unfortunately I have no idea how to begin coding something like that
08:53:25 <peter1138> But it means I need to rewrite it to the palette conversion/lookup is in a sensible place.
08:53:27 <reldred> I would absolutely throw money down on a patch bounty board
08:54:11 <peter1138> I should probably remove the 15 year old TODO comment actually :)
08:54:24 <truebrain> peter1138: do people want that ? (8bpp transparency remaps in 32bpp)
08:54:53 <truebrain> maybe more to the point: should that be part of that PR? ๐
08:55:08 <emperorjake> The PR I made was more of an exercise in fiddling with the code and sparking a discussion, which I think was satisfied. I should have known that removing behaviours coded by Sawyer himself wouldn't go down too well ๐
08:55:35 <peter1138> No, it should be a separate PR, I put it there because it uses the same rgb to palette index code.
08:55:52 <truebrain> peter1138: ah; that makes more sense ๐
08:56:07 <truebrain> emperorjake: Mainly it seems to be fixing things in the wrong order ๐
08:56:22 <truebrain> but removing lines of code is easy: now try adding a few! ๐ ๐
09:03:08 <emperorjake> My idea looks something like this: the Random button is added to the company colours GUI and when pressed, it selects a random combination of 2 company colours where available.
09:10:45 <peter1138> 08:54 < truebrain> peter1138: do people want that ? (8bpp transparency remaps in 32bpp)
09:11:03 <peter1138> ^ that was used by MB's newstats.grf. Probably no others :D
09:11:20 <truebrain> my reasoning: it was a TODO for .. 10+ years?
09:11:21 <peter1138> But potentially others if it worked in 32bpp mode.
09:11:38 <peter1138> I didn't scratch anyone's itch.
09:12:06 <truebrain> no, okay; I am still fine with a PR to add it btw
09:12:13 <truebrain> was just wondering if there was an active demand/request for it
09:13:04 <peter1138> 21:15 < locosage> though iirc there was some recoloring thing in newgrf format that only 8bpp-simple supported
09:13:24 <peter1138> locosage mentioned it, and I realised it would be simple with the stuff I already had :)
09:13:42 <truebrain> why do we have `yr` in text ... was adding the `ea` so much effort? Odd .. (reviewing a PR about real-time units)
09:14:00 <truebrain> peter1138: that is how we build most things, not? Because we can! ๐
09:15:45 <peter1138> emperorjake, does every addon set use "2cc" mode these days?
09:16:58 <peter1138> emperorjake, maybe you could look at setting the initial second cc of a new company to a different random colour.
09:17:42 <peter1138> Hmm. Splitting code = adding more includes :O
09:17:44 <truebrain> maybe we should redo the whole CC, and unlink the colour used in the interface from the colours used on the vehicles?
09:18:03 <emperorjake> I can't think of any recent NewGRF that uses purely 1CC mode. In JP+ Engines, I use a mixture as some of the real liveries required the CC green, but I'm fixing that with 32bpp and/or variants ๐
09:18:22 <peter1138> Interface colours aren't the same as company colours already.
09:18:37 <emperorjake> NewCC set affects the colours of some windows
09:19:43 <peter1138> Hmm. oh yes, they are initialized via the palette remaps, so I guess they are the same.
09:20:00 <truebrain> I never actually understood NewGRFs and CC; I also can never remember where to find the interface to change colours ๐
09:20:04 <peter1138> We have so many colour systems it's confusing :)
09:20:31 <truebrain> But we have a company colour we use in the interface, on minimap, graphs, etc
09:20:39 <truebrain> and we use that colour primary for vehicles too
09:22:06 <peter1138> By default yes. That's... pretty much the point of company colours, no?
09:22:21 <truebrain> kinda; I am now actually trying to have my vehicles another colour than my company colour
09:22:25 <truebrain> I guess that is not possible
09:22:31 <truebrain> that interface is so incredibly unclear to me ๐ฆ
09:22:46 <peter1138> It is entirely possible.
09:22:58 <truebrain> you first have to select an entry
09:23:03 <truebrain> than you can change it by the dropdown in the top?!
09:23:11 <truebrain> does anyone actually figure out how to use that?
09:23:27 <truebrain> only because you said it was possible, that I was clicking around more ... agressively
09:23:31 <truebrain> to figure out how that actually works
09:23:35 <peter1138> It's a weird UI, but it lets you change multiple rows at once. With the hidden ctrl-click.
09:23:38 <truebrain> sorry, but this is horrible UX. Sorry to who-ever wrote it ๐ฆ
09:24:04 <truebrain> it really is entirely unclear that is how it is suppose to work
09:24:19 <andythenorth> It makes complete sense
09:24:19 <truebrain> hihi, multiselect always picks the first colour
09:24:23 <andythenorth> you just have to check boxes
09:24:27 <andythenorth> like no UI ever I've seen
09:24:39 <truebrain> what would help, I think, is if the dropdown is at the bottom
09:24:59 <truebrain> as it now feels like a filter
09:25:01 <truebrain> like most other windows
09:25:09 <peter1138> andythenorth, do you even look at it?
09:25:19 <andythenorth> I have learnt not to see it
09:25:28 <peter1138> andythenorth, those boxes haven't existed for years.
09:25:33 <andythenorth> I just set 'red and white' at the start of the game and run away
09:25:37 <truebrain> why are there two "Show train color schemes" in that window?
09:26:06 <andythenorth> oh yes, the checkboxes are gone visually ๐
09:26:31 <truebrain> hmm .. guess they are NewGRF related?
09:26:48 <peter1138> You mean two columns of colours?
09:26:49 <truebrain> or did someone reuse the tooltip while it has a different function? ๐
09:26:56 <andythenorth> screenshots ๐
09:27:14 <peter1138> The second set are for vehicle groups.
09:27:20 <truebrain> these two buttons have the same tooltip
09:27:24 <truebrain> but the second one gives an empty list
09:27:34 <peter1138> Yeah, fucking idiot coder. Why bother.
09:27:46 <truebrain> well, at least we know who wrote it ๐
09:27:53 <truebrain> vehicle groups, ah, that makes sense ๐
09:27:54 <andythenorth> who reviewed it? ๐
09:28:01 <andythenorth> who tested the PR?
09:28:12 <emperorjake> peter1138: omg, you can do that? ๐ฎ Still learning things...
09:28:26 <andythenorth> oof ctrl-click is multi-select ๐ฎ
09:28:31 <truebrain> ah, yeah, okay, when I make a group, things show up. That is nice, so I can colour groups ๐
09:29:01 <truebrain> okay peter1138, I take by my suggestion .. you basically did exactly what I was suggesting ๐
09:29:41 <emperorjake> Group colours are one of the best things ever. I used to have to make whole separate companies to acheive the same effect
09:29:56 <truebrain> yeah, we just need to fix the tooltip ๐
09:30:07 <peter1138> Okay, so improvements to that window: 1) move the dropdowns to the bottom so they look like actions not filters. 2) fix the tooltips for groups 3) maybe should some explanation text when you go to groups and have none.
09:30:22 <truebrain> owh, 3 would be excellent, yes
09:30:47 <truebrain> okay, I now really like this window; that gives colour to your game ๐
09:33:04 <truebrain> should we add, next to the "Standard Livery", a "Company Colour" of sorts? To control the colour used in minimap and graphs etc?
09:33:14 <truebrain> as I might want all my vehicles to look purple
09:33:17 <truebrain> but be red on the minimap?
09:33:55 <truebrain> hmm, one other thing that is a bit confusing that might be easily solved: "Standard Livery" sets the "Default" colour
09:34:02 <truebrain> should we call it "Default Livery" instead?
09:34:10 <emperorjake> Wouldn't that get too confusing, as the purpose of CC is to tell players apart? Nothing stopping someone from already doing that manually though
09:34:26 <truebrain> exactly; you can already do it, but takes a lot of clicking ๐
09:35:22 <emperorjake> Infrastructure like rail fences and stations etc. would still follow the main company colour
09:35:52 <emperorjake> but there was discussion on Discord channel #jgr-patch-pack not long ago about adding CC options for stations and objects separately
09:36:09 <truebrain> lol, I can even imagine people want to colour each station differently ๐
09:36:32 <peter1138> truebrain, people want to colour industries differently... and they don't even own them.
09:36:38 <truebrain> I also think there should be a charge to changing colour ๐
09:36:42 <truebrain> repainting takes effort!
09:37:16 <truebrain> anyway, I was reviewing a patch ๐
09:37:18 <emperorjake> I've suggested it before, how about a paintbrush tool like in RollerCoaster Tycoon ๐
09:37:46 <peter1138> I've never got into RCT. What does that do?
09:38:14 <truebrain> honestly, it is a bit odd, that we do allow groups to have different colours, but that you can't set the colour of your individual station ๐ But I guess it is mostly because nobody did it, more than any principle issue ๐
09:39:16 *** Guest11399 is now known as TinoDidriksen
09:39:39 <peter1138> There's also the problem that adding arbitrary 'livery' sections requires a savegame bump, and UI work to make sure it goes in the right place.
09:39:53 <peter1138> (That window was designed in pre-C++-awakening.)
09:40:08 <emperorjake> It's a bit clunky but you can repaint individual vehicles and sections of track. From the scenery menu you can also recolour and repaint individual scenery objects
09:40:16 <truebrain> I read emperorjake is looking for more C++ work, so ... ๐
09:40:24 <locosage> there is also a bit of a problem in mp when people start using colors of other companies
09:41:09 <peter1138> Okay so now we need to reserve map bits for company colours too :D
09:42:37 <peter1138> 4 bits for 1cc, 8 bits for 2cc -- but not quite.
09:42:49 <peter1138> There are 16 colours so that leaves no room for 'default'.
09:42:51 <truebrain> 16 colours isn't enough!
09:43:02 <truebrain> so 24bit for 1cc, 48bit for 2cc!
09:43:23 <truebrain> just imagine the bug-report .. "OpenTTD uses twice as much memory as before!!!!!!!"
09:43:28 <peter1138> static uint48_t map_colour[MAP_SIZE]
09:43:37 <peter1138> truebrain, you know what... nobody would notice.
09:43:50 <peter1138> We use so little memory compared to modern games...
09:44:01 <truebrain> that one person will notice ๐
09:44:13 <peter1138> Someone running it on a 256MB Raspberry Pi...
09:44:15 <truebrain> but yeah, we are VERY picky with memory, for no real good reason ๐
09:44:20 <locosage> 32bpp for shady companies ;)
09:44:31 <truebrain> no need for `map_colour` to be allocated on a dedicated server!
09:45:04 <peter1138> truebrain, ah, so colours are not synchronized between clients.
09:52:11 <reldred> openttd doesn't use anywhere near enough memory, I'm generating a 2k x 8k map atm in jgrpp and not even tipping 400MB of ram.
09:52:32 <truebrain> increase your sprite-cache
09:55:21 <reldred> openttd also doesn't use enough cpu, just, I dunno, run a small crypto miner or something to bump it up a little and pad out the beverage fund
09:57:00 <reldred> ooh, no, I got it to 416MB of ram.
10:05:00 <truebrain> well, that PR is not far from being complete, that is nice ๐
10:05:47 <truebrain> I think that concludes my list of things I promised to do ๐
10:08:08 <truebrain> what are we looking at?
10:09:24 <peter1138> Something is being sized wierdly :)
10:10:32 <peter1138> Literally unplayable.
10:10:57 <peter1138> I'm guessing the DHCP server is returning the wrong value.
10:58:17 <emperorjake> I think that only works if the liveries are also in the same position on the list
11:24:59 <georgevb> emperorjake: They both are located on ID 30
11:34:43 *** fairyflossy has joined #openttd
11:34:43 <fairyflossy> Yeah but one has more entries before it than the other, I think that's the issue? Can't talk about the technical side of fixing it, though
11:35:43 <_zephyris> peter1138[d]: Hmm. My fault?
11:37:29 <peter1138> _zephyris, don't think so. I don't know why the row height is smaller, but if things overflow it's generally OpenTTD's fault.
11:37:56 <peter1138> IIRC I think in this case it just doesn't check that the row is tall enough for the sprites because by default it is.
11:38:01 <peter1138> So, it's me being lazy.
11:58:21 <_zephyris> Must be the profit/loss indicator. Pretty sure I made that the same size though.
11:59:01 <LordAro> offsets might be buggy, but OTTD shouldn't display it like that either
12:00:10 <peter1138> The row itself is a different height, which is odd as that is determined by some other bounding boxes.
12:11:03 <_zephyris> On another note, all this chat about 2CC reminds me that 2CC for base set vehicles would be nice...
12:11:34 <peter1138> Needs a way to turn it on...
12:12:16 <peter1138> Someone probably mentions station 2cc too.
12:12:44 <peter1138> Anything-company-built-2cc
12:16:33 <peter1138> Imagine if it was encoded into the sprite data itself...
12:16:36 <_zephyris> I poked at adding 2CC to stations. Naively thought it'd be easy.
12:17:52 <peter1138> Resolve Sprite. if sprite has 2cc flag, apply 2cc remap else apply 1cc remap.
12:18:04 <peter1138> That would almost be sensible...
12:18:39 <peter1138> Although it would make detecting enabling 2cc awkward.
12:25:37 <xarick> That CircularTileSearch from OpenTTD is a nice little treasure. So much complexity compressed into a tiny piece of code
12:26:17 <xarick> I'm extending it with a few improvements
12:26:47 <xarick> and it's been magical, that I didn't have to add that much more to it to make it work more efficiently
12:34:54 <xarick> What's still missing is: I need to limit distance_outer to the minimum required so that the last radius is inside the map, cut the excess radius that is
13:58:09 <peter1138> andythenorth, per-company fog-of-'war'?
13:59:30 <_glx_> good luck to find 16 free bits in all tiles
13:59:45 <peter1138> That's easy. Just add 16 more bits.
14:00:30 <peter1138> (Pretty sure it is a bad idea :))
14:01:01 <_glx_> I'm thinking about replacing the "tabs" in script debug with a dropdown
14:30:42 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
14:38:22 <peter1138> Then up the company limit to 255 and have an extra 256 bits in the array. That's only 32 bytes!
14:38:44 <peter1138> 512MiB for the largest map :)
14:41:05 *** rau117 has quit IRC (Quit: User went offline on Discord a while ago)
15:01:42 <xarick> uhm, I have a question
15:02:02 <xarick> TimerGameCalendar::date_fract vs TimerGameTick::counter
15:02:16 <xarick> what's the difference, how do I know which one to use
15:02:31 <peter1138> date_fract is tick within the date.
15:02:42 <peter1138> So it is already limited to DAY_TICKS.
15:03:26 <peter1138> Okay, I can bolt non-SSE code into the SSE blitters...
15:05:00 <peter1138> (The palette lookup is probably slow enough to not care anyway.)
15:05:25 *** virtualrandomnumber has joined #openttd
15:06:26 <talltyler> date_fract counts up to DAY_TICKS and then gets reset to 0 when the date changes. Counter counts up forever and is never reset.
15:08:02 <xarick> hmm, seems TimerGameTick::counter is the one to use
15:08:26 *** virtualrandomnumber has quit IRC ()
15:09:15 <xarick> if it resets the same manner as day_ticks, I don't see the difference
15:09:34 <xarick> ah, nevermind, the % 74 is ommited
15:10:57 <xarick> okay, it's starting to make sense in my head
15:17:13 <Rubidium> peter1138: regarding 2CC in base sets, is it naive of me to think that a field in the obg file would be enough to enable it for *all* applicable sprites? Then it's up to the author(s) of the base set to either us all 2CC or all 1CC, but there is at least a choice
15:17:29 <locosage> hm, I just thought that alternative to autoseparation might be some kind of "load until full or other vehicle arrives" order
15:22:29 <merni> locosage: how would that be an alternative? in passenger transport you don't really need a vehicle at the station at all times, but it is still useful to have them arriving at regular intervals
15:31:05 <locosage> merni: because that won't make them group up like load if available does and it's always good to gave vehicle loading to keep station ratings
15:31:28 <merni> > it's always good to gave vehicle loading to keep station ratings
15:31:28 <merni> That's not the only goal which autoseparate achieves though
15:32:49 <merni> Having trains always loading also blocks up tracks and requires more trains on a longish passenger line than would otherwise be necessary
15:34:20 <merni> also when was the last time you saw a passenger station other than a city centre hub that *always* had a train there
15:34:43 <locosage> anyway it's an alternative to autoseparation because it separates vehicles
15:34:52 <locosage> keeping vehicles at stations I see as an advantage
15:35:17 <merni> locosage: so do manual timetables then
15:35:41 <merni> but we aren't arguing autoseparate is unnecessary because you can always do manual timetables instead
15:35:43 <locosage> timetables are a waste of time
15:36:10 <merni> and keeping a train always loading (or more than one if traffic flows in many directions) is a waste of space and trains
15:36:51 <_jgr_> It really depends on what quantity you're trying to optimise for
15:37:00 <locosage> keeping a train loading is like openttd 101
15:37:28 <merni> locosage: for freight or non-cargodist pax where realism is not important, *perhaps*
15:37:35 <_jgr_> Not everyone cares about appeasing the station ratings algorithm
15:39:19 <locosage> well, I'll take gameplay-based separation over eyecandy one :p
15:42:52 <merni> That's up to you but autoseparation as implemented in jgrpp and in this pr are not "eyecandy", they ensure a fixed interval between vehicles which is both "gameplay based" and "efficient" (in that it requires fewer trains and tracks than keeping a train waiting at all stations at all times)
15:43:20 <_jgr_> The auto-separation in my branch is not like this PR, they're not directly comparable
15:44:12 <merni> Their effect seems to be rather similar though since they are both based on time intervals between vehicles, no?
15:46:33 <_jgr_> Mostly yes, though the separation is applied at all stations, not just one per order list
16:02:31 *** Wormnest has joined #openttd
16:11:32 <peter1138> But why bother righg?
16:13:31 <LordAro> don't suppose you've done any benchmarking?
16:13:50 <LordAro> could be interesting to know if adding a load of ifs to the blitters makes any notable impact
16:14:43 <peter1138> No I have not. It is at least added out as far as possible.
16:16:43 <peter1138> It could templated out I suppose.
16:16:50 <peter1138> (Like BlitterMode is)
16:25:21 <locosage> your use of color distance seems wrong
16:25:46 <locosage> since you're using non-smooth distance you're basically calculating some colors with one distance formula and some with another
16:26:40 <locosage> and then compare them to find "best"
16:29:12 <locosage> also variable declaration inside of if condition for some reason...
16:34:05 <locosage> _palette_lookup can probably be pre-calculated...
17:06:09 <peter1138> It's not wrong but perhaps needs a note that col1 should be a palette colour. col2 is bitcrushed precisely so that order of colour lookup does not affect the result.
17:08:25 <peter1138> Anwyay, I think I'll do the template specialization.
17:20:49 <peter1138> LordAro, no longer adding a bunch of ifs :)
17:21:56 <locosage> wrong is comparing distances from two different formulas
17:22:08 <peter1138> There's only one formula.
17:22:12 <locosage> very similar colors can have very different distances like that
17:22:16 <locosage> (128, 0, 0) - (128, 0, 255) : 130050
17:22:16 <locosage> (127, 0, 0) - (127, 0, 255) : 195075
17:22:42 <locosage> there is ternary in CalculateColourDistance that chooses the formula
17:24:26 <locosage> that wiki page you linked even has a smoothened formula to avoid this issue
17:27:58 <locosage> example with the same color:
17:27:58 <locosage> (128, 0, 0) - (129, 0, 155) : 48053
17:27:58 <locosage> (128, 0, 0) - (127, 0, 127) : 48389
17:28:19 <locosage> here it would pick (129, 0, 155) over (127, 0, 127)
17:28:32 <locosage> trading 1 in red for 30 in blue
17:29:45 <locosage> well, not even trading, they both differ by 1 in red
17:31:11 *** giords[m] has quit IRC (Quit: Client limit exceeded: 20000)
17:32:13 <locosage> even more exaggerated example would be picking (129, 0, 255) over (127, 0, 209) as closest to (128, 0, 0)
17:35:10 <peter1138> There is a bigger problem.
17:35:59 <peter1138> The reshade stuff (which isn't actually used here), is incorrect cached.
17:37:40 <locosage> locosage: though looking at the image it's hard to tell which is closer xD
17:40:44 <peter1138> I think reshade can be separate lookup, it does not need to handle colour, only brightness.
17:40:49 *** Hanicef has joined #openttd
17:44:15 <locosage> also, if I understood it right I'd expert reshading involve AdjustBrightness at some point
17:44:35 <peter1138> It does, but that isn't used here so I didn't pull it in.
17:45:53 <peter1138> The rest of "support 32bpp in 8bpp mode" is not included here.
17:50:24 <peter1138> Just going to remove the shade stuff for now, if the patch needs it it can add it.
17:52:34 <peter1138> ~600 ms to precalculate.
17:53:43 <peter1138> Although that is in debug mode.
17:54:11 <peter1138> 77 ms if I reduce the bits to 5.
17:54:44 <peter1138> int avgr = (col1.r + col2.r) / 2;
17:54:45 <peter1138> int r2 = ((2 + (avgr / 256)) * r * r) + (4 * g * g) + ((2 + ((255 - avgr) / 256)) * b * b);
17:55:38 <peter1138> The other equation is considerably faster.
17:56:20 <peter1138> 400ms for the other formula.
17:56:28 <locosage> can just add the whole array as constant
17:56:40 <locosage> 256kb to executable size though I guess
17:57:10 <locosage> double that with reshading I guess
17:57:18 <peter1138> Does NewGRF support 256KiB data chunks? :D
17:58:38 <peter1138> Hmm, probably reshade can be done with just 1 channel.
17:58:51 <locosage> peter1138: avgr / 256 seems wrong
17:58:54 <peter1138> As the remap is always blue
17:58:55 <locosage> it will round in integers
18:00:57 <peter1138> That is quicker o_O
18:02:16 <peter1138> Probably the formula has some special meaning that I've taken literally.
18:03:38 <locosage> it just blends those two formulas in the if
18:03:58 *** wallabra has quit IRC (Quit: Bowserinator is wrong don't blame iczero)
18:04:02 <locosage> on avgr = 0 one is used on 255 another, and weighted avg in between
18:04:21 *** wallabra has joined #openttd
18:04:58 <locosage> though idk why it divides by 256, should be 255
18:05:39 <locosage> close enough I guess xD
18:06:08 <xarick> Hmm... needs more improvements
18:06:54 <xarick> CircularTileSearch is still not at the level of AreTilesQueued
18:11:30 <peter1138> Unweighted isn't that terrible to be honest.
18:12:08 <locosage> that's just naive euclidean distance
18:12:15 <peter1138> Of course I'm only testing with the green tint so there's not a lot of options :)
18:12:41 <peter1138> Hmm, let's see if I disable the non-custom transparent mode.
18:12:49 <locosage> when I tested recolors for town zones I found redmean to be noticeably better
18:13:00 <locosage> not much but noticeably
18:15:10 <peter1138> 286ms for the naive calculation.
18:17:16 <locosage> I think dropping bits would have less impact than worse distance formula
18:18:01 <locosage> bits just mess close colors where formula shifts the whole color space
18:21:53 <locosage> and rmean without /2
18:24:17 <xarick> AreTilesQueued jumps to the exact coordinate of the first tile that is sure to be inside the map for each of the 4 sides, and starts iterating these tiles one by one until it reaches the other end of the segment inside the map. If the remaining tiles for that side are outside the map, it skips to the next side. If an entire side is outside the map, it skips the entire side. If entire rings of
18:24:17 <xarick> sides are outside the map, they are just skipped. CircularTileQueue on the other hand is still doing minimal tile by tile steps for those outside the map for each side. It has only just got a limit to the number of rings, so that the last ring it starts to will have at least some tiles inside the map.
18:25:51 <xarick> AreTilesQueued works from the outside to the inside, CircularTileQueue works from the inside to the outside
18:27:00 <peter1138> I need to pull in the 32bpp-to-8bpp changes to verify the results
18:27:49 <xarick> RectangleQueue is just very basic. It's slapping 2 rectangles inside the map. The tiles that remain from the difference of those two rectangles are just added to a list that will be then iterated via TileIndex order.
18:31:03 <locosage> hm, I wonder how it choses colors for cc
18:31:17 <locosage> because I just remembered that _colour_gradient array is wrong
18:31:24 <locosage> it only uses 7 colors out of 8
18:35:01 <peter1138> _colour_gradient is for UI colours.
18:35:17 <locosage> yeah, but it's filled from recolor sprites
18:36:35 <locosage> so I'm trying to figure out why cc recolors work))
18:36:56 <peter1138> 1) All of _colour_gradient is fill, not just 7 colours.
18:37:02 <locosage> when gradient taken from them is not
18:37:05 <peter1138> 2) _colour_gradient has nothing to do with cc recolours.
18:39:56 <peter1138> Oh, fair. Answer to that is that index 0 is never used.
18:40:37 <xarick> why use pastebin and not gist.gisthub.com
18:41:08 <peter1138> _colour_remap_ptr = GetNonSprite(pal, SpriteType::Recolour) + 1;
18:41:14 <peter1138> const byte *b = GetNonSprite(PALETTE_RECOLOUR_START + i, SpriteType::Recolour);
18:41:22 <peter1138> That + 1 is missing, so...
18:41:44 <peter1138> C6 there is actually C5.
18:42:54 <locosage> I even tried adding it back at some point but didn't particularly like the result
18:43:03 <locosage> so may even be intentionaly
18:43:04 <peter1138> No it's washed out.
18:44:09 <peter1138> The lack of +1 and then shifting the offsets by one.
18:44:20 <peter1138> I'm sure the final colours are correct and intentional.
18:44:47 <peter1138> But that still has nothing to do with CC recolours :)
18:46:39 <locosage> well, it has, but error isn't in recolors
18:47:47 <locosage> and I'm doing is just trying to get the list of company colors xD
20:02:42 *** TinoDid|znc has joined #openttd
20:02:47 <xarick> is it possible to create a table of functions in squirrel
20:02:51 *** TinoDidriksen has quit IRC (Ping timeout: 480 seconds)
20:03:04 <xarick> access it like an array
20:03:07 *** TinoDid|znc is now known as TinoDidriksen
20:13:02 <andythenorth> Almost everything in squirrel is actually a table slot
20:13:42 <peter1138> Not quite the right shade.
20:13:47 <andythenorth> You wouldnโt array access functions though that might be weird; you want slots
20:16:21 <andythenorth> language is a bit weird, so you can do all kinds of stuff, also with bonus weird syntax
20:21:58 <xarick> > ` local is_inside = [
20:21:58 <xarick> > function(x, y) { return x >= _min_x; }, // DIAGDIR_NE
20:21:58 <xarick> > function(x, y) { return y <= _max_y; }, // DIAGDIR_SE
20:21:58 <xarick> > function(x, y) { return x <= _max_x; }, // DIAGDIR_SW
20:21:58 <xarick> > function(x, y) { return y >= _min_y; } // DIAGDIR_NW
20:22:02 <xarick> > ` if (!is_inside[dir](x, y)) {
20:24:53 <xarick> ah snap... the index _min_x does not exist
20:25:03 <xarick> it can't access my global variables?
20:27:14 <andythenorth> Put it in the root table? ::_min_x
20:28:11 <andythenorth> Canโt remember how to actually do it ๐
20:41:17 <xarick> hacks! it works function(x, y, min_x = _min_x)
20:44:20 <Eddi|zuHause> accessing global variables is an antipattern
21:04:48 <Rubidium> peter1138: have you considered a constexpr/eval table? Won't that be compiled as a table in the executable, while it's being programmed. It will still be 256 kiB of table, but probably easier to maintain/check than a NewGRF blob
21:05:43 <peter1138> That sounds like a bit of magic.
21:11:12 <xarick> but... it introduced a bit of code repetition
21:11:53 <xarick> How do I avoid repeating
21:11:53 <xarick> > `x += tileoffs_by_diagdir[dir].x;
21:11:53 <xarick> > y += tileoffs_by_diagdir[dir].y; `
21:20:16 <peter1138> palette.cpp(59, 2): Constexpr evaluation hit maximum step limit; possible infinite loop?
21:33:03 <peter1138> I guess that's a no then :(
21:33:10 <peter1138> Or somehow optimize it more.
21:33:29 <peter1138> Split into multiple smaller tables...
21:37:04 <Rubidium> recommended constexpr limit is about 1 million full-expressions
21:39:15 <peter1138> This is a complex lookup :)
21:40:21 <peter1138> Autogenerate a file containing every value... :D
21:49:26 <locosage> that's what I usually do xD
21:53:12 <peter1138> With the default execution limit it's not even completing the first colour component :)
21:54:36 <peter1138> It's filled in 2348 values. Somewhat less than 262144.
21:56:51 <peter1138> 3 bits works. But that's pretty bad.
22:02:24 <peter1138> That's interesting.
22:04:46 <peter1138> I put a TICC();TOCC(); in the constructor and... the output is displayed. While linking.
22:04:58 <peter1138> (That's no longer constexpr)
22:13:52 <peter1138> -fconstexpr-steps=100000000 Let's see :p
22:20:34 <peter1138> Hehe, still ran out :)
22:20:50 <xarick> OpenTTD doesn't like big tilelists...
22:21:53 <peter1138> 21:04 <@Rubidium> peter1138: have you considered a constexpr/eval table?
22:22:08 <andythenorth> xarick: you cached the entire map in Squirrel? ๐
22:22:15 <andythenorth> that's unwise, I tried it already
22:22:38 <xarick> can't squirrel quit faster? I am trying 'newgame 1' and I'm waiting for the whole memory to unload
22:23:16 <xarick> I assume it's squirrel and tile lists...
22:23:22 <xarick> didn't exactly confirm
22:23:51 <xarick> 4.6 GB in use, still unloading
22:24:33 <xarick> it was a 4096x4096 map
22:25:08 <xarick> I had at least 3 similar sized lists accross the 3 different tile searchers
22:25:29 <xarick> for verification of results, but yeah... unloading these takes a ton of time
22:27:27 <andythenorth> hmm cargo payment rates eh
22:27:38 <andythenorth> chart is highly useful ๐
22:27:47 <andythenorth> not that I ever look at the payment rates
22:29:33 <peter1138> Hmm, now I need to ctrl-z all these changes.
22:31:41 <wensimehrp> xarick: Better than 7-zip at least. Last time I used it it took up ~57gb of my ram
22:41:45 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:52:03 <peter1138> Hmm, wonder how slow it is with release bit.
23:17:00 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:24:30 *** Hanicef has quit IRC (Quit: leaving)
23:41:26 <talltyler> Zoom level setting is confusing. Bigger number == more zoom?
23:43:34 <peter1138> In OpenTTD code, "Normal zoom" ZOOM_LVL_NORMAL is the largest.
23:43:48 <peter1138> And the rest at ZOOM_LVL_OUT_2X 4X 8X etc.
23:44:44 <peter1138> But! In settings text it's generally referred to as 4x zoom in, 2x zoom in, 1x, 2x zoom out, 4x zoom out...
23:51:39 <talltyler> I meant the setting value (possibly an enum?). Itโs hard to review the code for correctness, but I trust you to either get it right first try or fix it later if not. ๐
23:56:49 <peter1138> Setting value is a ZoomLevel.
23:57:04 <peter1138> That saves getting it wrong :)
23:58:56 <peter1138> 23:58: So much for early night.
continue to next day โต