caustic

Nice! Though this thread has gotten a little bit offtopic I really like your personal benchmark results. A benchmark of a small and not generalized problem and some guy who tries to write perfect in 6 different programming languages normally is the best way to start flame wars galore. (Quote Joey: "I never understood why microbenchmarks are run with bad algorithms.") As somebody wrote on that testing page he got down to 6 lines python and he said that the example code is about how *not* to write python. While I certainly didn't see all the possibilities (I just saw one thing I would make faster as the other stuff would spoil readability) I don't know if I would choose another programming style. I have much to learn. And I do hope that some JIT will get my stuff straight somehow. On big problems: I would guess in the end it's all about moving patterns using arrays/lists. If you get down to that there is a big speed difference when using static typed languages or not... But maybe not much more... But it's all how you set up the test and write the code. I would say that IronPython maybe could be a lot better, but who knows...

The framerate should be the same, of course. After all it's LE looping alone when once you finished setting up the scene. The question which and how many calls you can make to LE when running through LE / IronPython. Let's say you can give LE 50 "commands" per frame when using C++ the question would be now on how much the overhead on calling LE is when using .NET/IronPython. Maybe you can just issue 20 "commands" per frame without lag. Performance wise I wouldn't give IronPython so less credit. It's slightly as fast as CPython, depending on the test you do of course. I would however like seeing PyPy using LE... :-) If you get IronPython into Unity3D let me know!! :-) Calling Lua gay is maybe over the roof but I don't like it very much either. I'm still trying to plan my world-viewer. Imagine you have the map of the world and want to stream it via modelled environment in junks via LE. So I would set up a small C-part (or Cython) which would just receive GMF-objects and feed them into LE when needed. Plus some wasd movement stuff to move the camera. Another process then would run in the background, parsing the huge databases about the world, trying to extract needed junks with different LODs and put them into GMF objects, sending it to the C-part. The good thing is that you could just spawn more of those background processes if you need them. I'm not sure about the "handover" process of the GMF objects. Shared MEM? Pipe? Some kind of in-mem database? I think I would prefer an in-mem File System like a RamDrive. :-) Maybe I will wait until LE3 comes out which will feature a bigger terrain...

It's really great. I wonder if it would run in Mono too :-) and via Silverlight in a Browser window? How much is the overhead? Could you make some small measurements? When calling a specific thing in C++ and when calling it in Iron Python via LE.NET... I would say at least LE.NET will add some latency to it, right? How much, does anybody knows? Also when installing a game written in IronPython you would need to install .NET, IronPython and LE, right? Sorry for the many questions, I'm just excited!

Hi rndbit, awesome! This is using LE.NET, right? Did you also had a look at Cython, to call the C part of LW directly? For Code Completion in Eclipse to work you would need to provide a own file I think...

Passworded zip you say? Are there any plans on upping the security there cause if you use the standard zip encryption the security gained is laughable.

Hi paramecij, the "online-fraud site" states at least "Eastern Europe". While I do not like that kind of categorizing because it's thinking in "big boxes" Slovenia is in Eastern Europe. Or ... uhm... depending on where the border of east/west is exactly. Personally I think to just tag a whole continent like Africa is a little bit extreme. Also the CIA classifies Slovenia as "Central Europe" (the UN put it into East-Central or something. Maybe you can argument on that somehow... http://en.wikipedia.org/wiki/Eastern_Europe

Hi - I'm the forum lurker, waiting till the time is right to jump out of the dark corners to start creating 'my game'. I just wanted to thank you guys: Clackdor - it's a nice thing to see how you plan it, from where you come, and where you wanna go. It's good to be upfront and honest to the people (and to the self of course). Rick - your post was the most compact but also comprehensive and very useful article I have ever read about any important subject. Thank you very very much! Clackdor, one more thing: From my projects, I can tell you: listen to the guys telling you to start small. The main problem is the motivation and the dissipating of ones energy with details. So start small: "ship" the stuff you have done, reward yourself, iterate to the next level. Maybe you can also read lums ('Metatrons') tutorial about the guess-a-number game, which is a basic 3d game with easy play procedures you can follow. I would really suggest starting with something very easy - once you 'got the moves' you will advance faster. I wish you best of luck.

Lum, you should really put some better clothes on for this kind of works! You know some smaller shrapnels can cut right through your shirt and harm you! Also I would argue that the majority of the oil drums probably is in the gulf of mexico and with all the oil there should be some much more realistic shader to display the oil film more correctly.

