IRC logs for #openttd on OFTC at 2023-12-18
00:05:55 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
00:09:21 <peter1138> Hmm, I have an idea.
00:21:45 <peter1138[d]>
00:21:46 <peter1138[d]> Almost...
00:23:20 <peter1138> Oh dear, I guess all the glyph widths have been modified in the sfd file.
00:23:47 *** esselfe has quit IRC (Ping timeout: 480 seconds)
00:32:22 <peter1138> Oh this is a shame, the source glyphs really don't match the sfd.
00:32:58 *** Wormnest has joined #openttd
00:37:29 <peter1138> I'm trying to make the svg be the source for the ttf.
00:37:40 <peter1138> Currently they are not, which is kind of awkward for source control.
00:40:22 <peter1138> (And reproduceability)
00:45:23 <peter1138> Hmm, I guess I could ... fix it.
00:56:50 <peter1138[d]>
00:57:01 <peter1138[d]> Seems to be fixable but kerning needs love.
01:07:53 <peter1138> Ah ah
01:09:22 *** esselfe_ has joined #openttd
03:24:12 *** Kitrana2 has quit IRC (Quit: Leaving.)
03:28:15 *** Wormnest has quit IRC (Quit: Leaving)
03:50:37 *** D-HUND has joined #openttd
03:53:54 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:42:02 *** keikoz has joined #openttd
06:05:45 <_zephyris> peter1138: Yup. Standard assumption for scaling the imported glyph is that an svg document is a 1 em square. Weird scaling can happen if it's not, at least via the gui.
06:07:00 <_zephyris> peter1138: A few are missing/misnamed, that's on the fix list. Most missing ones are because the glyphs are built up from linked copies.
06:07:41 <_zephyris> You'd need a formatting rules json or similar.
06:08:37 <_zephyris> Eg. Default right bearing of 100, but overrideable. Positions and source unicode indices for composite glyphs. Kerning groups and tables...
06:11:49 <_zephyris> Or, use the sfd file as the source for those values and re-import the outlines from the svg automatically
06:29:04 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:30:47 *** tokai has joined #openttd
07:30:47 *** ChanServ sets mode: +v tokai
07:31:07 *** m1cr0man has quit IRC (Quit: G'luck)
07:33:29 <andythenorth> peter1138[d]: β€œFlat docks hack”
07:34:09 *** m1cr0man has joined #openttd
07:37:36 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
08:45:16 <andythenorth>
08:45:16 <andythenorth> ok flat multi-docks
08:45:31 <andythenorth> quite labour-intensive to build πŸ˜›
09:01:21 *** D-HUND is now known as debdog
09:15:47 <_zephyris> Looks really good tbh
09:16:50 <peter1138> Hmm, would be nice if OpenTTD could handle the combining marks :)
09:17:18 <peter1138> (Or I suppose the text layout/font system in use.
09:17:19 <peter1138> )
09:17:49 <peter1138> I was trying to work out why I had a conflict, then I realised you'd force-pushed :)
09:25:54 *** Hanicef has joined #openttd
09:33:25 <michi_cc[d]> peter1138: The layouts (except the fallback one) should handle combining characters without problem, but as we don't do any specific string normalizing, it depends on what is in tghe language file.
09:33:44 <peter1138> Yeah, I figured that might be an issue.
09:33:59 <peter1138> Oh, 32bpp-only nml is not yet merged.
09:34:22 <peter1138> truebrain, please sir, can I have more (rights)?
09:34:41 <michi_cc[d]> I'm not sure if any of the layout libs we use automatically compose or decompose as needed based on the font.
09:36:58 <truebrain> peter1138: Done
09:37:04 <peter1138> ty <3
09:38:23 <DorpsGek> [OpenTTD/nml] PeterN merged pull request #314: Change: Allow creating 32bpp-only NewGRFs
09:41:36 <peter1138> Plagued :)
09:42:52 <michi_cc[d]> Okay, composed/decomposed stuff is apparently based on the `GSUB` table in the font file, so the font can have composed or decomposed glyphs and you "just" need the right contents in the table.
09:43:13 <peter1138> Interesting.
09:44:24 <michi_cc[d]> And `cmap` as well of course, as this is the basic codepoint -> glpyh mapping.
09:46:18 <andythenorth> _zephyris: it's slightly odd in practice because the ship descends in the lock before unloading
10:11:20 <peter1138> Huh. Oil rigs in this 32bpp industry NewGRF cut down trees...
10:16:37 <peter1138> This is all coded badly ;(
10:17:52 <peter1138> I think some authors don't realise that drawing everything as overlays over a common ground tile (replacing every pixel) is... inefficient.
10:20:19 <peter1138[d]>
10:20:19 <peter1138[d]> How many industries in this picture?
10:22:20 <peter1138[d]>
10:22:20 <peter1138[d]> That's right, 4.
10:51:49 <peter1138> _zephyris, have you considered removing non-extrazoom sprites from OpenGFX2 Hi Def?
10:53:47 <locosage> why remove?
10:53:52 <peter1138> There's a big difference in hue and brightness between 2x and 4x sprites.
10:54:37 <locosage> can be fixed
10:54:42 <peter1138> (That may be 1x and 4x.)
10:54:49 <locosage> automatic downscale isn't that great either iirc
11:06:35 <_zephyris> Between 2x and 4x? The only 2x-specific sprites are for the GUI elements.
11:07:19 <_zephyris> The issue is nearest neighbour downscale. I do have (most) ground tile/infrastructure sprites as 1x, 2x and 4x, but it's a maintenance nightmare
11:14:19 *** blathijs has quit IRC (Quit: WeeChat 4.0.5)
11:15:24 *** blathijs has joined #openttd
11:15:24 *** ChanServ sets mode: +o blathijs
11:17:38 <peter1138> Yeah, I think it was 1x sprites :)
11:18:00 <peter1138> The 1x sprites are noticably different from the 4x sprites.
11:19:20 *** Flygon has quit IRC (Remote host closed the connection)
11:19:26 <peter1138> Hmm, I wonder what it looks like with just 4x.
11:22:06 <peter1138> Maybe a bit too grainy :/
11:29:15 <peter1138[d]>
11:29:15 <peter1138[d]> 32bpp-to-8bpp crunchiness
11:29:25 <peter1138[d]>
11:29:41 <peter1138> Probably "acceptable"
11:31:20 <peter1138[d]>
11:31:20 <peter1138[d]> actual version in grf
11:32:05 <peter1138> Surprising amount of colour fringing with V's colour depth downsampling.
11:34:04 <rau117> peter1138[d]: Hmm, what about reducing the sprite resolution? This... can be useful to maintain the overall style of the graphics, not like aBase+iron horse or GETS+vanilla
11:34:10 <peter1138> Although there is clearly a bug here, as the NewGRF provides the 8bpp version it should be using that :)
11:34:35 <peter1138> Well, that's a different (but related) proposal, to be honest.
11:34:41 <emperorjake> rau117: JGRPP has a setting for that
11:35:42 <peter1138> Oops, return true should be return false :-)
11:44:03 <rau117>
11:44:03 <rau117> emperorjake: Hmm... either it doesn't work or it doesn't work as expected.
11:44:32 <peter1138> It doesn't work if the grf ONLY contains 2x or 4x sprites.
11:46:29 <peter1138[d]>
11:46:32 <peter1138> I can make it work though.
11:49:29 <peter1138> Inefficient though, as it takes the full zoom sprite (1), downscales it to 2, 4, 8, 16 and 32 zoomed out sprites, and then upscales 4 to 2 and then 2 to 1.
11:52:00 <rau117> But if you take sprites for x1 and simply enlarge them by 2 or 4 times?
11:53:44 <peter1138> If the grf contains "1x" (zoom_lvl_out_4x) sprites that is what happens.
11:54:15 <peter1138> Well kinda. It always creates the zoom_lvl_normal sprite, then downscales to zoom_lvl_out_2x.
12:01:56 <_jgr_> emperorjake: This is a vanilla setting
12:04:23 <xarick> how do I convert the name of a variable into a string ?
12:04:42 <xarick> I have x = 3, I wanna print "x" instead of 3
12:05:04 <Eddi|zuHause> in which language?
12:05:08 <peter1138> print "x" :)
12:05:25 <xarick> squirrel
12:06:28 <Eddi|zuHause> the usual keyword for that is "inflection", but i can't find any support for that in squirrel within 2 minutes...
12:08:07 <xarick> > foreach (tile in [ _tile_N_outer, _tile_W_outer, _tile_S_outer, _tile_E_outer, _tile_N_inner, _tile_W_inner, _tile_S_inner, _tile_E_inner ]) {
12:08:07 <xarick> > PlaceSign(tile, tile.tostring());
12:08:07 <xarick> > }
12:08:07 <xarick> this is printing the value in tile into the sign message 😦
12:10:57 *** keikoz has joined #openttd
12:13:02 <peter1138> "Why is it doing what I told it to do"
12:14:03 <peter1138> KISS: PlaceSign(_tile_N_outer, "_tile_N_outer"); PlaceSign(_tile_W_outer, "_tile_W_outer"); ...
12:14:46 <xarick> okay, I do code repetition then
12:15:30 *** merni has quit IRC (Quit: User went offline on Discord a while ago)
12:15:40 <LordAro> it's pretty rare that variables have any link to what their name is
12:15:59 <peter1138> C# has nameof(), but even here that would just be "tile".
12:17:11 <xarick> oh 😭
12:44:25 <peter1138[d]>
12:44:25 <peter1138[d]> Pikka carefully crafts a 32bpp-only 4x zoom baseset and vehicles... and I carefully downscale to 8bbp 1x zoom...
13:05:11 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11598: Fix 3317e298: Window width/height was doubly-scaled with automatic DPI switch.
13:08:24 <_zephyris> As you're thinking about DPI switching, super niche bug: if you switch UI scale with the newspaper open it can detach from the bottom bar.
13:08:46 <peter1138> I'm not, and I'm aware of that.
13:08:47 <_zephyris> I also got the sans font crunched into a true 10px height...
13:35:18 <DorpsGek> [OpenTTD/nml] glx22 merged pull request #305: Fix a9a1a3e: Don't use station properties 1C/1D for IDs 00-FF
13:35:23 <DorpsGek> [OpenTTD/nml] glx22 closed issue #311: Incorrect error when not providing a `name` property for waypoints.
14:00:42 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11588: Change: Split ScriptDate:: into Calendar and Economy variants
14:04:10 <peter1138> Oh, so with original TTD, the news window doesn't avoid the status bar at all, it just sits over it.
14:06:53 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11588: Change: Split ScriptDate:: into Calendar and Economy variants
14:07:07 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler closed pull request #11588: Change: Split ScriptDate:: into Calendar and Economy variants
14:20:13 *** nielsm has joined #openttd
14:33:57 <xarick> omg, there are already rumours of a 256 core / 512 thread amd cpu
14:34:43 <xarick> LGA-6096... insanity
14:39:02 <LordAro> i think they're already using SP5 with the latest epyc processors
14:39:08 <LordAro> many many pins
14:50:49 <peter1138> Is it 6,096 pins? :D
14:51:03 <peter1138> Just like Socket 4 was 4 pins.
14:52:21 <LordAro> funnily enough, yes
14:55:26 <peter1138> :o
15:34:33 *** Hanicef has quit IRC (Quit: leaving)
15:45:19 <xarick> I'm bad at maths
15:45:47 <xarick> need to calculate a rectangle area - another rectangle area inside the first one
15:46:09 <xarick> get a count of the number of tiles that remain
15:47:49 *** esselfe_ has quit IRC (Remote host closed the connection)
15:49:03 <lamarr> is that not just the larger area minus the smaller one?
15:49:58 <peter1138> Assuming the smaller rectangle is fully inside the larger one, yeah.
15:50:41 <xarick> yes, but in a GetTileX/Y context, I'm getting lost
15:51:38 <LordAro> get a piece of paper, draw a diagram
16:01:15 <xarick>
16:01:16 <xarick> here's some paper, let's see if I can vizualise it
16:01:35 <lamarr> in like pseudocode you'd do something like this, where the two corners are the two diagonally opposing ones
16:01:35 <lamarr> length = | cornerTileOne[X] - cornerTileTwo[X] |
16:01:35 <lamarr> height = | cornerTileOne[Y] - cornerTileTwo[Y] |
16:01:35 <lamarr> area = length * height
16:02:03 <lamarr> repeat likewise for the inner one, and subtract it from the outer one
16:07:41 *** wallabra has quit IRC (Ping timeout: 480 seconds)
16:08:11 *** Wormnest has joined #openttd
16:09:31 <xarick> `_map_size = (GetTileX(_tile_S_outer) - GetTileX(_tile_N_outer) + 1) * (GetTileY(_tile_S_outer) - GetTileY(_tile_N_outer) + 1) - (GetTileX(_tile_S_inner - 1) - GetTileX(_tile_N_inner + 1) + 1) * (GetTileY(_tile_S_inner - 1) - GetTileY(_tile_N_inner + 1) + 1);` I think I'm doing it correctly... why does it fail 😦
16:11:17 <lamarr> make sure you're taking the absolute values of the lengths and heights (| |)
16:11:41 <xarick> ok, let me try abs
16:13:32 <locosage> xarick: you do +-1 to TileIndex, not x/y
16:14:19 <lamarr> would some of those +/- 1 not cancel out as well? the inner ones minus and add one then add one which could just be add one
16:15:39 <lamarr> wait nvm it would shift it over I think
16:17:15 *** Hanicef has joined #openttd
16:19:35 <xarick> ok, I see my mistake
16:19:53 <peter1138> They would cancel out if you only cared about length, but it matters with area.
16:19:54 *** wwww has joined #openttd
16:20:08 *** wwww has quit IRC (Remote host closed the connection)
16:20:43 <peter1138> Who know that calculating the area of a rectangle was so hard :D
16:21:06 <peter1138> Step 1: calculate outer area
16:21:11 <peter1138> Step 2: calculate inner area
16:21:17 <peter1138> Step 3: subtract inner area from outer area.
16:21:32 <peter1138> Or, shove it all onto one line and get it horribly wrong.
16:23:11 <peter1138> LordAro, recovering from being ill stucks, my little 55 + 30 mile weekend was over double the "relative effort" of your 125 mile day... :s
16:23:20 <LordAro> peter1138: :o
16:23:39 <LordAro> if it helps, i spent pretty much all of Sunday on the sofa with a massive headache
16:23:50 <LordAro> didn't drink enough, evidently
16:24:26 <LordAro> but "relative effort" tends to be extremely personal, ime
16:24:47 <LordAro> my highest ever is ~450, but i have friends who regularly get over 1000
16:25:34 <peter1138> My 55 miles was 469. Clearly although I was feeling better I'm not actually recovered.
16:25:42 <peter1138> I had to nap after that.
16:26:45 <peter1138> Mine does generally overstate the effort mind you, but not that much.
16:32:30 *** merni has joined #openttd
16:32:30 <merni> is there a way to make a resizeable window where if you increase the horizontal size, not just the rightmost thing gets expanded?
16:33:01 <peter1138> Yes.
16:33:28 <merni> could you point me to an example of such in openttd?
16:33:54 <peter1138> load game window. (any of the file open/save windows)
16:34:03 <merni> thanks
16:35:22 <merni> ah, NC_EQUALSIZE
16:35:28 <peter1138> Nope.
16:35:39 <peter1138> SetResize()
16:35:59 <merni> Hm
16:36:30 <peter1138> SetResize is what allows them to be resized, NC_EQUALSIZE ensures that resizable widgets will have the same size.
16:36:59 <merni> If I use SetResize on more than one widget without using NC_EQUALSIZE... how does it decide?
16:38:12 *** gelignite has joined #openttd
16:41:00 <peter1138> It resizes both.
16:41:13 <peter1138> / all
17:05:42 <DorpsGek> [OpenTTD/OpenTTD] DonaldDuck313 opened issue #11599: [Bug]: Large town doesn't build houses as dense as usual
17:07:22 <peter1138> That basically a duplicate of some flyspray bug from about 18 years ago...
17:19:58 *** deerecom has joined #openttd
17:19:58 <deerecom> This might be better to ask here... Does openttd log the statistics over longer period than just now/last year? Stuff like the revenue/expenses breakdowns from the yearly finance summary and vehicle profitability.
17:20:15 <DorpsGek> [OpenTTD/OpenTTD] ldpl commented on issue #11599: [Bug]: Large town doesn't build houses as dense as usual
17:22:25 *** frosch123 has quit IRC (Quit: User went offline on Discord a while ago)
17:23:30 <xarick> make central town tile indestructible
17:24:10 <merni> no, that would hurt players' ability to build
17:26:27 <locosage> it's so rare of an issue it's fine as it is imo
17:26:37 <merni> What does `SetFill` do?
17:26:37 <merni> "Set the filling of the widget from initial size. " is not very comprehensible to me
17:26:46 <locosage> though some kind of town center protection would be nice for gameplay reasons
17:29:25 <DorpsGek> [OpenTTD/OpenTTD] DonaldDuck313 commented on issue #11599: [Bug]: Large town doesn't build houses as dense as usual
17:43:15 <merni> Could someone explain to me how the window resizing actually works in the station picker widget ( ? Particularly with newgrf stations.
17:43:15 <merni> What I'm trying to do is to have the station name & station class names in the list truncate and (hopefully) wrap on multiple lines, instead of forcing the window to be as wide as the longest name. I want to be able to resize the window such that both the stationtype list / station name text and the previews on the right get resized.
17:43:15 <merni> The way it is currently set up, you can only resize that window in discrete intervals -- one image's width on the preview. How does that work and how do I change it to allow continuous resizing, with the elements on the left also resizing?
17:49:14 <_glx_> <> <-- that's where the size is actually calculated
17:51:25 <peter1138> You need to make every element on the left hand side resizable.
17:52:16 <merni> ah
17:53:41 <_glx_> I think it's possible to use smallest string length, then get the biggest multiline height for this length
17:54:38 <merni> but where/how is the right side made resizeable?
17:55:39 <merni> _glx_: this would not be ideal though -- do we always want the station type list to be only as wide as the smallest string in it, even if the player resizes the window to allow a lot more space (that would be wasted on widening the right side)
17:55:43 <merni> might be easier to implement though
17:56:54 <peter1138> Are you trying to solve long strings making the left side too wide?
17:57:00 <merni> Yes
17:57:11 <merni> and hence the whole window
17:58:06 <_glx_> the calculation would be for the minimal size, if you later resize the window the string will expand itself
17:58:51 <peter1138> Resize of the NWID_MATRIX (not to be confused by WWT_MATRIX) is set by the NWidgetMatrix code itself, based on the size of the element & padding inside it.
17:59:26 <merni> Ah. That is smart and hidden
17:59:49 <peter1138> And yes, to allow the class list to be narrower, the code that sets the minimal size of the class list widget needs to ignore the width.
18:00:26 <merni> Yeah, I got that bit already, so it displays however much can be fit in the current width plus ...
18:00:38 <merni> just need to make it wrap instead of truncate now
18:00:40 <peter1138> To be honest, that's probably the best.
18:01:00 <merni> hm, really?
18:01:03 <peter1138> Class names were not meant to be a giant long sentence.
18:01:30 <merni> That's true and also true for vehicle names, but this is what newgrf authors do
18:01:36 <merni> is it worth fighting that battle?
18:02:12 <peter1138> Yes. When they're too wide the UI is useless. And making both the left side and the right side of that window resizable is not intuitive.
18:02:36 *** Hanicef has quit IRC (Quit: leaving)
18:03:23 <_glx_> limit width to draw string, and increase height so multiline is possible
18:03:23 <merni> Yeah I agree with you on the first part, hence all this, but why is truncating better then line-wrapping?
18:03:31 <peter1138> Neat trick: show them cropped, and for the selected class, if it's too long scroll it left & right like a ticker :D
18:04:07 <peter1138> WWT_MATRIX only allows each item to be a fixed height.
18:04:09 <merni> lmao, JGRPP does that with departure boards' "Stops at" lists but that is actually realistic
18:04:37 <peter1138> I've got a UI mock up that removes the class list completely anyway.
18:05:02 <merni> peter1138: ouch. is that limitation also why the build vehicle list truncates?
18:05:15 <merni> peter1138: what does it replace the class list with?
18:09:13 *** wallabra has joined #openttd
18:10:30 <_glx_> <> <-- funny on the wiki it shows a dropdown and the matrix
18:11:12 <merni> maybe the matrix was instead of the previews on the right side?
18:11:17 <peter1138> Yes, originally there was no massive preview matrix.
18:17:03 <peter1138> _glx_, literally unplayable.
18:32:06 <peter1138[d]>
18:32:06 <peter1138[d]> AIs be AIs πŸ˜„
18:32:38 <peter1138> Hmm, should I keep the dummy 8bpp sprite detection code...
18:39:17 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master
18:39:18 <DorpsGek> - Update: Translations from eints (by translators)
18:46:59 <xarick>
18:46:59 <xarick> I need geometry lessons 😦
18:51:47 <xarick> I don't even know how to explain. I need to iterate the minimum amount of tiles possible. The tiles I'm interested are those between the two red lines. For the outer red line, I need the search area to begin all the way to the north blue corner. And then for the inner red line, I need the search to iterate from the blue line down to the road tiles. Anything inside the road rectangle is not
18:51:47 <xarick> iterated
18:52:30 <xarick> how do I do this
18:52:58 <xarick> I already do the circular ring search thing, from the blue line to inside
18:53:12 <xarick> but I am unable to determine the formula to get the limits
18:53:37 <xarick> the last ring to search is the one marked with roads
19:02:06 <andythenorth> GSRegions strikes again πŸ™‚
19:03:25 <peter1138> :D
19:03:47 <peter1138> Scoped RegionMode()?
19:05:45 <deerecom> do the corners of those red rectangles touch those circumscribed diamonds right in the middle of their edges (seems they are shifted a bit)
19:20:18 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #11600: Change: Scale sprites to requested highest resolution level.
19:29:42 <peter1138> Not entirely sure our resize stuff is right, everything seems to shift down.
19:33:55 <peter1138> Oh, it's probably because the author isn't aware of how sprite offsets work.
19:36:28 <peter1138> Hmm, Yeti is even worse :(
19:39:18 <peter1138[d]>
19:39:18 <peter1138[d]> That padding...
19:41:21 <andythenorth> peter1138: Multi-threaded though. Start more Squirrel VMs
19:44:08 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened issue #11601: [Bug]: Compilation fails when DEBUG_DUMP_COMMANDS is defined
19:55:36 <peter1138> For 512 cpu cores?
19:57:35 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11574: Codechange: Use town zone constants instead of magic numbers
20:04:11 *** Wolf01 has joined #openttd
20:05:48 <peter1138> Hmm, have I just over-engineered this...
20:08:20 <xarick>
20:08:20 <xarick> how do I test this assert?
20:09:54 <peter1138> Remove or add a row from _town_road_types
20:10:56 <_glx_> it's a compile time check, so breakpoint have no effect
20:10:59 <xarick> ah, nice, it's an immediate error
20:11:19 <xarick> doesn't even build
20:11:28 <_glx_> yes compile time
20:12:58 *** Hanicef has joined #openttd
20:16:54 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #11574: Codechange: Use town zone constants instead of magic numbers
20:23:23 *** gelignite has quit IRC (Quit: Stay safe!)
20:28:50 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler approved pull request #11574: Codechange: Use town zone constants instead of magic numbers
20:49:01 *** virtualrandomnumber has joined #openttd
20:49:18 *** virtualrandomnumber has quit IRC ()
20:50:59 <xarick>
20:50:59 <xarick> the "piece of paper" trick helped a ton, thx. I was able to come up with the coordinates I needed
21:01:05 <_glx_> it always helps when you can visualise what you want
21:03:48 <xarick> oh boy I still didn't get this right... I'm sad
21:09:10 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #11602: Feature: Convert 32bpp-only sprites to 8bpp for 8bpp blitters.
21:12:47 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #11574: Codechange: Use town zone constants instead of magic numbers
21:16:18 <peter1138[d]>
21:16:28 <peter1138[d]> I guess that's a dodgy Industry set...
21:20:55 <xarick> the distance I'm using must be wrong
21:21:04 <xarick> min_d
21:21:51 <xarick> distance is actually 20, but I wanted to get 10 instead 😦
21:22:03 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #11602: Feature: Convert 32bpp-only sprites to 8bpp for 8bpp blitters.
21:23:59 <xarick> I'm just not confident in just slapping a /2 to it, I must be missing something
21:26:13 <talltyler> Heh, find and replace does funny things with comments πŸ˜„
21:26:13 <talltyler> `If you create an instance of this class, the mode will be switched to either Timehronous or Non-Timehronous mode.`
21:31:36 <_glx_> Async with Time ?
21:32:35 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:34:47 <andythenorth> xarick: radius vs. diameter? πŸ˜›
21:36:12 <talltyler> Yep πŸ™‚
21:36:43 <talltyler> I might be subjecting you to Cunningham's Law once I make a PR for this πŸ˜›
21:36:55 <talltyler> I don't have a GS to test it with, either
21:37:28 <talltyler> I believe company mode is a better blueprint to follow than async mode, though
21:38:08 <DorpsGek> [OpenTTD/OpenTTD] github-advanced-security[bot] commented on pull request #11602: Feature: Convert 32bpp-only sprites to 8bpp for 8bpp blitters.
21:50:10 <_glx_> yeah company mode seems better, in case you add more timer types
21:50:54 <_glx_> and in the functions it would just be switches
21:52:43 <_glx_> async, test, and exec follow the same logic (handled in docommand), while company is more local
21:56:31 <peter1138> Ah, windows fail :D
21:59:51 <_glx_> should be an easy fix with explicit template parameter
21:59:57 <peter1138> Hmm, I should detangle the colour brightness stuff too.
22:00:24 <peter1138> Yeah, but that was lazy copy & paste code which should be better deduplicated.
22:01:58 <_glx_> so INT8_MAX is a char
22:02:25 <peter1138> Not for me :-)
22:02:28 <peter1138> # define INT8_MAX (127)
22:02:36 <_glx_> the usual unknown char signedness
22:02:47 <peter1138> Does not confer any type on my system.
22:03:18 <_glx_> well `'_Ty std::min(std::initializer_list<_Elem>,_Pr)': could not deduce template argument for 'std::initializer_list<_Elem>' from 'int'` is the complex calculation
22:03:35 <_glx_> I deduce `'const _Ty &std::min(const _Ty &,const _Ty &) noexcept(<expr>)': could not deduce template argument for 'const _Ty &' from 'char'` is the constant
22:05:08 <_glx_> oh actually it can't find the correct std::min signature
22:06:53 <_glx_> anyway explicit template param should fic
22:06:54 *** Flygon has joined #openttd
22:10:24 <xarick> I found the issue, it was the _map_size yet again
22:11:30 <peter1138> _glx_, basically it's copied from the 32bpp blitters (although they just use 255/256 there)
22:11:38 <_glx_> `#define INT8_MAX 127i8`
22:12:00 <peter1138> But I can't really be calling blitter code here, even if it is a static method.
22:12:31 <peter1138> Also the SSE blitter has its own special SSE version.
22:13:42 <peter1138> So I copied it and tidied it up, but really it should be unified somewhere. But then then... Hmm.
22:20:00 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #11603: Add: AI/GS Time Mode to choose between economy (default) and calendar time
22:22:52 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #11604: Fix: Add missing includes to timers from script implementation files
22:25:40 <_glx_> hmm not sure about the constructors
22:26:08 <_glx_> I think you need to do something like Async
22:26:10 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #11604: Fix: Add missing includes to timers from script implementation files
22:30:26 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11603: Add: AI/GS Time Mode to choose between economy (default) and calendar time
22:32:46 <_glx_> but I need to write a test script
22:34:20 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10543: Feature: Region-based pathfinder for ships (no more buoys!)
22:35:33 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11603: Add: AI/GS Time Mode to choose between economy (default) and calendar time
22:37:01 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:41:44 <andythenorth> such sleeping time
22:45:50 <_glx_> just tested, it's fine like that
22:46:52 <_glx_> now I'm wondering why AsyncMode uses a more complex version
22:50:55 <wensimehrp> peter1138: On a different topic, does irc support markdown?
22:51:09 <_glx_> most likely no
22:51:19 <_glx_> unless the client handles it
22:51:57 <wensimehrp> It looks weird on discord
22:52:20 <_glx_> it was just a `#define`
22:52:27 <wensimehrp> I know
22:53:12 <peter1138[d]> # lol?
22:53:26 <peter1138> That's never going to be abused...
22:54:00 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11603: Add: AI/GS Time Mode to choose between economy (default) and calendar time
22:54:29 <_glx_> #define
22:54:49 <_glx_> discord intercepts it on the app I guess
22:55:05 <wensimehrp> # space?
22:55:56 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11602: Feature: Convert 32bpp-only sprites to 8bpp for 8bpp blitters.
22:56:27 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11602: Feature: Convert 32bpp-only sprites to 8bpp for 8bpp blitters.
22:57:25 *** Hanicef has quit IRC (Quit: leaving)
22:58:14 <peter1138> I undid the tidying because it was totally wrong...
22:58:59 <peter1138> INT8_MAX != UINT8_MAX :)
22:59:22 <peter1138> But I didn't want the rest of the calculation to be affected by the constant's type.
23:12:48 <peter1138> Hmm, probably ought to remove the 0x0E test.
23:14:28 <peter1138> (It makes Sunshine work with 8bpp, but that's perhaps a bit too niche :))
23:15:53 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11603: Add: AI/GS Time Mode to choose between economy (default) and calendar time
23:17:09 <peter1138[d]>
23:17:09 <peter1138[d]> πŸ˜„
23:20:19 <_glx_> like hole in a sprite ?
23:22:08 <peter1138> So the "8BP :|" text is palette index 0x0E. It's a bad hack to make this work, and is better served by the set just not having 8bpp sprites ;)
23:24:36 <DorpsGek> [OpenTTD/OpenTTD] github-advanced-security[bot] commented on pull request #11602: Feature: Convert 32bpp-only sprites to 8bpp for 8bpp blitters.
23:32:27 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11604: Fix: Add missing includes to timers from script implementation files
23:33:50 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11602: Feature: Convert 32bpp-only sprites to 8bpp for 8bpp blitters.
23:37:17 <_zephyris>
23:37:17 <_zephyris> Vehicle icons! Anyone feel like testing if I got the private Unicode range coding right?
23:38:38 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)