Canardia

If you have a webcam or wii controller, you can do headtracking, which creates a real 3D look without the need for glasses: And of course you might want to use your living room's wall as a multitouch screen also, then you don't need to buy a 300 inch LED screen, but only a wii controller: Maybe LE3 could have those features built-in, so we could call it a 5D engine 5D because 4D would be just 3D and motion, which it already has, and 5D would add the extra dimension which is outside of the computer world.

You have to pay over $50000 for each game your make with Havok, if your game costs more than $10. The page doesn't say it directly, but since you can download only Windows version of Havok, and only the commercial license gives you the Linux and Mac versions, you need to buy the commercial version of Havok anyway: http://www.havok.com/index.php?page=pro The same applies for PhysX also: if you make a game which runs also on Linux and Mac, you have to pay over $50000 for each game.

There is hardly any support for C# and .NET if you compare it with C++ and the millions of standard libraries for C++ you can get for all platforms from the internet for free. No language will ever beat that.

It's just the phase in everyone's game development. When you start making a game with LE, you'll notice you need to do some things yourself, first the level save/load (which kinda conflicts with SBX scenes), then the networking (then you don't necessarity need load/save, unless your game is like diablo 2 which is a hybrid single/multiplayer game).

You can do hidden banning, so you check if someone's client is behaving regularly unexpected, and then you make his character die more often in battles or let his weapon miss more often. Some game, I think BatMan Forever had this kind of hidden banning, where it detected that it was not the original game, so it caused some wierd behaviour ingame. And when people asked why this happens, the moderator just said: "It's because you are using a pirated version."

It's only the name of the function, which calculates the force needed to get the velocity needed to reach the position wanted.

It doesn't have a hard limit of 64, but the developer said it can't handle more. When we tried that with Josh's multiplayer game we also saw that the lag increased with more players, and it looked also like it would cap at 64.

There's still way too much overhead in the TCP protocol, that a few additional checks with UDP are still much faster. You can also include a checksum in each UDP packet, but I think it might be already done automatically also.

No, I had a typo, it was meant to be CalcBodyVelocity, which interpolates a physics body to a given position.

Interpolation is very easy in LE, you just do AddBodyForce( clientbody, CalcBodyVelocity( EntityPosition(serverbody) ) ). That way you don't have to care about latency either, since you can send every 1000ms or even every 5000ms only one message, and even if the message is delayed by 60000ms (one minute), it would still work and have no jittering. For non-physics model movements you would interpolate using PositionEntity( clientmesh, Curve( oldpos, newpos ) ). If the server does physics, it would have also its own benefits: 1) You could use a super fast 64-bit server with Linux (Debian of course) and a super fast physics engine which doesn't need to be deterministic. 2) Clients would run faster, since they don't have to calculate physics at all.

Packets need to be numbered sequentially, and if the client doesn't get the next packet, he needs to ask again for it. The UDP engine using SDL_net handles lost packets and makes sure the packets are in right order, so that happens automatically.

Networked physics means that each client runs the physic simulation exactly the same way, and the server only sends short symbols or force vectors to the clients. If the server does all physics, then you can do it with any physics engine, as you have to submit the whole entitymatrix of each entity to the clients.

Sure it is OK, I would be also interested how fast Newton would be with a pure C++ interface. Also remember to disable RTTI in VS, since it's always enabled by default since VS2008. It's only needed for a couple of special virtual class functions, which are basically used for debugging only. Actually I don't think they have fully stopped then yet, because it can take a long time before Bullet fully stops.That's partially because I didn't adjust the friction of the boxes, so they keep sliding very slowly if they are a bit slant on top of other boxes. When all boxes have stopped, the FPS goes back to what Newton has too when all are stopped.

I think the reason why the Bullet box stack blows up from the bottom is that it starts with a compression wave from the above boxes. I've noticed that Bullet bodies sometimes penetrate other bodies, and then jump back where they are allowed to be. This might be some setting in Bullet too. But the biggest problem with Bullet and PhysX is still the determinism, however it has been fixed in Bullet in several places, while in PhysX there is no intention to be deterministic at all. Like I said earlier, Bullet will be a great physics engine if they keep fixing it, but at the moment Newton is the only usable physics engine for networked physics.

I think it's a bug in the Lua interface, since it works fast in C++.

You don't need to use SetFont() in each frame, do it only once before the main loop (or once when switching the font inside the main loop).

Newton might be the only deterministic physics engine though, which is very important when making networked physics. I'm trying to get Bullet also deterministic by removing all rnd() calls. The coming to rest time can be configured in Bullet, and it has also less friction by default so things slide longer. Bullet.lib is the LE integration of Bullet. While Bullet itself is free, there is a lot of LE related code in Bullet.lib which is not part of Bullet. As it's using ZLib, I can modify also the bullet source code without needing to publish it. But I would probably publish my Bullet changes, to make Bullet a better product, while the source code of Bullet.lib for LE is strictly my business secret

It's quite easy to integrate Bullet into LE, and it works without modifying the source too. I will publish Bullet.lib soon, of which the basic version is free, but maybe a commercial version will have more features. Depends how many people are interested in it. Bullet has also concave bodies, which I missed in Newton always. The vehicles work also fine, as well the character controller. It has also cloth simulation. #include "engine.h" #include "Bullet.h" int main() { if(!Initialize())return 1; Bullet bt; vector<TModel> newtonmodel; bt.CreateGround(); SetAppTitle("LE 2.4: Newton vs Bullet"); Graphics(800,600); CreateFramework(); TMesh groundmesh=CreateCube(); MoveEntity(groundmesh,Vec3(0,-3.5,0)); ScaleMesh(groundmesh,Vec3(1000,1,1000)); EntityColor(groundmesh,Vec4(0.5,1,0.5,1)); PaintEntity(groundmesh,LoadMaterial("abstract::terrain_forest_grass.mat")); TBody newtonground=CreateBodyBox(1000,1,1000); MoveEntity(newtonground,Vec3(0,-3.5,0)); EntityType(newtonground,1); Collisions(1,1,1); TCamera cam=GetLayerCamera(GetFrameworkLayer(0)); MoveEntity(cam,Vec3(1,0,-20)); // create environment TLight sun = CreateDirectionalLight(); TurnEntity(sun,Vec3(25,82,75)); AmbientLight(Vec3(0.025,0.025,0.050)); SetFarDOF(1); SetFarDOFRange(20,80); SetShadowmapSize(sun,3072); SetShadowSoftness(sun,0.1); SetSSAO(1); AFilter(MaxAFilter()); TFilter(1); SetBloom(1); int newtonboxes=0; int bulletboxes=0; // run main loop while(!KeyHit()) { if(KeyHit(KEY_1)) { // create newton boxes TBody newtonbody=CreateBodyBox(); TMesh newtonmesh=LoadMesh("abstract::bamboocrate.gmf",newtonbody); for(int y=0;y<20;y++) for(int z=0;z<5;z++) for(int x=0;x<5;x++) { TModel model=CopyEntity(newtonbody); PositionEntity(model,Vec3(x,-2.5+y,z)); SetBodyMass(model,1); EntityType(model,1); newtonboxes++; newtonmodel.push_back(model); } FreeEntity(newtonbody); } if(KeyHit(KEY_2)) { // create bullet boxes TMesh bulletmesh=LoadMesh("abstract::bamboocrate.gmf"); for(int y=0;y<20;y++) for(int z=0;z<5;z++) for(int x=0;x<5;x++) { bt.AddBox(x,-2.5+y,z,CopyEntity(bulletmesh)); bulletboxes++; } FreeEntity(bulletmesh); } if(KeyHit(KEY_SPACE)) { bt.Erase(); bulletboxes=0; vector<TModel>::iterator newtonmodel_iter; for(newtonmodel_iter=newtonmodel.begin();newtonmodel_iter!=newtonmodel.end();newtonmodel_iter++) { FreeEntity((*newtonmodel_iter)); } newtonmodel.clear(); newtonboxes=0; } bt.Update(); UpdateFramework(); RenderFramework(); DrawText(1,20,"1: newton 2: bullet space: clear"); DrawText(1,35,"newtonboxes=%d",newtonboxes); DrawText(1,50,"bulletboxes=%d",bulletboxes); Flip(0); } return Terminate(); }

At least SDL graphics works with LE, when you make a CustomBuffer in LE, so Qyoto/Qt should work too.

Qyoto is a .NET based Qt wrapper for C#: http://techbase.kde.org/Development/Languages/Qyoto

LE is the best, and if you don't want to pay for it, you will burn in hell. Churches also charge a lot of money to get people in heaven, so why should LE not? With LE you will get in heaven AND you make money from your games, it's the ultimate win/win deal.

Bullet is nice, but still a bit slow. I think it will get faster when it develops more, and it's being developed quite often. PhysX is quite fast, but Havok is faster. PhysX is again faster than Havok with GPU Physics. PhysX has a nice cloth simulation and concave bodies. Havok has also concave bodies which work very well, but Havok Cloth is a seperate product which I don't like, because it's like the Torque style of marketing. Havok has the best fluid and massive amount simulation though. PhysX is also not bad even without GPU support, but I heard the code has all SSE2 commands disabled deliberately, so it could be much better if they would fix that. The speed of Newton is a joke compared to all other physics engines (about 4 times slower than Bullet, about 8 times slower than PhysX), and it's not even accurate since it often keeps bodies standing on one edge. Overall, I tend to prefer Havok at the moment, but maybe in future Bullet will be the best.

See the example in Wiki about CreateCustomBuffer.

With LE 2.4 you need to remove the attenuation variable from the last line in PointLight.frag to get an arealight.

I open a SDL window, and then somehow hook the LE window to use it. It's part of bigger game projects, but I could make a simple demo sometime.