IRC logs for #openttd on OFTC at 2023-04-30
⏴ go to previous day
00:56:59 *** gelignite has quit IRC (Quit: Stay safe!)
01:24:59 *** Wormnest has quit IRC (Quit: Leaving)
02:16:41 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:13:13 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
04:13:19 *** WormnestAndroid has joined #openttd
04:32:09 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
06:56:36 <andythenorth> vehicles running through long switch chain on every tick just to choose company colour remap
06:56:40 <andythenorth> or is that cached?
06:57:00 <andythenorth> its cached in some contexts, because it doesn't always update, but that might be a bug 😛
07:02:16 <jfs-> I don't think there is any kind of cache for it no
07:07:26 *** HerzogDeXtEr has joined #openttd
07:21:30 *** phatsak77[m] has joined #openttd
07:21:58 *** phatsak77[m] has left #openttd
08:09:26 <petern> Colour remap is cached.
08:11:07 <petern> There's even a nasty const_cast 🙂
08:20:03 <TrueBrain> are you calling us old? 😛
08:23:29 <petern> Instantly out of date 😄
08:29:03 <petern> I guess a NewGRF to test it would be useful.
08:29:20 <petern> And that needs grfcodec/nmlc updates. Hmm.
08:31:41 <andythenorth> I got a bit stuck trying to update nmlc
08:31:56 <andythenorth> adding more objects to FIRS is trivial, it's one line to make an industry tile also an object
08:32:18 <petern> Tip, vehicles already have extendedbyte action 3s.
08:33:38 <petern> I've got nml open in VS Code, now where to start 😄
08:35:18 <petern> Hmm, does nmlc ALWAYS output an 3-byte sequence regardless of the value being < 0xff?
08:37:21 <petern> Okay, the print_varx method to output extended bytes is weird, the caller needs to decide
08:39:40 <petern> Does nml not write multiple IDs in an action 3?
08:40:18 <petern> file.print_bytex(1 if not self.is_livery_override else 0x81) # a single id
08:42:15 <andythenorth> I can't return negative numbers as results from a procedure yes/no?
08:42:21 <andythenorth> because 15 bit result can't be signed?
08:42:57 <petern> I think it can be signed, just signed with the 14th bit instead of the 15th bit.
08:43:24 <JGR> The limit on the number of varaction2 IDs in flight makes combining action3s together a bit less useful than it would otherwise be
08:43:43 <JGR> You can use variable 1C if you need to get a full 32 bit result from a procedure
08:45:18 <JGR> `last_computed_result` in NML, it seems
08:47:00 <JGR> Or you can store the result in temporary using STORE_TEMP, etc
08:53:40 <petern> Hmm, some action 3 errors show decimal, some show hexadecimal.
08:57:45 <andythenorth> is there some clever way to ensure a python list length is a power of 2?
08:57:57 <andythenorth> this is to generate results for a switch using random bits
08:58:09 <andythenorth> currently I have to measure the length of the list, and extend it
09:08:08 <petern> Doesn't nml cope with that?
09:09:28 <petern> If it's not a power of 2, what would you want python to do?
09:10:02 <andythenorth> nml doesn't cope with it
09:10:24 <andythenorth> python currently extends the list by copying a slice of the existing list and appending
09:10:40 <andythenorth> we don't use random_switch, we build our own
09:10:59 <andythenorth> so I have to provide exact number of possible results
09:18:32 <petern> Alright, were are limits keep in nml.
09:21:20 <petern> `# Maximum allowed id (houses and indtiles in principle allow up to 511, but action3 does not accept extended bytes).`
09:31:21 <petern> Jesus Dalestan, spaces are free
09:31:40 <TrueBrain> but think about the storage!
09:32:17 <TrueBrain> nothing `clang-format` cannot fix
09:32:37 <TrueBrain> or CTRL+P -> Format document
09:33:23 <petern> Is it better though :p
09:33:27 <michi_cc[d]> Ctrl+A and Backspace? 🤣
09:33:47 <TrueBrain> it is how I deal with a lot of projects with shitty coding style .. first fix the coding style 😄
09:33:52 <petern> although color should be defined on a separate line.
09:35:53 <petern> Huh, `#define NUM_PALS ${PALNUM}` becomes...
09:36:14 <TrueBrain> shitty defines being shitty!
09:36:37 <TrueBrain> you can alter the coding style with a `.clang-format` file, but now it might become a bit of a rabbithole 😄
09:36:39 <petern> It's the weird format, VS Code is treating { } as a code block.
09:37:00 <TrueBrain> `${PALNUM}` also doesn't really have a meaning in C++ 😛
09:37:26 <TrueBrain> I am guessing it is another preprocessor that runs over it first?
09:38:43 <andythenorth> should I use cargo subtypes to control the amount of random colour?
09:40:35 *** JobbeDeluxe has joined #openttd
09:40:35 <JobbeDeluxe> Hi a short question. I try top get an Server running in Raspberry Pi 4 32bit. I Take the source and compli with No Problem. But now the Server ist running with Version number "norev0000-uunknown" how can i Change that top Join the Server?
09:40:52 <petern> Pretty sure that would be impossible 🙂
09:43:21 <LordAro> JobbeDeluxe: where did you get the source from?
09:43:42 <TrueBrain> JobbeDeluxe: Make sure to use either our source tarball you can find on https://www.openttd.org or use `git clone`. Otherwise compiling doesn't know which version you actually downloaded the source of
09:47:11 <JobbeDeluxe> okay, i just downloaded the relase version
09:47:25 <JobbeDeluxe> so git clone is the way to go?
09:47:45 <TrueBrain> JobbeDeluxe: that means little to us. That doesn't actually indicate what you downloaded where 😛
09:47:53 <TrueBrain> JobbeDeluxe: I gave you two options; yours to pick 🙂
09:48:06 <JobbeDeluxe> i used that source
09:48:28 <TrueBrain> yeah, that will not work. GitHub does this for us, and is out of our control. But it does not contain any information about the release itself
09:48:35 <TrueBrain> so yeah, pick either of the two options, and you should be good to go
09:49:33 <JobbeDeluxe> I will give a try
09:52:56 <andythenorth> adding lots of random wagons to Horse also causes the nml file to grow 14 MB -> 17MB
09:53:07 <andythenorth> and the grf has grown 2MB
09:53:37 <TrueBrain> michi_cc[d]: I am looking at harfbuzz, but boy .. that is .. euh .. difficult 😄
09:53:50 <TrueBrain> loading in the font alone is .. euh .. yeah 😛
09:54:28 <michi_cc[d]> I guess that why Linux GUI programs seems to like using Pango 🙂
09:54:53 <TrueBrain> Mozilla uses ICU too be, I noticed; not sure what they use for layout
09:55:34 <michi_cc[d]> Mozilla/Chromium probably roll their own, just so they stay consistent on any platform.
09:56:02 <petern> andythenorth: Is it adding duplicate sprites?
09:56:13 <andythenorth> nah, just action 0 / 3 / 2
09:56:24 <michi_cc[d]> And I assume they have enough manpower to do that, too.
09:56:26 <andythenorth> the 'random' is just a choice of company colour remap here
09:56:46 <TrueBrain> michi_cc[d]: gecko at least uses icu .. well, they vendor it, but still
09:57:18 <petern> 'an open source low cost DIY project.' -> £170 DIY kit...
09:57:46 <TrueBrain> and they patch ICU .. lol
09:59:18 <TrueBrain> ah, they also use pango
09:59:48 <TrueBrain> and they seem to have a custom linebreaker
10:00:51 <TrueBrain> they seem to use bidi from ICU
10:01:47 <TrueBrain> their code is as hard to follow as ours 😛
10:06:27 <petern> Hmm, I guess I need to vcpkg boost for grfcodec.
10:06:50 <TrueBrain> that will take a while 😛
10:06:52 <petern> And then remember how to tell CMAKE to use vcpkg.
10:07:38 <petern> Yeah, that's a long list of packages. I don't think I can be bothered.
10:11:40 *** D-HUND is now known as debdog
10:13:36 <TrueBrain> michi_cc[d]: seems Pango would give equal amount of work of getting fonts to work 😛
10:21:50 <michi_cc[d]> Yeah, the font things is annoying, which is why I got rid of Freetype for Win and OSX. It helps todo the fonts like the system is excepting them.
10:22:57 <TrueBrain> there are more rough edged here .. harfbuzz has its own buffer
10:23:08 <TrueBrain> and as you need to use both, it is a bit .. awkward
10:23:19 <TrueBrain> it really helps that OSes offer a single interface for this all 😄
10:25:14 <michi_cc[d]> Uint16 for the chars or for something else? The joys of UTF-16, too?
10:26:14 <TrueBrain> didn't look that far into it
10:26:44 <TrueBrain> but just this handoff between libraries in different encodings .. will be "fun" 😛
10:27:28 <michi_cc[d]> Uniscribe and CoreText are both UTF-16, too. At least you'd have enough reference material for all the needed mapping tables 🙂
10:28:07 <TrueBrain> if only I understood enough to actually have the idea I can do this 😄
10:28:19 <TrueBrain> what-ever I produce, most likely someone will be like: you did what now here? 😛 😛
10:29:02 <TrueBrain> but, from what I gather, it is just a matter of: bidi, shape, linebreak, shape, linebreak, shape, linebreak
10:30:02 <michi_cc[d]> Itemize first. And bidi is basically the last step after linebreaking a run because you can only know the final bidi order iafter you built a line.
10:30:33 <TrueBrain> wouldn't know what to itemize for harfbuzz / ICU?
10:32:06 <michi_cc[d]> At minimum font and style/colour info. And itemize is the uniscribe term, ICU might call it differently, but it basically is the part that separates e.g. a latin part embedded inside an arabic part (so it produces runs with the same layout needs).
10:32:59 <TrueBrain> does it need seperating?
10:33:10 <TrueBrain> and font/color is given to the layouter ofc in FontMapping
10:34:03 <michi_cc[d]> It really depends how the lib works. Like I said, in Uniscribe itemize is a separate step, while CoreText has that included in some higher-level functions.
10:34:28 <TrueBrain> okay, itemize in that definition is basically creating an array of scripts?
10:35:15 <michi_cc[d]> CoreText is "create a layouter for this text", "get next suggested line break", "layout line". As the layouter is an object, it tracks its own internal state. Uniscribe OTOH is a set of procedures, you you get to keep track of any state.
10:35:46 <TrueBrain> CoreText went the extra mile, nice 😄
10:36:16 <michi_cc[d]> CoreText basically gets that fontMap array passed into it and it handles the itemize step fully internally.
10:36:34 <TrueBrain> but just to confirm, itemize in that definition is the creation of an array of scripts?
10:37:07 <michi_cc[d]> It is breaking the text into logical runs that have the same layout rules (script, writing direction, formatting).
10:38:31 <michi_cc[d]> Linebreaking will then try to fit as many logical runs into the line as possible.
10:38:51 <TrueBrain> harfbuzz calls that "segmenting"
10:39:08 <michi_cc[d]> Finally, you apply bidi rules to convert the logical order of the line into a physical order and then shape the characters to get the font glyphs.
10:39:51 <michi_cc[d]> Usually, shaping is done earlier than this though as it is the step that provides the font information needed for knowing how wide the lines is.
10:40:21 <michi_cc[d]> TrueBrain: The name sounds fitting enough for it 🙂
10:41:18 <TrueBrain> you got to love ICU
10:48:27 *** lobstarooo has joined #openttd
11:08:23 <glx[d]> Oh more strings can be removed now with SetTextStyle
11:34:41 <TrueBrain> lot of small things that need addressing too .. like the language, we need to map our language to one harfbuzz understands ..
11:35:51 <TrueBrain> but looking at other implementations based on harfbuzz .. the insanity of it all
11:42:34 <TrueBrain> currently I am mostly wondering if I can make this work 😛
11:43:07 <TrueBrain> Scribus has a rather readable implementation .. still no clue what most does, but okay 😛
11:44:01 <TrueBrain> when shaping text, they first run bidi, then itemize per script, then itemize per style, to shape if with harfbuzz
11:45:52 <TrueBrain> per run they mark what each run is capable of
11:48:06 <TrueBrain> ICU has a ScriptRun, which is not really documented, but seems to itemize per script
11:48:14 <TrueBrain> in a file called scrptrun
11:48:23 <TrueBrain> as that extra `i` was really worth saving diskspace for ..
11:49:21 <michi_cc[d]> DOS compatibility 🙂
11:50:17 <TrueBrain> the issue with ScriptRun only seems to be it is not included in the libraries .. you have to include the source file directly, it suggests
11:50:43 <TrueBrain> this is such a collection of small tools that together MIGHT do what you want 😛
11:52:21 <michi_cc[d]> ICU really is in a strange place today. On the one hand, it (or at least parts) are used basically everywhere (I think it is included in Windows, OSX, Android, Java and so on), and yet docs are often a shit-show and it seems to be full of quirks everywhere.
11:52:44 <TrueBrain> I guess it is just too complicated 😄
11:53:14 <TrueBrain> so another approach would be to use icu-le-hb, and continue to use our current code
11:53:17 <TrueBrain> but vcpkg doesn't have that 😛
12:13:50 <TrueBrain> okay, guess the first step is to make it actually output what the result of shaping is .. eeeuuuhhmm ... so yeah, solving the fonts crap first
12:41:12 <TrueBrain> lol, is `positions` really an x/y in a flat array 😄
12:41:40 <TrueBrain> some places could use some modern C++ touches, I see 🙂 And that is okay 🙂
12:47:41 <petern> Yeah, I was considering looking at positions the other day.
12:51:39 <petern> Oops, it's in there twice.
12:53:31 <TrueBrain> okay ... the `advance` is a bit big ... like, a single character is 600+ in width, it says
12:54:44 <michi_cc[d]> Font units are usually something like 1/1000 of some base unit like e.g. the font size or em width.
12:55:56 <petern> Supporting a sub-pixel GUI would be... interesting.
12:55:58 <TrueBrain> I don't think I even suggested a font-size yet 😄
12:56:57 <TrueBrain> but it is a bit annoying it doesn't seem documented what unit the advance is in
12:59:01 <michi_cc[d]> From where do you get the advances from?
12:59:17 <TrueBrain> from harfbuzz .. but I think I can just ignore it, and use the font for it
13:01:43 <TrueBrain> hmm .. looking at the Windows layouter .. `du` seems always 0 (x-offset)
13:05:14 <TrueBrain> at least it is maintained 😛
13:06:23 <TrueBrain> such library would make a tight link between FreeType and the layouter
13:06:27 <andythenorth> weird, I've also had to install all of these text libs, just to get pillow to build 😛
13:06:27 <TrueBrain> not sure that is actual an issue
13:06:55 <michi_cc[d]> You can't shape text without a font/glyph engine anyway.
13:07:11 <TrueBrain> yeah, but you can't use this library with anything but freetype, is my point 🙂
13:07:37 <glx[d]> andythenorth: can pillow write text in images ?
13:07:54 <michi_cc[d]> `bool _raqm_in_hangul_syllable () -> return false;` 🙂
13:10:02 <michi_cc[d]> TrueBrain: Is there anything besides FreeType for Linux we support?
13:10:06 <TrueBrain> okay, with some cheating at least I can see something on the screen now .. but not always .. funny ..
13:10:53 <michi_cc[d]> But even if that lib isn't used, it might still be a good cheat sheet for some harfbuzz functions.
13:11:44 <TrueBrain> it is so funny if you don't do RTL, what kinda of weird sentences it reads 😛
13:11:50 <TrueBrain> (at least, Google Lens makes the funniest things out of it)
13:16:28 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
13:16:30 *** WormnestAndroid has joined #openttd
13:19:13 <TrueBrain> bit too small for Google Lens to always read it properly
13:19:20 <TrueBrain> but at least harfbuzz seems to do its job
13:19:31 <michi_cc[d]> font size 40 will do the job 🙂
13:21:08 <TrueBrain> rendering seems weird
13:21:21 <TrueBrain> Is what Windows produces
13:21:26 <TrueBrain> looks a lot better 😛
13:21:26 <glx[d]> looks like proper writing
13:21:50 <michi_cc[d]> You either have a very bad font or are not doing the shaping yet.
13:21:53 <TrueBrain> anyway, this is all without bidi, clustering, scripting, etc
13:22:05 <TrueBrain> no, shaping is fine from what I can tell
13:22:25 <TrueBrain> en this is DejaVu Sans
13:22:29 <TrueBrain> no clue if it is any good 😛
13:22:41 <glx[d]> oh baseset description probably doesn't look nice then
13:23:38 <TrueBrain> but I am using tricks .. I manually read the ttf, as I have yet to figure out how to hook harfbuzz to our font reader 😛
13:23:55 <TrueBrain> so there might be some issues based on that
13:25:39 <TrueBrain> now with actually the same font internally as I give harfbuzz 😛
13:26:41 <michi_cc[d]> Shaping seems to not be totally right yet.
13:27:08 <michi_cc[d]> Left bottom button, secnd rightmost char. This is DejaVu Sans as well.
13:27:23 <TrueBrain> I am using DejaVu Sans Bold, as it turns out btw
13:27:31 <TrueBrain> no clue why, but it auto-selects that font 😛
13:27:52 <TrueBrain> how to tell Windows to use the same font ... hmm
13:28:34 <michi_cc[d]> If you have it installed, just putting DejaVu Sans Bold into either the cfg or the font command works for me.
13:29:20 <michi_cc[d]> In-game font console command.
13:29:47 <TrueBrain> one is windows, the other harfbuzz .. which is which? 😄
13:30:01 <TrueBrain> and you were right, shaping wasn't correct yet .. I forgot to set the script 😄
13:32:11 <michi_cc[d]> Looks identical, but then it should as there is an objectively correct way to shape this text.
13:32:24 <TrueBrain> at least means harfbuzz is solid 🙂
13:32:44 <michi_cc[d]> Given the amount if usage, it kinda has to be.
13:33:10 <TrueBrain> just now a ton of things to add to make it proper ... 😄
13:33:23 <TrueBrain> lol, glx[d] is like .. fuck this shit, approve and go-go-go 😛
13:33:46 <glx[d]> well it doesn't seem to add new annotations
13:34:58 <glx[d]> and grfcodec is full of weirdness
13:35:33 <TrueBrain> michi_cc[d]: I need to be able to access the FT_Face of FreeTypeFontCache .. what would be the best way to do so, you think?
13:35:46 <TrueBrain> misuse `GetOSHandle` for that?
13:36:24 <TrueBrain> (as that is what OSX and Win32 use for the same functionality)
13:36:31 <michi_cc[d]> Why would that be a misuse? It literally was intended for "here goes the font-specific library handle".
13:36:41 <TrueBrain> yes, but it isn't .. `OS`
13:36:44 <TrueBrain> that name could use a rename 🙂
13:37:05 <glx[d]> nice OSX fails to build now
13:37:44 <glx[d]> looks like vcpkg changed stuff
13:38:05 <glx[d]> `Cannot open include file: 'boost/foreach.hpp': No such file or directory`
13:40:14 <TrueBrain> lol, loading our font is trivial with this information 😄
13:40:22 <TrueBrain> `auto hbfont = hb_ft_font_create_referenced(*(static_cast<const FT_Face *>(font->fc->GetOSHandle())));`
13:41:29 <glx[d]> but I may use an older vcpkg setup
13:45:00 <TrueBrain> michi_cc[d]: I guess we can wonder if we want to drag in fribidi, or use ICU .. the first has a much easier interface, but the latter saves another dependency ..
13:47:49 <michi_cc[d]> I guess we'll have ICU anyway for sorting and comparison stuff, so I guess if ICU is usable and sane, it does save another lib more.
13:48:09 <TrueBrain> just the ICU interface ... owh boy, it is one to write home about 😛
13:55:47 <glx[d]> lzo takes so much time to configure
13:59:26 <glx[d]> oh they reduced the number of things installed with boost-bimap
13:59:45 <TrueBrain> they fixed their shit, basically? 😄
14:00:59 <glx[d]> seems it's not directly the boost-bimap package, but some of the many dependencies
14:03:02 <TrueBrain> michi_cc[d]: no clue how good your memory is, but `fontMapping` .. does that always contain at least pos=0 and pos=length?
14:03:14 <TrueBrain> as with pos=length I also see a `Font`, but that feels a bit odd 😄
14:04:17 <TrueBrain> owh, I see, pos=length always exists indeed, and with what-ever font was last ..
14:04:26 <TrueBrain> I expected a `nullptr` there
14:04:51 <michi_cc[d]> gfx_layout.cpp:660 seems to indicate it always having and end entry
14:05:26 <TrueBrain> but okay, that is good; makes things a tiny bit easier 🙂
14:05:33 <TrueBrain> just the Font was unexpected 😛
14:06:50 <TrueBrain> (the comment in FontMap is a bit unclear what index it is .. the start? the end?)
14:07:20 <TrueBrain> hmm, pos=0 doesn't always seem to exist
14:07:33 <petern> I think I broke the clipping 😄
14:09:50 <TrueBrain> okay, lol, a lot of text start with a blue-font, but is changed colour at the first character .. hence the pos=0 entries .. they are irrelevant
14:10:05 <andythenorth> I mean....I wrote it...but eh
14:11:43 <TrueBrain> okay, so for the uniscribe you have two itemizations .. font/color and script/direction/.. .. and you overlay these to get the smallest runs .. now that kinda makes sense (finally :P)
14:11:44 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
14:11:54 *** WormnestAndroid has joined #openttd
14:13:07 <petern> Yeah, 10731 starts to remove some of those colour-codes-in-strings.
14:13:40 <TrueBrain> yeah, lot of waste CPU cycle now 😛
14:14:33 <glx[d]> default text color used to be blue, I think it's black now
14:14:49 <TrueBrain> still blue here, at least, the first FontMapping entry is blue 😛
14:14:57 <petern> It's black for the widget system, but the default for DrawString is still blue.
14:15:28 <petern> We should just change that to black and get rid of TC_FROM_STRING.
14:15:51 <petern> Then remove {BLACK} from the start of most strings (but probably not all)
14:17:20 <andythenorth> how many parameters can a procedure have?
14:17:48 <glx[d]> a lot, but the limitation is temp_register numbers
14:18:04 <andythenorth> I only need about 20
14:18:23 <andythenorth> not sure if it's going to free up any varact2 IDs but have to try
14:19:11 <glx[d]> should be fine with 20 (the 128 upper registers are reserved for nmlc internals)
14:19:25 <glx[d]> and the 20 params will be there
14:20:03 <glx[d]> and if procedures don't call each other they are shared
14:20:05 <andythenorth> it's quite easy to hit the varact2 limit 🙂
14:20:56 <glx[d]> it's worse with generated code I guess
14:22:57 <glx[d]> nmlc would require to make a dependency tree of all varact2 to reorder them and reduce the IDs lifespan
14:23:38 <andythenorth> 65536 varact 2 IDs maybe? 😛
14:23:56 <glx[d]> this option was discussed yesterday 🙂
14:24:32 <glx[d]> it won't be 65536 anyway
14:24:36 <petern> It was probably prompted by your shenanigans...
14:26:01 <andythenorth> well for today, I can probably pass a lot of params to one global procedure
14:26:05 <glx[d]> but 32 768 is already better than 256 🙂
14:26:07 <andythenorth> instead of switches for vehicles
14:26:16 <andythenorth> maybe I could have just one 'do everything' switch? 😛
14:26:19 <andythenorth> and parameterise it
14:26:27 <andythenorth> self-modifying function?
14:29:24 <TrueBrain> BiDi is up and running
14:29:49 <TrueBrain> now for script detection ..
14:31:03 <TrueBrain> mind you btw, the hardest part isn't done at all yet: multi-line support 😛
14:32:37 <glx[d]> hey at least it's easy to check right from main menu
14:40:42 <EmperorJake> Ooh is RGB patch making a comeback? Exciting
14:40:58 <TrueBrain> peter always has a patch for it 😛
14:42:42 <EmperorJake> Well the UI looks like an improvement over the earlier version
14:48:11 <TrueBrain> oof, the ScriptRun thingy from ICU is annoying to work with 😛
14:48:19 <TrueBrain> is in `icu_70` namespace
14:48:22 <TrueBrain> like .. I don't like that!
14:49:49 <Rubidium_> use the icu namespace
14:50:10 <Rubidium_> (which becomes icu_<somen number> during compilation in some way)
14:50:28 <TrueBrain> ah ... fucking magic ...
14:51:51 <andythenorth> lol concatenating accessor IDs for templating to template some accessor IDs
14:52:52 <andythenorth> I heard you like code generators?
15:03:39 <petern> Hmm, is an 8 bit colour index a byte or a uint8_t...
15:10:48 <TrueBrain> this is weird .. good portions work fine now, but there are also those that do not work fine .. like loading a game, paths are inverted 😛
15:11:16 <TrueBrain> that really isn't right 😛
15:17:12 <TrueBrain> seems BiDi does work sometimes, but doesn't work other times .. weird
15:27:15 *** WormnestAndroid has quit IRC (resistance.oftc.net reflection.oftc.net)
15:27:15 *** nebulabc has quit IRC (resistance.oftc.net reflection.oftc.net)
15:27:15 *** felix has quit IRC (resistance.oftc.net reflection.oftc.net)
15:27:15 *** hnOsmium0001 has quit IRC (resistance.oftc.net reflection.oftc.net)
15:27:15 *** rightnut has quit IRC (resistance.oftc.net reflection.oftc.net)
15:27:15 *** Ttech has quit IRC (resistance.oftc.net reflection.oftc.net)
15:27:15 *** nik has quit IRC (resistance.oftc.net reflection.oftc.net)
15:27:15 *** dwfreed has quit IRC (resistance.oftc.net reflection.oftc.net)
15:27:15 *** nebulabc has joined #openttd
15:27:17 *** rightnut has joined #openttd
15:27:24 *** WormnestAndroid has joined #openttd
15:27:34 *** hnOsmium0001 has joined #openttd
15:27:45 *** dwfreed has joined #openttd
15:42:21 <TrueBrain> lol, given the string `/home/micro/.local/share/openttd/save/`, the first and last character are seen as RTL, the rest as LTR
15:46:21 <TallTyler> Okay, need some C++ help here. I'm trying to move `ConvertDateToYMD()` and friends inside `TimerGameCalendar`, since it has separate implementations depending on whether the game is in real-time mode. I'm getting an incompatible declaration error for the implementation.
15:46:21 <TallTyler> The implementation is `/* static */ void TimerGameCalendar::ConvertDateToYMD(TimerGameCalendar::Date date, YearMonthDay *ymd)`.
15:46:21 <TallTyler> The declaration is `static void ConvertDateToYMD(TimerGameCalendar::Date date, YearMonthDay *ymd);`
15:46:21 <TallTyler> I suspect it has to do with the pointer, since I was able to move `ConvertYMDToDate()` with no problems, and `SetDate()` is already there. What am I missing?
15:48:55 <TrueBrain> is `YearMonthDay` in a namespace?
15:49:37 <TallTyler> It's still a struct in `date_type.h`, which I made sure is #included
15:49:53 <TrueBrain> I would like to see the actual error; but that is a bit verbose on Discord, so maybe via a gist 😉
15:51:52 <TallTyler> Super annoying that you can't copy error text in MSVC, but here's a screenshot 🙂
15:52:05 <TallTyler> Objectively the worst way to share text, I know 😄
15:52:10 <TrueBrain> yeah, see that `error-type` there
15:52:16 <TrueBrain> it couldn't resolve `YearMonthDay`
15:52:53 <TrueBrain> so `date_type.h` is included in the header file?
15:53:42 <TallTyler> I don't need to declare it outside of this namespace? Like in a folder path, `../`
15:54:08 <TallTyler> That wouldn't make any sense to me, but maybe I'm crazy
15:54:27 <TrueBrain> most likely this is something silly we are overlooking; but without seeing the code, it is a bit difficult for me at least 🙂
15:55:50 <TallTyler> Here's the diff, obviously doesn't build or anything
16:04:14 <petern> You've got a circular dependency.
16:07:52 <petern> YearMonthDay is defined in date_type.h which depends timer_game_calendar.h
16:08:11 <glx[d]> only #2 left to fix, but it's a lot of work I fear
16:08:35 <TallTyler> Ah, and there was another declaration in date_func.h which may have been confusing things too 🙂
16:13:39 *** Wormnest has joined #openttd
16:43:03 <TallTyler> Ugh, I'm almost regretting splitting Date typedef
16:43:17 <TallTyler> Fixed other problems, now I'm back to a circular dependency
16:43:31 <TallTyler> Where date_type holds some date types but not all
16:44:37 <TallTyler> Maybe the solution is to move most of date_type.h inside TimerGameCalendar...
16:51:19 <TrueBrain> okay, guess I was copying a bit too much from the Windows driver ... ICUs bidi flips the runs when in RTL
16:51:55 <TallTyler> Wow, what a rabbithole this is turning into
16:52:18 <TrueBrain> and seemly the itemizer of Windows doesn't do this .. interesting. I wonder how much it actually matters
16:52:38 <TrueBrain> TallTyler: : if you have cycle dependency, it mostly means you should have made another header file long ago
16:53:17 <TrueBrain> but yes, `YearMonthDay` should be part of `TimerGameCalendar`, given all its members are
16:53:46 <TrueBrain> it makes little sense to move the function manipulating it, and not the definition 🙂
16:55:17 <TallTyler> There's a lot of #define garbage in date_type.h that I'm not a fan of
16:56:03 <petern> Get rid of it first, if you can.
17:00:11 <petern> It's packing month and day into a uint16 (not sure why not a byte)
17:00:46 <petern> Oh 12 doesn't fit in 3 bits.
17:00:56 <TallTyler> Do we still need to keep this and similar things as macros, or can I convert them to functions?
17:00:58 <TrueBrain> diskspace is important!
17:04:14 <petern> A big lookup table like that implies something is performance sensitive.
17:04:23 <TrueBrain> michi_cc[d]: what can you tell me about the order of runs in relation to RTL? I am a bit confused .. different implementations act differently on it, and it seems OpenTTD has an expectation about it
17:04:33 <petern> But it may just have been carried through from the original code...
17:05:37 <TallTyler> Shall I try? Or leave them as-is?
17:09:48 <petern> I don't think anyone is particularly attached to that code 🙂
17:10:12 <TrueBrain> my offsets aren't right 😄
17:14:14 <TrueBrain> I assumed OpenTTD would reposition runs, but it doesn't .. 😄
17:14:36 <michi_cc[d]> TrueBrain: In which sense? I think the actual rendering code wants physical ordering of the complete line.
17:15:12 <TrueBrain> I am mostly confused when a string has some RTL and some LTR .. in what order they should be stitched
17:15:33 <michi_cc[d]> Also, not sure what ICU/harfbuzz except, but at least for Uniscribe you have to set the default bidi order of the string based on `_current_text_dir`.
17:15:51 <TrueBrain> so <RTL1> <LTR1> <RTL2> .. what is the visual form on screen ... <RTL2> <LTR1> <RTL1>?
17:16:38 <michi_cc[d]> In a single line without any other control codes going on, yes. Or more exactly <2LTR> <LTR1> <1LTR>
17:17:04 <michi_cc[d]> At least if you have a base direction of RTL.
17:17:23 <TrueBrain> so that explains why ICUs bidi already flips the runs around .. as it wants you to draw from right to left too
17:17:57 <TrueBrain> So now I have this flipped 😄
17:18:36 <michi_cc[d]> If the base language direction would be LTR, I *think* (might be wrong) it should be <1LTR> <LTR1> <2LTR> (visually speaking).
17:18:54 <TrueBrain> I would assume as much too, yes
17:19:37 <TrueBrain> but okay, it means I cannot copy/paste the Windows part to overlay fontMapping with the itemized runs
17:19:52 <TrueBrain> as for Windows it remains left to right, and sorting is done much later, it seems
17:20:30 <TrueBrain> most harfbuzz implementations have an endless amounts of if cases for RTL / LTR
17:21:29 <TallTyler> It seems putting a nested macro inside a namespace is a very bad idea
17:22:25 <michi_cc[d]> Also, at least back then one of the RTL translations (persian, arabic, hebrew; don't recall which one sadly), was not really good/proper on the LTR/RTL mixing. The translation might have been fixed by now of course.
17:22:27 <TallTyler> Because accessing it from outside the name space is either problematic or just straight up not allowed
17:22:58 <TrueBrain> michi_cc[d]: good point, I should update Steam to the nightly
17:23:07 <TrueBrain> that way at least I know we use give or take the same translation 🙂
17:24:50 <michi_cc[d]> Uniscribe itemize is still in char (logical) order as far as I can remember and only the `ScriptLayout` makes the visual order for a line.
17:25:09 <TrueBrain> so I am going to do the same, although ICU doesn't really want that
17:25:13 <TrueBrain> but it just makes a lot of things easier
17:25:23 <TrueBrain> endless amount of RTL checks is also not all that helpful
17:28:03 <LordAro> michi_cc[d]: #6667 iirc
17:28:03 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
17:28:11 <LordAro> somewhere around that number, anyway
17:28:43 *** WormnestAndroid has joined #openttd
17:35:09 <TrueBrain> And that too looks a match with Windows
17:35:22 <TallTyler> Would `static inline` functions be the right choice to replace macros?
17:35:47 <TrueBrain> not using macros is good, that is for sure
17:35:56 <petern> Really depends. Sometimes the macro is just for convenience, not performance.
17:36:25 <TrueBrain> in case of day/month, that sounds to me that a simple function with a switch case will carry the same idea 😛
17:36:33 <petern> Something like MAX_DAY could just be a constant instead of a macro.
17:36:33 <TrueBrain> let the compiler deal with it .. but that might be just me speaking 🙂
17:36:57 <TrueBrain> TallTyler: that is just a `static constexpr` or something
17:37:03 <TrueBrain> lol, reading is hard
17:37:11 <TrueBrain> an inline function will do fine if you ask me
17:37:51 <petern> MAX_DAY can't be constant, sorry 🙂
17:38:10 <TrueBrain> michi_cc[d]: okay, all pieces are there, seems to work fine. Even without harfbuzz-icu plugin. Only ICU i18n and harfbuzz needed. Now for the biggest job ... multiline support .. means I need to understand clustering 😄
17:38:39 <petern> LEAP_YEARS_TILL is only used in DAYS_TILL anyway.
17:38:46 <petern> But DAYS_TILL is used all over the place.
17:39:13 <petern> Wait, it's not, that's DAYS_TILL_ORIGINAL_BASE_YEAR...
17:39:44 <TrueBrain> That looks weird! But seemly that is correct 🙂
17:39:47 <petern> Only MAX_DAY and ConvertYMDToDate uses DAYS_TILL.
17:39:53 <petern> Yeah, MAX_DAY should definitely be a function.
17:40:20 <TrueBrain> michi_cc[d]: found what you meant with translators did silly things 🙂
17:41:21 <petern> I dunno, every time I look at it it looks like it can return different data, but MAX_DAY must be constant.
17:41:24 <TrueBrain> But that is my mistake somewhere .. hmm
17:42:34 <TallTyler> What I don't understand is how none of those macros look at the current day or year
17:44:27 <petern> They are days-till from day 0.
17:50:37 <petern> So yes, although MAX_DAY looks like it does evaluations, it should end up as a constant.
17:51:20 <petern> But every time it's used the compiler has to optimize that equation away.
17:54:04 <TallTyler> End up a constant after compiling, or I should make it a constant?
17:58:41 <TallTyler> Not sure what you're proposing I do, but I'm happy to follow instructions 🙂
18:00:46 <TrueBrain> michi_cc[d]: hmm ... ICU's bidi seems to do some weird things, but I can't really tell if it is ICU or just the string .. but something like "MyTown (123)" ... it says "MyTown " is LTR, the ( is RTL, the 123 is LTR, and the ) is RTL again
18:00:55 <TrueBrain> this causes some funky results 😛
18:01:06 <petern> TallTyler: I'm looking at it with no idea either 🙂
18:01:41 <andythenorth> hmm goes it nest wagons into 2 layers? 😛
18:01:44 <TallTyler> I'll open a PR and you can let me know your thoughts once you see the whole picture 🙂
18:03:06 <TrueBrain> seems Windows does the same ... still not what I expected, but I guess ....
18:04:41 <andythenorth> ha each sprite stack layer can have a recolour sprite I think :)D
18:05:02 <andythenorth> might need more spritelayers 😛
18:06:59 <andythenorth> for the 'mixed' I can show the available colours in some swatch
18:07:09 <andythenorth> or different coloured dice 😛
18:22:55 <andythenorth> "we're going to need a bigger boat"
18:29:10 * LordAro throws andythenorth overboard
18:29:30 <andythenorth> I watched Jaws last week
18:29:33 <andythenorth> pretty good still
18:34:30 <michi_cc[d]> TrueBrain: I had the "is it the translation or the code"-problem, too. If you paste the lang string into some "good" editor (like Word etc.) and it looks the same, I've just assumed a bad translation.
18:36:09 <TrueBrain> style: check; scripts: check; bidi: check
18:36:11 <michi_cc[d]> Pure numbers combined with punctuation is not always completely unambiguous, so translators need to occasionally include directional overrides.
18:37:04 <michi_cc[d]> Now I have no idea if you can actually paste them into Eints and see any sensible result...
18:39:24 <petern> `/* XXX: these are not done */` I wonder what that means.
18:39:39 <TrueBrain> most likely that it is implemented, knowing us 😄
18:40:47 <DorpsGek> - Update: Translations from eints (by translators)
18:41:53 <michi_cc[d]> No changes for any "interesting" language today 🙂
18:47:13 <TrueBrain> something for you to look at and laugh of the mistakes I am making 😉
18:47:32 <TrueBrain> and yes, the shaping shouldn't be done in ICUVisualRun, that should be done in its own function, much like the Windows variant 🙂 But this was easier for now 😛
18:49:42 <michi_cc[d]> Just as a different data point, I just tried Japanese IME input in three different commerical games (and not just low-budget indie games), and none had anything even resembling proper japanese input.
18:50:18 <TrueBrain> IME input is also very broken with my PR 😄 The map-function returns a nullptr 😛
18:50:22 <pickpacket> michi_cc[d]: how’s openttd doing by comparison?
18:50:22 <TallTyler> Another possible relevant issue: #6666
18:51:22 <TrueBrain> TallTyler: that issue is solved, but one of the comments derailed it a bit 😛
18:51:24 <michi_cc[d]> Game 1 let Windows handle the IME overlay, which meant it was completely in the wrong place. Game 2 blocked even switching to japanese input, and game 3 allowed the switching but never gave Windows a chance to handle the key input.
18:52:03 <michi_cc[d]> pickpacket: On Windows and OSX, fully integrated, with proper positioning of the IME overlay and proper marking of in-progress text in our custom input widgets.
18:52:52 <michi_cc[d]> I.e. probably better than 99% of commercial games that draw their own UI (which excludes all the hidden or not so hidden in-browser games).
18:55:25 <petern> Every time I look at RGB-CC I get confused about colour, because we have "a few" different representations.
18:57:10 <andythenorth> wonder what your RBG patch is going to do all my colour choice ideas 😄
19:00:34 <michi_cc[d]> TrueBrain: I guess you forgot some conditionals in your CMakeList files 🙂
19:00:41 <TrueBrain> yeah, fixing them already 🙂
19:02:14 <petern> We have 16 `Colours` (used by widget backgrounds and company colours, and text in certain places (although in that case it's translated to a palette index and is a byte), and 17 `TextColour` which are only used by text, unless the text uses a `Colours`. And of course there are raw palette indices (usually passed as byte), and also `Colour` which is 32 bit RGBA, for the 32bpp pixels. Such.
19:02:34 <TrueBrain> okay, I expected this to be much worse, but I have to say .. it is not that bad .. and I think I somewhat understand it too 😛 Tnx again michi_cc[d] for the endless amount of context / information 🙂
19:03:00 <petern> With RGB-CC, I need to stuff RGB into both Colours and TextColour, but it has to be different in each.
19:03:21 <petern> And I need to change the raw palette indices to be palette index + RGB component.
19:03:34 <petern> Okay, that's how I'm confused, too many different types 🙂
19:04:23 <TrueBrain> drop indexed and switch to RGBA for everything? 🙂
19:04:29 <TrueBrain> drop 8bpp blitters while we are at it?
19:14:22 <TrueBrain> the one function I already mention here that I have to address .... he comments on 😛 😛 😛 😄
19:14:28 <TrueBrain> like I could predict it 😄 ❤️
19:16:12 <TrueBrain> oof, good point; I read the special code, and I did not validate what happens if I now run it .. most likely BOOOOEEEEMMMMM 😄
19:16:47 <michi_cc[d]> Probably not. It might just map them to the undef font glyph (often a square box).
19:16:56 <michi_cc[d]> I.e. how does a station sign look like?
19:17:19 <michi_cc[d]> string_uniscribe.cpp:188 for reference
19:17:26 <TrueBrain> a nice questionmark!
19:17:35 <TrueBrain> and yes, I read the code .. just forgot about it 😛
19:17:40 <TrueBrain> pretty sure I forgot more things 😄
19:19:46 <petern> Hmm, what about... replacing textcolour with indices. Hmm.
19:20:06 <TrueBrain> it says the first word means "sensual" .. sounds weird
19:20:37 *** WormnestAndroid has quit IRC (Remote host closed the connection)
19:20:38 *** WormnestAndroid has joined #openttd
19:33:49 <michi_cc[d]> A really interesting thing to know for the automated survey would be OpenTTD language compared to system language, as that might indicate bad translations. Except of corse that this is straying very close to gathering personal data.
19:41:24 *** axet has quit IRC (Quit: Leaving.)
19:43:26 <petern> Oh yeah, I forgot about PC_ colours, which are also just palette indices. Hm.
19:46:06 <andythenorth> oof Horse compile time increased 😛
19:51:46 <andythenorth> can't even think why this might increase compile time 😛
19:51:54 <andythenorth> 5 generations of that, with 3 wagon lengths
19:52:20 <andythenorth> just the casual 240 vehicles or so
19:53:13 <andythenorth> it's increased from 16s to 17s
19:57:33 <LordAro> is that really all that's left?
19:59:01 <Rubidium_> this is just an assortment of related changes
20:00:49 <TrueBrain> Misleading topic, pfffff .. we were already having a party :p
20:48:48 <Kuhnovic> Time to clean this old PR of mine up
20:59:07 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:02:03 <Kuhnovic> That was very quick 😛
21:13:17 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:13:38 <TrueBrain> That's what she said 🤡
21:43:39 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
21:43:49 *** WormnestAndroid has joined #openttd
22:12:53 <andythenorth> I should never write `while` ever
22:15:30 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:20:53 <petern> What have you done now...
22:25:20 <andythenorth> random wagons, your choice of colours
22:29:25 <andythenorth> do I want to add another option for some sort of magic realistic colours, per RL
22:30:31 <andythenorth> might increase compile time 😛
continue to next day ⏵
