| Time |
Nick |
Message |
| 00:10 |
|
v-rob joined #minetest |
| 00:37 |
|
Alias2 joined #minetest |
| 00:41 |
|
Guest93 joined #minetest |
| 00:53 |
|
ronoaldo joined #minetest |
| 00:58 |
Pexin |
am I correct that server lua cannot tell if a player is currently flying, only whether they have the priv? |
| 00:59 |
MTDiscord |
<Jonathon> there is no nice way to do it |
| 01:00 |
MTDiscord |
<Jonathon> but you can roughly calculate it |
| 01:00 |
MTDiscord |
<Jonathon> still glitchy |
| 01:01 |
Pexin |
just trying to find a good fix for nuke arrows. currently crashes if a player with fly priv takes damage from the blast |
| 01:02 |
Pexin |
i mean i fixed that part |
| 01:02 |
Pexin |
but it's not "supposed" to knockback a flying player |
| 01:02 |
Pexin |
welp TOO BAD i guess |
| 01:04 |
MTDiscord |
<Benrob0329> If their velocity is 0 and they're above the ground, don't knock them back? it's not perfect but that should mitigate most false positives |
| 01:04 |
Pexin |
nah i'll just call it wind velocity |
| 01:04 |
MTDiscord |
<Benrob0329> You can get a terrain heightmap for quick lookup on most mapgens too |
| 01:05 |
MTDiscord |
<Benrob0329> But just knocking back everyone is also a good, consistent fix :P |
| 01:05 |
MTDiscord |
<Benrob0329> The nuclear option, for sure, but not an unfounded one |
| 01:05 |
Pexin |
heh. heh heh. nuclear option. |
| 01:29 |
|
v-rob joined #minetest |
| 01:41 |
|
drewnix joined #minetest |
| 02:23 |
|
drewnix joined #minetest |
| 02:30 |
|
Guest93 joined #minetest |
| 02:42 |
|
drewnix joined #minetest |
| 02:51 |
|
grouinos joined #minetest |
| 02:59 |
|
Lunatrius` joined #minetest |
| 03:08 |
|
Jason232_ joined #minetest |
| 03:09 |
|
Sven_vB_ joined #minetest |
| 03:19 |
|
drewnix joined #minetest |
| 03:28 |
|
queria joined #minetest |
| 03:34 |
|
queria joined #minetest |
| 04:06 |
|
v-rob joined #minetest |
| 04:12 |
|
drewnix joined #minetest |
| 04:24 |
|
v-rob joined #minetest |
| 04:54 |
|
drewnix joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 05:01 |
|
Jason232 joined #minetest |
| 05:08 |
|
drewnix joined #minetest |
| 05:53 |
|
v-rob joined #minetest |
| 06:01 |
|
riff-IRC joined #minetest |
| 06:02 |
|
Pexin joined #minetest |
| 07:02 |
|
jvalleroy joined #minetest |
| 07:11 |
|
riff-IRC joined #minetest |
| 07:16 |
|
v-rob joined #minetest |
| 07:17 |
|
specing_ joined #minetest |
| 07:26 |
|
CWz joined #minetest |
| 07:31 |
|
v-rob joined #minetest |
| 07:41 |
|
riff-IRC joined #minetest |
| 07:45 |
|
olliy joined #minetest |
| 08:02 |
|
Jason232_ joined #minetest |
| 08:24 |
|
calcul0n joined #minetest |
| 08:32 |
|
nemo42 joined #minetest |
| 08:36 |
|
Sven_vB joined #minetest |
| 08:44 |
sfan5 |
Pexin: add_velocity() will not apply to players in fly mode |
| 09:17 |
|
basxto joined #minetest |
| 09:20 |
|
basxto joined #minetest |
| 09:40 |
|
proller joined #minetest |
| 10:10 |
|
Fixer joined #minetest |
| 10:27 |
|
Jason232 joined #minetest |
| 10:35 |
|
erlehmann joined #minetest |
| 10:49 |
|
Markow joined #minetest |
| 11:06 |
|
grouinos joined #minetest |
| 11:07 |
|
appguru joined #minetest |
| 11:19 |
|
HuguesRoss joined #minetest |
| 11:38 |
|
proller joined #minetest |
| 11:51 |
|
Flabb joined #minetest |
| 11:51 |
|
jvalleroy joined #minetest |
| 11:56 |
|
definitelya joined #minetest |
| 12:36 |
|
tech_exorcist joined #minetest |
| 12:50 |
|
definitelya_ joined #minetest |
| 12:53 |
|
jordan4ibanez joined #minetest |
| 13:06 |
|
drewnix joined #minetest |
| 13:20 |
|
GNUHacker joined #minetest |
| 14:19 |
|
drewnix joined #minetest |
| 14:20 |
|
kamdard joined #minetest |
| 14:46 |
|
drewnix joined #minetest |
| 15:05 |
|
proller joined #minetest |
| 15:26 |
|
nemo42 joined #minetest |
| 15:59 |
|
grouinos joined #minetest |
| 16:16 |
|
behalebabo joined #minetest |
| 16:18 |
|
LibreGNU joined #minetest |
| 16:22 |
|
behalebabo joined #minetest |
| 16:46 |
|
v-rob joined #minetest |
| 16:58 |
|
Yad joined #minetest |
| 17:27 |
|
Talkless joined #minetest |
| 17:59 |
beanzilla |
Anyone else getting technical difficulties when viewing a mod on ContentDB? |
| 17:59 |
|
unexploredtest[m joined #minetest |
| 17:59 |
MTDiscord |
<Warr1024> got a specific link? |
| 17:59 |
MTDiscord |
<Jonathon> any package |
| 18:00 |
MTDiscord |
<Warr1024> oof |
| 18:00 |
MTDiscord |
<rdococ> am also getting this problem |
| 18:00 |
beanzilla |
Just any package in general on contentdb |
| 18:00 |
MTDiscord |
<Warr1024> @rubenwardy musta broke something deploying a layout change...? |
| 18:02 |
erlehmann |
wsor4035 since this is a general game dev question i am going to ask here. you downvoted my issue on irrlichtmt: https://github.com/minetest/irrlicht/issues/94 could you please explain to me why exactly the code that was removed was removed? |
| 18:02 |
erlehmann |
because to me, the rule “do not do timer stuff across threads or cores” seems logical |
| 18:02 |
erlehmann |
i must be missing something about how stuff changed since 2007 or so |
| 18:03 |
MTDiscord |
<Warr1024> It sounds like a "burden of proof" disagreement. |
| 18:03 |
MTDiscord |
<Jonathon> i downvoted it because your being a ass about it and insisting it should be reverted if sfan5 doesnt do your own work for you |
| 18:04 |
MTDiscord |
<Warr1024> You are saying that the "burden of proof" is on the change, while it sounds like they're saying the burden is on the code to continue existing that way. |
| 18:05 |
erlehmann |
have you read the linked article and the irrlicht changelogs? i have and i have found only reason to believe that the code that was removed actually increases performance and reliability. |
| 18:05 |
MTDiscord |
<Warr1024> Can you demonstrate that using the actual code itself? |
| 18:05 |
erlehmann |
well, the code was removed? |
| 18:05 |
MTDiscord |
<Jonathon> your asking the person who reads basically everything if they read it lol |
| 18:06 |
MTDiscord |
<Warr1024> i.e. can you find some way to reproduce the problem that the code actually purports to fix? |
| 18:06 |
erlehmann |
oh, let me check |
| 18:06 |
MTDiscord |
<Warr1024> If the code removal was unjustified then it should create some kind of regression. |
| 18:07 |
MTDiscord |
<Warr1024> The way I see it, the burden of proof for justifying code's continued existence falls on the code itself, i.e. code must always have a reason for existing, and removal of code that has failed to demonstrate its relevance is always justifiable barring some actual counter-evidence. |
| 18:08 |
MTDiscord |
<Warr1024> Code removal can be excessively naive but that doesn't really rise to the level where it's "suspicious" in any way. |
| 18:09 |
erlehmann |
well this is suspicious because all documentation i have seen suggests that it creates problems to not do it |
| 18:09 |
erlehmann |
i am looking for a test case, wait 4 it |
| 18:10 |
erlehmann |
Warr1024 the way i see it, only tear down a fence if you know why it was built |
| 18:10 |
MTDiscord |
<Warr1024> I mean if you can find a smoking gun where the removal actually breaks something, then ... well then I guess we'll have that old argument about "what systems are actually supported anyway" for a bit ... but arguably you could justify the code going back in. |
| 18:12 |
MTDiscord |
<Warr1024> erlehmann, that kind of thinking is why projects end up just a labyrinth of fences that nobody can remember why they exist but nobody has the energy to actually try to tidy up. |
| 18:12 |
MTDiscord |
<Warr1024> If you don't know why it was built, tearing it down is often the simplest way to find out. |
| 18:12 |
erlehmann |
Warr1024 i think you misunderstand me. if all the documentation about timers says to do it one way and a project did it one way for >10 years and then someone removes the thing, that is the suspicious thing. |
| 18:13 |
erlehmann |
like there must be a reason |
| 18:13 |
erlehmann |
but the reason should not be “this looks useless” |
| 18:13 |
MTDiscord |
<Warr1024> The suspicious thing here is expecting a 10 year old hack to still be relevant |
| 18:14 |
beanzilla |
Looks like it's working (contentdb, on viewing a mod) |
| 18:14 |
erlehmann |
Warr1024 it is only a hack insofar that it fixes a thing that works fine on single core machines on multicore machines AFAIK. i mean, if your timing logic switches between cores, it's bound to be messed up, from my understanding. |
| 18:15 |
erlehmann |
i also see no review for this change |
| 18:15 |
MTDiscord |
<Jonathon> its irrlicht, not mte |
| 18:17 |
MTDiscord |
<Warr1024> If your timing logic switches between cores, it may be bound to be messed up. Or it might not, as a lot can have happened in 10 years. Given the choice between some documentation and reality, I'm inclined to trust reality ... but that requires you to actually ask reality. |
| 18:18 |
MTDiscord |
<Warr1024> I mean, it's already gotten you motivated to try to find out if this problem is really still relevant, so in a way it's already working great XD |
| 18:20 |
erlehmann |
it is not working great, since i have so far ONLY found information why this would be a problem |
| 18:20 |
erlehmann |
i have found info on timer changes in windows |
| 18:20 |
erlehmann |
but nothing that justifies removal of that code |
| 18:22 |
erlehmann |
https://stackoverflow.com/questions/44020619/queryperformancecounter-on-multi-core-processor-under-windows-10-behaves-erratic |
| 18:22 |
erlehmann |
> There is no promise that the timestamp counters of multiple CPUs on a single motherboard will be synchronized. Therefore, a program can get reliable results only by limiting itself to run on one specific CPU. |
| 18:24 |
MTDiscord |
<Warr1024> Is this something whose magnitude or likelihood of being noticeable may depend on multi-CPU vs. multi-core, i.e. for mobos with multiple sockets? |
| 18:25 |
erlehmann |
https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps |
| 18:25 |
MTDiscord |
<Warr1024> It really sounds like the kind of thing that might be a theoretical problem but is just never large enough in magnitude to actually per perceptible, especially for something like a game where immediate timing judder might matter a lot but long-term drift is much less noticeable. |
| 18:26 |
MTDiscord |
<Warr1024> Anyway, evidence that something might theoretically be needed is pretty weak justification for keeping it, and not having justification for keeping something IS justification for removing it. I've kept some code on weak justification like that before, but I always feel bad for being too lazy to actually try removing it and seeing what the consequences are. |
| 18:26 |
erlehmann |
as i understand, it is a thing for high resolution timers only. basically, if your CPUs have different frequency, depending on your BIOS and windows version, you will get different readings across cores. |
| 18:27 |
erlehmann |
well, all documentation i found says it to basically only use the function in the way that it was used before sfan5 changed it |
| 18:27 |
MTDiscord |
<Warr1024> Is this a Win32-specific thing? |
| 18:28 |
MTDiscord |
<Warr1024> Like does it not carry over to other OSs or to Win64? |
| 18:28 |
erlehmann |
> When you need time stamps with a resolution of 1 microsecond or better and you don't need the time stamps to be synchronized to an external time reference, choose QueryPerformanceCounter |
| 18:28 |
erlehmann |
well it is the win32 API |
| 18:29 |
erlehmann |
okay i understand it now |
| 18:30 |
erlehmann |
i think the code that sfan5 deleted made sure that on win32 systems where the processors might not be synchronized for timing purposes, switching over between cores does not mess up the timing |
| 18:31 |
MTDiscord |
<Warr1024> I mean I guess it depends on what you mean by "timing", as well as "how messed up." |
| 18:31 |
erlehmann |
we are talking 1 microsecond or better |
| 18:31 |
MTDiscord |
<Warr1024> I sort of doubt that anything that relies on microsecond precisions is gonna work very well anywhere in the MTverse. |
| 18:32 |
erlehmann |
uh |
| 18:32 |
MTDiscord |
<Warr1024> yeah, uh |
| 18:33 |
erlehmann |
i have not been able to find a list of such systems, but a lot of ppl claim that this is a windows only thing. like on linux, counters don't do weird stuff. |
| 18:33 |
erlehmann |
oh, additionally, some systems deviate from the official documentation, i.e. different cores will get different timing. |
| 18:35 |
MTDiscord |
<Warr1024> MT already runs so poorly and inconsistently on Windows in general I'd be surprised if this makes a tangible difference. |
| 18:35 |
MTDiscord |
<Warr1024> And if this doesn't carry over to Win64 then it's gotta have a pretty niche audience by now. Windows is not exactly the poster child for getting the most out of older hardware. |
| 18:36 |
erlehmann |
i think to find a test case, one would have to have a system where different cores can have different frequencies and then run minetest on it |
| 18:36 |
erlehmann |
but a windows system. wine does not cut it. the timers work differently. |
| 18:36 |
|
___nick___ joined #minetest |
| 18:38 |
erlehmann |
Warr1024 i do not think “minetest runs badly on windows” is a good justification to make it worse |
| 18:39 |
erlehmann |
https://docs.microsoft.com/en-US/troubleshoot/windows-server/performance/programs-queryperformancecounter-function-perform-poorly |
| 18:39 |
erlehmann |
> Applies to: Windows Server 2012 R2, Windows 10 - all editions |
| 18:40 |
erlehmann |
> Multi-core or multiprocessor systems may encounter Time Stamp Counter (TSC) drift when the time between different cores is not synchronized. |
| 18:40 |
erlehmann |
oh lol |
| 18:40 |
|
JordanL2 joined #minetest |
| 18:40 |
erlehmann |
Warr1024 this is funny |
| 18:42 |
MTDiscord |
<Warr1024> I don't think we should make it worse. I think we should either make it better, or drop support. |
| 18:42 |
MTDiscord |
<savilli> irrlicht timer desync is the last minetest problem we should deal with |
| 18:42 |
MTDiscord |
<Warr1024> It's also not really in scope for MTE or MTIrr to fix OS bugs. |
| 18:43 |
MTDiscord |
<savilli> we have the same code in the engine where the timer really matters |
| 18:43 |
MTDiscord |
<Warr1024> Our duty to work around such issues may be limited. |
| 18:44 |
erlehmann |
<Warr1024> I don't think we should make it worse. I think we should either make it better, or drop support. |
| 18:44 |
MTDiscord |
<savilli> the timer can have desync between processor cores for sure, but the probability is too small to care about it in projects like minetest |
| 18:45 |
erlehmann |
drop support for windows? |
| 18:45 |
MTDiscord |
<savilli> we don't make nuclear reactors after all |
| 18:45 |
erlehmann |
savilli it seems to depend on the hardware. also that is a really bad argument to REMOVE code that handled that case. |
| 18:45 |
MTDiscord |
<Warr1024> Drop support for Windows? Maybe some of them. |
| 18:46 |
erlehmann |
http://oliveryang.net/2015/09/pitfalls-of-TSC-usage/#31-tsc-unstable-hardware |
| 18:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/31 -- GUI Tooltips |
| 18:46 |
MTDiscord |
<Warr1024> I would certainly drop support for the ones Microsoft has at least. I wonder how much Win32 that would leave... |
| 18:46 |
MTDiscord |
<savilli> i don't think it depends on the hardware |
| 18:46 |
MTDiscord |
<Warr1024> thank you shadowbot that was very helpful |
| 18:46 |
MTDiscord |
<savilli> maybe if your hardware is broken, then for sure |
| 18:47 |
|
BuckarooBanzai joined #minetest |
| 18:47 |
MTDiscord |
<Warr1024> RDTSC was pretty cool back in like the Pentium 2 days, but it seems weird to use it across thread preemptions, let along core affinity switches. |
| 18:49 |
MTDiscord |
<savilli> also, compared to hypothetical desync problem, the code causes performance problem with 100% probability, so removal is pretty justified for me |
| 18:49 |
erlehmann |
okay so if i am not mistaken, linux does A LOT to prevent the problems inherent in desyncing timers |
| 18:49 |
MTDiscord |
<savilli> not a lot |
| 18:49 |
erlehmann |
windows does not, it just says pls set affinity to 1 core |
| 18:49 |
MTDiscord |
<savilli> it trusts the hardware pretty much |
| 18:50 |
erlehmann |
not at all https://github.com/torvalds/linux/blob/master/arch/x86/kernel/tsc_sync.c |
| 18:50 |
erlehmann |
here you have a test case where it checks if time is going backwards |
| 18:51 |
erlehmann |
* We take the global lock, measure TSC, save the |
| 18:51 |
erlehmann |
* previous TSC that was measured (possibly on |
| 18:51 |
erlehmann |
* another CPU) and update the previous TSC timestamp. |
| 18:52 |
MTDiscord |
<savilli> it's not relevant |
| 18:52 |
erlehmann |
“compared to hypothetical desync problem, the code causes performance problem with 100% probability” – this is a good start. what is the performance problem? |
| 18:52 |
MTDiscord |
<savilli> thread rescheduling |
| 18:53 |
erlehmann |
please elaborate. |
| 18:55 |
MTDiscord |
<savilli> if the thread is running on cpu 2, and we force it to run only on cpu 1, it has to reschedule |
| 18:55 |
MTDiscord |
<savilli> if cpu 1 is busy with another task, we have to wait |
| 18:55 |
erlehmann |
oh nice |
| 18:56 |
erlehmann |
i do actually have a system where 2 CPUs have a timing problem |
| 18:56 |
erlehmann |
i am writing from it right now |
| 18:56 |
erlehmann |
i do run linux on it though |
| 18:56 |
MTDiscord |
<savilli> looks too easy |
| 18:57 |
MTDiscord |
<savilli> are you sure you measured everything right |
| 18:57 |
erlehmann |
[ 0.351568] TSC synchronization [CPU#0 -> CPU#1]: |
| 18:57 |
erlehmann |
[ 0.351568] Measured 521224 cycles TSC warp between CPUs, turning off TSC clock. |
| 18:58 |
erlehmann |
kinda a big value lol |
| 18:58 |
|
Guest99 joined #minetest |
| 18:59 |
MTDiscord |
<savilli> do you have intel turbo boost or some intel shit enabled? |
| 18:59 |
|
Guest99 joined #minetest |
| 19:00 |
erlehmann |
i have some intel shit processor, so what is turbo boost? |
| 19:00 |
erlehmann |
the best thing about this |
| 19:00 |
erlehmann |
the processor claims to have constant TSC |
| 19:00 |
erlehmann |
so the processors should tick the same |
| 19:00 |
erlehmann |
and i STILL get a delta |
| 19:01 |
|
GNUHacker left #minetest |
| 19:01 |
MTDiscord |
<savilli> https://askubuntu.com/questions/619875/disabling-intel-turbo-boost-in-ubuntu |
| 19:01 |
MTDiscord |
<savilli> oh wait, you can't remeasure |
| 19:04 |
|
___nick___ joined #minetest |
| 19:05 |
erlehmann |
savilli i do not get it, what is the issue with turbo boost? |
| 19:06 |
|
___nick___ joined #minetest |
| 19:06 |
erlehmann |
constant TSC should mean that frequency does not matter |
| 19:07 |
MTDiscord |
<savilli> it messes with CPU frequency and potentially with TSC |
| 19:08 |
erlehmann |
well, my tsc is already messed up |
| 19:08 |
MTDiscord |
<savilli> maybe bc of turbo boost |
| 19:09 |
erlehmann |
i am done with this. if you have anything about the commit, please comment on the issue: https://github.com/minetest/irrlicht/issues/94#issuecomment-1021517079 |
| 19:10 |
MTDiscord |
<savilli> you didn't do anything tho :} |
| 19:10 |
MTDiscord |
<Warr1024> TSC was intended to measure the number of clock cycles that a CPU has counted. It's not supposed to actually measure anything correlated with wall-clock time, it just happened to be introduced in a time when CPU frequencies were generally fixed and thus people started to depend on it for that. |
| 19:13 |
|
garywhite joined #minetest |
| 19:13 |
|
garywhite joined #minetest |
| 19:13 |
erlehmann |
savilli hot burn |
| 19:15 |
|
tech_exorcist joined #minetest |
| 19:15 |
MTDiscord |
<savilli> i actually would like to see CLOCK_MONOTONIC desync on linux |
| 19:15 |
MTDiscord |
<savilli> or QueryPerformanceCounter desync on windows |
| 19:18 |
|
specing joined #minetest |
| 19:21 |
|
v-rob joined #minetest |
| 19:35 |
erlehmann |
savilli the timestamps are guaranteed monotonic only on the same core |
| 19:36 |
|
Jason232 joined #minetest |
| 19:42 |
MTDiscord |
<savilli> prove it |
| 19:44 |
erlehmann |
please show me the code that you would think does that |
| 19:46 |
MTDiscord |
<savilli> does what? |
| 19:49 |
sfan5 |
prove it obviously |
| 19:50 |
MTDiscord |
<savilli> I don't need to. I believe it won't cause problems for minetest |
| 19:54 |
|
Jason232 joined #minetest |
| 20:06 |
|
proller joined #minetest |
| 20:08 |
|
nemo42 joined #minetest |
| 20:11 |
jordan4ibanez |
Quite random, does anyone know what happened to Linux MultiMedia Studio's website? |
| 20:12 |
jordan4ibanez |
Nevermind it showed up :T |
| 20:23 |
|
kamdard joined #minetest |
| 20:41 |
|
v-rob joined #minetest |
| 21:18 |
rubenwardy |
ContentDB now supports YouTube embeds, click Edit > Video URL to set it |
| 21:19 |
rubenwardy |
I've updated all mods that mentioned a YouTube URL in their desc to use this |
| 21:19 |
rubenwardy |
Support for other hosts coming soon :tm: |
| 21:19 |
rubenwardy |
well, I might just link to them |
| 21:21 |
rubenwardy |
(the embed doesn't load until you click the icon, for privacy/antitracking reasons) |
| 21:35 |
|
Oksanaa joined #minetest |
| 21:38 |
erlehmann |
rubenwardy is it possible to maybe automatically replace it with a link to an advertising-free youtube frontend, like https://tube.cadence.moe? those usually load the video from google servers, but are not only ad-free, but also much lighter on processors, due to barely using any javascript. |
| 21:40 |
erlehmann |
can texture packs be used on the player character? a friend of mine is trying to work around the camera-in-head bug on the reform2 |
| 21:42 |
rubenwardy |
surely there's a plugin that converts youtube embeds to that |
| 21:44 |
rubenwardy |
the following script is used to convert the links into embeds: https://github.com/minetest/contentdb/blob/master/app/public/static/video_embed.js |
| 21:46 |
rubenwardy |
if you want to do anything custom, you can use greasemonkey in a similar way or block that script |
| 21:51 |
|
definitelya joined #minetest |
| 21:56 |
|
Jason232_ joined #minetest |
| 22:05 |
|
v-rob joined #minetest |
| 22:16 |
rubenwardy |
ContentDB now lets you link to other video websites, but won't show in an embed |
| 22:21 |
HuguesRoss |
> can texture packs be used on the player character? |
| 22:21 |
HuguesRoss |
Depends on how the character was textured, but there's nothing that prevents it on the engine-side. If the character's texture is not dynamic media you should be able to replace the corresponding file and have it work out of the box |
| 22:22 |
|
Markow joined #minetest |
| 22:22 |
HuguesRoss |
There's no way to specifically apply overrides to players / entities right now though, so if it's skinned with something generated or sent outside of the initial loading process then you're out of luck |
| 22:22 |
erlehmann |
thx |
| 22:31 |
|
jordan4ibanez joined #minetest |
| 22:40 |
erlehmann |
HuguesRoss https://github.com/minetest/minetest/issues/11987#issuecomment-1021676043 |
| 22:43 |
HuguesRoss |
Huh, odd. I guess for some reason backface culling doesn't work in that instance or something? |
| 22:44 |
HuguesRoss |
Another possible hack, I wonder if you could increase the camera min distance to fix that. Not sure what it'd do to the game world itself though |
| 22:44 |
erlehmann |
i think it used to work |
| 22:44 |
erlehmann |
are you saying the camera is always located there? |
| 22:44 |
HuguesRoss |
Well, in first person it clearly is |
| 22:44 |
MTDiscord |
<Jonathon> it seems no one has even verified if opengl vs direct3d is being used |
| 22:45 |
HuguesRoss |
I don't know too much about how the engine handles the player camera sadly, it's a part of the code I haven't touched |
| 22:45 |
erlehmann |
Jonathon how are you even going to use direct3d on a recent linux computer with a 64 bit arm processor |
| 22:45 |
erlehmann |
this is opengl |
| 22:45 |
erlehmann |
look at the screenshot, it says opengl |
| 22:45 |
MTDiscord |
<Jonathon> https://github.com/minetest/minetest/issues/11987#issuecomment-1020719528 |
| 22:46 |
sfan5 |
why is your screenshot from 5.4 when the description says master? |
| 22:46 |
erlehmann |
because i replicated it recently |
| 22:46 |
erlehmann |
and the screenshot was provided by someone else |
| 22:46 |
erlehmann |
the guy who makes the laptop |
| 22:46 |
sfan5 |
not that I don't believe that it's in 5.5, just wondering |
| 22:46 |
MTDiscord |
<Jonathon> also should update your comment |
| 22:46 |
HuguesRoss |
I guess the first thing to check would be what shader changes occured since 5.3 |
| 22:47 |
erlehmann |
i have given my reform to a friend to help with the system image review |
| 22:47 |
erlehmann |
so i can not debug it right now |
| 22:47 |
erlehmann |
but i can assure you that it happens in whatever was current around new year |
| 22:47 |
erlehmann |
like 3 weeks ago or so |
| 22:47 |
HuguesRoss |
I think irlichtmt wasn't released for 5.4 right? So unless I'm misremembering it'd be something before that |
| 22:47 |
erlehmann |
yep |
| 22:48 |
erlehmann |
5.4.1 was the last irrlicht release |
| 22:48 |
HuguesRoss |
good, that narrows things down! |
| 22:55 |
MinetestBot |
[git] Dragonop -> minetest/minetest: Translated using Weblate (Spanish) c3a82b9 https://github.com/minetest/minetest/commit/c3a82b9a49aa91f6d9ef2ac5d0737994482f398b (2022-01-25T22:05:56Z) |
| 22:55 |
MinetestBot |
[git] AFCMS -> minetest/minetest: Translated using Weblate (French) d9caa1b https://github.com/minetest/minetest/commit/d9caa1bd481a3c947628f3d35e5ef9550c043b52 (2022-01-25T22:05:56Z) |
| 22:55 |
MinetestBot |
[git] srifqi -> minetest/minetest: Translated using Weblate (Indonesian) d4746b3 https://github.com/minetest/minetest/commit/d4746b349de550ccfa37dc8435e4edd5e66a6f7b (2022-01-25T22:05:57Z) |
| 22:55 |
MinetestBot |
[git] DandelionSprout -> minetest/minetest: Translated using Weblate (Norwegian Bokmål) 1a98351 https://github.com/minetest/minetest/commit/1a98351212cc3c443ce3e4030e415326be91b508 (2022-01-25T22:05:57Z) |
| 22:55 |
MinetestBot |
[git] rudzik8 -> minetest/minetest: Translated using Weblate (Russian) 620ba51 https://github.com/minetest/minetest/commit/620ba513756c40a82699211fb9f9c2c341cae0d1 (2022-01-25T22:05:57Z) |
| 22:55 |
MinetestBot |
[git] mnh48 -> minetest/minetest: Translated using Weblate (Malay (Jawi)) c6f3dcc https://github.com/minetest/minetest/commit/c6f3dcc0096bc71eeb23daddf143da23ebd72ddf (2022-01-25T22:05:57Z) |
| 22:55 |
MinetestBot |
[git] (14 newer commits not shown) |
| 23:00 |
|
proller joined #minetest |
| 23:00 |
erlehmann |
HuguesRoss any idea how to figure out what it is? |
| 23:00 |
|
Sven_vB joined #minetest |
| 23:02 |
HuguesRoss |
Without hardware to test on, it's gonna be tough for me to do much. But personally I'd start by looking at changes to shaders and graphics code in clinet. It looks like a few months before 5.4 released there were several commits related to the graphics, including what looks to be a moderately-sized cleanup/partial refactor |
| 23:03 |
HuguesRoss |
I don't think renderdoc will work with MT iirc, so most likely it's going to come down to reading diffs and testing with specific modifs reverted if/when you can get the machine back |
| 23:03 |
HuguesRoss |
I will try to look a little as well, but no promises |
| 23:03 |
erlehmann |
if you can tell me promising commits, i can forward those to someone who has a reform rn |
| 23:04 |
HuguesRoss |
You mentioned it's an ARM device right? Do you know if it uses GLES? |
| 23:05 |
HuguesRoss |
Oh wait, the issue mentions Opengl 2.1 so probably not |
| 23:16 |
|
reddit89_ joined #minetest |
| 23:17 |
|
proller joined #minetest |
| 23:19 |
HuguesRoss |
erlehmann I just saw something interesting. No idea if it's related but it seems like an avenue to check: https://github.com/minetest/minetest/issues/10525 |
| 23:32 |
|
Sven_vB_ joined #minetest |
