| Time |
Nick |
Message |
| 01:04 |
|
sugarbeet joined #minetest-dev |
| 01:59 |
|
Noisytoot joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 06:06 |
|
calcul0n_ joined #minetest-dev |
| 06:56 |
|
Fleckenstein joined #minetest-dev |
| 10:11 |
|
appguru joined #minetest-dev |
| 11:18 |
|
olliy1or joined #minetest-dev |
| 11:55 |
|
calcul0n_ joined #minetest-dev |
| 13:53 |
|
appguru joined #minetest-dev |
| 14:12 |
|
[MTMatrix] joined #minetest-dev |
| 14:41 |
|
appguru joined #minetest-dev |
| 14:49 |
|
grorp joined #minetest-dev |
| 16:03 |
|
calcul0n_ joined #minetest-dev |
| 16:30 |
jonadab |
"Implemented in C" is the only sense in which I can think of lua as C-based. |
| 16:30 |
jonadab |
And let's be honest, _most_ programming languages are implemented in C. |
| 16:30 |
jonadab |
And almost all of the rest, are self-hosting. |
| 16:32 |
MTDiscord |
<luatic> Well, Lua being implemented in C does also manifest in the design of Lua, esp. the standard library, which is in large parts just a Lua wrapper around the C standard library whereas many other languages that don't value portability as much go the extra mile to write much more platform-specific stdlib code. |
| 16:55 |
jonadab |
Higher-level languages typically have a lot of the stuff the C standard library does, as native built-in functions or whatever. |
| 16:56 |
jonadab |
But lua was designed to be lightweight because it's intended to be embedded in other applications. |
| 16:56 |
jonadab |
Similar to rep. |
| 16:57 |
celeron55 |
most computers are basically designed for C, thus C-based, from processors to keyboards, and everything in between |
| 16:57 |
celeron55 |
just due to the history that is built into everything |
| 16:58 |
jonadab |
I mean, by that logic you could say that computers are designed to run Unix. |
| 16:58 |
celeron55 |
that goes with the C thing |
| 16:58 |
jonadab |
I suppose. |
| 16:59 |
|
grorp left #minetest-dev |
| 16:59 |
celeron55 |
once you get into machines and environments not designed for C, you feel it. it's entirely different, and not many practically exist |
| 16:59 |
erle |
celeron55 which ones do you have in mind? |
| 17:00 |
celeron55 |
of course arguably this is stretching it a bit |
| 17:00 |
erle |
lisp machines? |
| 17:00 |
erle |
the colorforth processors? |
| 17:00 |
celeron55 |
maybe something like smalltalk or APL |
| 17:01 |
celeron55 |
not sure |
| 17:02 |
celeron55 |
certainly lisp machines |
| 17:04 |
erle |
should we take this to #minetest maybe |
| 17:25 |
|
MTDiscord1 joined #minetest-dev |
| 18:05 |
[MTMatrix] |
<localhost> position locker, it works... https://git.phreedom.club/localhost_frssoft/fediauth/src/branch/master/join.lua#L205 |
| 18:12 |
|
shangul joined #minetest-dev |
| 18:34 |
nrz_ |
Hello, merging #13847 |
| 18:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/13847 -- doc: fix improper code blocks parsing for lua_api_deploy by using pymdown-extensions by corpserot |
| 18:36 |
nrz_ |
sfan5, i merge irr#245 which is whitespace only. I don't know why ci link build fail, but it's not related to the PR, let's move forward on this huge topic |
| 18:36 |
ShadowBot |
https://github.com/minetest/irrlicht/issues/245 -- Cleanup line endings by numberZero |
| 18:40 |
|
habeangur joined #minetest-dev |
| 18:42 |
sfan5 |
every existing PR will now need to be rebased |
| 18:44 |
Krock |
dear god |
| 18:44 |
sfan5 |
(which is like 5 or 6 but still bad) |
| 18:45 |
sfan5 |
also we cannot merge upstream changes anymore |
| 18:45 |
Krock |
wasn't it possible to wait a day to at least give a chance for feedback? |
| 18:47 |
Krock |
I suppose this was done in regard to the irrlicht merge into Minetest, though. |
| 18:54 |
|
grorp joined #minetest-dev |
| 19:00 |
nrz_ |
i thought it was validated we moved forward on this topic my bad. What's the goal on the irrlicht repo ? merge all current PR then merge code in MT ? or freeze PR, (they can be reopened after merge if useful, it's not a big deal) |
| 19:01 |
nrz_ |
github doesn't say it require rebase , whitespaces are pretty properly handled by git |
| 19:02 |
nrz_ |
hard question about the render, we continue to maintain this irrlicht version or at a moment we try a big bang to another solution, like godot or something ? |
| 19:02 |
sfan5 |
https://github.com/minetest/irrlicht/pull/243 this one does |
| 19:02 |
sfan5 |
anyway I don't think the full path before merging irrlicht has been decided yet |
| 19:02 |
|
shangul joined #minetest-dev |
| 19:03 |
nrz_ |
tbh we talked about this for months, i now some "mature" OSS tools have some lag on some important decisions. Do we have some issues remaining before the merge ? |
| 19:03 |
nrz_ |
(i saw that irrlichtmt doesn't build on the whitespace PR on mingw for example) |
| 19:04 |
sfan5 |
https://github.com/minetest/irrlicht/issues/107 |
| 19:04 |
sfan5 |
and there's also open bugs with sdl2 |
| 19:04 |
nrz_ |
understood, but it's not related to the code merge in MT |
| 19:05 |
|
shangul joined #minetest-dev |
| 19:05 |
nrz_ |
there is not much remaining point in your roadmap, and they can be merged as a section in MT roadmap no ? |
| 19:06 |
|
shangul joined #minetest-dev |
| 19:07 |
nrz_ |
oh there is my started work on the IRR_DEFINE which may block yeah |
| 19:08 |
nrz_ |
it's i think the most blocking part to merge both, other are just cpp, this one is the build system |
| 19:08 |
sfan5 |
I'd like to get as many intrusive changes as possible done before the import |
| 19:08 |
sfan5 |
(because importing and then changing everything again clutters git history) |
| 19:09 |
nrz_ |
which change are your refering about, in the previous list ? |
| 19:10 |
nrz_ |
because, for example the interface removal is huge, but can be done over time. Interfaces are pretty nice if properly used (irrlicht used a bit too much i think) |
| 19:10 |
|
Desour joined #minetest-dev |
| 19:12 |
MTDiscord |
<josiah_wi> Does this mean getting upstream help for the glTF loader is now no longer possible? |
| 19:16 |
sfan5 |
" Remove compressed color formats" for example |
| 19:16 |
sfan5 |
or "Drop anything but SDL2" |
| 19:16 |
sfan5 |
every line of code we don't have to copy into MT is a win |
| 19:18 |
nrz_ |
for the color format what's the point, code removal sound too simple, i may miss something |
| 19:18 |
nrz_ |
why do we want to remove that ? there is no side effect ? |
| 19:21 |
sfan5 |
why do you want to keep unused code? |
| 19:27 |
nrz_ |
if it's unused why we don't have removed it yet ? ๐ |
| 19:27 |
nrz_ |
if it's unused i'm totally with you, i just don't understand this point in the roadmap, it sounds simpler than the build system itself which requires a bit rework on those shit includes |
| 19:30 |
sfan5 |
it's indeed unused, I just haven't had time to do this yet |
| 19:31 |
sfan5 |
in case someone is worrying about future usage: I did ask x2048 about this and he said that it won't be useful to have even in the future |
| 19:33 |
erle |
nrz_ you can look at the tradeoffs yourself https://www.khronos.org/opengl/wiki/S3_Texture_Compression |
| 19:33 |
erle |
nrz_ basically you have the option to sacrifice texture accuracy for memory bandwith |
| 19:34 |
erle |
nrz_ for the general style of minetest you'd *probably* notice any degradation in textures? no idea |
| 19:36 |
erle |
if bandwith is the bottleneck on any GPU for a game, you can use compressed texture formats ig |
| 19:37 |
pgimeno |
I thought it was a question of memory capacity more than bandwidth |
| 19:37 |
pgimeno |
(GPU memory capacity, that is) |
| 19:38 |
erle |
i guess? when your GPU memory becomes full of stuff, you have to switch out and in textures in some kind of streaming setup. |
| 19:38 |
nrz_ |
Ok it's more for old hardware |
| 19:38 |
erle |
no? |
| 19:40 |
erle |
nrz_ what makes you think that actually? |
| 19:42 |
erle |
i know very little about 3D and opengl, but i am pretty sure it is lossy compression that is just inappropriate for pixel art |
| 19:43 |
erle |
nrz_ look at pages 7 and 8 here https://www.oldunreal.com/editing/s3tc/ARB_texture_compression.pdf |
| 19:45 |
erle |
and maybe, just maybe, read the paragraph with the heading โRuntimeโ that goes from page 8 to 9 |
| 20:38 |
|
Desour joined #minetest-dev |
| 21:16 |
|
YuGiOhJCJ joined #minetest-dev |
| 22:22 |
Desour |
merging #13244 in 5 |
| 22:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/13244 -- MapblockMeshGenerator: Use more verbose member names by Desour |
| 22:28 |
[MTMatrix] |
<localhost> ๐ |
| 22:35 |
|
panwolfram joined #minetest-dev |
