Time Nick Message 00:02 sapier https://github.com/minetest/minetest/pull/2044 00:08 Wayward_One https://github.com/minetest/minetest/issues/2045 00:08 ShadowNinja VanessaE: Right. I assumed that was intentional. Does it detach the mouse on Windows? 00:09 VanessaE ShadowNinja: I'm not sure, but I think so. how else would people copy&paste from the chat console? :) 00:09 ShadowNinja VanessaE: And C&P should work in the console now, although it's never worked on Linux, so that's not an issue. 00:09 ShadowNinja VanessaE: C-a C-c C-v 00:10 ShadowNinja Or Shift-direction C-c 00:10 VanessaE ShadowNinja: nope, I can't highlight to copy out from the console. 00:10 VanessaE neither c-a nor shift-arrows cause a highlight. 00:11 VanessaE nor can I paste in from e.g. hexchat. 00:11 VanessaE but I can at least c-a, c-c and copy out from the old command line back to here. 00:11 ShadowNinja VanessaE: Well, pasting has never worked. Copying should be fixed though. Make a comment on this usse so that this isn't forgoten. 00:12 ShadowNinja the issue* 00:13 VanessaE done. 00:18 hmmmm so I think I got a pretty solid idea down, going with a slightly modified version of alternative lighting method #2 as discussed. i can make light spread further, i'll save 8 bits per mapnode, i can speed up lighting calculations, and i can have 24-bit colored lighting this way 00:18 * VanessaE updates just to make sure about the console C&P 00:18 hmmmm :D yay 00:18 VanessaE hmmmm: very nice indeed. and it works okay with mods that check light levels in the usual way? 00:18 sapier speed up light calculations? *Jumping up* 00:18 hmmmm vanessae: nope 00:18 sapier wanna have this! ;-) 00:18 Wayward_One hmmm, can't wait to try it! :D 00:18 VanessaE hmmmm: boooo :( 00:19 Wayward_One *hmmmm 00:19 hmmmm mods are gonna have to calculate light the 'hard' way 00:19 hmmmm well 00:19 sapier hard way? 00:19 hmmmm nah i can just modify the api for it 00:19 sapier you're kidding, I once wrote that in lua it's gonna take all the speed benefit and reverse it ;-P 00:19 hmmmm but it'll be way, way, way more computationally expensive to get the light at a specific point 00:20 hmmmm because i won't store it in the node any longer 00:20 VanessaE ShadowNinja: ok, at git HEAD now and still can't c-a, c-c (doesn't highlight on c-a). 00:20 sapier so any mapgen or spawning mod requireing light information will get drastically slower 00:20 hmmmm pretty much yep 00:20 VanessaE hmmmm: um 00:20 sapier not good 00:20 hmmmm :) 00:20 VanessaE that breaks like half of plantlife. 00:21 sapier I have some mobs spawning only in areas where almost no light is there .. e.g. vombies 00:21 hmmmm I think there is a better way to do the thing you'd like to do 00:21 hmmmm rather than check light levels 00:21 sapier suggestions hmmmm? 00:21 sapier I never found a way to do same thing another less expensive way 00:21 hmmmm have a bit present in the mapnode for 'has_sunlight' 00:21 sapier won't work 00:22 sapier because spawning doesn't care about sunlight but actual light 00:22 VanessaE hmmmm: torches triggering solar panels to act as node sensors. 00:22 VanessaE (think: automated tree farms using pipeworks and mesecons) 00:22 hmmmm that's a hacky way to do things to begin with though 00:23 hmmmm so what do we actually need light levels for 00:23 sapier it's not hacky to check for light if something doesn't have to spawn once light is around ;-) 00:23 ShadowNinja VanessaE: "Doing this would leave the ESC/Pause menu as the only way to release the keyboard/mouse." -- not true, opening formspecs also releases the mouse. 00:23 hmmmm is it absolutely necessary to know that (x, y, z) == 13 or something 00:23 VanessaE ShadowNinja: oh right. /me fixes. 00:23 hmmmm or is it more like 00:23 hmmmm "i need to know where in the mapblock i can place this" 00:23 sapier no but I need to know if light at xyz is > a 00:24 hmmmm so if you're doing a bulk query then calculating light levels in a mapblock probably isn't too expensive 00:24 sapier if you can provide the max light level within a certain area that'd be enough 00:24 hmmmm yeah that too 00:24 hmmmm that would be extremely quick 00:24 sapier if light in (x1,y1,z1) (x2,y2,z2) > a 00:24 VanessaE that would NOT be enough 00:24 VanessaE you'll break everything that relies on light levels at specific locations. 00:24 sapier how do you intend to make this quick? 00:25 hmmmm VanessaE: yes, and minetest moves forward as a whole 00:25 sapier in worst case x2 == x1+1 00:25 hmmmm well 00:25 sapier that's not moving forward thats moving backward ;-) 00:25 hmmmm hopefully your radius is conveniently the size of a mapblock 00:25 sapier you're removing a feature because it's to slow for you 00:25 * VanessaE grumbles 00:25 sapier nope 00:25 sapier a mapblock is way to big for spawning 00:26 VanessaE hmmmm: why can't the light at a given point be calculated the "old" way on demand? 00:26 sapier especally as usually no more then a few blocks are even loaded 00:26 hmmmm because that takes up 8 bits 00:26 hmmmm well 00:26 VanessaE on the server? 00:26 hmmmm on both 00:27 sapier hmmm it's not gonna work on mapblock granularity I already tried this 00:27 VanessaE you're gonna trifle over one byte?! 00:27 hmmmm that's not just one byte 00:27 sapier I had to add a separate spawn position storage with all issues to get rare mobs spawning correct 00:27 hmmmm that's 25% of the most commonly used data structure in the entire engine 00:27 VanessaE ok fine, 4k then 00:27 VanessaE (per block) 00:27 sapier I know hmmmm but that's like "let's remove the screen update it's causing most load" 00:27 hmmmm besides, with RGB lights, how are you even going to get brightness? you'd need to do YCrCb conversion 00:28 sapier who did add rgb lights? 00:28 VanessaE ok we have maybe 2000 blocks loaded at once in worst case. that's not even 8 MB. 00:28 hmmmm so what's the largest radius we're looking at here 00:28 VanessaE (I'm pretty sure I've seen my server's count get close to that a few times) 00:28 hmmmm larger than a mapblock? smaller than a mapblock? 00:29 VanessaE hmmmm: for a light radius test? 00:29 sapier largest light radius I'm looking for is about 3 nodes 00:29 hmmmm for the radius tests you commonly do 00:29 VanessaE hmmmm: I would say 3x3x3 nodes off the top of my head 00:29 hmmmm note this isn't absolutely horrible 00:29 sapier yes but block granularity is way to big 00:29 VanessaE judging by what I've seen done in practice in actual users' builds 00:29 VanessaE and what I've done myself 00:30 sapier having only about 9 blocks loaded in singleplayer some mobs would never ever spawn 00:30 VanessaE but even THAT will be too coarse for some fine tuning 00:30 VanessaE (e.g. making "unit tests" so to speak, in-game) 00:30 hmmmm how many of these radiuses would happen in the same mapblock 00:30 sapier a lot 00:30 hmmmm then it'd be worth it 00:31 VanessaE depends. in a typical pipeworks/mesecons apparatus, probably 20-30. 00:31 sapier if you find a way NOT to break light per node and still speed it up it'd be worth it 00:31 VanessaE (usually far less) 00:31 sapier mobf uses up to 20% cpu load to do this if you make it 10 times slower about 10 times less mobs will spawn 00:32 VanessaE in plantlife, probably hundreds of such checks per mapblock are done 00:32 sapier and of course lag issues will increase as spawning will take time from more valuable tasks 00:32 VanessaE (I've never counted) 00:34 sapier hmm vombie does use a radius of 0 (only spawn location) 00:36 sapier big red uses 2, 10 retries, each 60 seconds, with half this time if not beeing able to spawn at least 3 within a range of 100 nodes ... which already requires separate spawn point storage 00:36 hmmmm the problem i have is that the engine itself storing light information is quite useless since it's only used at one point, at mesh render time 00:36 VanessaE for plantlife, knowing the light level within 2 nodes of the target would be sufficient 00:37 hmmmm on the other hand mods are storing it and reading it much more often 00:37 sapier no it's a basic feature used by mods 00:37 VanessaE it's not useless because it's used by dozens of mods 00:37 sapier light is a property of a noded it's not only something client has to display 00:37 VanessaE so calculate it your fancy way, store it, and don't fret over the extra storage it takes. 00:37 sapier e.g corn growing 00:37 hmmmm well, it's never explicitly written to 00:38 sapier most nodes never write a node type too 00:38 sapier mobf for example usually doesn't modifiy exisiting nodes 00:38 ShadowNinja hmmmm: Maybe you could cache the light level in a param3 that's only compiled in on the server and isn't sent to the client? 00:38 hmmmm yeh but light information is implicit along with the content type 00:38 sapier removing per node light information is a big step backward 00:39 hmmmm ShadowNinja, that would stop working the minute we add client side scripting 00:39 ShadowNinja (Or "light", since that's a lot less cryptic. 00:39 hmmmm i'd rather focus on ways to get computing this very fast 00:39 VanessaE hmmmm: well the client will eventually do some kind of hardware-assisted lighting rendering, right? 00:40 hmmmm thought about it, no, hardware lighting doesn't help much with minetest's use case 00:40 VanessaE at that point, all it needs to know is where all the light *sources* are. it doesn't have to care what the server says are the per-node light levels 00:40 hmmmm sunlight can be done by hardware lighting but light sources not so much 00:40 VanessaE hrm 00:40 * VanessaE pokes RealBadAngel 00:41 hmmmm the issue is that our world is dynamic 00:41 deezl sapier, are you here? 00:41 VanessaE yeah I know 00:41 hmmmm this is simply something that games never did 00:41 sapier yes deezl 00:41 VanessaE meaning a user could potentially place thousands of light sources, while opengl et al. are limited on how many they can render. 00:41 sapier is anyone about to fix the particle spawner memory leak? 00:42 deezl hi, just had someone log into one of my servers with your name, was wondering if it was you 00:42 hmmmm calculating light correct way is very difficult, you basically need to solve the radiosity problem each time you add a light 00:42 deezl (I was doubting it) 00:42 hmmmm which is like 5 differential equations 00:42 VanessaE sapier: what about jin_xi/SN's irrlicht particles code? shouldn't that be finished/merged first? 00:42 hmmmm the minecraft light calculation method is so cheap on the other hand 00:42 sapier if it's been the big... server yes I'm trying to pinpoint a memory leak 00:43 deezl oh ok, well that's good 00:43 ShadowNinja sapier: No. The particles code is a mess though, and jin_xi's code needs a lot of work. 00:43 deezl yes, that was my server 00:43 sapier loosing about 2k on processing each particle packet? 00:43 sapier that's a huge issue ;-) 00:43 VanessaE sapier: you really want to see that in effect, I seem to recall the just test server had an active spawner near the spawnpoint that really set it off. 00:44 deezl sapier, if it helps any, or matters at all, BigPappa's is not standard minetest_game, it is a modified version of carbone. 00:44 sapier who wrote this code? 00:44 sapier client has no chance to cleanup the spawners 00:44 VanessaE particle spawners? jeija did I think. 00:44 hmmmm that's mirciakitsune 00:45 VanessaE oh right 00:45 hmmmm it's so sloppy 00:45 hmmmm i'm not sure why i approved that 00:47 sapier hmm at least there's a clear_particles() function ... let's hope it's doing what I expect it to do ... well actually it's clearing the spawners not the particles 00:47 sapier deezle thanks for this information but memory leaks still shouldn't happen ;-) 00:48 deezl agreed. 00:49 hmmmm so on a lighter note (pun intended) what do you guys say about merging some options in the pause menu 00:49 hmmmm change password, sound volume, change keys -> Options 00:49 VanessaE er... 00:50 ShadowNinja hmmmm: That sounds good. 00:50 sapier agreed 00:50 VanessaE yeah, sounds good. 00:59 paramat hmmmm sounds okay, personally i wouldn't much miss light as param2, i've written a variety of mods and have rarely used it. when it's occasionally needed in mods a slower method would be okay 01:04 sapier as I said paramat for spawning a slower method would be a desaster current method is already a big problem 01:06 paramat yes this will be unpopular with those who use light level a lot, i would suggest perhaps triggering spawning a different way 01:07 sapier there's no way to replace it 01:07 sapier if there's no way to spawn mobs based uppon light level the only option is removing those mobs 01:07 sapier meaning almost all hostile mobs dying in sunlight 01:08 sapier dieing 01:09 paramat i'm suggesting spawn or kill them dependant on something else then, time of day .. 01:09 sapier not very usefull 01:09 hmmmm we don't need to copy minecraft into our grave 01:09 sapier it's already hard to spawn a mob below ground 01:09 hmmmm they don't have RGB light or any of the other cool stuff because they store it all in the node information 01:09 sapier we don't need to remove features just because you think theyre slow either 01:09 paramat i would still like to have sunlight with simple shadows (low res shadows?) by hardware lighting 01:10 paramat i guess hmmmmm's method would mean a usable system without hardware sunlight, so it's not essential 01:10 sapier you could use your calculation for rgb and just store brightness in node 01:10 paramat (for slow computers) 01:11 hmmmm no, sunlight would still be hardware lighting 01:11 hmmmm sapier, how about 4 bits 01:11 hmmmm or 3 01:11 hmmmm 3 is the best I can do 01:12 sapier 3 is way to limited 01:12 hmmmm 8 levels of light?? 01:12 paramat sorry i mean, with hmmmmm's suggestion hardware sunlight becomes optional instead of essential, so this would be good 01:12 hmmmm of brightness rather 01:12 sapier it's half we have now 01:12 hmmmm 4 of them are pretty much wasted 01:12 sapier 2 and those will still be wasted 01:12 hmmmm why you'd need 16 levels of light for deciding where mobs spawn is beyond me... why can't you do the same with 8 01:13 paramat 8 levels is good enough 01:13 sapier so you have 6 levels only 01:13 paramat for plant spawning too, 4 would be fine 01:13 hmmmm lemme call up my buddy who's an expert at lighting 01:14 sapier no they wouldn't it's like ohhh seee rendering my screen is slow lets draw everything black only to get it more fast 01:14 hmmmm lol 01:14 hmmmm what are you complaining about. 01:14 sapier basicaly you diminish mods making decisions based uppon day night cycle 01:15 sapier as well as artificial lighting 01:15 hmmmm the only noticable difference here is that you'd only be able to choose between 8 levels of light instead of 16 01:15 sapier 8 is as good as 640kb are enough memory for any application ever beeing programmed 01:15 sapier and it's still 6 levels not 8 01:16 hmmmm that's like saying "there are 254 shades of gray" 01:16 hmmmm "not 256" 01:16 sapier why don't we just switch to monochrom mode we'd never have to cope with colors ;-) 01:16 paramat 6 is more than enough for a rough light level 01:16 sapier no it's not 01:16 hmmmm also keep in mind this is a rough light level estimate 01:17 hmmmm to get a more accurate light level it'd be a bit slower 01:17 hmmmm but possible 01:18 sapier if you get at least a two digit percentage fps increase by doing this I'd think about it but if it's only 0.5 forget it 01:18 hmmmm what about all the other advantages 01:18 paramat also, i don't see coloured light as a priority, if there's a gain from not implementing that i would choose to not have it 01:18 sapier I see no other advantages 01:18 hmmmm truecolor lighting 01:18 sapier for me it's just rendering some way to spawn mobs way less conveniant then before 01:18 hmmmm indefinite light spread distance 01:19 sapier if I'd get light color per node too I'd have at least another benefit do i get this information? 01:19 hmmmm yes 01:19 sapier so I can ask per node brightness as well as color? and this ain't horribly slow? 01:20 hmmmm best part is, if the node you're querying happens to be a light source, you can do an O(1) lookup of the brightness/color :) 01:20 hmmmm color is just a function of brightness 01:20 hmmmm rather other way around 01:20 sapier for what I know most nodes aren't light sources so don't tell optimized cases not happening very often ;-) 01:21 sapier usually next light source is quite far away 01:21 paramat i don't consider mob spawning a priority importance in minetest compared to general lighting, sorry =) 01:21 sapier paramat as everyone does that's why mobs suffer that much 01:22 sapier and mob spwaning is by far the most cpu consuming part so if you make any part of it slower it's gonna cause a huge penalty 01:22 hmmmm how is mob spawning so cpu consuming 01:23 sapier because you have to check a lot of nodes around in regular intervals 01:23 sapier light is one of the most time consuming things but checking for node types isn't much faster if it's not a single node only you have to check 01:24 paramat mob spawn/kill seems only an occasionally done thing so okay to to have a slower light check. just check less often 01:24 sapier e.g. if you wanna spawn a fish you need to make sure there's enough water around 01:24 sapier no it's not ocassional if you have about 20 different mobs 01:25 sapier even if you only do this once per 60 seconds 01:25 sapier most time you don't find a valid location for the first time 01:25 sapier I'd guess about 5-10 tries to find a suitable location 01:26 sapier if you wanna keep population stable you don't spawn a single mob only so you're doing this more then once per spawn event 01:27 sapier 20*7.5*2 01:27 sapier and the 7.5 is only true on surface, to find a suitable location below ground you often need way more tries 01:27 paramat i guess we need to consider the strongest arguments against, mob checks is one, spawning every plant by light level is overkill IMO so not important (sorry Vanessa), any others? 01:27 sapier of course that count happens for about each mapblock 01:28 VanessaE paramat: mesecons. 01:28 paramat ah lght sensors 01:28 paramat *light 01:28 sapier paramat if you find a working faster way we can think about it but by now everyone claimed it's bad but noone did find better 01:29 sapier I once tried spawning on mapgen only but ppl aren't happy if mobs don't regenerate 01:30 paramat to be clear i'm playing devil's advocate a little, i'm actually undecided but think hmmmmm's idea should be seriously considered 01:31 sapier I do consider it but only if it provides really good benefit, I'd not accept this for a 1fps increase 01:32 sapier and if those colors he suggests can't be used because reading a single nodes color is 100 times more expensive then reading current light level it's basicaly useless for mods anyway 01:42 kahrl sapier, why not do only 1 spawn attempt per mapblock but if successful, spawn a pack instead of a single mob 01:43 sapier any suggestions how to spawn at a matching location at once? 01:44 sapier I already use spawn eggs doing the spawning but they still need to find locations for different mobs 01:44 sapier each spawner spawns all possible mobs distributing cpu time across them 01:45 kahrl for i = 1..rand(1,4) { pos = original pos + v3s16(rand(-3,3),rand(-1,1),rand(-3,3)); if pos is a suitable spawn location { spawn mob at pos }} 01:45 kahrl something like that? 01:45 sapier and how do you expect that random pos to match immediatly? 01:46 kahrl since you already checked the original position, the new position is more likely to be valid 01:46 sapier why? 01:46 kahrl because if the original position is dark then the new one will be too most likely 01:46 kahrl replace "dark" with "water" or whatever 01:47 sapier I see no reason for this to be true in generic case 01:47 sapier if some position is stone why should next position be stone too? 01:47 kahrl because noise is continuous 01:47 sapier it'd be more likely to check for height above ground 01:48 sapier but It's useless to create a specialized spawner for every single mob I once had it it just didn't work so I need generic spawning 01:48 sapier and making it more likely always has to make assumptions which may or may not be true 01:49 sapier e.g. in vanessae's heavyly modified worls not even noise continuity is correct 01:50 sapier and even if there's a way to improve hit chances it's not gonna compensate a 100 times slower light calculation in situations where you don't find a single suiteable position and still have to try 01:51 kahrl if you don't find a position, don't spawn a mob 01:51 kahrl on first try* 01:51 kahrl simple as that 01:51 sapier and then? 01:51 sapier not spawn any mob at all? 01:51 sapier there's always a second third .. try 01:52 kahrl not in this spawn event 01:52 kahrl perhaps the next one will be successful 01:52 sapier which is already configurable and will cause drastically less mobs to be spawned in total 01:52 paramat i don't see mesecons light sensors being particularly important either (with apologies to the authors/users) 01:52 VanessaE so what you're really saying is mods aren't important at all. 01:53 sapier in worst case (lots of different mobs) you won't ever get a certain mob because a block is never active long enough to even try to spawn it 01:53 kahrl personally I think guaranteeing exactly one mob of each type being spawned per event is pretty boring 01:53 kahrl too predictable 01:53 sapier that's not a new issue it's there right now too but making spawning slower causes it to be way more of a problem 01:53 sapier I don't do this karl 01:53 sapier I try to spawn x mobs of one type 01:54 sapier if I have cpu time left in this spawn event 01:54 sapier if there's not time left nothing is spawned at all 01:54 kahrl ah, okay 01:55 sapier so if spawning becomes more time consuming overall mob spawn chance is reduced 01:55 sapier that's why I'm oposing to making some heavyly used function drastically slower 01:56 kahrl but for some reason MC can do a spawning cycle every tick (i.e. 20 per second) without completely locking up the CPU, which is why I'm wondering why it's so much more expensive in mobf 01:56 sapier and at night for example light checking uses almost full cpu time 01:57 sapier I don't lock up cpu too 01:57 sapier problem ain't mobf but the way minetest calculates light 01:58 sapier for mobf it's just reading a value that should be there 01:58 kahrl I mean they are doing 1200x as many spawn cycles than mobf 01:58 sapier I don't have any knowledge about minetest recalculating this each step 01:58 kahrl if the default interval is 60s as you said 01:58 kahrl s/than/as 01:58 sapier if e.g. minetest did recalculate light in regular intervals instead of each step you could save a lot of time too 01:59 sapier interval depends on mob 01:59 Wayward_One ShadowNinja, just finished running minetest through valgrind's massif tool, but i have no idea how to read the results lol. should i pastebin the results here...? 01:59 sapier there are mobs with 300 or more too 01:59 sapier my spawning mechanism is highly configurable 02:00 kahrl oh right, in MC the "once per tick" is only for hostile mobs 02:00 kahrl other mobs have an interval of 20s afaik 02:00 sapier I don't know how much about mc 02:00 sapier well as I said I have some way less then this 02:02 sapier still this is already an open issue so making it even more slow is wrong direction ;-) 02:03 kahrl well this is the algorithm pretty much if you want to know: http://minecraft.gamepedia.com/Spawn#Mob_spawning 02:04 sapier well I'd be glad if I could spawn in 240x240 range 02:04 sapier usually I can only spawn in 32x32 02:05 sapier because everything else is out of activity range 02:05 kahrl yeah that's a big difference too 02:05 sapier spawning a entity just to be unloaded is useless 02:05 sapier and causes lots of trouble 02:06 sapier 128 blocks activity range is about 4 times as much as we have 02:06 sapier it'd make spawning way more easy if we did have that range 02:07 kahrl I'm not sure all of those count as active 02:07 kahrl could be the case those mobs just spawn and don't move or do anything until you get nearer 02:08 sapier "However, hostile mobs (and some others) that move farther than 128 blocks from the nearest player will soon despawn" I'd understand this as similar concept then our activity range 02:08 sapier well they have different activity ranges for different mobs so it's not exactly same 02:08 kahrl not completely the same 02:08 kahrl they are not saved to the mapblock/chunk (hostile mobs, anyway) 02:09 sapier true 02:09 sapier but I don't think this is an issue for us 02:10 sapier why do we have a memory leak in mapblock? 02:10 kahrl huh? 02:10 sapier nodemetalist seems not to be freed correct 02:10 kahrl ohh.. I thought that was fixed 02:10 kahrl but have imagined that 02:10 kahrl must have* 02:11 sapier well valgrind says it's not fixed ;-) 02:11 kahrl yeah, I saw that in valgrind ages ago 02:11 kahrl wonder why Zeno never noticed it even though he valgrinded a lot 02:12 sapier and particle spawners are still a mess ... not sure how they get lost 02:12 sapier ahh 02:12 sapier ok the add function doesn't even check if it already exists ... could be a chance to loose something 02:13 Wayward_One speaking of valgrind, i just ran mt through massif, and i'm not sure what to do with the output, or if it's even needed still 02:17 sapier well if you're looking for a memory leak valgrind would be more helpfull then massif 02:19 Wayward_One hmm... SN suggested massif on github, so that's what i used lol 02:19 sapier hmm well post the output maybe he knows where to look at :-) 02:19 sapier heap profiler usually is required if it's not a real leak 02:22 Wayward_One ok, here it is: http://pastebin.com/jamrtjsj 03:53 * kahrl wonders what the deal with #1505 was 03:53 ShadowBot https://github.com/minetest/minetest/issues/1505 -- Update to SQLite 3.8.5 by SmallJoker 03:53 kahrl why was the bundled sqlite neither updated nor removed? 04:00 Miner_48er what updates are missing from it? 04:01 kahrl the one we're bundling is several years old 04:01 kahrl from 2011 to be exact 04:02 Zeno` Isn't it because of potential compatibility problems with LuaJIT? 04:03 kahrl does sqlite interact with LuaJIT in any meaningful way? 04:03 Zeno` lol 04:03 Zeno` of course not. I misread :) 04:04 Zeno` bundled sqlite not updated... no idea why not 04:05 kahrl SN discourages using it for this reason: http://irc.minetest.ru/minetest-dev/2014-07-20#i_3823030 04:05 kahrl (but not everyone knows, as the discussion at that link shows) 04:06 Zeno` hmm 04:06 Zeno` not really sure how updating the bundled version can hurt though, even though I see SN's point. 04:06 kahrl I think we should update it for now, we can still remove it 04:07 Zeno` yeah, that's what I mean 04:08 hmmmm +1 for updating bundled sqlite 04:11 kahrl https://github.com/kahrl/minetest/commit/dc90dd1d051ba62789df4224f92dfe47c4af75d7 04:11 kahrl will push ^ in a few minutes then 04:42 hmmmm hmm 04:42 hmmmm paramat, i think i see the problem with the light 04:44 hmmmm nope, i know *exactly* what the issue is 04:44 hmmmm grr 04:45 hmmmm this is tough 04:47 hmmmm those ores not lighting up completely are in a part of a cave carved into the upper bordering block of the chunk directly below the one the ore exists in 04:47 hmmmm they never git hit by calcLighting() 04:47 hmmmm because I don't pass that upper border plane of blocks to calcLighting since that needs to be the overtop for sunlight propogation 04:48 hmmmm so if you calcLighting the entire full area, you'll get complete darkness because the overtop will never exist since it's outside of the vmanip 04:48 hmmmm but the ores will light up correctly 04:57 hmmmm so technically the ore has a param1 of 0, it's just that the mesh making code takes the light value of the content instead of the param1 if it's a light source 05:40 paramat hmmmm i'm not so sure 05:41 paramat in my mapgen https://github.com/paramat/noisegrid every light source has the problem, where-ever it is within a mapchunk, above or below sea level 05:43 paramat if you disable the ABMs that spread the light you can see. lights in road tunnel roofs and luxore in fissures below ground 05:44 paramat the 'spread light' ABMs are in functions.lua 05:45 hmmmm paramat, try it yourself. 05:45 hmmmm change calc_lighting to calculate the entire voxelmanip area, not just the central chunk 05:45 hmmmm no sunlight but your ores sure will work 05:46 paramat ah okay perhaps i misunderstood 05:47 paramat it sounded like you were saying the only affected nodes were in particular parts of a mapchunk, which is untrue 05:50 paramat will try 06:07 paramat i edited the mod to have vm:calc_lighting({x=minp.x-16, y=minp.y-16, z=minp.z-16},{x=maxp.x+16, y=maxp.y+16, z=maxp.z+16}) but still doesn't work 06:08 paramat landscape is dark with occasional light patches 06:10 paramat is it because i have 'vm:set_lighting({day=0, night=0})' just before calc_lighting? 06:10 paramat ^ that seems to be essential for lua mapgen lighting to work properly 06:10 hmmmm no, but it's recommended that you set mapgen flags to nolight instead of zeroing the light out 06:11 hmmmm saves some execution time by doing less work 06:12 paramat okay will do in future, but that shouldn't make a difference? 06:12 hmmmm nope, it shouldn't 06:13 paramat i can confirm every light soure node in every possible position in a mapchunk is still buggy 06:13 paramat *source 06:13 hmmmm by "is still buggy", what do you mean exactly 06:13 hmmmm like what was happening with the ore in the screenshot you pasted or what? 06:13 paramat yeah 06:14 paramat light source node looks bright but light doesnt spread more than say 0.5 nodes 06:14 hmmmm i'll have to check it out but i think something might be going wrong with the mod itself because the code being executed is identical to internal mapgen code 06:15 paramat this bug happens in several of my mapgens, could be my way of coding i guess 06:26 hmmmm hey paramat, i was looking at your mapgen a little closer and i noticed that in the definition of your ore you don't have light_propgates = true 06:26 hmmmm that could be the issue here 06:26 paramat oh man i'll try 06:27 paramat okay for singlenode mapgens i will use minetest.set_mapgen_params({mgname="singlenode", flags="nolight"}) 06:28 paramat i got into the habit of 'vm:set_lighting({day=0, night=0})' because my earlier mapgens created a layer above a normal v6 world 06:29 paramat where that is essential 06:30 paramat .. to set no light only in the mapchunks i was generating 06:32 hmmmm yeah I think it would be a huge problem if you don't set your light to propagate because your mapgen would actually have the same problem if you tried the old calcLighting() 06:33 paramat paramtype = "light" is in torch and lava definitions, that sets light to propagate 06:37 paramat phew it's fixed, thanks 06:37 paramat big relief 06:38 paramat one less bug for you to tackle 06:44 hmmmm hmm.. VoxelManipulator::spreadLight() doesn't have the problem i was explaining earlier because it doesn't respect the specified area boundaries, it'd just try to propogate the light 'upstrairs' and if it fails (blows an InvalidPositionException) just continues on 06:44 hmmmm but predictably it misses out on light sources in the overtop 06:46 paramat when originally creating my glowing nodes i must have not realised the importance of 'paramtype = "light"' and left that out, despite it being in the torch definition 06:46 hmmmm I can fix your river light problem, the V7 caves, and the ore light issue 06:49 paramat great. yes river water at y = 47 is dark 06:51 paramat i will add a note to lua-api.txt about setting paramtype = "light" for light sources 06:53 paramat lua-api.txt was just beginning to look good and readable, now it's in horrible MD format 06:53 hmmmm i don't think the md format is too horrible 06:53 hmmmm it reads mostly like regular text 06:58 paramat guess it's a personal thing, i am very visually sensitive and prefer simplicity, i get visually overwhelmed easily 06:58 hmmmm ahhh the v5 overtop thing 06:58 hmmmm hrmmmmmm 06:59 hmmmm i know how to solve this 07:05 hmmmm haha 07:05 hmmmm dungeons really wreak havoc on mapgens 07:07 hmmmm awesome! it works perfectly 07:16 paramat https://cdn.mediacru.sh/I/I4nkyaIHgODw.png 'levels' mod with a 1kn spiky tower 07:17 hmmmm cool stuff 07:17 hmmmm i'm going to work on sunlight producing shadows that fade out rather than the opposite 07:18 hmmmm i am aware that "fixLight()" would break this effect but in the common case it'd work as intended 07:20 paramat shadow decay yes please 07:21 paramat https://cdn.mediacru.sh/-/-k6m-ogUBmkF.png small spike nicely merging with nearby terrain 07:21 hmmmm do they normally merge? 07:27 paramat i wasn't expecting the spike to melt into the terrain like that 07:31 paramat it seems the spikes have a cylindrical volume around them which increases the node 'densities', and so inflate any nearby terrain causing a merge .. 07:32 hmmmm alright i sufficiently tested this BS 07:40 hmmmm :)!!!!! https://github.com/minetest/minetest/commit/54713cbb475f9dcf5b59dd3d0b0dc52cf62d25e2 07:44 paramat good work, very productive night 07:46 paramat will test this later 08:12 hmmmm wooh 08:12 hmmmm i just cleared like 7 issues 08:24 chchjesus neat! 08:24 chchjesus hmmmm++ 08:25 hmmmm :) 08:25 hmmmm https://github.com/minetest/minetest/commit/ef8ed5d127f2c698586efdfd254c8e5c7ba66f19 08:25 hmmmm https://github.com/minetest/minetest/commit/8eb9cebdd058c7df0c1735cd083f09d962c7bb84 08:30 hmmmm https://github.com/minetest/minetest/commit/6fdb32361a01ed385b36f941f4ad0d7e32ea288d 08:31 hmmmm oh shoot, that last one is going to change the protocol version, isn't it 08:31 hmmmm well it's a good time for that anyway 08:32 hmmmm actually nevermind, it never gets serialized 08:33 Calinou “nonsense” 08:33 Calinou I agree it was too game-specific, but respect other developers please 08:33 hmmmm he doesn't respect any of us 08:34 hmmmm i don't see why i should afford him any respect. and none of that "be the bigger man" stuff. 08:59 chchjesus hmmmm: Who? 14:20 Zeno` PilzAdam, Some of the aliases in the alias.lua files are not there for backwards compatibility (e.g. STSword), so putting them in legacy.lua is wrong. 14:20 Zeno` What are they in there for? 14:21 PilzAdam the /giveme command 14:58 Zeno` I think version numbers (of the engine) should be available to mods 14:58 Zeno` This is how every other engine/lib in the world works 14:59 Zeno` engine/game/lib 14:59 Zeno` If other software did not allow querying of the version the whole makefile/cmake/etc/etc would fall apart and be useless 15:00 Zeno` Even minetest queries the OpenGL version 15:34 celeron55 Zeno`: it's a political issue; i don't want to centralize minetest development in a way that breaks forks; everything that has a version has a central authority who decides what goes to which version 15:34 celeron55 s/everything/every API/g 15:35 celeron55 cutting off competition by political means is always a very bad idea for general progress 15:35 celeron55 and you can't even seriously disagree with that 15:35 Zeno` no, I can't 15:36 Zeno` that makes sense. Thanks 15:38 sapier https://github.com/minetest/minetest/pull/2043 merging in a few minutes (Android only change) 15:39 celeron55 Zeno`: currently minetest's modding api and mods are such that anyone can fork mientest and continue development to a better way without having to do *any* tricks whatsoever to maintain compatibility 15:40 celeron55 i belive this forces people including me to "keep it real" 15:40 Zeno` yep, I understand the argument now that you've made it clear 15:41 celeron55 also, as you mentioned opengl, it actually partly does the same: no program ever checks whether it supports the drivers by checking the opengl version number; they check if the particular extensions are supported that they need (and the extensions can be added by anyone and then later adopted by others) 15:41 celeron55 (or, they can, but it's bad behavior) 15:42 celeron55 the version just gives a general idea 15:51 sapier on opengl the version number is almost useless as most features are "optional" 16:06 sapier ShadowNinja if I ever meet you in person I'm gonna kick your ass this is the 3 time you break the android menu by doing some nonsense cleanup without testing 16:07 sapier there's been a reason why it was a separate menu, this way you could test it on pc where debugging is way more easy then on android devices 16:14 sapier And who the hell tells simple menu is android only?! 16:15 sapier I never seen a rule pc menus have to be overloaded and complex ;-P 16:54 Zeno` sapier, I have a cunning plant 16:54 Zeno` err plan 16:55 Zeno` Add comments to sections that sections of code that are the for a reason but maybe not obvious :p 16:55 sapier I can't do more then telling him this in person 16:55 sapier if someone doesn't understand it this way more text wont help 16:55 sapier ls 16:55 Zeno` You can't add a comment in the code? 16:56 sapier we're talking about a full file not some part of code 16:58 Zeno` so? 16:58 Zeno` Is a file not some part of code? :p 16:58 sapier well is there a line in game.cpp about this file beeing required? 16:58 Zeno` no idea off the top of my head. Is there? 16:59 sapier have a look at it 17:02 Zeno` not really sure what I'm looking for. The pause menu? 17:04 Zeno` are we talking about https://github.com/minetest/minetest/commit/c4e393deea4f1a6d242a3fdf392c463ed5a3b58d ? 17:04 sapier yes 17:04 sapier which is a non sense change as the simple menu is not by defininition android only 17:06 Zeno` hmm, fair enough 17:06 sapier so now we have a perfectly fine simplified menu which can only be used if you claim to run on android :-( 17:08 Zeno` yes :( 17:08 Zeno` Anyway I must sleep 17:08 sapier good night 18:02 Wuzzy Hi there. I wonder if something in the auth.txt format has changed lately significantly so that it breaks 0.4.11 worlds 18:03 Krock a timestamp has been added but that shouldn't be a problem 18:05 Calinou apparently it is for Wuzzy 18:05 Calinou 11:51:45: ERROR[main]: /usr/share/minetest/builtin/game/auth.lua:48: Invalid line in auth.txt: "singleplayer::" 18:05 Wuzzy My Tutorial World does not load in 663e42ca… but it loads in 0.4.11. 18:06 Wuzzy I shall post error output soon 18:07 Wuzzy Here it is: http://lpaste.net/raw/117753 18:07 Wuzzy This is the error I get when I try to load Tutorial World in 663e42ca… 18:08 rubenwardy https://github.com/minetest/minetest/blob/master/builtin/game/auth.lua#L48 18:09 rubenwardy It's because there is no password specified, it seems 18:09 rubenwardy Did it work after last_login was added? 18:09 Wuzzy what is this? 18:10 rubenwardy what? 18:10 Wuzzy oh, for you, here is the content of auth.txt of Tutorial World 18:10 Wuzzy “singleplayer::” 18:10 rubenwardy yes 18:10 Wuzzy that's all 18:10 rubenwardy singleplayer:password:privs:last_login 18:10 Wuzzy I tried deleting auth.txt and reload 18:10 Wuzzy it loaded again o_O 18:11 rubenwardy It is because there is no password string there. 18:11 Wuzzy and generated a new auth.txt 18:11 PilzAdam its probably because string.split() is used instead of match() 18:11 Wuzzy Generated auth.txt is “singleplayer::interact,shout:1420398524” 18:11 Wuzzy plus a line break 18:11 rubenwardy And does that work? 18:11 Wuzzy yes 18:12 Wuzzy But why did “singleplayer::” ever work in 0.4.11 in the first place? xD 18:13 Wuzzy anyways, I think I provided enough proof to show that 0.4.11 and older worlds are currently not compatible with the bleeding edge 18:15 rubenwardy https://github.com/minetest/minetest/commit/ab55da589c27e65e54956b32a1550e21169447ae 18:15 rubenwardy That's the problem 18:15 rubenwardy Changed string:split 18:15 rubenwardy * probably the problem 18:15 PilzAdam it seems that string.split() with include_empty does not return an empty string after the last delimiter 18:15 PilzAdam ^ ShadowNinja 18:16 Wuzzy ok. Say my name if you fixed the bug so I can pull it and test it on Tutorial World 18:19 ShadowNinja kaeza: ^ 18:19 rubenwardy Lol 18:19 ShadowNinja sapier: Include things like this in your local tree: https://github.com/minetest/minetest/commit/21ee434832126f288c58f5a9cd2a3b509946319c 18:20 ShadowNinja sapier: Or just modify init.lua. It's a temporary change after all. 18:20 ShadowNinja And my commit was definitely an improvement, seing as you added that back with two lines of code instead of copying the whole file.. 18:21 sapier no I will not do this because I already know how often this gonna be merged 18:21 sapier especially as your change is crap 18:21 sapier you made something not beeing android specific artificially android specific 18:22 sapier there'*s not a single reason why a simple menu shouldn't be used on pc mac or any other os 18:23 ShadowNinja sapier: init_android.lua doesn't suggest Android-specific to you? Because it sure does to me. 18:24 sapier well if you did one time read what you change you'd have relaized that filename is wrong and not content 18:24 ShadowNinja sapier: And I agree, a lot of Android-specific things shouldn't depend on that particular OS. 18:24 ShadowNinja But I didn't write the Android stuff. 18:25 PilzAdam ShadowNinja, I agree with sapier, init_android.lua should have just been renamed to init_simple.lua or so 18:25 sapier tell me where I used ANDROID where it ain't required? because I specially did look at which features are specific to android and which could be used elsewhere 18:25 ShadowNinja sapier: You can change it to use simple_menu = true/false in minetest.txt. 18:25 ShadowNinja sapier: Please make it false on Android though. 18:25 rubenwardy s/minetest.txt/minetest.conf ? 18:25 sapier ShadowNinja: because of what reason? we already have a setting where you can enable any menu not only those provided in builtin 18:26 ShadowNinja PilzAdam: Have you seen the old init_android.lua? It was just `cp init.lua init_android.lua` with minor modifications. 18:26 ShadowNinja PilzAdam: Not only that, but it bypassed the builtin init.lua, breaking things like print() and the locale. 18:26 sapier ShadowNinja: true because simple menu did provide similar things 18:26 ShadowNinja rubenwardy: Yes. 18:26 PilzAdam ah, didn't see that 18:26 rubenwardy ok 18:27 sapier new one will fake android switch wich is just crap but best without resplitting it again 18:27 PilzAdam ShadowNinja, there should still be 2 different init_*.lua, since you can choose your menu script in minetest.conf 18:27 PilzAdam no need to check any OS for that 18:27 ShadowNinja sapier: Please make a PR, or at least post a patch here, before changing ti further. 18:28 sapier I already changed it so I can fix the bugs in there again if you don't break this a 4th time I don't intend do change anything there 18:28 PilzAdam ShadowNinja, maybe move the duplicated parts to a init_all.lua or so? 18:28 ShadowNinja PilzAdam: Just have simple_menu = true/false or menu_type = normal/simple in minetest.conf instead, no need to change the file loaded. 18:29 sapier ShadowNinja: NO 18:29 sapier why ANOTHER menu config setting 18:29 PilzAdam why provide extra settings for functionality that is already provided? 18:29 sapier next time we have a new menu for tablets then we add tablet_menu= true false? 18:29 ShadowNinja sapier: It was broken to begin with, and http://xkcd.com/1172/ 18:29 PilzAdam add a comment that you can point it to the simple.lua file, thats enough 18:30 ShadowNinja PilzAdam: that's a lot simpler than telling users to set the script path to a different file. 18:30 hmmmm yeehaw... 18:31 sapier still the script path is already there and provides the required functionality 18:31 ShadowNinja sapier: Or menu_type = tablet, or better yet just make the menu adapt by itself. 18:31 sapier AND script path is the better way doing it because it enables total conversions to write their own menu 18:31 sapier why two settings for same thing? 18:32 sapier still if you want to ADD your nonsense menu_type, do it but don't expect me to consider it as a sane solution 18:32 hmmmm maybe there should be a device profile setting that's a setting and gets autodetected if not present 18:32 ShadowNinja sapier: Yes, but that's only intended for anvanced users that want to replace the whole menu. It's a much more complicated setting than what I'm proposing. 18:32 hmmmm device_type = tablet, device_type = smartphone, etc.. in addition to setting the menu stuff it'll load performance profiles to enable/disable certain things 18:32 ShadowNinja IMO wo shouldn't have two menu styles in the first place. 18:32 hmmmm I think it's a good idea 18:32 ShadowNinja we* 18:33 sapier same as last time as long as you don't break things I don't really care ... sadly you did it again 18:33 hmmmm the alternative is to have one menu that works with both mobile and desktop and lots of things that work for desktop don't work for mobile 18:33 sapier that's not gonna work 18:33 hmmmm this is how you get firefox-type fuckups 18:33 ShadowNinja hmmmm: Some smartphones are really powerfull, some are weak, some have big screens, others tiny... 18:33 hmmmm say no to australis for minetest 18:33 sapier range of screen sizes and dpi is just to big 18:33 VanessaE jesus fuck. stop arguing and just fix the problem, guys 18:34 VanessaE two menu files. a config option to select which one is used for the platform in question. default to the "complex"/PC one if no config option is specified. 18:34 VanessaE it does NOT need to be more complicated than that. 18:34 rubenwardy "Jesus fuck" 18:34 hmmmm what, I say that sometimes 18:34 Wuzzy by the way, how is “singleplayer::” in auth.txt supposed to work/what does it mean? 18:35 ShadowNinja hmmmm: The desktop menu works fine on Android AFAIK, and I prefer it because the Android(/"simple") one only lets you manage one world. 18:35 hmmmm VanessaE: I think it should autodetect if not present 18:35 sapier we already have two menus and default to the complex one 18:35 PilzAdam ShadowNinja, kaeza, about that auth.txt thing: I just tested it, and ab55da589c27e65e54956b32a1550e21169447ae definetly broke the old behaviour that returned an additional "" after the last ":" 18:35 hmmmm ShadowNinja, does that hold true for lower-DPI devices? 18:35 VanessaE hmmmm: I'd prefer that too but as we've seen in the past, auto-detect isn't as graceful as one would like it to be. 18:35 hmmmm it should be pretty easy to detect mobile 18:35 hmmmm and reliable 18:35 ShadowNinja Wuzzy: user="singleplayer", password="", privs = {} 18:35 sapier ShadowNinja: desktop menu doesn't work at all at low screensize android devices 18:36 VanessaE hmmmm: that's the keyword, "should" :-) 18:36 ShadowNinja hmmmm: It will probably be hard to use, but the Android menu is the same size IIRC. 18:36 sapier hmmmm I agree it "should" but in practice it's almost impossible to always find correct settings automaticaly 18:36 ShadowNinja hmmmm: (or at least very close) 18:36 PilzAdam Wuzzy, you could test your world with 86cfbc21da10e9984a1b9f8f2f5bf259fba5efb9 and then with ab55da589c27e65e54956b32a1550e21169447ae to confirm that the latter one broke it 18:36 VanessaE rubenwardy: that's a short form of "jesus fucking christ". 18:37 sapier ShadowNinja: no because of important buttons aren't visible on some low screen size devices 18:37 rubenwardy I believe that's called masturbation 18:37 VanessaE lol 18:37 hmmmm I always thought it was when you had a situation where you need to say "jesus christ" but you're super flabbergasted at whatever it is 18:37 Wuzzy ShadowNinja: Weird. That would mean no interact either. But I know in Tutorial World I amsolutely can interact with “singleplayer::” as auth.txt 18:37 Wuzzy PilzAdam: I am on my way 18:37 VanessaE hmmmm: indeed. 18:37 rubenwardy Wuzzy, default_privs in minetest.conf 18:38 hmmmm ugh 18:38 Wuzzy oh shit. This means I need to update. 18:38 hmmmm really hate typing 18:38 ShadowNinja Wuzzy: You get all privs that aren't give_to_singleplayer=false, even if they're not in auth.txt. 18:38 hmmmm ManualMapVoxelManipulator 18:38 sapier crap new ssl version doesn't work after cleaning all 18:38 hmmmm AbstractManualMapVoxelManipulatorManagerFactory 18:38 Wuzzy ShadowNinja, rubenwardy: WTF? 18:39 sapier << leaving to fix the ssl issue ... DONT break menu again! 18:39 Wuzzy You gave me 2 different answers 18:39 ShadowNinja Wuzzy: -> #minetest 18:39 hmmmm what's the most efficient way to break the menu? 18:39 rubenwardy oh 18:39 rubenwardy ShadowNinja is right 18:39 rubenwardy hmmmm: core = core / 0 18:39 ShadowNinja hmmmm: error() in init.lua 18:39 hmmmm :D 18:41 VanessaE stick a spurious comma somewhere ;) 18:41 VanessaE if you wanna both break it and be evil about it ;) 18:41 ShadowNinja hmmmm: Actually, running ./bin/minetest-noexist is even faster :-P 18:41 rubenwardy IMO, the menu is currently too techie and not enough gamie. Most games use buttons instead of tabs.https://jarime.files.wordpress.com/2011/12/terraria6.png 18:42 rubenwardy But it doesn't matter that much 18:45 hmmmm https://github.com/kwolekr/minetest/commit/10d24b48f387a642ceea85d3703748c46f34c78e 18:50 Wuzzy PilzAdam: I tested it for both commits. It works in the first one but it fails in the second one. 18:51 PilzAdam q.e.d. 18:53 Wuzzy ok, just tell my name in chat when you fixed it yadda yadda. Or should I open an issue on GitHub? 18:58 ShadowNinja #2046 18:58 ShadowBot https://github.com/minetest/minetest/issues/2046 -- Remove included SQLite3 by ShadowNinja 18:59 ShadowNinja I also wrote a version for JsonCpp, but I had trouble getting it to work (CMake couldn't find the include directory, but it found the library fine) 21:35 ShadowNinja http://sprunge.us/ZVPa?diff 21:36 ShadowNinja Any objections? 21:36 hmmmm nope 21:36 sfan5 looks good 21:36 hmmmm probably should do the same thing for decorations though 21:41 ShadowNinja Alright, I'll do that. I'll see if there's a make_redistration_storer or similar or make it though. 22:53 kaeza PilzAdam, hm? 22:54 PilzAdam kaeza, string.split(":", ":", true) should return {"", ""} instead of just {""} 23:06 kaeza PilzAdam, oops 23:06 kaeza PilzAdam, https://github.com/minetest/minetest/blob/master/builtin/common/misc_helpers.lua#L181 --> s/len/len+1/ 23:06 kaeza guess the test suite missed some cases... 23:11 kaeza ShadowNinja, https://github.com/minetest/minetest/pull/2047 23:20 paramat hmmmm, https://github.com/minetest/minetest/issues/1727#issuecomment-68627007 23:29 paramat any mod that uses lvm to add mapchunks to a v5/6/7 world has to use vm:set_lighting({day=0, night=0}) i'll test such a mod v. soon 23:35 paramat https://cloud.githubusercontent.com/assets/3686677/5607999/557f6c48-946a-11e4-8c51-e8c93dafb629.png closeup