Canardia

Make a LUA hybrid mode template also.

Gamelib 0.0.16.0 is now uploaded, and it should work with all kind of old and new and mixed sandbox/editor scenes. One benefit of its scene loader is that it optimizes the world entities a bit by removing unnecessary physics objects which are left behind when using LUA only. I think when you have many lights in the scene it should also bring some performance boost, but at least it's using less memory.

You might run out of texture memory for no real reason then. So it might work, but it would be wasting resources. I would make the main menu rather a seperate an 2D/3D overlay, that's how many games do it (sometimes you can even see the game scene behind the menu, since they put a black rectangle to cover the screen, but a line of pixels is still visible.

I haven't tried more than one, but why do you want two?

Wow cool! I love how the brightness of the TV screen works as a light too, but a colored like Josh said would add a huge realism and should be quite easy to do too.

I think it's a bug in the DDS converter. When I opened your DDS file in Paint.NET, I could see those 4x4 pixel blocks clearly. Then I did a Gaussian Blur with radius 8 and saved the DDS and reopened it, and the blocks were gone and all was smooth.

Then you can do SetBodyGravityMode(e,0);

Just set entitytype of the controller to something which is not set collide, and don't move the controller.

No, nothing is hidden from us. It's just the first version of Framework, and Josh agreed that it needs some additional functions to be able to be customized for every need. In BlitzMax you have the full source code to Framework, but also then it's not very wise to modify it, since it will get overwritten by updates. So the only viable solution is to provide callback functions at the important steps inside Framework.

There will be a callback function, which probably provides access to the framework buffers. I don't think Josh wants us to render post-effects more often than necessary, so we should get access the latest processed buffers and add our own stuff on top of them.

You can have as many directional lights as you want. But it makes no sense, since it would slow down the performance horribly. Framework is designed on one directional light also, as that's how nature on earth works too. It's either Sun or Moon light, but never both. Even if both are in the sky, only one would cast the light, the moon would only do a slight reflection which would vanish like one to a million under the sunlight. Of course you can have then hundreds of spotlights and pointlights all with realtime shadows without any major performance hit, that's how you should design your scenes.

You can use OpenGL commands from LE. LE doesn't have all OpenGL commands as native LE commands, so you need sometimes to use raw OpenGL commands in LE also. The most popular example is drawing 3D lines, that can be done only when using OpenGL within LE.

1. I had over 4 million polygons rendered at a decent framerate (actually there were much more, since I didn't count shadow polys). However that is just what you see, the whole scene can have hundreds of millions polygons as only the visible polygons are rendered. 2. I don't know what you mean here. If you mean mathematical calculation time to render a frame, it's completely calculated by the hundreds of cores your GPU has. Not much is calculated on the CPU at all. 3. Yes, maximum. You can do as good or even better looking games than Crysis. 4. I think the engine is very efficient, because it uses the GPU for almost everything. Of course it has also some smart logic how to process things. 5. I would do so, if you are serious about writing games. But that's just my opinion. BlitzMax can do a lot, but it's not a industrial standard. Using Leadwerks Engine, it doesn't matter very much which language you use, since the command syntax is almost the same in all languages. However, the vast support of 3rd party libraries in C++ is what will benefit you when writing serious games, like controller supports, SDL.net, sqlite3, encryption libraries, etc... If you however feel comfortable with BlitzBasic (and thus BlitzMax), you can always make the decision later on too, or use both BlitzMax and C++ where each fits better.

I think you should make your own emitter class in C++. You can then entitypick from the cloud vertically down to see where it collides. The particles would be drawn with OpenGL 3D sprites (like drawimage, but with 3D position).

But you could move it far away, so that it's not visible anymore. You would probably need to do this in each frame until the particle is removed by the engine.

It's possible to get the position of a particle, but only in BlitzMax at the moment. The class property for the particle position would need to be exported to the dll to be able to use it in other languages.

It might be that the evaluation version had some entity occlusion for the lights enabled, but it's also a quite old version of the engine, and might have been a bug at that time also. Entity occlusion can be enabled or disabled per entity ( see http://www.leadwerks.com/wiki/index.php?title=Entities#EntityOcclusionMode ) to optimize performance, but usually it's not needed since the engine and OpenGL has also automatic occlusion which is usually good enough.

GetEntityKey(e,"class") should do it, although it won't do all what you wanted, just some entity classes.

How can Autodesk still make apps which are not backwards compatible, don't they ever learn? Lotus has made apps since 1985 which are all backwards compatible still today!

OK, I found a hack for leoLayer.h which makes it work in Debug mode also. Just need Josh to update it. The good thing is, it makes GetWorld() and GetCamera() functions a bit faster too, since they use now a pointer instead of calling framework functions each time. It allows also more LUA/BlitzMax style coding now, since you can say now: fw.main.camera.SetPosition(0,0,-5); and of course the strict OOP syntax works also: fw.GetMain().GetCamera().SetPosition(Vec3(0,0,-5));

Yes. You can see all details of LEO changes in CPP/LEO/changes.txt.

It works only in Release mode, in Debug mode I get also the error, and the camera entity is sometimes NULL and sometimes some lower value than the real camera value. Seems rather like a bug in Visual Studio C++ to me, since how can something work in Release but not in Debug? I'll try to find a hack which makes it work in Debug mode also.

We really need a playerstart entity for LUA. I think I'll continue developing fpscontroller2.lua and see where it gets. My goal is of course to unify it with gamelib somehow, but the best ideas come when coding

I found a way to fix the roads, at least in LUA. Change line 13 in road_node.lua to: class.roadoffset=0.055

Roads don't work properly from engine.exe with the fpscontroller2.lua script either. You can test this by changing the scene to deserthighway.sbx and line 44 to: controller:SetPosition(Vec3(1032,173,-244)) What happens is that the road splits more and more into pieces the closer you get to it. From further away it looks OK. I think this might be related to the C++ roads issue also.