Canardia

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.

Yeah, that would make sense, since I don't usually make errors, and I still get those messages. LUA errors show up also differently, with a clear line number and descriptive syntax error. I think the access violation is just a simple memory violation caused by the memory allocation routine of the built-in script editor.

Yeah, I wasn't saving either, it's a bit wierd that LUA errors can occur even when you haven't saved the file yet. Maybe some workaround, like adding -- to the front of the line before doing other changes could avoid the problem

Usually this error starts to popup when I initially make an error in LUA code.

It's not better, but different. One needs to get used to the new one to say if he likes it in the long run. The new theme uses also 3 times more bandwidth, so I think I like the old one better for technical reasons (I use the forum also from my 3G/EDGE mobile phone).

You can't just send something before checking if the network latency is good enough. You would only make it worse if there was some other traffic going on. The network could be also completely down, then you need to wait and collect the messages anyway. That's why you need to collect the packets to be sent, and send them when the latency is good. You should have also different priorities between important messages, like object positions and not so important messages, like chat messages. The object position messages should run at a shorter interval than the chat messages. And if any object position messages are not sent yet, then no chat messages should be sent before them, else people could exploit the system by spamming the chat channel to cause warping of objects and cheating the battle system.