Why do I have to use DXTory to capture spring?

[Forboding Angel]

Anyone other game I can just use screen capture. But nooooo, for spring you have to use a gobetween. Otherwise, you end up with a black screen. Probably for the same reason that pressing print screen in spring causes you to capture a flat black image.

[Beherith]

Printscreen works for me in windowed mode in win7.

[AntiAllez]

yea press F12

[SpliFF]

First line of the DXTory homepage: "Dxtory is a movie capture tool for DirectX and OpenGL Applications". Spring is OpenGL; windows printscreen is presumably DirectX only. Blame Microsoft.

[Forboding Angel]

So surface and overlay capture does not work for opengl?

That doesn't make sense, cause it works for stuff like quake live which is opengl.

yea press F12

I am aware of how to take a screenshot. You missed the point of the post entirely.

Printscreen works for me in windowed mode in win7.

Same here, however, go to windowed fullscreen (borderless window) and all of a sudden it doesn't work.

[Floris]

try using OBS: "Open Broadcaster Software"


you can stream to twitch for examle, but you can also save to file.

[SpliFF]

So surface and overlay capture does not work for opengl?

The original 2D rendering system for Windows was something called GDI and each windowed application has to maintain a bitmapped "layer" of its contents. When Aero came out this changed to Direct2D "surfaces" but the concept remained the same. Either way requires making your application use windows underlying renderer. For OpenGL applications you pretty much just reserve some screen pixels for rendering but otherwise Windows knows almost nothing about the data being rendered (Spring uses the SDL library to facilitate this in a cross-platform way).

When you go fullscreen or use a video overlay you are typically writing straight to video hardware memory so no bitmapped surface is maintained. Presumably Direct3D/DirectShow has some builtin mechanism for providing a bitmap on demand via some system callback but naturally it will be Windows-specific. OpenGL can also generate a bitmap through its API which is presumably what Springs screenshot key is using but it writes to your screenshots directory instead of the clipboard (which would require more Windows-specific code/callbacks). Even if Spring/SDL was modified to handle these callbacks there's no gaurentee it wouldn't come with a framerate hit.

If you're getting a black screen then the issue depends on whether your PrintScreen key is actually mapped to Windows PrintScreen or Springs internal screen capture (I'm guessing the first). If it is the first the problem may be because Spring doesn't participate in the DirectWhatever callback system and if it is the second then it might be a driver issue (OpenGL read bitmap call returning the wrong data).

[Forboding Angel]

try using OBS: "Open Broadcaster Software"


you can stream to twitch for examle, but you can also save to file.

I'm already using ffsplit. That isn't the issue. The issue is that spring is unique in it's rendering apparently, so that unless you specifically capture opengl, you will only get black. Whereas every other game you can just capture the screen and call it a day.

---

The issue is not printscreen.

[SpliFF]

