Canardia

Total NDA, I can only tell that it's better than anything you've seen before. Josh said that too in his blog: it's something no game engine has done before.

I think the Beast rendering looks cheap and clumsy. I've seen pictures from LE 2.4 and it's much better

I'm not completely skipping updating, but only one update per frame, which is how games are written also, so these should be relevant speed tests. Many games have thousands of objects, which need to be moved, rotated, etc... so a 16ms delay which equals a 60FPS loss is quite remarkable, especially if you can avoid one 16ms loss by knowing which commands can do the same thing faster.

BlitzMax code gives the same results also: SuperStrict Framework leadwerks.engine Graphics 800,600 registerAbstractPath "c:/program files/leadwerks engine sdk" If Not CreateWorld() RuntimeError "Failed to create world." Local cam:TMesh=CreateCube() Local start:Int = 0 Local stop:Int = 9999 Local t1:Long Local t2:Long Local tt:Long Local ttt:Double Local tti:Long=0 Local ttx:Double While Not KeyHit(KEY_ESCAPE) t1 = MilliSecs() For Local i:Int = start To stop PositionEntity(cam, Vec3(1, 1, 1)) Next t2 = MilliSecs() Local tt:Float = t2 - t1 tti:+1 ttt:+tt ttx=ttt/tti Print "tt=" + tt + ", ttx=" + ttx UpdateWorld(); RenderWorld(); Flip(0); Wend

You shouldn't run UpdateWorld and RenderWorld in the loop, as I only measured the speed of the commands, not the update/render time. And you shouldn't use BlitzMax, because it lacks the DLL interface which was supposed to be measured. Here's my code: #include "engine.h" #include "Application.h" TEntity e; TVec3 v; TVec4 v4; TVec16 v16; void test1(void) { //1 char s[16384]=""; //1 SetEntityUserData(e,(BP)s); //2 TBuffer b=BackBuffer(); for(int i=0;i<10000;i++) { MoveEntity(e,v); //PositionEntity(e,v); //FreeEntity(e); } } int main() { double t1,t2,tt; Application app; app.Create(); RegisterAbstractPath("c:/program files/leadwerks engine sdk"); Graphics(640,480); CreateFramework(); v=Vec3(0,0,0); v4=Vec4(1,1,1,1); v16=Vec16(); e=CreateCube(); int tti=0; double ttt=0; double ttx; while(!KeyHit()) { t1=clock(); test1(); t2=clock(); tti++; tt=(t2-t1)/CLOCKS_PER_SEC; ttt+=tt; ttx=ttt/tti; printf("tt=%f, ttx=%f\n",tt,ttx); app.Run(); } app.Free(); }

They are, I reran the test over even longer time, and it settled more accurately at: Move:14ms, Position:17.5ms Once the total average time starts to pump few nanoseconds up and down, I know that the initial double time (when starting up the engine and loading shaders) has been eliminated in the total timing.

I wonder how a single softbody would work as water. For diving underwater you would just disable the collision.

They are probably good for physics audio. So when a body collides or sweeps over another body, the material callback would determine which sound to play. For example metal against wood, metal against sand, wood against glass, wood against rock, etc... Every game has that.

10000 times: GraphicsWidth : 0.06ms GraphicsHeight : 0.06ms BackBuffer : 0.08ms ShowEntity : 0.1ms HideEntity : 0.1ms EntityHidden : 0.1ms EntityPosition : 0.1ms GetEntityUserData : 0.1ms BufferWidth : 0.16ms BufferHeight : 0.16ms EntityColor : 0.2ms GetEntityMatrix : 0.2ms SetEntityUserData : 0.4ms EntityRotation : 0.7ms SetEntityKey : 2ms GetEntityKey : 3ms TranslateEntity : 13ms FreeEntity : 14ms ScaleEntity : 14ms MoveEntity : 14ms PositionEntity : 17.5ms CreatePivot : 21ms CopyEntity : 22ms RotateEntity : 22ms SetEntityMatrix : 22ms EntityVisible : 22ms EntityPick : 24ms TurnEntity : 28ms PointEntity : 28ms CreateEmitter : 46ms 16ms means a loss of 60FPS. It seems you should not use TurnEntity, but either use EntityRotation+RotateEntity, or keep your own variable of the entity's rotation and use RotateEntity only. Also GetEntityMatrix/SetEntityMatrix is a lot faster than their separate commands (Position/Rotation/Scale/Quaternion), but that was already known, or at least expected.

