[Help with 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

[Help with rain]

Take a look at this thread:

http://www.leadwerks.com/werkspace/topic/12160-rain-possible/#entry88234

[Mouse and multiple monitors]

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.

[Mouse and multiple monitors]

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);

[evp.h]

I ran into this too. You need to change the working directory. For some reason that doesn't transfer over properly. Right-click on your project name on the left, click Properties, Debugging and fix the Working Directory. $(SolutionDir)..\..\ worked for me.

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.

[Ogg support]

Presently it's not possible to plug in a sound loader class

 

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.

[New gfx card help]

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.

[C++ vs Lua]

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.

[Physic Stop]

Your pivot is an entity and an entity has a body. Try this:

NewtonBodyDisableSimulation(((NewtonDynamicsBody*)pEntity->body)->body);

[Help! My Leadwerks kinda error...]

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

[Help! My Leadwerks kinda error...]

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.

[Physic Stop]

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

[Realtime Playing/Editing]

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/

[swordfight prob [c++]]

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);

[LibSteam api architecture]

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.

[I'm new to all this.]

@Ma-shell I think for now I'll take a crack at Lua to at least feel it out, but still I think it would be handy to know some C++ down the line, and the "C style" C++ you mentioned helps make it less intimidating. Any books/tutorials that demonstrate this that you know of?

 

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'm new to all this.]

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.

[I'm new to all this.]

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++.

[Cylinder and Materials]

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

[How would you store a grid-based map?]

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.

[Shader, any there are tutorials with examples?]

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.

[2D pixel art shader ?]

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.

[Holograms & Holographs?]

I was viewing in-game (Run Game)

 

hmm, strange, but if it works now, that doesn't matter...

 

Is there a way of slowing down the flicker?

 

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".

[Holograms & Holographs?]

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.

[Holograms & Holographs?]

No, this is NOT a postprocessing-shader. This is a material-fragment-shader. To apply it do the following:

1. Open up the material-editor for your hologram's material
    
   
2. Set the Blend Mode to "alpha" and the diffuse color to some nice blue
    
   
3. Go to the shaders-tab
    
   
4. 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