Ma-Shell

When objects other than the light move, the matrix of the light stays the same. So does this mean that shadows for dynamic objects are only updated, when the lights move?

And make sure, you do this for all Configurations (the dropbox in the upper left corner). I just spent an eternity trying to find out, why that window ignored me.

Well, you could create a new class OggOpenALSound, which uses the OpenALSound as a base-class and just overwrites the Load-function. I played around with getting the open-source-library opusfile (opus is the latest codec for ogg) to run with Leadwerks but I stopped, when I noticed that these guys have neither .lib-files, nor vs-projects, which makes linking it a major hassle.

Both of your links are the same. Are you sure, all the necessary power cables are actually plugged into your gfx? Some cards need more cables than others.

I'd rather say it this way: there is a huge speed difference BUT unless you are going to write some really really heavy code, graphics, physics, etc will take up 99% of your time between the frames. These things are handled by LW internally, which is written in C++. No matter, whether your own code is C++ or LUA, these LW-functions will always be executed from their compiled C++-form. TL;DR: You most likely won't notice any difference.

Your pivot is an entity and an entity has a body. Try this: NewtonBodyDisableSimulation(((NewtonDynamicsBody*)pEntity->body)->body);

There is one x64 and one x86 version in that folder. Just install the x86, if you have a 32 bit Windows.

You need to install VC-redistributable. If you look into your Leadwerks-install folder, you'll find "_CommonRedist/vcredist". I suppose, you'll need to install the 2015-version from that folder.

