SpecialKO / SpecialK

Lovingly referred to as the Swiss Army Knife of PC gaming, Special K does a bit of everything.
https://www.special-k.info/
GNU General Public License v3.0
859 stars 51 forks source link

Special K uses the "BackBufferCount" label for both d3d9 and dxgi, but that is wrong for dxgi #173

Open giias opened 5 months ago

giias commented 5 months ago

technically in d3d9 you specify the number of backbuffers, and so d3d9 uses a "back buffer count" (where there may be an implicit front buffer...)

but in dxgi you specify the number of total buffers, and so dxgi technically uses a "buffer count" (which counts the total number of buffers).

with that said, unfortunately... special k has kept the label "backbuffers" for not just d3d9 games, but also for dxgi games. the same sk setting is used, but yeah it doesn't work exactly the same with dxgi games compared to d3d9 games.

that also means that setting BackBufferCount=2 in d3d9 games with sk may result in triple buffering (2 back buffers + 1 front buffer that was a given), but setting BackBufferCount=3 in dxgi games (d3d10/d3d11/d3d12) with sk would be needed for triple buffering.

basically, for accuracy in dxgi games... the setting should really be labeled "BufferCount" or "Buffers" (or "Buffer(s)" as another option...) instead of "BackBufferCount"

note also that sk's log file, the specialk.log, already uses the label "Buffers" for dxgi games, but unfortunately the specialk.ini config and the special k control panel menu are still incorrectly using "BackBufferCount" or "BackBuffer Count" (in the swapchain management section) and "Back Buffers" (in the framebuffer tooltip) for dxgi games.

Why stop using the "BackBuffer Count" label for dxgi games ?

for example, we've had someone thinking that flip model needs triple buffering after seeing "BackBuffer Count: 2" being forced by sk and shown in the sk control panel menu for their dxgi game, but that's wrong since. for triple buffering in dxgi, a count of 3 is needed, and flip model needs at least a buffer count of 2 (NOT a back buffer count of 2)

and someone else was thinking that "quadruple buffering" was being used when sk was showing "BackBuffer Count: 3" for their dxgi game in the sk cp menu, which of course is also wrong (because that's not actually quadruple buffering in dxgi), but unfortunately it's what sk was leading them to believe due to sk (incorrectly) displaying "BackBuffer Count" instead of "Buffer Count" for dxgi there...

below are some suggestions:

"BufferCount=-1" could also be used, but "Buffers" or "Buffer(s)" can be a more general term to refer to either the "back buffer count" for d3d9 or the "buffer count" for dxgi respectively, and we could still keep one setting for both d3d9 and dxgi.

Alternatively, we could have 2 specialk.ini config settings: "BackBufferCount=-1" and "BufferCount=-1"

(also, keep in mind, "buffers" is what sk's log, the specialk.log, already uses and is not incorrect for dxgi)

(the sk control panel menu doesn't even have a swapchain management section for d3d9 games anyway, so don't really need to worry about the swapchain management section for d3d9 games...)

for example:

change this:

backbuffercount

to this:

buffercount

giias commented 5 months ago

or an alternative/simpler change:

("Buffers" or "Buffer(s)" can be a more general term to refer to either the "back buffer count" for d3d9 or the "buffer count" for dxgi respectively, and we could still keep one setting for both d3d9 and dxgi.)

after the .ini config setting gets renamed (or if a new one gets added for dxgi games), some people (basically those who had a "BackBufferCount" override) may need to reset their sk config .ini and/or adjust it to use the new setting, but i don't think that's a big issue...

marat569 commented 5 months ago

It seems the only place "Backbuffer Count shows up is in cfg_d3d11.cpp

Which means that line of text controls all apis; so if you change "Backbuffer Count" to "Buffer Count" there, it will show up as "Buffer Count" in 9, 11, and 12 (with footguns)

Its possible to do a simple if statement though; so the text is different depending on render api