Clickteam please improve PERFORMANCE of MMF2 games ASAP

[Konidias]

As many others have stated, it has a lot to do with your events and making your game run efficiently. It's like creating some huge fastloop running through hundreds of objects doing some complicated stuff and then complaining that it's not running at constant 60fps. MMF2 is not a miracle maker... it can't fix your poor coding habits.

Another thing I want to point out is that Blue66 keeps saying that doing things more efficiently and with workarounds takes "lots of time" but I think he fails to realize that MMF2 has already saved him infinitely more time by doing what it does best... creating super quick prototypes of games and making game development incredibly fast and easy.

No game engine is going to handle poorly optimized code well. If MMF2 isn't cutting the mustard, feel free to go create your own engine from scratch and see what takes you longer... doing it all from scratch, or doing it in MMF2 with some time invested in proper coding/optimizing.

The benefits outweigh the downsides in this situation. Would we like to see MMF2 run things a bit faster and smoother? Of course. Is yelling at Clickteam going to make it happen any faster? Nope.

[Pixelthief]

I do what I do in MMF2 with Asunder and it runs efficiently, there simply aren't any unreasonable limitations on what you can do with a 2d application in MMF2.
Maybe if I run into a upper cap on total events, or the bit where my HWA is somewhat limited by having to use pixel shaders where I should use vertex shaders (cough, update plox)

But with intelligent coding and resource allocation and optimization, framerates should never be a concern in MMF2.

[SolarB]

LB - since you're so confident - or anyone else, if you can find a way to optimize my 1000 unit RTS example you will receive a large portion of cake and perhaps a live badger!

[conceptgame]

I did not really understand what you meant by this. Actually I would love to have some kind of big article or example files of ways to do optimizing in the code. It would be extremely helpful. A place where all clickers or the most experienced could share their knowledge on how to optimize the code.

I totally agree with this. An article explaining some of the well-known optimization tricks is definitely a good idea. The article from Andos for the iOS exporter is some of the examples that are extremely valuable. If they are stored in one place, it would be efficient and avoid some users to be frustrated in the middle of the project. A good community as this of Clickteam, which can support you when optimization is required, is good but it is even better if the developper can anticipate and start programming in a more efficient way. Perhaps, it already exists but it could be more visible.

[Konidias]

LB - since you're so confident - or anyone else, if you can find a way to optimize my 1000 unit RTS example you will receive a large portion of cake and perhaps a live badger!

Changing the objects to box collision instead of fine collision added a few frames for me, but other than that I think there isn't much else to do to optimize that any more.

The thing is, your example is CRAZY and I don't really think anyone is going to have 1000 units all firing at each other on the screen at the same time. :p I think under normal gameplay circumstances it would be just fine. I can't even think of an RTS that had 1000 units. Most RTS I've played have maybe a hundred units on screen total at max.

[Nifflas]

But with intelligent coding and resource allocation and optimization, framerates should never be a concern in MMF2.

There should be no problem with what Blue66 is trying to accomplish with around 800 objects, a bit of optimization should take care of that. However, it is still a fact that MMF2 isn't the fastest software around and where it's possible to use thousands of thousands of rather complex particles simultaneously in e.g. Unity, to create quite amazing effects, you have to hold back a lot in MMF2. Or even just complex systems with a bunch of modular robots with modules that interact with each other and send information back and fourth. It quickly starts to involve a lot of iterations and becomes slow, even with the ForEach object. You can not say that framerates should never be a concern, with my new project I have to hold back all the time, and this is one of the most optimized MMF2 game you'll find.

In a game with a lot more interaction between all objects than mine and more iteration can't be worked around, I can easily see it crossing the point where optimizing will not help and it's just too slow to be done in MMF2.

I agree as little on your superlative "should never be a concern" statement as I agree on Blue66's "it's all MMF2's fault" take. Try to make anything where you can't work your away around large amounts of iteration in MMF2. Powder game for example. Try to simulate a large ecosystem of interacting creatures like in Blueberry Garden.

