Roland

In this case the problem had nothing to do with libraries.

std::string period.

For such external source files (c or cpp which you have no control of) added to project you have to select them and go into properties. Change those to "Not using precompiled headers". They do not have the #include "your precompied header file.h" as fist statement and cant be used for this.

Thats nice. And thinking of it, if someone needs to have it as a DLL (C# users) it can be solved by creating a own DLL containing the lib.

As I'm using C++ a static lib would be fine. Specially as you will not have to bother about using memory over a DLL boundary. But the downside would be that the C# users would suffer as the import to C# wrappers must go through a DLL.

Nice. Hello World is a good start

You should always do this in any case. You can preferable use the new way of doing this in all headers #pragma once your code .... .... ... This has nothing to do with compilation speed. This is a way to avoid double declarations in nested includes. Regarding changing headers often while developing you can go this way. Include all your own headers in the pre-compiled header when they are stable. This means that while you are changing things often in a header while working, you should not include this header in the pre-compiled header. Then when your work is more stable and does not change to often you may include the header file in the pre-compiled header. A little religious note about this: ---------------------------------- Making frequent changes in header should not be needed if you have thought things through before hitting the keyboard. When I write code I try to write the headers first with all that should be needed. Then I go into implementing the headers. If I then have to make a change in a header it should be more of an emergency and tell that I did not think enough before starting with the code. Of course this is true in a perfect world and of course I have to change my headers now and then. But in general they should not have to be changed to often. If you have to make changes in the headers often, it may be pointing to the fact that you are creating to big classes. Always try to break things down to as small pieces (classes) as possible and don't fall into the trap of having four of five giants taking care of all. This is my personal notes. Others may think different. But I thought it could be mentioned here as a note about pre-compiled headers. ----------------------------------

Maybe this could help

for small cpp files less than a second

Just great work as usual.

You need one header that is the target for pre-compiling, in our example its the leheader.h. Which headers to be included in the pre-compilation is defined by you when you include other headers in leheader.h. This way you can tell which headers to be pre-compiled and not. The natural thing is to add all system/sdk/stdlib-headers there as the never changes. Then you could add your own headers that you don't change so often. One suggestion is to include the ones that are stable and have the experimental ones not included. Then when the experimental ones become stable you can include them. In previous versions of VS there was an alternative where you could tell to use all headers as precompiled. That options was removed as it did not work well at all (I don't know why as I never used it). Anyway, since the Jura-period they have recommended the method used now. Hope that this helped a bit

No. That's why Pre-Compiled header option exists. This can't be set by default as there is a need to define which file should be used as pre-compile header.

Thats true, but I'm not talking about compiling source files. Here we are speeding up things by using pre-compiled headers (not cpp). Normally the compiler has to pre-compile each included header every time when in compiles a source file. That takes time. The option to use pre-compiled headers makes this pre-compilation only needed when any of the included headers changes. This results in a faster compilation as you normally make changes in the cpp files. The compilation time can be improved a great deal in big projects.

Make one header file that includes most of the system includes and your most common includes. Then include that header file first thing in each source file. Name it anything you want, lets say leheaders.h #pragma once #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <string> #include <vector> #include ..... #include ..... etc etc etc..... Make one leheaders.cpp that contains one statement #include "leheaders.h" In project properties Set C++ settings "Precompiled headers" to "Use" Precompiled Header = leheaders.h Select leheaders.cpp and Properties Set C++ settings "Precompiled headers" to "Create" This will precompile your headers so they don't need to be parsed and compiled on each project compile. The only time precompilation is done is when you change something in the header files included in leheaders.h or if you selects rebuild. You must include leheaders.h as first include in all your sourcefiles. Also check that "C++/Browse Information" is "No" Edit: "C++/Code Generation/Enable Minimal Rebuild" should also be set to "Yes" "C++/General/Debug Information Format" set to "Program Database (/Zi)"

use precompiled headers

In that case I have no problem with it.

I might have misunderstood this but in the blog Josh gives an example Class Vec3 { Field x:Float Field y:Float Field z:Float } I thought this was the substitute for class Vec3 { public: float x; float y; float z; Vec3(): x( 0.0 ), y( 0.0 ), z( 0.0 ){} }; Quite different.

I can't really see the meaning of making a C++ clone with your own syntax just to save some typing. People who already knows C++ has to learn yet another language and its a languages that cant be used elsewhere, and people that has no previous programming knowledge has to learn a language that they cant use for other things than Leadwerks. Of course I don't know the capabilities of this C++ clone, but I doubt it will produce better results than using the original language. To me it looks like making an own LE-version of Blitz. Another thing that worries me is the documentation of this language. The documentation of the engine could be far better than its now. Just having a reference to a community driven Wiki is kind of weak documentation. Introducing a new language would then make this shortage more obvious if the documentation is handle in the same way. I cant see that introducing a new language should save costs for the industry. They already have programmers that knows their C++. This would render in having them to learn this new language and that is really a big cost. Time is money as you say. I don't by that argument at all. I don't believe in spend time, creating new languages when there already is capable languages. If you fell that C++ is troublesome I would recommend that you go for a C# (Mono) solution instead.

Pixleperfect.... Yeah... Its tempting as I have a Pro licence for the engine using that one

Wow Pancakes. Thats what I call awesome and its also fun guy to listen to. Just Great

support at leadwerks dot com I guess

I have been pondering on some ideas on how to implement animation for my Cells game. Currently you can play character animations and as also blend them if I got it right. That's a good thing, but the drawback is that the character feet's tend to float over the ground and climbing footsteps is almost impossible to do. The alternative is having a IK driven character and write some IK solvers (some did I think) and then manage the animations that way. This will probably solve the problem and give some advantage like gripping things etc. The drawback is that you then cant use animations recorded in your external software. I want both standard animations and IK for the legs at the same time. Standard animations as BHV is great, but then we have the problems with having the feet's touch the ground. My idea is to on each frame, after the animation has placed the bones(or joints) at the prerecorded positions, move the feet's in Y-direction so they actually touch the ground. The model must of course have the legs IK-rigged. A Pseudo code for this could be something like OnUpdateFrame: // I assume the animation has already done its job here // and the we have a handle to each IK-Leg-Controller (LeftLegController,RightLegController) Find Y-position of LeftLegController Find Y-position of terrain at coordinates LeftController.X & Z Move LeftLegController.Y to TerrainPos.Y Repeat for RightLegController Run IK solver. I have not though about the details so far. What do you think guys and girls. Could this be something?

Okidoki. Thanks for that info Lazlo

Following links in C# Tutorials on the Wiki is missing Foreword PDF Getting Started PDF The author should either remove them or fix the links.

Great tool. Many thanks