Canardia

The dynamic shadow system would be the main reason to use LE for a 3D OS, but it really needs to be made in C++ first. Of course the realtime Lua would work nicely as a OS scripting language too.

I'm actually more worried that there will be soon a OpenGL 3.2 engine out, and I think I would seriously consider it since it runs even on my 3 years old GeForce 8800 GTS. I just want a game and engine which utilizes my hardware fully. I paid big money years ago for my graphics card, and even today maybe only 80% of its hardware features are used

They tested OpenGL vs DirectX performance under Windows 7 64-bit, which is known to run OpenGL apps 15% slower than on XP 32-bit. Run the same test under XP, and OpenGL will be faster.

An OS is just an application like any other. Some games have even an OS built-in. "In computing, an operating system (OS) is an interface between hardware and user, which is responsible for the management and coordination of activities and the sharing of the resources of a computer, that acts as a host for computing applications run on the machine." http://en.wikipedia.org/wiki/Operating_system I've actually started years ago to make such an 3D OS which runs under Windows (doesn't need explorer.exe though). But for the final version I would need it to run under Linux and Mac also, so it would bring the same GUI for all 3 OS.

Actually it's just the opposite. The Ogre3D demos run much faster in OpenGL mode than in DirectX mode I see in the long run that both won't exist anymore, so I'd rather start preparing for PS6 (which was already announced last year) and Linux.

DirectX was made because Windows 95 didn't allow direct memory access, which DOS did. Windows NT had OpenGL: http://en.wikipedia.org/wiki/DirectX#History OpenGL allows Windows to have direct memory access to the GPU, which DirectX still doesn't do today. So you could say Windows 95 and DirectX was just an emergency hack (because Windows NT had problems running DOS programs) which should have never have existed, since they already had OpenGL working on WinNT. It took them indeed until Windows XP before they had finally managed to run DOS programs under Windows NT, but the damage was already done. John Carmack asked in an open letter to Bill Gates to stop developing DirectX, but Bill didn't understand this, and kept doing the wrong things.

I think it's kinda logical. If I say I'm gonna buy a Mercedes, I don't even think of any older model. Or If I say I'm gonna buy a bottle of milk...

You can run OpenGL on XBOX 360 also, since you can run Linux on it (just need to remove the firmware protection (which is software protection only), or install an older firmware which still allowed to run Linux ).

It shouldn't be bigger than 1x1x1 meters, because then it fits perfectly around the camera (which is infinitely small, as it's a point). If you make it bigger, let's say 200x200x200 meters, then it still looks the same, but the FPS goes down.

DirectX means (or should mean, since it does so with OpenGL also!) the latest version of DirectX, and there are almost no users who can run DirectX 11 games (only some ATI users with Win 7). nVidia has no DirectX 11 cards, and won't have in the next few years either (I think GTX 350 will be the first DirectX 11 card from nVidia). All nVidia and ATI users with any Windows version can run OpenGL 3.1 or 3.2, which is partially better than DirectX 11.

The RenderFramework() command is only used for the main rendering, you can use many mini-renders with your own RenderWorld() and RenderLights() commands (mirrors, dynamic cubemaps, maps, etc...).