You could try disabling physics for that body for one frame and then enabling it again the next frame (haven't tried, whether this will actually stop the entity but it might be worth a try). In this post I described how to do that: http://www.leadwerks.com/werkspace/topic/13883-hidden-entities-still-get-iterated-over-in-le/page__st__20#entry95890

Einlander did something similar some while ago. While this isn't exactly what you want, this might still be interesting to you: http://www.leadwerks.com/werkspace/blog/120/entry-1414-playing-around-with-near-real-time-map-edititng/

That's quite an interesting bug you have right there. What flags are you using in release mode with gcc? Also, have you tried printing out all the values after each intermediate step to find out, where exactly the values turn to -NaN? From the function you posted, the only two ways for getting NaN, would be a division of 0/0, or calculating acos of a value outside the range ]-1,1[. Both functions would be only possible inside the if(d<1.0f) - branch. However, in your case, in order to get to this branch, the value of d must be in the range [0.0, 1.0[, thus the acos-function can't produce NaN. Furthermore, the value of si = sin(acos(d)) is only zero for d==-1 or d==1, which again can not happen. All the other math-functions can only return NaN, if (at least) one of their inputs is already NaN, so I would be very interested in seeing, where the values actually start turning crazy. Can you provide input values for "q" and "result", and "this", that reliably produce this misbehaviour?

So you're looking for the maths to determine, whether the characters are facing each other, right? Assume, c1 is your character's entity and c2 is your NPC's. We start off, by calculating the forward-vectors of both characters (as discussed in http://www.leadwerks.com/werkspace/topic/11708-vision-cone/ ) and obtain forward_c1 and forward_c2. Next we need the vector between both characters, which can be obtained by subtracting one position from the other. Now we need to calculate two angles: The first angle (called angle1) is the angle between both forward-vectors. If this angle is maximal (at PI=3.14), the vectors are pointing into exactly the opposite directions and it's likely the characters are looking directly at one another. However, it could also be, that both characters are standing back-to-back. To determine this, we also calculate a second angle (angle2) between your character's looking-direction and the diff-vector. If this value is maximal, your character is facing away from the NPC. So we need to give a threshold for both of these angles, in order to determine, whether the characters are facing each other. The following code should print the two angles and "match", if the characters are facing each other, and "no match", if they are not. You might want to play around with the thresholds (2.5 and 0.5), until you find values that suit your needs. Vec3 diff = (c2->GetPosition(true) - c1->GetPosition(true)).Normalize(); Vec3 forward_c1 = Vec3(c1->mat.k.x, c1->mat.k.y, c1->mat.k.z).Normalize(); Vec3 forward_c2 = Vec3(c2->mat.k.x, c2->mat.k.y, c2->mat.k.z).Normalize(); float angle1 = acos(forward_c1.Dot(forward_c2)); float angle2 = acos(forward_c1.Dot(diff)); bool match = angle1 > 2.5 && angle2 < 0.5; char* match_str = match ? "match" : "no match"; printf("%f, %f, %s\n", angle1, angle2, match_str);

That's not entirely true. WPA is only a link-level protocol. This means that the message is decrypted when it reaches the access point. The same holds for your cellular data. Once the message reaches the wire, it could theoretically be eavesdropped / modified by any node between your router and the destination. For actually securing your data you should use a transport-or-higher-level protocol, like SSL/TLS. Most websites with a login-functionality offer HTTPS (which is a form of SSL/TLS) and only allow their login over HTTPS. TL;DR: HTTPS keeps you encrypted even on public WIFI.

You will have to sign up with your steam account here: https://partner.steamgames.com/ After you have done this and aggree to their terms and conditions, you can download the entire sdk including x64 versions of the libraries on the right.

Unfortunately I have never used any books or tutorial series to learn C/C++. Things just came naturally to me, when I was tought programming at school and I only ever had to look up very specific things. The best thing you can do, is to look at existing projects and try to understand the code. Then start by modifying some values and see, if they have the desired effect and then move on to bigger code-changes. Of course, if you have never programmed before, you will have to learn about the general concepts like variables, functions/methods, and the C-memory-model first, in order to understand things, but, as cassius said, there are lots of good tutorials online. About the "C style C++": You can just take any code that would compile with C and use it, just as simple as that . If you want to write C++ in C-style then you just need to learn C.

I also wouldn't see a benchmark as relevant for deciding whether to use Leadwerks with C++ or LUA: The computationally most expensive parts of a frame are most likely the rendering and the physics simulation, both of which are done by Leadwerks. Unless you totally screw up, your own programs written for Leadwerks will not influence the computational speed too much.

Welcome! The basic concepts between C and C++ are the same. In fact, you can write most of the C++-stuff in C-style, as well. The most important difference between C and C++ is that C++ is (/can be?) object oriented. This means that things are organized in classes, which have attributes and functions. Actually classes are only more comfortable ways to represent structs and corresponding functions. In order to work with the C++-Edition of Leadwerks, you will have to make yourself familiar with the concepts of classes, but other than that, there is not much difference between C and C++.

Not sure, but I would assume, the material gets overwritten by the SetShape-function. Have you tried putting the SetMaterial after that?

I agree with Rick and nick.ace: You should really use a 2D-array for that purpose, which also means, you neither have to store the cell's position, nor its row/column, as you can get that from the array. The memory usage should not be a problem. If you really notice that you have a problem with the memory consumption, you might want to use quadtrees: Devide the map into four parts. For each part store whether it contains walkable cells. If it does not contain walkable cells, you can just stop there. If it does contain walkable parts, you further divide the tile into four tiles and repeat the procedure until you reach your final grid resolution. That way you can discard big chunks of un-walkable tiles earlier. I hope, you can understand my explanation. Just tell me, if you need further explanation on this. While you can save some memory with this technique, using quadtrees instead of arrays also comes with a price, because now you actually have a time complexity of O(log(n)) (or something similar; I never liked calculating runtime complexities ) instead of O(1) in order to access the individual cells. To sum this up: You should be fine using an array! If you really don't want to do that because of the memory consumption, use quadtrees/octrees. UNDER NO CIRCUMSTANCES use a linked list for this purpose. Furthermore, DO NOT explicitly store the position or row/column of the cells, as you can get them as the index of the array.

At the moment, community member Rastar is gauging interest for shader programming and eventually he may be doing a kickstarter for a tutorial series. Maybe that is something for you: http://www.leadwerks.com/werkspace/topic/14291-gauging-interest-shader-programming-in-leadwerks/ Also take a look at his blog, which explains some concepts of the various types of shaders: http://www.leadwerks.com/werkspace/blog/117-rendering-puzzles/ In general you can basically take any tutorial on GLSL shader programming out there, but keep in mind that Leadwerks is a deferred renderer and thus doesn't perform lighting calculations in the fragment shader, but instead has multiple output buffers.

I am currently not at my pc with leadwerks so I can't try it, but setting the filter mode in the left window of your screenshot ("Texture Editor") to something like "Pixel" instead of "Smooth" should achieve the same thing as the command you posted. Also, I guess, this should be visible in the editor.

hmm, strange, but if it works now, that doesn't matter... With a bit of maths you can do anything . You will have to modify the shader: Open up the shader in the shader editor (you can do so by clicking the icon with the pen in the material editor). Make sure, you are editing the fragment shader (there is a selection box where you can switch between vertex/geometry/control/evaluation/fragment). You should see the code I posted above (with a slight modification). All the magic happens in this line: fragData0.rgb += .2*sin(tan(texcoords0.y-currenttime*.008)*10)+.25 if you change the factor after currenttime (0.008), you can influence the speed. Just play around with the values there. If you e.g. want to have a regular pattern instead, you could also go ahead and just remove the "tan".

That's just in the editor. Try pressing the start-button and view it in-game. Then it shouldn't be red anymore. I edited my post above to point to the shader-file that should look correct in the editor, as well.

No, this is NOT a postprocessing-shader. This is a material-fragment-shader. To apply it do the following: Open up the material-editor for your hologram's material Set the Blend Mode to "alpha" and the diffuse color to some nice blue Go to the shaders-tab As the shader choose the one attached to this post (you should rename it to have ".shader" in the end, instead of ".txt"). The attached one has its vertex-shader and its fragment-shader already set (as they always have to fit together), so you don't have to do that anymore. hologram.txt

You don't need to live with this It is possible to directly access the NewtonDynamics-Functions like so: Joint* j; j = (...) NewtonJointSetStiffness(((NewtonDynamicsJoint*)j)->newtonjoint, 0.42); will set the stiffness of the joint j to 0.42. Of course you will have to make j point to the joint you created previously, before calling the function. EDIT: Oops, just noticed, you are probably using LUA, as you wrote things like "Model:Box()". No idea, whether you can do something like this in LUA.