Generally in OOP, the method name should always start with a verb, followed by the object. Get/Set are good where things are really getted and setted, those are usually values. Other good verbs are Turn, Rotate, Flip, Render, Update, Scale, Load, Save, etc... The only exception to using verb as first word are prepositions, which are used to get boolean values, like Is, Has, Can, May, etc...

With leo you still need engine.cpp.

But 3DWS already supports DDS.

DLLs can be linked implicit or explicit, and LE is using explicit linking. So you need to use the engine.h and engine.cpp file and use the Initialize() command to load the DLL.

Nobody is, since nobody has the guts to try something new and possibly better. Only id software has, and they will once again show the world what to do. And then there are still people who don't listen to John Carmack. http://www.pcper.com/article.php?aid=532

Half or more of those features are obsolete and automatically present when using a Voxel engine.

8192x8192 takes already 256MB of VRAM, 16384x16384 takes 1GB. And since LE needs mipmaps, they take about twice as much.

Maximum shadowmap size is the same as maximum texture size, and you can get it this way: http://www.opengl.org/resources/faq/technical/texture.htm#text0120

Collision detection is quite sophisticated, because it uses the physics engine for all collisions, even static ones. Static collisions take basically no FPS away (I've tried with a test scene with 10000 cubes).It has also 3D sound, which is quite important in full 3D simulations too. The only thing which I am missing from the 3D sound system is raytracing and occlusion of sounds. So far 3D engines do that for graphics only, but I could actually do that myself in LE also, for example if a sound is not visible to the camera, it would dampen it. And using A* pathfinding I could check how a sound would reflect over a corner in a corridor.

For some users DirectX might be faster than OpenGL, but that means they have something wrong in their configuration: no Windows XP, no nVidia card, badly written engine.

Actually you can do much more in OpenGL than in DirectX, because for the newest DirectX you need a DX11 capable card and OS, and for OpenGL you just need a SM3.0 capable card to do the same things and much more. The code in OpenGL is also much shorter than in DirectX, which brings a speed benefit in rendering and programming. The current DirectX doesn't even run under Windows (Windows NT, 2000, 2003, CE, XP), but only under special versions of Windows (Vista, 7), but OpenGL runs on all Windows versions while bringing the same and more features as DX11 has.

Generally speaking Leadwerks Engine is a very good choice for DIY people, because it doesn't restrict you in anything or force you to do things in the engine's way. And even when you do everything your way, it still makes it very easy and allows to mix your own ways with the engine's ways. 1) From blender you can export as FBX and don't need any other tools then, since there is FBX2GMF.exe converter in the engine. 3) You can mix OpenGL code with Leadwerks. 4) We have seen a demo with 200 animated zombies, and the FPS was still very high. So I guess there can be around 1000 or more animated characters at once on the screen (and much more out of sight).

You must use the 3dw2gmf.exe tool from the SDK. In the Power Tutorial I wrote a little helper tool also which makes it drag and drop action: http://www.leadwerks.com/wiki/index.php?title=Power_Tutorial#6.29_Making_models

I can write the storyline to the game: Supernatural Squid approaches girl. Girl tries to lift the massive sword, but it's too heavy for her to even move it an inch. Squid eats the girl as a snack. Game Over.

How do you prevent that the rain goes through objects with particles and shaders?

EntityDistance(centerpivot,player)