User Tag List

Page 7 of 14 FirstFirst ... 5 6 7 8 9 ... LastLast
Results 61 to 70 of 138

Thread: Clickteam please improve PERFORMANCE of MMF2 games ASAP

  1. #61
    Clicker Fusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleSWF Export ModuleXNA Export ModuleUnicode Add-on
    Fanotherpg's Avatar
    Join Date
    Jul 2006
    Location
    High Wycombe, Buckinghamshire, UK
    Posts
    3,665
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    TBH everyone who are attacking Blue66 should step back a little bit, as his argumentation is totally valid, unfortunately. And he is responsible for one of best games I ever played, made in MMF, and only projects done by Nifflas and Pixelthief are coming anywhere near it (at least for people involved here in discussion about optimisation and as far as I know their releases if any).

    And I'm stating it after experiences with creating my own Pseudo 3D cRPG with 7k+ events running without group disabling in one frame on max FPS in MMF 1.5 (Cade Tower), Raycaster engine hacks to make it efficient and usable for games (Sens3s: The Art of Understanding) or even highly optimised cross-platform platformer engine Mush Mush (http://community.clickteam.com/showthread.php?t=70671 ) where I receive a lot of input from some best coders around (SEELE, Nifflas, Pixelthief, Sketch/MuddyMole, Mathias).

    He is right that MMF2 is unoptimised and slow. He is right as well that with modern hardware such issues almost shouldn't exist. As such projects where playable and possible years ago on consoles and home computers and now hardware improved heavily (modern pocket calculators have more MHz CPU's than PC's on which original Tron 3D effects were generated).

    Thought I agree with others that proper using of extensions and/or HWA as well as optimised coding and hacking events to get maximum performance are a way to go (and always were even in true coding) they shouldn't be in MMF.

    MMF is promoted as a software for NON-PROGRAMMERS as such contexts and ideas of Group/Object iterations, loops, code garbage, inefficient coding, wrong order of events/actions etc shouldn't be expected to be used or even KNOWN from the end user. And as such MMF should be able to handle such coding, rearranging it, dealing or performing better - which is the exact point of Blue66. MMF fails in it's basics, providing efficient environment for complex games for non-programmers with no prior knowledge, as getting issues with performance is much easier to achieve than anything else in MMF.

    At the same time I'm not negating the fact that MMF is my prior tool for game designing and fast prototyping and I'm not going to change it any time soon. Furthermore advanced users in MMF are able to get amazing effects from it and are pushing it's real boundaries and I seen that work with my own eyes on every Click Convention and private presentations so yeah... both sides are right but instead of attacking each other you could understand the issue.

  2. #62
    Clickteam Clickteam
    Simon's Avatar
    Join Date
    Jun 2006
    Location
    UK
    Posts
    2,670
    Mentioned
    60 Post(s)
    Tagged
    3 Thread(s)
    I am writing up an analysis of what is slowing the game down at the moment which I'm going to post here for everyone to see (without disclosing anything of Blue66's actual game/programming of course).

    Whilst it is true that there are some things MMF could and should do better/more efficiently, I don't think that is the case here personally. From what I can see it is down to the way in which certain things have been coded and I don't say this in any way to attack Blue66... just that I don't think MMF is really at fault on this one.

    I will post again when I've written up a detailed analysis of it.

  3. #63
    Clickteam Clickteam
    Simon's Avatar
    Join Date
    Jun 2006
    Location
    UK
    Posts
    2,670
    Mentioned
    60 Post(s)
    Tagged
    3 Thread(s)
    I thought I'd report back about what is slowing down the game in the open forum, as it is drawing so much attention.

    Specifically (and this will only mean anything to Blue66) the events which are really bringing down the frame rate are in the Enemies group in the Global Events.

    All of the groups are quite intensive, but I'll focus on the worst offenders here. To determine which events were actually slowing down the game I disabled groups one by one and observed the frame rate after each was disabled. This is a good habit to get into when experiencing inexplicable slow downs and you will quickly determine where the bottleneck is this way.

    Within the Enemies group, the following nested groups were causing the most slowdown:

    Skullface (around 4 FPS drop when active) [30 present on the demo frame = very approximately 0.13 FPS per object]
    NoseMan (around 3 FPS drop when active) [12 present on the demo frame = very approximately 0.25 FPS per object]
    Cowboy Bot (around 10 FPS drop when active) [25 present on the demo frame = very approximately 0.4 FPS per object]

    As it is the most costly, I'm going to look at the Cowboy Bot events to see what is causing the slowdown. First of all, some statistics about the events within the group that controls this object:

    There are 38 events which run, with various conditions in the normal linear sequence of events (excluding loops and for each loops).
    Multiply this by the number of cowboy objects (25) and this equates to up to 950 events to handle the cowboy bots (checking each instance of the active)

    Within the 38 events, the following collision detection conditions are checked:

    Collision with backdrop: 3 events with this condition (multiplied by every object equates to 75 background collision checks)
    Overlapping another object: 8 events with this condition (multiplied by every object equates to 225 overlap checks)

    Two of the objects which overlapping is tested against are medium sized actives too, each containing an oval shape and with fine detection enabled.

    There are also some loops triggered by these events:

    A ForEach on the Cowboybot object, which triggers a further 25 events, each of which contains an "overlapping another object" test

    You also have a loop "xPopCowboy". I have measured the frequency with which this is called. Over a period of 60 seconds, during which the FPS was consistently 48, the loop was called 628 times. This equates to 10.4 loops each second, or, 0.2 times per frame loop - more helpfully, every 5 frame loops (roughly) the loop gets called.
    This loop has two event lines, each with an "overlapping backdrop" condition in it. This means that for every 5 frame loops, two backdrop overlap checks are performed. Your ACEs potentially check each of the 25 cowboybot objects, so this value multiplies to 125 backdrop overlap checks. 48 FPS/every 5 frames = 9.6, therefore every frame loop you are running these overlap checks 13 times on average.
    As this loop operates on each cowboy bot object, it essentially adds 13 events to each frame loop also.

    To sum up, for each frame loop you are doing the following:

    Collision with backdrop: 75 times per frame loop
    Overlapping backdrop: 13 times per frame loop
    Overlapping another object: 225 times per frame loop
    Equivalent number of event lines: 38 + 13 + 25 = 76 events per frame loop.

    As it is running for me at 48 FPS, this equates to:

    Collision with backdrop: 75 * 48 FPS = 3600 times per second
    Overlapping backdrop: 13 * 48 FPS = 624 times per second
    Overlapping another object: 225 * 48 FPS = 10800 times per second
    Equivalent number of event lines: 76 * 48 FPS = 3648 events per second

    In your MFA you had set the frame rate at 60 FPS. To achieve this rate, the following values would be the case:

    Collision with backdrop: 75 * 60 FPS = 4500 times per second
    Overlapping backdrop: 13 * 60 FPS = 780 times per second
    Overlapping another object: 225 * 60 FPS = 13500 times per second
    Equivalent number of event lines: 76 * 60 FPS = 4560 events per second

    Even at the modest frame rate of 30 FPS, you are asking MMF to perform 9390 collision/overlap detections and the equivalent of 2280 events every single second and this is just one set of logic for one enemy/actor in your game.

    There are things that MMF does to be more efficient than these bare numbers above in real operation, so these values are the worst case scenario. That said, none of the above takes into account any of the other overheads present in your events, including:

    * conditions not mentioned above (including comparison of alterables, use of the Select Object Extension, flag comparisons, testing position values, accessing data of multiple objects (position, alterables etc.), x chances out of y, )
    * overhead of running loops themselves
    * overhead of running for each loops
    * MMF's internal object selection overhead
    * Changing alterable values
    * Creating additional objects (when cowboybot fires for example)
    * Changing the direction of the actives
    * Changing the coordinates of the actives
    * Random number generation in expression
    * Playing samples

    I've just picked out the common/costly things which you are performing here for this object's logic routines and whilst individually these things may seem trivial, they do all add up to a lot of overhead just for this one object. And, none of this has even taken into account redrawing those objects within the loop - which is done pretty frequently. Each redraw involves updating collision masks, restoring saved background from memory, drawing the objects in their new positions and saving what was behind them.

    Now consider this in the context of your game. I mentioned the Skullface and Noseman objects which introduce a drop of around 7 FPS to your game, based on 42 objects in the level configuration you sent me. I won't go through each one as I did Cowboybot but there are comparable inefficiencies in your logic for those too, not to mention the 4 other types of enemies' logic (each of which introduces a drop of around 1 FPS).

    This is all of course in addition to yet more processing time and overheads for everything else in the game, including:
    * a total of 900+ objects
    * over 2500 event lines (globally and directly in the frame)
    * 5 layers of parallaxed background scrolling, all of which are scaled to the full window size at runtime, one of which is constantly being rotated and scaled at runtime
    * sub app frames
    * an 8000 x 3600 pixel frame
    * 8 layers in the frame
    * 1 layer with subtract effect (albeit via shaders)

    The reality is that you are asking MMF to do a hell of a lot of processing and when the level came to me for examination, virtually everything to increase efficiency was disabled or not considered. This included:

    * fine detection being enabled for all objects and backdrops (where relevant) rather than much faster box collisions
    * save background set for objects which never need to redraw the background
    * inactivate if too far from window switched off for everything
    * no optimisation to disable objects which are invisible off screen, everything was running everywhere all at once regardless. This doesn't necessarily need to include enemies - things like coins, powerups etc. (which are static and don't move around) can all be frozen when out of sight for example to improve efficiency (as I said above, MMF has an option to do this automatically but you had it disabled on all objects).
    * costly conditions such as overlapping/collision tests repeated multiple times rather than testing once and using such as determining whether an active has move since the last check etc. to reduce the need for further collision detections (just one possible technique).
    * object selection in loops not sufficiently narrowed/focussed, resulting in unnecessary processing of objects which for which no processing is required.
    * costly loops running more times than necessary, increasing the burden on the runtime

    So, there is an awful lot that can be done to improve the efficiency of your MFA. The simple truth is that MMF is doing exactly what you've programmed it to do here and due to the sheer volume of costly operations it is inevitably slowing things down. Any language/environment (Unity included) is susceptible here, if you overburden it with unoptimised code. No matter how clever or sophisticated the interpreter, runtime or compiler may be - there is not one in existence which has psychic powers and to that end MMF simply cannot be expected to guess where to optimise your logic and routines.

    All that said however, I don't disagree that there are areas where MMF could and should be more efficient, nor that there could be optimisations in many places... MMF3 simply wouldn't be on the cards if that weren't the case. In this case however MMF was performing well in my opinion under the circumstances. All too often I see people blaming the tool rather than the workman - but then again this is hardly unique to MMF users!

    I just want to make clear that what I've said is in no way intended as a personal attack or anything of the sort, just a clear and methodical analysis of some programming for Blue66 and everyone to learn from. Programming is ALWAYS a learning curve (how steep depends on your experience of course). I am always discovering new tricks and techniques and no matter how well I think I have done something, it's almost certain that there's a better way! but a lot of this comes down to your style and what you learn by doing things the hard way - it's all part of the process and evolution of it and for me at least, it is what keeps programming fresh and interesting

  4. #64
    Forum Moderator Fusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleSWF Export ModuleXNA Export Module
    ProdigyX's Avatar
    Join Date
    Jan 2011
    Posts
    1,197
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    +9001 to Simon.


    This is for you Simon.


  5. #65
    Clicker Fusion 2.5 DeveloperAndroid Export ModuleSWF Export ModuleXNA Export Module
    Fusion 2.5 (Steam)
    Mathias's Avatar
    Join Date
    Jun 2006
    Location
    Copenhagen, Denmark
    Posts
    1,083
    Mentioned
    9 Post(s)
    Tagged
    0 Thread(s)
    Since most people have no idea what goes on behind the scenes with MMF, I hope to shed some light on the issue - I did write a runtime after all.

    The problem is not rendering, memory allocation, or all the other buzzwords that seem to have come up in this thread - those things can be done very quickly. Most problems stem from people not knowing what MMF actually does with events.

    MMF's biggest problem is iteration, especially with the way objects are implicitly selected. Since evaluation of expressions are not compiled to native code, any sort of iteration that includes both objects and evaluations can be a big performance hit. I know the Windows runtimes have highly optimized assembly code to do evaluation and to handle the selected object list, but in some cases, it's not enough. That's why e.g. ForEach makes object iteration faster. Consider the following example:

    Code:
    Always
        Spread value 0 in Alterable A of Object
        Start Loop "do_iteration" Count(Object) times
    
    On loop "do_iteration"
    Alterable Value A of Object == LoopIndex("do_iteration")
        Add 1 to Alterable B of Object
    If we had say 50 objects, this would lead to 50 + 1 + 1 + 50 + 50 * 50 + 1 evaluations. 50 evaluations for the 0 in 'spread value' (yeah, it has to iterate objects in case you did something like "Spread value Alterable B + 1 in Alterable A"), 1 for the "do_iteration", 1 for the Count expression, 50 for the "do_iteration" loop string comparison, 50 * 50 evaluations for the LoopIndex expression (it has to iterate and evaluate all the objects every time), and 1 evaluation for the Alterable B addition. 2603 evaluations to perform a single action on 50 objects! Wow.

    However, using ForEach:

    Code:
    Always
        Start ForEach loop "do_iteration" for Object
    
    On ForEach loop "do_iteration" for Object
        Add 1 to Alterable B of Object
    This gives 1 + 50 + 50 evaluations, 1 for the "do_iteration" string, 50 for the "do_iteration" comparison string, and 50 for the "1" in the Add alterable action. 101 evaluations! That's something like 3.9% of the number of evaluations for the iteration above. Offloading the work to extensions where the object comparison can be done explicitly and faster is obviously a big win.

    This problem gets worse as you add multiple event groups with alterable value checks for any triggered condition. Example:

    Code:
    Start of Frame
        Spread value 0 in Object1
        Spread value 1 in Object2
    
    Always
        Start ForEach loop "do_iteration" for Object1
    
    On ForEach loop "do_iteration" for Object1
    Alterable A of Object2 == Alterable Value A of Object1
    Global Value A == 1
        Add 1 to Alterable Value B of Object2
    
    On ForEach loop "do_iteration" for Object1
    Alterable A of Object2 == Alterable Value A of Object1
    Global Value A == 2
        Add 2 to Alterable Value B of Object2
    
    On ForEach loop "do_iteration" for Object1
    Alterable A of Object2 == Alterable Value A of Object1
    Global Value A == 3
        Add 3 to Alterable Value B of Object2
    With 50 Object1 and Object2 instances, this would give something like 7951 evaluations, not counting the spread value actions. This means that the more intricate object iterations you make, the slower your game will be. (hint: the Global Value A comparison could be placed elsewhere to make it faster, but it was just an example)

    This is the sort of coding style MMF tends to advocate for; it's not obvious to the casual user that this will take a major performance hit. In comparison to typical programming languages, you would instead make multiple checks/actions in an object iteration, and it would be fast and easy to write (it would be stupid to repeat the object iteration). MMF, on the other hand, comes with this implicit performance bottleneck in the way it's designed to work. To be fair, there's not much that can be done about it while the existing concept is kept (something for MMF3 hey?).

    If I had to return to Blue66's original post, MMF cannot use multithreading. In fact, most games do not use multithreading, mostly because making the threads work faster than the singlethreaded sibling is hard, and synchronization is a bitch. Some 3D games do take advantage of threads, where vertex data generation can be delayed ala MineCraft, but for MMF, it would NEVER be a viable solution. It would probably make it slower even!

    One way to make MMF faster with the existing approach (the naive approach really) would be to compile the events to native code. This could be done with LLVM as a JIT or at build time. However, this would be a major change from the current system, so it would be something CT would defer to MMF3.

    I did write a prototype MFA/EXE -> native Python code converter (no, not Anaconda, this was another project - Anaconda is mostly written in C++), and it worked pretty well feature-wise. Python turned out to be too slow for doing something like this though, but making a MMF -> C++ converter should make the result a lot faster than the status quo.

  6. #66
    Clickteam Clickteam
    Simon's Avatar
    Join Date
    Jun 2006
    Location
    UK
    Posts
    2,670
    Mentioned
    60 Post(s)
    Tagged
    3 Thread(s)
    Nice post Mathias It is not obvious how the "magic" behind the scenes works, I agree entirely there and you'd certainly know more about that than most people! One thing that is crystal clear from this thread is the information, tips and tutorials that we have could be better organised and more accessible so people can learn more about improving efficiency and so on - without needing to know all the gory details of course!

  7. #67
    Clicker

    Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleSWF Export Module
    Konidias's Avatar
    Join Date
    Aug 2009
    Posts
    1,546
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    I just wanted to post another example of MMF being able to handle a lot if done properly:



    Here's a snapshot of a game I'm developing. You can see there's 515 objects in the level and a whole ton of active object blocks there of all types. These blocks have collision checks, constant gravity applied to them, and lots of conditions and actions involving them.

    Now take a look at the bottom left number. That's my framerate. Maxed at 59-60fps solid. Now when I first started working on this game, I used fastloops for everything and did things not as efficiently as possible, and the end result is that I couldn't even get 50 blocks on the screen without the framerate slowing to a crawl. After I switched to ForEach and optimized things to only get checked when absolutely necessary, I shaved it down so much that now I haven't even hit a framerate issue when stress testing it.

    I hope this and what Simon has posted helps people to understand that it's totally possible to do some heavy loaded stuff without any framerate hits. Just need to make sure you optimized properly.

  8. #68
    Clicker Fusion 2.5 DeveloperAndroid Export ModuleiOS Export ModuleMac Export ModuleUnicode Add-on
    Fusion 2.5 (Steam)Fusion 2.5 Developer (Steam)Android Export Module (Steam)HTML5 Export Module (Steam)iOS Export Module (Steam)Universal Windows Platform Export Module (Steam)
    AyreGuitar's Avatar
    Join Date
    Jan 2011
    Location
    Wales, UK
    Posts
    1,113
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Simon - I noticed from your post that Blue66 is using loops with names like "xPopCowboy". Not sure if it's still the case, but I remember reading years ago on these forums that the longer the loop name the longer the time it takes in matching it for 'On loop "xPopCowboy"' conditions - so using a different name like "x" might give some speed improvement (of course it makes the code less readable). Not sure if this extends to ForEach too, would be nice to know.

    This is actually shaping into a nice thread for optimisation tips!

  9. #69
    Clicker Fusion 2.5 DeveloperFusion 2.5+ DLCAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleUniversal Windows Platform Export ModuleSWF Export ModuleXNA Export Module
    Outcast's Avatar
    Join Date
    Jan 2011
    Location
    Sweden
    Posts
    3,157
    Mentioned
    9 Post(s)
    Tagged
    0 Thread(s)
    Yeah nice read I say again, it would be extremely useful to have some sort of optimization "wiki" where these things can be learned. I think it would be an invaluable resource. There could also be example mfa:s of these methods used, for example an example that runs the same events with regular loops and the foreach object to show how much faster you can do things and how to do efficient collision detection with groups that are disabled and so on.

  10. #70
    Clicker Fusion 2.5 DeveloperAndroid Export ModuleHTML5 Export ModuleiOS Export ModuleSWF Export ModuleXNA Export ModuleUnicode Add-on
    Fanotherpg's Avatar
    Join Date
    Jul 2006
    Location
    High Wycombe, Buckinghamshire, UK
    Posts
    3,665
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks Simon and Mathias for your input. I agree that Blue66 might not fo a lot of optimisation, but hoe many people really are interested to look under the sheed to see how everything works. I learnt lot during last few months I haven't know at all fir years using MMF (better help file please) and such optimisation Wiki might be interesting.

    But is it really his fault? Or rather design choice, on both ends and CT and end user. Simplicity comes with costs.

    Anyway the lenght of loops names is still taking on account as it first does string comparison in the list of loop names to find all events we are looking after thus code deactivation is so vital.

Page 7 of 14 FirstFirst ... 5 6 7 8 9 ... LastLast

Similar Threads

  1. Replies: 10
    Last Post: 15th October 2012, 05:33 PM
  2. How can I improve screensaver performance on Win 7
    By RGBreality in forum Multimedia Fusion 2 - Technical Support
    Replies: 0
    Last Post: 10th November 2010, 09:03 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •