Canardia

fw.main.camera self.model:Point(fw.main.camera,3,0.1,0)

Add CREATENOW parameter to LEO's Framework::Framework() and Engine::Engine(). Expand hybrid fpscontroller2.lua example Also try to split it into universally reusable thingoids [*]Make some cool dungeon with 3DWS [*]Write a short tutorial how to create a distributable game (including built-in C++ RunTime) Include a game launcher and updater in the tutorial [*]Write also a mini game while doing the tutorial [*]Try to get a ragdoll physics character controller working [*]It could be used also for n-pedal monsters Realistic movement is not important in first phase [*]Make physics based 3D emitters They could be used for physics based 3D decals also

Normally you should only use Framework, and not manually setup the buffers and shaders.

You can use the #include command to include the GPLed code. Then you just tell your game dll to call those functions via callbacks. Users can use the GPLed headers freely, they just need to buy LE, or code a similar engine themselves. So they could still use the GPLed code, but the part which does things which the GPLed code does not do, like rendering, is not part of the code. There's also GPL v3, which has some better thought out rules.

You should use transparent windows, and some more ground foliage, since the flat terrain shines too much through. A less stretched ground texture would also look better.

But what if my whole program has no source code? If it's like LE, just calling binaries. How can I release source which does not exist? Also game code will be sourceless soon, when I get gamelib compiled as a DLL. Then the whole game is just a series of parameters in text files, with some occasional high level commands like: LoadGame, StartGame, etc...

Wierd, I thought this is quite clear:

GPL can be used in commercial projects, you just need to publish the source code of the modified parts of the libraries.

You could use Houdini Oceat Toolkit. It's free and open source, and uses also FFTW, which is the fastest FFT library benchmarked. Houdini was used also in Terminator Salvation movie, and some other commercial stuff: http://anusf.anu.edu.au/~drw900/houdini/ocean/docs/ Smirnoff Sea ad uses it also: Smirnoff Sea Video:

You can't upgrade laptops. You could however buy an external GPU docking station for it.

Why do you need a new computer, you can just buy a SM4 capable graphics card for 8€. Look on 2nd hand web sites, like: http://cgi.ebay.com/Nvidia-GeForce-8600-GT-512MB-PCI-E-XFX-Video-Great-deal_W0QQitemZ260543668049QQcategoryZ3762QQcmdZViewItemQQ_trksidZp4340.m263QQ_trkparmsZalgo%3DSIC%26its%3DI%252BC%26itu%3DUCI%252BIA%252BUA%252BFICS%252BUFI%252BDDSIC%26otn%3D10%26ps%3D63

In LE 2.0 you need to use Framewerk, not Framework.

A trigger can be any kind of measurable thing. You could make a "trigger" so that when an entity (for example the player) is close enough to some other entity, then the entity would slowly turn towards the first entity. This would be really simple to code, somehow like (in pseudocode): If(EntityDistance(this,namedentity)<5) PointEntity(this,namedentity,3,0.01) End

From what I understood, the games should be primarily played on the same server, and although it's possible that some players play on a different server, it's not completely optimized for that yet, and would need also higher bandwidths between the servers. At the moment the limit is 1500 miles between client and server. They could solve the problem by launching their own OnLive satellites into space, which allow 100GB/s connections

You don't necessarily even have to have seperate exes for clients and server. A powerful server could render all 64 clients in the same exe. But I guess that would be more work to rewrite the game, than just use a local network, or server to server network, which is anyway super fast.

With OnLive you don't need any networking for the game itself. You can just code the multiplayer features into the game using direct memory access between game clients and game server. Of course you can also use the local network on the same IP, so you don't have to rewrite your networking code, and the network speed is then as fast as SATA3 (6GB/s).

Maybe ModelViewer skips illegal pointers, kinda like this: For local X:Int = 1 to CountChildren( Mesh ) Local Child:TEntity = GetChild( Mesh, X ) If Child Then Print GetEntityKey( Child, "name" ) EndIf Next

There's some challenges to master before you can write games on the PS3: You must release a commercial game on the PC and convince Sony that you are a professional game developer PS3 has it's own graphics API (PSGL 2.0), so Leadwerks Engine would need to be majorly rewritten to use that API (PSGL is similar to OpenGL, but not quite the same) In addition Leadwerks Engine would need to be rewritten in C++, since BlitzMax does not run on its PowerPC CPU and the PS3 OS PS3 GPU is quite low end, even CryTek had problems with it when porting Crysis 2 to it, and they said things would work better on PS4 I think before that happens, there will be some PC console out which can run PC games directly and support hardware upgrades also. There's already the OnLive console out, which is much cheaper than PS3 and XBOX360, and it fits into your pocket, and can run games made with Leadwerks Engine directly.

I think it looks OK, it's just the type of clothing which makes it look a bit rounded and stuffed. But there could be also a looser camouflage clothing, to see how that looks. Also modern AAA games look quite similar, see for example Arma2, and compare loose vs tight clothes:

BUG: When I choose VS2008 console+gamelib, it adds all kinds of cpp files, but it must add only gamelib.cpp.

There might be a difference when you export it after you first opened 3DS Max, and when you export it a 2nd time while 3DS Max is still open (some internal variables being set differently). You could try if it works always when you close 3DS Max, open 3DSMax, then export it, and close 3DS Max again.

I don't think CPU based waves is bad at all. Especially when using C++ they should be super fast. The benefit of using CPU based waves is that you can deform the water in realtime when a boat moves, and also create waves caused by the boat.

If it works with the same mesh all the time, and it never works with a mesh with never works, then it's probably not a bug in the engine, but in the way how you export or in the modelling program you use.

Yes, and realistic physics kinda writes the game logic for you. All you have to do is to setup meaningful physics objects, and the game is ready.

The new Lua tutorials are a bit different from Power Tutorial. Lua alone can't maximize the optimization, but only the engine can. However, I'm thinking how to use Lua to it's maximum extend without causing negative effects in the game regarding memory consumption and performance. It's also planned to have SQLite integration and networking, and blowfish encryption for SQLite records, A* pathfinding (only C++ is fast enough for that), force feedback joystick support, etc... Which means, you can do a game fully with Lua, but the most optimal situation is achieved when using C++ and Lua in perfect combination.