| Time |
Nick |
Message |
| 00:01 |
|
Anchakor_ joined #minetest-dev |
| 00:05 |
|
Taoki joined #minetest-dev |
| 00:16 |
|
OldCoder joined #minetest-dev |
| 01:17 |
Warr1024 |
http://i.imgur.com/lKHlzQB.png |
| 01:20 |
VanessaE |
loking good, Warr1024 |
| 01:20 |
Warr1024 |
btw, the inverting isn't based on the LSB, it's the 2nd LSB |
| 01:20 |
VanessaE |
+o |
| 01:20 |
Warr1024 |
so if I expand the image by 2px, it inverts |
| 01:20 |
VanessaE |
strange |
| 01:20 |
Warr1024 |
my guess is it has something to do with the way inventory cubes are created |
| 01:20 |
Warr1024 |
they're rendered to a virtual scene then resized to 64x64 |
| 01:21 |
VanessaE |
what scaling algo are you using now? |
| 01:21 |
Warr1024 |
resizing the image by 2px would be what would change the screen half-size between even/odd. |
| 01:21 |
VanessaE |
(I ask because that dry shrub looks a bit blurry) |
| 01:21 |
Warr1024 |
my algo is basically a linear filter. |
| 01:21 |
Warr1024 |
blurry is sort of a consequence of resizing a 16x16 image to 49x49 |
| 01:21 |
VanessaE |
*nod* |
| 01:22 |
Warr1024 |
the lanczos you were playing with compensates by sharpening, but it's a bit beyond what I'm working with here. |
| 01:22 |
Warr1024 |
also, dunno how lanczos handles alpha channels, which is where the blur is really noticeable |
| 01:22 |
VanessaE |
that one is the result of your in-world filter? |
| 01:23 |
Warr1024 |
you mean the texture filter? |
| 01:23 |
Warr1024 |
that's not in this branch |
| 01:23 |
VanessaE |
oh ok |
| 01:23 |
VanessaE |
and yeah |
| 01:23 |
Warr1024 |
there's not a hell of a lot I can really do; any non-integer scale risks blur |
| 01:23 |
VanessaE |
I meant the one you had in that other pull for the in-world filtering-with-threshold |
| 01:24 |
Warr1024 |
oh, yeah, that one |
| 01:24 |
VanessaE |
no worries then |
| 01:24 |
Warr1024 |
the one where I fake the RGB values of transparent pixels |
| 01:24 |
Warr1024 |
I had to pull in an adaptation of that here. |
| 01:24 |
VanessaE |
in any case it's a vast improvement over what was the case before |
| 01:24 |
Warr1024 |
I wonder if maybe I should merge this with my other pullreq, since they share some common logic. |
| 01:24 |
Warr1024 |
it's an improvement if I can squash that upside-down texture bug. |
| 01:26 |
|
Zeno` joined #minetest-dev |
| 01:27 |
Warr1024 |
yeah, the bug must definitely be in the inventoryimage generator |
| 01:28 |
Warr1024 |
even if I do nothing but convert the texture to an image and then back, it's still flipped. |
| 01:28 |
Warr1024 |
there must be some internal bit on the texture on the image to control its flippedness that's not propagated to the image. |
| 01:42 |
Warr1024 |
holy crap, all that code I was manipulating made no diff because it was all in an #ifdef __ANDROID__ block I didn't notice |
| 01:42 |
Warr1024 |
which I guess might explain why android nodes are upside-down... |
| 01:47 |
Zeno` |
heh |
| 01:50 |
Warr1024 |
Zeno`: http://i.imgur.com/lKHlzQB.png |
| 01:51 |
Warr1024 |
made them look better, but now I've got a weird issue where they flip upside down if the target rectangle is an odd number of px height/width. |
| 01:53 |
Zeno` |
err, that does sound very weird |
| 01:54 |
Warr1024 |
https://github.com/Warr1024/minetest/commits/guiscaling |
| 01:54 |
Warr1024 |
it's definitely not a problem with the drawing |
| 01:54 |
Warr1024 |
er, teh scaling filter |
| 01:54 |
Warr1024 |
I think the problem is we render to texture and then I convert texture back to image for the scaling filter |
| 01:55 |
Warr1024 |
and the texture->image->texture round trip has some isse |
| 01:55 |
Warr1024 |
like the ITexture I'm looking at has some hidden isFlipped bit that's not accessible on ITexture. |
| 01:55 |
Warr1024 |
or maybe it's a bug in the driver trying to pull it from video to main memory |
| 01:56 |
Warr1024 |
the filter is basically an box filter, i.e. anti-aliased nearest-neighbor. |
| 01:57 |
Warr1024 |
should make non-exact-integer-scaled images look like non-crap. |
| 01:57 |
Warr1024 |
works nicely, aside from seriously messy code and that one damn caveat. |
| 01:58 |
Warr1024 |
ah, good, I thought I found a 2nd bug, but apparently it's an upstream one. |
| 01:58 |
VanessaE |
Warr1024: something must be wrong. |
| 01:58 |
|
OldCoder joined #minetest-dev |
| 01:58 |
VanessaE |
Warr1024: because I ...think I understand this code. O_O |
| 01:59 |
Warr1024 |
resize your screen to very narrow like a portrait phone, and the invbar and hud get kinda messed up |
| 01:59 |
Warr1024 |
VanessaE: :-) |
| 01:59 |
|
OldCoder joined #minetest-dev |
| 02:00 |
Warr1024 |
I thought that iterating over images using getPixel in nested loops would be horribly slow, until I read a bit of the Irrlicht source code and saw that that's exactly what they do in many places. |
| 02:00 |
Warr1024 |
I figured it'd have some kind of fancy 2D accel for things like that, but I guess it just leans on the compiler to provide decent optimizations. |
| 02:02 |
Warr1024 |
it's almost tempting to write a very lightweight software renderer just to parse the node meshes and render those inventory cubes |
| 02:04 |
Zeno` |
sy <= maxs32sy ? |
| 02:04 |
Warr1024 |
Zeno`: I don't know a shitload about optimizing compilers |
| 02:04 |
Warr1024 |
but I didn't really want to do a cast inside a loop |
| 02:04 |
* kahrl |
is suddenly reminded of https://github.com/kahrl/minetest/commits/optimize_invtex |
| 02:04 |
Warr1024 |
where the result value would always be the same. |
| 02:05 |
VanessaE |
Warr1024: there's already a software renderer in irrlicht....... |
| 02:05 |
Warr1024 |
yeah, I played with it |
| 02:05 |
Warr1024 |
there are 2, actually |
| 02:05 |
VanessaE |
yeah |
| 02:05 |
Warr1024 |
one that works poorly and one that's pretty much useless |
| 02:05 |
VanessaE |
probably not good enough to do what you have in mind |
| 02:05 |
Warr1024 |
I tried playing in fullscreen in BurningsVideo, and it feels like I'm playing Minecraft again, only still with better drawdist. |
| 02:06 |
Warr1024 |
well, my idea was a fake renderer that'd actually do all the work in 2d |
| 02:06 |
Warr1024 |
since it's an isometric projection, it's just a simple transformation matrix. |
| 02:06 |
Zeno` |
kahrl, interesting :) |
| 02:06 |
Zeno` |
Maybe you should look at kahrl's link, Warr1024 |
| 02:06 |
Warr1024 |
kahrl: why did work stop on this, and/or why not make a pullreq? |
| 02:07 |
Warr1024 |
for one thing, I know android will probably benefit |
| 02:07 |
Warr1024 |
render-to-texture is very finnicky and not very portable. |
| 02:07 |
Warr1024 |
all the android images right now are upside-down, except for glass, which is just trash for me. |
| 02:07 |
kahrl |
it was buggy and I didn't figure out a way to fix it |
| 02:07 |
Warr1024 |
maybe I'll have to pull it |
| 02:08 |
kahrl |
can't remember what exactly the problems were |
| 02:08 |
Warr1024 |
see if I can beat it into good enough shape to at least compete with the turd running on android right now |
| 02:08 |
kahrl |
in any case, it was orders of magnitude faster than render-to-texture, on my machine at least |
| 02:08 |
Warr1024 |
nice |
| 02:09 |
Warr1024 |
ok, here's a weird thing |
| 02:09 |
Warr1024 |
images are either always upside-down or right-side-up for a given target size |
| 02:09 |
Warr1024 |
depending on odd or even |
| 02:09 |
Warr1024 |
but apparently on subsequent runs, whether odd or even are the upsidedown ones changes...? |
| 02:10 |
Warr1024 |
the first time I open my inventory, it's always upside-down |
| 02:10 |
Warr1024 |
then if I resize the window, it inverts depending on the LSB of the size. |
| 02:11 |
Warr1024 |
so if I maximize the window, open my inventory, then restore, the images are fine whenever I'm not maximized |
| 02:11 |
Warr1024 |
but if I open my inventory the maximize, they're fine when I AM maximized. |
| 02:12 |
Warr1024 |
kahrl: I kind of wouldn't care if your renderer were actually faster, since there's the potential to make it less buggy, but for RTT, I don't think there's much we can do other than layer on workarounds. |
| 02:13 |
Warr1024 |
just about the only thing I think I can do right now for this pull request will be either (1) some awful heuristic hack to detect upside-down shit and flip them, or (2) just exclude inventory elements from filtering for now. |
| 02:13 |
* Zeno` |
compiles it |
| 02:14 |
Zeno` |
I did something similar to this a *long* time ago but I used a modified breshenhams algo (well, I used the error accumulator idea from that) |
| 02:15 |
Warr1024 |
whoa, and glass is NOT upside down for me |
| 02:15 |
Zeno` |
back when FPUs were not common heh |
| 02:15 |
kahrl |
Zeno`: yeah, that could potentially be even faster |
| 02:16 |
kahrl |
I didn't bother with that because I wanted to fix the bugs first :P |
| 02:16 |
Warr1024 |
holy shit, glass is una-f***ing-ffected. |
| 02:16 |
Zeno` |
kahrl, of course |
| 02:16 |
Zeno` |
get it to work, then optimise... the standard rule |
| 02:17 |
Warr1024 |
Zeno`: my filter is pretty much a completely unoptimized naive box filter; it works well for me mainly because I cache the generated images permanently, and the source images are generally not huge to begin with. |
| 02:17 |
Warr1024 |
though I wouldn't mind seeing how some of my stuff behaves on against a modpack with insane texture sizes. |
| 02:17 |
Zeno` |
Warr1024, if they're cached then optimisation may not be worth the hassle (it probably wouldn't be) |
| 02:17 |
Warr1024 |
you can still almost always process images faster than they're loaded from disk. |
| 02:18 |
Zeno` |
grr I have to look at the src code again |
| 02:18 |
Zeno` |
save me the time... anything special I need to do to enable this? |
| 02:18 |
Warr1024 |
yeah, config |
| 02:18 |
Warr1024 |
gui_scale_filter = true |
| 02:19 |
Zeno` |
k |
| 02:20 |
Zeno` |
lol at my config |
| 02:20 |
Zeno` |
I just noticed this: |
| 02:20 |
Zeno` |
new_style_leaves = true |
| 02:20 |
Zeno` |
pooh = 21 |
| 02:20 |
Zeno` |
I wonder what I was doing... :3 |
| 02:22 |
Warr1024 |
combine this patch (assuming we can work out the bugs) with my other one for the 3d textures, and we can get this game looking damn smooth. |
| 02:22 |
Warr1024 |
I remember playing minecraft and wondering why it didn't let you enable texture filtering. |
| 02:23 |
Warr1024 |
but I still got like 15fps with a draw dist of 32 in it |
| 02:23 |
Warr1024 |
probably because they recalculated all the geometry every frame |
| 02:23 |
Warr1024 |
now I'm starting to get used to a fully-filtered MT at 15fps and a 256 draw dist on my old-ass laptop |
| 02:24 |
Warr1024 |
15 is my wanted_fps; I don't get involved in a lot of action, and I like to be ready to take HQ screenshots :-) |
| 02:28 |
Warr1024 |
btw, sorry about my abuse of errorstream; I couldn't figure out where the messages went when I was using infostream... |
| 02:34 |
Warr1024 |
http://i.imgur.com/doE76WJ.png |
| 02:35 |
Warr1024 |
world and GUI filters both. |
| 02:36 |
Warr1024 |
It's still quite playable on an IGP from about 5 years ago; seems to run about as well as with all filters off |
| 02:36 |
VanessaE |
the 3d/in-world seems a bit blurry compared to the screenshots you provided the other day? |
| 02:38 |
VanessaE |
(particularly that near cactus and the wielded cobble stairs) |
| 02:38 |
Warr1024 |
just noticed that glass actually has an [inventorycube{ image, while the others are using RTT, so that explains THAT. |
| 02:38 |
Warr1024 |
VanessaE: I'm a lot closer to that cactus that I was before |
| 02:39 |
VanessaE |
oh ok |
| 02:39 |
Warr1024 |
I run my textures at 64x, and it doesn't bother me; if it bothers you, you could go up to 128x or higher. |
| 02:39 |
|
OldCoder joined #minetest-dev |
| 02:39 |
VanessaE |
Warr1024: no worries. just taking note of it is all. |
| 02:39 |
VanessaE |
makes it look like a focus-limit filter :) |
| 02:40 |
Warr1024 |
:-) |
| 02:42 |
Zeno` |
it's a large aperture filter |
| 02:42 |
Zeno` |
heh |
| 02:43 |
Zeno` |
not all images are upside down |
| 02:44 |
Warr1024 |
yeah |
| 02:44 |
Warr1024 |
which ones are you seeing? |
| 02:45 |
Warr1024 |
I think it's only true RTT's that are upside down |
| 02:45 |
Zeno` |
http://i.imgur.com/31AuLqI.jpg |
| 02:45 |
Warr1024 |
some nodes use an [inventorcube{ image, which are done in 2D, and are thus not affected |
| 02:45 |
Zeno` |
so jungle leaves are ok... normal leaves, not ok |
| 02:45 |
Warr1024 |
weird that |
| 02:46 |
Warr1024 |
them hearts are antialiased too |
| 02:47 |
Zeno` |
grrr, cavegen is using unitialised values again |
| 02:47 |
Warr1024 |
I've mostly been playing MP on a 0.4.12 server, so testing out in SP today was the first I ran into the "HUD/inventory not updating when I eat an apple" bug. |
| 02:47 |
Warr1024 |
it's somewhere near the top of the issues on github... |
| 02:48 |
Zeno` |
memory leak in Server::ProcessData() ... interesting |
| 02:48 |
Warr1024 |
you gotta admit, it may be wrong, but at least it's pretty :-) |
| 02:48 |
Warr1024 |
it's also quite different from the android issues |
| 02:49 |
Warr1024 |
for one, on android, the mesh generation is all messed up; here, it uses the correct mesh, and rasterizes it fine, just ends up flipping the finished image |
| 02:49 |
Warr1024 |
then I guess what that means is maybe it's [inventorycube{ that's actually messed up on android...? |
| 02:50 |
Warr1024 |
since that's what glass uses...? |
| 02:50 |
Warr1024 |
and my glass-materialed nodeboxes are fine |
| 02:50 |
VanessaE |
glass doesn't need to use that feature anymore, kahrl fixed the normals in that drawtype a while ago |
| 02:51 |
VanessaE |
btw, your minetest_game is out of date. |
| 02:52 |
VanessaE |
WAY out of date :) |
| 02:52 |
VanessaE |
zeno ^^ |
| 02:53 |
Warr1024 |
ha, I just assumed it was a different gametype that "borrowed" some of the old textures. |
| 02:53 |
Warr1024 |
mt has the very best fjords |
| 02:54 |
Zeno` |
VanessaE, i kind of know that :) |
| 02:54 |
Zeno` |
it's the commit before minetest next was merged |
| 02:55 |
VanessaE |
oh right, forgot |
| 02:55 |
Warr1024 |
I hope mgv7 still has nice fjords... |
| 02:55 |
Warr1024 |
minetest next? |
| 02:55 |
Zeno` |
hdx-128 looks nice with this scaling/smoothing business |
| 02:55 |
VanessaE |
Warr1024: https://github.com/BlockMen/minetest_next |
| 02:56 |
Warr1024 |
had controversial artwork? |
| 02:56 |
VanessaE |
BlockMen was maintaining minetest_game in a so-named separate branch for a while, eventually that merged into minetest_game mainline. a few problems sprung up at the time but I think they've all been ironed out |
| 02:57 |
VanessaE |
s/branch/fork/ |
| 02:57 |
Warr1024 |
VanessaE: they're practically the same thing, the way git is designed... |
| 02:57 |
Warr1024 |
Zeno`: if you're using 128x textures to begin with, they probably won't be upscaled unless you set your texture_min_size above 128 |
| 02:58 |
Warr1024 |
Zeno`: BUT if you're on a world with a mix of texture sizes the texture_min_size thing will scale them up |
| 02:58 |
Warr1024 |
GUI scaling doesn't need any fine-tuning |
| 02:58 |
Warr1024 |
nor does the transparency fix |
| 03:00 |
Warr1024 |
hm, one drawback to the transparency thing is that it does weird things to non-fancy trees |
| 03:00 |
Warr1024 |
because non-fancy trees are a weird alpha hack themselves |
| 03:00 |
Warr1024 |
they DO blend nicely though in the distance |
| 03:02 |
Warr1024 |
hm, it was actually better when I had the filters applied in the other order |
| 03:02 |
Warr1024 |
though doing that had its own cost in terms of load time |
| 03:07 |
Zeno` |
they're upscaled in the world though aren't they? |
| 03:08 |
Warr1024 |
well, first I apply the transparency filter |
| 03:08 |
Warr1024 |
then I upscale them |
| 03:08 |
Warr1024 |
so I save the cost of having to transparency filter the extra pixels, since, for normal transparent textures, the end-result is the same |
| 03:09 |
Warr1024 |
except for trees, where transparent gets baked into black, I guess it would have been better to do it the other way around? |
| 03:09 |
Warr1024 |
but that's such a weird corner-case... |
| 03:09 |
Warr1024 |
frankly, the way the fanciness of leaves works is a bit bizarre to me |
| 03:10 |
Warr1024 |
the fact that that one optimization is so highly positioned as a setting to warrant a dedicated checkbox for it is dependent on a lot of assumptions about the game/mods/mapgen the user will be using.. |
| 03:10 |
Zeno` |
yuck, I am getting nasty spikes in drawtime |
| 03:11 |
Warr1024 |
related to my patches? |
| 03:11 |
Warr1024 |
I also gotta see how the inventory/gui filter looks on droid. |
| 03:11 |
Zeno` |
not related |
| 03:12 |
Zeno` |
it's nasty |
| 03:12 |
Zeno` |
my drawtime spikes from 4 to ~60 |
| 03:12 |
Zeno` |
fortunately I can repeat it |
| 03:13 |
Zeno` |
wtf would be causing that?! |
| 03:13 |
Warr1024 |
I've actually seen a lot less spikege than I used to |
| 03:13 |
Warr1024 |
IIRC mesh recalcs can be bad |
| 03:13 |
Zeno` |
I've never seen this before |
| 03:14 |
VanessaE |
Zeno`: got anything causing periodic mesh regens? like a mesecons blinky plant? |
| 03:14 |
Zeno` |
VanessaE, no |
| 03:14 |
Zeno` |
this is an area of my test world I use in testing a lot |
| 03:14 |
Zeno` |
I've never seen it before |
| 03:14 |
Zeno` |
it's a complete freeze then the scene redraws |
| 03:14 |
VanessaE |
minimal game, no mods, I assume? |
| 03:15 |
Zeno` |
bizarre |
| 03:15 |
Zeno` |
yeah |
| 03:15 |
Zeno` |
it's a jungle tree area where drawtime has always been longer but not with spikes/freezes like this |
| 03:16 |
VanessaE |
that sounds like something "spooling up" and then dumping out after a while |
| 03:17 |
VanessaE |
meshes being sent to the GPU getting hung up somewhere in a cache maybe? |
| 03:19 |
Zeno` |
I would have noticed it before now; it's one of my controlled test areas I used for optimising the previous 2 releases |
| 03:19 |
Warr1024 |
that one black pixel on the wall-torch animation is driving me nuts |
| 03:20 |
* VanessaE |
hides from Warr1024 |
| 03:20 |
Zeno` |
*sigh* I'm going to have to bisect I suppose |
| 03:21 |
VanessaE |
that black pixel was supposed to be coal tar or something similar |
| 03:21 |
VanessaE |
the torches are actually downscaled and tweaked from the ones I made for HDX |
| 03:21 |
Zeno` |
lol I can force packets to be lost |
| 03:22 |
Zeno` |
walk into the jungle leave, lose 4 packets |
| 03:22 |
VanessaE |
how? |
| 03:22 |
Warr1024 |
a lot must have been lost in the downscale |
| 03:22 |
Zeno` |
rinse and repeat |
| 03:22 |
Warr1024 |
seems like the coal tar should be always visible or never... |
| 03:22 |
VanessaE |
Warr1024: indeed so: https://github.com/VanessaE/hdx-512/blob/master/default_torch.png |
| 03:23 |
Warr1024 |
actually, one network bug that's been bothering me is that when my master-branch client quits my 0.4.12 server, sometimes the server never seems to get the quit packet and thinks I'm still logged in |
| 03:23 |
Warr1024 |
I'm on a wired network, so I REALLY shouldn't be seeing dropped packets. |
| 03:23 |
Warr1024 |
VanessaE: wow, holy shit that's a downscale if I ever saw one |
| 03:24 |
VanessaE |
yep. looks better than what we had before though :) |
| 03:24 |
Zeno` |
I'm not even on a network... well unless you call 127.0.0.1 a network, which it is, but it's neither wired nor wireless |
| 03:25 |
Zeno` |
what troubles me is it always drops packets when I walk into these leaves |
| 03:25 |
VanessaE |
Zeno`: well technically it would be a wired network, albeit an extremely fast one, wouldn't it? ;) |
| 03:25 |
Zeno` |
and always 4 |
| 03:26 |
Zeno` |
VanessaE, technically I suppose you're right |
| 03:26 |
VanessaE |
you're right, notwithstanding |
| 03:26 |
* Zeno` |
tries to work out how to trace this |
| 03:26 |
VanessaE |
but, always 4 packets just from walking into some leaves?? |
| 03:26 |
Zeno` |
a big bunch of leaves yes |
| 03:26 |
VanessaE |
you sure it isn't because you cross some arbitrary mapblock boundary or something? |
| 03:27 |
Zeno` |
I walk into them, lose 4 packets, back out, wait and walk into them again (lose 4 packets again) |
| 03:27 |
Zeno` |
no I'm not sure |
| 03:27 |
Zeno` |
checking |
| 03:27 |
VanessaE |
what happens if you manually force some of those leaves to snap into view by manipulating your min view range, without walking? |
| 03:27 |
VanessaE |
some of the leaves out PAST the ones you walked into I mean |
| 03:27 |
Zeno` |
they are in view. I have to be inside them |
| 03:28 |
Zeno` |
s/be/go inside |
| 03:28 |
VanessaE |
inside? as in non-walkable? |
| 03:28 |
Zeno` |
as in no clip into them |
| 03:28 |
VanessaE |
interesting |
| 03:28 |
VanessaE |
(same difference) |
| 03:29 |
VanessaE |
I just wondered if there was stuff coming into view out past those leaves, that might be triggering the packet loss somehow |
| 03:36 |
ShadowNinja |
Zeno`: Nocliping disables occlusion culling, could that be it? |
| 03:37 |
Zeno` |
ShadowNinja, maybe |
| 03:37 |
|
WarrTab joined #minetest-dev |
| 03:37 |
ShadowNinja |
Zeno`: Do the spikes repeat regularly? |
| 03:37 |
Zeno` |
http://dpaste.com/0C723ZG |
| 03:37 |
Zeno` |
nah once I'm "in there" they stop |
| 03:38 |
Zeno` |
I'll continue looking at my logs |
| 03:39 |
Zeno` |
not that it helps much |
| 03:39 |
Zeno` |
I think I'll run it under callgrind |
| 03:42 |
WarrTab |
Huh. So adding a cpp file to cmake doesn't seem to add it to the android build... |
| 03:42 |
Zeno` |
WarrTab, correct |
| 03:43 |
Zeno` |
add it to minetest/build/android/jni/Android.mk |
| 03:45 |
WarrTab |
That's kind of awkward... |
| 03:45 |
Zeno` |
I can think of a better word, but that's the way it is right now :) |
| 03:45 |
WarrTab |
I managed tonfigure it out with grep anyway; was jist remarking... |
| 03:46 |
WarrTab |
Sounds like we need a meta-meta-build process :-) |
| 03:46 |
Zeno` |
weta-meta! |
| 03:47 |
WarrTab |
Technically metameta == pata |
| 03:47 |
Zeno` |
well, I'll leave you to write the pata-build process (haha) |
| 03:48 |
WarrTab |
Makes me think it's time to uprgade to a sata-build process |
| 03:49 |
WarrTab |
Most of the stuff I build is basically gcc -o $(OUT) `find src -type f -name '*.c'` |
| 03:55 |
Zeno` |
gcc *.c |
| 03:55 |
Zeno` |
:D |
| 03:55 |
Zeno` |
works |
| 03:55 |
Zeno` |
the build when you're umm not really building |
| 03:55 |
Zeno` |
I have lots of those |
| 03:55 |
Zeno` |
haha |
| 03:55 |
WarrTab |
Cheapo one-step-compile-and-link |
| 03:56 |
Zeno` |
well not everything needs a makefile |
| 03:56 |
WarrTab |
np, everything does, but not every makefile needs to be more than 2 lines long... |
| 03:57 |
WarrTab |
Time to try this apk... |
| 03:59 |
WarrTab |
Total fail |
| 04:00 |
WarrTab |
Apparently I can't retrieve images back from the gpu on android |
| 04:00 |
WarrTab |
I figured portability could be a problem... |
| 04:00 |
Zeno` |
well that was an epic waste of time |
| 04:01 |
WarrTab |
Oh? |
| 04:01 |
Zeno` |
I forgot to callgrind_control -i on lol |
| 04:01 |
WarrTab |
Ha |
| 04:01 |
Zeno` |
I have a 15 minute call profile of... nothing |
| 04:01 |
WarrTab |
Well, I have a possible workaround, if I can intercept where images become textures |
| 04:01 |
WarrTab |
RTT's will still be tricky |
| 04:03 |
WarrTab |
We need some way to keep android from quitting if the activity is disposed |
| 04:04 |
WarrTab |
Sucks to tab out to respond to irc, load a link, and have mt get killed |
| 04:07 |
WarrTab |
Touchscreen controls are also counterintuitive |
| 04:08 |
WarrTab |
bot axes should benreversed, thougn not exactly either... |
| 04:09 |
WarrTab |
It's more like the thing you first touch should stay locked under your finger, and your view should rotate as necessary to keep that true |
| 04:10 |
WarrTab |
Tap-to-look would be nice too. |
| 04:13 |
|
neoascetic joined #minetest-dev |
| 04:35 |
|
neoascetic joined #minetest-dev |
| 04:39 |
|
neoascetic joined #minetest-dev |
| 04:40 |
|
Hunterz joined #minetest-dev |
| 05:24 |
|
chchjesus_ joined #minetest-dev |
| 06:15 |
|
Megaf joined #minetest-dev |
| 06:15 |
|
neoascetic joined #minetest-dev |
| 06:16 |
neoascetic |
why do we have all of this CUSTOM_bla-bla-bla variables? Why not simply redefine original variables with -DLOCALDIR, for example? |
| 06:21 |
|
neoascetic joined #minetest-dev |
| 06:28 |
|
neoascetic joined #minetest-dev |
| 06:34 |
|
manax joined #minetest-dev |
| 06:49 |
|
Hunterz joined #minetest-dev |
| 07:26 |
|
neoascetic joined #minetest-dev |
| 07:29 |
|
neoascetic joined #minetest-dev |
| 07:32 |
|
neoascetic joined #minetest-dev |
| 07:36 |
|
neoascetic joined #minetest-dev |
| 08:30 |
|
nrzkt joined #minetest-dev |
| 08:30 |
|
ImQ009 joined #minetest-dev |
| 08:32 |
|
Zeno` joined #minetest-dev |
| 08:32 |
nrzkt |
hi Zeno` |
| 08:32 |
Zeno` |
howdy |
| 08:33 |
Zeno` |
Only here for a moment (but will be back properly later on) |
| 08:33 |
nrzkt |
interesting conversation this night. Are you trying to improve rendering of the interface ? |
| 08:33 |
Zeno` |
interface? |
| 08:33 |
nrzkt |
gui |
| 08:33 |
Zeno` |
oh, not me. I was going to but WarrTab began before I got a chance |
| 08:34 |
Zeno` |
Since he's started I'll let him continue :) |
| 08:34 |
nrzkt |
that's good, more hands = precise tasks for other devs :p |
| 08:34 |
Zeno` |
Yeah. I've been testing his patch |
| 08:34 |
nrzkt |
good ? |
| 08:34 |
Zeno` |
it looks pretty good... well, apart from the upside down images heh |
| 08:34 |
nrzkt |
i see, what is the real improvement in fact ? |
| 08:35 |
Zeno` |
just better scaling |
| 08:35 |
Zeno` |
of images |
| 08:36 |
nrzkt |
okay :) |
| 08:42 |
Zeno` |
I'm going to add memset(this->heightmap, 0, csize.X * csize.Z * sizeof(*this->heightmap)); to the constructor of MapgenV6 because it's using unititialised values again |
| 08:43 |
|
FR^2 joined #minetest-dev |
| 08:43 |
|
Dartmouth joined #minetest-dev |
| 08:43 |
Zeno` |
will merge in a second |
| 08:46 |
|
kilbith joined #minetest-dev |
| 08:53 |
nrzkt |
okay |
| 08:57 |
Zeno` |
for reference, https://gist.github.com/Zeno-/37566659c0e442605771 |
| 08:58 |
nrzkt |
good :) |
| 08:59 |
Zeno` |
I sent paramat a memo as well |
| 08:59 |
Zeno` |
ok, will be back later :) |
| 09:05 |
|
Dartmouth joined #minetest-dev |
| 09:21 |
|
neoascetic joined #minetest-dev |
| 09:40 |
|
selat joined #minetest-dev |
| 09:43 |
neoascetic |
Hi, could someone help me with testing of #2471 on windows? |
| 09:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/2471 -- Implement dependencies copying to target directory on OSX by neoascetic |
| 09:49 |
|
est31 joined #minetest-dev |
| 09:54 |
|
sofar joined #minetest-dev |
| 10:21 |
|
proller joined #minetest-dev |
| 11:08 |
|
proller joined #minetest-dev |
| 11:19 |
|
crazyR joined #minetest-dev |
| 11:19 |
|
crazyR joined #minetest-dev |
| 11:30 |
|
proller joined #minetest-dev |
| 11:33 |
|
Dartmouth joined #minetest-dev |
| 11:36 |
|
Dartmouth_ joined #minetest-dev |
| 12:08 |
|
selat joined #minetest-dev |
| 13:03 |
|
Zeno` joined #minetest-dev |
| 13:06 |
Zeno` |
who would have thought tooltips would be such a controversy :/ |
| 13:06 |
Zeno` |
bugger adding an option to turn them off. Either add them or not |
| 13:06 |
Zeno` |
Personally I think add them |
| 13:10 |
Zeno` |
But if the decision is made to not add them it probably should be a very good reason :) |
| 13:11 |
est |
where? |
| 13:11 |
Zeno` |
#2438 |
| 13:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/2438 -- Add tooltips for many elements of the main menu by Wuzzy2 |
| 13:13 |
Zeno` |
I'm not sure how tooltips in the main menu can distract anybody |
| 13:13 |
Zeno` |
heck, I hardly even look at the main menu |
| 13:14 |
nrzkt |
right, or maybe wait 1 sec before showing it ? :) |
| 13:14 |
est |
yup |
| 13:14 |
est |
that should be done |
| 13:14 |
est |
like normal tooltip |
| 13:14 |
est |
tooltips* |
| 13:14 |
est |
1 sec or .5 sec or whatever |
| 13:15 |
est |
instantaneous is not good |
| 13:15 |
est |
I mean no program does instantaneous toltips do they? |
| 13:15 |
Zeno` |
it's not instant |
| 13:16 |
Zeno` |
maybe the tooltips detract from the submersion into the main menu |
| 13:16 |
nrzkt |
main menu submersion... it's a strange thing :) |
| 13:16 |
Zeno` |
but to be honest I don't want to be submersed into the main menu and I've never met anyone who would |
| 13:17 |
est |
tooltips are no manual |
| 13:17 |
est |
manuals are manual |
| 13:17 |
est |
manuals* |
| 13:17 |
Zeno` |
yes, but tooltips are not strange nor unexpected |
| 13:17 |
Zeno` |
not it that situation anyway |
| 13:18 |
est |
yes thats right, but not more than one sentence |
| 13:18 |
est |
80 chars not more |
| 13:18 |
Zeno` |
yep. It needs improvements |
| 13:18 |
est |
perhaps even less |
| 13:18 |
est |
(just said random number :D) |
| 13:22 |
|
Tablet_One joined #minetest-dev |
| 13:28 |
|
cib0 joined #minetest-dev |
| 13:42 |
|
est31 joined #minetest-dev |
| 13:48 |
neoascetic |
once again :) Could someone help me with testing of #2471 on windows? |
| 13:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/2471 -- Implement dependencies copying to target directory on OSX by neoascetic |
| 13:53 |
Zeno` |
sfan5 ^ |
| 13:55 |
neoascetic |
This is sadly that travis cannot into pure-windows testing |
| 13:57 |
est31 |
sadly that windows still gets used |
| 13:57 |
neoascetic |
well, that's also true :) |
| 14:31 |
|
johnnyjoy joined #minetest-dev |
| 14:53 |
|
cib0 joined #minetest-dev |
| 14:55 |
|
SopaXorzTaker joined #minetest-dev |
| 14:56 |
|
Hunterz joined #minetest-dev |
| 15:02 |
|
srifqi joined #minetest-dev |
| 15:15 |
sfan5 |
neoascetic: how would fixup_bundle know that it need to copy the DLL files? |
| 15:16 |
est31 |
whats all this narrow_to_wide stuff about? |
| 15:17 |
est31 |
and back again |
| 15:17 |
neoascetic |
sfan5 it uses otool (something else on windows, some black cmake's magic) |
| 15:17 |
est31 |
why does it need to be typed the right way |
| 15:17 |
est31 |
its data |
| 15:19 |
sfan5 |
neoascetic: it links to the .dll.a or .a files, so it can't know where the DLLs are |
| 15:19 |
sfan5 |
-> this can't work |
| 15:19 |
sfan5 |
also bundles are an osx only thing |
| 15:20 |
sfan5 |
i would be surprised if the bundle code handled windows and/or linux |
| 15:21 |
neoascetic |
I sure it not only osx-specific, it's just strangely named |
| 15:21 |
neoascetic |
Let me search |
| 15:22 |
neoascetic |
here one example: http://www.cmake.org/pipermail/cmake/2012-January/048487.html |
| 15:22 |
neoascetic |
have you tried it? |
| 15:22 |
sfan5 |
apparently it handles other OSs aswell |
| 15:24 |
sfan5 |
I'll try this later |
| 15:24 |
neoascetic |
Ok, thanks, I hope it will work |
| 15:24 |
sfan5 |
neoascetic: does the bundle code print something when doing it's work? |
| 15:25 |
neoascetic |
yes, on OSX is something like 'fixing_bla bla bla |
| 15:25 |
sfan5 |
it didn't print something |
| 15:25 |
sfan5 |
https://travis-ci.org/minetest/minetest/jobs/53765089#L9239 |
| 15:25 |
neoascetic |
I guess this is because it is not true windows env |
| 15:26 |
sfan5 |
it also still *can't* even work because it doesn't know where the DLLs are |
| 15:26 |
sfan5 |
you mean it will only work when you compile on windows? |
| 15:26 |
sfan5 |
I'm against that in that case |
| 15:27 |
sfan5 |
everything should work as expected when cross-compiling |
| 15:27 |
neoascetic |
I don't know if CMake's WIN32 flag defined when building from linux |
| 15:27 |
sfan5 |
and if you are going to add the code back for cross-compiling you could just not do this bundle thing for windows |
| 15:28 |
sfan5 |
it is |
| 15:28 |
sfan5 |
otherwise it wouldn't install the DLLs and get many other things wrong |
| 15:30 |
neoascetic |
I. e. we never build minetest on windows but always use cross-compiling? |
| 15:31 |
exio4 |
it may be built on windows, or it may be crosscompiled |
| 15:31 |
exio4 |
both things should work |
| 15:32 |
neoascetic |
Ok, I didn't knew that. I'll investigate then. I just didn't want to setup Windows env for build. Now I'll setup debian box for cross-compiling tests |
| 15:34 |
est31 |
Zeno`, sfan5: #2472 |
| 15:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/2472 -- Unescape tooltip texts by est31 |
| 15:54 |
neoascetic |
sfan5 I guess safest way for now is to implement that part for OSX only |
| 15:56 |
neoascetic |
I hope one day all these CMakeList files will be refactored and cleaned |
| 15:57 |
est31 |
neoascetic, there is currently need for a build system maintainer |
| 15:58 |
neoascetic |
Yeah |
| 16:05 |
|
roniz joined #minetest-dev |
| 16:07 |
|
Calinou joined #minetest-dev |
| 16:42 |
|
ImQ009 joined #minetest-dev |
| 16:45 |
nrzkt |
est31: you are right |
| 16:46 |
est31 |
lol with what |
| 16:46 |
nrzkt |
we can rename some functions on this pr |
| 16:47 |
est31 |
ok |
| 16:47 |
est31 |
ah that |
| 16:47 |
est31 |
thx |
| 16:48 |
|
PilzAdam joined #minetest-dev |
| 16:53 |
* ShadowNinja |
points neoascetic to #2402 |
| 16:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/2402 -- Clean up and tweak build system by ShadowNinja |
| 16:54 |
VanessaE |
~tell nrzkt seems the problems I've been bitching about predate your major network changes. meh. |
| 16:54 |
ShadowBot |
VanessaE: O.K. |
| 16:54 |
ShadowNinja |
And, while we're at it, PilzAdam: You O.K. with that ^ ? |
| 16:55 |
est31 |
ShadowNinja, before merge, can I test whether it works on android? |
| 16:55 |
neoascetic |
ShadowNinja oh, great, I'll take a look |
| 16:56 |
est31 |
could have had idea earlier I admit |
| 16:57 |
PilzAdam |
ShadowNinja, looks good, if it works |
| 16:59 |
neoascetic |
ShadowNinja why do we have all of these CUSTOM_bla-bla-bla variables? Couldn't we simply redefine original variables instead, could we? |
| 17:02 |
neoascetic |
https://github.com/minetest/minetest/pull/2402/files#diff-af3b638bc2a3e6c650974192a53c7291R5 |
| 17:02 |
neoascetic |
this message is also unnecessary because we do not build deb packages? |
| 17:03 |
est31 |
wasn't there an option to build deb packages |
| 17:03 |
sfan5 |
no |
| 17:05 |
est31 |
but some people may want to run CPack? |
| 17:05 |
est31 |
its far more better than make install |
| 17:05 |
est31 |
dunno if we support that |
| 17:06 |
est31 |
lots of dunnos |
| 17:06 |
est31 |
waiting for android build of SN's patch |
| 17:06 |
sfan5 |
ofc we support cpack |
| 17:06 |
sfan5 |
make package is handled by cpack |
| 17:06 |
neoascetic |
But it creates only zips |
| 17:06 |
neoascetic |
as far as I know |
| 17:07 |
sfan5 |
it could theoretically create other things |
| 17:07 |
sfan5 |
packages |
| 17:07 |
neoascetic |
but anyway our CMAkeList should be modified |
| 17:07 |
neoascetic |
to do this |
| 17:08 |
ShadowNinja |
neoascetic: It might be possible to do that. I'll check. |
| 17:08 |
ShadowNinja |
est31: Sure, try it now. |
| 17:09 |
est31 |
ShadowNinja, doing it some reason my downstream is 3 kbps |
| 17:09 |
est31 |
oh 5 |
| 17:12 |
est31 |
ShadowNinja, btw you could clean up your branches :) |
| 17:14 |
ShadowNinja |
neoascetic: It's doable, but I'd have a bunch or DEFAULT_* vars instead. |
| 17:15 |
neoascetic |
I also do not like this stuff: https://github.com/minetest/minetest/pull/2402/files#diff-af3b638bc2a3e6c650974192a53c7291R39 |
| 17:15 |
neoascetic |
can it be replaced with something shorter? :) |
| 17:16 |
neoascetic |
ShadowNinja but why all these DEFAULT_* vars? Why simply not let to redefine variables? |
| 17:19 |
ShadowNinja |
neoascetic: option()/set() needs a default. |
| 17:20 |
ShadowNinja |
And changing it later will be even uglier. |
| 17:21 |
ShadowNinja |
As for the RUN_IN_PLACE thing, I can use #cmakedefine01 RUN_IN_PLACE instead. |
| 17:25 |
|
Hunterz joined #minetest-dev |
| 17:30 |
neoascetic |
https://github.com/minetest/minetest/pull/2471 implemented this stuff for OSX only. I guess this may be merged now? |
| 17:32 |
|
ElectronLibre joined #minetest-dev |
| 17:36 |
est31 |
ShadowNinja, sfan5 building on android works, I've also added a github comment |
| 17:37 |
est31 |
for* |
| 17:45 |
|
Robert_Zenz joined #minetest-dev |
| 17:57 |
|
nrzkt joined #minetest-dev |
| 18:13 |
|
crazyR joined #minetest-dev |
| 18:27 |
|
Krock joined #minetest-dev |
| 18:34 |
|
cib0 joined #minetest-dev |
| 18:43 |
|
neoascetic joined #minetest-dev |
| 18:46 |
|
twoelk joined #minetest-dev |
| 18:46 |
Calinou |
so, nrzkt, you could make a forum post to announce your Jenkins once it is ready. |
| 18:46 |
Calinou |
so that users can download daily builds |
| 18:47 |
|
rubenwardy joined #minetest-dev |
| 18:47 |
nrzkt |
then, we continue to talk about daily builds here. ATM i can provide windows-x86 builds. but i need to talk with celeron55 because he maintain the page, and we need to talk together to interact :) |
| 18:47 |
Calinou |
rubenwardy & others can edit minetest.net if needed |
| 18:47 |
rubenwardy |
Yes. What needs to be done? |
| 18:47 |
|
Jordach joined #minetest-dev |
| 18:48 |
nrzkt |
nothing atm :p |
| 18:48 |
neoascetic |
What purpose of daily builds? I think fast releases are more better for end users, no? |
| 18:49 |
nrzkt |
no |
| 18:49 |
est31 |
no agree |
| 18:49 |
nrzkt |
quality process |
| 18:49 |
nrzkt |
we are working on great work and it need a longer release cycle, because we need to break some huge things and have feedback from community tests before release :) |
| 18:49 |
est31 |
because with daily builds, you can say "its a daily build, dont expect to it be working" |
| 18:50 |
Calinou |
neoascetic, people can test them for bugs |
| 18:50 |
Calinou |
without having to compile |
| 18:50 |
est31 |
and fast releases require testing each time |
| 18:50 |
est31 |
or not |
| 18:50 |
neoascetic |
But if cross-compiling works as expected, we may use travis to make daily builds (and even every-push-to-master) build with no problem |
| 18:50 |
est31 |
bullshit what I said |
| 18:51 |
est31 |
travis already is building |
| 18:51 |
est31 |
its building every PR |
| 18:51 |
est31 |
we only need to record it |
| 18:51 |
neoascetic |
Yes, but result of build is not published |
| 18:51 |
est31 |
yes |
| 18:51 |
est31 |
it can be turned on |
| 18:51 |
nrzkt |
est |
| 18:51 |
est31 |
you need to specify it as "release" |
| 18:52 |
est31 |
then turn on release publishing with travis |
| 18:52 |
est31 |
yes nrzkt? |
| 18:52 |
nrzkt |
est31: right :) travais already build we don't need to override him atm i think. But for daily builds it's not the correct tool :) (sorry i type enter too fast :p) |
| 18:52 |
neoascetic |
Why not? |
| 18:52 |
nrzkt |
because it's not our instance ? :p |
| 18:52 |
neoascetic |
I don't see the problem |
| 18:53 |
neoascetic |
Not our, and?.. |
| 18:53 |
nrzkt |
if it's not our server, how to get the builds ? :p |
| 18:53 |
nrzkt |
and how to schedule releases because it's only a PR build system ? |
| 18:53 |
est31 |
there is a feature that even does download publishing |
| 18:53 |
nrzkt |
oh, i didn't know about taht |
| 18:53 |
neoascetic |
http://blog.biicode.com/automatically-build-publish-via-travis-ci-github/ |
| 18:53 |
neoascetic |
for example |
| 18:54 |
est31 |
yup |
| 18:54 |
neoascetic |
I want do same thing for OSX - daily builds |
| 18:56 |
nrzkt |
i will look at this |
| 18:56 |
nrzkt |
it only permit to build push and pull requests |
| 18:56 |
est31 |
no |
| 18:56 |
neoascetic |
It may be easy than you think to setup daily builds :) |
| 18:56 |
nrzkt |
i'm on https://travis-ci.org/minetest/minetest/settings |
| 18:56 |
neoascetic |
you may trigger the build via API |
| 18:56 |
est31 |
you can set it up to test every commit |
| 18:57 |
nrzkt |
yes push and pull :) |
| 18:57 |
neoascetic |
Nope |
| 18:57 |
nrzkt |
there are Build only if .travis.yml is present / Build pushes / Build pull requests / Concurrent jobs |
| 18:57 |
neoascetic |
for example, here a little utility I've wrote https://github.com/neoascetic/travis-cron |
| 18:57 |
est31 |
push does mean every commit |
| 18:57 |
neoascetic |
you may trigger latest build on specific branch (for example, master) |
| 18:58 |
nrzkt |
i know est31 |
| 18:58 |
nrzkt |
i mean trigger a build every day for example |
| 18:58 |
nrzkt |
not every commit or every pull :) we don't have this option on the interface |
| 18:58 |
est31 |
ah yes thats not possible |
| 18:58 |
est31 |
also publishing requires to mark every commit as release |
| 18:58 |
nrzkt |
it's there where jenkins can come. |
| 18:59 |
neoascetic |
Ohh... give me a time and I'll show how to do this with travis :D |
| 18:59 |
neoascetic |
I need this be merged, however: https://github.com/minetest/minetest/pull/2471 |
| 19:00 |
neoascetic |
Btw, how is long the review process? |
| 19:00 |
est31 |
2 core devs need to say yes |
| 19:00 |
est31 |
officially |
| 19:00 |
est31 |
if its small thing then I think one is enough |
| 19:00 |
est31 |
I'm not sure |
| 19:00 |
neoascetic |
core devs, cmon, say yes please, this won't break anything :D |
| 19:00 |
nrzkt |
right est31 |
| 19:01 |
nrzkt |
i look at your commit, please wait |
| 19:01 |
est31 |
nrzkt, also consider reviewing #2472 |
| 19:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/2472 -- Unescape tooltip texts by est31 |
| 19:02 |
nrzkt |
i don't understand the improvement here, because i'm not very familiar with formspec |
| 19:03 |
rubenwardy |
nrzkt, it builds current master as well. |
| 19:04 |
nrzkt |
rubenwardy: on which PR are you talking about ? |
| 19:05 |
rubenwardy |
It does here: https://github.com/rubenwardy/NodeBoxEditor |
| 19:05 |
rubenwardy |
So Minetest would too |
| 19:06 |
rubenwardy |
https://travis-ci.org/minetest/minetest |
| 19:06 |
rubenwardy |
See |
| 19:06 |
nrzkt |
building != working :) |
| 19:06 |
est31 |
but building == you can compile and bisect |
| 19:07 |
est31 |
which is most important thing |
| 19:07 |
neoascetic |
Yeah, cpp is not Haskell ;) |
| 19:07 |
nrzkt |
but it seems good, as far i can remember the modificated options are good |
| 19:07 |
rubenwardy |
I may have misunderstood |
| 19:07 |
nrzkt |
you have my +1 if a mac os fanboy (burn them) core-dev agrees |
| 19:08 |
exio4 |
neoascetic: you said the magic word |
| 19:08 |
est31 |
nrzkt is a devil he is burning master |
| 19:09 |
exio4 |
there are no os x core devs, as far as I know? |
| 19:10 |
neoascetic |
yeah, that's why my PR sometimes stuck :) |
| 19:11 |
|
Warr1024 joined #minetest-dev |
| 19:12 |
nrzkt |
i need to test it on a real BSD in fact |
| 19:15 |
nrzkt |
oh lol |
| 19:15 |
nrzkt |
we can use travis & jenkins together |
| 19:15 |
neoascetic |
but why? |
| 19:15 |
nrzkt |
build on FreeBSD :) |
| 19:16 |
est31 |
because as it seems travis doesnt have enough ram for android |
| 19:16 |
nrzkt |
erf jenkins became crazy |
| 19:16 |
neoascetic |
We may build on OSX with travis - that's better IMO |
| 19:16 |
nrzkt |
i launch the PR process and he will try to build every opened PR |
| 19:17 |
nrzkt |
lohttp://jenkins.unix-experience.fr/ |
| 19:17 |
nrzkt |
http://jenkins.unix-experience.fr/ |
| 19:17 |
neoascetic |
Oh android |
| 19:17 |
nrzkt |
and also android yes, i will add the 3 jobs |
| 19:17 |
nrzkt |
2* |
| 19:18 |
neoascetic |
We may use travis for android also... |
| 19:18 |
nrzkt |
yes but not enough ram then killed |
| 19:18 |
nrzkt |
my server has 8-12GB free, it's sufficient for this build |
| 19:19 |
nrzkt |
when the crazy jenkins will have finished i will look at android compilation integration, i also need a NDK for other android projects |
| 19:20 |
est31 |
nrzkt, you can start with the one I have created for travis |
| 19:20 |
est31 |
#2436 |
| 19:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/2436 -- Add Travis checks for Android |
| 19:21 |
est31 |
its a bit complicated as version numbers are important |
| 19:21 |
neoascetic |
I hope you guys will not turn travis off because I have a dream of builds and for OSX too |
| 19:21 |
est31 |
I would be for having both enabled too |
| 19:21 |
nrzkt |
travis can build for OSX ? |
| 19:21 |
neoascetic |
yes |
| 19:22 |
nrzkt |
i think i also can, because i run FreeBSD and OSX is a FreeBSD :p |
| 19:22 |
neoascetic |
https://travis-ci.org/neoascetic/minetest/branches I track master branch for every push and build it on OSX with travis |
| 19:23 |
neoascetic |
oh well FreeBSD is unix and linux is unix and if it builds on unix it should also work on OSX |
| 19:23 |
neoascetic |
but that's not true ;) |
| 19:23 |
nrzkt |
linux is not unix |
| 19:23 |
nrzkt |
:) |
| 19:23 |
neoascetic |
unix-ispired, ok |
| 19:23 |
neoascetic |
inspired |
| 19:24 |
est31 |
linux isn't even unix-inspired |
| 19:24 |
est31 |
linux is a kernel, unix is an operating system |
| 19:24 |
est31 |
thats two things |
| 19:25 |
Warr1024 |
unix isn't really an operating system;m more of a specification for one. |
| 19:25 |
Warr1024 |
Unix is an OS like ARM is a processor. |
| 19:25 |
neoascetic |
let's holywar begin |
| 19:26 |
Warr1024 |
nah, let's not. |
| 19:28 |
neoascetic |
as per http://docs.travis-ci.com/user/ci-environment/#The-Build-Machine, On the Linux platform, builds have 3 GB of memory available. Disk space is limited, but there's no fixed limit per build. Builds have up to two cores available (bursted). |
| 19:28 |
neoascetic |
3 GB is not enough for android build? |
| 19:30 |
est31 |
as it seems |
| 19:30 |
est31 |
perhaps you can point to something else that makes build failing |
| 19:30 |
neoascetic |
something wrong with this world |
| 19:32 |
neoascetic |
swapon: /swap: swapon failed: Operation not permitted |
| 19:33 |
neoascetic |
that's why I guess? |
| 19:33 |
est31 |
no |
| 19:33 |
est31 |
that was test error message |
| 19:33 |
est31 |
I tried to add swap to test whether its ram issue |
| 19:33 |
est31 |
travis doesnt allow swap |
| 19:33 |
est31 |
thats why |
| 19:33 |
neoascetic |
Ok, where is previous? |
| 19:36 |
est31 |
neoascetic, https://travis-ci.org/minetest/minetest/jobs/53444462#L7045 |
| 19:36 |
est31 |
I also linked to it in history |
| 19:53 |
nrzkt |
hmmm sorry for the jenkins PR build on github, i let him compile all issues and disable the task after. clang is not very happy on freebsd with our build :p |
| 20:18 |
|
Player_2 joined #minetest-dev |
| 20:37 |
|
cib_ joined #minetest-dev |
| 20:57 |
|
MinetestForFun joined #minetest-dev |
| 22:42 |
nrzkt |
Ok core-devs, my jenkins has built all PR, sorry for the inconvenience. I will let him build PR for freebsd builds (using Clang) natively, which permit to point other bugs. The builder is called jenkins-ci/freebsd-nrz |
| 22:43 |
|
twoelk|2 joined #minetest-dev |
| 23:02 |
VanessaE |
so what's the story with the ghost entities? |
| 23:02 |
VanessaE |
00:02:35: ERROR[ServerThread]: ServerEnv: Trying to store id=30875 statically but block (-43,1,-28) already contains 554 objects. Forcing delete. |
| 23:02 |
VanessaE |
etc. |
| 23:03 |
VanessaE |
players being deleted while the server tries to delete these non-existent entities. |
| 23:05 |
VanessaE |
it just keeps repeating the same message over and over for a given mapblock, but with the count gradually increasing (that block is at 558 now) |
| 23:11 |
|
srifqi joined #minetest-dev |
| 23:29 |
|
srifqi joined #minetest-dev |
| 23:32 |
|
everamzah joined #minetest-dev |
| 23:47 |
|
AnotherBrick joined #minetest-dev |