You could make the light dynamic. If the framerate drops you could switch off some distant lights. If the monster boss jumps out of his hideout in front of you the least worry is that some distant lights went out. You could also do that as an effect. If the monsters are about to rush at you the lights will just go out. Good luck aiming in the dark when too much are around hehe.

Oh yes! Just get those number-carrying aliens out and then you can shoot 'em! Hit the 'boss' asap for extra mega giga points and to advance to the next level. You will get hints where the boss is after each shot. I bet that just 1% of users would just get the idea that this is a guess-a-number game.

Regarding the perks: So the perk could just help you a little little bit. Ok, if you would display the range of numbers as a bar: <----------------------------> 0 100 And one would guess 40 you could grey out the already guessed stuff: <----------------------------> 0 100 A Joker could then be applied and give you a hint where to search, or NOT to search (a random range is being made red). <----------------------------> 0 100 A perk would help you like this (two numbers right of the currently guessed numbers the perk marked them BLUE): <----------------------------> 0 100 (so it would broaden the range of your guessing a little bit.) Regarding the point system I meant like 5-Star system. You can have 5 stars in a level or 4,5 or something. If you put this thing graphically it would say more on the first glance than just the number of the points.

Lum, are you on a quest to have every game in the universe coded yourself at least once? Features for Guess-A-Number: - 3D "feedback" on the guessing (if you guessed much too high the number will explode and you will hear 'boo! boo!') - Hints in the form of jokers which could point you to the area where to guess next - "Perks" for the guessing - like if you guessed too low the perk will automatically guess the number +1 again - different AI players with a 'personality' (trying to guess using other models than just "range/2" - also they could lough at you when you are guessing wrong) - music which will get more intense as the guessing range will narrow down - point system with stars which will tell you how good you were - cheats - a poker - style betting system where you can bet on your win. if you lose, you lose the (virtual) money.

Putting it simple: I want to be able to stream everything without having to wait for the engine. When the engine is lame in loading models (because the model is damn detailled) I can come up with something. When the engine has low FPS (because the world is too big or complex) I can come up with something. If the engine stalls because it has to do *something* I can't come up with something. So, simply put: please let's just not stall the engine. Stream everything or make small parts of it or load it in in another thread. Whatever you (the engine) do: Don't stall.

Guys, I think I found the solution for my initial "problem". The solution seems to be Cython. Cython is a Python implementation and I can call C++ functions directly with very few overhead (no header files modification or "glue code" needed). Also the speed is much faster (because Cython compiles into C++ code) and I can use everything from Python or import this Cython module in Python. So I can program everything I want in Python and call the LEngine through Cython or I can off-load heavy code into the Cython module and run it there. Maybe I should use this chance to separate the core game logic (and some AI and some terrain/model loading) from LE what do you guys think? The good thing about this I could use Message Passing Interface MPI - follows C++ implementation. The bad thing about this would be that if LE3 would do everything better (loading models in another thread or something/ streaming bigger terrains) I can scrap all that separation and just use LE3. If I would have the (alpha-)documentation of LE3 I could write (some crappy) wrapper functions for LE2 for my stuff in cython, which would provide an early LE3 experience... Later, when LE3 comes out I would just need to scrap those wrapper-functions... There is a even faster version of something like this which is named "Unladen Swallow" but it got paused when Google removed funding. Sad.

Can someone please please compile a list of all the features which are planned for LE3? It can be unconfirmed, of course. Just so that I can see where the direction is pointed at.