I thought Spring has, or used to have, an AVI frame recorder builtin (http://test.springrts.com/mantis/view.php?id=364). Does it not do what you need?

[Forboding Angel]

No, because I don't save locally. I stream directly to twitch. I have a 50/35 mbit connection. There is no reason for me to save locally.

But Dxtory is essentially a camera and eats performance. Spring is unique in this, so it is definitely a spring problem.

[Floris]

Again obs can do the job, because ive already did that.

Apply focus shortcut and thats it, you can add a windows screencapture layer below the sping game capture if you like to show desktop on alt tab

[SpliFF]

But Dxtory is essentially a camera and eats performance. Spring is unique in this, so it is definitely a spring problem.

There's no reason to believe that implementing this in Spring won't eat exactly as much performance since what you are essentially asking the application to do is read the OpenGL screen buffer out of the graphics hardware and render it to a system memory bitmap (not to mention compressing said bitmap and sending it to a network interface). This will put extra strain on your PCIe interface and CPU in what is basically the same process that DXTory is using - the only real difference being that DXTory is an external process which may or may not be relevant depending on the number of free CPU cores you have.

If you believe DX programs don't have exactly the same issue you'd be mistaken. Hardware accerated rendering is done in hardware and any attempt to move the screen buffer out of hardware will cause slowdown due to IO overhead.

[Forboding Angel]

Again obs can do the job, because ive already did that.

Apply focus shortcut and thats it, you can add a windows screencapture layer below the sping game capture if you like to show desktop on alt tab

That does not work in windowed fullscreen floris.

I have been doing this for a while. I know what I am doing.

@spliff. It is only necessary to use dxtory and programs like it with spring. Period.

[SpliFF]

@spliff. It is only necessary to use dxtory and programs like it with spring. Period.

I know. What I'm saying is this isn't so much a "bug" as it is a missing windows-specific feature and demand for that feature was virtually non-existent until you tried to use it. Somebody *could* add this feature to Spring but you'd have to convince them it was worth the time and effort and would result in better performance than using DXTory which as I've said is not guarenteed since the overhead you're concerned about is mostly caused by high IO and compression overhead due to how the hardware works.

I guess some numbers would help. What is the typical overhead of running ffsplit on a game like Crysis vs running dxtory? Your central argument seems to be that performing windows native screen capture has significantly lower overhead than under dxtory but I can't think of any technical reason why that would be the case. I do accept your argument that using dxtory is more complicated as an end-user but does that complication justify the development time and added complexity required to enable native screen capture in Spring when you're probably the only person trying to do video streaming from Spring in real-time?

[Forboding Angel]

Till I decided to use it? I've been making spring videos for years.

I have been working around the issue all that time.


Screen capture is a lot faster. Remember, when using dxtory or similar programs, you are routing things twice.

Dxtory >ffsplit/xsplit >web

Btw, that OBS program doesn't hold a candle to ffsplit.

[SpliFF]

I was thinking it could be the way WindowBorderless is implemented. As a quick hack you could try normal windowed mode with a tool like http://grismar.net/shiftwindow/ to push the frame decoration offscreen. Then you wouldn't need DXTory at all.

I still think blaming Spring is misguided here. Many, if not most games, don't support "borderless windowed mode" at all and lack of DirectX support is a feature, not a bug.

[Forboding Angel]

Yet games like starcraft 2 do it perfectly.

I don't think I play any games that don't have windowed fullscreen. I believe you are a bit misguided as to just how many games have it implemented.

I'll try that, but I would prefer that borderless window were implemented properly.

[Forboding Angel]

Spliff, you're a damn genius. Yes, it is the way spring does borderless fullscreen that is the problem. Check this out:

http://www.twitch.tv/forbodingangel/b/430763295 << 720p
http://www.twitch.tv/forbodingangel/b/430764898 << 1080p

LOOK AT THAT SEXY FPS IN 720/1080P!

Fuckyes!

I did it using a program called window manager:

Download: http://sourceforge.net/projects/mmfh/

How to use it: http://sourceforge.net/p/mmfh/discussio ... it=50#8ea2

[SpliFF]

Happy to help.

Having said that I still don't buy your premise that this is specific to Spring. The window mode is controlled by SDL (SDL_NOFRAME) which is used in a lot of cross-platform games. If it's a bug in SDL I haven't found any evidence it's widespread and I cannot fault how it's implemented in Spring.

The core of your issue seems to be this statement: "go to windowed fullscreen (borderless window) and all of a sudden it doesn't work."

By "doesn't work" you appear to mean "captures are black". When I looked into causes of that particular effect with ffsplit there are several known causes:

* No Fullscreen Support. Turning on WindowBorderless option in Spring config DOES NOT disable fullscreen mode. You need to turn fullscreen OFF (Fullscreen=0) to get proper "borderless windowed" (and set the window resolution to your monitor native res). The Springsettings wiki page says specifically: For Windowed Fullscreen of Borderless Window, set Fullscreen to 0, WindowBorderless to 1, and WindowPosX and WindowPosY to 0.
* Hybrid Graphics (ffsplit has issues with laptop hybrid graphics (eg, Optimus) when hybrid mode is on. You can disable it in Nvidia/ATI controlpanel.
* FFSource Overlay. The *new* overlay in ffsplit has black screen issues in some cases where the old overlay did not. Try the old ffsplit overlay method.
* Bug in ffsplit (you should set overlay quality to high) - http://www.ffsplit.com/forum/index.php? ... creen.466/

For framerate issues:

* Vsync (if vsync is enabled ffsplit framerates drop).
* DXTory scaling. Using any scale factor other than 100% will cause framerate loss. Capture at the native screen resolution and let ffsplit do the scaling.

For stuttering issues:

* Disable vsync, as above.
* Disable Aero (Aero caps FPS at 22fps for some reason)


Some good benchmark info can be found here (covers xsplit, dxtory and ffsplit under various conditions): http://www.xsplit.com/forum/viewtopic.php?t=10740


In summary getting black screens in ffsplit appears to be a common issue and not something specific to Spring. Furthermore, performance with DXTory may be seriously impacted by certain settings. Try some of the suggestions above and I suspect you'll overcome any issues with borderless mode without additional software or window hacks.

[jK]

It is all microsoft's fault.
Windows detects fullscreen apps and disables all background GUI (Aero), this includes the window managment of the current fullscreen window, so instead of keeping a sysram available copy everything done on the GPU without a feedback loop to sysram. This is an optimization and is wanted cause it increases your FPS.
Also windows detect fullscreen borderless windows too and handles them in a similar manner!
Never the less, I don't see a reason to run spring in any fullscreen mode when recording/streaming, in such cases you always want to know if streaming is still happening etc and that can only be seen in normal windowed mode.