TheoLogic

C++ without pointers is not really the way to go, but enforcing pointer usage is generally not a best practice... I have nothing against pointers (although I prefer smart pointers over raw pointers), but it is possible to declare a Model (not pointer) and initialize it in your initializer list. //header private: Model m_model; //cpp MyObject::MyObject() : m_model("mymodel.mdl") { }

Agreed, and you don't even need pointers. You can use stack semantics if you want: Model model("mymodel.mdl"); I even strongly suggest to use smart pointers (and not auto_ptr, but unique_ptr, shared_ptr and weak_ptr).

Static methods exist in C#, so I don't get your point. Then you don't know what you are talking about. This is just one of the studies done about p/invoke performance. Even Microsoft admits it is a lazy way to cross language boundaries... And now that you are talking about the language wrapper, this is where I would put the language specific implementations. File handling in the language defaults for example, not pushing in another language to replace it. Pushing it in is the easy solution, but I'm not convinced it is the best one... Again, nothing to do with my remarks. Why couldn't a C# static method be documented?

I don't really agree here. What you're saying is to push limitations from one language into another... Where I see such design it goes wrong. People won't use the API where they aren't supposed to, duplication of code, bad designs, ... It might be an option that the API is LeadWerks specific, and that a bridge is specified for each language. To take the FileReader example, custom for C++, C# uses the .NET library, Lua uses the lua capabilities, ... Don't force your way of working in a language, push the language standards in your way of working. Regarding the static classes build-in into the API, this means you need to expose a C interface and call all those functions with p/invoke. Isn't this a waste of time and a performance drainer? Not being documented makes no sense. If the methods are static and have the same name, you only need to document them once. The only difference is where they are and the implementation details.

Does a single class for global functions look totally weird to you, or does it make sense? Have you seen this done before, and can you provide any examples? The way to go is probably service-operation. The service is your class name, the operation is the function. This follows the WCF (Windows communication foundation) concept. A simple example could be the logger service which has the LogToFile and LogToConsole functions (for examples sake ) namespace LeadWerks.LeadWerks3D.Services { class Logger { public static LogToFile(string message) {...} public static LogToConsole(string message) {...} } } I also strongly suggest that it is a best practice to put different services in different assemblies (not I do not use DLL's, .NET is compiled to MSIL and I don't want to confuse with native dynamic link libraries). So you could have a renderer assembly, a physics assembly, ... It's also a good idea NOT to use abbreviations. The commodore64 times are over . What would you call this class in which global functions are kept? See above... If categories like FileSystem.ReadFile(), Window.Create(), and Log.Print() were used, would you feel comfortable remembering which prefix to use with what global function? These would not be documented on the function page. Don't reinvent the wheel. The .NET libraries offer a lot of functionality out of the box. FileSystem.ReadFile() is just plain evil. Every C#.NET developer knows that he needs to use the .NET streams and readers. Before you implement, I suggest you google what you need to do and there's a fair chance that the .NET library already offers that functionality. That's how .NET developers (we have 300 of them here at work) develop, they just know the most common things and google specific functionality they don't know. On the other hand, specific LWE functions should just be documented. This documentation can easily be generated from your code.

If I'm not mistaken, LE is managed. So the garbage collector kan kick in whenever he wants... Just call Free when you don't need it anymore, when all references are gone and the garbage collector does his work the memory will be freed...

@Clackdor; small remark. I see you have a LoadPlayer and no constructor. You need at minimum a constructor, and even if you work with a Load/Init/... function this should be private and called from the constructor. This is rather a design remark and the idea is pretty simple: "If I create an object of your defined type, I expect it to be correctly initialized. I don't want to create + call a Load/Init/... function." By the way, in C++11 there is a new feature called "Non-static data member initialization". This means you can set the default value in the header file like you did in the first post.

C++11 has threading facilities, so I honestly think you are wasting your time to reinvent this...

Euhm, iOS = objective C for all system calls and C++ support. C# is a microsoft producy . Don't know about the lua support.

Last time I checked this was impossible but high on my wishlist...

a map of <string, pair<bool, menuitem> maybe?

Like Metatron says, you need some more detailed analysis. I personally use AMD code analyst (free) for the first rough profile. In 90% of the cases this pinpoints the actual bottleneck pretty correct, after which I tune. In some cases, this is not enough end you really need to go inside a couple of performance eating methods, and for that I use a custom Timer. Much like what Metatron shows here, but in a singleton class and logging to csv to easily generate some metrics and charts from it...

