Done in next update.Quote:
Originally Posted by SHINBAXTER
Printable View
Done in next update.Quote:
Originally Posted by SHINBAXTER
Sorry, I might have missed that, thanks for the answer tho!
BUG?
"Animation is over" condition is not triggered if use the movement type of "Movement extensions(e.g. Vector, Sinple elipse)"
is there a way to get the number value of how many frames an objects current animation sequence has? i can't find it anywhere.
i recall many users asking for this years ago, was it ever added somewhere?
otherwise is it possible to be added, maybe like this :)
Animation Info object can get it, but only for the current animation, and Windows only.Quote:
Originally Posted by SHINBAXTER
if you remember, i work mostly on mobile ;DQuote:
Originally Posted by Phi
Another improvement that could be realy interesting but probably complex to make is a real viewport management in runtime.
This could help a lot to make split screen multiplayer games and even make non-destructive real zoom with simplicity.
Currently making a working split screen for a complex game is a nightmare. I personaly cancelled my multiplayer project because of the complexity to make decent split screen (and also to make network playable game, but this is another subject).
Zoom are also not easy to do. Some effect can be done with shader but with this way, zoom will pixelate content and will won't be usable under 100% level of zoom. Another workarround is to zoom all objects and move them programatically but it's still not alway easy to manage it.
Real viewport can be helpfull for theses kind of usage.
Maybe the more quicker way to allow easy splitgames could be this :
I seen an interesting extention for that named "Viewport" made by Anders Riggelsen (Andos)
But naturaly the object can't display content out of the main windows. I don't know if an option in the frame to "allow rendering of the entire frame" and not just the current windows size could be added and could work with this extention but maybe this kind of option combined with the Viewport extention could open the way to make split screen game if it's work.
Thank you for all !
Allowing the rendering of the entire frame would definitely slow things down...
Cause all this processing would go into the GPU, you seeing it or not.
But perhaps Clickteam could add a margin, something that will still render, but not the entire frame, would make zoom out a whole lot easier.
I honestly would prefer a better control of app resolution through Window Control object.
Currently you cannot toggle "Resize display to fill window size", I even made a small extension for this, but it gets reset on frame switches, like it changes per frame although it's a app property.
So I did a few tests of toggling it and trying to switch the fullscreen app resolution on the go. (all of this to simulate the "Fit inside and adjust window size" from mobile, adding support to different aspect ratios)
"Resize display to fill window size" is important for window mode, so you can resize the window and such without showing more of the frame.
But for Fullscreen you have to do something odd... You have to go windowed, change the window resolution and instantly go back to fullscreen, allowing it to show more or less of the frame depending on your aspect ratio.
Problem is that once you switch frames this is lost, so you have to go windowed again and repeat the process.
If it was just this, it wouldn't be too bad, but there's also another problem...
Within the logic of Window Control object (or some other part of Fusion) something prevents it to set it certain resolutions depending on the default resolution, it just doesn't make sense to me...
You can go lower, you can go higher, but certain resolutions will refuse to work, it reports the resolution you set, but it shows the default resolution or the last one you set before.
So I think this part could be improved, of course I'm talking about a workaround, but the ability to just allow the fullscreen app to automatically resize the window to fill up the black bars would be awesome.
Meaning a game running on a 4:3 monitor could crop the sides or perhaps show more above and bellow (although cropping the sides would be easier to work with)
A game running on 21:9 would resize the window to fill up the sides, showing more of the frame.
The expressions for getting screen edges should also reflect this change so people can anchor UI elements accordingly.
Anyway, I was trying to make a extension that does this, but of course I would need to figure out how to bypass certain limitations, which I'm not sure if it's on Window Control or Fusion itself.
And since my PC burned with the lightning strick I can't do much right now...
I'm not sure if I totally understand what you mean, so maybe the fix you mention will fix my issue too. I don't think it's the same thing, though as I say I'm not sure. However, when you say that the margin is not in "visible" pixels but frame coordinates, that almost sounds like the opposite of what's actually happening to me. Because in my experience, the frame coordinates that are actually reachable will depend on zoom level - almost as if Fusion is ignoring the frame coordinates and just cutting off the margins based on visible pixels.Quote:
Originally Posted by Yves
Either way, I think the following GIF should illustrate the problem I'm having:
https://s10.gifyu.com/images/mmf2u_mjNBqbKG6i.gif
-The margins in the above example are set at x=5000px, y=5000px (the frame dimensions are x=10000px, y=7000px). The tall purple mushrooms are placed at about -5000px, so that they should be about half cut off by the westmost margin.
-At 100%, 200%, 300%, and 400%, the Frame Editor correctly cuts off the frame at -5000px (in the middle of the purple mushrooms).
-At 75% it cuts off at -6667px (I checked it, though didn't show it explicitly in the gif)
-At 50% it cuts off at -10000px (I checked it, though didn't show it explicitly in the gif)
-At 25% it cuts off at -20000px (you can see this in the gif, where I demonstrate that I can scroll much further westwards than the purple mushrooms).
-The same pattern as above happens on the eastern margin too (at 100% the east margin stops correctly at 15000px, at 25% it stops at 30000px)
If my math is correct, that means that with a new zoom level of 10%, the frame editor will now cut off at -50000px, which will make it even harder to find my actual content, as it'll produce 45000px of 'dead space' between the westmost margin and my content (most/all of which will be eastwards of -5000px, since that is the intended margin of my frame, and that is the only area accessible at 100%-400%)
Just tried with a Vector movement, apparently this condition is triggered.Quote:
Originally Posted by ASD