I have a UWP app running on Xbox One. The app uses mouse pointer for navigation. It works well. One screen contains a video player that can be set to run fullscreen. When in fullscreen video playback, the mouse pointer does not disappear.
How can I make the mouse pointer programmatically disappear when the player enters fullscreen and appear when it exits full screen?
I found How Can I Disable Pointer Mode For Xbox One (C#, UWP) but it only handles global pointer set when the app starts.
Found a working solution, to hide the cursor, do Window.Current.CoreWindow.PointerCursor = null. First store the value somewhere of course so you can restore it when you need the cursor back.
Have you tried wrapping the media player in a custom user control on which you could say RequiresPointer = RequiresPointer.Never; whenever the player enters fullscreen?
I don't have an Xbox here at the moment to test it and it's been a while since I've wrote something for it. But this approach would be my first guess.
I am trying to make a custom Startup window Or Before start Window for unity3d Standalone.
I do not know how to start Working on It i have Researched but got noting that can point me on the direction or a Kick start.
Is it even Possible to Do it As i have seen option in Player Settings--> Display Resolution Dialog-->Hidden By default But how dose it work and how i can set up my own window
If you have the Personal edition, you can't do a true customized start screen, as per their licenses page: https://unity3d.com/get-unity. You also cannot turn off the default Unity startup screen without using the Professional edition.
The Player Settings -> Display Resolution Dialog -> Hidden by Default options is to enable/disable a screen allowing the player to set the resolution before game start. Allowing the player to do this can have some undesired effects, depending on how you've set up your game's resolution. On this resolution screen, you can set a splash image by scrolling down the Player Settings inspector a bit.
To make a pseudo-startup screen that occurs after the actual Unity startup is not actually difficult. Take the image you want for your startup window, put it on a quad. Set your camera so that the quad fills the whole camera space. Add some light and you're done. You can add effects or animation as well. There are a number of other ways but this is probably the easiest.
Edit: I only have the Personal edition myself so I can't confirm any of the stuff in the following link works firsthand, but I expect you will find it and/or the links it contains to be very helpful in your efforts (the links referenced in it give quite a few worthwhile looking suggestions to accomplish it that I am unable to test):
https://gamedev.stackexchange.com/questions/72087/can-i-legally-remove-the-default-unity-splash-screen-by-removing-it-from-the-apk
I am working on a multi-touch app using Monogame, where multiple users can work on a larger multi-touch screen with separate documents/images/videos simultaneously, and I was wondering if it's possible to make gestures "context-aware", i.e. two fingers pinching a document on one side of the wall shouldn't affect somebody panning the other side of the wall.
The way Monogame works is, all input points are translated into gestures, which can be read using:
if (TouchPanel.IsGestureAvailable)
{
var gesture = TouchPanel.ReadGesture();
// do stuff
}
Is there a way to make gestures limited to a certain point on the screen, or do I need to implement this myself? For example, by looking at the source code, it appears that the TouchPanelState class does all the work, but unfortunately its constructors are internal.
That feature is not built in to MonoGame, as it is not part of original XNA. Essentially you'd want more than one 'logical' TouchPanel defined by its sub-rectangle of the window. However TouchPanel is static, hence there is only one for the whole game in default XNA.
The good news is that MonoGame does its own gesture recognition. So, the code is there, you just need to make some changes to MonoGame.
Eg...
-Make TouchPanel a non-static class that can be allocated with a given subrect.
-Add non-static versions of all TouchPanel methods.
-The static methods redirect to a singleton/instance of TouchPanel, preserving the old API.
...now you can optionally allocate more TouchPanel(s) that AREN'T the whole screen.
Note: This doesn't help you, but MonoGame does allow you to have more than one OS window (on windows only afaik) in which case the static TouchPanel is the first window and there is a separate API for accessing touch input / gestures for any additional windows.
I have been fooling around with screen capture for awhile now and I managed to capture the entire screen, certain areas on the screen etc...
But when I go into a game and try to capture the screen, it completely ignores the game and instead, captures the desktop (or whatever is behind the game window).
Another interesting fact is that the same thing happens with the PrtScn button.
Any ideas on how to capture a game's screen?
The screen capturing technique you are using works well for capturing things that aren't hardware accelerated. I suspect you'd have the same problem trying to capture a movie frame in Windows Media Player.
The solution is the do a screen capture from the hardware itself using DirectX. This article explains how to do that with some code and a managed wrapper around DirectX called SlimDX.
EDIT
If Slim DX doesn't work for you, then you'd just have to find another managed wrapper around Direct X. I don't think you are going to be able to do the screen capture without working at the hardware level, and DirectX is the means of doing that on the Windows platform.
I'd like to make an animated desktop background for Windows 7 using DirectX. I'm using C#, SlimDX and a couple of P/Invoke imports of Windows API functions. I'm not brilliant with native Windows programming, but I've had a poke around online and I believe what I need to do is either:
1) Find the handle of the window containing the dekstop wallpaper, hook it up to a DirectX device and draw into it.
2) Make a new output window, and insert it above the desktop wallpaper but below the desktop icons.
I've tried both these, but neither seems to work. If I navigate the Window heirarchy starting from the handle returned by GetDesktopWindow(), I can go Desktop -> WorkerW -> SHELLDLL_DefView -> SysListView32. If I hook up a DirectX device to this handle, I can draw over the entire desktop, but it also covers the icons. If I create a Windows form, set its parent to SHELLDLL_DefView using SetParent() and then use SetWindowPos to play with its Z-order I can only seem to get it to go either behind the desktop wallpaper or in front of the desktop + icons.
It looks as though the desktop wallpaper is background to the folder view containing the icons, and therefore what I am trying to do cannot work. The only solution then would be to not use the desktop for icons, or to find some alternative, e.g. overwriting the desktop then overlaying a transparent window containing a view of the contents of some folder.
Does anyone have any idea of what I should be doing, or even whether what I want to do is possible? It seems you can draw to the desktop background using the GDI (as I believe the wxSnow program does), and I've seen something similar to what I want done by VLC Media Player under Windows XP with its DirectX wallpaper mode (interestingly, I can't seem to get this option enabled on my system).
Thanks!
Looks like this might not be possible. See this link:
http://social.msdn.microsoft.com/Forums/en-US/winforms/thread/69839cec-3424-4300-9ac3-486b8c2fe492
If you need to draw some controls
between the desktop background and
desktop icons, an alternative step is
below:
Create your user control in a windows control library.
Embed the user control in an ActiveX control.
Embed the ActiveX control in a web page.
Enable active desktop and set the web page to be your desktop
background.
This can only be done in XP since
Vista doesn’t support active desktop.
Another post there suggests that you could possibly do this with the background of an explorer window - if you could get the handle of the window that constitutes it. Of course, if that's possible then it may be possible also to get the handle of the desktop window behind the icons.
Update: Well, so far the only thing I've found that could possibly "work" is just creating Bitmap files and changing the wallpaper over and over again (I suspect this would be slow, as you mentioned).
That full screen image must be resident in memory somewhere, but there may be no way to access it without some serious low-level memory hacking. I'm going to keep looking.
Update 2: This might work, but I'm not sure:
http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/4af734fb-d2c1-414b-a9f1-759b76692802
The meat of it is this:
HWND p = FindWindow("ProgMan", NULL);
HWND s = FindWindowEx(p, NULL, "SHELLDLL_DefView", NULL);
HWND dtw = FindWindowEx(s, NULL, "SysListView32", NULL);
HDC hdc = GetDC(dtw);
You're basically starting with the ProgMan window and drilling down from there to the desktop wallpaper ("SysListView32", I guess). I'm going to try this out.
Update 3: No go - the above code does get the desktop's DC, but it's above the icons so BitBlt draws over them. It's not drawing to the Screen, though, because I can draw underneath an open form without covering it, so that's progress at least.
I'm guessing that there's some window available other than "SysListView32" that is the desktop behind the icons, or there's more than one "SysListView32" window.
Update 4: I'm pretty sure something using this would work:
http://msdn.microsoft.com/en-us/library/bb761155(v=VS.85).aspx
http://msdn.microsoft.com/en-us/library/bb774742(v=VS.85).aspx
Basically, it's an API method that you call, passing in a structure which include a bitmap handle. If the call is successful, that bitmap becomes the desktop.
Does DirectX expose frames as bitmap handles (GDI-compatible), or does it only expose the DC? In my case, my animation is already an array of GDI-compatible bitmaps, so I would have no trouble using this approach. If this is the only route, and DirectX doesn't expose the bitmap handles (and I don't think they would), then for each frame you would have to create a new GDI bitmap, which would slow things down quite a bit.
Actually, there might be an easier way, although I'm not sure it would work. Once you get the handle to the actual bitmap of the wallpaper, you can select it into a device context using SelectObject, and then just use that device context as the BitBlt destination. You might have to send a repaint instruction to the desktop, though, which might trigger the icons to be repainted every time.
How about you do some work here? :)
I guess you could get quite a few frames per second by dynamically generating bitmaps and constantly setting these as the desktop background. However, this sounds unnecessarily (almost stupidly) heavy for the CPU. Update: Now that I think about it (it was late when I wrote this), the main problem with such an approach is that you need to write and read bitmaps from the hard drive every time a new frame is to be displayed. This is not feasible.
Are you really using the desktop for icons? In Windows 7 the start menu search function and the new taskbar has made me not use the desktop for icons.
Just an idea
It might be possible to alter the desktop window, by means of SendMessage(GetDesktopWindow, WM_SOME_MESSAGE, wParam, lParam), so that you can achieve what you want. I might investigate this further tomorrow (currently 3 am, local time).
I've done some animation of alpha blended windows that are always on the top of the Z-Order. One idea would be to ignore trying to modify the desktop bitmap and just draw your stuff as a layered window but manage the ZOrder somehow so it is always the bottom-most, non-desktop window (perhaps by strategically calling Form.SendToBack() or something at the right times).
Depending on what you are trying to do this may give you the same effect of animating the desktop.