This is why an MMF3 with an event system that allows us to write more efficient code would make a huge difference for me, and will be required to attract more advanced users. I don't want to have to hold back so much, which is why I hope MMF3 will be amazing.

[Phi]

With regards to multi-core and multi-threading design, which I am immersing myself into, it is much harder than a simple flick of a checkbox in the compiler. And if difficult to design in MMF2 itself, it would be much harder to design into all the apps it compiles.

If you are using the HWA runtime, I can report I have good experiences with it; it is much faster than regular runtime. I would be quite happy to review your application for fixes; my company offers an UltraCode service whereby code is improved, and one code language it supports is MMF2. The only time I've gotten real issues with MMF2 is when C++ code in the objects themselves was inefficient, for example non-HWA-compatible displaying objects cause the CPU to go off the roof. I have also encountered small memory leaks.

The bottom line is, unless you code everything yourself down to the C++ code, you won't be sure of problems. Deadlines aside, a problem is resolvable if there is time to fix it. I've got myself in the habit of only complaining about things I can fix or the person I'm complaining to can fix. It's quite useless for me to complain to my brother about something like this. Your critique is well noted and I have encountered bad performance before.

I can confirm with Nifflas that there is a lot of code resolving from several major versions back, including Click 'n' Create and KNP. A single inefficent method coded back then would be used in multiple scenarios and be accustomed to over time and thus would take far longer and more painstaking to fix now then it would then. It is nearly out of the question; it would take years to completely rework MMF2 itself, and I don't mean just a few. Just a glance at the SDK code I removed for optimisation in my SDK would reveal that the engine itself has a inefficient foundation. Not to insult Clickteam's developers of course, since my code has certainly improved over time and I would probably dislike it five years from now.

I am doing my part in optimising code by offering the UltraCode service, coding multi-threaded extensions, recoding inefficent and buggy ones, and providing a new extension SDK which is capable of creating multi-threaded extensions - with examples of the SDK in practice, both in C++ form and extension form. I expect it will be released within the month, which is what those reading my "Beginner's Guide to Creating C++ Extensions" blog will be using and the reason for the delay in the latest posts.

So if you're interested in my optimisation of your code, contact me on ClickConverse.

[GrayFace]

About destorying things like enemies when they are offscreen. Is not creating objects all the time going to slow things down? What about object pooling? Could an alternative be to stop all movement of the obeject, disable its group and set its animation to a single frame tiny square, and then enable everything when it comes into the screen again?

Group applies to all objects of a kind, so group disabling won't help. If some objects of the kind are on the screen, the group must be enabled and any condition would still traverse all objects.

[Konidias]

Any game development tool is going to have limitations... you just need to decide if you need to exceed those limitations. If that is the case, maybe find a different tool. People keep mentioning Unity like it's the holy grail of game development tools, but even Unity has limitations and you'd have to rework the engine to push things further.

Meaning if you want absolutely zero limitations, you're going to have to build the entire game engine from scratch. MMF2 in my opinion is a great game dev tool for making quick prototypes and smaller games. I don't think it's really meant to push the envelope and do triple A titles. It can make really great games that are totally enjoyable and great looking... but don't think it's going to handle making the latest and greatest next gen stuff when the software is really dated.

I have to ask though... if you really are running into limitations with 2D games in MMF, is what you're trying to add actually needed? Does it make the game better? It would be like making super mario bros but you need to have 500 goombas on screen at the same time because you suck at designing levels and flooding the levels with crap is the only way to make it look interesting.

I'm pretty sure that MMF can handle making most SNES games without problems. You just have to be smart and efficient.

[Outcast]

Group applies to all objects of a kind, so group disabling won't help. If some objects of the kind are on the screen, the group must be enabled and any condition would still traverse all objects.

Its not those kind of groups (qualifiers) we are talking about.