It's not a driver bug, but there is no DirectX engine on the market which is completely dynamic like LE, and uses GPU for almost everything. CryENGINE 3 might be the closest match. You can do many settings to make it faster on low-end graphics cards. Some examples: 1) Use static lights 2) Use smaller window resolution (big FPS boost!) 3) Use smaller shadowmaps 4) Use smaller camera range 5) Use spotlights instead of pointlights where possible (6 times less render passes) 6) Disable post-processing effects 7) Use inaccurate physics mode 8) Always use Flip(0) and set vsync=force off in nvidia control panel 9) Enable more optimizations in VC++ (favor speed, SSE2, 4 byte alignment, etc...) 10) Remove all inline statements from C++ code (can make big FPS improvement, since compiler knows better when to use inline and when not!) 11) Always use double type for floating point numbers (up to 5 times faster than float type) 12) Always use bool type instead of int type (up to 2 times faster) 13) Use rivatuner to raise the clock speed of your ati/nvidia GPU (it might explode, so use at your own risk, and watch the temperature!) 14) Install Windows XP SP3 32-bit, it's the fastest Windows for OpenGL games (25% faster than Vista, 15% faster than Win7) 15) Install the latest graphics drivers (new nvidia drivers have 85% speed increase for some games) 16) Use LOD models and make the LOD range smaller (50 meters at least) 17) Use same model as often you can, instead of different models (more GPU instancing) 18) Disable unneeded services and processes in Windows XP (18 processes is enough that everything works) 19) Send me money so I have more motivation to write full C++ version of LE which works on Linux (Linux GNU C++ is 2.5 times faster than VC++, VC++ is 2.5 times faster than BlitzMax) 20) Disable vegetation and terrain shadows 21) Use billboards for vegetation 22) Disable unneeded water reflection render components 23) Design your levels smart! Make sure in heavy density areas some walls always occlude the camera view, also use zig zag corridors ( _|¨ ) to seperate big areas from eachothers 24) Use the hierarchical entity group occlusion system 25) Disable two sided meshes in mat file (cullface=1, it's the default setting when not specified)

DirectX has actually more bugs than the OpenGL drivers. It used to the the other way around, but since now most developers use OpenGL, they have pushed the development a lot. Even Blitz3D which uses DX7, doesn't work on Windows 7 64-bit anymore, with OpenGL it would still work. DirectX 10+ doesn't work on XP, which most people still have. I don't think Microsoft will ever release a good OS again, since the development has been going in the wrong direction since Bill Gates left, so it only can get worse. My next OS when XP doesn't work anymore will be probably Debian. Until then, I have good time to make a native Linux version of LE. DX also doesn't work on Mac, Linux, consoles, phones, pads, and any other platforms. OpenGL does.

Yes, the constants defined in scripts/constants/engine_const.lua are the same ENGINE_xxx constants as used in other languages.

Did you enter the registration key?

You can choose which elements to render: http://www.leadwerks.com/wiki/index.php?title=Worlds#RenderWorld

I think it should be LODDistance="60.0,120.0", because in LE 2.3 sbx format all value seperators have changed from space to comma also since LE 2.28.

It's quite annoying when the camera moves just because a little toe is hiding behind a little stone on the ground (one ray can not see 1 corner). I'm much happier when the camera doesn't move closer when I still can see 1cm of the top of my head, because then I know the rest of the body is also there, no need to show it. Only when I can't see anything of the player body, then I lose orientation and need to move the camera closer until I can see at least something of the player.

Physics body can get stuck in the environment (unless you have some pathfinding for it), so I guess 4 entitypicks is better. I would however move the camera closer only when all picks can't see the player, and not when only 1 can not see. The EntityVisible command also checks for the center pivot of the model only, which is kinda useless. It would be more useful if there was a parameter to say: 0=center visible, 1=completely visible, 2=partially visible. Then you could use option 2 for 3rd person camera checks.

You can also use a sphere as skybox. Just disable the Framework skybox and put your own inside out sphere in the background world. It doesn't even need a shader.

PositionEntity( camera, EntityPosition(camerapivot) ); RotateEntity( camera, EntityRotation(camerapivot) ); MoveEntity( camera, Vec3(0,0,cameraZoffset) ); To move 3rd person camera closer and further, just change the value of cameraZoffset.

When using gamelib, make sure you don't have engine.cpp or leo.cpp added to the project, since gamelib will add them automatically.

I think you could place a physics cloak over the player, so when the player moves, it will move with him, and when applying force the the cloak, it will move the player too. The cloak could look like a flat cylinder on top of the controller, and few flat cubes hanging on all sides of the player. The cloak parts are connected with fixed joints, but the whole cloak is not connected to the player controller, it's just laying on on him.

LEO is more based on C++ than C. I normally just do pivot.SetPosition( player.GetPosition() );

Rendering densily populated areas with minimal FPS loss is one of the biggest strengths of Leadwerks Engine. It provides many methods for occlusion culling, here's some what comes to my mind, although I'm not sure if they are technically correct terms: 1) Entity Groups, which map together multiple entities for hierarchical occlusion culling 2) Per-Entity occlusion culling 3) Visibility occlusion culling (when camera is not seeing them) 4) OpenGL hardware occlusion culling (for meshes hidden behind other meshes, and backfaces facing away from camera) 5) Per-Entity instance LOD models and LOD range settings 6) Camera range based occlusion culling