Ma-Shell

For a minimap I would actually use an orthographic projection mode. I guess, in an orthographic projection, you can simply set the width and the height of the camera to exactly your map's dimensions. If you want to use a perspective projection: macklebee's formula surely looks nice but the map doesn't include the whole map (which I suppose, you want to have). Doing the math I arrive at Q = X/(2*Math::tan(camera->GetFOV()/2.0f)) (though I didn't test it)

I think, you should consider adding this to the API, as Herobot's use-case is quite a good example for the usefulnes of that function. I really hate it, when I alt-tab out of a game to change some setting and I can't because my mouse keeps jumping to the center of the screen. Also, there is relly not more to it than just comparing the output of "GetActiveWindow()" from the windows-API to "window->hwnd".

Yeah, as I said, the function is not documented and thus probably not exported to LUA. This means, you actually have no way to choose the rendered camera and should therefore use a pivot to mark the position of the second camera instead, like I did in my first post. In your UpdateWorld()-function, you then have to swap the position and the buffers and render. Try it like this: Script.buffer=0 Script.mapcam=0 function Script:Start() .... self.camera=Camera:Create() self.camera:SetRotation(0,0,0) self.camera:SetPosition(self.entity:GetPosition(true)+Vec3(0,1.8,0)) self.buffer = Buffer:Create(100, 100, 1, 1, 0) self.mapcam = Pivot:Create() end function Script:UpdateWorld() .... local buff=Buffer:GetCurrent() local mat = self.camera:GetMatrix() self.camera:SetRenderTarget(self.buffer:GetColorTexture()) self.camera:SetMatrix(self.mapcam:GetMatrix()) world:Render() self.camera:SetRenderTarget(buf:GetColorTexture()) self.camera:SetMatrix(mat) end function Script:PostRender(context) .... context:DrawImage(self.buffer:GetColorTexture(),0,0,100,100) end

You can also find an implementation that works without the pivots here (that's only the facing-directions-test without the distance-test, but the latter one is straight forward): http://www.leadwerks.com/werkspace/topic/15187-swordfight-prob-c/#entry102424

Well, actually I just found, that you can call camera->Render() instead of world->Render() (though this isn't documented and thus probably not available in LUA) and you can set a Render-Target. This means, you can actually simplify that a bit: Buffer* map_buf; Camera* map_cam; bool App::Start() { ... map_buf = Buffer::Create(100, 100, 1, 1, 0); map_cam = Camera::Create(); map_cam->SetRenderTarget(map_buf->GetColorTexture()); } bool App::Loop() { ... // Clear both buffers context->Clear(); map_buf->Clear(); // Render both cameras camera->Render(); map_cam->Render(); // Draw the map over the context int blendMode = context->GetBlendMode(); context->SetBlendMode(Blend::Solid); context->DrawImage(map_buf->GetColorTexture(), 0, 0, 100, 100); context->SetBlendMode(blendMode); context->Sync(false); return true; } This kind of cleans the rendering-function a bit.

Even with two cameras you would need to go through all this buffer-swapping-stuff and render the scenery twice. The reason for this is that you can only render the world to the currently enabled buffers. Also I don't know, how/whether it is even possible to switch the currently rendered camera. In order to decrease the costs of this you could do something like changing to a less costly render-mode for the map and decreasing the update-frequency, by only performing the rendering to the map-buffer, if at least X milliseconds have passed since the last rendering.

You will need to use multiple buffers and render the scene twice. You can use a pivot (I named it "map_viewport") to mark the position and rotation of the camera for the map. See the following C++-Example to see, how to do that. If you're using LUA, it should be pretty straight-forward to translate this. Buffer* map_buf; Pivot* map_viewport; bool App::Start() { ... map_buf = Buffer::Create(100, 100, 1, 1, 0); map_viewport = Pivot::Create(); } bool App::Loop() { ... // Clear both buffers context->Clear(); map_buf->Clear(); // Save the current position and rotation Mat4 cur_mat = camera->GetMatrix(true); // Set the camera's position and rotation to the pivot's camera->SetMatrix(map_viewport->GetMatrix(true), true); // Render the world to the map-Buffer context->Disable(); map_buf->Enable(); world->Render(); // Restore the position and rotation camera->SetMatrix(cur_mat, true); // Render the world to the context-Buffer context->Enable(); map_buf->Disable(); world->Render(); // Draw the map over the context int blendMode = context->GetBlendMode(); context->SetBlendMode(Blend::Solid); context->DrawImage(map_buf->GetColorTexture(), 0, 0, 100, 100); context->SetBlendMode(blendMode); context->Sync(false); return true; } Edit: Changed the code to use the transformation-Matrices instead of setting position and rotation, as this should be more efficient Edit2: Changed the blend-mode to Blend::Solid instead of Blend::Alpha

Are you using any other posteffects? If so, the order in which they are executed is important. It looks like in the first picture your image is darkened after applying the rain and in the second the darkening happens before applying the rain.

Look at the description on the second page of the same thread: http://www.leadwerks.com/werkspace/topic/12160-rain-possible/page__st__20#entry88294

Take a look at this thread: http://www.leadwerks.com/werkspace/topic/12160-rain-possible/#entry88234

The main problem is that between frames, if you move the mouse fast enough, you might click somewhere out of the window. The only possible solution for this is to tell the operating system to do so, using the windows-API as I showed in the above code-snippet. So the only way to do so without C++-version is, if Josh adds a wrapper for my 2nd snippet above to the Leadwerks-library, and exposes it to LUA. So Josh, please...? Edit: As a side-note: This does not only concern multi-monitor environments. If you have a non-fullscreen-window, this can happen to you on a single-monitor, as well, so I think many people might profit from a simple "trapMouseInContext"-function that does exactly what I've demonstrated.

If you have the C++-version, you can use the windows-ClipCursor-function for this: I recommend using the following in your App::Loop-function: if(window->Active()) ClipCursor(&window->rect); Using the window->Active-condition will ensure that you only do this, if your window is actually focused (so when you alt-tab, your cursor won't be locked). Also note, that upon moving the window or switching to a different window, the locking will be void, which is why you should put this in the App::Loop instead of at the start of the game (it would be even better to register a callback for focusing and putting it there but I don't think, that will gain you that much performance to actually be worth the troubles). I also noticed that window->rect is a bit off for me (strangely even the GetWindowRect-function returns this "false" rectangle). Also this includes the title-bar and the border. If you only want the area without the border (the so-called client-area), you can use the following chunk of code: RECT r; GetClientRect(window->hwnd, &r); MapWindowPoints(window->hwnd, HWND_DESKTOP, (LPPOINT)&r, sizeof(RECT)/sizeof(POINT)); if(window->Active()) ClipCursor(&r);

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.