Not so much a issue but I need to ask something Important

[danny199012]

As much as I love Soul Calibur 2 I want to ask for permission to be able to make a Windows Build It will be on my Github I already have made a massive amount of progress to the point it runs I get past the memcard screen FMV's at the moment don't render and I haven't managed to get my pad to work but it's kinda working The tool I have is a Python GUI it downloads everything needed and users will need to have there own .iso the tool will build everything that is needed (May even change this step) to simply download everything run the rigout.exe which asks for the iso of the game and will build it not sure as of yet.

As I don't really have a method of messaging I thought I woul give this a try in hopes I can get your attention of approval at this moment in time I can't really disclose to much more info as work behind the scenes needs to be fixed in order for it to truly run on windows.

[danny199012]

FMV's are now working they seem fine however audio seems a little stuttery I'm working on the main issues now like getting my dualsense to work and fact alt+enter won't go fullscreen Also if it's ok Can we leave this issue open I will use it to log my progress if that's ok.

[jackpoison-prog]

Go for it — genuinely, no permission needed and you have my blessing anyway.

Worth knowing: the project is GPL (it's Dolphin-derived, which is why the
release ships its source), so a fork was always yours to make as long as you
keep it GPL and pass the source offer along. Asking first was decent of you.

I am planning a Windows version myself eventually, and that doesn't change my
answer — the more the merrier. Yours will exist long before mine does, and
people are already asking for it (#3). There's also another Windows fork in the
wild at github.com/Ell/RingOut that someone's actively playing on in #2 —
worth a look, whether that means comparing notes or just not solving the same
problem twice.

Getting past the memory-card screen with the game running is the hard part, so
you're well past the worst of it. On the two you mentioned: the FMVs and pad
input are both areas I've spent time in on the Linux side, so if you hit
something specific, open an issue here and I'll tell you what I know rather than
let you rediscover it.

One request, and only because people will inevitably confuse the two: make it
clear in your README that it's a separate fork and that issues go to you, not
here. Saves us both answering each other's bug reports.

[danny199012]

I'm glad you mentioned the ell fork I wasn't aware of it and already in terms of progress it's way a head and everything so far looks to be working I'm gonna abandon my version just to save confusion Your welcome to officially close this issue if you like and thank you such a great job you've done.
Also for HD texture Packs it wasn't to clear where they should be on the Ell Fork anyway I found where they were mant to be placed
%LOCALAPPDATA%\RingOut\Load\Textures\GRSEAF
Oddly that fork doesn't have a issues I suppose it would be handy if there was a discord or something for the project and that way it would be possible to talk and also share updates etc...

Just a suggestion.

Is there a issue with linux version when trying to use more than 1 controller?

I ask because In the Ell fork I can't seem to use 2 dualsense controllers and not sure if this is also a issue with the Linux version if it is a issue may have a fix for it soon.

Ok I have forked the Ell Fork and while the controller Issue I had should be fixed I'm having Build issues on Windows so I'm currently Working on a tool that should be able to build Ease of use and support both Linux and Windows also Adding in Source of the recomp so users can simply download the tool pick which version they want to use and the tool will do compile everything also Wrote it in Python so it's easy to use on multiple devices while staying Lightweight.

At the moment in time I haven't tested the controller fix if it's a issue on linux also your welcome to cherry pick the fix If it works that is.

So my tool can build it but fine just a few bugs now to fix my ringout.exe had no GUI inside when got built that is getting worked on it last few minor adjustments as for my 2 controllers fix it does work however there's a caveat in the ringout.exe GUI I can't configure 2 controllers will look at making a 2nd device in the controllers section.

[danny199012]

This is a fresh build on windows but 2 controllers work also don't need to use GUI for it can just turn pad on and press start (Only tested with a dualsense) However but this was something I couldn't get working at all until now not sure if Linux has same issue.

My tool now can fully build everything however performance is tanking again not sure if this issue is same as linux but my pc is i9 10850k, rtx 5070ti and 64gb ram and the game tanks from 60fps down to 40 and below at times not sure the cause yet but looking into it.

[danny199012]

@jackpoison-prog I need to ask you what's your performance at on linux and what is your fmv's like are they rendered at locked 60fps or have dips I mean I can test a Linux build on my spare PC but honestly probably isnt capable of running this I mean DDR3,Radeon HD 5770 1gb and a i5 750 I can install Linux to try it but highly doubt it would run well if at all.

I'm asking as I noticed it's forced to use vulkan and looking into perf with dx11/dx12 any feedback would be much appreciated
My fork has a python tool which if you also wanted you can manually edit to pull your repo and change the build structure also 2 controllers are working fine pretty much everything is almost there just need to look into preformance now as my gpu and cpu are barely getting used and fps tanks at lowest 48 -49 fps and seems to be certain stages or some sound effects.

I say sound effects as FMV was mostly 60fps until there was a lot of sounds then it seemed to drop frames and i believe it also seems to be the case in game but changing latency etc... didn't really help.

I think my performance issues are due to vulkan actually I tried same game on dolphin and it was running less than 30fps tried changing things no joy in the end it ended up black screen at less than 30fps
I switched to DX12 and game ran pretty perfect 60fps
with same settings as vulkan but 1 thing i noticed vulkan seemed like it wasn't properly compiling shaders with dx12 it oddly compiled and then said there was more to compile as for vulkan there was way less.

Also sorry to be a pain as I haven't really seen any Youtube videos other than VGE

[jackpoison-prog]

Is there a issue with linux version when trying to use more than 1 controller?

Yes — four separate ones, stacked. All fixed in 1.5, out now:
https://github.com/jackpoison-prog/RingOut/releases/tag/v1.5

Since you're fixing the same thing in your fork, here's what they actually were.
The first two are Dolphin-inherited, so they very likely apply to the Ell fork
as well:

1. Port 2 was never attached. Config::GetInfoForSIDevice defaults SIDevice0
   to a controller and ports 1–3 to SIDEVICE_NONE, and nothing overrode it. The
   game saw one pad however many were plugged in.
2. A second pad gets no bindings. InputConfig::LoadConfig gives default
   bindings to controller 0 only and calls the base LoadDefaults on the rest,
   which clears them (ControllerEmu.cpp:145-157). Dolphin does this
   deliberately so four pads don't share one device — but it means port 2 arrives
   attached and blank.
3. Device ids are numbered per (source, NAME), not per source.
   ControllerInterface::AddDevice compares source, name and id together, so
   two pads of different models are both SDL/0. Only two of the same
   model get 0 and 1. We were numbering sequentially, which produced
   SDL/1/<name> for a device Dolphin calls SDL/0/<name> — a device that
   doesn't exist. Dolphin resolves a binding to an absent device silently: the
   pad reads centred and unpressed, and nothing logs a thing. This one is worth
   checking in your fork; two DualSenses are the same model, so you'd get 0 and
   1 and it would look fine, right up until someone mixes a DualSense with an
   Xbox pad.
4. Only [GCPad1] was ever written, so player 2 had to hand-bind in the UI.
   That matters more than it sounds: Main Stick/Calibration is a group
   setting, not a bindable control, so it doesn't appear in the controls list at
   all. Without it Dolphin assumes a square gate and the diagonals never reach
   full deflection — movement and guard, in a fighting game. A hand-bound port 2
   is permanently miscalibrated and there's no screen anywhere that fixes it.
   That's why we write the section instead of offering a UI for it.

You mentioned you can't configure a second controller in your GUI — (4) is
probably why you'll want to write the section rather than expose it.

Also worth pulling into your fork, unrelated to controllers. I found a freeze
this week that lives in Dolphin's Fifo.cpp, so any fork of this code has it:
on a fresh install, the first time you enter a fight, the game can hang forever
with a black screen and audio still playing. The GPU loop snapshots the FIFO read
pointer, runs the batch, then writes the pointer back — but a first-time shader
compile makes that batch take a long time, and the game swaps its GX FIFO during
the transition into a fight. The write-back then puts a pointer from the old
buffer into the new FIFO's registers, and nothing can ever be drawn again. Fix
is about fifteen lines: snapshot CPBase/CPEnd with the batch and drop the
write-back if either moved. Warm shader caches never reproduce it, which is why
it survived months of testing here.

On the HD texture path you worked out — on Linux it's
userdata/Load/Textures/GRS/, and note the three-character GRS rather than the
full GRSEAF: Dolphin falls back to the 3-char id only if the region-specific
directory doesn't exist, so creating an empty GRSEAF/ silently shadows it and
kills every region-free pack.

A Discord isn't something I'm going to run, but this tracker is open and I'm
happy to keep answering fork questions here.

[danny199012]

Thanks for getting back to me i did push a few changes to my fork from ell's but as my build is mostly windows I'm not sure how much things may interfere as your mostly targetingg linux I have made a python script that can happily compile fork all on windows If you ever need it as a start point on a windows build varient I may look at additional improvements also later 1 of them may be just using dx11/dx12 renderer as had found odd issues in vulkan on windows and maybe a somewhat hinderance to performance.

[jackpoison-prog]

Thank you — and that script will be genuinely useful.

A Windows build is planned rather than hypothetical: the workflow, packaging script, installer and launcher scaffolding are all still sitting in attic/windows/, so it is a revival rather than a fresh start. The piece I do not have is exactly the piece you have — something that reliably builds the thing on Windows. I would like to take you up on it when I get there.

Noted on the Vulkan oddities on Windows as well. Useful to know before I hit them myself rather than after.

No date from me — Linux and the Deck come first, and I would rather ship those properly than half-start a third target.

[danny199012]

The python tool I have made you can also edit it do build Linux versions also is a great way to build newer builds as it's fully automated it pulls changes from the GitHub, downloads dependencies and builds it all only thing is you would need to make a few changes and point it to your repo also the dependencies links may need to be changed also I mean it is planned at some point to have options of which build to use and what OS so it can build for that OS.

And Thank you I will take a look at somepoint I have taken a little bit of a break as I don't get much free time and have other projects in the works.
I will try and get gameplay performances improved I may also look at using ffmpeg for the video handling as I'm sure in my previous build using that method fmv's ran better I may have to compare actually now I think of it I think fmv's were running better with ffmpeg.

[jackpoison-prog]

Thanks — and yes please, I'd like to take you up on it.

Since we last spoke I've said publicly that Windows is next for me once Linux
and the Deck are tidy. So the timing works out. Everything for a Windows build is
still sitting in attic/windows/ — the workflow, the packaging script, the
installer, the launcher. The only bit I'm missing is a reliable way to actually
build it on Windows, which is the bit you have. No rush at all, especially as
you're on a break. Whenever you get a spare evening, a link is plenty.

On performance, here are my real numbers rather than impressions:

• Linux desktop, uncapped: about 110 fps in a fight, worst second I saw
  was 100.
• Steam Deck: around 54–55 fps in normal fights, 58 against Inferno.

One thing that might save you time: which stage you're on is worth about 10% by
itself, and what drives it is the number of draw calls, not the polygon
count. So a stage that looks simple can be the expensive one.

Your 60 down to 40 is probably not the recompiled code. I chased that exact
symptom for a while, sure the final fight was hitting slow code. It turned out to
be 8x MSAA at a huge internal resolution. With MSAA on I got dips to 45 fps;
with MSAA off, same resolution, it sat locked at 60. Nothing lost but the
anti-aliasing.

What made it hard to spot is that the GPU showed near 100% either way — it was
the power draw that gave it away. So if your build turns on MSAA by default,
that could easily be your whole 20 fps. High internal resolution on its own is
cheap; it's the MSAA that costs.

On FMVs, honestly: I've never measured them properly. They play fine here,
but that's an impression, not a number, and I'd rather not pass it off as one.
Happy to go and measure it if that would help you.

And noted again on the Vulkan weirdness on Windows — useful to know before I run
into it myself. If DX11 or DX12 turns out to be the answer, I'd much rather hear
it from you than find out the hard way.

[jackpoison-prog]

Followed up on the FMV question, since I said I would rather give you a number
than an impression.

The intro FMV runs at a locked 60 on my Linux desktop. Sampled once a second
for 70 seconds with no input: median 59.9 fps, and during the movie itself it
never left 59.8–60.0. There were three seconds below 59 in that whole window —
one during boot, two after the movie had already ended — so none of them were the
FMV.

Two things probably matter more to you than the number, though, because they mean
I am not doing the same work your build is:

1. The movie is 640x368. Tiny. Whatever is costing you, it is unlikely to be
   the decode resolution.
2. This build has an FMV HLE. The game's own YUV to ARGB conversion is
   replaced with native frames, and there is a further mode that skips the MPEG
   decode entirely and paces synthesised frames at 29.97. So the FMV path here is
   doing meaningfully less than an unmodified port would.

That second one is worth knowing before you chase your stuttery audio — if your
build is running the game's original software decoder, you are comparing against
something that isn't the same workload.

One limit on my number, to be straight about it: 60 is my frame cap, so "locked
60" means it keeps up, not how much headroom is left. If headroom is the thing
you actually want, I have a harness that measures CPU-seconds during playback
instead — it exists precisely because at a 60 fps cap every configuration reports
the same number while consuming very different amounts of CPU. Say the word and
I'll run it.

[jackpoison-prog]

Update you'll want, given what you've been building.

There's an official Windows build now: https://github.com/jackpoison-prog/RingOut/releases/tag/v1.6

That doesn't make your work pointless and it isn't me closing a door — the licence has always allowed it and still does. But you were solving the FMV and pad problems yourself, and both of those are solved in this build, so you may prefer to point people at it rather than carry the maintenance.

For the record, since you asked about both: the movies play (ffmpeg is bundled, LGPL, credited in the package), and pads work including the analog sticks, confirmed on real hardware rather than under Wine.

One thing I noticed while reading your builder, offered as a heads-up rather than a complaint: it downloads several components and doesn't verify any of them before running them. Nothing about it is malicious — I looked precisely because I was asked to and I'd say so if it were otherwise — but anyone who can intercept one of those downloads gets to run code on your users' machines. A published checksum per download closes it. Happy to go into detail if useful.

[danny199012]

Thanks for reaching out and yeah i will improve the script so checksum checkon per download to prevent any such thingsfrom happening I'm glad you worked on a windows build btw...