Minetest logo

IRC log for #minetest-dev, 2021-06-26

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:04 Extex joined #minetest-dev
02:01 v-rob joined #minetest-dev
02:03 v-rob joined #minetest-dev
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 kilbith joined #minetest-dev
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 <Jonathon> 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:25 queria joined #minetest-dev
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
02:57 v-rob joined #minetest-dev
03:26 kilbith_ joined #minetest-dev
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:08 kilbith__ joined #minetest-dev
04:30 MTDiscord <Jordach> Vulkan entirely deprecates the entire iOS and Mac platforms which we currently support
04:35 tekakutli joined #minetest-dev
04:45 hecks joined #minetest-dev
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 YuGiOhJCJ joined #minetest-dev
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
07:35 specing_ joined #minetest-dev
08:02 tech_exorcist joined #minetest-dev
08:05 tech_exorcist joined #minetest-dev
08:18 tech_exorcist joined #minetest-dev
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
09:29 entuland joined #minetest-dev
09:48 calcul0n_ joined #minetest-dev
09:48 Fixer joined #minetest-dev
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 Thomas-S joined #minetest-dev
10:23 Thomas-S joined #minetest-dev
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 Fixer_ joined #minetest-dev
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:35 twoelk joined #minetest-dev
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
11:24 calcul0n__ joined #minetest-dev
11:43 basxto joined #minetest-dev
11:53 behalebabo joined #minetest-dev
12:44 MTDiscord <Jordach> ShadowNinja OpenGL is still supported on M1
12:46 Thomas-S joined #minetest-dev
12:46 Thomas-S joined #minetest-dev
14:35 Thomas-S joined #minetest-dev
14:35 Thomas-S joined #minetest-dev
14:38 basxto joined #minetest-dev
14:40 MTDiscord <Benrob0329> 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 <Warr1024> 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 <Warr1024> How much of a perf gap are we talking about in the case of DX anyway?
15:03 MTDiscord <Jordach> DX never confirmed any sort of benefit
15:04 MTDiscord <Jordach> It was at a time where AMD had rather terrible OpenGL support and Nvidia shrugged it for DX11
15:04 MTDiscord <Jordach> More recent drivers have much less overhead than older ones when it comes to 2.1
15:05 MTDiscord <Jordach> This is due to Mesa providing a reference implementation that’s relatively efficient
15:05 MTDiscord <Jordach> And is freely implemented
15:06 MTDiscord <Warr1024> Could always just disable it early in a development cycle and see if anybody freaks out XD
15:06 MTDiscord <Jordach> That said implementing VK would be dangerous as some platforms lack either the VK driver or software rendering for VK
15:11 MTDiscord <appguru> 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:18 kilbith__ joined #minetest-dev
15:39 calcul0n joined #minetest-dev
15:49 Wuzzy joined #minetest-dev
15:51 sfan5 d3d9 support is disabled in irrlichtmt
15:51 sfan5 so effectively it's already killed
15:53 kilbith__ joined #minetest-dev
15:54 Extex joined #minetest-dev
16:16 Extex joined #minetest-dev
18:21 calcul0n joined #minetest-dev
18:31 kilbith joined #minetest-dev
18:32 v-rob joined #minetest-dev
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:35 specing_ joined #minetest-dev
19:49 kilbith joined #minetest-dev
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 <Benrob0329> 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 <Benrob0329> 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 <Benrob0329> 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 <Benrob0329> 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 <Warr1024> 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 <Benrob0329> Freetype can to "pixel-art" fonts just fine afaik
20:00 Krock vector graphics can do pixel art as well
20:00 MTDiscord <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 hecks joined #minetest-dev
20:03 MTDiscord <Benrob0329> 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 <Warr1024> Wieldmeshes also turn out to be surprisingly terrible
20:04 MTDiscord <Warr1024> apparently they're a big scene complexity contributor
20:05 MTDiscord <Warr1024> well, I say "wieldmeshes" but the real problem is that it's just "wieldmesh"
20:05 MTDiscord <Benrob0329> 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 <Benrob0329> So I say complexity broadly here
20:07 MTDiscord <Warr1024> Yeah, I've run into that "fewer triangles more transparency -> worse fps" situation myself
20:08 MTDiscord <Warr1024> 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 <Lone_Wolf> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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:16 Extex joined #minetest-dev
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 <Warr1024> 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 <Warr1024> 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 <Benrob0329> 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 kilbith joined #minetest-dev
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 <Benrob0329> 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 <Warr1024> 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 <Benrob0329> "I too like to live dangerously"
20:49 MTDiscord <Benrob0329> 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 <Benrob0329> Haha
20:51 MTDiscord <Benrob0329> 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:53 tech_exorcist joined #minetest-dev
20:54 MTDiscord <Benrob0329> Don't forget Blink Video
20:55 sfan5 Bink*
20:57 MTDiscord <Benrob0329> realizes young me had it wrong this whole time
21:14 v-rob joined #minetest-dev
21:34 pgimeno it would be nice if MT ran on ao486 </troll>
21:42 behalebabo joined #minetest-dev
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:53 v-rob joined #minetest-dev
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 <Warr1024> I like the idea of crashing and erroring out on fail
22:11 MTDiscord <Warr1024> trying to sweep a problem under the rug and just having silent failures leads to more confusion
22:11 MTDiscord <Warr1024> 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 <Warr1024> 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 <Warr1024> 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...
22:16 behalebabo joined #minetest-dev
22:54 x2048 joined #minetest-dev
22:54 x2048 left #minetest-dev
23:47 T4im joined #minetest-dev
23:56 AliasAlreadyTake joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext