Canardia

An animated texture is just a file format how multiple textures are stored. They can be stored in a single file (animated gif), or in multiple files (like the multiple DDS files in LE). When the file is loaded, it's split into seperate images anyway, so it doesn't really matter at all how it was stored on disk (or in a SQLite database, or whatever media).

I just finished Far Cry 2 today, and in the last mission I saw a waterfall. I analyzed it with the sniper scope of my Dragunov rifle, and it looked basically that it was made out of several emitters. There was one emitter at the start which rotated the sprites to make it look like a swirl. Then there was the actual waterfall emitter, which moved sprites downwards at a higher speed, and at the ending there was a elliptic emitter where the water bounced back from the river once. LE has only one-directional emitters, so you would need to code the elliptic emitter yourself. I haven't analyzed yet how the waterfalls in Crysis are done, but I think they use a much better approach, as everything in Far Cry 2 was like trying to copy features of Crysis, but failing in basically everything. I was wondering why Far Cry 2 looks so bad, although it had those Crysis style bright and dark areas, but then I noticed it's all fake. Far Cry 2 has no real lights at all, it's all somekind of hardcoded in-place effects. You could see some objects lighted nicely, but everything around them was dark, so there was no real directional light, but only some "light" which was applied on hardcoded objects. Heck, even a plain cube without texture in LE looks better than Far Cry 2

You don't need regions at all. You should make a game streaming all objects from a SQLite database, based on their distance. Terrain would not work how it works now, but you could just build the terrain from meshes which connect to eachother. Editor should also use SQLite databases instead of sbx files. They are just as easy to edit as text files with the free SQLite client: http://sqlitetool.googlepages.com

Same happens for me when I used sand_05 or sand_07 on a terrain (probably same problem with other sand textures also). It's probably some nVidia driver problem, since I'm sure it has worked earlier.

For a flying camera, you should use a flying physics sphere, as it brings much smoother movement than raw entity movement. You can then also specify with what it should collide.

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