Ma-Shell

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.

To get you started: use a blue material (mode alpha) and some simple fragment-shader like this: #version 400 //Uniforms uniform sampler2D texture0; uniform vec4 materialcolordiffuse; uniform float currenttime; //Inputs in vec4 ex_color; in vec2 texcoords0; in float clipdistance0; //Outputs out vec4 fragData0; void main() { //Clip plane discard if (clipdistance0>0.0) discard; fragData0 = ex_color * materialcolordiffuse; fragData0.rgb += .2*sin(tan(texcoords0.y-currenttime*.008)*10)+.25; fragData0.a = .5; } This does in fact look horrible. You will need some (maybe even a lot of) fine-tuning of the parameters, but it should give you an impression, how to create that flickering look.

[App.h]: Buffer* mybuffer; Buffer* mainbuffer; Texture* mytexture; Texture* mydepthtexture; [App.cpp, App::Start after context = Context::Create(window);] mainbuffer = Buffer::GetCurrent(); mybuffer = Buffer::Create(context->GetWidth(), context->GetHeight(), 2, 0); mytexture = Texture::Create(context->GetWidth(), context->GetHeight(),Texture::RGBA,0,1,0); mydepthtexture = Texture::Create(context->GetWidth(), context->GetHeight(), Texture::Depth, 0, 1, 0); mytexture->SetFilter(Texture::Smooth); mybuffer->SetColorTexture(foregroundtexture1); mybuffer->SetDepthTexture(foregrounddepthtexture1); mybuffer->Disable(); [when rendering (normally in App::Loop())] world->Update(); Buffer::SetCurrent(mybuffer); mybuffer->Enable(); world->Render(); mybuffer->Disable(); Buffer::SetCurrent(mainbuffer);

I assume, what you want is the following (where s is the source): ALint i; alGetSourcei(((Leadwerks::OpenALChannel*)s->channel)->source, AL_SAMPLE_OFFSET, &i); printf("%i\n", i);

Which OpenAL-function are you talking about? If Leadwerks doesn't provide it, you can directly call it. See the following example: Sound* snd = Sound::Load("Sound\\Footsteps\\concrete1.wav"); Source * s = Source::Create(); s->SetSound(snd); s->SetLoopMode(true); s->Play(); if (alIsSource(((Leadwerks::OpenALChannel*)s->channel)->source) == AL_TRUE) printf("Source TRUE\n\n"); if (alIsBuffer(((Leadwerks::OpenALSound*)s->sound)->buffer) == AL_TRUE) printf("Buffer TRUE\n\n"); alSourceStop(((Leadwerks::OpenALChannel*)s->channel)->source); As you can see, you can get the OpenAL-source and OpenAL-buffer as demonstrated. If you need any other OpenAL-ids, I would be glad to show you, how you can retrieve them.

Also for the record, here you can see, what happened to the option you are missing: http://www.leadwerks.com/werkspace/blog/1/entry-1439-cleaning-up-physics-shapes/

Just get a script that does copies and formats your disk at system boot... Have you tried creating a new user on your pc and executing leadwerks from this new user? Also, when executing tasklist with the parameter "/V", does it say, the state of the processes is "Running"? EDIT: Bonus: get the parent process of the leadwerks-processes by issuing: wmic process where (processid=7276) get parentprocessid (change the pid with your current values and find the result in tasklist)

You are missing context->Sync(false) right between the render call and the return of the loop. This call is important, as everything is only rendered to the backbuffer and the buffer is never switched to become front-buffer

Hi, are the missing models imported meshes or are they brushes (i.e. simple forms created in the editor, like boxes, spheres, etc)? In the latter case, it is important to know, that they get collapsed, so that they are only one model, which has several advantages with respect to performance. You can prevent them from being collapsed by either giving them a mass =/= 0 or by assigning a script (just a dummy one is enough).

Or you right-click and choose "properties" -> "local data" -> "check game-data for errors" (the actual texts might differ from those I wrote here, because I had to translate them from my native language). By doing this, you don't have to download everything all over again.

Hi, for the window, "window->whnd" should do the trick. For the context you will need a typecast: "((OpenGL4Context*) context)->hrc"

Actually, it's not only the physics, since I get a lot more fps, if I don't create them at all (~80), but disabling the simulation for these bodies increases the fps from like 1 frame every 30 seconds to like 30 FPS, which is still massive. Also, I noticed, if I delete the phy-file, I also have to wait ~20 seconds after the scene has loaded, before the fps stabilize. The whole code I inserted into App::Start(): Model* m; for (int n = 0; n < 20000; n++) { m = Model::Load("Models/Trees/pine01.mdl"); m->SetPosition(n, 0, 0); NewtonBodyDisableSimulation(((NewtonDynamicsBody*)m->body)->body); m->Hide(); } (You can re-enable physics by calling "NewtonBodyEnableSimulation" with the same parameter.) Is something like this possible in LUA?

In C++ you can get access to a few more functions for manipulating physics by casting m->body (best look at the definition of NewtonDynmaicsBody in Newton.h): ((NewtonDynamicsBody*)m->body) Furthermore, you can access the NewtonBody-structure which is used internally for all the Newton-functions by doing: ((NewtonDynamicsBody*)m->body)->body You can then proceed to call any function from the Newton by using this body. Sadly, I have no idea, whether you can do something like this on LUA. However, I don't think that the problem lies in the physics, since if I remove the file "pine01.phy", there is no physics-model, as can be seen by issuing camera->SetDebugPhysicsMode(true); in App::Start(). The FPS are bad in that case, nevertheless... EDIT: By "all the Newton-functions", I meant those: http://newtondynamics.com/wiki/index.php5?title=API_Database Also notice, that you won't see an effect for some, as they get overwritten by Leadwerks in the world-update (I guess). EDIT2: It IS in fact the physics. You can call NewtonBodyDisableSimulation(((NewtonDynamicsBody*)m->body)->body); Doing this with 20000 trees will give me a solid 30 fps on my i5 2500 and gtx970. Withouth that line, I get like no frames at all... However, even after the scene has loaded, it takes a few seconds (~20) before the fps stabilize.

Thx, shadmar, for this example. For this to run, you will nevertheless have to modify some parts of your vertex-shader, so that the "in"s and "out"s match. That's not true. You just have to set the same shader in the Material-Settings in the Shaders-tab as the Shadow-shader, then it will have a shadow. This is the advantage of shadow maps: The shadows are generated from the depth-buffers of the generated fragments, so that is after the fragment-shader (and since the fragment-shader is run for the newly generated gemoetry, as well, they can cast shadows as well).