I'm currently trying to re-write my binder between Ogre and SDL in my game engine. Originally I used the method outlined in the Ogre Wiki here. I recently updated my version of SDL to 1.3 and noticed the "SDL_CreateWindowFrom()" function call and re-implemented my binder to allow Ogre to build the window, and then get the HWND from Ogre to be passed into SDL.
Only one window is made and I see everything renders properly, however no input is collected. I have no idea why. Here's the code I am currently working with (on windows):
OgreWindow = Ogre::Root::getSingleton().createRenderWindow(WindowCaption, Settings.RenderWidth, Settings.RenderHeight, Settings.Fullscreen, &Opts);
size_t Data = 0;
OgreWindow->getCustomAttribute("WINDOW",&Data);
SDLWindow = SDL_CreateWindowFrom(&Data);
SDL_SetWindowGrab(SDLWindow,SDL_TRUE);
I've tried looking around and there are a number of people that have done this to one degree of success or another(such as here or here). But no one seems to comment on handling the input after implementing this.
I originally thought that maybe since SDL does not own the window it wouldn't collect input from it by default, which is reasonable. So I searched the SDL API and only found that one function "SDL_SetWindowGrab()" that seems to relate to input capture. But calling that has no effect.
How can I get SDL to collect input from my Ogre-made window?
It has been a while, but I figured I would put in the answer for others that may need it. It turned out to be a bug/incomplete feature in SDL 1.3. The "CreateWindowFrom" method wasn't originally intended to be used exclusively as an input handler. At the time of this writing I know myself and another on my team wrote patches for Windows and Linux that permitted this use to work and submitted those patches to SDL.
Related
As used in DebugHitTestBounder in SampleApp; I have subclassed SkBounder and installed in my canvas (created in each draw) in order to find what is drawn under mouse clicks but the onIRect method is never called by the drawing routines. The commit method is called as expected (but I don't need it, I need one with a display-space converted rectangle parameter). I debugged the code, found out draw loops are managed in canvas.cpp in one place with macros (LOOPER_BEGIN and LOOPER_END) and found no place in the drawing calls that calls bounder's onIRect. Am I doing something wrong?
Note: I am using code from 2 months old master branch of git repo with XCode 4.6 in Mac OS 10.8.x. Project files are created via gyp.
Apparently, SkBounder only works on the raster backend, I was using the accelerated (GL) backend.
I'm looking for a way to get the actual available screen space, similar to the Cocoa NSScreen visibleFrame method, but on Linux. That would be the displays resolution minus the menu-bar/dock/title-bar.
I'm using SDL2 for the windowing code, but can't find anything within the library documentation that might help.
SDL_GetWindowMaximumSize seems like the closes candidate, but this is returning 0,0 for me.
Any ideas?
Use SDL_GetDesktopDisplayMode(),( previously SDL_GetVideoInfo() in
SDL1.2)
https://wiki.libsdl.org/SDL_GetDesktopDisplayMode
I was happily improving my C++-program where I read videos via directshow. Now I tried to also write videos which was also nicely working.
Then came the search for an appropriate codec (thought about vob/ogg)...
However, suddenly today the video was displayed really slowly.
And now that I uninstalled any additional codecs I installed before, the video won't play at all.
The reason seems to be CComQIPtr< IMediaSeeking, &IID_IMediaSeeking > pSeeking( pGraph ); and hr = pSeeking->SetPositions( &Startzeit, AM_SEEKING_AbsolutePositioning,NULL, AM_SEEKING_NoPositioning ); gives an error, SetPosition is not supported at that time... acutally at any time.
also hr=pSeeking->GetDuration(&duration) returns 0 and the corresponding AM_MEDIA_TYPE mt; I use to get the framepersecond has an empty format-type. (pbFormat is Null).
Did I unintentionally installed/uninstalled something important?
Have you heard of similar problems?
As I said, some days ago the same video and source-code was working fine (I commented by changes out by now).
I would like to give you more source-code but it is kind of long but if you think it would be helpful I will add it of course.
Regards,
Julian
Here is the source-code: http://pastebin.com/jMdWejH9
It's of course only a part of the whole code, but I think this is the main part as here are all filters inserted.
Keep in mind that this actually worked until some days before!^^
The first part is the variable-deklaration (all important variables as fas as I could tell, the second is the function called)
If you render a file in DirectShow, the framework uses the installed codecs/filters in the system. If you remove some codecs it takes another or breaks because it can't render. To know wich filters the framework uses you can try to render the file in GraphEdit or GraphStudioNext. (Just drop the file on one of these programms and see the filtergraph). We got the best results with the codec pack ffdshow-tryouts and the Haali Media Splitter for our player.
I want to create an editor in C++ using SDL & OpenGL and have decided to use the win32 api to access the window bar menus (for file, edit and so on) and it seems quite simple, but I don't know how to create a "file-> open" file browser/loader... I'm hoping it's quite simple but I'm finding it hard to look up any tutorials on google because of the phrasing...
I just want to have an "open" or "import" option in the file menu that will open a standard windows file browser... then grab the file location, place it into a string then pass it into a function that is activated by selection a file... (I hope that makes sense).
The method I'm using to create the win32 menus are from this post:
http://www.gamedev.net/topic/400677-sdl-with-a-win32-menu/
Half way down the page there is a comment by "caseyd"... that's how I learnt how to use it, so that is my current understanding of win32 menus in SDL... I wanted to post the code here, but I didn't know how to paste it here in codeblocks without reformatting every line.
I'm hoping this is quite simple... Thanks to anyone who can teach me how or just point me in the right direction.
Oh, and I'm not trying to convert this to other operating systems, I just like SDL.
Use GetOpenFileName(). Note that that function blocks until the user selects a file, so if you want to continue rendering etc. in the background, make sure to run it on a separate thread.
Suppose I have an OpenGL game running full screen (Left 4 Dead 2). I'd like to programmatically get a screen grab of it and then write it to a video file.
I've tried GDI, D3D, and OpenGL methods (eg glReadPixels) and either receive a blank screen or flickering in the capture stream.
Any ideas?
For what it's worth, a canonical example of something similar to what I'm trying to achieve is Fraps.
There are a few approaches to this problem. Most of them are icky, and it totally depends on what kind of graphics API you want to target, and which functions the target application uses.
Most DirectX, GDI+ and OpenGL applications are double or tripple-buffered, so they all call:
void SwapBuffers(HDC hdc)
at some point. They also generate WM_PAINT messages in their message queue whenever the window should be drawn. This gives you two options.
You can install a global hook or thread-local hook into the target process and capture WM_PAINT messages. This allows you to copy the contents from the device context just before the painting happens. The process can be found by enumerating all the processes on the system and look for a known window name, or a known module handle.
You can inject code into the target process's local copy of SwapBuffers. On Linux this would be easy to do via the LD_PRELOAD environmental variable, or by calling ld-linux.so.2 explicitly, but there is no equivalient on Windows. Luckily there is a framework from Microsoft Research which can do this for you called Detours. You can find this here: link.
The demoscene group Farbrausch made a demo-capturing tool named kkapture which makes use of the Detours library. Their tool targets applications that require no user input however, so they basically run the demos at a fixed framerate by hooking into all the possible time functions, like timeGetTime(), GetTickCount() and QueryPerformanceCounter(). It's totally rad. A presentation written by ryg (I think?) regarding kkapture's internals can be found here. I think that's of interest to you.
For more information about Windows hooks, see here and here.
EDIT:
This idea intrigued me, so I used Detours to hook into OpenGL applications and mess with the graphics. Here is Quake 2 with green fog added:
Some more information about how Detours works, since I've used it first hand now:
Detours works on two levels. The actual hooking only works in the same process space as the target process. So Detours has a function for injecting a DLL into a process and force its DLLMain to run too, as well as functions that are supposed to be used in that DLL. When DLLMain is run, the DLL should call DetourAttach() to specify the functions to hook, as well as the "detour" function, which is the code you want to override with.
So it basically works like this:
You have a launcher application who's only task is to call DetourCreateProcessWithDll(). It works the same way as CreateProcessW, only with a few extra parameters. This injects a DLL into a process and calls its DllMain().
You implement a DLL that calls the Detour functions and sets up trampoline functions. That means calling DetourTransactionBegin(), DetourUpdateThread(), DetourAttach() followed by DetourTransactionEnd().
Use the launcher to inject the DLL you implemented into a process.
There are some caveats though. When DllMain is run, libraries that are imported later with LoadLibrary() aren't visible yet. So you can't necessarily set up everything during the DLL attachment event. A workaround is to keep track of all the functions that are overridden so far, and try to initialize the others inside these functions that you can already call. This way you will discover new functions as soon as LoadLibrary have mapped them into the memory space of the process. I'm not quite sure how well this would work for wglGetProcAddress though. (Perhaps someone else here has ideas regarding this?)
Some LoadLibrary() calls seem to fail. I tested with Quake 2, and DirectSound and the waveOut API failed to initalize for some reason. I'm still investigating this.
I found a sourceforge'd project called taksi:
http://taksi.sourceforge.net/
Taksi does not provide audio capture, though.
I've written screen grabbers in the past (DirectX7-9 era). I found good old DirectDraw worked remarkably well and would reliably grab bits of hardware-accelerated/video screen content which other methods (D3D, GDI, OpenGL) seemed to leave blank or scrambled. It was very fast too.