IRC logs for #openttd on OFTC at 2025-03-15
⏴ go to previous day
00:41:29 *** WormnestAndroid has quit IRC (Remote host closed the connection)
00:41:33 *** WormnestAndroid has joined #openttd
00:50:46 <ajmiles> Are there any rules about the resolutions of different zoom levels for sprites? I see most usually get 2x small with each zoom, but do they have to?
00:52:47 <ajmiles> I'd not been able to use actual mipmaps for zoom levels because they don't follow the usual rules in how the resolution goes down. A normal GPU texture wouldn't go from 3x7 to 2x4, it'd go to 1x3
00:54:33 <reldred> I'm still getting my ass kicked with building, I've scrapped and re-setup vcpkg, done fresh clones of all my repos, etc.
00:56:31 <ajmiles> ajmiles: A normal GPU mip map chain just shifts width/height by 1 with every mip, so 12x29 goes to 6x14, not 6x15. But if OpenTTD "mips" always round down by doing ceil(width / 2) I think I can handle that
00:56:56 <_glx_> reldred: oh you're using solution mode
00:57:24 <ajmiles> reldred: What does that mean exactly?
00:57:55 <reldred> _glx_: Yeah I don't really know what I'm doing with VS Code, but it's where I've done most of my recent patch development (last 12mo or so)
00:58:03 <reldred> I did earlier use just straight Visual Studio
00:58:32 <reldred> ajmiles: Start at 1x sprite sizes, multiply by 2, multiply by 4
00:58:55 <reldred> additional zoom levels are just that, additional
00:59:25 <ajmiles> But 3x7 and 2x4 are two zoom levels here that are obviously not multiples of each other
01:00:10 <reldred> Ah, I wonder whether JGR has caught up with that trunk commit yet
01:01:04 <_jgr_> You could just locally cherry-pick it
01:01:14 <reldred> alright, I'll make sure I can compile openttd master before I get too carried away
01:01:56 <reldred> _jgr_: I'm less inclined to do that as it will likely result in me making a mess someone else has to clean when I send a PR to you.
01:08:37 <reldred> Nice, finally got my first exit code 0
01:08:43 <reldred> it's uhhh, been a journey
01:10:31 <reldred> _jgr_: do you have a rough guestimate on when you'll get patches up to date with openttd again? I know there's probably a few chunky changes upstream, the house picker probably doesn't help things.
01:11:07 <_jgr_> It'll probably be some point this year
01:11:17 <_jgr_> The house picker is not really an issue
01:11:41 <_jgr_> I may well pick that ahead of the other stuff anyway
01:12:23 <reldred> Awesome. What's the process you'd normally follow for that? I'd be fine with submitting a PR for it if you don't have the time.
01:13:02 <reldred> my stupid lizard brain would probably just do it by hand
01:17:12 <_jgr_> Don't worry about it, I will take care of it
01:17:38 <reldred> I'll go get some breakfast and get out of everyones hair 🙂
01:17:57 <_jgr_> I've been busy doing some other changes before I resume merging upstream things
01:18:32 <reldred> No that's fine, I'm in no hurry, I've just got a brain worm regarding these fences I want to explore.
02:05:27 *** Wormnest has joined #openttd
02:06:20 <ajmiles> ajmiles: I put some code in to check, and every sprite I've seen loaded has followed the same pattern of nextWidth = ceil(prevWidth/2.0f);. So until proven otherwise I'll assume this is true for all sprites.
02:07:59 <ajmiles> I've figured out a way to use proper GPU mips even though their dimensions don't match how TTD does it in terms of dimensions. I'll only have to create 1 texture per sprite now instead of 1 per sprite per zoom level. Looks like it'll probably save half the memory currently expended on sprites
02:43:28 *** Wormnest has quit IRC (Quit: Leaving)
03:10:41 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:33:57 *** geizeskrank has quit IRC (Ping timeout: 480 seconds)
03:37:31 *** geizeskrank has joined #openttd
07:01:39 <_zephyris> ajmiles: It's not a rule or requirement when defining grfs, sprite sizes for each zoom level are set completely independently. But I think on load OTTD does a padding process to enforce it.
07:17:31 *** Speedy` has quit IRC (Read error: Connection reset by peer)
07:18:51 *** Speedy` has joined #openttd
07:23:16 <peter1138[d]> You can save a bunch of memory by not prescalibg the 1x sprites to 4x., given the GPU can do the 4x scaling itself 'for free'
07:24:28 <peter1138[d]> Would need a bit of reorganising as the loading-encoding flow is almost separate.
07:57:09 <peter1138[d]> No, that's 30 miles in.
08:08:06 <andythenorth> I had to have some
08:43:20 *** HerzogDeXtEr has joined #openttd
08:46:54 *** kuka_lie has joined #openttd
08:52:50 <truebrain> What is annoying about the Steam issue, releasing is now more annoying 😛
08:53:22 <truebrain> owh, tonight it was a different error .. `CPack Error: Error generating temporary disk image.`
09:37:11 <xarick> train progress, almost there...
10:20:34 <xarick> wow, there's more windows 10 users than windows 11 according to some youtube video about operating systems
10:34:27 <emperorjake> I'm on win 10 with no plans to upgrade
10:36:37 <reldred> Yeah win11 was sitting at around 45% last I reard
10:41:29 <reldred> iirc the split was like 40-45% win11, 50ish% win10 and the remainder win8/7/etc.
10:43:06 <reldred> in the enterprise sector win11 will go up in numbers this year but I reckon there'll still be a good 20/30ish percent come october when win10 support ends
10:46:42 <Rubidium> .. and what is the date of the youtube video?
10:49:14 <LordAro> such numbers are always influenced by whoever's doing the sampling
10:50:09 <reldred> Yeah the numbers I remember seeing were the usual IT industry rags, RMM vendors, yadda yadda
10:51:22 <reldred> we've only got a few dozen left of about 5000ish machines across the country but yeah, that's sampling business customers in australia
10:51:34 *** fairyflossy has joined #openttd
10:51:34 <fairyflossy> I'm on Win11 but not by choice
10:51:55 <xarick> there is some kind of bug in the minimap. "Show cargo flow on map" is displaying parts of "Show transport routes on map"
10:52:39 <xarick> "Toggle display of height map" seems to fix it if pressed down
10:54:28 <LordAro> reldred: you've done well!
10:55:11 <reldred> heh, in our region I think we only have like one or two
10:55:13 <xarick> actually, I don't know what's the expected behaviour
10:55:18 <reldred> the rest are in the eastern states
10:55:28 <xarick> but something seems inconsistent in the UI
10:55:43 <reldred> couple PC's in customer networks just running veeam
10:56:27 <LordAro> we've still got ~20 to do, out of about ~80 total :D
10:57:31 <reldred> yeah, one's a VM running a bespoke app with no win11 support 'officially', and it's running on ESXi without vsphere so getting virtualized TPM running isn't really an option.
11:00:22 <LordAro> it's just a bit of a pain because half the stuff we're having to replace is 7th-gen stuff - so it works fine but no official support
11:00:49 <reldred> yeah it's not my problem directly, but my colleague's dealing with it, doing another trial of getting the software running on server '22
11:28:32 *** Flygon has quit IRC (Read error: Connection reset by peer)
12:24:37 <xarick> why is estimate multiplier in pathfinders such a boon, and a curse at the same time?
12:32:52 <kuhnovic> Because you trade in optimality for ease of computation. Can't eat your cake and have it.
13:15:49 <peter1138[d]> Silly thing, spamming rides.
13:17:21 <xarick> should I investigate AAAHogEx building routines?
13:17:52 <xarick> it can put a train out in 3 days
13:19:02 <xarick> from looking how and where to placing station, picking town, calculating profit estimates...
13:19:21 <xarick> and then building the connection
13:20:41 <xarick> and its routes aren't even that bad
13:21:02 <xarick> not many weird turnarounds and such
14:49:39 *** Wormnest has joined #openttd
15:25:47 <ajmiles> _zephyris: Do you happen to know where that code lives?
15:26:11 <_zephyris> No, sorry... I think PeterN pointed me at it before
15:27:24 <ajmiles> I'll leave the check in for now and maybe I'll come across the padding code at the same point I find the 4x scaling code that Peter mentions
15:33:15 <ajmiles> Pretty sure I've found the 4x scaling code though in 'ResizeSprites'. It seems to load a sprite whose "first_avail" zoom is LVL_OUT_4X and it's creating a 'normal' zoom level
15:34:14 <ajmiles> "PadSprites" in spritecache.cpp is where I am now, getting warmer
15:34:56 <_zephyris> That sounds hot, not warm!
15:40:58 <ajmiles> ResizeSprites does assert that any provided zoom levels are the correct dimensions relative to the 'NORMAL' level, so I'm safe in my assumption
15:42:51 <ajmiles> And I saw it pad one too from 9x9 to 10x10 because the one above was 20x20. So, all good
16:10:20 *** Wolf01 is now known as Guest11415
16:15:46 *** Guest11415 has quit IRC (Ping timeout: 480 seconds)
17:09:05 <xarick> i just got 13 "needs rebases"
17:41:52 <ahyangyi> I have a question: what is the color 0 in the DOS/Windows palette?
17:41:52 <ahyangyi> I know, usually 0 denotes a transparent pixel. However, I noticed that if I also supply an alpha channel, the index 0 is drawn black (instead of either blue or transparent). Where is the source code for the default palettes? I cannot find it...
17:52:22 <_zephyris> Not sure what the rest of your question means... If you have an 8bit image with an incorrect palette, ie. with an alpha channel, then nml and grfcodec should throw errors
17:57:06 <talltyler> Silly idea, curious what kuhnovic (or others who know pathfinder stuff) thinks:
17:57:06 <talltyler> If a vehicle has no orders, it wanders about randomly. What if, if the player's viewport is following the a road vehicle or ship, it tries to drive toward the player's cursor instead of choosing a path randomly? That would let the player explore the world on a vehicle which can't crash or cause deadlocks, playing off the "press H to honk" feature. 🙂
17:59:07 <_zephyris> Fun idea. Spacebar heating risk though, a few strategies use vehicles with no orders, and that will give unexpected behaviour if a vehicle window is left open.
17:59:14 <_jgr_> talltyler: You'd definitely have to disable that in multiplayer
17:59:28 <talltyler> _zephyris: Only if you're following it with the viewport, though
17:59:39 <_zephyris> Oh, I see what you mean.
18:00:47 <talltyler> What's the multiplayer risk? It's not that different than controlling vehicles with orders.
18:00:59 <talltyler> Besides "which player has control?", I suppose
18:03:47 <_jgr_> "Drive towards the player's cursor" sort of implies propagating a player's cursor position to all the other machines in the game
18:05:04 <talltyler> Ah, good point. My initial thought was hotkeys but the axes of road vehicles don’t correspond to any usual arrow keys, not to mention most good hotkeys are used already.
18:14:02 <kuhnovic> I've had a similar idea at some point. My idea was to right-click somewhere and the vehicle would try to go there. Age of Empires style.
18:15:11 <kuhnovic> In the end it's just a matter of instructing the Pathfinder to find a path to a certain destination. The hard is usually to integrate it into the other vehicle logic without breaking anything 😛
18:16:02 <xarick> have you fixed the bouy?
18:18:42 <frosch123> talltyler: did you try andy's game script?
18:20:34 <xarick> or just remove buoys from the game
18:20:55 <xarick> no more positioning required
18:26:27 <kuhnovic> No I did not fix that, what makes you think that?
18:28:50 <ajmiles> I've just synced my D3D12 GPU fork with master for the first time in about 12 (?) months, and a piece of code I'd written that looks at the 'type' of each Sprite has broken. It looks like 'type' is now only initialised for the NORMAL level and left uninitialised (0xCC) for the other levels. Does that smell like a bug or just the new way of doing things?
18:30:54 <ajmiles> I don't think I can rule out it being my fault, but this only appeared when I synced my fork
18:37:13 <_zephyris> Not sure of the details, but I think it was changed so that a 8bpp sprite was no longer required, which might have included changes to how the different zoom levels are initialised
18:37:15 <talltyler> frosch123: No, but road vehicles look more fun to drive than airships 🙂
18:37:50 <ahyangyi> _zephyris: There are many things that were rejected by nml and grfcodecs that later turned out to be OK, such as "not providing 8bpp graphics"
18:37:50 <peter1138> Type is only set and used on the first sprite, it cannot be different for other zoom levels.
18:38:25 <peter1138> (Or rather, it's not taken from other zoom levels, because it cannot be different depending on zoom level.
18:38:43 <ahyangyi> Oh, somehow you are already talking about this.
18:39:18 <ajmiles> peter1138: So I should just start looking at spriteColl[0].type only, and never other zoom levels?
18:39:42 <ahyangyi> Anyways, I'm messing with grf-py and 8bpp+alpha seems to produce valid grf files.
18:39:50 <_zephyris> ahyangyi: Separate problem, just happens to be similar
18:39:56 <peter1138> Yes, well, ZOOM_LVL_MIN rather than 0.
18:39:57 <ahyangyi> I might need to double check if grf-py is secretly converting things for me.
18:40:04 <_zephyris> Sounds like a grf-py bug TBH, or silent conversin
18:40:36 <peter1138> I don't think there's been any concious change here though.
18:40:50 <ahyangyi> I trust neither grf-py nor the existing documentation (which still insists the "must have 8bpp graphics" rule 😛 ), hence asking here
18:41:08 <peter1138> You need 8bpp for TTDPatch... :)
18:41:17 <ajmiles> Given that there's memory allocated for the type, it seems odd to not have it initialised. And I think I saw other places in the code referring to the 'type' of other zoom levels
18:41:56 <wensimehrp> ahyangyi: Do you mean by 32bpp image that only has alpha + 8bpo mask or 8bpp image + 8bpp image that only has alpha?
18:42:28 <wensimehrp> Iirc isn't the latter impossible?
18:42:55 <ahyangyi> wensimehrp: That's the question, technically I only provided the 8bpp image and alpha, and judging by the documentation it's impossible. But the documentation does not even say what the enum values are for `8bpp` and `32bpp` modes
18:43:10 <ahyangyi> And it might be actually a bitmask allowing other combinations
18:43:17 <ahyangyi> Just hidden behind the nfo interface
18:43:44 <ahyangyi> point is, the documentation is both outdated, and does not actually contain enough information for me to manipulate the bits 😛
18:44:11 <ahyangyi> So I have to read the source code, and got confused because I can't even find the palette
18:44:49 <_zephyris> Did you see the NML link I posted?
18:44:55 <peter1138> ajmiles, it's not exactly allocated "for the type", it's just part of the Sprite struct which is reused for the other data.
18:44:55 <_zephyris> AFAIK there's no such thing as "8bpp+alpha", but there is "8bpp with palette entries which are rgba"
18:45:29 <ajmiles> I guess my point was just that "it's there", and no memory is being saved by not initialising it to the correct value
18:45:29 <ahyangyi> The same NML says color 0 is blue, which already contradicts with my observations.
18:45:30 <peter1138> There's no RGBA palette maps.
18:45:51 <peter1138> Colour 0 is blue in the palette files.
18:46:16 <ahyangyi> Interesting. I think that points to a secret conversion in grf-py then.
18:46:20 <ahyangyi> I'll look at it first.
18:46:27 <peter1138> If m is zero, then it will use the RGBA component.
18:46:36 <peter1138> If you don't set the RGB component, then it will be black.
18:46:55 <peter1138> Oops, m is a bit internal to OpenTTD :)
18:47:02 <peter1138> If the indexed colour entry is 0...
18:49:11 <peter1138> ajmiles, nothing uses type of other zoom levels.
18:49:36 <ahyangyi> anyways, perhaps I should ask first: what are the actual byte values for `8bpp`, `32bpp` and `mask` modes?
18:49:39 <peter1138> You cannot have sprite that is a font at 4x, and a normal sprite at 1x.
18:50:42 <peter1138> RGB is 1, Alpha is 2, and Palette is 4. It's a bitmask.
18:50:55 <peter1138> 8bpp and mask are the same thing.
18:51:15 <ahyangyi> Yeah, I think I produced sprites with `0x6`
18:51:34 <ahyangyi> something not possible with nfo, but works
18:52:44 <ahyangyi> Hopefully this clarifies my question?
18:53:36 <peter1138> 17:41 < ahyangyi> I have a question: what is the color 0 in the DOS/Windows palette?
18:53:41 <peter1138> Do you mean that question>
18:53:55 <peter1138> There is no colour 0.
18:54:50 <ahyangyi> OK, "is the alpha-blending behavior with non-zero alpha and m=0, simply darkening the pixel"?
18:55:21 <peter1138> It8:46 < peter1138> If m is zero, then it will use the RGBA component.
18:55:21 <peter1138> 18:46 < peter1138> If you don't set the RGB component, then it will be black.
18:56:07 <ahyangyi> There is no colour 0, but in my particular use-case, it is *equivalent* to alpha-blending an RGB value of (0, 0, 0)
18:56:24 <ahyangyi> which is otherwise imposible to get (since none of the other 255 colours are pure black)
18:56:31 <ahyangyi> Thanks and I'm good 😛
18:56:47 <peter1138> You've made a 32bpp grf without setting the RGB component.
18:57:15 <peter1138> If using an 8bpp blitter, alpha and rgb is ignored, so an m=0 pixel will not be set.
18:57:17 <ahyangyi> It's a 32bpp grf anyways, I'm just trying to compress certain child sprites
18:57:45 <peter1138> You should probably just define it per the spec. to avoid undefined behaviour.
18:58:18 <ahyangyi> OK, so -- can we make the behavior part of the spec?
18:58:18 <peter1138> Don't try to implement a custom compression algorithm based on quirks.
18:58:39 <ahyangyi> or define any behavior you want, just make 8bpp+alpha possible.
18:59:08 <ajmiles> Looks like my code is getting caught you by the fact that ZOOM_LVL_NORMAL is no longer 0. A change from last April
18:59:19 <ahyangyi> also, is just the colour 0 undefined, or the very practice of using Palette+Alpha undefined?
19:00:38 <_zephyris> ahyangyi: It's definitely not typical
19:00:42 <peter1138> Correct, use ZOOM_LVL_MIN instead.
19:00:43 <_zephyris> Just palettes with rgba
19:02:39 <ahyangyi> The use case is a "night mask", which does two things:
19:02:39 <ahyangyi> 1. darken everything by about 75%
19:02:39 <ahyangyi> 2. override certain pixels with yellow or orange
19:02:39 <ahyangyi> So it happens to be a task where I really only need colours in the palette (plus black), and I definitely need an alpha channel.
19:04:26 <peter1138> I recommend absolutely NOT trying to bodge a night mode by doing such things.
19:04:51 <peter1138> Add another channel to the sprite system instead.
19:05:01 <ahyangyi> I mean, you can also modify the game to explicitly reject such sprites.
19:05:10 <wensimehrp> Imo easiest way to implement night without breaking anything is to add a night layer in the spritlayout
19:05:25 <ahyangyi> The current state of it actually works (and works well) but undocumented is the worst
19:05:37 <ahyangyi> wensimehrp: That's what I already do
19:06:01 <wensimehrp> And you're trying a new method, which is undefined?
19:06:02 <ahyangyi> Just the night layer is semiparent black and opaque yellow, not a darkened image of the base
19:06:38 <ahyangyi> I got things to work with the grf-py API, but I feel I am actually using undocumented features.
19:07:19 <ahyangyi> So the question is either to make the current behavior official, or guard against it (and I question why)
19:07:53 <peter1138> Mainly "stop people trying implement features in a stupid way"
19:08:12 <peter1138> Alas, "you use the tools you're given".
19:09:30 <ahyangyi> You didn't even try to stop
19:10:36 <ahyangyi> And 8bpp+alpha has a clearly defined interface, and is already working.
19:10:45 <ahyangyi> All you need to do is to make it official.
19:11:18 <ajmiles> OK, 12+ months of code merged and I'm rendering correctly again with only relatively minor changes to the blitter class and the ZOOM_LVL changes. Thanks!
19:12:13 <ahyangyi> Really, your only argument so far against that is "I don't like it / I think it's stupid", which is very unconvincing...
19:12:30 <ahyangyi> Especially the interface is already a bitmask
19:12:59 <ahyangyi> what's the point of designing a bitmask with 3 bits, then declare there are only 3 legal combinations? 😛
19:13:38 <_jgr_> GRF is just not well designed, arguments about design don't really hold much water
19:13:52 *** Wormnest has quit IRC (Quit: Leaving)
19:13:57 <ahyangyi> Sure, but I also explained why that feature is useful to me
19:14:14 <ahyangyi> and that it is *already supported* anyways
19:22:27 <_zephyris> Fwiw, night mode by darkening everything except lights isnt great graphics deaign or usability.
19:23:05 <_zephyris> A useful night mode is a colour grading to shift shadows blue, highlights less saturated, and adding light glow... The aim shouldn't be making it darker.
19:23:17 <ahyangyi> Sort of, if you make NightGFX2 I would try to produce a night mode to work along it.
19:23:32 <ahyangyi> But for now, the goal is working with NightGFX, because that's all we have 😛
19:24:40 <_zephyris> That's kinda the point though - I wouldn't plan to make a night mode because the way to do that is better done by colour grading.
19:25:13 <_zephyris> But, a light emission mask for sprites might make sense.
19:25:33 <peter1138> 19:04 < peter1138> Add another channel to the sprite system instead.
19:26:34 <_zephyris> Add a normal channel, an emission channel, an albedo channel and a metalicity channel.
19:26:36 <peter1138> Not sure if you need to start dealing with normals...
19:26:40 <_zephyris> Go full physically based rendering.
19:26:51 <_zephyris> Bring on dynamic lighting!
19:27:11 <ahyangyi> anyhow, I think there is *some* interest with NightGFX-style darkening, also FYI bohaska
19:27:21 <michi_cc> Global illumination and screen space ambiant occlusion you say? 🙂
19:27:33 <peter1138> NightGFX is just an unusable joke.
19:28:05 <pickpacket> ahyangyi: I'd bet there is, yeah
19:28:07 <peter1138> Just add a shader, that'll do it.
19:28:44 <wensimehrp> Normal maps for sprites
19:28:46 <peter1138> Anyway, I mean... I would support adding features necessary to do it properly, like whatever extra channels are neded.
19:28:47 <pickpacket> peter1138: I tried nightgfx and... Uhh... Virtually couldn't see anything
19:28:56 <peter1138> Probably PBR is a bit a much :)
19:29:17 <peter1138> But I don't think doing a hack based on undefined behaviour is worth it.
19:29:30 <ahyangyi> That's why I ask about the possibility to make it defined.
19:29:49 <ahyangyi> Officialise the current behavior.
19:30:04 <peter1138> It should the defined, but NOT what you are currently doing, because that has no use for it.
19:30:53 <ahyangyi> That has use for emulating the NightGFX style
19:31:10 <ahyangyi> whether you like or dislike that style is besides the point
19:40:43 *** gelignite has joined #openttd
19:40:46 <ahyangyi> _zephyris: This might also be a useful use case BTW. I'm not doing that yet, but I will probably eventually consider adding light emission masks for features such as light ppsts.
19:41:03 <ahyangyi> Which can also make use of the palette + alpha combination.
19:41:25 <ahyangyi> (not ideal, I know, we actually need other blending modes)
19:42:29 <_zephyris> I'm still not sure what you mean by palette+alpha
19:43:54 <ahyangyi> _zephyris: A childsprite with the m and a channel, and without the r/g/b channels.
19:44:04 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
19:44:20 <_zephyris> As in a ottd-internal thing?
19:45:04 <ahyangyi> peter1138: ^ using this interface
19:45:20 *** WormnestAndroid has joined #openttd
19:49:51 <ahyangyi> So for example I want to make a darkening mask, I can:
19:49:51 <ahyangyi> a) provide r/g/b channels where all pixels are black, and an alpha channel to represent the semitransparency
19:49:51 <ahyangyi> b) provide a one-channel indexed image where all pixels are black, and an alpha channel to represent the semitransparency
19:49:51 <ahyangyi> Currently both a) and b) work, but a) uses 2x space of b), and b) is not an officially supported mode.
19:49:51 <ahyangyi> So, I want to make b) official.
19:52:24 <_zephyris> My fundamental issue is that a _darkening_ mask isn't the way to go. Maybe you call it a style thing, but I think it's objectively not a good solution.
19:52:56 <peter1138> But this isn't a "darkening mask"
19:53:06 <_zephyris> There's a big difference between dark and night...
19:53:13 <peter1138> This is "overlaying another sprite which darkens what's under it".
19:53:23 <peter1138> This is fundementally a bad way to implement something like a night mode.
19:54:03 <peter1138> Hence I say add another channel. I do not say add another sprite layer.
19:54:38 <peter1138> Sprite layers also mean it's up to the NewGRF to enable/disable the layers itself.
19:54:39 <ahyangyi> To be honest I don't understand your argument at this point. It is an overlay because it's not always on.
19:56:18 <ahyangyi> The game itself does nothing about day/night at this point, so **naturally** it is always up to the NewGRF to control it. Is it any surprise?
19:56:45 <peter1138> Naturally designing a solution that doesn't involve the game doing it is fucking dumb.
19:57:21 <ahyangyi> My question does not exclude any future game features.
19:57:48 <peter1138> Your question was "what colour is palette index 0" and I gave you the answer to that ages ago.
19:58:15 <ahyangyi> No, the new question is "can we make the palette+alpha combination official"
19:58:21 <ahyangyi> It has nothing to do with index 0
19:58:36 <ahyangyi> Actually I said you can decide whatever you want wrt index 0
20:02:28 <ahyangyi> _zephyris: When I add this kind of feature, I always ensure they are turned off by default, so those are future proof already -- at worst it would turn to an odd useless feature, not a hindrance.
20:04:23 <peter1138> Neither the NML or NFO part of the spec actually define the internals. They define how NML and grfcodec do things.
20:05:23 <ahyangyi> Hence I am asking about the spec of NewGRF itself, not NML or NFO.
20:05:36 <peter1138> You cannot do 8bpp and palette with NML or NFO.
20:05:38 <_zephyris> Help me out - if you're talking about features for a specific newgrf, why not just use recolour sprites if the night parameter is selected?
20:06:12 <wensimehrp> _zephyris: Because it is 32bpp,
20:06:45 <wensimehrp> Or do you mean recolouring a 8bpp sprite using the transparent palette?
20:07:17 <_zephyris> You can define any remap you want for the transparent recolour mode, so design your own night effect.
20:12:07 <ahyangyi> How does that work for 32bpp images, since the glass effect is just another recolour sprite?
20:12:55 <peter1138> Which glass effect?
20:13:06 <ahyangyi> That `0x322` recolour sprite
20:14:00 <frosch123> A few selected recolour sprites are implemented algorithmic in the 32bpp blitters
20:14:03 <ahyangyi> I haven't looked at the source but I would assume the built-in `0x322` recolour sprite gets special-cased wrt 32bpp images, and any custom recolour sprite would not be able to replicate its effect.
20:14:04 <peter1138> The built in PALETTE_TO_TRANSPARENT is special-cased.
20:14:08 <ahyangyi> Seems I guessed right.
20:14:17 <peter1138> But 8bpp remaps are supported by converting 32bpp to 8bpp and remapping that.
20:14:49 <peter1138> e.g. the green glass in MB's NewStations.
20:15:26 <ahyangyi> Hence, useful if I have a different effect in mind, but will produce inferior results if all I currently want is to replicate the NightGFX effect (which *is* simple darkening)
20:19:43 <peter1138> Well, whatever, it's unlikely the default values for the RGB component will ever be non-zero.
20:20:21 <peter1138> But it won't work with an 8bpp blitter, because they ignore alpha.
20:21:21 <ahyangyi> Is "using a 32-bpp NewGRF with an 8bpp blitter" possible in the first place?
20:22:17 <ahyangyi> peter1138: Can I take this as meaning "using index 0 with palette+alpha is UB, but using the other 255 indices is defined"? 😛
20:25:08 <peter1138> Everything is undefined.
20:25:21 <peter1138> Just use the Canadian building set.
20:26:06 <peter1138> Feature: Support converting 32bpp-only sprites to indexed 8bpp.
20:26:21 <peter1138> I would say that yes, using a 32-bpp NewGRF with an 8-bpp blitter is possible.
20:27:14 <peter1138> (Not that many people are using an 8-bpp only blitter)
20:35:32 <ahyangyi> Alright, I guess I will go with that...
21:01:46 *** ChanServ sets mode: +v tokai
21:08:52 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
21:08:58 *** WormnestAndroid has quit IRC (Remote host closed the connection)
21:09:00 *** WormnestAndroid has joined #openttd
21:47:36 *** WormnestAndroid has quit IRC (Remote host closed the connection)
21:47:39 *** WormnestAndroid has joined #openttd
21:57:42 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:18:38 <xarick> I have a request: Don't scan for newgrfs on startup if I have not set any newgrf
22:19:19 <xarick> or start the scan only when clicking NewGRF
22:22:39 <_glx_> there's a flag for that
22:26:17 <xarick> ehh... it should be the default behaviour, honestly
22:29:31 <xarick> hmm, actually, it doesn't quite do what I expected
23:00:49 <xarick> help me someone! `if (openttd started with -Q) RequestNewGRFScan(this);`
23:01:08 <xarick> this is the NewGRFWindow
23:01:34 <xarick> how do I check the -Q option was used?
23:12:20 <xarick> well it can't get any better than this... gonna wait 1 more day
23:12:33 <xarick> get them all over 4950
23:15:33 *** WormnestAndroid has quit IRC (Remote host closed the connection)
23:15:38 *** WormnestAndroid has joined #openttd
23:20:19 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:23:22 *** kuka_lie has quit IRC (Remote host closed the connection)
continue to next day ⏵
