Time Nick Message 02:07 v-rob I noticed from the earlier shader conversation that hecks proposed multiple things that used raw OpenGL. I don't see how that's ever a proper solution as long as we superficially support any non-OpenGL drivers in Irrlicht. Either they have to be go or the OpenGL code has to be implemented in Irrlicht. 02:08 hecks our support for any video driver other than GL is only nominal 02:08 hecks just try running MT in any of the other renderers 02:08 hecks it's also worthless, do windows machines without GL exist? no 02:08 v-rob I know. I certainly wouldn't miss D3D or the software renderers 02:08 hecks do software implementations of GL exist? yes 02:09 hecks and they perform better than burningsvideo 02:09 v-rob I'll bet 02:09 hecks is the irrlicht base software driver horribly broken? yes 02:09 hecks it's basically a joke 02:09 hecks in short we can straight up delete everything except gl and gles 02:09 v-rob They say it's for 2D, but it can't even scale images 02:10 hecks since we write shaders in glsl, do we require opengl for shaders? yes 02:10 hecks then why shouldn't i just use gl apis for that 02:11 hecks in fact i'm now writing this thing against raw gl2 and i'll figure out later how to hook it up 02:11 hecks it's so much less code than irrlicht anyway 02:12 v-rob I'd personally advocate for throwing out all non-GL drivers from Irrlicht before using raw GL in Minetest. 02:12 hecks is that a request 02:12 hecks because i'll be happy to rip those out 02:15 v-rob Well, I would request it, but it's probably best to see what the other devs think (although I'm fairly certain that they'd mostly agree) 02:15 hecks i vaguely recall hearing sentiments like this long long ago 02:15 hecks i think we basically don't support anything other than GL anyway 02:16 v-rob Yeah, we've recently closed some D3D-specific issues because we don't care about it 02:18 hecks my plan right now is to call GL directly for program and blend state while still leaving textures and meshes to irrlicht because it provides a tiny bit of value there 02:19 hecks though not a whole lot of said value; irrlicht's handling of meshes is meh 02:20 hecks and for textures we also don't officially support all the formats irrlicht does 02:20 v-rob I'm pretty sure the main argument for keeping Irrlicht at all is that it gives us a scene graph and because getting rid of it would be hard 02:20 MTDiscord More the latter 02:20 hecks it's a very naive scene graph, almost worthless; we do half its job anyway 02:21 v-rob With a voxel-based system like we do, I'm sure a very intelligent scene graph could be made 02:21 hecks i'll write a better one eventually, just not everything at once 02:21 hecks like 02:21 hecks it's 100% worth it for the sake of gutting irrlicht 02:22 hecks irrlicht is what prevents us from fixing things like our drawcall bottleneck 02:22 v-rob I like having someone who knows OpenGL 02:22 hecks well you got that 02:23 hecks while i mostly know it from the gl4.5 perspective, shaders have barely changed at all 02:23 hecks actually none of the basic parts of gl have changed much 02:23 v-rob Anyhow, I'm pretty interested in Irrlicht stuff right now because I want to expose some higher-level 3D rendering APIs to CSM Lua, but I don't want to tie it to Irrlicht 02:23 hecks oh yeah you see 02:24 hecks what i'm doing now (materials) will let you do exactly that 02:24 hecks both clientside and remotely triggered 02:24 hecks and if i can "punch through" some GL functions, even better 02:25 hecks i'm sure you'd rather have control of things like the viewport and the matrix stack for your experiments 02:26 hecks oh and more good news 02:26 hecks multidrawelements is pretty widely supported 02:26 hecks it's in both gl2 and gles2 02:27 hecks which means that the drawcall bottleneck is pretty solvable - but it requires some rethinking of how VBOs are built 02:27 hecks and that'll be an excuse to yank meshes away from irrlicht when we get around to it 02:28 hecks but that's down the road, right now it'll just be shaders and i'll have to necessarily take a break from the engine after this is up 04:02 ShadowNinja software/burningsvideo have always been varying degrees of "badly broken" so I wouldn't miss them. We might be able to do just modern OpenGL (3+) and ES, looks like just about everything in mesa supports 3.1+, and most support 3.3+: https://mesamatrix.net/ Vulkan would also be nice, a good option for when the OpenGL drivers are bad. 04:30 MTDiscord Vulkan entirely deprecates the entire iOS and Mac platforms which we currently support 04:54 hecks sadly don't count on me doing anything vulkan related because i don't have vulkan capable hardware 04:54 hecks nvidia didn't write me a driver =] 04:59 hecks ShadowNinja: interesting about gl3 and mesa 05:00 hecks now gl2 is good enough but 05:00 hecks if we can just go with gl3 then please let me know 05:01 hecks it doesn't matter for shaders in particular but it opens some possibilities elsewhere 05:02 ShadowNinja Jordach: There's MoltenVK/gfx-portability for Apple systems. Apple's deprecated OpenGL so having support for Metal even through a compatibility layer would be good as long as it's a fairly low-overhead layer. 05:03 hecks a well designed renderer shouldn't care; we ought to talk to the driver as little as possible anyway 05:04 hecks i mean less than 0.5% of the chatter we do now, seriously 05:08 ShadowNinja hecks: Well there's the lavapipe software renderer, but that's still kind of experimental... If you have an intel igpu there's also the ANV driver. I'm not too woried about Vulkan though, a good OpenGL renderer will get us 90% of the way there in the performance department. 05:09 ShadowNinja (also OpenGL is quite a bit easier to use, even if it does depend on a bunch of global mutable state) 05:09 hecks that is correct, vulkan is not necessary to reduce chatter; azdo techniques exist 05:10 hecks the advantage of vulkan comes from being able to thread the renderer, but a well saturated GL driver can get at least two threads busy 05:11 hecks also, vulkan capable hardware is pretty much always capable of compute, and that can further reduce cpu involvement 05:11 hecks let's see what GL3 actually gives us over GL2 05:12 hecks we get mapped buffers, but no persistent bit yet 05:12 hecks and guaranteed GS 05:12 hecks oh and transform feedback which can be used for gpu skinning 05:12 hecks more specifically gpu skinning that doesn't need hardcoding into the rendering shader 05:19 hecks oh but of course there's still android and gles 05:19 hecks we don't get the mesa excuse on that 05:28 hecks gl1 and gl2 like fallbacks must still exist so there's no reason to not do them on desktop too 05:51 hecks someone's telling me that gles1 is extinct in the wild, is this true? 05:56 hecks http://opengles.gpuinfo.org/ 05:56 hecks according to this it is 05:58 hecks i mean if this is true then machines that don't support at least GL2 don't really exist anymore 05:58 hecks except like 05:58 hecks windows machines with GPUs worse than radeon 9500 05:59 hecks unless you can just install mesa on windows 06:04 hecks i'll let you guys figure this all out; i'll be writing the shader api against gles2 in any case 09:23 celeron55 definitely start with gl2/gles2 so that android gets covered 09:23 celeron55 it might also help with some other obscure hardware that people want to run MT on 09:24 celeron55 even a web browser if someone's up for that madness 09:27 sfan5 our android stuff still runs with gles1 IIRC 10:15 pgimeno my opinion is drop GLES1 but not GL2 support, even if at the cost of disabling features 10:19 sfan5 we currently also support opengl without shaders, dropping that is another question 10:19 sfan5 there's probably nobody who can't use shaders but I wonder how many people disable them 10:23 celeron55 well i for sure know the laptop that i originally developed MT on won't run at reasonable speed with shaders 10:23 celeron55 it's an intel 945gm thing 10:24 celeron55 it can run a web browser and modern websites with a maxed out processor upgrade though, it's not entirely obsolete 10:25 celeron55 i think nobody would expect it to run any 3d game these days though 10:26 celeron55 i think most commonly you'd be looking at a thinkpad t60 if you wanted a 945gm machine 10:29 pgimeno but expect lots of complaints if you drop support for old hardware that you currently support 10:30 celeron55 worth a forum poll? 10:30 celeron55 "does your computer run MT with shaders at playable FPS and view range?" 10:31 celeron55 or more like "do you have to disable shaders for some reason? explain in a reply" 10:31 celeron55 this is a bit ridiculous though 10:33 pgimeno maybe "would you be affected if support for OpenGL older than 2.0 was dropped?" 10:33 celeron55 a 5.4 client will work fine enough until MT 6.0 is released and by that time there's been probably a year or more of time to get a better computer for free from some electronic recycling place 10:35 celeron55 and even while schools use old hardware, i believe even in relatively poor countries they've gotten rid of this level of hardware years ago, even if for no other reason than it doesn't last that long in heavy use 10:36 celeron55 this is my reasoning for why shaderless rendering can be dropped now 10:36 celeron55 without asking anyone 10:37 celeron55 if you look at the proprietary world, anything that can run a supported version of windows can run a gl2 program with a normal amount of shader use 10:41 pgimeno keep raspberry pi in mind too, I have an old Minetest installation in a RPi3 that drops FPS below 20 with shaders disabled 10:42 pgimeno I used it to test the CPU impact of the IMatrixTransform scene node PR 10:43 specing celeron55: you have a T60? 10:44 VanessaE I'm fine with shaderless rendering being dropped as long as the result works on, and doesn't melt-down my R9 280X ;) 10:44 specing I'm also fine with dropping support for potatos 10:45 VanessaE or at least, doesn't melt it down before I get the RX5500 I have my eye on :P 10:45 specing I need more games to stop supporting 7yo intel iGPU so I can justify getting a real gpu 10:45 celeron55 specing: no, i have a toughbook cf-51 10:45 celeron55 these days i mostly use it for car diagnostics and such 10:47 celeron55 specing: MT will definitely support a 7 year old intel GPU for a long time still 10:47 celeron55 945gm is a 15 year old intel gpu 10:47 specing celeron55: have you tried librebooting it? 10:47 celeron55 why? 10:48 specing why not/ 10:48 celeron55 is there a benefit of some kind 10:48 celeron55 it works and i would risk bricking it, doesn't seem worth it 10:48 specing libre init + grub secure boot 10:48 celeron55 it's not a shitty market laptop with a shitty bios 10:48 celeron55 so it's pretty good 10:50 celeron55 pgimeno: i believe rpi will be taken into account as long as android is taken into account 10:51 celeron55 they should have similar capability 10:52 celeron55 that being said, do you actually use MT on the rpi? 10:52 celeron55 it isn't worth supporting something just because you can 10:58 pgimeno I don't, but it's likely that some people do 11:05 VanessaE maybe Megaf still does ;) 11:06 VanessaE (ok to be fair, it was a server, not a client :P ) 11:17 sfan5 pgimeno: I'm sure rpi performance would be better if people used gles2 on it and not opengl 11:17 sfan5 distros ship the "desktop build" of MT 12:44 MTDiscord ShadowNinja OpenGL is still supported on M1 14:40 MTDiscord Asking only about our shader pipeline's performance isn't really fair to the technology as a whole, since many older games make use of one just fine on equivalent hardware. 14:47 rubenwardy the one caveat with removing DX is that it is used by people to get better performance on windows 14:47 rubenwardy but I'm generally in favour of removing all but gl and gl es 14:48 rubenwardy using raw opengl for shaders is fine though, we only support shaders in /OpenGL (ES)?/g anyway 15:02 MTDiscord Isn't it used not so much to get better performance as to get less predictable performance? From what I've heard it either doesn't work, or is at least very hit or miss. 15:02 MTDiscord How much of a perf gap are we talking about in the case of DX anyway? 15:03 MTDiscord DX never confirmed any sort of benefit 15:04 MTDiscord It was at a time where AMD had rather terrible OpenGL support and Nvidia shrugged it for DX11 15:04 MTDiscord More recent drivers have much less overhead than older ones when it comes to 2.1 15:05 MTDiscord This is due to Mesa providing a reference implementation that’s relatively efficient 15:05 MTDiscord And is freely implemented 15:06 MTDiscord Could always just disable it early in a development cycle and see if anybody freaks out XD 15:06 MTDiscord That said implementing VK would be dangerous as some platforms lack either the VK driver or software rendering for VK 15:11 MTDiscord We're constantly seeing issues with DX and I don't think anybody is actually able to fix them. We should kill DX support. 15:51 sfan5 d3d9 support is disabled in irrlichtmt 15:51 sfan5 so effectively it's already killed 18:50 v-rob Ha, D3D having better performance on Windows? I get 0 FPS different in OpenGL and D3D. 18:55 v-rob Maybe we could get better speed on Windows if we used a modern version of D3D with competent D3D programmers, but otherwise, no. 18:55 v-rob I say kill it 18:57 rubenwardy ?️ 18:59 kilbith another thing that ought be killed are the non-freetype fonts 18:59 kilbith bitmap fonts 18:59 kilbith totally useless 18:59 Krock D3D performed a few FPS better on my ancient OpenGL 1.4 card, but that's really a corner-case and to be ginored. 19:00 Krock and that might also only be caused due to some weird driver caveats or whatever. D3D does not need attendance. 19:02 Krock I'd like to disagree about the bitmap font one. It's implemented already, and does not seem to need any maintenance. It also brings some performance improvement to weak systems: https://github.com/minetest/minetest/pull/8641#issuecomment-507056996 19:03 Krock However I do not know whether this has changed a bit in the recent GUITTFont change 19:04 Krock looking at the code... it should have changed the situation for good, due to the batch image draw for colored text 19:49 kilbith Krock: you cannot design modern GUIs with bitmap fonts, thats' why 19:50 Krock that's the problem of the user to sacrifice that for performance 19:50 MTDiscord I mean, I feel like there are much, much bigger fish to fry for scaling MT down on slow platforms 19:51 kilbith how much of the performance would be impacted by using freetype fonts? 19:51 Krock there's the item serialization which is horribly slow 19:51 Krock kilbith: depends on the drawn text, see link above. however, it might be outdated already 19:51 kilbith and how old are these weak systems 19:51 Krock see also link above. 19:52 Krock Core 2 Quad is like 2008 I guess? 19:52 Krock feel free to do some up-to-date statistics with master. I'm sure the numbers differ less. 19:54 kilbith it's not even ecological to use a Core 2 Quad 19:54 MTDiscord I feel like Minetest needs to have a support baseline, slowest/cheapest kind of hardware its willing to maintain reasonable performance and compatibility for. 19:54 Krock @Benrob0329 Aside this bitmap font, the options are to disable smooth shadows, disable alpha textures, use 8px texture packs, and to reduce the draw distance 19:55 MTDiscord And undersampling 19:55 Krock and for the hacky part - disable z-buffer clearing, if there's anything. undersampling did not make a difference on the systems I tested 19:56 kilbith so there's actually people in the world that can afford buying a brand new $500 laptop every 5 years 19:56 Krock that being said - that's now how I think that Minetest should be used. however, the options are there for low-spec gamers 19:56 kilbith interesting 19:56 kilbith * can't 19:56 Krock *that's not how 19:58 MTDiscord I mean I've played MT on some pretty potato hardware ($250 laptop, Win7 era all-in-one, my old-ass phone) but there does come a point where it doesn't make sense to support it 19:59 MTDiscord Bitmap fonts are worth keeping if somebody is going to do something really artistic with them like designing a beautiful pixel-art font that fits in with the theme of a game ... but at that point, it may make as much sense just to bake the text right into formspec or background images. 20:00 MTDiscord Freetype can to "pixel-art" fonts just fine afaik 20:00 Krock vector graphics can do pixel art as well 20:00 MTDiscord I've played MT on a core 2 duo and an samsung tablet from 2012 so I'm no stranger to potatoesville but I don't think bitmap fonts are really big there either. 20:00 kilbith text as formspec images wouldn't be filtered very well 20:01 MTDiscord Basically I'm okay with keeping bitmap fonts so long as we're able to successfully forget that they exist, but if they're causing any cognitive load at all (like I guess this discussion) then that's a good argument for culling them from the herd. 20:02 MTDiscord Baking text into formspec images may well be an abomination (bad filtering, terrible accessibility and localization) but then probably so are bitmap fonts today... :-/ 20:03 Krock why are we discussing this at all? it's not even default or recommended in any way 20:03 MTDiscord From what I've seen scene complexity is one of the biggest factors (1 big mesh vs 100 small meshes, the 100 small meshes are what does it), but I don't have anything to back this up on its own. 20:04 kilbith shadows are not default too, yet we were in a hot debate whether to remove it or not 20:04 MTDiscord Wieldmeshes also turn out to be surprisingly terrible 20:04 MTDiscord apparently they're a big scene complexity contributor 20:05 MTDiscord well, I say "wieldmeshes" but the real problem is that it's just "wieldmesh" 20:05 MTDiscord Actually, come to find out it's not even the amount of geometry that is the biggest factor, having less geometry in some meshes using transparent textures resulted in measurably worse performance for me. 20:06 MTDiscord So I say complexity broadly here 20:07 MTDiscord Yeah, I've run into that "fewer triangles more transparency -> worse fps" situation myself 20:08 MTDiscord It'd be nice if there were an in-place fix for it, like an "oops we had the wrong configuration set" or something, because otherwise I can't really fix it without taking away creative freedom from texture pack authors by making custom meshes that make assumptions about texturing... 20:09 MTDiscord Assuming minetest_game PRs are ok here, 3-liner change: https://github.com/minetest/minetest_game/pull/2888 20:09 Krock yes this is the correct channel 20:11 hecks sup folks 20:12 hecks re some things in the logs; supporting gles2 is basically automatically supporting gl2 too 20:13 hecks and as for having a path without shaders, and people who disable shaders for performance - their drivers and cards might still be running shaders to emulate fixed function 20:13 hecks of course our shaderless path is so dirt simple that it won't cost a thing to keep it 20:14 MTDiscord I like the shaderless path in principle but I do worry that having to assume players may be using only fixed-function rendering could be rather restrictive on game design 20:15 MTDiscord for example it's pretty hard to make a really atmospheric game the way things are right now, and more rendering flexibility might help with that a lot 20:15 MTDiscord Once upon a time, the kinds of tricks people used to create really immersive atmospheres in fixed pipelines seemed clever but now they seem sort of unnecessarily hackish. 20:15 hecks that is true, but i have no opinion about this either way; i can work with the fullbright path 20:16 hecks if a shader and materials api exists, specifying fallback textures for said path migh become an option 20:16 hecks that is, textures where anything fancy is just baked in 20:16 MTDiscord Heh, I feel like Benrob is the best person to talk about creative flexibility in rendering pipelines maybe, because he's trying to make a game with a spooky otherworldly atmosphere AND explicitly support potato-spec systems... 20:17 hecks you can make a spooky game in basically a shaderless renderer, see silent hill on psx 20:17 hecks good texture work can carry anything 20:18 MTDiscord I personally run a laptop from 2012 so I do worry about rendering becoming inaccessible to me, but at the same time I don't feel like I'm in danger quite yet, and I can even use the shadows thing a little bit. 20:18 celeron55 it's probably easier to make a spooky game without shaders than try to imagine how to make it spooky with shaders... 20:18 MTDiscord I know that with artistic talent you CAN make nearly anything look good, but it'd be nice to put as little burden on the creators to do that the hard way as we can 20:18 hecks you are not in danger of being left out of a GL2.0 renderer unless your computer is older than the Radeon 9500 20:19 hecks anyway shaders are one thing; what i'd actually require if anything is VBOs 20:20 hecks that is, require at the very least glDrawElements 20:20 celeron55 VBOs are something even the 945gm supports and benefits somewhat from (not a lot though) 20:20 hecks yes, they're an absolutely ancient extension 20:20 celeron55 so it's a no brainer 20:20 MTDiscord c55: Depends, adding atmosphere to a game is usually something you do in steps rather than all at once. Modern gamedev is usually more about "what's the best way to do X" rather than "what can we do with Y" afaik 20:20 hecks i don't think anyone runs minetest with VBOs disabled ever 20:20 hecks it's on by default and nobody disables it for any reason 20:21 hecks there was like one reason to disable it in the past - when we were holding on to mapblock VBOs for too long and could run out of vram, this is fixed now 20:21 hecks the non-vbo path is atrociously slow anyway and nothing that needs this fallback can actually run it 20:22 hecks minetest throws around millions of primitives 20:22 MTDiscord Also, I don't do anything crazy (at least, I don't think I do) as of right now with my game, its all a process and I'm just trying to make use of what we've got. 20:22 celeron55 this is probably the only place in the universe where even the concept of rendering without VBOs is considered 20:22 MTDiscord If you want to know if anyone really uses something but don't want to start a huge debate about removing it, just introduce a bug that breaks it and see if anyone notices ... XD 20:22 celeron55 in 2021 20:23 hecks =] since mesa exists and gles1 is extinct in the wild, i don't think *anyone* needs a glBegin path 20:23 hecks absolutely no one 20:23 hecks i mean 20:23 hecks warr has a point 20:24 hecks let's make a 6.0-dev with no fallbacks and see if anyone even notices 20:24 hecks and handle people's weird setups as they pop up 20:25 hecks technically you can run minetest on something absolutely awful with a draw distance of 20 nodes 20:25 hecks but in that case a special renderer would actually be warranted, one that does not use mapblock meshing at all 20:25 hecks yeah in fact 20:25 hecks meshing is counter productive for a glBegin path 20:26 hecks so if we have to make a fallback for these machines (say any machine that can run quake 3), that's what i'd rather do 20:30 celeron55 i'm not so sure, i mean the 945gm is barely an upgrade from something that can run quake nicely 20:30 celeron55 and meshing with vbos was certainly necessary on it 20:30 hecks so in fact nothing that needs the fallback can run it? 20:31 celeron55 i'd say so 20:31 celeron55 i mean, the 945gm _is_ capable of distances of like 60 nodes without shaders 20:32 celeron55 something that can render just 20 nodes will have such a slow cpu you'd get depressed waiting for mapgen or anything 20:32 hecks skinning will kill it 20:32 hecks network serialization will kill it 20:33 hecks texture modifiers will kill it 20:33 hecks uhhh yeah a little bird is telling me that DrawElements is available on everything except SGI irix workstations 20:34 hecks so this is all moot 20:35 celeron55 well, this just went so far back into legacy computing it turned back into meaningful 20:36 celeron55 but whatever, while running MT on 90s crap is interesting, it's not a priority 20:36 hecks sega dreamcast MT client, who dares 20:37 celeron55 16MB RAM? ehm... 20:37 hecks :DDD 20:37 hecks client only ok? 20:37 specing celeron55: have you done any hardware survey to know what's up? 20:38 celeron55 no, and i won't. feel free to, though 20:38 hecks is it necessary? once again 20:38 celeron55 just ask here before actually running the survey so that we can check it actually asks something relevant 20:38 hecks anything outside of windows has at least software mesa (which runs pretty well) 20:39 hecks any mobile device has gles2 at least 20:39 sfan5 (you can build mesa for windows) 20:39 hecks you can, i'm just saying what people are likely to have installed 20:40 hecks and then on windows itself, how many people are still on pentium 2 tier hardware? how do they even run a web browser? 20:41 celeron55 well minetest windows builds haven't run on windows xp or older since probably 2012 when i stopped making visual studio 6 builds or something 20:41 celeron55 i don't even remember 20:41 hecks i guess you can use x86 mingw 20:42 hecks irrlicht itself *does* run on pentium 2 windows xp computers... i tried 20:42 celeron55 the pre-built zlib binary doesn't run on xp but i guess if you build custom versions of every library, maybe then 20:42 hecks but minetest would probably die for other reasons 20:42 hecks like ram 20:42 celeron55 well i mean 20:43 celeron55 it's easier to find a newer machine than a pentium 2 one 20:43 hecks true, actually, have you seen the prices on those "retro" parts lately? 20:43 hecks it's cheaper to build a ryzen 20:44 celeron55 when you look up the cheapest used computers these days those are something like core2duo 20:44 hecks the only remotely close thing i'm curious about is if minetest can run on ReactOS out of the box 20:44 hecks but that comes with mesa so it's not graphics that worry me 20:44 celeron55 those support gl2 even with integrated graphics 20:44 celeron55 ...i guess 20:45 hecks that's where the "can't compile for windows xp" thing could be a problem... but they'll sooner make NT6 compat a thing than we get around to fixing it 20:45 specing I doubt I'd have a great experience running minetest on my core2duo laptop 20:45 sfan5 I have seen a few machines in the serverlist logs that supposedly run MT 5.x on WinXP 20:46 hecks :o 20:46 hecks and besides, jesus, just install bsd at that point 20:46 sfan5 and I'm pretty sure the code that detects this is accurate 20:46 sfan5 but who knows how they did it 20:46 celeron55 i'm going to guess some builds happen to run on xp then 20:46 celeron55 i'm sure they haven't built it themselves 20:46 hecks do we have 32 bit mingw builds? it's probably that 20:47 sfan5 we do 20:47 celeron55 but... xp running a server means someone connected an xp machine to the internet and opened a port towards it 20:47 celeron55 that's an extreme sport 20:47 hecks haha 20:48 hecks for a server no less... install bsd? please? 20:49 MTDiscord "I too like to live dangerously" 20:49 MTDiscord motions to Win2k machine with Netscape trying to load Google 20:50 v-rob I don't understand this discussion... why are we seriously considering Pentium 2's? 20:50 celeron55 the coredev invite only server is going to run on windows me 20:50 v-rob Oh no please no 20:50 celeron55 once i get my fiber optic 20:50 MTDiscord Haha 20:51 MTDiscord My future videos will only be produced on XP-era Windows Movie Maker 20:52 v-rob All in favor of making Minetest's in-game content browser depend on IE6 with ActiveX say "aye" 20:53 * celeron55 has stopped working 20:53 v-rob Windows is checking for a solution to the problem... 20:54 MTDiscord Don't forget Blink Video 20:55 sfan5 Bink* 20:57 MTDiscord realizes young me had it wrong this whole time 21:34 pgimeno it would be nice if MT ran on ao486 21:45 hecks okay folks 21:46 hecks what do we do with shader compile failures? 21:46 hecks or more specifically, pass compile failures where the pass may be something like a shadow caster 21:47 hecks and just drawing the material in some "default" way won't suffice there - skip it for rendering? 21:49 celeron55 i guess the hope would be that some kind of descriptive error is available and the user could file an issue about it 21:50 hecks the error is emitted when a pass fails, like this 21:50 hecks https://paste.uguu.se/?520b31217893ded6#Es8nrZc4SemYf5A1iMm4TihiQjMRWpGABvaAKwuKWnLx 21:51 hecks together with the exact #define list that triggered the build failure; pass building bails out at the first failed variant 21:54 hecks oh right i think if you mess up something like the nodes shader now, nodes won't even be drawn, right? 21:55 hecks so skipping is the correct way 21:55 hecks for user defined shaders, if ever, some kind of fallback mechanism can exist, but not for the shaders MT comes with 21:57 celeron55 the goal of course for default shaders is to have them so simple they can't fail 21:57 hecks i guess 21:59 hecks output should look something like this https://paste.uguu.se/?900097496e725eaf#EkHpMoHPU1zK1Am3EjkvCmErbdyd733uBKbiaK43eVmL 22:10 MTDiscord I like the idea of crashing and erroring out on fail 22:11 MTDiscord trying to sweep a problem under the rug and just having silent failures leads to more confusion 22:11 MTDiscord I'd rather get a shader compile error message that I can ask about and be told that I'm running the wrong shader versions for the engine version than just log in and see everything be mysteriously black. 22:12 MTDiscord Having the interface be obviously painfully broken doesn't reduce the support issues we deal with, it just makes them harder to deal with. 22:13 MTDiscord and as a general rule, it's better to know when you screwed up and have to decide whether to sweep it under the rug after the fact than it is to just be oblivious to begin with...