Posts by PkR

Update: I made a version that breaks at the 1920x1080 resolution, and a user on Discord was able to reproduce it. Here it is.

It seems that for the glitch to happen, the application window must be exactly half the resolution of the screen, e.g. 960x540 if you have a 1080p screen, or 1280x720 for 1440p in my case.

Quote

When you build an EXE, does it have the same issue on your system?

It only happens when I run it from the editor. I don't know what kind of system issue would cause this only in Fusion editor and nowhere else, and only with that combination of resolutions...

Additional info: My monitor resolution is 2560x1440. The issue doesn't happen if I set the desktop resolution to 1920x1080, but it returns when I set it back to 2560x1440.

Quote from Yves

I've tried on several machines, 150% and 200% scaling, no problem.

Do you use the stand-alone version of Fusion? If so, maybe try to re-install the latest update patch?

I installed a fresh copy from Steam just to be sure and it still happened... It looks like this when I run dpi.mfa from the editor.

Quote from Yves

Works fine...

That is unfortunate because it's 100% reproducible on my system... Is there anything else I could share to help isolate this?

EDIT just in case: I'm running Windows with 150% display scaling.

Sure, here it is. I use an AMD GPU if that helps.

Since Build 296 is taking a while, I'd like to report a graphical issue found with Build 295. It would be nice to have this fixed in 296. Here's how to reproduce it:

1. Create a new application.
2. In Window properties, set window size to 1280x720, resize the frame too. Set a background color.
3. Disable "Heading", "Menu bar" and "Menu displayed on boot-up".
4. In Windows properties, enable "DPI aware".

When you run the application from the editor, there will be a gap on the bottom right, and the graphics will be squished. I've only seen this happen with the 1280x720 resolution. 1280x721 or 1280x719 works fine.

A new SDL Joystick update has been released.

Version 2.20 introduces support for gyroscopes and accelerometers. I've added an example that draws graphs based on the device's sensor readings.
There is also support for rumble in triggers (Xbox Elite controller) and some more conditions/actions/expressions.

New conditions:
-Device triggers can rumble
-Device has accelerometer
-Device accelerometer is enabled
-Device has gyroscope
-Device gyroscope is enabled
-Device remapped
-Any device remapped
-Device sensors updated

New actions:
-Rumble (triggers)
-Set player indicator (I couldn't get it to do anything with my X360 controller though)
-Set accelerometer state
-Set gyroscope state

New expressions:
-Get player indicator
-Device USB vendor ID
-Device USB product ID
-Device product version
-Device firmware version
-Device serial number
-Get accelerometer status
-Get accelerometer X, Y, Z
-Get gyroscope status
-Get gyroscope X (pitch), Y (yaw), Z (roll)

SDL Joystick version 2.10 has been released.

- Added support for retrieving battery status
- Added support for setting controller LED color
- Added support for controller touchpads, including multi-touch
- Added new actions to add GameController mapping strings
- Added more conditions related to various device states
- Added new expressions to get Joystick/GameController type and analog axis resting values
- Added battery percentage, LED and touchpad example

The original version of SDL Joystick has been updated. Please login to see this link..

This update makes major improvements to the conditions exposed by the extension, and is should be much easier now to design games with it. The example file was updated with simple analog and digital movement for a 2-player game.

I have also updated Please login to see this link. with explanations of conditions, differences between Joysticks and GameControllers etc.

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.
EDIT: I got my hands on a PS5 controller and I can tell that it doesn't expose the D-Pad as a Hat in Joystick mode, so the behavior you're describing is correct. You need to use D-Pad button IDs instead.

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 Gоdot (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.