Posts by Anders

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    Volnaiskra: List view: The small button at the left of 'Frame_1' with the '123' icon is the one that toggles the global "Event list mode".
    Clicking it again turns the list back into the pr-line mode :)

    About where Fusion3 stores files: If you don't want to then you don't have to worry about where F3 saves game files. It will simply store files you use in F3 inside it's hierarchical folder structure that makes up your projects. For the runtime you can have files laid out loosely or packaged into file bundles (separate resource files).
    More information on how that will work will come later as we feel we are ready to share that information :)

    A couple things:

    1) I couldn't get the pinch to work until I removed the extra conditions in the 'A pinch is active' event. The Min/Max expressions should prevent the values from getting out of the range but if they somehow did you actively prevent the code from correcting this.

    2) When you start a pinch you need to find out a "pivot point" of sorts - a point where the zooming scaling will originate from. If you simply use the XMouse/YMouse unmodified you end up having the objects jump when you start pinching. So when the pinch is started your "pivot point" should be the center point between the two fingers which you have to figure out yourself : (first touch position + second touch position)/2

    So to scale and position objects you first subtract the pivot point position from the object's orginal coordinate (I think you store this in Alterable Value X and Y), then scale and then move back to the pivot position.
    Basically in pseudocode: (originalPosition - pivot)*scale + pivot

    I'll see if we can make it an option.
    If you want to manually disable the un-premultiplication step that slows it down you can do it here:

    In XCode open up "Extensions/CRunpica.m" and find line 330:

    [newImage unpremultiply];

    and outcomment it like this:

    //[newImage unpremultiply];

    That will stop the image from having the unpremultiply step and it will be fast again for you.

    Clickteam Fusion's standard "List object" has the option to display as either a TableView or a PickerView type list on iOS which is what you are looking for.
    It is very simple though, it only shows the text from that line and nothing more.

    In general the default user controls like buttons and checkboxes will automatically look native.

    I don't know if there is a JSON object ported to iOS at this point but you can always extract simple data from it using the StringParser extension. Otherwise you can easily just get the contents of the list file from the web and populate the list with that. The 'Get object' can easily download files like that from the web.

    It should work just fine on iOS. The Windows runtime doesn't have this implemented yet sadly.

    If you have an example file of it not working I would be interested in taking a look at it. Can you put it in the bug box?
    Thanks.

    The Fusion2.5 runtime is only single-threaded. Making a game engine multithreaded is a huge task as every game is different and can only benefit a certain amount from being multithreaded.

    Many tasks are not in their nature parallelizable as all the work done depends on previous work.
    Parallelization comes into play when you can start many similar tasks that doesn't depend on each other.

    The iOS in-app object is more or less a direct interface for the Apple iAP framework.
    Apple does not want to force a specific user-interface on the user for in-app purchases and leaves that responsibility with the developer so they can style the store as they want.

    A way to make the store easier to use is to put it in a frame for itself and then open it up in the levels using a modal subapp. That way the underlying game will pause and only the store frame will run.

    For the next release of the runtime the INI handling of the runtime has been reworked so all changes in one frame is immediately carried over the other frames that points to the same INI file. This makes it useful for carrying over the information to the main frame that something has been purchased in the store frame.

    Actually that doesn't look like it reloads the images all the time. It just shows that the initial time spent loading the frame is skewing the statistics a lot. Playing the frame for a longer period of time without changing frames will make more accurate statistics.

    I see in the graph that there is a place where it spends a lot of CPU time. What frame is that? Any chance I can profile this game myself?

    It seems it spends a lot of time unpacking compressed data from the .cci file.
    Any chance you can expand the top item on that list "NSData(NSDataExtension) zlibinflate" to reveal where it does this the most? Expanding it down a few levels into the hierarchy would be helpful.

    There can be a number of causes for this but the most likely one is that your app constantly load some image resource from disk - and that can again be caused by a number of things:
    - You manually do it in your events
    - Your app consumes too much memory and is given memory warnings from the iOS operating system.

    When the app receives a memory warning it attempts to free as much image data from memory it can.
    When the image resource is needed again (for drawing on screen) it will be reloaded from disk.

    If you app in general consumes too much memory it goes into this bad cycle where it loads a lot of resources, gets a memory warning, unloads all resources - only to reload them again almost immediately.
    As you can see this is very power consuming but it is necessary or the app will be force-closed by iOS and will look like a crash.

    Your only way to fix this is reduce how much memory you are using.

    If you want I can profile your game more in-depth to figure out exactly where the problem lies.