Jump to content
  • Advertisement

vanka78bg

Member
  • Content count

    42
  • Joined

  • Last visited

Community Reputation

534 Good

About vanka78bg

  • Rank
    Member

Personal Information

  • Interests
    Programming
  1. Hello! I am trying to get the current display mode resolution, refresh rate and pixel format with the following code: var bounds = output.Description.DesktopBounds; var mode = new ModeDescription { Width = bounds.Right - bounds.Left, Height = bounds.Bottom - bounds.Top }; output.GetClosestMatchingMode(device, mode, out ModeDescription match); Here 'output' is the current output device. My first question is if the above code is correct? My assumption is that I can compute the current display mode resolution from the desktop bounds returned for the current output. Does that make any sense at all or is there a better way to do so? Then I call 'GetClosestMatchingMode' to get the current display mode, assuming that if I let the pixel format and refresh rate unspecified (all zeroed out), the function would fill them out with the values from the current display mode. Is my assumption correct? The above code seems to work fine on my machine, but that might just be a coincidence. My second question is related to a particular error I am receiving. When calling 'GetDisplayModeList' and 'GetClosestMatchingMode' on my own desktop everything seems to work just fine. However, when accessing my PC via a remote desktop both methods would throw an exception with DXGI error 'DXGI_ERROR_NOT_CURRENTLY_AVAILABLE'. Is that expected or I am doing something wrong? My current workaround is to simply catch the exception and deal with it by assuming the available display modes cannot be determined, except for the current desktop resolution computed from the output bounds. Any advice or insight regarding this would be greatly appreciated! By the way, I have noticed that posting a code block would render it with black text on black background on my Chrome browser, making it extremely difficult to read, unless I copy-paste it to Notepad. Seems like a broken CSS perhaps?
  2. vanka78bg

    DX12 to Vulkan

    Porting a large game like Tomb Raider to another platform and rendering API would never be easy. The question is whether it is profitable to do the port or not. If it is profitable then a large studio could spare the resources.
  3. Many of these tips apply to game development in general, and not solely to Unity. This doesn't make them less useful with Unity, of course. Nice article!
  4. Hello!   I need to implement a simple DirectX wrapper component for an UWP app similar to how Win2D is implemented, but it should be used for rendering and animating 3D models instead. Since I do not have much experience with universal apps, I need guidance about picking the right technology for the task.   After a bit of research, I have found my options are: WRL, C++/CX, and C++/WinRT. To my understanding, WRL is a very low level C++ template library, and implementing even a simple UWP component with it would require a lot of repetitive boilerplate code - something that can be very error-prone, especially for someone with little C++ experience. The C++/CX option seems more tempting at first glance, for someone with mostly C# and Java background, requiring seemingly less boilerplate code, which is more readable and maintainable at the same time. Unfortunately, C++/CX is not strictly C++, but a custom language extension introduced by Microsoft, so my fears are it is less likely to get adequate help from the community when I get stuck with something. Then it comes the fresh new C++/WinRT, which is basically a template library implemented in standard C++, but using certain C++11 and C++14 features to achieve a friendlier API and reduce the boilerplate code needed, in comparison to plain WRL. C++/WinRT is also advertised to generate more efficient code than C++/CX in some cases. Unfortunately, being a preview technology, I am not certain how capable it is of generating complex UWP components.   There is another option - to ditch C++ entirely and go with C# instead, using a wrapper library like SharpDX. The SharpDX option seems tempting as well, considering my C# background and my previous positive experience using it in some desktop applications. The only problem is I am not certain how well SharpDX runs with UWP. The author of the library does not have enough time to fix bugs, so if something goes wrong, I am basically on my own there.   Any advice from someone more experienced in this would be greatly appreciated.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!