Canardia

Probably something like this would work, but it seems like a good idea to add this to mathlib: void _stdcall EntityCollisionCallback( TEntity entity0, TEntity entity1, byte* position, byte* normal, byte* force, flt speed ) { TVec3 hitforce; hitforce.X=force[0]; hitforce.Y=force[4]; hitforce.Z=force[8]; }

I just had a brilliant idea! Since porting source code seems to be a major handicap, why not make gamelib a DLL too? Then all languages could use it, as making the header file is much easier. It would be just as customizable as it is now in source code form, since all customizations have to be done using callbacks anyway (you don't want to modify the source code, since then you essentially throw yourself out from updates (the same applies for framewerk source code too)).

You can find it on google: http://lmgtfy.com/?q=leadwerks+wiki , or on the leadwerks main page: http://www.leadwerks.com

External libraries have nothing to do with LE, they work in any C++ program. The same way LE is just another external library for C++ as all the other thousands of libraries for C++. The most popular Joystick libraries for C++ are SDL and OIS: SDL: http://www.libsdl.org/download.php OIS: http://sourceforge.net/projects/wgois/files/ I would probably use SDL, since it brings also MMO capable network functions. If I want only a input library for Joysticks and other controllers and don't need anything else from SDL, then I would use OIS, since it's much smaller and not so bloated as SDL.

You could go through the Power Tutorial on the wiki main page.

What's wrong with voting yourself multiple times? You can do that in president votes too!

You need to declare the global variables before the functions which use them, and please use the code tag in the forum when you paste code: int TailGateAngle=0; int TailGateStatus=0; void UdateTailGate(void);

FontHeight()

I agree that it should be possible to remove the physics balls caused by lights, emitters and other entities which really don't need a physics body with LUA. At the moment the only way to remove the physics balls is to use GameLib's processscene, which just recreates the entity and deletes the original entity which was created by LoadScene(). However, that will also remove the LUA script of the entity from memory, and I don't know if it can be reloaded.

You can fix the stuttering by changing line 123 in fpscontroller.lua to: camerapitch=math.max(camerapitch,-89.99)

This is actually a good idea to use always GCSetMode(2) and do the freeing of memory by code. That would probably speed up LE also a lot, and get rid of those random bugs in Editor.

Josh talked about the new engine integrated Framework: http://leadwerks.com/werkspace/index.php?/blog/1/entry-57-merry-christmas/ The engine integrated framework is the only way at the moment to have LUA and C++ code use the same framework instance. This brings some great benefits over the old way how framework works: 1) You can have LUA scripts which access framework commands, and they work also in your C++ program. Earlier the LUA scripts could not access the framework commands of your C++ code, and you couldn't create a 2nd framework instance from LUA either, since it would have caused a big mess. 2) You can port framework to other languages much easier now, as you only need to port the C headers. 3) When framework is modified, you barely need to do anything to update your "other than BlitzMax or C/C++ code". In most cases the modifications and updates are only internal, so the interface doesn't change. In this case you don't need to do anything. In the case that the interface changes, you only need to update the changed interface commands. Although the C/C++ framework source code will still remain, it is not needed at the moment (it will be needed later on when LE is ported to C++ (officially (for console ports), or inofficially (by source owners)). I think that now it will mostly serve as documentation how framework works internally. At the same time framework will get a more object oriented environment also, since LEO needs to access it too. Optimally, game developers would use LEO and Lua, as their syntax is almost identical (and can be made even more identical when Josh makes every Lua command OOP style). I say optimally, because with the combination of LEO and Lua you get the fastest possible code for a game with the biggest 3rd party library support (from LEO), and also the easiest, most interchangable and fastest to code code (from Lua). GameLib 0.0.16.0 will also use the engine integrated framework, so it will bring another boost to C/C++(LEO) game development (and to BlitzMax and to other languages if the community would be more supportive in porting GameLib ). Although if the C++ game development accelerates even more in future, soon anyone not using C++ would be a fool and waste his time, and that's not a bad alternative either. I personally think that the world would be much more advanced if people would stop making new languages all the time (there are over 350), and focus on C++ only.

I'm sure Dexsoft delivers their models in FBX format also, and not only in GMF.

Ambient light can be completely black. Directional light should be a very dark blue. To get more light to the night scene, you should use spotlights for lanterns and flashlights, and a few point lights for in-house ceiling lights and fireplace lights. If the spot and point lights are based on fire, you should add a yellow hue to them. For glow bulbs add a very slight yellow hue, and for energy saving and neon lights use white.

You should make a pivot, which is not rotated, and parent the camera to that pivot. Then you can move the pivot on the plane you want with the WASD keys.

There is no command called CurrentBuffer(), I think you meant BackBuffer(). Then your command should be: SaveBuffer( GetColorBuffer(BackBuffer(),0), (str)strName.c_str(), 99 );

Why would you have a gmf of a model which is not ready yet? You should make the gmf only after you have textured it with xnormal or whatever. But also in the modelling phase you should assign a white dummy texture to the model, so you can test it in the engine while modelling.

Looks quite buggy, the 2 trees in the middle look wierd, since their upper part is sharp, and lower part is blurry. The upper part is against the skybox, and the lower part is against the terrain behind them. Overall it looks rather like some broken DoF effect than antialiasing. The far away trees are clearly blurred by DoF, and also the away facing side of the closest tree on the left.

You can put your pictures on google sites (free 100MB space), and on skydrive (free 25GB space), and just post a link to the gallery. I wouldn't use jpg since it ruins the picture quality so badly.

You can also check that your monitor brightness is calibrated correctly with this web site: http://www.displaycalibration.com

You don't need to do anything, let the physics handle it. You only need a pickup/drop object key, usually this is the F key like in Crysis. You could have a softbody bag (softbodies are planned in LE), and a simple box where you can drop the items. To avoid that other players steal the items from your box, or the box itself, you could dig it in the ground, so that they don't find it. You could also have a lockable cover on the box, which can be opened only with a key you possess (a key is useful, if you want to borrow the key to a friend to pick up some stuff from your box). If you feel that just digging the box into the ground is not safe enough, you can also place some heavy ballast into the box, so that people can't move the box.

There's also a simple power tutorial: http://www.leadwerks.com/wiki/index.php?title=Power_Tutorial (it's also on the wiki main page). GameLib is also on the wiki main page including source code.

You can see in the Tracker that LE 2.28 is still being actively bug fixed, when you look at the "Fixed in" column.

Hard to say, it looks fine on my monitor. There are no completely black places, everything is still clearly visible. It's just more fun to the eye to have a more dramatic dark/light scene than a boring flat image.

With color balance and saturation (both available in Framewerk via ambientlight, hdr, saturation), you could do this (although you should primarily do it in your textures, and rather do a desaturation to get your current image):