This is not true. For very simple games it may be, but a couple of years ago we created an educational game using LeadWerks and has some performance issues. After profiling, most went indeed to the engine, but in the range 80-90%. LeadWerks is more middleware render engine as game engine, so game logic is just custom. This is the reason I talked to Josh, giving an overview and analyze with profile logs screens, and proposed to move to C++. The problem is rendering is max 50% (should be to allow complex functionality) of your application, so with LE3 I will evaluate again, do the same analyze and profiling to see where it can actually be faster.

YouGroove, You might want to work on your normals. Especially the green tile is blubber...

Sorry if it sounded like that. The second part of my message was way more important . The bottom line here is it all depends on what you are creating for game...

8X8 on your development machine. Try a more realistic setting like 128X128 and 30 characters and test again. But again it depends on what you are doing. If 8X8 is required by your game, I should say go for it. If on the other hand you're making a RTS I would suggest C++.

Oh, here they go again and say some comments are a language war. Let's blame the C++ guys and go off-topic. Read my original response and blame me being a C++ guy. Metatron, you brought up Fortran. Read the wiki page . And thanks to ZioRed I had to bring it back up.

No, it was designed by IBM for scientific and engineering purposes: http://en.wikipedia.org/wiki/Fortran I don't see the added value for games, and can't honestly image people using it...

Fortran is a joke right? It was designed for scientific purposes by IBM and was used in games a long time ago. I don't think it is still used for games, and I think there's a reason for that .

As Roland says, not a straight forward answer. These is what I personally do most of the time: - LUA (or another scripting language) for very basic things, like for example environment related stuff like a rotating windmill. - C# for tooling (GUI tooling is just very strong) and for prototypes. C# is RAD, you work fast, and the .NET library gives you to power you often need where you need it. - C++ for final games. Some may ask why I don't stay to C# after a prototype for example, and there are a couple of reasons: - C# has a performance impact. You will not or hardly notice this on your developer machine, but remark most people don't have specific game tweaked setups. The biggest issue would be the garbage collector, but with some neat tricks you can work around them. - C# performance impact is a bottleneck on mobile devices. - C# isn't supported on all platform, where C++ almost always is. - C++ is just fast and cross platform, but is the hardest to do and tweak. In more complex situations C++ gives you the power to win just that kind of performance to get your game running smoothly. So it all comes down on what you want to do. You want a MMORPG, I would say go for C++. Going more small levels, indie style 2D game or something like that I strongly suggest C#. Anyhow, your first step is a prototype. You focus on one level for example with basic or complete gameplay depending the amount of work. Test the performance, send it over to friends and family with a home and kitchen desktop. Make a decision afterwards.

interface is a MS extension, and point to __interface which is an alias for struct. http://msdn.microsoft.com/en-us/library/50h7kwtb(VS.80).aspx It's not about liking it more, it's just not ISO C++ .

Regarding previous state: you can for example enter the options screen from the main menu and from the pause. It is handy that the options menu knows what state to go back to. Regarding tweens: you should add states to your MenuStates. State_In, State_Idle, State_Out for example. This can be by design. Interface keyword in C++ is not interface in C# . You should just use class. http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/c8a50d60-c4e7-440b-8f27-0939da61d8a2/ I am talking about your abstract class methods like UpdateState, RenderState. In my opinion these can just be Update and Render. You know it's a state object.

Your are leaking memory, you must use virtual destructors!!! It is also very interesting to know the previous state on state activation. You may have a back button redirecting to a previous (not defined) state. You also miss some logic: Deactivate a menu: I want a nice tween, like a fade or a slide. You have already activated the second one, which also wants a nice animation. You don't want buttons and so to be enabled during that animation. You may want to render another state during the animation (even at a different position), ... This is a nice start point, but not completed yet. Maybe some remarks, I guess they are copy/paste errors: - Interface in C++? - Protected destructor of your base class? - new StateMenu() and so on - Extern enum? Enum is a custom type... - underscore prefix for function arguments? - You may want to loose that "State" in your methods. C++ is strongly typed, so you know you update a state, no need to say UpdateState and so on.

NOTE: Use visual studio 2010 for the following reasons: - In VS2008 SECURE_SCL is enabled by default in release builds, having a performance impact of X2 for every STL container handling. - VS2010 has rvalue references implemented in the STL which is a pure performance boost Now regarding your problem, you need to place the dll in your working directory. For example your bin directory, and after that you can set your working directory in your project settings. Take in mind you don't link a dll (where you do for static libs).

Concurrency comes with .NET 4.0 .