Canardia

You can use the Curve() function of LE to smoothly interpolate to a certain coordinate, or you can parent the camera to a physics sphere and move the sphere with force commands.

http://en.wikipedia.org/wiki/Wheat_and_chessboard_problem#Origin_of_the_problem

Soon you should start charging for the next 64 models: 1 cent for the first, 2 cents for the second, 4 cents for the third, ...

LOL @ TrueBones: It has also a "ObamaBones Motions" pack

Can't you just do EntityColor()

Here's the LEO version to set the global fw variable in LUA (LuaTools is not part of LEO, but it inherits LEO's Lua class, so you have to copy this code to your program): class LuaTools : public Lua { public: int GetStackSize() { return GetTop(); } void SetStackSize( int size ) { int currentsize = GetStackSize(); if( size<currentsize ) Pop( currentsize-size ); } void SetScriptObject( const std::string& name, BP o ) { int size = GetStackSize(); PushObject( o ); SetGlobal( name ); SetStackSize( size ); } }; Then you can load a whole scene without any need for processcene (water, skybox, lights, everything works): #include "leo.h" using namespace LEO; int main() { Engine engine; Framework fw; engine.Create("Integrated Framework Demo",640,480); fw.Create(); LuaTools luat; luat.Create(); luat.SetScriptObject("fw",fw); fw.SetStats(2); Scene scene; scene.Load("abstract::main.sbx"); fw.main.GetCamera().Move(-10,140,30); fw.main.GetCamera().Turn(0,180,0); while( !Keyboard::I****() && !engine.IsTerminated() ) { fw.Update(); fw.Render(); engine.Flip(0); } fw.Free(); return engine.Free(); }

No, there are more. And as I wrote before, the source is usually not used to modify the engine, but used rather as a business backup.

Obviously there is a source license, as I am writing this. There is also a team/studio/school/etc... license, all is handled and judged on individual cases, just write to support at leadwerks dot com to get the best license you need for your business.

Swearing is not allowed on these forums.

LE should use an physics abstraction layer, which allows people to write their own implementation of physx, havoc, ode, bullet, etc.... Newton should be a default example.

Use Editor, it's like making 90% of the game. However, Editor is not fully equipped with all game related entity scripts yet (me and Rick are working on those). In Editor, you place all the models, lights, effects, etc... You can then press Ctrl-G to run the default game script (fpscontroller.lua), and that same script can be used also for the final game; although the game might need also a bit more kick (speak: SQLite database, PS3 6-axis controller, etc...) so it could be run from a C++ app. That however, doesn't change or replace anything what you do in Editor.

Well, you can use C++ code in BlitzMax, but that's not the point here now. BlitzMax should have a similar method to construct a foreign type from pointers, like in the C++ example I showed. Indeed, Josh started to use those wierd [] operators for float arrays some time ago, so instead of saying Vec3(1,2,3) he says [1,2,3]. So I think the Byte Ptr problem could be easily solved using the fact that Vec3 is just an array of 3 subsequent float (4 byte) values.

It could be a 3DSMax problem, if the models are made with 3DSMax. When you modify anything in 3DSMax, all faces are randomly flipped. 3DSMax has a "bug fix" tool which then flips all faces outside again.

Ugh, you should use framework in first place. It's horrible to read code which uses custom buffers and renderlights and stuff

No, a SQL database handles queries to lookup only the records which are close enough by its XYZ coordinates (the SQL engine needs to support exclusive greater/smaller than queries which perform like indexes), so you don't need to loop through all records. You don't also need to check the entities in each frame, but only every 10th-30th frame. You can see that kind of behaviour in MMORPGs like AO, but also in Crysis where objects are first loaded and painted with an average texture color, and then textured later on.

I posted a standalone version of fpscontroller.lua long time ago: http://leadwerks.com/werkspace/index.php?/topic/73-run-sbx-scene-outside-the-editor/page__view__findpost__p__659

Basically not bad, but it can be improved with very little effort: place the swirl emitter at the beginning (like in Far Cry 2) to avoid those popping up of new sprites at the top, and make the falling emitters longer sprites, not so round (or maybe it can be done with the existing sprite, if you make the falling stream not so broad).

Yeah, that's how Lua entities should work. I think at some point there needs to be some standardization how plug-in Lua scripts should work, and what global named objects or other entities they are looking for. One standardization there is already: fw=GetGlobalObject("framewerk"), although it might be renamed into framework soon (due to general definitions of the term "framework", and naming conventions in LE).

2D sprite emitters have a lot of problems anyway, I must really implement 3D mesh emitters with physics into GameLib.

Sounds similar like GameLib. I'm planning also to make certain functions work with Lua scripts, but leave the C++ version still there as an option. If you make your scripts public, I guess they can be copied to a community project like GameLib, which is also free for all LE users?

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.