| Time |
Nick |
Message |
| 00:50 |
|
v-rob joined #minetest-dev |
| 01:14 |
|
MTDiscord joined #minetest-dev |
| 01:36 |
erlehmann |
did i just find out that for image sizes around 16x16 it is actually possible to have TGA files that are the same size or smaller than PNG files? if not, what am i doing wrong? https://github.com/minetest/minetest/issues/11600#issuecomment-921380019 |
| 01:36 |
erlehmann |
to quote myself |
| 01:36 |
erlehmann |
> I wonder, what if there was some kind of game in which many textures were so small? |
| 01:40 |
erlehmann |
i suspect the reason may be that some constant PNG overhead is pretty good at eating up the relatively small efficiency gains – up until an image size of somewhere between 12×12 and 16×16. or maybe i am just doing it wrong? |
| 01:42 |
erlehmann |
if i am wrong here, i would like to know how to improve the PNG in the example. |
| 01:42 |
erlehmann |
if i am right, hecktest is just making up stuff, for the third time in a few days. |
| 01:44 |
MTDiscord |
<exe_virus> are you using gimp or something else for your png files? |
| 01:44 |
MTDiscord |
<exe_virus> are you compressing your png files with optipng? |
| 01:44 |
erlehmann |
exe_virus i drew the smiley in gimp |
| 01:45 |
MTDiscord |
<exe_virus> gimp by default adds a bunch of overhead to png |
| 01:45 |
MTDiscord |
<exe_virus> like 6 KB by default or something |
| 01:45 |
erlehmann |
tbh i tried to get something that was only 1 byte apart by default |
| 01:45 |
erlehmann |
unlikely, because: |
| 01:45 |
erlehmann |
The TGA file has 98 bytes (as saved by GIMP) |
| 01:45 |
erlehmann |
The PNG file has 99 bytes (saved wtih GIMP, then used pngcrush) |
| 01:45 |
MTDiscord |
<exe_virus> look at the pngs in minetest_game, and notice how they are all like 0.4kb haha |
| 01:45 |
erlehmann |
there literally can not be 6KB of overhead |
| 01:45 |
MTDiscord |
<exe_virus> pngcursh is why |
| 01:45 |
MTDiscord |
<exe_virus> no worries |
| 01:46 |
MTDiscord |
<exe_virus> but yeah TGA can be better in these really minute examples |
| 01:46 |
erlehmann |
no, it was 101 bytes before pgcrush |
| 01:46 |
MTDiscord |
<exe_virus> then you have a good gimp setup haha |
| 01:46 |
MTDiscord |
<exe_virus> anyways, why are you worried about it? pngcrush and pngs are plenty small |
| 01:47 |
MTDiscord |
<exe_virus> if we wanted better, we would use webp |
| 01:47 |
MTDiscord |
<exe_virus> which is about 20% smaller on average in my experience |
| 01:47 |
MTDiscord |
<exe_virus> we would also perhaps use draco 3d model compression.... |
| 01:48 |
MTDiscord |
<exe_virus> and a bunch of other file optimization stuff.... fluid synth support (midi), etc. |
| 01:48 |
MTDiscord |
<exe_virus> luckily we are getting Z-standard compression soon ? |
| 01:49 |
erlehmann |
exe_virus oh, i am not that worried. recently hecktest removed a bunch of stuff. most of that was not used, but TGA was. now TGA is added back in and hecktest bitched about it being super inefficient, while the truth seems to be, not only does it not really matter, but hecktest probably never tested that. |
| 01:50 |
erlehmann |
honestly, hecktest seems like a person who casually makes shit up without and gets away with it. |
| 01:50 |
erlehmann |
without actually expecting others to verify it |
| 01:51 |
erlehmann |
i meant |
| 01:51 |
MTDiscord |
<josiah_wi> When I started learning basic modding I used gimp and I didn't know about compressing PNG files. Is this documented somewhere for modders? If not is it worth documenting somewhere? |
| 01:51 |
erlehmann |
josiah_wi both pngcrush with -brute option and optipng generate very good results |
| 01:52 |
erlehmann |
commit 524442fc5e9bc64952301b9ba25aefb0d9bf781b suggests to use “optipng -o7 -strip all” |
| 01:52 |
MTDiscord |
<exe_virus> it is worth documenting, and yes optipng and a script are included with minetest_game |
| 01:52 |
erlehmann |
and now for the fun part |
| 01:53 |
erlehmann |
you can run optipng on the 99 byte PNG, it does not get smaller |
| 01:53 |
MTDiscord |
<josiah_wi> Well, I never heard about it before, so I wonder how many mods have uncompressed PNGs. |
| 01:53 |
MTDiscord |
<Jonathon> >honestly, hecktest seems like a person who casually makes shit up without and gets away with it. >without actually expecting others to verify it seems rather rude and wrong given that he has made long explanation posts |
| 01:53 |
MTDiscord |
<exe_virus> sfan5: I have a proposal, copy pasting it here |
| 01:55 |
MTDiscord |
<exe_virus> New Engine Proposal (please critique): --------------------------------------------- New Mapgen "vLua" (game level idea, not mod-level) --------------------------------------------- - Multithreaded, determinant (doesn't have to be, probably should be recommended that way haha) - Optional blocksize for generation - uses multiple lua-contexts (that are disconnected from the default one we use for normal mods) so that no mutexes are |
| 01:55 |
MTDiscord |
required between thread generation (fast) and only for locking the map and writing the values at the end in C++ (blazingly fast) - the only information the engine provides at runtime is the current block size and X,Y,Z of the block - This would be provided by games in a new special "mapgen" folder at the top level (or specified folder via a game.conf) - Optional arguements like seed or so on could be provided with the game.conf so that the menu |
| 01:55 |
MTDiscord |
settings dialog for a world provides the options in a scroll box. i.e. flexible arguments. The goal here is to provide a way for game makers to invent lua mapgens that aren't slow by default, as right now all mapgens share a single lua context and have to wait on things such as globalsteps and whatnot that often are independent. This is by no means a solution to all lua-based mapgens, but it allows us to provide modders with a LOT more |
| 01:55 |
MTDiscord |
flexibility in their mapgens. Implementation detail: if game.conf specifies this mapgen, or somewhere in the menu this mapgen is specified, then a function becomes available called something like "register_mapgen(function())", where you provide the main mapgen function to execute. That function will hopefully be given a lua voxel manip for the region being generated and that's all the game designer needs to implement their mapgen code. |
| 01:55 |
MTDiscord |
Thoughts? P.S. if we allow them to specify if their mapgen is determinant, then we could start doing delta-based maps |
| 01:57 |
erlehmann |
Jonathon well, so far hecktest claimed a) no one used TGA (which was wrong) b) basically no computers without opengl 2.0 can comfortably run minetest (i am typing on one) c) TGA can never beat PNG (so i uploaded the example where it does). making long explanation posts is literally what i mean with making shit up. |
| 01:57 |
erlehmann |
there are a bunch of smaller things as well, but let's leave it at that |
| 01:57 |
erlehmann |
just having a “hunch” is not enough, you need to benchmark, benchmark, benchmark |
| 01:58 |
specing |
I don't like that irrlicht was absorbed. I prefer if common code is maintained as that way projects need less manpower in general |
| 01:58 |
erlehmann |
everyone else seems to be able to say “i don't know”, or “i assume”, but hecktest makes absolute statements that are demonstrably wrong |
| 01:59 |
erlehmann |
Jonathon yes calling someone a liar is very rude. you are right. lying is also very rude. |
| 02:02 |
erlehmann |
Jonathon the thing is, everyone else seems to not do stuff like that. but if you tolerate it, it is very bad. |
| 02:03 |
MTDiscord |
<josiah_wi> specing, last I saw it hasn't been absorbed yet, but a lot of features were removed partly with that goal in mind. |
| 02:05 |
|
v-rob joined #minetest-dev |
| 02:13 |
MTDiscord |
<exe_virus> irrlicht classic is dead, and we are an engine, so it makes sense to me |
| 02:20 |
erlehmann |
so where are the new features? |
| 02:20 |
erlehmann |
i only saw things being removed so far |
| 02:20 |
erlehmann |
(and shadows, which suck, but is that irrlichts fault?) |
| 02:28 |
|
queria^clone joined #minetest-dev |
| 02:30 |
specing |
Shadows got removed? |
| 02:30 |
erlehmann |
now, shadows is a new feature? |
| 02:30 |
erlehmann |
that is what i meant |
| 02:30 |
specing |
Well, port mt to Torque3D. I watched a video review of Uebergame (a libre Torque3D FPS) and the graphics are mindblowing |
| 02:31 |
|
tekakutli joined #minetest-dev |
| 02:31 |
specing |
There's no comparison in the libre world. Shadows on individual grass leaves, animated trees and leaves.... |
| 02:34 |
|
queria^clone joined #minetest-dev |
| 02:34 |
specing |
I don't see why minetest has to be/have its own engine |
| 02:34 |
specing |
waste of time |
| 02:34 |
erlehmann |
specing, come on |
| 02:34 |
erlehmann |
here is what will happen |
| 02:35 |
erlehmann |
1. hecktest will provid something actually working on most core devs machines |
| 02:35 |
erlehmann |
2. it will probably not work on machines of some people who do not have a say, those people will be ridiculed and declared legacy |
| 02:35 |
erlehmann |
3. minetest has its own engine, mostly unrelated to irrlicht |
| 02:35 |
specing |
Ah yes, 90% of people here probably can't run Torque3D (me included) :D |
| 02:38 |
specing |
I wish I'd have more incentive to actually get a real GPU... 99% libre games you can play with a 10 year old iGPU because the visuals are so poor |
| 02:38 |
erlehmann |
specing, prepare to be declared legacy |
| 02:38 |
erlehmann |
specing uh |
| 02:38 |
specing |
oh, I *wish* I would be declared legacy |
| 02:38 |
specing |
because that would mean that libre games actually progressed |
| 02:38 |
erlehmann |
i think you have no idea what you are saying |
| 02:39 |
erlehmann |
you want better graphics, not dropping support |
| 02:39 |
erlehmann |
those two do not *have* to go hand in hand |
| 02:39 |
specing |
instead of repeatedly poking their own engines in their own corners and never getting to the point of not being 10+ years outdated graphics-wise |
| 02:40 |
specing |
erlehmann: they do, because nobody has the manpower to also support 15 yo hardware |
| 02:40 |
erlehmann |
remind me again why you are playing with heavily pixelated virtual legos |
| 02:40 |
specing |
guess why? Because everyone has to have their own engine! |
| 02:40 |
erlehmann |
not really |
| 02:40 |
Pexin |
what does "outdated" mean? |
| 02:40 |
erlehmann |
it is mostly bad developers |
| 02:40 |
MTDiscord |
<Benrob0329> Ubergame looks..alright, I've seen better FOSS games tbh but it's decent for what it is |
| 02:41 |
specing |
Which FOSS games were better? |
| 02:41 |
MTDiscord |
<Benrob0329> Cube 2 looks a good bit better as far as older FOSS FPS games go |
| 02:41 |
MTDiscord |
<Benrob0329> IMO |
| 02:41 |
specing |
Pexin: it means that the graphics look like from an AAA game from N years ago |
| 02:41 |
erlehmann |
specing the vast majority of ppl who loudly claim “we need to throw out the legacy stuff only that way we can progress” are simply incapable of designing both forwards- and backwards-compatible code or data formats. |
| 02:42 |
specing |
Cube 2 has better graphics than torque? |
| 02:42 |
MTDiscord |
<Benrob0329> Than Ubergame |
| 02:42 |
Pexin |
remember morrowind? remember morrowind with an aesthetic facelift? the engine is not the thing holding graphic quality down |
| 02:42 |
specing |
Last time I played assault cube, the avatars looked like moving garbage bags |
| 02:42 |
MTDiscord |
<Benrob0329> I've seen some good looking Torque games, but the engine does not make the game |
| 02:42 |
erlehmann |
do you have any proof of that? please provide garbage_bag.md2 |
| 02:43 |
erlehmann |
what Benrob0329 says |
| 02:43 |
MTDiscord |
<Benrob0329> I've seen some good looking MT games as well, it's down to how you use the tools |
| 02:43 |
specing |
erlehmann: I argue that the reason for that is simple: no manpower to support legacy hardware |
| 02:44 |
MTDiscord |
<Benrob0329> People have been shouting at the MT devs to switch engines for years, the problem is that that would (probably) require more work than just cleaning up Irrlicht like what's being done now |
| 02:44 |
erlehmann |
specing with what evidence |
| 02:44 |
MTDiscord |
<Benrob0329> Generally these shoutings come from people who don't understand game or graphics programming |
| 02:45 |
Pexin |
FOSS games tend not to require top of the line hardware because FOSS games don't have a stake in pushing the sale of new hardware. commercial devs frequently have contracts with hardware manufacturers |
| 02:45 |
erlehmann |
specing do you know xscreensaver collection maintained by jwz? that guy goes through ridiculous length to make it work on a wide range of hardware. |
| 02:45 |
erlehmann |
specing and it's a single guy who's day job is managing a night club or so |
| 02:45 |
erlehmann |
or rather night job lol |
| 02:45 |
specing |
https://news-cdn.softpedia.com/images/news2/AssaultCube-Review-7.jpg |
| 02:45 |
specing |
see how awful the graphics are |
| 02:45 |
MTDiscord |
<Benrob0329> Now I don't know what your experience is, but saying that we need to switch to a fundamentally different engine archatecture on a whim doesn't give me good feelings |
| 02:46 |
specing |
polygonal scope, square floor lighting, ... |
| 02:46 |
erlehmann |
surely specing is an experienced 3d engine coder with multiple AAA games on their belt |
| 02:46 |
MTDiscord |
<Benrob0329> https://cdn.discordapp.com/attachments/747163566800633906/888254470075605022/main_sauerbraten_wide.png |
| 02:46 |
MTDiscord |
<Benrob0329> Oh look, a less awful screenshot |
| 02:46 |
specing |
erlehmann: I'm not, I'd just like to see better libre games |
| 02:46 |
MTDiscord |
<Benrob0329> Fancy that, not posting a terrible screenshot you found makes a game look better |
| 02:47 |
erlehmann |
look if you want AAA you also have to force people into unpaid overtime and all that |
| 02:47 |
erlehmann |
the toxicity of the work environment is a necessary ingredient for the look & feel of the engine |
| 02:48 |
Pexin |
or, you just need enough coverage/popularity that a community of modders crowdsources your asset creation |
| 02:48 |
specing |
Benrob those pictures are so far that you can't tell anything |
| 02:48 |
erlehmann |
you think someone lying in an issue is wrong? imagine that someone is your manager and you get fired if you post the counterexample! |
| 02:48 |
specing |
you can't tell how good the visual details are, I mean |
| 02:48 |
MTDiscord |
<Benrob0329> What, do you want me to boot up Cube 2 and take a screenshot? |
| 02:49 |
specing |
Yes, please |
| 02:49 |
specing |
Show me how it's better :P |
| 02:51 |
specing |
https://pic.infini.fr/cPoDcshq/R2UT3WgG.png |
| 02:51 |
specing |
This is a screenshot from the stream |
| 02:52 |
specing |
Look at those shadows, and those leaves. And how detailed the gun is |
| 02:52 |
specing |
(though the latter is probably mostly artist work) |
| 02:55 |
erlehmann |
specing i think you should watch this video https://yewtu.be/watch?v=2TNSaEJHBrQ |
| 02:57 |
MTDiscord |
<Benrob0329> https://cdn.discordapp.com/attachments/747163566800633906/888257248315449394/unknown.png |
| 03:02 |
specing |
The fire looks pretty nice. Any shots of grass/trees outside? |
| 03:09 |
Pexin |
as someone who thinks kotor's graphic quality is perfectly acceptable, I want to mention I'd prefer an engine that can handle large view distances and a very large number of autonomous objects, rather than graphical detail. but that's just me. |
| 03:09 |
specing |
Why not both? |
| 03:09 |
specing |
It should adjust detail based on distance |
| 03:10 |
Pexin |
gotta pick your priorities |
| 03:11 |
specing |
no |
| 03:15 |
Pexin |
(and doesn't require expensive new hardware, forgot to mention that important bit) |
| 03:21 |
erlehmann |
specing, did you watch the video? |
| 03:22 |
|
hendursa1 joined #minetest-dev |
| 03:25 |
specing |
not yet no |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:10 |
|
olliy joined #minetest-dev |
| 04:26 |
erlehmann |
Jonathon btw i realized that hecktest probably only lies when it is sweeping generalizations. there are certain things that are very well demonstrated: https://github.com/minetest/minetest/issues/11455 |
| 04:27 |
erlehmann |
i find it deeply ironic that the evidence that TTF is not usable for pixel fonts means “no pixel fonts then” for some people, while the pixel font renderer could totally do the job. |
| 06:04 |
|
v-rob joined #minetest-dev |
| 06:10 |
|
ivanbu joined #minetest-dev |
| 06:23 |
Calinou |
pixel fonts are viable as TTFs *if you enforce integer scaling* |
| 06:23 |
Calinou |
bitmap fonts can't solve this problem – your monitor can't render subpixels without a loss of detail :) |
| 06:23 |
Calinou |
Minetest doesn't enforce integer scaling for fonts, this should be added as a minetest.conf setting if you want to use a pixel font |
| 06:36 |
|
v-rob joined #minetest-dev |
| 06:55 |
erlehmann |
Calinou, pixel fonts are not scaled |
| 06:55 |
erlehmann |
right now |
| 06:55 |
erlehmann |
Calinou that is the reason they are crisp |
| 06:56 |
erlehmann |
well, i go off to holidays |
| 06:56 |
erlehmann |
have fun! |
| 07:04 |
Calinou |
enjoy your vacation, stay safe :) |
| 07:09 |
erlehmann |
thx |
| 07:14 |
|
specing_ joined #minetest-dev |
| 07:30 |
sfan5 |
Calinou: only having fonts sizes 8, 16, 24, 32 seems kind of a problem for a GUI |
| 07:30 |
erlehmann |
having used unifont for a while, it is not really one an practice. it kinda enforces a specific style though |
| 07:32 |
erlehmann |
sfan5 you are right about the TGA thing being offtopic. i'll probably not reply to hecktest for a while now bc holidays! btw, you may find my compirason ridiculous, but you can easily count the bytes and verify that i am not lying. of course i didn't want to make the point that TGA is better (like who has textures that are 16x16? that would be ridiculously low!) but reacted to the idea of hecktest that the better |
| 07:32 |
erlehmann |
compression is meaningful. for it to do something, you actually need a bigger file. |
| 07:32 |
erlehmann |
bye then! |
| 07:32 |
sfan5 |
@exe_virus since IRC does not have multiline messages that's kinda hard to read, because of that and so I don't forget please just open an issue |
| 07:33 |
Calinou |
sfan5: yeah, pixel fonts aren't a good default for accessibility reasons |
| 08:05 |
|
hendursaga joined #minetest-dev |
| 09:12 |
|
Fixer joined #minetest-dev |
| 10:51 |
|
calcul0n_ joined #minetest-dev |
| 10:55 |
pgimeno |
oh my what a flamer |
| 11:15 |
|
tech_exorcist joined #minetest-dev |
| 11:33 |
|
Wuzzy joined #minetest-dev |
| 12:11 |
MTDiscord |
<Jonathon> @Exe, Virus (reply mention) |
| 12:15 |
|
tekakutli joined #minetest-dev |
| 12:31 |
|
calcul0n__ joined #minetest-dev |
| 12:47 |
|
Jordach3 joined #minetest-dev |
| 13:00 |
pgimeno |
@josiah_wi I was under the impression that you were going to submit a PR for the signed overflows, are you going to? |
| 13:48 |
MTDiscord |
<exe_virus> Ah okay, I'll put it in a PR later then |
| 13:48 |
MTDiscord |
<exe_virus> Or issue |
| 13:48 |
MTDiscord |
<exe_virus> Depends on my effort levels |
| 13:57 |
MTDiscord |
<josiah_wi> pgimento, I haven't tested that map consistency was maintained, but I have everything ready to open the PR, so I'll do that today if I have time. |
| 14:08 |
pgimeno |
ah okay, thanks |
| 14:08 |
|
tech_exorcist joined #minetest-dev |
| 14:09 |
pgimeno |
this fixes irr#67 for me: http://www.formauri.es/personal/pgimeno/pastes/fix-irr-67.patch |
| 14:09 |
ShadowBot |
https://github.com/minetest/irrlicht/issues/67 -- Pixelflood 2 – Segfault Boogaloo: Sending lottapixel.jpg from server segfaults client upon connection |
| 14:20 |
pgimeno |
the problem is that 16778*32000*4 is > INT32_MAX, so it switched to negative while processing row 16778 of the image, just about half of it |
| 14:27 |
pgimeno |
and that section is unable to process images with more than 32768x32767x4 in general, so maybe it would be wise to add that limit to all supported graphics formats and not just jpg? |
| 14:30 |
MTDiscord |
<Benrob0329> Shouldn't unsigned ints be used for the header and pixel index? |
| 14:31 |
pgimeno |
@Benrob0329 what do you mean? |
| 14:31 |
MTDiscord |
<Benrob0329> You can't ever have negative resolution, but then I don't remember if the libjpeg API allows unsigned ints to be passed |
| 14:31 |
MTDiscord |
<Warr1024> For pixel resolution values, it's probably safest to interpret it as signed and then reject negative values, i.e. de facto treat the top bit as "reserved" |
| 14:33 |
pgimeno |
this is not about the sign of the input, but about an overflow when indexing the raw image. A raw image of 32kx32kx4 is 4GB, the range of a 32-bit unsigned integer. |
| 14:33 |
MTDiscord |
<Benrob0329> Ah |
| 14:34 |
MTDiscord |
<Benrob0329> Does MT always store an alpha channel, even with a 3 channel image? |
| 14:34 |
MTDiscord |
<Warr1024> Anyone actually trying to use an image that large seems ... ill-advised :-) |
| 14:34 |
MTDiscord |
<Benrob0329> Well yes but it shouldn't segfault |
| 14:35 |
MTDiscord |
<Benrob0329> But also, world map |
| 14:35 |
pgimeno |
this is about potential security issues, not about whether it should be done :) |
| 14:37 |
MTDiscord |
<Warr1024> World map is an interesting use-case in theory but I think probably still completely impractical. What I'm saying is more along the lines of 32k is impractically large enough that if we wanted to clamp down more in the name of safety margin it would still be pretty reasonable. |
| 14:44 |
|
v-rob joined #minetest-dev |
| 14:47 |
|
Kimapr[i] joined #minetest-dev |
| 15:15 |
|
longerstaff13 joined #minetest-dev |
| 15:17 |
pgimeno |
I think the limit should be 23000x23000 for all image formats, to prevent signed overflow in other places (that limits images to 2GB) |
| 15:18 |
pgimeno |
the direct cause of irr#68 is this: https://github.com/minetest/irrlicht/blob/master/source/Irrlicht/CColorConverter.cpp#L22 |
| 15:18 |
ShadowBot |
https://github.com/minetest/irrlicht/issues/68 -- Pixelflood 3 – Server-Sent Client-Side Mayhem: Sending overalloc.bmp from server segfaults client upon connection |
| 15:26 |
|
appguru joined #minetest-dev |
| 15:27 |
pgimeno |
oh, Irrlicht does not support top-down images |
| 15:27 |
pgimeno |
top-down BMPs* |
| 15:43 |
appguru |
!tell Desour so what about the references now? a-z & A-Z or is A-Z fine too? |
| 15:43 |
ShadowBot |
appguru: OK. |
| 15:55 |
|
Extex joined #minetest-dev |
| 16:02 |
sfan5 |
merging #9464, #11605, #11607 in 10m |
| 16:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/9464 -- Hide Wself-assign-overloaded and Wself-move unittest compilation warnings by HybridDog |
| 16:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/11605 -- Fix GLES2 discard behaviour (texture transparency) by sfan5 |
| 16:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/11607 -- Shave off buffer copies in networking code by sfan5 |
| 16:03 |
sfan5 |
the hud code could use a rewrite |
| 16:03 |
sfan5 |
to keep state instead of doing all kinds of things every frame |
| 16:05 |
MTDiscord |
<Jonathon> isnt vrobs gui framework supposed to rewrite/unify hud+formspecs if i recall correctly? |
| 16:07 |
sfan5 |
I think so |
| 16:07 |
sfan5 |
no idea when that is coming though |
| 16:07 |
MTDiscord |
<Jonathon> very true |
| 16:14 |
|
Desour joined #minetest-dev |
| 16:17 |
|
v-rob joined #minetest-dev |
| 16:35 |
MTDiscord |
<exe_virus> So about that in menu game music....? |
| 16:53 |
|
Kimapr[i] joined #minetest-dev |
| 17:00 |
pgimeno |
https://codeberg.org/pgimeno/irrlichtmt/pulls/1 |
| 17:05 |
MTDiscord |
<josiah_wi> pgimeno, #11641 is ready for review. |
| 17:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/11641 -- fix integer overflow in mapgen by JosiahWI |
| 17:05 |
pgimeno |
thanks |
| 17:30 |
|
tekakutli joined #minetest-dev |
| 17:32 |
|
tekakutli joined #minetest-dev |
| 17:36 |
|
v-rob joined #minetest-dev |
| 17:47 |
|
tekakutli joined #minetest-dev |
| 17:48 |
|
Desour joined #minetest-dev |
| 17:49 |
Desour |
test2 |
| 17:50 |
MTDiscord |
<luatic> I'm seeing your "[off] test2" |
| 17:51 |
MTDiscord |
<luatic> So it is certainly persistently stored in a publicly accessible Discord server's chat history |
| 17:52 |
Desour |
that was to test ShadowBot, see #minetest |
| 18:03 |
|
tekakutli joined #minetest-dev |
| 18:05 |
|
proller joined #minetest-dev |
| 18:29 |
|
Noisytoot joined #minetest-dev |
| 18:43 |
|
v-rob joined #minetest-dev |
| 18:59 |
|
Extex joined #minetest-dev |
| 19:12 |
|
specing_ joined #minetest-dev |
| 19:34 |
|
v-rob joined #minetest-dev |
| 19:37 |
|
fluxionary joined #minetest-dev |
| 21:19 |
|
ssieb joined #minetest-dev |
| 21:27 |
|
calcul0n joined #minetest-dev |
| 21:49 |
|
v-rob joined #minetest-dev |
| 22:04 |
MTDiscord |
<josiah_wi> It appears the Perlin Noise code uses floats instead of doubles. Is this an optimization? It seems like it wouldn't hurt to have a comment explaining why this decision to have more precision error in exchange for, hopefully something good, was made. |
| 22:38 |
MTDiscord |
<exe_virus> Haha, do we support 32 bit still? |
| 22:39 |
MTDiscord |
<exe_virus> My guess is that double actually does make more sense for 64 bit computers |
| 22:43 |
|
Extex joined #minetest-dev |
| 22:44 |
sfan5 |
using a data type twice as big doesn't suddenly make more sense on 64bit |
| 23:18 |
MTDiscord |
<Warr1024> I think FPUs have been able to handle 64bit just fine for some time before the integer units were 64bit (remember MMX?) but there could be other costs to larger types, like memory bandwidth constraints or cache usage. |
| 23:20 |
MTDiscord |
<josiah_wi> Well, the few tutorials I've looked at so far all used double in their implementations, and so did snippets of code from the original code by Ken Perlin, so I was wondering why Minetest does it differently. |
| 23:24 |
MTDiscord |
<Warr1024> I guess I'd go digging for documentation (possibly also in git blame) and if you don't find anything, it's POSSIBLE that there was no solid rationale. Sometimes decisions are just made heuristically and people don't have time to build controlled experiments and benchmark everything. |
| 23:25 |
MTDiscord |
<Warr1024> I think you'd have a hard time though proving that there's any real reason it shouldn't remain as it is. |
| 23:35 |
MTDiscord |
<josiah_wi> Yeah, and it probably isn't worth proving anyway. It's just my habit to question anything that I learned was a bad practice (and I did; I learned never use float except by specific decision due to precision error). |
| 23:37 |
MTDiscord |
<Warr1024> A number of HLLs like Lua, JS, etc. seem to like 64-bit floats and not offer any other size, larger or smaller. Seems to suggest there's some kind of sweet spot there, especially for a "general" application where you can't be sure how it's going to be used. At least, there's evidence that it makes sense to "assume" 64bit as a sane default absent any other specific guidance... |
| 23:39 |
MTDiscord |
<Warr1024> You might have to track down the original author to be sure though :-) |
| 23:40 |
MTDiscord |
<josiah_wi> The reason I learned for the practice of using doubles wasn't performance-related at all. It was because of stuff like cumulative arithmetic error. |
| 23:48 |
MTDiscord |
<Warr1024> Yeah, I'm saying the only reason I can think of for using something smaller than a double would be either some speed difference, or memory consumption. In this case, it doesn't seem like floating point numbers are one of the major memory consumers. |
| 23:49 |
MTDiscord |
<Warr1024> It does suggest at least that if you DID want to try to find out if there was a legit reason, speed might be one of the things you could try comparing. |
