Posts by PkR

I'd like to report an issue affecting window scaling on nVIDIA cards.

If you have "resize display to fill window size" enabled and use the Window Control Object to scale the game's window by 2x, 3x etc., the resulting picture won't be pixel perfect. It seems that the inner window (rhHEditWin) is being filled or resized incorrectly. When it happens, it also affects stuff like Ultimate Fullscreen etc. To work around this, I've been adjusting the game's inner window manually using code in an extension like this (param1 is integer scale value).

HWND subwindow = rhPtr->rhHEditWin;
scaledX = MV->mvRunHdr->rhFrame->m_leEditWinWidth * param1 - (param1 - 1);
scaledY = MV->mvRunHdr->rhFrame->m_leEditWinHeight * param1 - (param1 - 1);
SetWindowPos(subwindow, HWND_TOP, finalPosX, finalPosY, scaledX, scaledY, SWP_NOOWNERZORDER | SWP_NOZORDER);

This chops off pixels on the bottom and on the right but the picture becomes pixel perfect.

The issue does not happen in DirectX 11 mode or on GPUs other than nVIDIA (as far as I can tell). Because of this, I had to add a toggle in my game and implement a test to tell whether the player needs the fix or not (if the fix is applied when it's not needed, it introduces the same issue it's meant to fix).

Additional info, including an example MFA and a workaround, is available here: Please login to see this link.

The original SDL Joystick extension has been updated to version 1.65.

Download: Please login to see this link.
Help wiki: Please login to see this link.

-The object is now compatible with sub-applications.
-Updated SDL2 to 2.28.1. I'll consider the switch to SDL3 once there's an official release.
-Updated the "Load GameController database" action to reset the SDL library before loading new mappings to make sure they are actually used. I'll try to figure out a better solution eventually.

Quote from SirEatAlot

The ps4 controller touchpad pressed state is not recognized, cant tell if problem is in sdl itself or the extension but thought I'd let you know. It worked in previous versions.

Sorry for the late response!
Not sure about this one, but try the latest release which comes with the latest stable version of SDL2. Maybe it was fixed. As far as I know, there's a 'touchpad button' that works as a regular button so it should be supported. There's also a lot of other touchpad-related functionality in SDL but currently I have no plans to implement that.

Quote from SirEatAlot

Also for ps4 controller, hat0 (dpad) is not recognized, the dpad button IDs work, but hat0 does not.

That seems like a controller mapping issue. Might also be specific to SDL itself since the D-Pads on my controllers work fine. Unfortunately I don't own any Playstation controllers to tackle this directly.

Quote from SirEatAlot

Is loading a game controller database file needed on every frame, or is it enough to do once and it will keep in memory over frames?

You only need to do that once, ideally at the start of your application.

Quote from SirEatAlot

Also is loading a game controller database file needed to recognize most common controller types or will they be recognized by sdl framework anyway?

As far as I know, SDL comes with a mapping database by default, so you only need this for custom mappings or rare controllers.

Quote from Progject

This is great, but one of the (quite many) reasons I jumped ship to Godot (which is 100% free!) was the lack of controller support - why hasn't this been a priority for Clickteam to resolve with a supported built-in solution? Isn't "stable support for a modern controller for video games" deemed important for a game engine?

Since the extension is open source and there are no license terms other than SDL's, Clickteam could make an integrated solution, though they might need to rework the code. As for Phi's version going paid and closed source, well, I kinda saw it coming. Anyway, the original version will remain free and open source. While I cannot promise a lot of features and support, the development should pick up a little because I am now using this extension in a game.

Still an issue. I've tested it on several devices and it seems to only happen on nVIDIA GPUs. Although NaitorStudios' workaround helps, this quickly becomes complicated to support. Please consider fixing this in the runtime.

Will have a look, appreciate it.

It does seem to work, thank you for the workaround. I hope Clickteam figures it out on the runtime's side, seems like an extra pixel is added with each multiplication?

Hello, since the bug box isn't working I'm posting here. When "Resize display to fill window size" is enabled, display size isn't scaled correctly even when the resolution is suitable for integer scaling.
The issue only happens in DirectX 9 mode. DirectX 11 mode appears to scale properly without artifacts.

Example MFA:
Please login to see this attachment.
Artifacts in DX9 mode at 2X:
Please login to see this attachment.
No artifacts in DX11 mode at 2X:
Please login to see this attachment.

This was reported back in 2016 and is still an issue. Original thread:
Please login to see this link.

Please look into fixing this, thanks for your time.

EDIT: Related Please login to see this link.

I updated the original version of the extension, which you can download here: Please login to see this link.
Help wiki: Please login to see this link.

