Time Nick Message 14:14 MTDiscord <appguru> Can we remove non-freetype support? 14:17 sfan5 why 14:17 sfan5 and yes 14:31 don_flymoor Hi! Does anyone know why I can see the inside of the player when using directx9? 14:31 don_flymoor This only happens in 5.4.0 14:32 don_flymoor It completely blocks the screen. 14:34 rubenwardy It adds more cases to support 14:34 rubenwardy We have freetype and nonfreetype text boxes or something iirc 14:35 don_flymoor I don't understand what you mean 14:38 don_flymoor Does using directx9 disable backface culling? 14:40 rubenwardy I'm not responding to yoy 14:42 MTDiscord <appguru> sfan5: I was looking into font media, which I'd do using .ttf files, which requires freetype 14:44 MTDiscord <IhrFussel> @don_flymoor there is already a github issue about your problem and I think the devs won't fix it as they don't offifially support directx 14:45 don_flymoor Even if it's not officially supported, it glaring issues like this should be fixed, as directx is faster than opengl on windows. 14:52 MTDiscord <Jordach> incorrect 14:52 MTDiscord <Jordach> a real GPU or Intel iGPU are actually considerably better at OpenGL 14:55 don_flymoor While true, Minetest is CPU bound, and at least on my pc, DirectX is faster because it uses less CPU than OpenGL. 14:56 MTDiscord <Jordach> what 14:56 MTDiscord <Jordach> if OpenGL had a bottleneck it wouldn't be used period 14:56 don_flymoor Of course it has a bottleneck 14:57 MTDiscord <Jordach> irrlicht's general implementation of the standard OGL library is a bit naff 14:57 don_flymoor It seems to use draw calls more than DirectX 14:57 don_flymoor I agree 14:58 don_flymoor So: Why are we still using Irrlicht? 14:58 MTDiscord <Jordach> i get zero GPU assistance as minetest does all mesh manipulation on CPU and is single threaded at that 14:59 don_flymoor So why isn't Minetest multithreaded? That would make it a lot faster, and get rid of a lot of server lag. 14:59 sfan5 "why isn't this glaring issue fixed?" "why are we still using irrlicht?" "why isn't minetest multithreaded?" 14:59 MTDiscord <Jordach> it probably uses more draw calls as OpenGL has a much better depth buffer solution than DX that is also portable against macOS, Linux, BSD 14:59 sfan5 who's gonna do it? 15:00 MTDiscord <Jordach> also this 15:01 sfan5 spending time to fix directx issues is also unwise as we're extremely likely to fully drop support in the upcoming 5.5.0 15:02 don_flymoor Perhaps supporting Vulkan would be a good idea. Now that Minetest has their own version of Irrlicht, it would be more feasable. 15:03 don_flymoor Of course, it's probably not going to happen 15:03 MTDiscord <Jordach> are you suggesting us unpaid contributors are to implement a brand new rendering stage 15:03 MTDiscord <Jordach> none of are named john carmack 15:03 don_flymoor Yes 15:03 sfan5 it's more realistic to fix up OpenGL usage to make it more performant 15:04 rubenwardy don_flymoor: have you tried disabling shaders? 15:04 don_flymoor Yes. No change in performance 15:04 sfan5 our shaders don't work under directx anyway 15:04 sfan5 oh this is in regard to performance 15:04 sfan5 nvm then 15:04 rubenwardy I meant on OpenGL, yeah 15:06 don_flymoor The bottleneck seems to be meshmaking, so multithreading would theoretically improve performance more than anything else, 15:06 sfan5 there is a thread dedicated to meshing 15:07 sfan5 I think first someone knowlegeable should analyze rendering with one of those opengl profilers and see what's so inefficient 15:07 Calinou RenderDoc time :) 15:10 don_flymoor rendermap:drawmeshes(SOLID) and game:updateframe:drawscene are the slowest parts 15:10 don_flymoor Yet my GPU is at 1/3 capacity 15:11 don_flymoor And when I activate ReShade, the FPS stays the same. 15:13 don_flymoor OpenGL and DirectX both suffer from this, but DirectX less so. 15:16 don_flymoor How difficult would it be to port Minetest to a different rendering engine like Ogre? 15:17 sfan5 very 15:18 MTDiscord <Jonathon> there are some github issues where people suggested bgfx and in there are some of the issues 15:19 don_flymoor I guess it isn't very feasible, without pretty much rewriting a lot of Minetest. 15:34 sfan5 >minetest_2021.03.29_15.32.35_frame3155.rdc loaded. Capture has 210 issues. 210 Unread. 15:34 sfan5 I guess this is a good sign 15:44 sfan5 okay turns out the OpenGL Irrlicht uses is way too legacy so RenderDoc can't be of help 15:44 don_flymoor Minetest tells me it's using OpenGL 4.6.0 15:45 sfan5 that's what the GL context says it supports 15:48 don_flymoor I wonder if we could use https://github.com/Devsh-Graphics-Programming/Nabla as the render engine. It promises Vulkan support, and is build off Irrlicht. 15:48 don_flymoor Nabla (previously called IrrlichtBaW ) is a new renovated version of older Irrlicht engine. The name change to Nabla allows for using Nabla side by side with the legacy Irrlicht and IrrlichtBaW engines. The project currently aims for a thread-able and Vulkan-centered API, but currently works on OpenGL only. 15:51 don_flymoor It it is a modified version of Irrlicht, it may be very easy to use it in Minetest. It might also be better, or at least faster. 16:33 don_flymoor I'm going to try building IrrlichtBAW and see if Minetest works with it. 16:53 rubenwardy The GUI will break, and the API will have differences 16:59 don_flymoor But it won't be very difficult to fix... I hope 17:02 sfan5 this has been brought up before, irrlichtbaw has dropped all GUI stuff which we do use 17:03 don_flymoor Could we change our GUI? 17:03 sfan5 change it to what? 17:03 don_flymoor Whaterver BAW uses 17:03 sfan5 nothing AFAIK 17:04 don_flymoor Build A World has a GUI 17:09 don_flymoor I believe remaking the GUI would be worth it to get the performance from IrrlichtBAW 17:09 MTDiscord <Benrob0329> It'd require another library, such as Nuklear or Dear ImGUI 17:11 don_flymoor As far as I can see, implementing another GUI wouldn't be very difficult 17:11 MTDiscord <josiah_wi> Is there anything I can do to help get my build PR to the new Irrlicht fork merged? 17:15 sfan5 I think it'd help to see how the changes that'd be made to the engine should looks like 17:15 sfan5 and maybe another coredev has an opinion on that 17:17 MTDiscord <josiah_wi> I could PR an update to the engine at the same time. 17:18 MTDiscord <josiah_wi> That might be kind of weird though because the engine can't actually use the change until it's been made here. 17:39 appguru #11130 needs some attention - Minetest is finally getting depth sorting! 17:39 ShadowBot https://github.com/minetest/minetest/issues/11130 -- Fix rendering of allfaces nodes with transparent textures by x2048 17:44 sfan5 merging #11084, #11124, #11126, #11132 in 10m 17:44 ShadowBot https://github.com/minetest/minetest/issues/11084 -- Replace fallback font nonsense with automatic per-glyph fallback by sfan5 17:44 ShadowBot https://github.com/minetest/minetest/issues/11124 -- Add missing languages to settingtypes.txt by Emojigit 17:44 ShadowBot https://github.com/minetest/minetest/issues/11126 -- Clean up various misleading and/or confusing messages and texts related to priv changes by Wuzzy2 17:44 ShadowBot https://github.com/minetest/minetest/issues/11132 -- Update CONTRIBUTING info on translating builtin by Wuzzy2 17:44 pgimeno wow, does that mean that water won't disappear when watched through glass? 17:45 MTDiscord <appguru> Yes. 17:45 appguru 11130 is really impressive. 17:49 sfan5 coincidentally I just looked at renderdoc (this time with GLES, that works) and wondered why Minetest draws the furthest mapblocks first, wasting effort 17:50 pgimeno farthest first is painter's algorithm, right? 17:50 sfan5 yes 17:51 pgimeno it makes sense for drawing half-transparent stuff 17:51 pgimeno not for fully opaque or fully transparent blocks 17:53 sfan5 drawing opaque stuff with z buffer should work regardless shouldn't it? wonder why that wasn't done 17:56 pgimeno for opaque geometry, drawing near stuff earlier improves performance, because shaders don't need to process pixels that are farther once the ones in front are drawn 17:57 pgimeno it works either way, it's just more performant to draw from front to back 17:58 sfan5 I know, but why aren't we doing that for opaque stuff? it looks like such an obvious optimization 17:58 pgimeno *shrug* 18:09 appguru Well 18:09 appguru You could first render all opaque stuff closest first 18:10 kilbith the chat messages are UTF-8, correct? 18:10 kilbith I'm wondering if we could extend it to UTF-32 to support emojis 18:11 sfan5 chat messages are unicode, usually stored in std::wstring 18:11 sfan5 whether that is 16-bit chars or 32-bit chars depends on OS 18:11 sfan5 network transfer uses utf-16 but I made surrogate escapes work before 5.4.0 recently 18:11 sfan5 or in short: the only thing preventing emojis on a platform with 32-bit wchar is the right font 18:12 sfan5 (emojis should be able to work on 16-bit wchar platforms too I'm just not so sure about that) 18:15 MTDiscord <appguru> Strings are rarely stored using UTF-32 as that wastes much memory. 18:15 appguru Which encoding is used doesn't matter however. UTF-8 and 16 support emojis just as fine. 18:16 appguru Sticking with UTF-8 is preferrable, as that is the encoding used by Lua. 18:30 pgimeno Yeah, emojis are a question of font support, not of encoding. And colour emojis are a different beast. 18:37 sfan5 appguru: lua doesn't deal with anything more than ascii 18:38 appguru sfan5: that's wrong 18:39 appguru newer Lua versions even ship with UTF-8 utility functions 18:41 sfan5 as long as string.sub() does not operate on utf-8 I consider "lua strings are utf-8" to be a false statement 18:41 sfan5 this is the case even with 5.4 18:42 appguru in most languages the substring method operates "char"-wise and not "rune"-wise 18:42 appguru examples: Go, Java 18:42 appguru those are UTF-16 though 18:44 sfan5 that's a different kind of broken 18:49 sfan5 "lua strings are byte strings and builtin functions operate on ASCII" is what I consider correct to be clear 18:53 MTDiscord <appguru> more like Latin-1 18:54 appguru I don't really see the point though 18:55 appguru Chat messages have to be passed to Lua. It is most convenient to have everything UTF-8 in Lua. 18:55 appguru Sure, most builtin functions operate on strings like on a byte array, which fair, they are. 18:55 sfan5 of course, I didn't say anything unlike that 18:57 MTDiscord <Warr1024> People seem to like to use UTF-16 because the assumption that each character could be represented by 2 bytes survived longer than the assumption that each could be represented by 1, i.e. a lot of supposedly-UTF-16 things are actually UCS-2 ones. 18:58 MTDiscord <Warr1024> Just query the string length of most emoji and you'll often get 2 characters, meaning that the string length function is just dividing byte count by 2 instead of actually walking the UTF-16 data. 19:09 celeron55 utf-16 is the worst, people think it works when it's actually broken 19:09 Krock UTF-32 will solve the world problems 19:10 MTDiscord <Warr1024> UTF-16 might be the worst right now, but give them time and they'll think of something worse. I mean after we've got the UUID data type, and time zones are still a thing. 19:11 celeron55 Krock: except that it's a waste of space if your use case is common languages 19:11 Krock to Chinese people, Chinese is common. 19:11 MTDiscord <Warr1024> UTF-32 will solve all of the world's problems exactly the same way UTF-16 did. 19:12 MTDiscord <Warr1024> And then UTF-64, UTF-128, etc will subsequently... 19:12 celeron55 Krock: don't most chinese characters fit in 2 bytes in utf-16? 19:13 sfan5 I think they do 19:13 sfan5 but if you're going for space savings you should really just use utf-8 19:13 celeron55 what i'm reading now says utf-8 generally needs 3 bytes for chinese characters 19:13 sfan5 and if you need quick iteration / random access or something else go for utf-32 19:14 sfan5 hm that's true 19:14 celeron55 i suppose utf-32 compressed using some very lightweight algorithm would be most idiot programmer proof, which is sad but could be a nice life hack 19:14 MTDiscord <Warr1024> UTF-32 would make the problem go away for now but you'd effectively be punting it down the line. 19:15 MTDiscord <Warr1024> i.e. the reason why you'd use UTF-32 in the first place is if you could pretend that you don't need to actually parse it and can just multiply stuff by 4 to calculate offsets 19:15 MTDiscord <Warr1024> which is true ... for now, just as it once was for UTF-16. 19:15 sfan5 if we define more than 4 billion(?) characters we have other problems 19:15 celeron55 utf-32 will suffice for our lifetime 19:15 celeron55 definitely 19:15 MTDiscord <Warr1024> We already have the other problems. 4B+ characters is just one of the few we haven't tried having yet. 19:17 MTDiscord <Warr1024> If the alternative is just playing a game of kicking the can farther down the road, might as well just use one of the UTF's we already have now, like UTF-8 or something. 19:17 celeron55 current computers could barely hold a font to display all of the utf-32 character space 19:17 celeron55 if it was the only task to do 19:19 celeron55 and it would take you years to read all the characters, assuming you knew them all already 19:19 celeron55 as a human 19:19 celeron55 if one of each was displayed 19:23 MTDiscord <Benrob0329> ah yes, making fonts is now a monumental task if you want to have a decent amount of Unicode support 19:45 sfan5 cppreference.com replaced its search with duckduckgo and it's pretty awful 20:11 sfan5 wonder why nobody has fixed #8662 yet, the problematic is identified and everythin 20:11 ShadowBot https://github.com/minetest/minetest/issues/8662 -- TextArea output color is ignored after first line of text. 20:11 sfan5 +g 20:12 sfan5 problematic code* 20:18 numzero utf-32 is limited to well below 4B characters (“code points” in Unicode terms) 20:19 numzero because every code point has to be encodable in UTF-16 as well 20:19 numzero whose surrogate pair can encode 20 bits only 20:19 numzero thus limiting Unicode to 1M characters 20:21 celeron55 that is a bit of a bummer really 20:21 numzero also regarding Chinese characters, read a bit about so-called Han unification 20:22 numzero which was needed to force Chinese and other languages into 16-bit encoding 20:22 numzero while Japan alone has about of 65k ideographs ATM AFAIK 20:23 numzero (“ATM” is important here, that number grows with time) 20:27 celeron55 1M is less than i thought, i suppose we need a new encoding in our lifetime after all 20:28 celeron55 if i go looking for a more future proof character encoding than utf-32 i suppose everyone will tell me i'm completely crazy 20:30 pmp-p not crazy and that would probably be abstract language indepedant lexeme encoding 20:30 numzero something like older (first draft, before cloning Unicode) ISO-10646? 20:30 MTDiscord <Warr1024> We're used to thinking of unicode as a technical project but really it's as poltical as anything else, which means they aren't really all that strictly bound by sense. 20:30 sfan5 for some reason Irrlicht uses about 400 triangles to draw a 16x16 inventory image 20:30 sfan5 under GLES at least 20:30 appguru Extrusion mesh 20:30 numzero also there is the TRON project, they have own character set too AFAIK 20:31 celeron55 i guess it'll be utf-8 anyway, with some crazy wasteful extension scheme in which the wastefulness will not matter in the slightest due to insane far future storage space and network bandwidth increases 20:31 numzero know little about these though 20:31 sfan5 (well not really 16x16, it's scaled and not all of the triangles are the same size) 20:31 sfan5 appguru: that'd be stupid 20:31 appguru yeah 20:31 MTDiscord <Warr1024> It is kinda stupid 20:31 Krock UTF-32 helpfully has enough space to contain the vomiting cowboy emoji. https://imgs.xkcd.com/comics/vomiting_emoji.png 20:31 appguru but Minetest has fancy spinning thingies support 20:31 appguru so I assume when that was added, people just got rid of plain old inventory image drawing 20:31 numzero sfan5, Warr1024: that only means that IS likely to happen 20:32 Krock s/help/hope/ 20:32 MTDiscord <Warr1024> That and the fact that the 2D image scaling formerly used on inventory images was controversial 20:32 numzero oops 20:32 appguru The vomiting statue of liberty is more important. 20:32 numzero answering to wrong question 20:32 MTDiscord <Warr1024> and also because rendering nodes to 2D textures for drawing in the inventory used to be a fuster 20:32 appguru well, nodes usually only have 12 tris 20:32 MTDiscord <Warr1024> I want a vomiting middle finger emoji 20:33 appguru we should really optimize extrusion meshes 20:33 appguru it's pretty simple in fact 20:33 MTDiscord <Warr1024> really really 20:33 celeron55 let's make a blockchain character set, anyone can add any characters and it'll just grow and grow indefinitely with some mining cost 20:33 sfan5 appguru: https://0x0.st/-bBv.png 20:33 numzero Warr1024: tell the Unicode consortium, it codifies emojis 20:33 appguru but C++ makes it hard 20:33 MTDiscord <Warr1024> I'm sure members of the Unicode Consortium read xkcd 20:34 sfan5 maybe this is irrlicht poorly attempting to emulate nearest neighbor scaling 20:34 sfan5 but why? 20:34 MTDiscord <Warr1024> I think if we were to optimize extrude meshes for specific transparency masks, at least, then it would improve render performance for NodeCore, possibly significantly in some areas. 20:34 celeron55 sfan5: nearest neighbor scaling isn't supported by the backend? 20:34 celeron55 i can imagine that for gles1, maybe not for 2 20:34 appguru we've got drawImageFilteredScaled or what it's called 20:35 appguru but this is probably not relevant here 20:35 Krock extrusion mesh optimizations? slap one front face and back face to it, then add the vertices on transparent borders 20:35 appguru that's the point 20:35 MTDiscord <Warr1024> Probably the reason for extrude meshes in inventory is a combination of the rotation thing, and that mixing 2D images and 3D models in the HUD or formspecs is probably too much of a pain. 20:35 sfan5 side fun fact: guiFormSpecMenu.cpp is 135 KB 20:35 Krock and only borders, rather than front&back 20:35 appguru currently there's unnecessarily many border vertices 20:36 MTDiscord <Warr1024> Extrude mesh optimization is good for more than just HUDs or Formspecs, though, it'd be a big boon for ents. 20:36 numzero remember #6803 20:36 ShadowBot https://github.com/minetest/minetest/issues/6803 -- Optimize wieldmesh by numberZero 20:36 appguru well, complex generation of front and back would fix one of warr's bugs 20:36 sfan5 celeron55: from a quick google gles2+ should definitely do GL_NEAREST 20:37 MTDiscord <Warr1024> IIRC there have been attempts to use a single face for the front/back but it's caused problems with texture filtering before. 20:37 appguru ^ 20:38 appguru numzero: #6803 looks fine - could you however cache the same normals, texcoords and vertices for all extrusion meshes of same size (say 16x16) and then just cache the different indices (omission of some border tris)? 20:38 ShadowBot https://github.com/minetest/minetest/issues/6803 -- Optimize wieldmesh by numberZero 20:38 sfan5 https://github.com/minetest/minetest/blob/master/src/client/hud.cpp#L949 20:38 sfan5 mystery solved 20:38 sfan5 appguru was right, it uses the extrusion mesh 20:38 sfan5 who writes all this stupid code and more importantly who reviews it.. 20:39 MTDiscord <Warr1024> probably whoever added the rotation feature 20:39 numzero appguru: um, well, I could 20:39 numzero for everything not too large (128² at most probably) 20:39 appguru Seeing as you already invested quite some work, albeit a few years back, could you basically redo that PR? 20:39 rubenwardy It would have been RBA when spinning slots were added 20:40 numzero make yet another PR that won’t ever be merged? 20:41 MTDiscord <appguru> ¯_(ツ)_/¯ 20:42 MTDiscord <Warr1024> HEh, yeah, LMD, I think maybe the torch has been passed to you now :-) 20:42 celeron55 #6067 20:42 ShadowBot https://github.com/minetest/minetest/issues/6067 -- [CSM] Add basic HUD manipulation. by red-001 20:43 appguru Well, I don't really want it 20:43 celeron55 sfan5: interesting, this was added as a PR 20:43 appguru I'd be a lot less efficient than numzero 20:44 sfan5 it doesn't matter if you inefficiently produce efficient code ;) 20:44 celeron55 with simultaneous changes and a move of the hud.cpp file making the automatic github diff not really work 20:44 celeron55 so probably nobody really even checked it 20:45 celeron55 wait 20:45 celeron55 this is just the move 20:47 appguru Is there any way you can hit yourself with a regular Minetest client? 20:47 appguru I'm considering making an anticheat PR for that 20:47 appguru Because while it can be caught at mod level, it shouldn't have to be 20:48 sfan5 that's more anti-things-that-shouldn't-happen and not anticheat, but good idea 20:48 appguru Well, this is used as a cheat 20:48 appguru For example medics in Capture The Flag healing themselves... 20:49 MTDiscord <oneplustwo> relevant issue: https://github.com/MT-CTF/capturetheflag/issues/756 20:49 celeron55 6cd2b3b445bf558fda1e5a7908adef8e3a45449a 20:49 sfan5 https://github.com/minetest/minetest/commit/6cd2b3b445bf558fda1e5a7908adef8e3a45449a 20:49 celeron55 that's the RBA commit doing this 20:50 sfan5 yea as suspected 20:51 appguru Should I compare player and hitter by name? 20:51 celeron55 https://irc.minetest.net/minetest-dev/2016-02-07#i_4526594 20:51 celeron55 https://github.com/minetest/minetest/pull/3610 20:52 celeron55 lol 20:53 celeron55 even sfan5 said "Very nice", and paramat tested "no FPS drop" 20:53 celeron55 so it was reviewed to today's standard 20:53 celeron55 somehow it's still what it is 20:53 appguru well of course no FPS drop with 16x16 textures 20:53 appguru RIP 1024x1024 20:54 appguru That's more than two million tris 20:54 appguru per item, that is 20:54 MTDiscord <Benrob0329> At very high resolutions, is it cheaper to just layer planes on top of each other and fake the effect? 20:54 appguru should not be done 20:55 appguru well now that I think of it 20:55 appguru well no 20:55 appguru now that we got object shading, edges will look weird 20:57 appguru can I rely on the fact that the pointers will be equal if puncher and hitter are equal? 20:58 sfan5 of what object? 20:58 sfan5 I can think of an easier way already: compare the ids of active objects 21:07 appguru #11137 21:07 ShadowBot https://github.com/minetest/minetest/issues/11137 -- Detect interacting with yourself by appgurueu 21:08 sfan5 https://0x0.st/-bBh.png now that's better 21:15 Krock is that a security issue after all? 21:15 Krock side-note: I observed this possibility in a 0.5.0-dev update where the GenericCAO message format changed. on failure, the entity would just follow the actual player 21:15 Krock by a delay of one server tick 21:16 Krock but well, that's an exotic case 21:20 sfan5 hm does devtest have any colorized items for testing? probably 21:23 appguru sfan5: fixed 21:27 sfan5 devtest has exactly zero items that are colorized 21:27 sfan5 (but a few nodes) 21:28 sfan5 wait nvm 21:30 sfan5 ah no it really has none 22:14 sfan5 merging #11067, #7840 in 10m 22:14 ShadowBot https://github.com/minetest/minetest/issues/11067 -- Fix wield image of plantlike_rooted by Wuzzy2 22:14 ShadowBot https://github.com/minetest/minetest/issues/7840 -- Degrotate support for mesh nodes by numberZero 22:23 Pexin question about the new font fallback stuff: will fallback glyphs be guaranteed to have the same dimensions as the main chat output monospace font? ..or is that a dumb question? 22:24 sfan5 the font engine will grab the fallback font at a matching size 22:24 sfan5 but it will not be monospace or support bold/italic (this is not different than before) 22:25 Pexin not be mono? 22:25 Pexin i'm talking about the "t" and F10 console 22:26 sfan5 yes 22:26 sfan5 fallback glyphs there will not be monospaced 22:26 Pexin maaan.. 22:27 Pexin so that requires a total rewrite of the layout code 22:27 sfan5 not at all, it should be easy to add this 22:28 Pexin even though it currently uses the column number when constructing fragments? 22:29 sfan5 I don't know the code of the chat console so I have no idea what you're referring to 22:29 sfan5 since it already works for the non-fallback font now it logically can also work for the fallback font 22:29 Pexin the T and F10 consoles rely on monospace font 22:29 sfan5 (that difference is invisible to the chat console) 22:30 sfan5 which usecase do you have anyway where fallback glyphs are used and monospace matters? (chinese characters are all the same width) 22:30 Pexin romanic letters mixed with pictographs? 22:31 Pexin the reason i'm curious is if the new font stuff makes #11092 obsolete 22:31 ShadowBot https://github.com/minetest/minetest/issues/11092 -- Make chat web links clickable by pecksin 22:32 sfan5 you mean for underlining and/or coloring links or something? 22:32 Pexin but if that's the case, as i see it layout will need major restructure 22:32 Pexin underlining is impossible currently 22:33 Pexin but the mouse picking, and more importantly construction of text lines, does rely on monospace 22:34 sfan5 you should use font->getDimension to determine the click targets for that 22:39 Pexin that is already used to populate v2u32 GUIChatConsole.m_fontsize which is used to build the output 22:40 sfan5 no I mean measure the size of the characters in the actual line with the link 22:41 Pexin currently can't be done 22:42 sfan5 then you do have a problem 22:42 Pexin we all do ;)