IRC logs for #openttd on OFTC at 2023-11-24
⏴ go to previous day
00:06:20 <talltyler> andythenorth: Hours late, but I still think “select parent variant and Ctrl+click the buy button” is an easy way to buy a random variant. At the risk of adding more hidden features that are only documented in a tooltip.
00:06:39 <peter1138> So... using GetSpriteSize/DrawSprite does not work for the bus sprite. becuase it's a viewport sprite.
00:06:44 <talltyler> Ctrl+click the buy button is currently available 🙂
00:07:17 <peter1138> Using GetScaledSpriteSize/DrawSpriteIgnorePadding does work, but means the cargo icons aren't aligned the same way as in the station view.
00:07:49 <peter1138> Sprite offsets are the bane of a nice scalable GUI :/
00:09:50 <peter1138> (Main thing is the piles of bulk cargo are meant to be in the lower portion, but end up floating in the middle...)
00:17:50 <peter1138> Weird, in Toyland, the bridges which are differentiated only by colour are... all the same colour.
00:32:46 *** Gadg8eer[m] has joined #openttd
00:34:26 <_pruple> the bus sprite in the player window is redundant anyway, get rid of it
00:35:04 <_pruple> it's not 2cc, and it doesn't tell you anything the colour of the title bar or president background doesn't.
00:36:42 <peter1138> Not the player window, the drop down list in the company colour/livery windw.
00:37:24 <_pruple> get rid of that too, just have a cc square? 🙂
00:37:55 <_pruple> that's what you end up with in the list anyway
00:38:01 <_zephyris> peter1138: Not in OpenGFX2 😜
00:42:04 <peter1138> The current code does it for the bus list item by... harding pixel sizes.
00:43:14 <_pruple> the bridges aren't the same colour in opengfx2, no quotes on IRC 🙂
00:44:09 <_pruple> get rid of the bus sprites all round. they make no sense anyway
00:44:28 <_pruple> "setting 2cc for aircraft? here's a 1cc bus to show you the colour"
00:45:41 <_pruple> those are certainly some colourful bridges
00:46:43 <_zephyris> I like the cc colour swatches
00:47:09 <peter1138[d]> Then OpenGFX/OpenGFX2 one is not brilliant though. Sorry!
00:49:43 *** calbasi[m]1 has joined #openttd
00:50:00 <peter1138> Not using the bus is sacrilege.
00:51:23 <johnfranklin> why is original TTD bus
00:52:30 *** _aD has quit IRC (Quit: leaving)
00:56:05 <_zephyris> The current design is a bit weird. You use a dropdown with buses to select a colour swatch...
00:56:53 *** audunm[m] has joined #openttd
01:03:49 <peter1138> Yeah, tempted to use thec olour swatch -- the small square rather than the company colour icon.
01:03:54 <peter1138> Then it's at least consistent.
01:04:37 <peter1138> Pick a random sprite on load :D
01:05:54 <peter1138> Is that square original or something we added?
01:06:06 <_pruple> something we added I think
01:06:12 <_pruple> can't think of anywhere original it's used
01:06:14 <peter1138> Yes, I could answer that myself.
01:06:22 <peter1138> SPR_SQUARE = SPR_OPENTTD_BASE + 38
01:06:31 <peter1138> 38 means it's quite... old.
01:06:40 <peter1138> I remember it was used in the original NewGRF window.
01:12:32 <peter1138> So for a long time it just listed the colour by name :)
02:08:22 *** blikjeham[m] has joined #openttd
02:33:48 *** ChanServ sets mode: +v tokai
02:40:30 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
02:52:02 *** Wormnest has quit IRC (Quit: Leaving)
03:15:49 *** citronbleuv[m] has joined #openttd
03:20:20 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:34:46 *** JohnFranklin_ has joined #openttd
03:35:09 *** JohnFranklin_ has left #openttd
03:55:28 *** John_Franklin has joined #openttd
03:56:33 *** John_Franklin has quit IRC ()
04:12:52 *** bryjen has quit IRC (Quit: Leaving)
04:13:17 *** nolep[m] has joined #openttd
04:32:50 *** rudolfs[m] has joined #openttd
05:24:46 *** vista_narvas[m] has joined #openttd
05:35:33 *** thelonelyellipsis[m] has joined #openttd
05:37:14 *** Heiki[m] has joined #openttd
06:18:57 *** igor[m] has joined #openttd
06:19:06 *** einar[m] has joined #openttd
06:19:43 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:50:23 *** tokai|noir has joined #openttd
06:50:23 *** ChanServ sets mode: +v tokai|noir
06:56:50 *** tokai has quit IRC (Ping timeout: 480 seconds)
07:05:59 *** Bilb[m] has joined #openttd
07:22:02 *** tonyfinn has joined #openttd
07:30:45 *** georgevb has joined #openttd
07:30:45 <georgevb> peter1138: May be instead of calling it "a bad feature" (I do not think it is bad), you can improve OpenTTD to support it better - allow selecting them, but not allowing building them. This would allow to press hide / unhide button (for groups should cause hiding all unhidden vehicles / unhiding all hidden for the whole hierarchy depth)
07:43:45 <truebrain> lol @ 11488 .. that sounds so passive agressive 😛
07:45:25 <_pruple> also doesn't actually identify what the issue is 😉
07:45:36 <truebrain> `768 MB (8.05*10^6 bytes)` I do have issues with the math
07:45:45 <truebrain> but that is me being childish 😄
07:46:19 <_pruple> "the sprite cache is too big!" - too big for what?
07:47:27 <_pruple> "Should _sprite_cache_size ever be > 512" - well, good job the default setting is smaller than that, then.
07:49:40 <truebrain> okay, so `_sprite_cache_size` used to be in MB, but is not in 4MB, because 8bpp->32bpp
07:49:54 <truebrain> so the initial size is `128 * 4 * 1024 * 1024`
07:50:00 <truebrain> which is just 512MB
07:50:09 <_pruple> yes, I checked, it's been in pixels since 11 years ago. 🙂
07:50:18 <truebrain> that also isn't in pixels
07:50:22 <truebrain> it is in 1/8th of a pixel
07:50:37 <truebrain> `_sprite_cache_size * bpp / 8 * 1024 * 1024`
07:50:37 <_pruple> units-of-pixels, then
07:51:15 <truebrain> the comment is true with a 8bpp blitter!
07:51:28 <truebrain> but why would it "overflow" with > 512? That is lost on me ...
07:51:56 <truebrain> pretty sure that is 2GB
07:52:00 <truebrain> pretty sure that fits in a 32bit integer
07:52:21 <truebrain> 1024, now that becomes an issue 😛
07:52:40 <_pruple> he still hasn't actually suggested that anything is *wrong*, besides an out-of-date comment in the code.
07:52:57 <truebrain> `Should _sprite_cache_size ever be > 512, the code would overflow target_size`
07:53:08 <truebrain> although STRICTLY true, that value is actually `>= 1024` 😛
07:53:14 <_pruple> the default might be "excessive" for playing without grfs on a regular size map, but people don't.
07:57:53 <_pruple> and sure, but neither 512 nor 1024 is the default setting, the complaint is specifically that the default is "excessive"
08:20:03 <truebrain> _pruple: highest possible value is 512, as it turns out 🙂
08:20:36 <truebrain> so I am pretty sure someone went through the motions already, with what sizes are allowed etc 😛
08:22:30 <locosage> does it really allocate the full sprite cache on startup?
08:22:42 <locosage> it does sound quite excessive but I don't think it's true
08:24:05 <_pruple> I'm running openttd right now with a bunch of 32bpp newgrfs and such and it's using 160mb of memory.
08:25:25 <truebrain> my trusted `gdb` says it does allocate 512MB of RAM for the introgame
08:25:36 <truebrain> the code is a bit weird btw .. it allocates 768MB, releases it, allocates 512MB
08:25:51 <truebrain> but I am sure there are good ideas about that 😛
08:26:37 <truebrain> 1002 _spritecache_ptr = reinterpret_cast<MemBlock *>(new byte[_allocated_sprite_cache_size]);
08:26:37 <truebrain> (gdb) print _allocated_sprite_cache_size
08:44:23 <LordAro> georgevb: fwiw, "bad feature" is usually used in a flippant or sarcastic context, rather than anything serious
08:45:41 <LordAro> truebrain: very well put
08:46:32 <_pruple> no, bad features are serious business, with or without the comma. 🙂
08:47:42 *** xyii[m] has joined #openttd
08:53:05 <peter1138> Anyway, all that cursed 4x extra zooming just in case you want to be able to see things on a modern screen.
09:05:14 <peter1138> Surprised it's not limied by the max zoom setting.
09:05:51 <peter1138> And I don't quite understand the bit that allocates more than requested.
09:06:18 <peter1138> Possibly don't allocate all ram leaving nothing for anything else.
09:06:48 <truebrain> that was my guess; but a comment should have mentioned that 😛
09:19:24 <LordAro> does sound like there's some improvement that could be made in that area, at least
09:19:30 <LordAro> with the whole alloc/realloc stuff
09:20:32 <truebrain> it happens once on loading of a map
09:20:38 <truebrain> I mean .... of all the things we can put effort on
09:20:44 <truebrain> this doesn't sound like anything worth while?
09:20:53 *** gretel[m] has joined #openttd
09:23:46 <peter1138> OpenGL sprite cache when? :D
09:25:17 <peter1138> Creating a sprite atlas on the fly sounds like fun right?
09:25:33 <truebrain> if it does to you, go nuts!
09:26:14 <LordAro> truebrain: i didn't say it would be worthwhile, just that it could be improved :p
09:26:27 <truebrain> yes, thank you for that contribution /s
09:34:56 <_jgr_> Loading every possible zoom level at that same time is a large part of that problem
09:37:10 <_jgr_> A lot of memory gets wasted on zoom levels which are never used
09:39:39 <peter1138> It also makes non-power-of-2 scaling very awkward.
09:52:56 <peter1138> Also, wtf Netherlands?
09:53:04 <truebrain> what did we do this time?
09:58:33 <peter1138> Hmm, if you go with a conservative 2048x2048 atlas, you're not actually going to get much 4x extra zoom on that.
10:04:23 <peter1138> (And some people want 8x :D)
10:10:46 <peter1138> The Japanese glyphs one is interesting.
10:14:56 <peter1138> But which sprites do you pack. I suppose it is possible to figure out which sprites are usable, but not which sprites will be used.
10:23:38 <peter1138> andythenorth, how many sprites in Horse now?
10:33:48 <andythenorth> 102179 according to nmlc
10:34:02 <peter1138> Nice. Deduplicated?
10:35:59 *** yubvin[m] has joined #openttd
10:37:44 *** menelaos[m] has joined #openttd
10:40:19 <andythenorth> Wonder how many of the 5111 trains are ‘randomised’ vehicles
10:40:26 <andythenorth> Probably more than half
10:45:50 <_pruple> horse has 5111 vehicles? D:
10:47:07 <_pruple> sunshine [trains] has 4245 realsprites D:
11:25:15 *** patricia[m]1 has joined #openttd
11:35:05 <locosage> horse 3.2.0: Found 40653(40%) duplicate sprites, 6359918(37%) bytes total
11:35:44 <peter1138> I suppose that's due to reuse of templates rather than reuse of spritesets, or something.
11:36:43 <ahyangyi> locosage: Is that nml or grf-py?
11:42:13 <ahyangyi> We have more excuses to convince Andy we need more variants in Horse 😄
11:44:13 <peter1138> Hmm. In LoadNextSprite we check if the NewGRF is version 2+ and the `grf_type` is 0xFD. But in SpriteLoaderGRF we only check for version 2+
11:45:21 <peter1138> `grf_type` is a sprite property, not a grf property.
11:45:58 <peter1138> Ah, becuase inline sprites aren't allocated in V2+.
11:46:08 <peter1138> So it would be redundant to check again.
11:49:19 *** imlostlmao[m]1 has joined #openttd
11:50:25 <peter1138> Heh, "webdev" as a derogatory term.
11:51:19 *** CornsMcGowan[m] has joined #openttd
11:51:29 <peter1138> Where did I hide the power supply for my synthesizer?
11:52:18 <peter1138> ahyangyi, "webdev mentality"
12:04:21 *** jact[m] has joined #openttd
12:06:10 *** joey[m] has joined #openttd
12:22:56 *** freu[m] has joined #openttd
12:30:53 <peter1138> Hmm, router/switch firmware updates?
12:35:54 *** philip[m]123 has joined #openttd
12:41:02 *** virtualrandomnumber has joined #openttd
12:42:43 *** virtualrandomnumber has quit IRC ()
12:44:44 <andythenorth> I've lost the saved grep command frosch gave me to find duplicate sprites
12:45:09 <andythenorth> nmlc reports 38667 duplicates, but I don't know if that means anything
12:47:22 <andythenorth> last detailed report I have here is from May 2023
12:48:05 <peter1138> Maybe nml needs a separate compiler and linker step :p
12:48:32 <andythenorth> pff, has been discussed before 🙂
12:48:52 <andythenorth> some of us tried doing it by merging nfo and using grfcodec as the linker
12:49:06 <andythenorth> but the string IDs get mangled
12:49:21 <andythenorth> and any 'global' varact 2 also
12:52:42 <andythenorth> oh maybe the Horse duplicates are mostly related to random reverse
12:53:04 <peter1138> That should just be colour maps...?
12:53:15 <andythenorth> many engines will show default sprites <- or -> direction, depending on random bit when built
12:53:30 <andythenorth> the actual realsprites sets are different sequence
12:53:34 <peter1138> Oh, reverse direction.
12:53:39 <andythenorth> but the sprites will be detected as dupes
12:53:40 <peter1138> Not reverse random colours :D
12:53:45 <andythenorth> yeah, no those are deleted
12:53:52 <andythenorth> this Variants thing, heard of it? 🙂
12:54:05 <peter1138> Sounds like a bad feature.
12:54:38 <andythenorth> I haven't read the nfo, but the nml suggests that's the cause of most of the dupes
12:54:51 <andythenorth> it's hard to tell because it's wrapped up in spriteset template magic
12:55:00 <peter1138> Imagine if random-reverse was nothing but an engine property that told OpenTTD to randomly set the flipped bit on build...?
12:55:19 <peter1138> (Imagine setting it on non-rail vehicles)
12:55:40 <locosage> grf-py highlights duplicated sprites if that can help
12:56:04 <locosage> also it should be possible to figure out what switches use them if needed
12:56:05 <peter1138> Imagine if random-colours was nothing but a list of primary and secondary colours that OpenTTD could applyt.
12:56:43 <peter1138> Yeah, you can't reuse spritesets for that.
12:56:52 <andythenorth> I _think_ there's some advanced action 1 format though?
12:56:58 <andythenorth> that can resequence the same sprites?
12:57:05 <andythenorth> I tried to understand it, but I think only MB does
12:57:43 <locosage> I don't know of any way to deduplicate sprites with same image but different offsets
12:57:48 <locosage> same offsets can be though
12:58:16 <peter1138> That is not different offsets, just different order :)
12:58:35 <peter1138> And no, you can't do that either.
12:58:57 <peter1138> Maybe your duplicate detector can check if they are in the same order to help reporting dupes.
12:59:48 <andythenorth> imagine if the grf spec just did all this stuff
12:59:57 <andythenorth> but then authors ignored it 😛
13:00:00 <locosage> different order can be deduplicated
13:00:41 <peter1138> Hmm, is that some spriteset magic?
13:01:38 <locosage> pseudo sprite section only has sprite ids and you can use same id multiple times
13:02:50 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
13:04:13 <peter1138> SpriteSet 0 = { 229875, 229876, 229877, 229878, 229879, 229880, 229881, 229882 }
13:04:26 <peter1138> SpriteSet 1 = { 229879, 229880, 229881, 229882, 229875, 229876, 229877, 229878 }
13:04:57 <locosage> nml doesn't but I do in grf-py
13:05:04 <locosage> can even recompile horse xD
13:05:58 <peter1138> I don't see any support for that in NewSpriteSet()
13:08:37 <locosage> it's in LoadNextSprite, it only reads sprite id and uses index to find data
13:09:47 <locosage> needs container v2 ofc
13:10:11 <peter1138> Okay, so it's "abusing" container v2 by reusing offsets. Interesting.
13:10:18 <andythenorth> so Horse is 40% smaller with grf-py?
13:10:20 <peter1138> That will still duplicate sprites in memory though.
13:10:42 <peter1138> So optimizing and reusing sprites is still better.
13:10:49 <locosage> decompiler misses some features though so it doesn't fully wor
13:10:53 <locosage> but it is smaller xD
13:10:54 <andythenorth> so about 18MB instead of about 30MB
13:13:00 <locosage> it reports 6359918 bytes of duplicates that can be removed
13:16:42 <locosage> locosage: tried that here (that's a reply, irc people :p)
13:22:09 <peter1138> Built-in random reverse?
13:22:26 <andythenorth> needs to be a thing
13:22:35 <andythenorth> Horse 4: Small Horse
13:22:48 <andythenorth> I mean...the nfo is 64MB for Horse
13:22:49 <peter1138> No, I mean, this is a thing.
13:23:04 <andythenorth> only when you merge it 😛
13:23:15 <andythenorth> or is it hidden in the spec?
13:23:56 <peter1138> lllegal multi-head.
13:24:06 <andythenorth> multi-head is always why we can't have nice things 🙂
13:24:20 <peter1138> "Can't reverse direction of vehicle... ... consists of multiple units"
13:24:30 <peter1138> Do we need that restriction?
13:27:40 <andythenorth> only 171 Horse vehicles using random_bits_reversed_engine()
13:27:46 <andythenorth> oh, but variants share varact 2 chain
13:28:27 <peter1138> [ Always forward, 25% reverse, 50% reverse, Always reverse ]
13:28:47 <peter1138> Not sure if Always reverse is useful.
13:29:19 <andythenorth> probability of reverse, 0-255?
13:29:22 *** andythenorth[m] has joined #openttd
13:29:41 <andythenorth> 255 being an ideal way to express %
13:34:34 <peter1138> Eh, I'm missing something, there must be an obvious way to turn take a random number and a value and use it as a probability.
13:50:53 <peter1138> `p + Random(255) >= 255;`
13:51:19 <peter1138> But with my current method of using 2 flags, that means 0, 33, 66 and 100% chance of reversing.
13:53:49 <andythenorth> no middle value 😛
13:54:20 <peter1138> If "always reverse" is not necessary, perhaps.
13:54:36 <andythenorth> at some level, can't the author just redraw the damn sprites in that case 😛
13:54:44 <andythenorth> this is action 0 props, not callback result?
13:54:56 <andythenorth> redraw / reorder the spriteset
13:55:27 <peter1138> This is using 2 bits of ExtraFlags, so doesn't needed adding a property.
13:55:48 <peter1138> Which is naughty but I started with 1 flag for "forward" and "random reverse"
13:56:01 <andythenorth> ok, so there's no need to handle "this train was always built backwards in January 1963 because the factory was still drunk"
13:56:11 <andythenorth> or all that other shit that we come up with as a community
14:00:43 *** magdalena[m] has joined #openttd
14:01:47 <peter1138> _pruple, did you ever do randomised reversed engines? If so what probabilities?
14:03:29 <andythenorth> FWIW Horse is just a single bit
14:04:10 <andythenorth> aren't Variants nice?
14:04:12 <peter1138> Oh yeah, doing it this way also frees up random bits.
14:04:22 <andythenorth> you added plenty of random bits 😛
14:04:33 <andythenorth> are they in a release yet? 😛
14:04:53 <peter1138> Oh I upped it from 8 to 16 bits.
14:05:02 <peter1138> I bet I didn't update the docs.
14:06:27 <peter1138> Okay, so with this we can just undo that ;)
14:07:14 *** gelignite has joined #openttd
14:08:26 <andythenorth> well the smart author will read the random reversed state, then flip the sprites in the graphics to always be forward facing
14:08:49 <andythenorth> then invert the available random bits using the random reversed state bits
14:08:55 <andythenorth> to increase the total random
14:09:08 <andythenorth> two sources of random innit
14:11:09 <peter1138> If you want 67%, 84%, 100% then set up a spriteset in reverse...
14:11:18 <peter1138> How about I delete myself.
14:13:18 <andythenorth> 1 bit worked for me
14:13:45 <andythenorth> I know that if someone is modelling Paddington for August 27th 1963 they'll want an accurate representation of how many tank engines came out of Old Oak Common that day backwards
14:13:50 <andythenorth> but then again...ctrl-click?
14:14:05 <peter1138> Right, this is just for randomness.
14:14:47 <andythenorth> 1 bit is enough IMHO
14:14:56 <andythenorth> there are only 2 directions I think?
14:14:58 <peter1138> Why is this other pi repeatedly sending a DHCPREQUEST.
14:15:10 <andythenorth> it's feeling lonely
14:15:22 <andythenorth> it wants a secure parental relationship
14:25:25 *** nielsm has quit IRC (Ping timeout: 480 seconds)
14:48:03 <_glx_> andythenorth: there's a PR using advanced action 1, but it's very basic
14:50:10 <andythenorth> Scunthorpe to Chippenham via Newmarket? Branch to Kingston?
14:51:13 <peter1138> Your system is drawing zoomed-out sprites and then pixel-doubling them.
14:52:50 <peter1138> It's not retina if it's all pixel-doubled...
14:53:25 <peter1138> Can we handle the scaling ourselves...
14:54:02 <peter1138> Of course, having to to 8x to be equivalent to 4x might be an issue :)
14:55:13 *** rau117 has quit IRC (Quit: User went offline on Discord a while ago)
15:08:13 <truebrain> okay, so yeah, his initial post failed to show the context required to understand what he meant 🙂
15:08:33 <truebrain> 32bit Windows upper memory limit .. that was .. yeah, not clear 😛
15:09:36 *** HerzogDeXtEr has joined #openttd
15:10:00 <peter1138> When we added the sprite pre-scaling system, 2x and 4x zoom in sprites didn't exist.
15:10:42 <peter1138> Why did pre-scaling everything? Was it performance or issues with drawing zoomed out sprites...
15:11:52 <georgevb> andythenorth: Does NML supports 16 random bits?
15:14:20 <LordAro> truebrain: specifies using Win10 64bit in the initial issue
15:15:27 <andythenorth> georgevb: spec page says yes, and links the NML pull request 😉
15:16:49 <peter1138> Previous build when it was SVN. Hmm.
15:17:08 <LordAro> that's been quite a while now
15:17:15 <peter1138> We still had 32bpp and 4x extra zoom back then.
15:17:32 <truebrain> it is also mostly virtual memory
15:17:46 <georgevb> Good news, I had to use random bits of the parts in ARVs to get more random bits. 16 bits would make situation a bit better. A pity, that it is not 32 bits
15:17:49 <truebrain> so it is more an argument about purity, than anything actually going on
15:20:10 <peter1138> It is not 32 bits because variable shifts the random bits by 8, so you'd lose the top 8 bits.
15:20:33 <peter1138> But 16 bits is a lot of combinations.
15:22:33 <peter1138> truebrain, s/[Bug]/[Opinion]/ ?
15:23:08 *** gelignite has quit IRC (Quit: Stay safe!)
15:23:11 <truebrain> I btw am somewhat surprised the `new byte[]` doesn't actually allocate the memory
15:23:20 <truebrain> (well, it does virtually, but not in RSS)
15:23:26 <truebrain> neither on Windows, nor on Linux
15:23:36 <truebrain> only once we write in the block, it is actually allocated
15:23:48 <truebrain> expected we would have to use `mmap` to do that, honestly
15:24:02 <LordAro> quite common with modern allocators, iirc
15:25:10 <peter1138> Probably the switch of default blitter from 8bpp to 32bpp made it noticable.
15:26:10 <peter1138> 1 byte/pixel to 6 bytes/pixel (iirc) is quite a jump.
15:26:30 <truebrain> where does the 6 come from? 😄
15:26:51 <peter1138> Oh, it's 40bpp, not 48 :)
15:39:10 <truebrain> I had to double-check you could actually overcommit the memory, but you can
15:39:25 <truebrain> so they can still run 40 instances of OpenTTD in the same amount of (actual) memory 😛
15:39:37 <truebrain> it was a bit troublesome to validate, as I have 64GB of RAM 😛
15:41:41 <peter1138> I managed to get Gnome Maps to OOM the other day.
15:42:09 <peter1138> Actually I also managed to get OpenTTD to OOM the other day, with that GetStringHeight(..., 0) call :)
15:42:27 <truebrain> I am still surprised, that `new byte[]` is mostly virtual .. that feels so weird 😛
15:42:31 <peter1138> There is an assert there now.
15:42:55 <truebrain> it throws an exception when it tries the actual allocation, it seems (if it doesn't fit)
15:43:03 <peter1138> I think it OOMed hard enough to kill VS Code and X11, which made debugging harder.
15:43:51 <truebrain> anyway, that makes it a rather non-sense ticket ... as the OS handles all the shit nicely for us 😄
15:44:42 <truebrain> curious if I missed something there ...
15:46:09 <peter1138> That's a pretty solid 50%.
15:48:36 <locosage> is that memory used continuously as sprite cache populates? os probably allocates it in pages so if there are gaps it may actually use more than necessary
16:07:09 <_jgr_> The sprite cache implements it's own heap/allocator type of structure on top of the single memory block
16:07:33 <_jgr_> It can get fragmented so probably will use more memory than strictly necessary
16:07:56 <peter1138> It can be fragmented but won't deliberately leave big gaps.
16:08:33 <_jgr_> The allocator/memory management is not great, so replacing it with something simpler which doesn't use a big slab would probably be a net benefit
16:09:47 <peter1138> Yes, it's mostly a left-over from C-style code where your choices are more limited.
16:15:56 <locosage> btw, I'm not sure it's even useful to have a cache
16:16:12 <locosage> I mean sprites obv need to be in memory but having something with max size seems pointless
16:16:35 <locosage> most sprites are used very often in openttd so once that limit is reached game starts to lag terribly
16:17:32 <_jgr_> The slowness when that happens is because the cache eviction algorithm is not very good
16:18:37 <locosage> for any eviction algorithm to work you need to have lots of srites that aren't used often
16:19:08 <peter1138> That works... when you're not zoomed out.
16:19:44 <_jgr_> In the zoomed out case, not caching the zoomed in sprites makes the problem go away
16:21:25 <locosage> it doesn't take that much of a zooming for cache limit to become a problem
16:21:35 <locosage> as it's not good when game lags when scrolling either
16:22:34 <locosage> also having a viewport on everything doesn't help either
16:24:59 <_jgr_> For what it's worth, I've got sprite caching on a per-zoom level basis, and a different sprite cache allocation model and eviction algorithm in my branch it seems to work fine
16:25:16 <_jgr_> Scrolling is a separate issue of the most part
16:27:17 <peter1138> This is also a problem with the idea of generating a texture atlas... we have no idea what is going to be used in advance.
16:27:41 <locosage> I can see cache being useful if there is something like epoch change when lots of stuff just change appearance permanently
16:27:59 <locosage> but that is probably best solved by unloading long unused sprites than some kind of size limit
16:29:20 <LordAro> _jgr_: patches appreciated ;)
16:29:32 <locosage> imo in a typical game it's safe to assume that pretty much all sprites will be used
16:29:57 <peter1138> LordAro, we don't do that. Hints to the fact they exist is nice though ;)
16:30:35 <locosage> well, climate aside that is
16:31:55 <peter1138> Hmm, 177 active connections. Such a home network.
16:32:23 <_jgr_> I'll look into turning it into a PR
16:32:40 <_jgr_> locosage: The whole conversation earlier about jumbo GRFs suggest otherwise
16:35:59 <locosage> as I see it the most (by size) sprites are for "empty map" stuff: landscape, towns, industries
16:36:09 <locosage> and those don't change like ever
16:36:23 <locosage> ofs some grfs can do weird stuff but in the most games that won't happen
16:37:04 <peter1138> Don't forget the giant cat objects.
16:37:24 <locosage> well, those are pretty static too
16:37:33 <_jgr_> I mean things like 5000+ trains in Iron Horse, all with their own sprites
16:37:49 <_jgr_> There's no point pre-loading in all those sprites as the vast majority will never be nedded
16:39:19 <locosage> I'm not talking about pre-loading here, I'm talking not unloading them
16:39:25 <locosage> or at least not unloading by size limit
16:39:56 <locosage> once some train is used it's sprites are likely to be needed quite often
16:42:33 <peter1138> Ooh, and 260 IPv6 connections.
16:42:38 <peter1138> More IPv6 than IPv4.
16:44:28 <locosage> As I see it better approach would be to unload all but ui sprites on every game load/start. Then load sprites as they're needed and only unload if they aren't used for a long time.
16:44:56 <locosage> I guess obvious landscape sprites can be preloaded/not unloaded on game start
16:49:12 <peter1138> All sprites are unloaded on game start.
17:06:31 *** Wormnest has joined #openttd
17:36:42 <pickpacket> andythenorth: is there room for more cargo types and industries in FIRS?
17:40:28 <peter1138> Iron Horse can probably shrink a bit with that.
17:43:32 <andythenorth> peter1138: or is it 49%?
17:44:59 <andythenorth> pickpacket: depends on the FIRS economy
17:46:12 <peter1138> The probability is 0-3 / 6ths
17:46:51 <andythenorth> hmm, is that democracy though?
17:47:00 <andythenorth> what's the will of the people re: random reverse?
17:47:13 <peter1138> Yes, I voted for it, and nobody else dissented.
17:57:38 <peter1138> Why can I not find this power supply? :(
17:58:19 <peter1138> Hmm, a random intel microcode update.
18:07:23 <locosage> 0-3 sounds like 4/6 :p
18:09:18 <peter1138> locosage, only if you add two rounds together.
18:09:41 <peter1138> But then why stop at two? 0-3 sounds like 666/6.
18:11:26 <locosage> I read it as 0, 1, 2, 3 vs 4, 5
18:12:01 <peter1138> Well you read it wrong.
18:37:04 <_zephyris> So... Crazy Friday idea. Can we use the unused palette entries for a few extra palette animations?
18:37:15 <_zephyris> Well, I know I _can_, I've already got code working. The real question is _should_ we?
18:42:33 *** Tirili has quit IRC (Quit: Leaving)
19:41:00 <andythenorth> _zephyris: I have counted them a few times to this end 😛
19:41:31 <andythenorth> Where is truebrain’s bug report about water slopes? 😛
19:45:36 <andythenorth> We don’t have enough water shades
19:45:49 <locosage> may be useful deep water
19:46:26 <_zephyris> Yeah we do, just use a 32bpp image with an 8bpp mask
19:46:58 <_zephyris> Shades aren't the problem, it's different animation cycles.
19:47:34 <locosage> shades aren't problem in 32bpp
19:49:51 <_zephyris> ... But I would suggest adding another darker water cycle. A 4 step one with a slow cycle time
19:50:40 <_zephyris> Plus a dark red cycle perfect for fire in combo with the existing orange. And flashing green and yellow, like the level crossing lights.
19:55:09 <andythenorth> _zephyris: Does that work in openttd.grf?
19:57:03 <andythenorth> ^ includes comments from me on water cycle, with mockups
19:57:48 <locosage> it doesn't work with 8bpp blitter
19:57:55 <locosage> which should probably be abandoned anyway
19:58:27 <frosch123> but it only needs 16MB
20:10:24 <peter1138> My 386 only had 1MB RAM, so it didn't.
20:11:13 <frosch123> did it have a turbo button though?
20:14:27 <pickpacket> andythenorth: I’m wondering if I can add my tea newgrf to it 😄 I can’t possibly play without tea 😉
20:14:47 <peter1138> It did. 8MHz or 16Mhz.
20:15:17 <andythenorth> Wonder how much ram my first computer had
20:16:23 <andythenorth> Only out by 1000
20:21:23 <Wolf01> <andythenorth> 32MB <- mine had 4MB :O
20:27:18 <andythenorth> We had an Acorn, but it wasn’t “mine” 😛
20:34:34 <peter1138> You weren't meant to steal them from school.
20:45:43 <andythenorth> my parents were teachers 😛
20:45:50 <andythenorth> weekends, the computers came home 😛
20:48:58 *** esselfe has quit IRC (Remote host closed the connection)
20:50:40 <andythenorth> we did buy an archimedes, but my mum had pre-emption rights on it
20:51:07 <andythenorth> then my brother got a pentium from whatever that high street chain was that went bust
20:55:12 *** fairyflossy has quit IRC (Quit: User went offline on Discord a while ago)
20:56:31 <andythenorth> might have been gateway, can't remember
20:58:04 <andythenorth> that had TTO or TTD on it
20:58:23 <andythenorth> I only remember temperate so maybe TTO, and the signals were crap
21:09:37 <andythenorth> such river slopes
21:12:12 <andythenorth> did we port JGR's multiple-cargo ships to vanilla yet?
21:26:07 <andythenorth> hmm cargodist eh
21:26:21 <andythenorth> kinda doesn't work does it?
21:27:03 <andythenorth> trains going A to B just aren't loading cargo at station A, even though target next hop is B
21:27:28 <andythenorth> does cdist distinguish between shared order groups when choosing to load cargo?
21:27:34 <andythenorth> e.g. does it see them as separate edges?
21:29:44 <andythenorth> this train just left Ivy Bridge and is the next edge to Red Lumb
21:29:50 <andythenorth> it's left mostly empty
21:30:28 <andythenorth> this train is heading directly to Red Lumb, and has also failed to load pax
21:31:20 <LordAro> _zephyris: there's a PR somewhere for "deep water", so another water cycle might be ideal
21:31:39 <LordAro> oh, locosage said that :D
21:31:46 <andythenorth> two water cycles 😛
21:32:17 <andythenorth> this train now left empty from Ivy Bridge
21:32:22 <andythenorth> cdist is just broken isn't it
21:32:29 <_pruple> andythenorth: soda and tap
21:32:52 <_pruple> andythenorth: skill issue, clearly
21:33:06 <andythenorth> skill in reporting reproducible bugs? 😛
21:33:13 <talltyler> andythenorth: Use OpenGFX2, it’s very obvious (and looks quite similar to original TTD) 🙂
21:33:37 <andythenorth> is cdist broken because I am using grfs not available on bananas?
21:34:30 <andythenorth> talltyler: can it be ported to openttd.grf?
21:34:35 <andythenorth> (the slope approach)
21:35:01 <talltyler> Ask _zephyris I guess?
21:41:08 <andythenorth> ok so is there a guide to making cdist work anywhere?
21:41:21 <andythenorth> do I have to create routes in a specific way or something?
21:42:46 <andythenorth> mail train is going to Chippenham, has not loaded cargo
21:48:54 <andythenorth> lol it's just broken
21:49:03 <andythenorth> ok well that savegame is dead 😛
21:52:12 <andythenorth> I wonder if players actually look at what cdist does
21:52:23 <andythenorth> or if they just assume the broken behaviour is as intended
21:53:41 <_jgr_> It works fine on my machine 😛
21:53:49 <andythenorth> that's what everyone else tells me 🙂
21:54:23 <andythenorth> are my settings inappropriate?
21:55:42 <_jgr_> It seems OK? I'd have the effect of distance on demand higher, but it's not going to matter much on a small map
21:58:30 <talltyler> “Any station” behavior is a bit odd sometimes. If cargo has chosen a destination, it always seems to behave as expected — at least for me 🙂
22:09:36 <LordAro> peter1138: while you're in the area, add the missing two characters to PopupMainToolbMenu ?
22:18:06 <peter1138> Hmm, I better sign up for tomorrow's ride in case I wake up lazy...
22:20:52 <peter1138> Rises to feeling like 1°C by midday.
22:21:01 <peter1138> Maybe I shouldn't've signed up.
22:21:38 <andythenorth> broken cdist save
22:21:43 <andythenorth> I'll find the grfs
22:26:36 <peter1138> Loading that game spends a LOT of time in AddGRFString.
22:26:55 <andythenorth> is that why cdist is broken? 😛
22:27:04 <andythenorth> I am waiting to see what the amusing user error will be
22:27:10 <andythenorth> some button I have forgotten to press
22:27:34 <_pruple> the fix cargodist button?
22:28:18 <peter1138> I only loaded it to have access to your super secret unreleased NewGRFs.
22:30:34 <andythenorth> non-bananas grfs
22:31:38 <andythenorth> are they the best kind?
22:40:29 <_zephyris> andythenorth: Yup, should work seamlessly.
22:40:39 <_zephyris> Presumably I can do a PR
22:41:32 <_zephyris> LordAro: Mmm, I think I'll try that then. Water is such a prominent use of animated palette it's probably worth the dedicated indices
22:57:35 <peter1138> I guess I should build a non-debug build.
23:00:43 <_jgr_> Your save is full of implicit orders
23:01:03 <_jgr_> You need to get rid of all of them and make sure that all order are non-stop
23:05:18 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:06:11 <andythenorth> then how will intermediate stations be served?
23:06:26 <_jgr_> By adding them to the order list of course
23:06:38 <andythenorth> they're implicit 🙂
23:06:50 <andythenorth> implicit orders were added explicitly to support cdist no?
23:07:03 <_jgr_> No wonder cdist never works in your save games
23:07:40 <andythenorth> what is the purpose of implicit orders except to add nodes to the linkgraph?
23:08:09 <_jgr_> Implicit orders are needed to load old saves
23:08:21 <_jgr_> If it were up to me I'd get rid of them, they're just a nuisance
23:08:57 <andythenorth> well it's a long time since they were added and I'm too lazy to dig out the release notes
23:09:04 <Eddi|zuHause> hm... when viewing a html file in github, is there a way to actually render it instead of seeing the raw text?
23:09:10 <andythenorth> at the time I formed an impression they were a cdist feature
23:12:27 <_jgr_> They pre-date cdist significantly
23:13:05 *** michi_cc[d] has joined #openttd
23:13:05 <michi_cc[d]> cdist should use them, but as I'd guess a lot more people play with non-stop orders, it might have gotten broken somewhere along the line.
23:13:37 <andythenorth> so I need to add explicit orders for every node I want in cdist?
23:14:28 <peter1138> michi_cc[d], I'm assuming this is one those "everyone knows it doesn't work" things, without realising that maybe it is meant to work...
23:14:51 <andythenorth> I'm probably just playing it wrong 🙂
23:14:56 <andythenorth> I predicted it would be user error
23:15:41 <peter1138> How do I time execution...
23:18:36 <peter1138> No, too many scope issues.
23:20:32 <_zephyris> Uch, why so many water slope variants? It's going to take me ages to code!
23:23:04 <andythenorth> I had to draw so many for openttd.grf
23:25:30 <_zephyris> That's my default state!
23:25:57 <_zephyris> Mostly for getting me hooked again on TTD in the early '00s
23:27:33 <_zephyris> It's been a very long time since I nfo coded...
23:28:05 <andythenorth> ok so cdist needs all orders to be non-stop?
23:29:41 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:30:49 <peter1138> In theory it shouldn't, but it seems it may be broken, and that is considered normal.
23:31:02 <andythenorth> I've replaced all implicit orders with explicit, but trains are still leaving without being full
23:31:15 <andythenorth> train capacity 168 / 1000 pax at the station waiting
23:31:19 <_glx_> it takes time to clean up
23:31:28 <andythenorth> real time, or ffwd time?
23:31:38 <_glx_> and cdist doesn't imply lull load
23:31:55 <_glx_> usually you don't want full load orders
23:31:59 <_jgr_> Because you originally had the direct links to the termini in the train orders, those were added to the link graph
23:32:09 <andythenorth> now it's re-adding the implicit orders
23:32:13 <andythenorth> so it does need full load?
23:32:23 <andythenorth> oops non-stop, not full load
23:32:47 <peter1138> full load is always needed to stop accidental implicit orders.
23:32:48 <_jgr_> There is a setting to make non-stop the default for new orders
23:33:24 <_glx_> I see what you did here 🙂
23:33:47 <andythenorth> ok so I changed this
23:33:57 <andythenorth> I've been playing wrong since 2008
23:34:55 <andythenorth> non-stop will prevent servicing though?
23:36:08 <_glx_> once train has reserved a track, it won't find a near by depot
23:36:19 <andythenorth> wonder how long it takes to fix the linkgraph
23:36:37 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:36:54 <_glx_> "service at" orders are a better solution
23:37:08 <andythenorth> these 1033 pax are just not loading
23:37:29 <andythenorth> is there some button now to clear cargo from a station?
23:37:47 <andythenorth> eh, so when players frequently report cdist overwhelms stations, is it just this?
23:37:54 <andythenorth> they're playing wrong?
23:37:55 <_glx_> they should vanish after some time
23:39:29 <_glx_> /me should remember to set FFWD limit next time I launch the game
23:39:49 <andythenorth> well it's 4 game years so far
23:39:54 <_zephyris> Err, is there an (easy) way to make just the orig_extra grf?
23:40:17 <_glx_> it's a target in build system
23:40:45 <_glx_> but you need grfcodec, and tell cmake where it is
23:41:10 <andythenorth> /me got bored of waiting
23:41:22 <andythenorth> turn cdist off I think
23:41:34 <talltyler> _jgr_: I have half a patch to hide them behind a setting for Workflow.png
23:41:44 <talltyler> And old saves, I guess
23:42:01 <andythenorth> why don't vehicles only stop at stations they have orders for?
23:42:06 <andythenorth> this non-stop thing is a footgun
23:42:49 <_glx_> they skip intermediate when going non-stop to a station
23:43:02 <andythenorth> ok even with cdist off, these 1033 pax just won't load
23:44:51 <andythenorth> usually I just play freight, and cdist doesn't work for freight, at least with FIRS
23:49:56 <andythenorth> so....point-to-point is best?
continue to next day ⏵