Changelog:
-Rewritten with Fusion 2.5 SDK.
-The extension is now built for Unicode.
-Added support for basic rumble.
-Added debugger functionality (it's like a limited version of the example but available straight in the debugger).
-The SDL library stays in memory when the object is destroyed, and is unloaded only when the application ends. This allows for better input detection across frames.
-Added support for the GameController interface, a Game Controller check condition and an action to load controller mappings from a file. See the wiki for more information.
-The project is now compiled as Multi-Threaded by default. This allows for the extension to run without Visual C++ runtimes installed at the cost of a larger .mfx file.
-SDL2.dll is now registered as the extension's dependency. As a result, you don't need to worry about loading it manually, but you have to put SDL2.dll in Clickteam Fusion's main folder and in the Data\Runtime\Unicode folder. This should hopefully fix all the instability issues that affected earlier versions of this extension. When you build the application, SDL2.dll will be included in its executable automatically (you can use "Unpacked EXE" in application properties to have the DLL separately).
-Fixed broken conditions related to pushed and released buttons.
-Some failchecks have been added to prevent potential crashes.
-The object can now have Alterable Values, Flags and Alterable Strings.
-Updated documentation and example. Replaced the .chm file with a link to the wiki on GitHub.

If you run into any bugs please let me know.

Thank you for the reply. From your response I was able to gather the following:

1. Other than ease of use and less clutter in the editor, there's no real difference between having Global Events and not having Global Events and just pasting those events in each frame.
2. Events in "Include another frame" are duplicated for each frame, however objects are stored as pointers.
3. Graphics are not duplicated.

Out of curiosity I made a quick test with two MFAs that had a frame of about 50 objects and ~1200 events. In the first MFA I added 20 blank frames. In the second MFA I added 20 blank frames and set them to include the frame with 50 objects.
Here are the results:
Compiled EXE
Original: 1.97MB
Include: 2.37MB.
With the Unpacked EXE option:
Original: EXE is 938KB, DAT is 419KB
Include: EXE is 938KB, DAT is 835KB

Better than I thought, hopefully it will manage similarly when there's more stuff in the main frame...

Sorry for going slightly offtopic, but this bit caught my attention and I wanted to confirm something about the way Fusion works.

Quote from NaitorStudios

Make some "Never" events in Global Event Editor with random conditions like Compare Two General Values comparing a emoji or some Japanese text to another (these would be copied to all frames automatically).

Is copying to all frames a side effect of using those tools, or is it the actual way Fusion compiles it?

If it's the latter, this greatly reduces the benefits of Global Events. I always assumed that Global Events are only saved once in the file so you could save space by putting code in them. If that's not the case, Global Events are only a QOL improvement rather than an optimization. I think this should be made clear in the documentation.

Does this also apply to "Include another frame"? If I have 100 frames which include one other frame, does this mean there will be 101 duplicates of that frame in the EXE?

How about Global Objects? If I have a 1000 instances of a Global Object in different frames, does it save all 1000 of them, including duplicate animations etc. individually?

Thank you for fixing the missing context menu in the object list.

I was wondering if it's possible to make this description box resizable, or add a tooltip that displays the cut off text on hover?

Please login to see this picture.

I think you might be confusing it with the (slightly newer but also old) Joystick 2 object, which is a different extension.
The updated Joypad object should be version 3.1 in the about dialog, however I don't think it's been updated yet. Since it's not my extension I can't release it on my own, so you'll have to wait until Yves approves the update in Extension Manager.

After trying to create a Windows application that would work with both XInput and DInput controllers I found out that all gamepad/joystick extensions currently available for Fusion (except the HTML5 one maybe, but I needed a Windows EXE version) have major limitations or serious flaws, some of which are documented here: Please login to see this link.. I also found it ridiculous that people have tried to profit from the situation by selling toolkits that simply work around bugs and attempt to make sense of what these extensions offer to the end user. So I made my own extension that uses the SDL2 library to poll input, and I'm also releasing an open-source version of it for anyone who might want to add new features to it.

Please login to see this link. - click on Releases to download the compiled version. In the downloaded source code zip file, the compiled version will be in the ToInst folder.

A few notes:
1) This extension requires SDL2.DLL to be placed in your Fusion main folder and in Data\Runtime\Unicode.
2) The extension was made for personal use. I assume no responsibility for usage of this extension in your projects and I am not obliged to provide tech support. Bug reports are welcome. Pull requests are also welcome and will be merged if the changes are compatible with my preferences. Otherwise feel free to make a fork.
3) Versions 1.50 and higher are compiled with Unicode support. I'm not sure if these versions are still compatible with MMF2.

Hope you like it!

