Posts by happygreenfrog

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!


    Well, it partially depends on whether or not you want decent performance, especially on mobile devices. If you want decent performance, then with Construct 2 being based on HTML5 and all, I wouldn't expect it to get you the same performance as Clickteam Fusion 2.5. However, if performance isn't a concern, Construct 2 would admittedly have some pretty serious advantages.

    However, I think the main reason that nobody here is responding is that most people here are a bit too busy making their own games... FYI, I probably won't be able to help make the game either, given how many games I'm already working on, but I thought I'd at least tell you the likely reason for the lack of responses, and answer your question about Construct 2.

    Lacewing was technically ported to Flash, but it's completely b0rked in CF2.5 for some reason. That's something I personally would also like fixed.

    As for HTML5, well, I've heard that Lacewing in particular for online stuff in HTML5 would be impossible due to the limits of HTML5 itself preventing the Lacewing protocol from being implemented in it.

    I personally don't have severe performance issues when using the physics object, even on already-laggy runtimes like Android (though I am trying to handle my levels in a way where it only loads small level segments instead of a full level all at once). However, I am using one of the beta versions of CF2.5 if I remember correctly, so that may have something to do with it, though I don't believe it was the latest beta.

    Actually, I've noticed that it can find the path instantly, though that may be because of the map size instead of it simply being a quick process. Also, where does the example use strings? If you mean those numbers all over the grid, then those can be deleted. It's actually using the arrays to handle that stuff without the string objects. Those are just to give you a visual representation of the "path finding map" (so to speak). Also, MuddyMole is the one who made the example that stores the path as a string, not crusher, and I linked to crusher's example, so if you downloaded MuddyMole's example, then you should instead look at crusher's example. If you are talking about MuddyMole's example, then yes, that isn't designed to handle multiple objects, so yes, it will run slow with multiple objects. However, crusher's example seems like it would work well at finding multiple paths at once, and be able to do it without lagging too much at that. As a matter of fact, thanks to the way it works, the "path" technically doesn't need to be found at all. To get the pathfinding done, you instead simply have each object look at the surrounding tiles, and then pick the one with the next number in the sequence. Then it won't find the whole path all at once, which could improve performance, especially in situations where the path can change (such as a tower defense game).

    EDIT: Also, I have two screenshots that prove two things:

    1. The pathfinding object is buggy (they did eventually find their way around the turrets, but it took them a while, and yes, I did highlight the area where this was happening):

    Please login to see this attachment.

    2. Your example doesn't support 2000+ objects at 60 frames per second either, so it doesn't matter whether or not the example I listed does (though it might just be because the debugger adds a little extra lag. However, you didn't give me any way to see how many objects were on screen at once without using the debugger, so that probably means that is how you were looking at the number of objects yourself):

    Please login to see this attachment.

    Neither of those extensions are multi-platform, but they are more likely to get ported to other runtimes since they are newer. I personally have found those other pathfinding extensions easier to understand then the original pathfinding object, just so you know. They, in my opinion, were better-designed, and they were designed with multiple objects at once in mind. As a result, I think it is more ideal to either port one of those two objects to other runtimes, or to make a new pathfinding extension, specifically designed with being cross-platform in mind.

    EDIT: Also, why make an extension for something when people have already made a cross-platform version of it without extensions?: Please login to see this link.

    There have been much better path finding extensions released since then. The original path finding object is terrible in comparison. For example, there is this one: Please login to see this link.

    And here is another one, which is essentially a direct replacement for/sucessor of the original path finding object, though it requires the .net framework for whatever reason, making it less likely to get ported to other runtimes than the other one I mentioned: Please login to see this link.

    The math is kinda simple, actually:

    X = <insert screen width/2>+((3D X-CameraX)/(Z-CameraZ))
    Y = <insert screen height/2>+((3D Y-CameraY)/(Z-CameraZ))
    Scale = Z-CameraZ

    The reason you divide the X and Y by the Z is because that will make the object move closer and closer to the center of the screen as they get further and further from the camera (it's also why you add the screen width and height divided by 2 to the X and Y). The Z is the distance from the screen, BTW. The 3D X and 3D Y should be stored as alterable values, BTW, and the same goes with the Z. This is the basic idea, anyway. It's actually also something along the lines of what you would do to use the surface object's polygon drawing feature to make colored (but not textured) 3D polygons. If it doesn't work, then let me know, and I'll try to see where I went wrong with the math (I learned the math from SEELE's article on 3D in MMF2, though I might not be remembering it perfectly).

    SEELE has made some quite nice 3D examples in the past. One of them was without extensions or anything like that, and it was a star field of sorts, if I remember correctly. I don't have it on this computer, but I remember that it exists, and that it proves that it is possible using only active objects. I could also probably make such an example, though I won't be able to do that right at this moment.

    Erm, MMF2 has built-in support for playing sounds (using the "play sample" action under the sound object). What sound format do you have in mind? MP3? If so, don't use MP3, since it has an expensive license for usage in anything. OGG is good, from what I've heard, though I personally use WAV files.

    I need a extension for a custom main-resolution. My problem is, I have a game with dynamic main-resolutions and stretching.

    The player change the resolution in the game-options to 800x600. The game startet now on main-resolution 400x300 and streched up to 800x600 (double size). This works perfectly.. but change the player the resolution to 1024x768 is the main resolution (512x384).. and this don't work anymore.

    Here my example to see the problem:
    Please login to see this link.

    The best example what I need you can see here (download the game and see the custom resolutions):
    Please login to see this link.

    Have you tried Ultimate Fullscreen yet?