Posts by casleziro

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.

    so we would have 2 "trigger" actions, and 1 "continuous" action: on begin overlap, on end overlap, and while overlapping.


    the biggest advantage of this would be performance. one of many potential use-cases for this: player collides with the trigger zone of an enemy. on collision start, the enemy flag "track player" gets set to TRUE, which causes the enemy to run some expensive pathfinding AI. as soon as the player leaves the trigger zone, set flag OFF. would not need to continuously check for overlap each frame with this setup.

    I'm not a huge fan of transitions, mostly because it pauses the entire frame when their happening, would be possible to add a "Freeze the app while happening" toggle?
    Been working with this project and got it with lots of transitions, had to replace all that with custom ones because of the freeze lol

    i agree, more modern interpretation of game transitions would be great.

    also, a feature request for clickteam: we already have "on object collides with object". would it be possible to get "object stops colliding with object"? so we would have 2 "trigger" actions, and 1 "continuous" action: on begin overlap, on end overlap, and while overlapping.

    bullet hell bullets are usually circles, right? not squares. a circle to rectangle check is really performance-friendly, since it is only a single distance check. you can easily have a few thousand of these with full framerate, no sweat. i made an example for you. make sure your player rectangle is cropped so there's no empty space, and manually set the collision radius of the bullets in their values.

    [MENTION=19022]Janette5[/MENTION] no need to run loops to compensate for delta time unless it's something that must be calculated each and every missing frame. For most things, such as running regular fastloops each frame and modifying acceleration values, you can just multiply by a value that takes into account framerate differences. I use (1.0/framerate)/(1.0/target framerate), so if my target is 60, it returns 1 if current framerate is 60, 2 if 30, 0.5 if 120, etc.

    [MENTION=8839]SergioAndre[/MENTION], i'm not sure if this will help you, but I made this so that the sun will always rotate 360 degrees over a specific time, and always at that time even if your framerate is different. For example, setting DLength to 60 when your target framerate is 60 means it only takes 1 second for a full rotation. My example uses a time of 600, so a cycle takes 10 seconds. You might be able to clamp the sun's angle after, and check if the "clock" angle is between the angles you deem as "night", then adding a multiplier to TSpeed if you want shorter nights, etc.

    you could take screenshots frame-by-frame of the effect looking as you like (the bottom here) and cut it out, turning it into the new version of that effect.

    I guess an alternative might be to clone that effect, turn it a solid color (with no shader effect), then always order it underneath the original if you don't feel like cutting it out.

    Looki's Background Offset shader. It takes the red and green color values out of whatever image you apply the shader to and modifies the position of the background behind it, kind of like a special lens. By different colors I mean instead of using red or green (which the shader offsets the background with, Red for X Green for Y, this can be found in this shader code itself) I used blue and fuschia. For example, when the shader works as it says it should, the image for a distortion effect might look something like this:
    Please login to see this attachment.

    but using this, it will either blur horribly like the image in my first post, or do nothing at all, seemingly at random. Tinkering around, I managed to get it to work as intended (smooth distorted background) using an inverted version of that image, which makes no sense considering how the shader originally works (supposed to only use R and G values to change background):
    Please login to see this attachment.

    And the shader worked properly when it came out quite some time ago, so I imagine something changed in fusion builds that affected it.

    The shader file i'm using is the updated one converted to DX11 by pixelthief, which can be found in the "converting shaders to dx11" thread. The problem existed in the old dx9 version of the shader too, at least for me and a few others.

    [MENTION=10153]NaitorStudios[/MENTION], I see. If you know how this could be done, let me know. I did not see anything to change that affects the amount of 'samples' within the shader.

    What's curious however is I seem to have fixed the problem by using different colors than Red and Green, which the shader is supposed to use and is even referenced in the code.

    Using (blue 0,0,255) and (fuschia 255,0,255) causes it to work correctly; at least on my main and secondary machines.
    Please login to see this attachment.

    I remember a while ago (6 years, in fact; time sure does fly) posting about an issue with the Background Offset shader blurring horribly, even with a simple pure red/green stripe:

    Please login to see this attachment.

    As far as I'm aware a few other shaders also did this (some out of the photoshop pack). Is there any fix to this? I recently came across a situation where i'd like a nice "underwater distortion" effect and while 2 perspective objects layered work, it's an ugly solution. Thanks.

    EDIT: a lot of shaders seem to not work with "premultiplied alpha" checked?

    use the embedded collision detector tutorial to detect collision with static objects (such as backdrops). don't use this for moving objects, however; for moving objects you will need to use math. I made an example of circle/rectangle intersection a while ago. this is the method you should use, but perhaps scoped to only objects on-screen for performance.

    Combining these two methods will let you use a single object such as your character sprite.

    Use an alterable value called MoveAngle_ or similar and replace every instance of the Zombie's actual angle in the code. Then you could select your iso animation directions using MoveAngle_/11.25 so the zombies look in the direction they're moving.

    Keep in mind that a circle will probably make the movement look best, so consider leaving the zombie's collision as a circle without changing how the code works, and adding the graphic as a sprite pinned to it.

    640x360 is the most flexible resolution for 16:9. It scales in multiples easily to all major resolutions:

    640x360 1x
    1280x720 2x
    1920x1080 3x
    2560x1440 4x

    etc.

    In the event of an odd resolution, you would default to closest multiple base resolution, then just stretch out the borders of your window without changing the scaling. Some graphics outside of the regular play area would make this look natural. Here's an article about how ludicrous did it: Please login to see this link.

    It's for unreal 4 but the same idea could be used in fusion.

    Would it be feasible to use something similar to boids to handle zombie groups? Only without the flock "cohesion" effect?

    There's a video here about the concept with info in the description: Please login to see this link.

    And I believe there is a fusion extension called "Flocking" that implements this here (not sure about obstacle avoidance): Please login to see this link.