| Time |
Nick |
Message |
| 00:19 |
|
hoborific joined #minetest-dev |
| 00:40 |
hoborific |
how do you police pull requests |
| 01:15 |
|
kahrl joined #minetest-dev |
| 01:16 |
kahrl |
https://github.com/minetest/minetest/issues/1728 fixed by https://gist.github.com/kahrl/778860462bfb6e43243c |
| 01:16 |
kahrl |
since the fix is so trivial I'll push it in an hour if nobody complains |
| 01:20 |
ShadowNinja |
Seems fine, provided that the engine prepends PROJECT_NAME + minetest_version_hash + " / " to it. |
| 01:20 |
kahrl |
yeah, it doe |
| 01:20 |
kahrl |
s |
| 01:21 |
kahrl |
(and skips the " / " part if the argument to set_topleft_text is empty) |
| 01:31 |
kahrl |
can anybody explain https://github.com/minetest/minetest/issues/1723? |
| 01:31 |
kahrl |
why would the game be in draw_load_screen while playing? |
| 01:49 |
|
NakedFury joined #minetest-dev |
| 01:49 |
ShadowNinja |
kahrl: He probably means "while connecting to play". |
| 02:12 |
|
Miner_48er joined #minetest-dev |
| 02:23 |
|
hoborific left #minetest-dev |
| 02:24 |
|
Zeno` joined #minetest-dev |
| 02:27 |
|
GrimKriegor joined #minetest-dev |
| 02:37 |
|
Zeno` joined #minetest-dev |
| 02:50 |
|
Hunterz joined #minetest-dev |
| 03:44 |
|
Hunterz joined #minetest-dev |
| 03:45 |
|
Hunterz1 joined #minetest-dev |
| 04:03 |
|
MikeFair_ joined #minetest-dev |
| 04:30 |
|
kaeza joined #minetest-dev |
| 05:01 |
|
SmugLeaf joined #minetest-dev |
| 05:01 |
|
SmugLeaf joined #minetest-dev |
| 05:15 |
|
sol_invictus joined #minetest-dev |
| 05:40 |
|
Hunterz joined #minetest-dev |
| 06:20 |
|
GrimKriegor joined #minetest-dev |
| 06:22 |
|
ImQ009 joined #minetest-dev |
| 06:25 |
|
alexxs joined #minetest-dev |
| 06:41 |
|
hintss joined #minetest-dev |
| 07:13 |
Zeno` |
how does this project like commits squashed? e.g. https://github.com/minetest/minetest/pull/1707 ? |
| 07:14 |
Zeno` |
git rebase -i HEAD~3 ? |
| 07:18 |
kahrl |
yeah, would be best in this case |
| 07:18 |
kahrl |
but generally don't squash if it would produce a commit that does multiple unrelated things |
| 07:21 |
kahrl |
(but do squash if the second commit just fixes a variable name introduced / heavily changed by the first, etc.) |
| 07:21 |
kahrl |
s/variable name/name of a variable |
| 07:24 |
Zeno` |
so in this case I *should* squash but only HEAD~2 ? |
| 07:25 |
Zeno` |
the bug fix is already merged... so maybe I'd be better to squash all I think |
| 07:25 |
Zeno` |
sorry, I just saw you already said that :3 |
| 07:26 |
kahrl |
wait, which one is already merged? |
| 07:26 |
kahrl |
oh, the "Fix use ..." one |
| 07:27 |
kahrl |
don't squash with that, just remove it |
| 07:27 |
kahrl |
otherwise git would try to apply that patch again and everyone would be crying |
| 07:27 |
|
kilbith joined #minetest-dev |
| 07:27 |
kilbith |
since today, I can't see the server list in the client |
| 07:28 |
Zeno` |
27eff75, but as another request. The mistake I made was fixing 27eff75 as a separate PR |
| 07:28 |
|
Krock joined #minetest-dev |
| 07:29 |
Zeno` |
I'll squash all 3 and see what the diff looks like |
| 07:30 |
kahrl |
don't |
| 07:30 |
kahrl |
Zeno`: in these cases, since I don't know git well, I just make a new branch, cherry-pick the (non-merged to upstream) commits from the first branch, delete the first branch, rename the second back to the first, and git push -f |
| 07:30 |
Zeno` |
ok, so leave as is? |
| 07:30 |
Zeno` |
or can I squash e5d1da2 into 934e1c2? |
| 07:30 |
Zeno` |
even if there is a commit in between them |
| 07:31 |
kahrl |
yeah, just change the order in rebase -i |
| 07:31 |
|
proller joined #minetest-dev |
| 07:31 |
Zeno` |
well I may as well try... won't learn any other way. Making backup heh |
| 07:32 |
Zeno` |
thanks |
| 07:33 |
kahrl |
you can also delete 27eff75 by removing that line in git rebase -i |
| 07:33 |
Zeno` |
just read that comment in vim |
| 07:33 |
kahrl |
but I never trust myself to not mess up by doing something like that so I go the cherry-pick way |
| 07:35 |
* Zeno` |
does git rebase --abort... lol, that worked out well |
| 07:35 |
Zeno` |
I will cherry pick... easier |
| 07:44 |
Zeno` |
seemed to work. Thanks again, kahrl |
| 07:50 |
|
sfan5_ joined #minetest-dev |
| 08:03 |
|
darkrose joined #minetest-dev |
| 08:07 |
|
sfan5_ joined #minetest-dev |
| 08:29 |
kahrl |
https://github.com/minetest/minetest/blob/master/src/drawscene.cpp#L524 |
| 08:29 |
kahrl |
why are the clouds rendered before beginScene? |
| 08:30 |
kahrl |
how does that even work? |
| 08:45 |
Krock |
and I wonder about this use: https://github.com/minetest/minetest/blob/master/src/sky.cpp#L497 |
| 08:48 |
kahrl |
Krock: that seems fine to me |
| 08:49 |
kahrl |
perhaps a bit hacky to use recursion like that but should be ok |
| 08:49 |
Krock |
kahrl, just interesting why a flood is needed to solve a problem |
| 08:50 |
kahrl |
the alternative would be to duplicate update() into an initialize function |
| 08:51 |
kahrl |
which does everything update() does except the smoothing |
| 08:51 |
Krock |
:/ |
| 08:55 |
kahrl |
just timed it, took <1ms to do the 100 updates |
| 08:58 |
|
ninnghazad joined #minetest-dev |
| 09:00 |
|
FR^2 joined #minetest-dev |
| 09:11 |
|
RealBadAngel joined #minetest-dev |
| 09:12 |
|
blaise joined #minetest-dev |
| 09:13 |
Zeno` |
it's probably tail-end optimisation and/or unrolled with optimisation anyway |
| 09:13 |
Zeno` |
optimised* |
| 09:14 |
Zeno` |
I was actually looking at that same line the other day :-o |
| 09:15 |
Zeno` |
when I was looking for an unititized variable... weird |
| 09:23 |
|
ImQ009 joined #minetest-dev |
| 10:00 |
ninnghazad |
is there a limit to size of log in memory? or can i blow the server's mem by producing large amounts of logging? |
| 10:02 |
kahrl |
the log is written to disk, not memory |
| 10:02 |
kahrl |
unless debug.txt happens to be on a tmpfs, I suppose (but why would you do that?) |
| 10:03 |
ninnghazad |
nono, i was wondering if the buffer used for logging may not be cleared (even if written to disk) |
| 10:03 |
kahrl |
any signs of that happening? would be strange |
| 10:05 |
ninnghazad |
not really, but i have a memleak and am looking for causes. there isn't much happening but logging, so i thought i'd ask |
| 10:05 |
kahrl |
tried valgrind? |
| 10:07 |
ninnghazad |
not yet, thought i might be able to pinpoint it by selectively disabling stuff in lua that is running when it happens. i was under the assumption that the lua-env gets destroyed when leaving the game, but the mem stays high when back in menu. does the lua persist until that point? |
| 10:07 |
kahrl |
I'm pretty sure it is destroyed |
| 10:08 |
kahrl |
maybe someone missed some userdata objects or something though |
| 10:12 |
|
jin_xi joined #minetest-dev |
| 10:12 |
ninnghazad |
hmk, has to be something in lua then that leaves stuff around outside of it. valgrind dumps me with: /tmp/minetest/src/script/cpp_api/s_base.cpp:74: ScriptApiBase::ScriptApiBase(): Assertion 'm_luastack' failed. |
| 10:12 |
Zeno` |
you need to disable LuaJIT |
| 10:13 |
ninnghazad |
aah.. ok |
| 10:13 |
jin_xi |
ninnghazad: is this with dronetests? because minetest leaks the textures for the screens |
| 10:13 |
Zeno` |
valgrind and LuaJIT do not work nicely together unless you have a special build of LuaJIT |
| 10:14 |
ninnghazad |
yes, i found it while coding for dronetest. hm, its a lot of screen-updates, maybe thats just it. |
| 10:14 |
ninnghazad |
using 640x640 screens, so that may explain the speed of leaking. |
| 10:16 |
kahrl |
aren't the textures unloaded when you exit to menu though? |
| 10:20 |
ninnghazad |
hm, i don't think thats it, printing lots of text alone is not enough to make it leak. |
| 10:21 |
ninnghazad |
i think it happens around get_objects_inside_radius and using those. |
| 10:23 |
|
PenguinDad joined #minetest-dev |
| 10:30 |
jin_xi |
i found collisionMoveSimple generates lots of spurious hits on node borders |
| 10:30 |
jin_xi |
i wonder if its a problem for some mods as its used for all movement in mt basically. |
| 10:34 |
|
Krock joined #minetest-dev |
| 10:43 |
Zeno` |
oh man, I don't wannna make a branch for this :9 |
| 10:55 |
Zeno` |
Krock!!! Best pal and buddy |
| 10:55 |
Krock |
I feel nothing good |
| 10:57 |
Zeno` |
No, no, this is fantastic. Can you check this is fine on MSVC? https://github.com/Zeno-/minetest/tree/minor_cleanup |
| 10:57 |
Zeno` |
It's terribly exciting |
| 10:58 |
Zeno` |
I only did it for memcpy(new_str, intermediate.c_str(), len * sizeof (wchar_t) + 1); in gettext.h :( |
| 10:58 |
Krock |
Zeno`, you really want to wait 25 minutes just to (maybe) get an error message? |
| 11:00 |
Zeno` |
probably not. It looks fine so I will trust it |
| 11:01 |
Zeno` |
actually forget it altogether |
| 11:09 |
|
sfan5_ joined #minetest-dev |
| 11:14 |
|
SudoAptGetPlay joined #minetest-dev |
| 11:14 |
|
proller joined #minetest-dev |
| 11:17 |
|
proller joined #minetest-dev |
| 11:51 |
ninnghazad |
hmk, i was confused. get_objects did not leak, must really be the textures or something related to that. when not updating dronetest_display's texture, memory stays cool. |
| 11:55 |
|
speak joined #minetest-dev |
| 12:02 |
|
mos_basik joined #minetest-dev |
| 12:06 |
Zeno` |
umm, kahrl... |
| 12:07 |
Zeno` |
https://github.com/minetest/minetest/commit/d1ccc64e1ecfd00df36d2b8a8b3420b70434fefd <-- Why is that necessary? |
| 12:07 |
Zeno` |
It makes no difference, I'm just interested |
| 12:07 |
|
hintss joined #minetest-dev |
| 12:13 |
|
SudoAptGetPlay joined #minetest-dev |
| 12:16 |
|
hax404_ joined #minetest-dev |
| 12:17 |
Megaf |
sfan5: I will try again with the following flags, cmake ../../ -DVERSION_EXTRA=MinetestPi -DRUN_IN_PLACE=1 -DENABLE_GLES=1 -DIRRLICHT_INCLUDE_DIR=../../../irrlicht/include -DIRRLICHT_LIBRARY=../../../irrlicht/lib/Linux/libIrrlicht.a -DENABLE_SOUND=0 -DENABLE_LEVELDB=0 -DENABLE_CURL=0 -DENABLE_REDIS=0 -DCMAKE_EXE_LINKER_FLAGS="-lGLESv1_CM -lEGL" |
| 12:17 |
Megaf |
and I recompiled Irrlicht too |
| 12:21 |
|
Amaz joined #minetest-dev |
| 12:22 |
|
PilzAdam joined #minetest-dev |
| 12:24 |
|
SudoAptGetPlay joined #minetest-dev |
| 12:31 |
|
ImQ009 joined #minetest-dev |
| 12:51 |
|
CraigyDavi`` joined #minetest-dev |
| 13:01 |
|
shadowzone joined #minetest-dev |
| 13:03 |
SudoAptGetPlay |
Hi, is there an easy way to link server's players credentials to an external mysql db ? |
| 13:18 |
|
rickmcfarley joined #minetest-dev |
| 13:21 |
sfan5 |
SudoAptGetPlay: you can generate an auth.txt from a mysql db, but linking? no |
| 13:26 |
SudoAptGetPlay |
the usecase is : users register on a site to create an account, and those credentials are used by minetest for user login |
| 13:37 |
sfan5 |
thats even easier |
| 13:45 |
|
hmmmm joined #minetest-dev |
| 13:47 |
|
rickmcfarley joined #minetest-dev |
| 13:49 |
|
Salbei joined #minetest-dev |
| 13:52 |
Salbei |
hi all |
| 13:53 |
Salbei |
sfan5: can u tell me more about SudoAptGetPlay question? |
| 13:54 |
sfan5 |
sure |
| 13:54 |
Salbei |
I want to link users from a mysql db to minetestserver |
| 13:55 |
Salbei |
how do that? |
| 13:55 |
sfan5 |
mysql is a bit more complicated |
| 13:55 |
sfan5 |
<SudoAptGetPlay> the usecase is : users register on a site to create an account, and those credentials are used by minetest for user login |
| 13:55 |
sfan5 |
<sfan5> thats even easier |
| 13:57 |
Salbei |
i have to write with php in the auth.txt right? |
| 13:57 |
sfan5 |
correct |
| 13:58 |
Salbei |
ok i can do that |
| 13:58 |
Salbei |
I have an another question |
| 14:00 |
Salbei |
what is the solution for put 2 serverlist_url in the minetest.conf? |
| 14:00 |
|
proller joined #minetest-dev |
| 14:00 |
sfan5 |
you can only put one url there |
| 14:01 |
Salbei |
ok |
| 14:05 |
sfan5 |
Salbei: http://sprunge.us/bWIG?php |
| 14:07 |
Salbei |
cool sfan5 thanks u :) |
| 14:11 |
Krock |
Does the bus still exist in the newest Git, where the selection box for nodes is not shown up when pointing through water? |
| 14:11 |
Krock |
*bug |
| 14:20 |
|
casimir joined #minetest-dev |
| 14:21 |
|
proller joined #minetest-dev |
| 14:28 |
|
Amaz joined #minetest-dev |
| 14:48 |
|
VargaD_ joined #minetest-dev |
| 15:00 |
|
Salbei left #minetest-dev |
| 15:05 |
|
proller joined #minetest-dev |
| 15:23 |
ninnghazad |
is there a callback for when entities get unloaded cause they are too far away? |
| 15:29 |
Krock |
why would you need that? |
| 15:30 |
ninnghazad |
cause i have entites communicating, when a and b talk, and i move away to unload b, a will not known that b is gone. |
| 15:30 |
ninnghazad |
like with digilines, what if an object is unloaded while processing a call between two objects? |
| 15:31 |
ninnghazad |
with a callback, i could remove that entity from the list of talkers, and prevent calling methods of the removed object (which return garbage it seems) |
| 15:32 |
|
mos_basik joined #minetest-dev |
| 15:35 |
ninnghazad |
hm, or can temporarily keep entities from being removed, so that they can finish what they are doing without crashing? |
| 15:39 |
ninnghazad |
hm there was some talk about unloading-prevention like 2 years back. |
| 15:41 |
Krock |
you can forceload blocks |
| 15:43 |
|
NakedFury joined #minetest-dev |
| 15:44 |
|
mos_basik joined #minetest-dev |
| 15:46 |
ninnghazad |
yeah, i guess that'll be the only way right now. at least that ensures that entities not only stay alive, but also the nodes around them they might want to access. |
| 15:46 |
|
mos_basik joined #minetest-dev |
| 15:47 |
ninnghazad |
from the irc-logs it seems the discussion about implementing isUnloadAllowed did not end fruitfull. |
| 15:49 |
|
proller joined #minetest-dev |
| 15:59 |
|
rubenwardy joined #minetest-dev |
| 16:00 |
|
kilbith joined #minetest-dev |
| 16:00 |
kilbith |
Megaf: what's the result of your compiling ? |
| 16:02 |
|
Megaf joined #minetest-dev |
| 16:02 |
* rubenwardy |
wishes compiling didn't take so long... |
| 16:03 |
kilbith |
Megaf: what's the result of your compiling ? |
| 16:05 |
* Krock |
slaps rubenwardy |
| 16:10 |
|
Hunterz joined #minetest-dev |
| 16:35 |
|
rubenwardy joined #minetest-dev |
| 16:40 |
kahrl |
Zeno`: oh yeah, I wasn't quite sure if the C++ standard guarantees that the first enum value corresponds to 0 in absence of an initializer, but it does (7.2.1) |
| 16:41 |
kahrl |
doesn't hurt to be explicit though |
| 16:44 |
|
petrusd987 joined #minetest-dev |
| 16:51 |
|
Calinou joined #minetest-dev |
| 16:52 |
|
zat joined #minetest-dev |
| 17:00 |
|
Calinou_ joined #minetest-dev |
| 17:04 |
|
Anchakor_ joined #minetest-dev |
| 17:16 |
|
asl joined #minetest-dev |
| 17:23 |
|
proller joined #minetest-dev |
| 17:32 |
|
petrusd987_ joined #minetest-dev |
| 17:37 |
|
kaeza joined #minetest-dev |
| 18:00 |
|
harrison joined #minetest-dev |
| 18:01 |
petrusd987 |
Does anyone know how I can link Koneki to Minetest for debugging? |
| 18:03 |
|
proller joined #minetest-dev |
| 18:04 |
Megaf |
sfan5: well, it compiled |
| 18:04 |
Megaf |
it have compiled |
| 18:04 |
Megaf |
does anyone heve have a Raspberry Pi to test my build? |
| 18:04 |
Megaf |
[100%] Built target minetest |
| 18:04 |
Megaf |
real 109m10.320s |
| 18:05 |
petrusd987 |
I can, I'd have to find the power cable though |
| 18:05 |
sfan5 |
can't you test it on your raspberry pi? |
| 18:05 |
sfan5 |
I have a raspi too, but it's busy with other stuff |
| 18:06 |
Megaf |
No I can't, I don't have any monitor or keyboard here |
| 18:08 |
Megaf |
petrusd987: Ok, I will find a way to upload to somewhere |
| 18:08 |
Megaf |
upload it* |
| 18:15 |
petrusd987 |
I'll be right back |
| 18:21 |
|
VargaD_ joined #minetest-dev |
| 18:27 |
|
kilbith joined #minetest-dev |
| 18:42 |
|
petrusd987_ joined #minetest-dev |
| 18:48 |
|
OldCoder joined #minetest-dev |
| 18:54 |
Megaf |
sfan5: proller: any idea on the cause of this? http://paste.debian.net/125419/ |
| 18:54 |
Megaf |
^ kilbith |
| 18:55 |
kahrl |
Megaf: npot2 problem? |
| 18:55 |
Megaf |
libEGL warning: DRI2: failed to authenticate |
| 18:55 |
proller |
google it |
| 18:59 |
kahrl |
Megaf: number 7 http://pi3d.github.io/html/FAQ.html |
| 19:00 |
Megaf |
Ok, thanks |
| 19:01 |
Megaf |
kilbith: try that |
| 19:02 |
kilbith |
ok |
| 19:04 |
Megaf |
[15:07:23] <kahrl> nonetheless at the rate Megaf gets them I would suggest doing a memtest on that machine |
| 19:04 |
Megaf |
Lets see for how long minetestserver can run without crashing |
| 19:08 |
kilbith |
ok I entered the commands and it still not works |
| 19:08 |
kilbith |
I should remove some libs iirc |
| 19:09 |
kilbith |
manually |
| 19:11 |
kilbith |
/usr/lib/arm-linux-gnueabihf/libEGL.so.1 |
| 19:11 |
kilbith |
/usr/lib/arm-linux-gnueabihf/libEGL.so.1.0 |
| 19:11 |
kilbith |
should just keep libEGL.so ? |
| 19:28 |
|
Krock joined #minetest-dev |
| 19:40 |
|
Miner_48er joined #minetest-dev |
| 19:41 |
|
w00tc0d3 joined #minetest-dev |
| 19:43 |
|
VargaD_ joined #minetest-dev |
| 19:55 |
|
jin_xi joined #minetest-dev |
| 20:06 |
|
VargaD_ joined #minetest-dev |
| 20:11 |
|
Amaz joined #minetest-dev |
| 20:15 |
Krock |
Any chance to get #1715 merged in this year? |
| 20:28 |
kilbith |
Megaf: also that when trying to get the public server list : 22:28:04: ERROR[AsyncWorkerThread_0]: httpfetch_sync: unable to fetch servers.minetest.net/list because USE_CURL=0 |
| 20:29 |
Krock |
^ curl missing |
| 20:29 |
|
paramat joined #minetest-dev |
| 20:34 |
paramat |
sfan5, (and other MTgame devs) please can boats mod be fixed by merging my pull https://github.com/minetest/minetest_game/pull/328 it's been tested and fine tuned for hours, works like a dream. best to test in my 'canyon' river mod as that has extreme water level changes |
| 20:34 |
sfan5 |
I'm fine with merging it |
| 20:34 |
sfan5 |
''tell BlockMen <paramat> sfan5, (and other MTgame devs) please can boats mod be fixed by merging my pull https://github.com/minetest/minetest_game/pull/328 it's been tested and fine tuned for hours, works like a dream. best to test in my 'canyon' river mod as that has extreme water level changes |
| 20:34 |
sfan5 |
where's the bot |
| 20:34 |
sfan5 |
argh |
| 20:43 |
|
gravgun joined #minetest-dev |
| 20:43 |
gravgun |
Hi everybody. @sfan5: some early work: http://pastebin.com/NFB031Rp |
| 20:44 |
sfan5 |
cstdint is C++11? |
| 20:44 |
gravgun |
Yes |
| 20:44 |
gravgun |
cstdint.h is C++ < 11 |
| 20:44 |
gravgun |
eh i meant <stdint.h> |
| 20:45 |
sfan5 |
TIL |
| 20:45 |
gravgun |
and <cstdint>, although it existed before C++11 on some libc's is really defined in the C++11 standard |
| 20:45 |
sfan5 |
>signed int types |
| 20:46 |
sfan5 |
why do we even have different types? |
| 20:46 |
sfan5 |
and "int addr;" |
| 20:46 |
sfan5 |
int is not guaranteed to be the size of a pointer |
| 20:46 |
gravgun |
not supposed to be |
| 20:46 |
gravgun |
supposed to be a stack pointer |
| 20:47 |
gravgun |
and stack will be an array, or a std::stack of some kind |
| 20:47 |
gravgun |
as i said it's early work |
| 20:47 |
gravgun |
and I've never made any VMs beforehand |
| 20:47 |
sfan5 |
not having the stack be an array will make it slow |
| 20:48 |
gravgun |
stl is slow in general you know... |
| 20:48 |
sfan5 |
are you aware that you also need to serialize instructions? |
| 20:48 |
gravgun |
at least compared to bare C arrays |
| 20:48 |
gravgun |
yes I am |
| 20:48 |
sfan5 |
and class Program should be class ProgramState (at least it's more like that) |
| 20:49 |
gravgun |
it's both actually... |
| 20:49 |
gravgun |
as I don't intend the code to be self-modifying, your suggestion is right |
| 20:49 |
sfan5 |
Program is just std::queue<Instruction> instructions; |
| 20:49 |
gravgun |
typedef? |
| 20:49 |
sfan5 |
having a stack and pc if you want to pass around a program is a waste of resources |
| 20:49 |
sfan5 |
typedef would be goo |
| 20:49 |
sfan5 |
d |
| 20:51 |
gravgun |
updated paste |
| 20:52 |
sfan5 |
what does emit<something>() do? |
| 20:52 |
paramat |
thanks |
| 20:53 |
gravgun |
Those are therefore supposed to be in some kind of Program factory, they just emit instructions and append them to the std::queue |
| 20:53 |
sfan5 |
which std::queue? |
| 20:53 |
sfan5 |
there is none |
| 20:53 |
gravgun |
typedef std::queue<Instruction> Program; |
| 20:53 |
sfan5 |
that doesn't define a variable |
| 20:54 |
gravgun |
not anymore according to my changes... |
| 20:54 |
sfan5 |
it didn't define one before either |
| 20:55 |
gravgun |
it did, it was in "class Program" |
| 20:55 |
gravgun |
changed to ProgramState |
| 20:55 |
sfan5 |
wat |
| 20:55 |
sfan5 |
you can't just <a class>.<a variable> |
| 20:55 |
sfan5 |
you need an instance of the class |
| 20:55 |
sfan5 |
ProgramState.pc = 0; is not going to work |
| 20:55 |
gravgun |
there was an instance |
| 20:55 |
gravgun |
|
| 20:55 |
gravgun |
class Program { |
| 20:55 |
gravgun |
std::queue<Instruction> instructions; |
| 20:55 |
gravgun |
std::stack<Arg> stack; |
| 20:55 |
gravgun |
int pc; |
| 20:56 |
gravgun |
}; |
| 20:56 |
gravgun |
|
| 20:56 |
sfan5 |
thats not an instance |
| 20:56 |
gravgun |
Program pgm; |
| 20:56 |
sfan5 |
thats a class def |
| 20:56 |
gravgun |
|
| 20:56 |
sfan5 |
what |
| 20:56 |
sfan5 |
where |
| 20:56 |
sfan5 |
hm |
| 20:56 |
sfan5 |
didn't see that |
| 20:56 |
gravgun |
And what is "Program pgm" then? |
| 20:56 |
gravgun |
:P |
| 20:56 |
gravgun |
got removed too |
| 20:57 |
gravgun |
Basically, those emitX() methods are here to create the program, step by step, to be called by a future asm syntax parser |
| 20:58 |
gravgun |
But i'll need to move them somewhere else |
| 20:58 |
|
shadowzone joined #minetest-dev |
| 20:58 |
|
shadowzone joined #minetest-dev |
| 20:59 |
gravgun |
and they'll possibly be exposed to the Lua API, in case someone writes a compiler of some kind |
| 21:00 |
gravgun |
the same ways GCC directly feeds its assembler (as) when not using (temporary) .s files |
| 21:05 |
ShadowNinja |
ninnghazad: You can use get_staticdata(). |
| 21:06 |
ShadowNinja |
ninnghazad: Really a #minetest question though. |
| 21:07 |
|
zat joined #minetest-dev |
| 21:15 |
|
iqualfragile joined #minetest-dev |
| 21:16 |
gravgun |
BTW isn't this commit pretty useless? https://github.com/minetest/minetest/commit/d1ccc64e1ecfd00df36d2b8a8b3420b70434fefd Because ISO C++ (98) 7.1§1 says "If the first enumerator has no initializer, the value of the corresponding constant is zero." |
| 21:17 |
PenguinDad |
gravgun: we already figured that out :P |
| 21:19 |
gravgun |
Well people, have a good night/day (depending on where you are :P ). Already 23:20 in France ;) Bye |
| 21:19 |
|
gravgun left #minetest-dev |
| 21:31 |
|
proller joined #minetest-dev |
| 21:42 |
RealBadAngel |
hi guys |
| 21:43 |
RealBadAngel |
im at the final testing stage for meshnodes |
| 21:43 |
RealBadAngel |
http://i.imgur.com/ECELl3Y.png |
| 21:43 |
RealBadAngel |
i had to learn blender a bit ;) |
| 21:49 |
|
rickmcfarley joined #minetest-dev |
| 21:57 |
|
DuDraig joined #minetest-dev |
| 22:01 |
|
DuDraig joined #minetest-dev |
| 22:06 |
|
petrusd987_ joined #minetest-dev |
| 22:12 |
paramat |
Hi RealBadAngel, if meshnodes eventually replace nodeboxes (i'm keen to see the speed increase), how will you achieve faces-shading that matches normal nodes? and how will you map 6 textures onto top, base, N, S, E, W as currently? =) |
| 22:14 |
RealBadAngel |
paramat, meshnodes are shaded basing on surface normals (so its working). bumpmapping and parallax is working too |
| 22:15 |
RealBadAngel |
about UVing objects: tiles are used to describe materials of the object |
| 22:15 |
RealBadAngel |
if you have more than one object in the mesh you can have different textures for them, described in tiles |
| 22:16 |
RealBadAngel |
but one tile can hold whole texture for a object |
| 22:16 |
RealBadAngel |
you need to define uv for it in blender |
| 22:17 |
RealBadAngel |
http://i.imgur.com/nuYwyFY.png |
| 22:17 |
RealBadAngel |
this is texture file for mushroom |
| 22:18 |
ShadowNinja |
paramat: With models you can map a face of the model to an arbritrary section on an image, that's how the default character.x works. |
| 22:18 |
paramat |
ah so the surface normals define a 'blend' of our current top, base, N, S, E, W shades ... |
| 22:19 |
RealBadAngel |
theres no top, bottom etc anymore |
| 22:19 |
RealBadAngel |
all has to be done in blender |
| 22:20 |
RealBadAngel |
you just cut a piece of texture and assign it to vertices |
| 22:21 |
RealBadAngel |
thx to that you dont care anymore bout it. and can scale it, rotate or whatever |
| 22:21 |
RealBadAngel |
meshnodes doesnt need textures rotating code like nodeboxes do |
| 22:24 |
paramat |
if you want meshes to replace nodeboxes, people will not want to use blender for texturing, they will want a simple way similar to how it is now |
| 22:24 |
paramat |
also, people will want to define a nodebox in a simple way (as it is now) and have code convert that into a mesh |
| 22:25 |
RealBadAngel |
nodeboxes will be turned into meshes on startup |
| 22:25 |
paramat |
cool |
| 22:25 |
RealBadAngel |
folks can wait for game to load a bit longer |
| 22:26 |
paramat |
because the current nodebox definition is simple and easy, even i wouldn't want to use blender for that |
| 22:26 |
RealBadAngel |
but if a stairs nodebox with just 2 boxes is slower than 7k vertices r2d2 model then its worth it |
| 22:26 |
paramat |
yes i agree |
| 22:27 |
RealBadAngel |
my target is to leave in custom drawtypes only those which are changing, are dynamical |
| 22:27 |
RealBadAngel |
rest will be turned into native irrlicht ones |
| 22:29 |
RealBadAngel |
but anyway, one with a bit of blender experience can replace almost any drawtype with meshnode |
| 22:30 |
paramat |
so meshnode shading (by surface normals) roughly matches the current shading of nodes? (top brightest, base darkest, EW faces slightly darker than NS faces? |
| 22:30 |
RealBadAngel |
with far more better results |
| 22:30 |
RealBadAngel |
yes |
| 22:30 |
paramat |
good |
| 22:30 |
RealBadAngel |
mesh comes with precalculated normals |
| 22:31 |
|
blaise joined #minetest-dev |
| 22:31 |
RealBadAngel |
whats more interesting can be cloned into mesh with tangents |
| 22:32 |
RealBadAngel |
but thats for laters |
| 22:32 |
RealBadAngel |
atm i will add static meshes |
| 22:33 |
RealBadAngel |
i know how to make also animated ones but this is far more complicated than static |
| 22:33 |
paramat |
for example, if i make a simple mesh which has all faces axis-aligned (like stairs) it would be good to be able to simply assign 6 textures to top/base/n/s/e/w as currently, without using blender |
| 22:33 |
RealBadAngel |
and will require static in the first place |
| 22:34 |
RealBadAngel |
paramat, you should check out terasology |
| 22:34 |
paramat |
aha i have |
| 22:34 |
RealBadAngel |
they are using clean models without textures |
| 22:34 |
RealBadAngel |
to define everything |
| 22:34 |
RealBadAngel |
and adding just textures |
| 22:34 |
paramat |
their shaders look horrible =) |
| 22:34 |
RealBadAngel |
theyre good |
| 22:34 |
RealBadAngel |
but damn slow |
| 22:34 |
paramat |
lol i would say that |
| 22:36 |
RealBadAngel |
but again, about stairs example |
| 22:36 |
RealBadAngel |
you can define uv based on one texture |
| 22:36 |
RealBadAngel |
like player model does |
| 22:36 |
RealBadAngel |
and know which parts of it are sides |
| 22:37 |
paramat |
ah okay |
| 22:37 |
RealBadAngel |
then using the same model for another node and modified texture |
| 22:37 |
paramat |
editing the character model texture is easy enough |
| 22:38 |
RealBadAngel |
you know that theyre meshes? |
| 22:38 |
RealBadAngel |
so why do you think meshnodes will be harder? ;) |
| 22:38 |
paramat |
well now i understand, thanks |
| 22:39 |
RealBadAngel |
also fun fact: size of texture will not matter |
| 22:40 |
RealBadAngel |
mapping will stay the same |
| 22:40 |
RealBadAngel |
you can have textures 1024x and 16x for the very same mesh |
| 22:41 |
RealBadAngel |
and they will be properly mapped without any effort |
| 22:43 |
paramat |
i want to see your work merged, so my advice is don't mix your speed-improving work with controversial changes to MT's visual style. i think this is why your pulls get blocked so often |
| 22:43 |
RealBadAngel |
how folks will use meshes is not my concern |
| 22:44 |
RealBadAngel |
accusing hammer producer that it was used to smash some1 in the head instead to a nail would be the same |
| 22:45 |
|
blaise joined #minetest-dev |
| 22:45 |
RealBadAngel |
drawtype itself doesnt change anything in the game |
| 22:45 |
RealBadAngel |
it just offers unlimited possibilities |
| 22:46 |
RealBadAngel |
rest is up to modders |
| 22:49 |
|
Taoki joined #minetest-dev |
| 22:49 |
jin_xi |
so, i think i just had a genius idea for dynamic textures: what if we create a [dynamic texture modifier, so it creates a texture with _two_ textures? |
| 22:50 |
jin_xi |
so you can switch them instead of creating new ones endlessly |
| 22:50 |
RealBadAngel |
ehm, we do have such mechanism already? |
| 22:51 |
jin_xi |
so digilines and signs and similar mods could work better |
| 22:51 |
jin_xi |
RealBadAngel: what? |
| 22:51 |
RealBadAngel |
tiles and special tiles |
| 22:51 |
jin_xi |
no, for dynamic textures which are changed in-game |
| 22:51 |
|
shadowzone joined #minetest-dev |
| 22:51 |
RealBadAngel |
ofc |
| 22:51 |
RealBadAngel |
theres a PR waiting that does it |
| 22:51 |
jin_xi |
oh |
| 22:52 |
RealBadAngel |
you simply define one set in tiles, another in special tiles |
| 22:52 |
RealBadAngel |
MSB of param2 switches them |
| 22:52 |
RealBadAngel |
runtime |
| 22:52 |
jin_xi |
but what if your texture is going to change? |
| 22:52 |
RealBadAngel |
for any kind of drawtype |
| 22:53 |
paramat |
RBA, for example, 'disable crack animation' pull is, i suspect, being delayed partly because you increased number of digging particles |
| 22:53 |
RealBadAngel |
by 3 |
| 22:53 |
RealBadAngel |
ROTFL |
| 22:53 |
RealBadAngel |
while dug one has way more |
| 22:54 |
RealBadAngel |
some folks are just idk, sarcastic? dumb? ironic? |
| 22:54 |
RealBadAngel |
no comments anymore ;) |
| 22:55 |
RealBadAngel |
calling 3 particles 300% when dug one has a few k %? |
| 22:55 |
|
blaise joined #minetest-dev |
| 22:57 |
RealBadAngel |
https://github.com/minetest/minetest/blob/master/src/particles.cpp#L242 |
| 22:58 |
RealBadAngel |
so following, dug one has 3200% more particles, and you can live with it :P |
| 22:59 |
RealBadAngel |
not to mention SN proposed once to increase that number already |
| 22:59 |
RealBadAngel |
by 25600% :P |
| 23:01 |
RealBadAngel |
https://github.com/minetest/minetest/pull/943 |
| 23:04 |
proller |
rewrite particles first |
| 23:04 |
RealBadAngel |
not my job, jin_xi is doing that |
| 23:06 |
RealBadAngel |
proller, and btw, you should know im developing the code on rather low end hardware |
| 23:06 |
RealBadAngel |
1,8ghz dual core, gallium drivers amd |
| 23:06 |
proller |
like rpi ? ;) |
| 23:06 |
RealBadAngel |
and i wont allow anything that would slow the game for me |
| 23:07 |
RealBadAngel |
unlike the other devs im rewriting the code all the time until i get satysfing results |
| 23:07 |
RealBadAngel |
and i do measure it |
| 23:08 |
RealBadAngel |
i am still a demoscene coder |
| 23:08 |
proller |
then you must rewrite most ugly places |
| 23:08 |
RealBadAngel |
lol, you never saw really ugly code then ;) |
| 23:09 |
RealBadAngel |
but you will, soon |
| 23:09 |
RealBadAngel |
with a guarantee it couldnt be done faster |
| 23:11 |
RealBadAngel |
point is that coding demos, and games have one goal |
| 23:11 |
RealBadAngel |
speed |
| 23:11 |
RealBadAngel |
not the nice code |
| 23:11 |
|
mos_basik_ joined #minetest-dev |
| 23:11 |
paramat |
indeed particles on dig is much higher at 32, however, this is one of those things celeron may not like ;) |
| 23:11 |
RealBadAngel |
if some1 thinks otherwise propably he should ask bill to hire him at mc |
| 23:12 |
proller |
i'm about slowest places |
| 23:12 |
jin_xi |
#of particles and their gravitation and such should not be hardcoded imo |
| 23:12 |
|
mos_basik_ joined #minetest-dev |
| 23:12 |
RealBadAngel |
proller, 3 particles more doesnt slow anything |
| 23:13 |
RealBadAngel |
you know what is slowing your game? like really? |
| 23:13 |
RealBadAngel |
cracks |
| 23:13 |
proller |
no |
| 23:13 |
RealBadAngel |
test the pull, disable the cracks |
| 23:13 |
RealBadAngel |
and enjoy :P |
| 23:13 |
proller |
cracks and particles slows ONLY on player interact |
| 23:14 |
proller |
but here is other slow things |
| 23:14 |
RealBadAngel |
you dont get |
| 23:14 |
RealBadAngel |
cracks are causing mesh updates for a block |
| 23:14 |
RealBadAngel |
so whole mesh is recalculated |
| 23:14 |
RealBadAngel |
for 16x16x16 nodes |
| 23:14 |
proller |
"it was solved in freeminer" ;) |
| 23:15 |
RealBadAngel |
no it wasnt |
| 23:15 |
RealBadAngel |
stop trolling :P |
| 23:15 |
RealBadAngel |
i did that but you never saw the code :P |
| 23:16 |
paramat |
personally, for speed reasons, i want to disable cracks, and not use highlighting, because i don't need to see dig progress. so i want to see your pull merged RBA |
| 23:16 |
RealBadAngel |
cracks and highlighting will become independent scene nodes |
| 23:16 |
proller |
mesh update - one of ugliest places |
| 23:16 |
RealBadAngel |
without need to refresh the mapblock |
| 23:17 |
RealBadAngel |
they will just use a copy of single node mesh |
| 23:17 |
paramat |
as you probably know, i have similar AV tastes to c55, so if you can keep me happy, there's a chance c55 will merge your work =) |
| 23:18 |
RealBadAngel |
paramat, you can define with mesh most simple and dumb voxel node |
| 23:18 |
RealBadAngel |
and it will be faster than nodebox |
| 23:18 |
paramat |
i would ask to be AV manager but i'm not qualified |
| 23:18 |
paramat |
cool |
| 23:18 |
RealBadAngel |
but |
| 23:18 |
RealBadAngel |
you can use it for something like this: |
| 23:19 |
RealBadAngel |
http://i.imgur.com/fUon82U.png |
| 23:19 |
RealBadAngel |
its only up to you |
| 23:29 |
paramat |
to me that looks ridiculous in a voxel game, however, i think very simple geometric shapes (like sloping roofs) will look okay in MT, and meshes will be good for this |
| 23:30 |
RealBadAngel |
also micronodes, nice furniture, complex machines |
| 23:30 |
RealBadAngel |
whatever you can imagine |
| 23:31 |
RealBadAngel |
without any limitations of nodeboxes |
| 23:32 |
paramat |
the digging particles argument: indeed 3 more particles is not much compared to breaking the node, however i suspect c55 and others will not want that changed (even though there is no performance hit), and that should really be a separate pull request |
| 23:34 |
shadowzone |
That is one interesting texture. |
| 23:40 |
RealBadAngel |
paramat, i wont be changing tested and proven to be fast code basing on some imaginations |
| 23:42 |
RealBadAngel |
using the phrase "300%" in the pull was just a pure nonsense |
| 23:42 |
kahrl |
the number of particles is really more artistic than performance based |
| 23:42 |
RealBadAngel |
and smelled monthy python |
| 23:43 |
RealBadAngel |
i raised the number of particles for the valid reason |
| 23:44 |
|
Taoki joined #minetest-dev |
| 23:44 |
RealBadAngel |
if cracks are disabled the process has to be more visible |
| 23:44 |
RealBadAngel |
and it plays nice together with highlighting |
| 23:44 |
RealBadAngel |
which also changes when digging |
| 23:44 |
kahrl |
but the number is just ridiculously large with the default settings |
| 23:44 |
kahrl |
i.e. crack animation, no node highlighting |
| 23:45 |
RealBadAngel |
dug one is a bit too much |
| 23:45 |
RealBadAngel |
i set it to 4 on punch (digging) |
| 23:45 |
paramat |
RBA separating number of dig particles from 'disable crack animations' will not affect your peformance improving code. such an attitude may be why your pulls are often not merged ;) |
| 23:46 |
RealBadAngel |
paramat, i dont care anymore if my pulls are merged or not |
| 23:46 |
RealBadAngel |
i know im doing good code |
| 23:46 |
paramat |
well i care, i want them merged |
| 23:46 |
RealBadAngel |
if mt wont have it? pity |
| 23:46 |
RealBadAngel |
i will |
| 23:47 |
paramat |
separating artistic matters allows your performance code to be merged quickly, unobstructed by artistic arguments |
| 23:47 |
RealBadAngel |
coding is an art |
| 23:48 |
RealBadAngel |
whoever thinks its a job should use the hammer. to kill himself for sake of humanity |
| 23:49 |
RealBadAngel |
any other way we will see M$ each time we will open the fridge |
| 23:51 |
paramat |
as i said in the comments, each punch releases 4+ particles already, not 1, so doesn't need increasing much, perhaps double it? i actually think 32 on node break is too much =) |
| 23:52 |
RealBadAngel |
before it was just 1 |
| 23:52 |
RealBadAngel |
now its 4 |
| 23:53 |
RealBadAngel |
that 32 could be lowered, by half propably |
| 23:53 |
RealBadAngel |
hey, thats what Blockmen could understand! MINUS 1600% lol |
| 23:55 |
kahrl |
so what about making the number dependent on the crack animation setting? |
