Fix Apply button not updating settings or closing dialog

[ExilProductions]

• Resolved an issue where BtnSave in the options dialog produced no visible effect
• Added a call to applypgxp() after saving to reload settings in the main form
• Closed the options dialog after saving to provide user feedback
• Made applypgxp() public to allow invocation from Form_Set

In the previous commit, I also changed how the SDL2 binaries are copied. All batch files except arm64 now copy the SDL2 binaries after publishing for the proper platform. Although you mentioned earlier that the core project should remain clean, I still recommend using a NuGet package for the SDL2 implementation so we do not have to handle copying the SDL2 binaries manually. Maybe put the Package also in ThirdParty?

I am also currently working on a separate branch for workflows to build ScePSX for all platforms (See git-workflow). I may create a PR once I finalize each workflow.

[unknowall]

Thanks for the PR! Good catch on the options dialog and the PGXP reload — that one’s been sitting there for a while.

About SDL2: I totally get why you'd want a NuGet package. The tricky part is that SDL2 is a native library, and the NuGet packages I’ve seen either pull in extra stuff I don't want, or don't cover all the platforms I care about (especially some of the less common ones). The manual copy is ugly but it keeps things predictable. I’m open to revisiting if there’s a clean, lightweight package that just does the copy without magic.

As for the CI — that’s a big one. I’d love to have it, but there’s a catch: some platforms (e.g., LoongArch) aren’t available on GitHub Actions or most hosted CI runners. If you’re setting this up, I’d suggest starting with the platforms that are easy (Windows x64, Linux x64, maybe Android), and we can figure out the rest later. No need to block a good CI on the hardest targets.

One more thing on the core design philosophy — since PS1 emulation has strict timing requirements, I try to avoid any NuGet references in the core execution path. Unpredictable GC or hidden allocations would be a disaster for frame‑accurate behavior. That’s why I ended up writing LightGL and LightVK myself, keeping them separate from the core. SDL2 is used for audio output and input handling — those calls happen on the bus side, so the current manual integration gives me the control I need to avoid surprises.

Really appreciate you digging into all this. Looking forward to seeing where the CI branch goes!

[ExilProductions]

Thanks for the detailed explanation, that all makes sense! Totally understand the reasoning behind keeping SDL2 manual and avoiding NuGet in the core execution path.

For the CI, I went ahead and set it up for the platforms available on GitHub Actions. For platforms like LoongArch, the workflow only compiles the Avalonia project since those targets aren't available on hosted runners. The other platforms build on their natural hosts: Windows for the Android and WinUI projects, and Linux for the Avalonia Linux build.

I'll mark the PR ready for preview once I've verified that the options dialog and PGXP reload are actually working correctly.

[unknowall]

Glad you understand the strict requirements on the core execution path — I once spent two weeks debugging a game crash, only to find out it was caused by a single array allocation triggering GC at the wrong time, messing up the timing. If you're interested, the game names are in the comments in DMA.cs.