TheoLogic

Strange, your approach with locking should work just fine... You could also use a concurrent_queue and load everything from your main thread. Just push_back everywhere you need it, and try_pop on the main thread.

What about move semantics? Those could really optimize the engine by X! Lambda's are also perfect candidates for inlining, use them where needed... Concurrency could be a great addition, most CPU's being multi-threaded this day, using unordered_map instead of map, hashing strings, loading from binary instead of text files, ... Many thing you can do

I did read the remarks, and I even quoted them . I know this reads like: "he's bashing C#", but I ain't really. I love C#.NET and very often use it. My only concerns were the things I stated above... I post this here, because it was linked here. The original author was already spoken too by other persons. I am sorry, I will not post criticism here again if it bothers some users.

Useless comparison: - VS2008 has secure SCL enabled by default in release. This is a performance impact of 2X in release builds. - hash_map is not even standard C++. Use C++0x unordered_map instead. - No garbage collector in play? You should also remove the C++ allocating and deallocating time... - std::string is slow in VS2008, duh no move semantics. Test this in VS2010. - Port C# to C++ one on one? Even the other way around this is a bad practice. I use C# often, even more as C++ lately, but saying the performance impact is minimal with these kind of test is just plain wrong! Especially for games, I needed to add a lot of caching to avoid lag... I'm not even speaking about the cold and warm starts of native .NET code. Like others stated in the comments, this isn't a real-life example. You can love up in both languages!

Due to not being able to vote due to the poll layout: Windows OSX iOS WP7 Cool would be dynamic settings, so you could create your game once and have automated conversion to other platforms. For example, iOS supports textures up to 1024², so your bigger textures get scaled down... I would also suggest binary files over plain text/XML for performance reasons on mobile devices.

Agreed, this is one thing I was going to test once my demo scene is done. I don't think LWE sorts the scene file by material (shader and texture), this could result in unnecessary texture and shader swapping. I will write some tool to sort: - By texture (is the heaviest swap) - By shader - By position So all of those combined, will need some testing. However, I do not know the internal implementation in LE2. Like josh is working in LE3, this may be very problematic because map is a red-black binary tree. Maybe we could get a gain by using an unordered_map. If Josh uses auto for iteration, or the for_each algorithm he could implements this in 1 min...

I'm actually creating a house myself at this very moment, and this is indeed a very good question... What I have remarked with LWE so far is that rendering multiple instances is slower as rendering one. Yes, this will result in memory bloating, but is memory still an issue these days? SSD's are coming up, making disc IO way faster... This is the main reason why I personally decided to create 1 mesh = 1 house. Another reason would be that placing separate objects in the editor is a pain in the bum .

Agreed, we're moving of topic . Answer could be simple: If Josh has the time and the will to keep them updated: "Be my guest..."

No I have not . I'm not in a good mood, sorry about that... I sometimes get tired of people bashing C++ devs (even if they use other languages and scripting where needed). I'm proud of C++, one of the old school languages still evolving!

Please don't overblow my words, I can't really appreciate people putting words in my mouth. So do you believe cheap software that has 101 features? In my experience everything has been blown up, and almost nothing works... If I see LeadWerks officially supporting a whole range of programming languages, I'm not convinced this will magically work. You are very, but then very cocky. This is an open discussion, and just because you don't like it, blame the C++ devs! We state that this could be an option, or that could be better. Go ahead and stay in your comfort zone. You want to weight to pros and cons, do it in group, we are open to suggestions. Weighting against yourself is gonna end up with what you like the most. Sorry for this...

@Paul Thomas: In my opinion it's not a plus that an engine supports so many languages. For me this reflects some kind of amateurism, because this gives me the idea that there is no clear goal or target... But that's just my personal opinion. But anyhow, I think there will be a time where the editor should be rewritten. I would prepare to this change, especially with a version change in mind. But Josh's decision .

Java is not native, that all...

Exactly, you're going to loop yourself... What do you do when something changed? Call an event . Event based development is loop based in the background. Don't go an reinvent the wheel! Josh, you could just use Java. Java is one of those languages that have been build for UI's...

You say something contradictory. Your suggestion is more code and more code is bad? I think you mixed up or I don't get it . But if you're talking about a loop, I don't think that's a very good idea for UI. You're saying you prefer an update() to check your objects state, but that doesn't really makes sense. You can check your elements by their name: m_buttonToDoSomeAwesomeMagic->isEnabled() ...

