Canardia
-
Posts
4,127 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Canardia
-
-
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.Lumooja, I use LE so I don't have to use OpenGL.
-
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.You can't delete a single particle.
-
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.Has LEO been updated to include functions for Framework?-
1
-
-
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.
-
It's IE which destroys the formatting. Use SeaMonkey, or any worse browser, but not IE.
-
The LUA entity scripts have been simplified, so make sure your entity scripts are done the same way.
-
If there is only 1 message per packet, it's only 1 byte more to send, but the multiple message feature allows you to have the packet sending on its own time interval, which is very important. With a single message per packet you could only send 1 message per interval, but with multiple messages you could send all messages which happened during that interval, so there would be no huge delay between messages if the interval is set to 5 seconds.
If you want to make it even more advanced, you could tune the interval according to the network latency. If there is no latency, the interval would go down, and if there is high latency, the interval would go up to prevent total overload of the network connection.
-
It's explained in the wiki: http://www.leadwerks.com/wiki/index.php?title=Visual_C%2B%2B_Custom_Syntax_Highlighting
-
You have to remember that most people don't know english very well either, so better keep the words simple
Normally in games those things you mention are called: Bank and Item. For example:
Bank: 1p 35g 12s 43c
Item: sells for 4g 5s
Lights appearing and disappearing
in General Discussion
Posted
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.