Why do I have to use DXTory to capture spring?

[Forboding Angel]

@spliff, I am aware of those issues, and none of them apply to spring, nor have I ever had them happen with anything other than spring.

JK's post was actually very enlightening, and it explains a lot of why the behavior is so inconsistent.

By using window manager and stripping the borders that way, it actually remains a window (and I have noticed that it responds a lot better than spring's native borderless fullscreen).

It sucks gigantic cock to have to use a 3rd party program in order to get good performance, but whatever, at least the 3rd party proggie is free.

With Dxtory, while streaming in 1080p I would get MAYBE 15 fps. With window manager + spring I average over 100.

[SpliFF]

I just had a play around with ffsplit and found an easier way that requires no third party tools. Run Spring windowed at whatever res you want your stream to be then create a new layer using the "window" capture mode, select Spring as the target window and tick "Only Client Area" to remove the window borders.

Even without disabling Aero, Spring's FPS is around 500 and the capture framerate is a consistent 30 fps at 1280x900 res on my i5 / AMD 6870 setup.

The only issue I had is that the ffsplit window overlapped a few seconds of the video but that's only because I was using the start button on the ffsplit gui and not hotkeys to start the recording.

All in all I agree with jK, true windowed mode is superior to either of the fullscreen modes in terms of ease of use and does not present any significant slowdown. There is no compelling reason to use borderless mode since it clearly triggers some kind of overlay/exclusive/direct rendering mode that prevents DirectShow capturing.

It's still doubtful this is a Spring bug and not simply a consequence of the fact that Spring doesn't use Direct3D like 99% of Windows-only games (not to mention Microsofts ongoing attempts to kill off OpenGL entirely). Since a simple workaround exists I see no compelling reason to use a tool like window manager unless you absolutely must use every pixel of screen realestate.

In related news I found this quite interesting: http://blog.mmacklin.com/2013/06/11/rea ... th-ffmpeg/ . With some small tweaks to Springs recording interface and a local copy of ffmpeg binary you could quite easily write video streams directly from Spring to ffmpeg and from there to MP4 file or stream output.

[Forboding Angel]

SPliff, I want to record in 1080p. Not 720p. In order to do that windowed, I would have to kiss the bottom 100 px of my screen goodbye. No thanks. Also, anytime when moving the mouse to the bottom of the screen I would be in danger of unfocusing the window.

[smoth]

but do those extra pixels make THAT big a difference?

[Forboding Angel]

Yes, considering that if you move the mouse to the bottom of the screen windows captures it because you are now over the taskbar. You can't see player information, you can't see the bottom of your menu which shows your buildqueue...


Yeah, it kind of matters.

Not to mention that the 1080p sized window will hang off onto the second screen.

Moreover, it's difficult to do commentary if windows is going ape shit all the time due to a gigantic window.

@spliff, the whole point of window fullscreen is that it's supposed to be a true window with to borders removed, no more no less.

So why doesn't it work like that?

[SinbadEV]

Dumb Idea... what would happen if you had two monitors? borderless full screen would still have to be rendering Aero etc to keep the second monitor's share of the desktop painted... place this second desktop above the primary and put the taskbar at the top of it for added oops avoidance.

[smoth]

Yes, considering that if you move the mouse to the bottom of the screen windows captures it because you are now over the taskbar. You can't see player information, you can't see the bottom of your menu which shows your buildqueue...

this is a side discussion for later.. so your ui requires a specific aspect ratio? we should chat about this later in gtalk so I don't derail.

[Forboding Angel]

This problem has been solved, so I'm not sure why half assed "solutions" are being discussed.

@smoth no need. Of course the UI can be shifted, but what users see on videos that I create will be default Evo UI, not some ham handed construct that looks like it came out of a user ZK clicking buttons at random (Sorry to pick on ZK, but it tends to have the most wildly inconsistent UI setups).

I also use this for playing as well, so I just want windowed fullscreen to work correctly in all situations. I don't feel that that is too much to ask.

[SpliFF]

So why doesn't it work like that?

That is the million dollar question but it isn't something that Spring code is doing. ALL Spring does when you set the WindowBorderless option is pass an additional display flag SDL_NOFRAME to the SDL library. SDL then requests windows/x11/macosx to remove frame decoration. That's it.

I'd bet 100% that on linux the same scenario would just work. In fact X11 windows actually have no frame decoration by default (your "window manager" adds them). All SDL needs to do is ask the WM to pretty-please don't decorate my window. Presumably on Windows the same thing should happen but clearly it does not.

So if you follow the blame trail to its logical conclusion you can probably assume that SDL is asking Windows to remove the decoration but Windows in all its wisdom has decided to do something else entirely. It may be, as jK suggests, deciding that if you don't want frame decoration you also also don't care about receiving events (like printscreen). The only way to know for sure would be to ask Microsoft what the fuck they're thinking.

I just want windowed fullscreen to work correctly in all situations. I don't feel that that is too much to ask.

It isn't but all the evidence suggests you're asking in the wrong place. If you want to know for sure where the blame lies try to get hold of another SDL+OpenGL game (plenty of freeware/opensource games are) that supports borderless and see if you get the same results.

[Forboding Angel]

But Spring seems to be the only mentally ill child in the room that is having issues. The same arguments could be applied to why ATI works fine on anything that isn't spring.

[SpliFF]

That has been your claim all along but you haven't given any examples that also use SDL and OpenGL. HL and Quake do their own window management but they aren't expressly cross-platform. Practically every other game released for Windows in the last 20 years uses DirectX which is closed-source and still only runs on one platform. SDL and OpenGL are important tools for cross-platform games and Spring isn't going to dump them because of one bug, that may or may not be a bug in Windows itself. Technically speaking you're comparing apples with oranges, if you can find another game using SDL+OpenGL that doesn't cause this issue then there is something worth discussing, otherwise you have your workaround.

Spring's entire contribution to this issue is 1 line of code.

Code: Select all

if (WindowedFullScreen) SDL_FLAGS |= SDL_NOFRAME;

It's hard to imagine that line could be "fixed" or in anyway responsible for the issue.

The ATI issues are another story. In my experience the cause was never simply "ATI bugs" (though there were many) but more to do with the fact none of the core devs were using ATI cards. As a result some of the opengl/shader code in Spring relied on nvidia extensions or quirks that weren't being picked up in testing. For a long time the devs simply blamed ATI and the users and didn't always spend the time to find solutions or workarounds. The same was also true for intel and mesa users until more recently.

[smoth]

windows is all kinds of fucking wierd it would not surprise me if that code is advocated as working 100% on the msdn but it was actually deprecated years ago for some other implimentation. God I remember when all the info on the msdn was working/updated reliably.

[Peet]

As someone who has written software bridging directx and directshow I assure you that this is a tiny little annoyance among the galactic clusterfuck of windows' video.

[knorke]

Also, anytime when moving the mouse to the bottom of the screen I would be in danger of unfocusing the window.

/grabinput ?

[Forboding Angel]

Also, anytime when moving the mouse to the bottom of the screen I would be in danger of unfocusing the window.

/grabinput ?

Randomly fails on Fullscreen with more than one monitor and randomly fails on borderless fullscreen.

However, using my method of using a window and then just killing the border with window manager, it works flawlessly.

But when it is a legit window, the taskbar overlaps the window, so moving down over the taskbar, windows recaptures the mouse.

Just use my window manager solution and it works perfectly.

Extra special thanks to Spliff and JK for their added knowledge which vastly helps clarify the subject.