Ma-Shell

For placing the turrets, you should multiply their positions with their widths. This means, you should differentiate between grid-coordinates and world-coordinates. So, say your turrets are 10 leadwerks-units wide, then your grid-point (0,1) would correspond to world-coordinates (0,10). The grid-point (9,8) would correspond to the world-coordinates (90,80), etc. This also means, when you are in the process of placing the turret, you should derive their grid-coordinates from world-coordinates by dividing the world-coordinate by the width, while rounding down, i.e., the world-point (94,83) would belong to the grid-point (9,8) and therefore the turret would be placed at (90,80). I hope, you can see, what I'm trying to say.

You should note, however, that the hardcoded ids are found in the compiled assembly-code and won't stop someone who is slightly experienced in binary editing.

This is most likely due to one of the Macros in that line not being defined. You would have to search the headers for the definitions of those macros (most likely WINMAPI, MMRESULT, or WINAPI) and include those files and hope that they do not have additional requirements. Since this is a part of DirectX (DirectInput), you will most likely have problems with this, nevertheless.

This is really amazing. How does this scale with lighting and physics? I would assume that there is not much overhead involved in the lighting calculations, which should be basically independent from the number of objects. However, the physics for all the trees at once would be a major problem. Do you have any tests or thoughts on this subject?

Woah, that's impressive! On what hardware do you get the 130 fps?

I tried that but this doesn't work. As soon as leadwerks.h is included, you can't prevent the LUA-Interpreter to be started. Even if you exit right in the first line of the main-function the tools for detecting memory leaks will tell you that there are allocated chunks everywhere. There seems to be something statically initialized. In the template code, there is no line which starts the interpreter (only one that connects it) and you can only disconnect it but never destroy it.

I don't think, this is possible... I tried to get rid of LUA a few times, since it is driving me nuts that I can't really check my games for memory leaks because the LUA-interpreter allocates and disallocates memory randomly (see e.g. this thread: http://www.leadwerks.com/werkspace/topic/9505-tons-of-memory-leaks-in-leadwerks/). Also, if you don't use LUA, this is only wasting performance and memory, so I would absolutely love to see the possibility to turn off LUA (/ to not turn it on in first place).

Just follow the link "API Reference" above... (direct link: http://www.leadwerks.com/werkspace/page/documentation/_/api-reference/)

That's a real shame. Blender's user interface is very well thought through. (Also, this statement makes me wonder, why you wanted this Blender plugin, if you seem to despise Blender.)

The microsoft compiler has some settings for optimization. You will find them in VS 2013 by clicking Debug -> [Project name] properties... -> Configuration Properties -> C/C++ -> Optimization You should set the value of "Optimization" to "Maximize Speed (/O2)" and "Favor Size Or Speed" to "Favor fast code (/Ot)". I am not sure, whether the other settings will also have a noticeable impact but these should be the most important ones. Be sure to select the "Release"-Configuration in the Combobox at the top of the dialog window.

Just because something isn't intuitive is no reason to abandon it. e.g. take blender: When you first use this tool you have absolutely no clue, what to do but once you get used to it, you will see, that it is designed to save loads of time! Another very important example for this is the command-line-editor vim. Hell, you will curse it a thousand times but if you take the time to actually learn to master it, you can be so much faster than with any other text-editor! I think, that the potential to be extremely fast is more important than intuitivity. But these things can go along with each other. Just have it enter the name automatically into the field, if you drag it and everyone is happy...

There is no difference between LUA and C++ projects anymore. If you own the C++-DLC, every new project you create will include a C++-project and sources.

Most of these values are printed, if you call self.context:DrawStats(10, 10, true) [LUA] context->DrawStats(10, 10, true) [C++] The third parameter ("extra") set to "true" instead of the default value "false" gives more output, which includes most of the values you mentioned.

The function signature is as it is written in the reference (only 5 parameters). You can access the individual components as position[0], position[1], position[2] normal[0], normal[2], normal[3]

They seem to have a problem with FBOs. See this thread: http://www.leadwerks.com/werkspace/topic/12058-performance-issues/page__st__20

You also have to make your functions in the base class "pure virtual". This is done by setting them to 0. The function from the base-class should read: virtual void Collision(Entity* entity, float* position, float* normal, float speed)=0; For more info on the difference between virtual and pure virtual refer to http://stackoverflow.com/questions/1306778/c-virtual-pure-virtual-explained

You will also have to override ALL the other virtual functions of the parent-class, if you want a class which is not virtual.

In your derived PlayerScript-class, you defined your methods as "virtual", which they aren't. They are only "virtual" in their parent-class. The compiler is searching for their implementations, which it can't find. Just leave out the "virtual"-keyword in the PlayerScript-class

What do you mean with "without interrupting anything"? You can get the mouse wheel as the z-coordinate of the GetMousePosition()-function (http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/window/windowgetmouseposition-r455)

How about categorising the non essential files and treating them like workshop-items, so you can choose whether to include them or not.

http://www.leadwerks.com/werkspace/files/category/39-leadwerks-2/ http://www.leadwerks.com/werkspace/files/file/186-leadwerks-engine-updater/ Community-Wiki: http://leadwerks.wikidot.com/wiki:tutorials Official Stuff: http://www.leadwerks.com/werkspace/page/documentation

You need to add the FPSPlayer-prefab. If it isn't in your project-folder, you can get it from the MyGame-project (located in \Steam\steamapps\common\Leadwerks\MyGame).

Just parent the box to the camera. No code needed.

Not really sure, what you are asking. Do you want to draw an image with an alpha-value above your rendered image? In that case the following code should do the trick: int blendModeOld = context->GetBlendMode(); context->SetBlendMode(Blend::Alpha); context->DrawImage(...); context->SetBlendMode(blendModeOld);

I don't really understand the question but I guess it's about the relationship between Context and Buffer. The Context-class inherits from / extends / is a sub-class of the Buffer-class, so basically the context is a special sort of buffer.