Hi Guy, Im a noob in c++ but I would strongly recommend to use it there as this is the natural choice for programming with LE. Though I know quite some possibilities to 'share objects' between processes I cannot promise that this stuff exists for C++ (for easy usage) also. I'm totally on your side regarding streaming content into the engine. I wouldn't want to wait for a loading screen which loads stuff I wouldn't even probably need later anyway. Also I hate when engines just use one core of my system and everytime they need something from disk they begin to freeze. Just have a look at some "web2.0" apps - the golden rule is: preload all "place-holders" (fast), then display them when you can't load the content fast enough, BUT DISPLAY something at the place for which you are loading something! This is something where many devs still have to learn (or the managers of them) - I think. As for LE - you know when you need a model - plus: you know it in advance (most of the time). e.g. If there are 'enemy units' coming in and they appear on the radar first and then they come into the range of sight. So I would propose the stuff above to be able to load stuff while you are playing without letting the FPS down. As I said I suck at C++ (atm) so I don't know what would be the fastest and most efficient lib to use here. Generally said: You can use nearly every lib which gives you inter-process communication. Just take the network architecture for example (which is quite slow and maybe some firewalls will cry). You could for instance do a small file-loading server service. Define (load_object(), is_object_loaded() and get_object()) and start it up. When LE is running and enemies would come into "radar range" you would lookup if you already have that model loaded. If not, you call the is_object_loaded("name") of the server service and ask if it has the object. It would say "no" maybe. So you send a load_object("name") and continue with LE displaying the world and being smooth and fast responding. In the next cycle you ask the server service again is_object_loaded("name") and this time it would say yes. Then you call the get_object("name") and put this stream of data right into a pre-defined file_object. (like filestream (I hope this exists for C++)). You would stream some kilobytes from the network buffer, and then in the next cycle more and then the rest somewhere in the future. When the object is there you just feed the filestream object to the engine, thus loading the model from RAM. So it all depends on which interface you use to communicate between the processes. Maybe it's fast enough to give the network buffer as a filestream into LE within one Frame. I don't know. Maybe it's better to use PIPEs or some kind of shared mem (some quick google: IPC / OpenMP) or shared objects lib or in-mem database or whatever! Or Remote Procedure Calls (Java: Remote Method Invocation) or somekind of distributed object technology - there has to be some open and easy lib for c++ somewhere. In Python I would use http://www.xs4all.nl/~irmen/pyro3/ . You would just need to search a lib where you can have another process fill a buffer or which can send some kilobytes per object per call and thus you would be able to keep FPS high, load the model in the background (give the process low prio can work also but you won't need it I guess), and 'stream' the model into the engine on the fly. Hopefully this helps somehow.

To put this kind of stuff in another process without having the hazzle to restruct ((un-)serializing) your objects you could use some kind of shared objects. If you know you need a new model to be loaded in the next cycles you just instance the super-class of all models with the name of the model you need and the other process would fill in the data part while the engine could carry on with drawing until the model data has been filled. I read that you can use this kind of shared objects (in shared memory or something) also with non-thread-save modules because the shared object library would handle all the needed processing properly.

Hi - I'm in no way a LE expert but from my 'workarounds' around some products I would guess you could do the following: 1. if the game mechanics see that they need another model to load you send a trigger via pipe (or network or whatever you hip kids today use) to another process running in the background 2. the other process will load the file just to read it 3. the other process pipes (or whatever) the file back to LE and when LE comes to see what input is in the pipe it can pipe it to a memory file object, loading the model from there (removing the object afterwards (or GC)). Don't know if that would be feasible for LE - maybe some LE expert should comment on that first.

Hi again, nice list! I certainly need to read more newb-threads - I see that many of my question have been answered already. Sorry for the redundancy! Problem with the list is: I would give totally other points for the importance. Is there any list for the new features of LE3 (apart from having improved terrain support)? Another question for lumjooa - "what" are you? Owning 20 3D engines, keeping track on all of them, being online nearly 24/7 writing many posts, building new tutorials... ... how?