I'm sorry but the solution with the Registry 2 object and relaunching the application is a lame hack that users shouldn't be forced to do. The proper way to make an application report as DPI-aware is to embed a manifest file into the executable declaring DPI awareness, as explained here: Please login to see this link.
In fact, just editing the manifests for all EXE files in Fusion's Runtime folder to include DPI awareness completely eliminates the need to mess with registry for any applications built with it. There's no reason this shouldn't be an option in build settings.

Now the problem with this overall is that most UI controls in Fusion weren't designed to be DPI aware (and Fusion itself isn't either - just look at how Picture Editor's icons look at 150%). So if you build an application that uses UI controls such as buttons or lists, there's a possibility that they will be scaled incorrectly if an application is forced to report as DPI aware. The issue posted in this thread is probably the reverse - the desired positioning of the string appears to have been made for cases when DPI awareness is force enabled like on the developer's PC, while the blurry and offset version reported by the testers is what the "correct" handling of that string is supposed to be, according to Windows anyway.

I would recommend ditching the String object (if that's what you use for the text) for something that scales more predictably, such as a bitmap font. Maybe Text Blitter? I would still recommend to force enable DPI awareness though, because the entire application will be blurry otherwise.

I don't know about this bug in particular, but from my experience the Surface object isn't well optimized for Fusion 2.5. Particularly alpha channel operations are much slower than with an earlier version of the object in MMF2. Maybe you could try using an older version of the object to see if it has the bug?
I tried bringing the issues with the object to Yves' attention, and while he acknowledged the issue I was having, I never heard back from him afterwards. I think they only updated the object for basic DX11 compatibility and the rest is low priority because it isn't obviously broken.

I hope the performance issues with the Surface object I reported here Please login to see this link. are fixed eventually. Surface is a useful object not only for games, but also for GUI tools, and getting it to perform fast like it did back in MMF2 would be great.

Hi Yves,
Here's the surface.mfx file from my pre-update extensions folder.
Please login to see this attachment.
Now that you mention it, I remember what happened when I ran into these problems back in 2016. I originally started my project in MMF2 and upgraded to Fusion 2.5 mid-development. With the version of Surface included with Fusion 2.5 I ran into the crash issue (the one you fixed a couple days ago) so I had to replace "Draw a line on the alpha channel" with "Draw a rectangle on the alpha channel". That worked, but then the performance issue showed up. I ended up using the MMF2 version of the extension, which still has the "Draw a line on the alpha channel" crash issue in Fusion 2.5 (but not in MMF2), but other alpha channel functions work a lot faster in it.
So that's the full story. I guess something was changed in the extension during the 2.5 transition that massively degraded alpha channel actions' performance.

Hi Yves,
Sorry to bother, but could you let me know if the issues with the Surface object described in my previous post are reproducible, and whether there are any plans to update the object to address them? My tool depends on using many instances of this object, and after the update my application is a lot slower than it used to be. I could possibly rewrite it without using the alpha-related actions at all, but it would be a relatively big workaround. I really hope I don't end up switching back to MMF2 because of this.

Indeed I couldn't reproduce the issue either on the latest version. Thank you for resolving the crash, too.

However, the new version's alpha channel actions appear to be much slower than the version I have on my old build of Fusion 2.5. The stuff I do in my project using actions "Draw line on the alpha channel" (that was previously crashing) and "Draw rectangle on the alpha channel" (which I used as a substitute for the crashing one) take almost half a second on my Kaby Lake i7 CPU now. However, before the update the "Draw rectangle on the alpha channel" action was instant in the same scenario.

I have uploaded an attachment that illustrates the issue. The file "surface_fast.exe" was built using the version before the update. The "Draw rectangle on the alpha channel" action works there and is instant. If you build the same MFA in the latest version, the application will visibly freeze for about half a second. In addition, the behavior of the action in this specific scenario appears to be different. Like, the latest version doesn't seem to do anything with the alpha channel at all in the example.

I also noticed that the EXE built with the older version from the same MFA is about 500KB smaller. Is there a way to reduce the EXE file size in the new version?
Please login to see this attachment.
Please login to see this attachment.
I couldn't upload an EXE built with the latest version because it exceeded the forum's attachment size limit.

I noticed that the Surface object has been updated recently. I'd like to point out that the crash I reported with this object back in 2016 is still not fixed: Please login to see this link.. The crash didn't happen in the MMF2 version of the object.
Additionally, I found out that the coordinates for the "Set alpha at XY" action are calculated wrong. If you make an event that does, for example, "Set color at 64,32" and "Set alpha at 64,32", there will be two dots on the canvas with different coordinates.
I was under the impression that the object was abandoned, but since you guys updated it I thought I'd bring this to your attention.

Yeah, unfortunately this action is just too slow to use in real time. What you can do is make clones of your player sprite, do the color replacement when the frame loads and swap between clones during gameplay.

The "Reduce CPU usage when idle" function sounds promising for people who make GUI applications. Thanks a lot!