I have an SDL2 windowed window accessed via Derelict 3.
It is supposed to strobe black and white (not because I hate epileptics), and it does this successfully. However, after a certain period of time, Ubuntu 13.10 marks the window as 'unresponsive', grays it out, and dulls the strobe effect.
This is highly irritating and totally kills the effect required by the application for visual stimulation to retrieve SSVEP readings from my EEG headset.
How do I get my OS to realize that the window is doing exactly what it should be doing?
Code
As I have wrapped the SDL calls in my actual code, I'm going to provide pseudo-code and the SDL methods called in those sections (I've checked that I'm not calling any other SDL functions):
make a window using SDL_CreateWindow (no set flags)
make a renderer using SDL_CreateRenderer (with presentvsync flag set)
for( ... )
{
fill screen black using SDL_RenderFillRect and SDL_SetRenderDrawColor
update screen using SDL_RenderPresent
fill screen white (same as above filling)
update screen (same as above update)
}
exit
I pedantically check error codes and return values for all SDL calls in the wrapper lib. They're all fine. What I need to know is what I must add to provide the heartbeat to my OS so it stops graying out my window.
Another thing...
Could someone please add an SDL2 tag? SDL2 has a very different API from SDL1.2...
Added event processing into the loop via SDL_PollEvent(null). This satisfied the OS.
For anyone using Ubuntu 16.04 and SDL2.0x -
The solution that worked for me was:
SDL_SetHint(SDL_HINT_VIDEO_X11_NET_WM_PING,"0");
set immediately after your SDL_Init(); call.
see : SDL2 wiki here.
I'm trying to obtain an figure object (using matplotlib), inside a wxpython application. I don't need to plot (or see) the figure, because I would want only to save it in a png file.
When I do it using Windows XP, it is all okay, if I do it outside the wxpython application, for example inside sphinx documentation, it's all okay again.
But If I do it inside my wxpython application... something goes wrong and it raises this:
_tkinter.TclError: bad screen distance "320.0"
Has someone any idea about?
Since you're trying to use wxPython and getting tkinter errors, you probably haven't told matplotlib to use wx. This can either be done in the matplotlibrc file, or in the program. Instructions are here.
I'm writing a plugin, using NPAPI and D3D. I just simply put a D3D sample from DXSDK and NPAPI together. I receive a HWND when the plugin starts up, and I passed it to D3D to draw.
It works though. the control(a 400 * 300 rectangle) on the test page DOES show what I expected.
But all other area in FireFox window is black, including the menu bar. All other contents on the test page cannot be seen.
I tried just InitDevice(D3D) with the HWND and do NO rendering at all. But still got the same problem.
Can anyone help me out here plz?
I've seen this happen a few times before; there are two different situations where I encountered it. The first is when I had something weird with my D3D initialization which aparently conflicted with firefox -- but I'm still not sure what I changed to get it working.
The second, which I hope is what you are encountering, is when I was initializing D3D and attempting to draw on the main thread. My theory (unproven) is that Firefox is actually creating its own DX context of some sort and so creating another one on the same thread conflicts. When we moved the init and drawing code to another thread it all started working.
This is one reason that FireBreath has so much code to help make things threadsafe and allow cross-thread calls back to javascript -- every time I've tried to do drawing on the main thread with OGL or DX I've run into problems somewhere.
Hope that helps!
Does anyone have a working example (code) of a DirectDraw overlay? Like something moving on the screen. I have been trying to find an example of DirectDraw overlaying usage and was unable to.
Thank you.
Try some of these:
from gamedev.net
from fourcc.org
[Edit] A bit more googling suggests you might want D3D Hooking? ..or have your tried the DirectDraw Overlay Library on CodePlex?
http://www.gamedev.net/community/forums/topic.asp?topic_id=359319
This code should work (I tried it when it comes out and it worked totally fine), its a little old and I don't know if it actually build with the actual SDK thought. (you maybe have to use an old SDK)
We've got some in-house applications built in MFC, with OpenGL drawing routines. They all use the same code to draw on the screen and either print the screen or save it to a JPEG file. Everything's been working fine in Windows XP, and I need to find a way to make them work on Vista.
In three of our applications, everything works. In the remaining one, I can get the window border, title bar, menus, and task bar, but the interior never shows up. As I said, these applications use the exact same code to write to the screen and capture the window image, and the only difference I see that looks like it might be relevant is that the problem application uses the MFC multiple document interface, while the ones that work use the single document interface.
Either the answer isn't on the net, or I'm worse at Googling than I thought. I asked on the MSDN forums, and the only practical suggestion I got was to use GDI+ rather than GDI, and that did nothing different. I have tried different things with every part of the code that captures and prints or save, given a pointer to the window, so apparently it's a matter of the window itself. I haven't rebuilt the offending application using SDI yet, and I really don't have any other ideas.
Has anybody seen anything like this?
What I've got is four applications. They use a lot of common code, and share the actual .h and .cpp files, so I know the drawing and screen capture code is identical.
There is a WindowtoDIB() routine that takes a *pWnd, and a source rectangle and destination size. It looks like very slightly adapted Microsoft code, and I've found other functions in this file on the Microsoft website. Of my four applications, three handle this just fine, but one doesn't. The most obvious difference is that the problem one is MDI.
It looks to me like the *pWnd is the problem. I'm not a MFC guru by a long shot, and it seems to me that the problem may be that we've got one window setup in the SDIs, and more than one in the MDI. I may be passing the wrong *pWnd to the function.
In the meantime, it has started working properly on the 64-bit Vista test machine, although it still doesn't work on the 32-bit Vista machine. I have no idea why. I haven't changed anything since the last tests, and I didn't think anybody else had. (On the 32-bit version, the Print Screen key works as expected, but it does not save the screen as a JPEG.)
Your question title mentions screen capture but your actual question doesn't. Please elaborate more clearly. Is the problem that you can do screen capture of three of your applications, but not the fourth one? You can use different screen capture software that can capture OpenGL/DirectX windows. Those surfaces are handled directly by the Window Manager and won't show up with a simple 'PrtScn'.
Switching to GDI+ won't solve it, nor will switching to SDI.
If it's the content of the CView that you want, then yes, that should be right one. If it's the content of the whole screen (at least the content, without the toolbar(s) and status bar), then you should pass it the CMainFrame (that's the default name which may have been changed, the one that is derived from CMDIFrameWnd).
Can you post the code of WindowToDIB()? I've just tried it and It Works For Me (TM), but without OpenGL code in the view. Try passing the following windows to your WindowToDIB() function:
CMainFrame* mainfrm = static_cast<CMainFrame*>(::AfxGetMainWnd());
- mainfrm
- mainfrm->MDIGetActive()
- mainfrm->MDIGetActive()->GetActiveView()
and see what you get.
The contents of each window are directX surfaces and are only assembled by the window manager in the graphics card. You'd not be able to capture this unless you switch off the new interface (DWM) or code specifically for screen capture from the DWM.
Wikipedia has a good description of the Desktop Window Manager (DWM)
Sorry, I still don't understand. You're trying to get the Print Screen key to work on all four applications? Or you're trying to get the WindowtoDIB() function to work, which takes a 'screenshot' (from within your own application) of the application itself, so that it can be saved as an image file?
Also, what do you mean with 'he Print Screen key works as expected, but it does not save the screen as a JPEG.'? Print Screen only copies to the clipboard, what happens when you paste in Paint?
If your WindowtoDIB() function only 'captures' the window you pass to it, then yes, your MDI child windows are not going to show up.
We eventually solved this by creating a different OpenGL context, and drawing everything to that. We gave up on the screen capture.