Canardia

SetViewport is commented out from the DLL, because it didn't work properly, but there is SetCameraClipPlane which does something similar.

It's even easier on Linux, because it has GNU C++ built-in.

Put your game.exe in a bin subfolder, and the dlls also. Then make a simple launcher exe in the main folder, which does a chdir("bin") and then starts the game using system("game.exe") or WinExec("game.exe").

Use string, not str for cl. str is just unsigned char*, and does not support == comparison. I recommend to copy paste shamelessly any code from gamelib, because it just works and is tested. If you can do it better, please do so, but it won't be tested, unless you test it yourself

I just looked at gamelib, and there I get the terrain in 3 steps: e=GetChild(scene,i); ... cl=GetEntityKey(e,"class"); ... if( cl=="Terrain" ) { // printf("******** FOUND TERRAIN ********\n"); terrain = e; SetEntityKey(e,"status","handled"); }

It's the first entity, so GetChild(scene,0) will return the terrain entity. You can also use FindChild("terrain"), but it's slower.

Yeah, it's a bug in IP boards. I tested it also on their official support forum, and got the same bug with tabs getting stripped from code tags. They never even bothered to publish my test report, so I think their support is actually less than zero, like a negative number. I would hire someone to make a completely new board software with Apache+PHP+PostgreSQL, or maybe I should make one myself and sell it for free.

So just remove OpenAL and Newton and recompile the DLL?

1) is better, because then complete walls can be occluded, and you can also remove walls in the game

I think STL::list is faster than a self-made simple list with pointers. I noticed that when I made one in Fortran, but I haven't speed tested yet how much speed difference there is in C++.

You must use the Framework command SetZoom, and/or possibly upgrade to 2.5 or at least get an updated Framework.

Your cylinder is way too wide for the character. Make the cylinder as narraow as the characters body. To prevent that arms go trough walls, animate them to raise arms when close to a wall, that's how crysis does it also when the weapon is too close to the wall.

It's possible to integrate the lua script runner (engine.exe) and/or lua script compiler (luac.exe) into Code::Blocks, which has multi-color syntax highlighting and auto-completion of brackets.

Curve the fabs to eliminate jagging.

Like Windows Phone apps, everything should be done in multi-threading manner. Sorry for giving Microsoft a credit, but they accidentally do sometimes something right. I actually noticed this with Fastnet yesterday, the whole idea of of WinSock is to drive the whole init+run+term chain into a seperate process. Kinda wierd, but it makes sense, and it requires also less programming, because you just multi-thread the whole program and don't have to take care of any threads or conditions.

Not sure what your problem is Josh, but any map query will always add the element you are asking for, unless you use find. Find will do the lookup without adding any new elements to a map. And no, STL is not stupid, it's made for maximum speed, and you have to take care of all things which are not default. That keeps the speed to it's maximum.

I don't think it can be fixed in LE2, because it uses garbage collection, that is the core reason for all problems with LE2. Slow CPU performance (GPU performance is OK), Windows Desktop disappearing (the classical BlitzMax bug, which some have, some don't (or who don't use their computer much, but still have it)). The sole fact that LE3D is written in C++ will solve a lot of problems, because C++ just works.

LoadModel works only in the main thread, because of the texture 0 size problem. Everything else in LE2 is multi-threading capable, just not LoadModel.

The only reason why multithreading does not work in LE2, is that when loading a model, the texture size is reported as 0 in the threads. This is probably caused by the way how LE2 uses OpenGL.

Random movement occurs when 2 physics bodies are parented, and they are colliding with eachother. The solution is the make the 2 bodies of different collisiontype, for example 6 and 7. And course to make sure that type 6 and 7 are not setup with EntityCollisions to collide with eachother.

It is directly related to Josh's problem with maps, where the compiler cached things in the VS cache file and he needed to clean rebuild to make it work. For example codeblocks and mingw doesn't have such cache file, and it still compiles much faster, and creates faster exes, and the syntax highlighting works also faster and more accurate.

VS is caching a lot of things, because it's slow, so it tries to overcome the slowness with caching, which causes even more problems. Use CodeBlocks and MinGW, and problem is solved, and you also create more cross-platform code, so less time lost on porting to iPhone and Android and Linux. VS is the worst C++ compiler in the world, MinGW is faster by 25%, and Intel C++ is faster by 47%. Just stop using VS and you have a better life, and your customers too. Same with SharePoint btw, totally horrible how slow it is because of C# garbage collection, and how you need to spam a SharePoint server every minute with a wakeup webservice. Apache does not have any of those problems, it just works.

I think one way to test memory leaks, would be to install virtualbox and windows xp on it, and then disable all services. And remove all running processes, including explorer.exe; you can start programs just fine with task manager. I got XP to work fine without any services running, and only 11 processes in task manager. Then you can see much clearer how much memory your app takes.

Of course for those cases you have to do the same. Doesn't really make a difference if it's a class or a function.

STL containers work kinda like BASIC: they make sure the zero element exists, is initialized. That's why they take up initial memory, but it's totally meaningless because you actually want to populate the container, and if not, then don't declare it. Where STL really comes to play is in the speed. Even an ineffective iteration through a vector is faster than an native Fortran linked list. I don't know how they do it, but it's insane fast. Windows cleans up all leaked memory, but it doesn't do it immediately. That's why it's kinda "OK" to not call delete, but just let windows clean the memory up. I mean in the sense that your game reserves the memory what it needs, so there is no harm done to the game itself.