| 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 |