Hi Lumooja, it's a very nice short starting guide - thank you very much - much appreciated! I can see that LE has very much thought put into details - finely crafted programming art. To be honest I have to evaluate (and disregard) two more engines before I start something with LE. I never thought finding a 3D engine would be this complicated. I'm coming from a language which normally provides frameworks for nearly everything - but is lacking 3D totally (how could that happen!) So I'm not sure if I really should put up a big decision spreadsheet and then compare every bit of feature... when this community is so nice. I just can't decide that :-( . Does anybody maybe have any last incentive for me? Can I participate in the beta once I bought the engine? What will be other big new features in LE3? If money wouldn't be the problem what could I get for LE?

Using ultra-huge terrains and streaming them automatically or using just small pieces of terrains and putting them together as you continue to the end of the first piece of terrain is not that big difference. It's just the question if the engine should do it or the programmer. But I guess the engine could do this more elegant of course. But either way is fine by me. Post some some screenshots when you get it to work, Lumooja! This will look faboulus.

Thanks Josh, may I then ask the next -what all here want to know- question? When (totally rough estimate) will LE 3 come out? Or let's say a nice beta for this? 67 km² with 2 meter per tile is not bad... but... uhm... the reason why all people asks for more is easy I guess: There is too much data and too many free databases. Just imagine: I have a database with the google-satellite-view like dataset of the earth with an accuracy of 0.2 meters. Also I do have a heightmap of the earth (from laser measurement of some satellites) with an even better accuracy. Sooo... I know thats much data! But it's pretty easy to think of putting those two together. The new tech would need to stream the whole world. Also the terrain would maybe not be flat, because we do live on a sphere (more or less). So you can at least drop stuff behind the horizon. (Which is not so much when you are a normal person on a normal sphere it would take something like 4km to draw). Of course maybe you would need to concurrently render meshes of far away mountains and put them into the scenery... But: you can. And that's the problem. If I do have 4 cores in my CPU I want all of them working hard to give me the best experience also I would upgrade if it's neccessary - because some crazy guy decided to model the whole earth and I can fly wherever I like and it looks decent (no, I won't do that). Also 'other engines' are continously raising the bar too. Voxel terrains allow for breathtaking environments. (forgot where I saw it) The infinity engine (which is maybe never going to launch) will procedural-build and show you a whole galaxy and it looks drop-dead gorgeous. (watch from 1:14 - you can just "zoom in" on the planet and the details just keeps on coming ) Please don't get me wrong: LE has many many advantages to those (not even halfway ready) engines, but it's coming. The flight simulators nowadays are showing a level of detail of the ground which is awesome. So to come back to the limitations: if you sit in a jet its easy to fly over 67km² within a mission, also if you crash you want to see the ants on the ant-hill in the forest you just crashed into. I guess the future is all about streaming big piles of data - or procedural creation of stuff - or somehow both.

Wow that sounds great. Family atmosphere is a very nice thing. But I got to know also other families where the sister would then say (without missing a beat): "ok, what do I get in return?" or "this will cost you your chocolate" But yours obviously is better - there is no use in calcing the favors and summing them up and then compare... I will keep that in mind. Hehehe, very nice one!! I'm all in for these kind of "passive" jokes. I can't download from there! But as if you did read my mind... Thanks!! Looking good, I'm in the middle of page one. Nice compilation! Will work through it today. Short tip: put that stuff on the main homepage and for every point put up a small screenshot with the code for this one (from an easy example)... then one could also have a look how easy it is (or how well-implemented the functions are and work). That brings me to my first question: I see that the terrain is not streamable right now. I think that matches with your entry in EN wiki in the section 'criticism': Let me say this one quick before you maybe think the wrong thing: I don't know if I will get to the "end of the world" within my planned game. I see that the terrain can be very huge in LE. Nevertheless my game would basically live from landscape which I would maybe (please don't kill me) build up using a semi-procedural algo (because I'm lazy) or from an actual landscape database (maybe this one, I need better and more accurate details). So if I have to.... hmmm... let's say... (it's not this kind of idea or game) conquer germany :-) and I want to "zoom" left to conquer the french right afterwards I would need an overlay and a loading screen and try to build the next terrain in the background which would disrupt the "fun" . Is there any kind of possible workaround or plan to upgrade the terrain system in the future? (I'm just asking! I don't want to give the impression of that the current system is bad or something!)

Hi Mumbles, Lumooja didn't demand the money - I just didn't want to be "yet another noob" asking noobish questions and then he will be gone forever. I saw some of your threads in the old forum like this and I just doesn't want to be like that. If Lumooja is setting up a tutorial to help me evaluate (and reducing) the costs for in-depth-learning leadwerks I find it nice to at least try to balance this out a little bit so I could at least offer to pay a little bit for good work. After all it's something I can use and I asked for so I see no problem to offer to give something in return. I just wanted to show a little bit respect towards your work and community - that's also the reason I won't go into the flamewar-direction when it comes to LUA vs Python or something like that. But of course it reflects well on Lumooja and the community by not taking it. Because you guys (or Lumooja in this case) is making a difference. You could very well say to me that I should go play somewhere else, but you guys seems to be focused, confident and positive about your work and your attitude. That's one of the reasons - and a big reason for me not to just go ahead and take the next engine.

That's something! Do it. As I don't want to be a cheap ******* - if you have paypal or something I can offer to (partly) reimburse you with 10 € if it's a nicely made tutorial. (Also you can still hold all rights for this.)