Canardia

1.) www.leadwerks.com 2.) There is a ocean shader in the works for LE3. The current lake water has also boyancy and waves, so it will be in the ocean water also.

LE needs mipmaps in the DDS file, else it will appear black.

A profit of 3 million Euro for that game is a major failure. I think it was not meant to make much money at all, but it did. Others who invest a lot of money and want to make games which make profit fail also, as they get much less profit. What did we learn from it? Maybe that you can't predict or control the popularity of a game, so just make a game which is fun to play and forget about everything else

Yes, that's a lot slower.

I would look in the Wiki for some command which changes texture UV coordinates, and then use that in the script.

LoadModel("cube.gmf"); repeat... and cube=CreateCube(); cube2=CopyEnitity(cube); repeat CopyEntity()... are identical. Which means, you should always instance models when they are identical, it brings a huge speed boost.

I hope someone will write a procedural C++ interface for LE3, since that starts to look just like Ogre3D to me

Yeah, the real 3D environment makes playing very fun.

Tesselation is supported only by SM5 cards (DX11/OpenGL 4), so only very few people can use it. You will still need to do your normal maps if you want more than 5% of the people to buy your game. Maybe in 6 years time it makes more sense. http://www.geeks3d.com/20100819/gpu-tool-tessmark-0-2-2-new-opengl-4-tessellation-benchmark/

I think there are many reasons why the graphics are like that: 1) Easy to create content by programmers anyone 2) Easy to make things dynamic and destroyable (since everything is a cube) 3) Having fun with the pseudo tile/8-bit cubic feeling, it's more neutral than specific shapes when the assets are very low poly 4) Cubic graphics can take advantage of voxel advantages too (since they are cubes too), you can make everything 3D and solid (not just surface polygons which are hollow inside) I like the graphics of minecraft, it gives a nice abstract feeling which satisfies the programmer's mind, since everything is uniformly organized, and you can make many many new cubes which represent some other stuff, like rocks, gold, snow, ice, etc.... We are basically talking about a balance between what the player accepts and how easy it is for the programmers to create things. And I think in minecraft this ratio is very good. If you compare it to a conventional polygon game, the artists have to do a lot of work to get things accepted by the players, since there comes the "trying too hard to fake an AAA game, while your resources don't allow it" effect in effect.

Unless you use octrees for searching which cubes are visible, then it's faster than drawing them.

I agree 100%. Freedom and to be able to make anything you want is the easiest and most powerful game engine.

Mesh::Load() is for the OOP interface, LoadMesh() is for the procedural interface. You make the procedural interface by using the OOP interface internally, just like you did in LE2 with BlitzMax.

.X files are imported as entities from the right side panel in 3DWS.

try/catch is not really meant for actual programming, but only for theoretical programming and teaching purposes. You should rather use checking of NULL pointers in your code, or use references.

You can make a FitMesh function quite easily: First check the current bounding box size, and then calculate a factor between your wanted bounding box and the current bounding box and scale the entity with that factor.

And I'm the evil Sith Lord of C++

Oh, you mean probably extreme OOP, with .Get/.Set style methods, like in C#: // Define objects Graphics graphics; World world; Mesh box; Camera camera; // Create graphics window graphics.Driver.Set( OpenGLGraphicsDriver() ); graphics.Create(1024,768,4); world.Create(); // Create a box; box.Create(1,1,1); box.Material.Shader.Load("Shaders/minimal.shader"); box.Material.Color.Set(1,0,0,1); camera.Create(); camera.Color.SetClear( Vec4(0,1,0,1) ); box.Position.Set(0,0,-2,false); float yaw = 0.0; while (!window.Closed()) { yaw++; box.Rotation.Set(yaw,0,0,false); camera.Render(); window.Flip(); }

I would do it like this: // Define objects Graphics graphics; World world; Shader shader; Material mat; Mesh box; Camera camera; // Create graphics window graphics.SetDriver( OpenGLGraphicsDriver() ); graphics.Create(1024,768,4); world.Create(); // Load a shader shader.Load("Shaders/minimal.shader"); // Create a material; mat.Create(); mat.SetShader(shader); mat.SetColor(1,0,0,1); // Create a box; box.Create(1,1,1); box.SetMaterial(mat); camera.Create(); camera.SetClearColor( Vec4(0,1,0,1) ); box.SetPosition(0,0,-2,false); float yaw = 0.0; while (!window.Closed()) { yaw++; box.SetRotation(yaw,0,0,false); camera.Render(); window.Flip(); }

Yeah, never judge someone who is marked by experience. He may not be benevolent to your current fashion, but in the end he will show you the right way.

I'm working on a vehicle game also, and I noticed you can have quite difference car behaviours when adjusting the wheel radius and the front/rear wheel distance. Now I got a car which gets totally instable at higher speed because its front/read wheels are quite narrow together. With a car with bigger front/rear wheel distance, it behaves very stable. One annoying thing is that the car stops when making a sharp turn, but I think I can simulate a roll-over and explosion when the steering angle gets too high.

Most, if not all C++ libraries use their own namespaces and constants. So you could say: #define LE_NULL NullEntity() and then use: TFormPoint( 1, 2, 3, LE_NULL, entity ); You shouldn't worry about C++ features at all, since you need to make a procedural C++ DLL for other languages anyway, just like you needed to with BlitzMax. The BlitzMax DLL had no BlitzMax features either.

I wouldn't make things more complicated than they really are. If the user deletes a texture of a material, he should do it from a method of the Material class, which should set the Texture pointer to NULL. Then the Material class can properly check for NULL textures. When the user destroys a texture which is used by other materials also, they should not stay visible! It would be like, WTF I just deleted the texture from the computer's memory, why is that material on that mesh still showing it, do I have to loop through the whole computer's memory to delete all copies? Why can't the engine do it automatically, since I definitely wanted to delete that texture, and I'm fully aware that it's used in many places?

It's nice to read API manuals when travelling on a train or airplane, and you don't have your laptop with you and don't want to waste your mobile phone battery.

It's not a complaint, but a recommendation. Why not make things right when you can make them right?