| Time |
Nick |
Message |
| 00:00 |
|
CraigyDavi_ joined #minetest-dev |
| 00:26 |
|
diemartin joined #minetest-dev |
| 00:33 |
|
proller joined #minetest-dev |
| 01:08 |
|
blaise joined #minetest-dev |
| 01:25 |
|
proller joined #minetest-dev |
| 01:30 |
hmmmm |
sapier, it seems like your state2Name() function is the primary cause of warnings for this build of minetest |
| 01:30 |
hmmmm |
ClientState is already implicitly converted to an integer, and then upcasted to a size_t since it's being compared to an expression of type size_t |
| 01:31 |
hmmmm |
but then if you get rid of that, it still give plenty of "comparison is always true due to limited range of data type" warnings - true, because you're using an enum there's no way for that to be out of range. so the check is sort of useless. not to mention that code will only ever be there with debug builds, so it's not very effective at error checking |
| 01:32 |
hmmmm |
I recommend removing that assertion entirely |
| 01:38 |
|
NakedFury joined #minetest-dev |
| 01:50 |
|
CraigyDavi joined #minetest-dev |
| 02:22 |
|
werwerwer joined #minetest-dev |
| 02:49 |
|
troller joined #minetest-dev |
| 03:34 |
|
CraigyDavi_ joined #minetest-dev |
| 03:45 |
Megaf |
hmmmm; sapier is not here, is he? |
| 04:05 |
|
us`0gb joined #minetest-dev |
| 04:20 |
RealBadAngel |
VanessaE, it was Mercury Rain |
| 04:20 |
RealBadAngel |
and the others from Skaven |
| 04:21 |
RealBadAngel |
theyre all used in technic_game |
| 04:21 |
VanessaE |
yeah, I eventually figured it out |
| 04:21 |
VanessaE |
at least I remembered the author :P |
| 04:22 |
RealBadAngel |
https://www.youtube.com/watch?v=cjHNPzv9sGY |
| 04:35 |
|
NakedFury joined #minetest-dev |
| 05:24 |
|
darkrose joined #minetest-dev |
| 05:43 |
|
Hunterz joined #minetest-dev |
| 06:04 |
|
CraigyDavi joined #minetest-dev |
| 06:10 |
|
Garmine joined #minetest-dev |
| 06:16 |
|
PenguinDad joined #minetest-dev |
| 06:20 |
|
CraigyDavi joined #minetest-dev |
| 06:55 |
|
GhostDoge joined #minetest-dev |
| 06:56 |
|
jin_xi joined #minetest-dev |
| 07:21 |
|
troller joined #minetest-dev |
| 07:49 |
|
darkrose joined #minetest-dev |
| 08:18 |
|
Jordach joined #minetest-dev |
| 09:35 |
|
CraigyDavi_ joined #minetest-dev |
| 10:07 |
|
Jordach joined #minetest-dev |
| 10:26 |
|
vifino joined #minetest-dev |
| 10:27 |
|
proller joined #minetest-dev |
| 10:55 |
|
PenguinDad joined #minetest-dev |
| 11:00 |
|
troller joined #minetest-dev |
| 11:13 |
|
Tesseract joined #minetest-dev |
| 11:14 |
|
khonkhortisan joined #minetest-dev |
| 11:23 |
|
Megaf joined #minetest-dev |
| 11:36 |
|
Eater4 joined #minetest-dev |
| 12:54 |
|
proller joined #minetest-dev |
| 13:04 |
|
proller joined #minetest-dev |
| 13:11 |
|
hmmmm joined #minetest-dev |
| 13:46 |
|
asl joined #minetest-dev |
| 13:53 |
|
NakedFury joined #minetest-dev |
| 14:22 |
|
proller joined #minetest-dev |
| 14:27 |
|
tomreyn joined #minetest-dev |
| 14:28 |
|
Anchakor joined #minetest-dev |
| 14:28 |
|
LemonLake joined #minetest-dev |
| 14:37 |
|
kahrl joined #minetest-dev |
| 14:39 |
|
Anchakor joined #minetest-dev |
| 14:49 |
|
Calinou joined #minetest-dev |
| 14:54 |
|
ImQ009 joined #minetest-dev |
| 14:56 |
|
CraigyDavi_ joined #minetest-dev |
| 15:04 |
|
EvergreenTree joined #minetest-dev |
| 15:06 |
|
PilzAdam joined #minetest-dev |
| 15:07 |
|
Zeitgeist_ joined #minetest-dev |
| 15:07 |
|
Zeitgeist_ joined #minetest-dev |
| 15:11 |
|
Zeitgeist_ joined #minetest-dev |
| 15:11 |
|
Zeitgeist_ joined #minetest-dev |
| 15:11 |
|
LemonLake joined #minetest-dev |
| 15:15 |
|
LemonLake joined #minetest-dev |
| 15:19 |
|
Evolykane joined #minetest-dev |
| 15:20 |
|
Piggybear87 joined #minetest-dev |
| 15:20 |
|
EvergreenTree_ joined #minetest-dev |
| 15:26 |
|
EvergreenTree joined #minetest-dev |
| 15:44 |
|
ImQ009 joined #minetest-dev |
| 16:14 |
|
zat joined #minetest-dev |
| 16:30 |
|
sapier joined #minetest-dev |
| 16:34 |
|
rubenwardy joined #minetest-dev |
| 16:43 |
sapier |
18:40:07: ERROR[main]: Texture size (I): 248x90 ( Total: 57076292 bytes Signs: 56603520 bytes ) that's amazing .... that damn signs mod composing texts from single textures causes about 99% of texture memory usage on vanessae's 30005 server |
| 16:46 |
sapier |
only around spawn there are more then 600 signs on her server, each of them requires 90kb ram on pc ... it's even worse on android devices not supporting npot2 textures as those textures have to be scaled up there and require 128kb there |
| 16:47 |
sapier |
additionally there seems to be a bug in that mod as there are plenty of abadoned, invisible sign textures there too |
| 16:48 |
Calinou |
this is why you don't do stuff like that entirely in Lua |
| 16:48 |
sapier |
Calinou can you give one single reason for this to be a lua issue? |
| 16:49 |
Calinou |
this is just a typical “whale mod†:/ but the texture combining is not ideal anyway |
| 16:49 |
sapier |
I'm still waiting for som explanation making your comment anything else as plain lua bashing |
| 16:52 |
sapier |
imho it's more a example for something beeing completely independent of language. No matter what language you use, if you do silly things in a even more silly way you're gonna get bad results. |
| 16:52 |
Calinou |
yeah, bad coding, not Lua in itself |
| 16:52 |
Calinou |
disregard the first sentence I said |
| 16:52 |
|
jin_xi joined #minetest-dev |
| 16:52 |
Calinou |
texture combining was not meant to combine dozens of textures |
| 16:53 |
sapier |
the one writing that mod wasn't aware how expensive textures are |
| 16:53 |
Megaf |
sapier: what mod? |
| 16:53 |
sapier |
creating a single texture per sign is way to costly for hundreds of signs |
| 16:53 |
Calinou |
I prefer having the text showing up on the GUI anyway… |
| 16:54 |
sapier |
homedecor if I remember correct. What we're talking about is sign text beeing displayed on sign |
| 16:54 |
|
Hunterz joined #minetest-dev |
| 16:55 |
Megaf |
sapier: could be the signs_lib |
| 16:55 |
sapier |
basically that'd be a monochrome texture ... but it's created as full rgba texture ... 248x90x4bytes |
| 16:55 |
Megaf |
VanessaE: What's the signs more you are using? |
| 16:56 |
sapier |
signs_lib sounds good |
| 16:56 |
Megaf |
sapier: I do great use of signs with texts on my server, you are scaring me... |
| 16:56 |
sapier |
the issue is client side |
| 16:56 |
sapier |
server doesn't even notice |
| 16:57 |
sapier |
those numbers I posted are from moving around about 50 nodes around that server spawn |
| 16:59 |
jin_xi |
guys im sorry, i made painting mod which started the technique |
| 16:59 |
jin_xi |
imho dynamic content is needed and fun, so pls dont kill the feature |
| 17:00 |
sapier |
I don't intend to kill it at all but ppl should realize how costly this things are ... at least we now know another location where a fix is required |
| 17:01 |
sapier |
having 600 signs within a distance of 50 nodes seems abusive to me |
| 17:01 |
jin_xi |
i also made a tetris mod using texture combining |
| 17:01 |
* jin_xi |
hides |
| 17:02 |
sapier |
the problem with signs is each sign is a separate texture as there's a different text on each |
| 17:02 |
sapier |
I guess for tetris there's only a small number of different textures |
| 17:03 |
sapier |
unless you did combine it pixel per pixel ;-) |
| 17:03 |
celeron55 |
i'm fine with engine abuse, but nobody should expect full optimization for abuse cases |
| 17:04 |
sapier |
actually that's what I mean :-) |
| 17:05 |
jin_xi |
i agree |
| 17:06 |
sapier |
For android I'm gonna try a quick hack ... almost no other texture is 248x90 pixels ... converting to 16 bit color format saves half of memory ... hope that's gonna work ... but that's a ugly hack not a solution |
| 17:07 |
sapier |
suggestions are welcome |
| 17:08 |
sapier |
does anyone know why we save the image in textureinfo cache? |
| 17:08 |
celeron55 |
i'm trying to understand whether the midway textures of the sign text combination are left stored in irrlicht |
| 17:09 |
celeron55 |
do they use a single [combine? |
| 17:09 |
sapier |
for what I understood a texture is a copy of an image |
| 17:09 |
sapier |
yes |
| 17:09 |
sapier |
and we keep the image too |
| 17:10 |
celeron55 |
in irrlicht a texture is an image that is stored in the graphics backend like opengl or directx |
| 17:10 |
sapier |
name of those combined textures is about 4 lines on screen ... NOT 80 char lines ;-) |
| 17:10 |
celeron55 |
an image is one that is in main memory |
| 17:10 |
celeron55 |
(which can't be used for rendering) |
| 17:10 |
sapier |
yes but for what is our local copy? |
| 17:10 |
sapier |
that one in main memory |
| 17:11 |
celeron55 |
? |
| 17:11 |
celeron55 |
"what is"? |
| 17:11 |
celeron55 |
i don't understand what you are asking |
| 17:11 |
sapier |
we need it to create the copy in gpu memory but do we need that main memory copy afterwards? |
| 17:12 |
celeron55 |
they are stored for the case of more textures needing to be combined from the end results of some other combinations |
| 17:13 |
celeron55 |
or, at least that is one reason |
| 17:15 |
sapier |
hmmm |
| 17:15 |
celeron55 |
it might make sense to not do that |
| 17:15 |
celeron55 |
depends on how much memory actually gets used for that |
| 17:16 |
sapier |
well 56.9mb of 57 mb |
| 17:16 |
sapier |
in case of vanessae's server spawn with 600 sign |
| 17:16 |
sapier |
s |
| 17:16 |
celeron55 |
what are these meaningless numbers |
| 17:17 |
sapier |
that's an example to show up the relations |
| 17:17 |
sapier |
100kb of regular textures : 56.9mb of sign textures |
| 17:17 |
sapier |
she's using 16x16 textures for nodes |
| 17:19 |
celeron55 |
so, what are all of those half a thousand signs doing? |
| 17:20 |
sapier |
some of them seem to be just lost entities ... you only see them if you disable texture combining, others fill whole walls with text |
| 17:20 |
celeron55 |
i guess some people just want to write novels in signs |
| 17:20 |
celeron55 |
try throwing the images away and see how a game performs |
| 17:21 |
jin_xi |
painting mod uses 1x1 textures for colors, but still, they're recombined every step of the drawing |
| 17:22 |
sapier |
how many pixels do your images have? |
| 17:22 |
celeron55 |
having an std::map<std::string, something> with thousand character keys with at least 500 items is going to be slow |
| 17:23 |
jin_xi |
8x8, 16x16 and 32x32 |
| 17:23 |
sapier |
and how many colors? |
| 17:23 |
celeron55 |
why do colors matter? |
| 17:23 |
jin_xi |
^ above are usable 64x64 is lagging hard, #colors is same as default dyes |
| 17:24 |
celeron55 |
anyway, every time you paint one pixel in the painting mod, you leak one texture (and one raw image) in minetest 8) |
| 17:24 |
celeron55 |
unless it's exactly the same as something you had already painted |
| 17:25 |
jin_xi |
well, first version used one entity per painting pixel. but i think its fair to call it engine abuse |
| 17:25 |
celeron55 |
they aren't technically leaked from the OS's standpoint, but nobody is going to free them because there is no backwards handling for references |
| 17:25 |
sapier |
yes that's where color matters the more colors the more possible paintings ;-) |
| 17:25 |
celeron55 |
jin_xi: that one got everything freed that you modified |
| 17:26 |
celeron55 |
sapier: you're going to have 2^64 paintings with 8x8 already 8) |
| 17:26 |
celeron55 |
even with black and white |
| 17:27 |
celeron55 |
that is why the question is nonsense |
| 17:27 |
sapier |
hmm ok ok ... guess the difference is only too much and way to much :) |
| 17:28 |
celeron55 |
the difference is between "maybe storeable before the human race dies" and "more than there are atoms in this universe" |
| 17:29 |
sapier |
I wonder if it'd be an option just to drop the images and reload on combining ... of course combining will be way more slow |
| 17:29 |
celeron55 |
uh? |
| 17:29 |
sapier |
that'd not solve the gpu memory overflow |
| 17:30 |
celeron55 |
there's no reason to drop the source images, the client doesn't store them on disk anyway |
| 17:30 |
sapier |
yes but in main memory ;-) |
| 17:30 |
celeron55 |
are you going to redownload them from the server or what? |
| 17:30 |
celeron55 |
the source images aren't our enemy |
| 17:31 |
celeron55 |
it's the result images from combining |
| 17:31 |
celeron55 |
which can be dropped and which i already suggested trying |
| 17:31 |
sapier |
that's what I'm talking about |
| 17:31 |
celeron55 |
just remove video::IImage *img from TextureInfo and kill a bunch of code |
| 17:31 |
celeron55 |
and then fight all the memory leaks that you created in the process |
| 17:32 |
sapier |
well I'm gonna free it immediatly so it's more likely to cause use after free issues ;-) |
| 17:33 |
celeron55 |
you're lucky that ITextureSource doesn't provide any interface for reading the cached video::IImages |
| 17:34 |
celeron55 |
because then this would be impossible |
| 17:46 |
sapier |
ok seems to work without keeping the temporary images in ram |
| 17:46 |
|
nore joined #minetest-dev |
| 18:19 |
|
proller joined #minetest-dev |
| 18:44 |
|
tomasbrod joined #minetest-dev |
| 18:44 |
|
vifino joined #minetest-dev |
| 18:56 |
|
Piggybear87 joined #minetest-dev |
| 19:03 |
|
smoke_fumus joined #minetest-dev |
| 19:24 |
|
Piggybear87 joined #minetest-dev |
| 20:08 |
|
kaeza joined #minetest-dev |
| 20:14 |
|
SmugLeaf joined #minetest-dev |
| 20:40 |
|
Kray joined #minetest-dev |
| 21:12 |
|
tomasbrod left #minetest-dev |
| 21:13 |
|
Jordach joined #minetest-dev |
| 21:36 |
|
VargaD joined #minetest-dev |
| 22:32 |
|
ImQ009 joined #minetest-dev |
| 22:42 |
|
sapier left #minetest-dev |
| 22:49 |
|
troller joined #minetest-dev |
| 23:24 |
|
iqualfragile joined #minetest-dev |
| 23:36 |
|
werwerwer joined #minetest-dev |
