for a simple demo program I am using the SDL library to play a mpeg movie file.
Unfortunately the demo app should be executed on one of our windows 7 servers and it should be looked at remotely.
The problem is, that when I connect via RDP to the server the SDL window stays black - although the movie becomes played (I hear the sound).
I guess this has something to do with the rendering device of OpenGL or DirectDraw when accessing via remote desktop. Does anyone know which settings I should use for setting up the SDL window so it works via RDP also?
When I play the movie with the windows media player the movie becomes displayed correctly - what kind of device uses the media player?
The problem is probably that SDL is rendering directly to video memory (or some sort of DirectDraw surface), but the RDP program is only able to retrieve what's in system memory.
If this is the case, there's a few things you can try. First is a different RDP program that has the ability to grab from DirectDraw or video memory. The other thing is when you call SDL_SetVideoMode() use the SDL_SWSURFACE flag. This will render to system memory where as SDL_HWSURFACE will render to video memory.
Related
I was experimenting with desktopduplication api sample code and it was mentioned here that
even full screen DirectX applications can be duplicated.
Also here it is mentioned that
The following components of the operating system can generate the desktop image:
The DWM by composing the desktop image
A full-screen DirectX or OpenGL application
An application by switching to a separate desktop, for example, the secure desktop that is used to display the login screen
However when I tested the sample code with multiple monitors provided here, it worked fine for other applications running on desktop but when I started a fullscreen directx application, the running applications in the background are pushed onto the secondary monitor and only the secondary monitor is captured in the duplicated window.
What might be the reason for this? I ran the exact sample code provided by MSDN. Is there something more I need to do in order to capture DirectX fullscreen games using DesktopDuplication API
So I am trying to figure out how get a video feed (or screenshot feed if I must) of the Desktop using OpenGL in Windows and display that in a 3D environment. I plan to integrate this with ARToolkit to make essentially a virtual screen. The only issue is that I have tried manually getting the pixels in OpenGl, but I have been unable to properly display them in a 3D environment?
I apologize in advance that I do not have minimum runnable code, but due to all the dependencies and whatnot trying to get an ARToolkit code running would be far from minimal. How would I capture the desktop on Windows and display it in ARToolkit?
BONUS: If you can grab each desktop from the 'virtual' desktops in Windows 10, that would be an excellent bonus!
Alternative: If you know another AR library that renders differently, or allows me to achieve the same effect, I would be grateful.
There are 2 different problems here:
a) Make an augmentation that plays video
b) Stream the desktop to somewhere else
For playing video on an augmentation you basically need to have a texture that gets updated on each frame. I recall that ARToolkit for Unity has an example that plays video.However.
Streaming the desktop to the other device is a problem of its own. There are tools that do screen recording, but you probably don't want that.
It sounds to me that what you want to do it to make a VLC viewer and put that into an augmentation. If I am correct, I suggest you to start by looking at existing open source VLC viewers.
We are trying to implement WebGL for a 3D user interface. We have some users that need access through a Remote Desktop connection, however, WebGL is disabled. When loading a page with WebGL on a Remote Desktop, the error "Oops... Sorry, experimental-webgl context is not supported on this machine!... " appears and the 3D rendering fails. The 2D rendering works. We were wondering if there is a way around this problem.
OpenGL doesn't work with remote desktop because remote desktop opens up another desktop and isn't attached to the hardware display, thus I would assume WebGL has the same limitations. You will need to do a different type of remote desktop maybe vnc or even join.me seems to work fine.
We have an application which uses an OpenGL render context in a subwindow to display a large bitmap. However, when a user remotely connects to a box running this app, the openGL display stops working, most likely due to the reduced texture resolution.
While we can detect the remote desktop connection starting/ending using WTS_REMOTE_CONNECT, the openGL context does not switch to the virtual driver when trying to determine the new max texture resolution.
Completely restarting the openGL subthread hangs on ChoosePixelFormat, this wont return until I am logged in locally again, otherwise this would be the "bad" solution.
It seam that application is badly written.
Code that is responsible for detecting context changes and reacting to them accordingly, do not exist or is buggy. Any way, you can not do much, unless you have access to source code. Also you can report is as a bug to vendor or provider from whom you bought it.
I have a C++ application that uses the Win32 API for Windows, and I'm having a problem with GDI+ dithering, when I don't know why it should be.
I have a custom control (custom window). When I receive the WM_PAINT message, I draw some Polygons using FillPolygon on a Graphics device. This Graphics device was created using the HDC from BeginPaint.
When the polygons appear on the screen, though, they are dithered instead of transparent, and only seem to show few colors (maybe 256?) When I do the same thing in C# using the .NET interface into GDI+, it works fine, which is leaving me wondering what's going on.
I'm not doing anything special, this is a simple example that should work fine, as far as I know. Am I doing something wrong?
Edit: Nevermind. It only happens over Remote Desktop, even though the C# example doesnt Dither over remote desktop. Remote Desktop is set at 32-bit color, so I don't know what's up with that.
Hmm... The filling capabilities are determined by the target device. When working over remote desktop, AFAIK Windows substitutes the display driver, so that can change the supported features of the display.
when drawing on wm_paint, you actually draw directly on the screen surface, while .net usually uses double buffering (draws to in memory bitmap and then blits the entire bitmap)
there are some settings in gdi+ that affect the drawing quality. maybe there are different defaults for on-screen, off-screen and remote painting?
It only happens over Remote Desktop
Many remoting applications will reduce colour depth in order to reduce bandwidth requirements. While I haven't used Remote Desktop, the same happens on certain VNC connections. I'd check your RD server and client settings.