Canardia

Why don't you do it like in gamelib, there you have as default separator whatever is in the current engine, and optionally you can specify as 2nd parameter a different separator.

I heard some rumours that there was a console version planned, and possibly also a mobile phone version, so it should run also on low-end PCs if the same renderer is used for PC.

I think it will be a bit faster, because all octree occlusion culling and looping through entities is much faster in C++. So a part of the rendering would be around 3-4 times faster, but not the whole rendering. It might result in that the whole rendering is about 1-1.5 times faster. But I think there will be new options to make rendering even faster by disabling certain features, some of them you can do already now: disable post-effects, render to a smaller buffer.

You don't need to use 2D drawing, but you can use 3D lines to connect real vertices with lines: http://leadwerks.com/werkspace/index.php?/page/resources/_/programming/cpp/using-opengl-for-drawing-r19

SBX can have "," or " " as separator, depending on the engine version (2.2x vs 2.3x).

That means your main loop is somewhere hardcoded, and when you change it there (if you even can change it), it will be overwritten by each patch. I think games and applications can be so different, that there is no way to make a standardized main loop. Some tool might just render one or 2 frames and then do something completely different. Or not render anything, like a game server. But yeah, LE is more a game library than a game engine, since it allows to do more than only games.

I have to make some test with tesselated mesh terrain. I don't see actually any major disadvantages of using meshes over terrain, since the renderer puts them on the GPU anyway. Alpha blending is also no problem when you put the transparent parts into the foreground world. It just needs to happen automatically, so some sort of class for the mesh terrain would be handy. And the engine needs to draw only to a certain range, so the seperate meshes will be drawn only within a certain distance. It's probably then even faster than the current terrain. The mesh terrain class should be also able to read terrain heightmaps from Editor, and convert them into meshes. Then the terrain can be deleted from Editor and the corresponding meshes can be used instead. Converting back to Editor terrain can be done too, but I think people would prefer then to use Sculptris or Blender for further terrain editing once the base mesh has been done with Editor. With those sculpting editors you can then make any kinds of overhangs, caves, loops, and completely 3D terrain in all directions. Once you've tried that I think you'll never want the normal 2D terrain back. I see also a huge improvement in loading times of big terrains, as only a small part of the infinite terrain needs to be loaded. The loading of the terrain will be handled by the meshterrain class too, so you only need to place the placeholders for them in Editor. You can also simulate in Editor the dynamic behaviour by using non-infinite viewranges for the terrain placeholders. Theoretically this would be sufficient for the class too, but there might be some problems with the 32-bit floating point accuracy, so to make sure it really works infinite, the positions for the meshes need to be 64-bit floating points, stored in a custom text file, which is then read into a STL map.

Flexibility and compatibility and integritability are one of the most powerful aspects of LE. I can't understand why some other engines don't even allow to program in C++, while LE allows to program in all languages. Or why some engines don't allow you to flip your buffer when you want, but take the main loop in their own control which only limits things and makes development much more difficult. Or why some engines don't support OGG, don't support OpenGL, don't support direct 3DSMax export, don't support UU3D, don't support Entity Oriented Programming, and so many other things which are essential for fast, easy and quality game development. It's so much more fun to develop games with an engine which is designed from ground on correctly, and allows you to program with whatever language you like most.

It's compilable with BlitzMax, but of course it has C++ code also, and the compiler just compiles them along with the bmx code. I haven't noticed any prerequisites, or then I had them already (perhaps some Brucey's etc... mods).

Yeah, I am a happy source owner

Yes, the source is always available. The pricing is like with the various team, group, coorporate, associate, etc... discounts: you need to ask Josh for the price. The source is ready to compile, just one command from the command line will do it, and another one to compile the DLL.

Terrain is not movable, but depending how fast you want to move, you can either just create a new terrain or move the camera instead, and load a new scene when the zone border is close enough. Of course you can also use models to create a terrain, which gives you a real 3D terrain, but is more work to draw.

It doesn't really matter which is a core and which a Framework command, this happens to be the only command which exists on both, and also the only command which does not work when using Framework, unless using the Framework version of the command.

I think it knows each part of the mesh, and can thus morph it to look like different people. If you do that manually, you only get random monsters And I think it has also lots of animations.

fw.renderer:SetWireFrame(1) WireFrame is the core engine command (same as Wireframe in C++), which is reset on each frame when using Framework. SetWireframe is a command to tell Framework to use your own wireframe mode for each frame. However, it works only on the main world, so models in the transparency world are still rendered without wireframe, which is a bug, and should be fixed soon.

It should work, since ION is a GeForce 9400M, which is a DX10/OpenGL 3.3 card: http://en.wikipedia.org/wiki/Nvidia_Ion

I tried it a bit, and it's very easy to use. I remembered then that Blender has also sculpting and painting, so I have to try how it compares with Sculptris. It would be probably better to have everything in the same modelling program, since you want to do also animations, boolean operations and vertex fine tuning.

Those 2 lines: require("scripts/class") local class=CreateClass(...) are needed for every model, because without those many things don't even work. For example entitykeys in a model's ini file are not read in. You don't usually need anything else in the Lua file than those 2 lines.

It is, the R5/R6 etc is not official versioning, but the community makes up those microversions since 2.32 has been updated several times. 6 times so far, thus R6 now. Josh should really use the industrial standard notation like 0.0.0.0 versions, so it would be 2.3.2.6 now

Some work solo, some work in a team. It's hard to say which is more popular, as with solo you can just buy stuff from others, so you kinda work as a team too.

I think you can do raycasts on vegetation layer with a little trick: draw the vegetation to a small separate buffer, and check if the pixel in the center of the buffer is not the background color (for example full blue).

Slidingcollison is a LEO feature, not gamelib. Gamelib doesn't change any engine commands, but only adds new unique commands.

Displacement maps create additional faces, so they are much heavier to render: http://www.ru.is/kennarar/hannes/useful/blendermanual/htmli/ch11s03.html I think instead of displacement mapping you could just create the details with real faces and then use a normal map on top of the details.

It works fine in 2.32R6.

You need a lot of money to make any kind of game, so game business is not the right choice for people without money. If you have no money and w2ant to earn some money, you shoould rather look at jobs like paperboy and grow from there.