You have QT, WxWidgets (which I prefer over QT), ... but that doesn't make C++ the best idea for UI. C++ has not been designed for event based UI development where other languages have. I used to do all my UI in WxWidgets (and Rick, this has an editor, generating clean C++ code), but have moved to .NET. These days you're app is not only the UI, but you want to sync with a server, extensive build-in help, ... and even with a C++ library this is still a pain in the bum.

I don't think C++ is a good choice for UI development. .NET or Java are way better UI languages... Maintaining a C++ based UI is just a time spender!

Let's say you have an entity (take model for example) which has 6 parameters. You specify a datacontract and the needed operations to communicate with your WCF service. The client would be the editor, the service a windows service for example. You can only provide 3 parameters, and the other 3 are optional. Thiw way you could extend your application. I agree that reflection gives you more power to do this, but in a reflective way. Things can get terribly wrong, because reflection is just string based...

I should personally use WCF for this. Every entity has a data contract which states the parameters, e message is send on change. Nice and easy!

I do not really agree with you. A strong typed language isn't supposed to be used like that, and I find using reflection rather a bad practice. I even use it, but the problem with this is it's going to be mis or/and over used. Take LINQ for example, this had a great boost but now more and more developers are saying they used it where they didn't had to, making it hard to debug, ... If you really want to use them, use languages such as Python which have been designed for. I even think C++ will never provide this support, this would enforce a string standard, ...

I agree, just don't mess with pointers. I would even say to not mess with raw pointers, use the way better unique, shared and weak pointers from C++11... The proposition made by Roland is by far the best, except for a possible thread safety issue (and Roland, there is no universal or accepted C++ standard... I go more for your design as far Lumooja's which I think is just plain evil ). But the big question here is, what is the idea? If this is based on stack semantics this is wrong! Take for example: std::string one("Test string"); std::string two("Test string"); one == two is true, but they don't point to the same memory block... The concept of stack based development is value semantics, not pointer semantics. Josh, what are you doing? Way better to comment that way ! If you have void pointers there is something wrong with your design . Don't take this wrong, even Microsoft uses it, and you can. But this doesn't mean you should... With some base class you can get as far...

omg lol . I'm running a GTX460 here, pricable and great graphics!

Even better: enum TextureMode { TextureMode_Diffuse, /* = 0 if you want to, but I don't really see the need to...*/ TextureMode_normal }; The main problems with defines are really simple: 'They are not subject to any C++ rule what so ever.' The precompiler just replaces them in place, so you can define them again at a later point in builds, even undefine them, ... with all undefined behavior and strange errors.

Some good concept, but again I find something that I don't really like in C++, being macro's. Even Bjarne Stroustrup advices against it .

You could indeed write an engine in C#, but it doesn't only takes a decent amount of knowledge but also involves some magic and hackery. The big problems with C# are the GC (duh) which will collect at the moments you don't want to. To fix this, you need some trickery to collect when you want, and it's very easy to get this wrong. On mobile devices for example, even that isn't enough and you will need some caching mechanisms to avoid lag while ingame. Another issue is that you can't do any meta programming at all. This is what offers the machine level performance to C++, compile time optimizations! Nevertheless, there are some teams who really get it right like rising rock games. All depends on the developers. That last statement is due for all languages; in C++ it is easier to not shoot you in the foot, but if you do you blow your whole leg off... I could say that C# prevents you to shoot yourself in the foot, but you will anyway, to get it like you want to. Now porting LWE to XNA? Well it would be a pretty good idea, but not a priority. You won't get the performance to run LWE graphics like we know them (especially on low(er) end devices) so we should cut in supported features. If LWE is ported, this should be done supported by LWE to avoid multiple versions like we have with C# atm.

I agree with this. You can accomplish great things in C# XNA (rising rock - athmos for example, some people I know), but it's very specific, and you need to know a great deal about C#, asset management and the memory management to get it working at decent framerates... About LUA, I see it more as a service to non experienced developers or artists. Don't take this wrong, I think LUA is a good idea until some points, but there isn't anything you can do in LUA you can in C# or C++. LUA is just easier, a good level of abstraction for those who need it .