Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

2268 Excellent

1 Follower

About SoldierOfLight

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. SoldierOfLight

    Questions about D3D12_INPUT_ELEMENT_DESC

    The semantic names of non-system-value inputs to the vertex shader don't have any meaning. It's holdover from DX9 that a lot of apps use POSITION or TEXCOORD, where the names did actually matter. AlignedByteOffset of 1 probably won't work, unless your data is a single byte. The 'aligned' in the name means that the value needs to be aligned to the size of the element you're trying to read. So for a 4-byte value, a value of 0, 4, or 8 is valid, but 1 is not. Unless you're intentionally leaving space for data that a different input layout will reference (e.g. a shadow pass only needs one value, but the same vertex buffer will also be used for real rendering with more data), you should just use the APPEND_ALIGNED_ELEMENT value. I'll let someone else comment on best practices.
  2. SoldierOfLight

    CBVs in Descriptor Heap?

    Positive. A root parameter of type CBV is a root CBV. A root parameter of type descriptor table contains ranges, which may include CBVs in those ranges.
  3. SoldierOfLight

    CBVs in Descriptor Heap?

    That says that you made root parameter 0 a root CBV, not a descriptor table of CBVs.
  4. SoldierOfLight

    How to create large upload buffers?

    Sounds like the problem is coming from the driver. What driver(s) have you tried this on?
  5. Depends on the sizes we're talking about here. Generally, using Map(WRITE_DISCARD) on a CB results in re-allocating the entire buffer. If you're talking about a few bytes per texture, then it's probably more efficient to cram them all together, as individual CBs would waste a lot of memory in padding. If you're talking about a few hundred bytes per texture, it probably makes more sense to only re-allocate/bind the one that's relevant at the moment. The actual hardware implications of "binding" CBs and textures vary across different hardware, even on the same vendor, but generally binding a CB is very cheap, while binding textures is less cheap. If you're interested in not needing to change texture bindings as often, you can take a look at DX12 with its bindless (read: bind fewer times, not never) options. But I'd recommend profiling before deciding that changing your bindings is the bottleneck.
  6. You're probably looking for ID3D11Fence. Treat your D3D11 device as if it was another D3D12 command queue.
  7. SoldierOfLight

    DirectInput GUID compare

    A GUID is 128 bits. A DWORD is 32 bits. You can't assign a GUID to a DWORD.
  8. Some drivers are mature enough to claim support for SM6 for all applications, but other drivers are only mature enough for developers to test SM6 on them. For these less mature drivers, the app needs to explicitly opt in to experimental mode, and must be running on a machine with Developer Mode enabled. If you query for SM6 support, the answer you get may change based on whether or not you've enabled experimental SM6 support.
  9. Ah, now I understand what you're looking for, you want to avoid stretching. You're looking for DXGI_MODE_SCALING, but note that there's only STRETCH and CENTERED. Fullscreen exclusive doesn't give you the option for aspect ratio preserving stretch. Sounds like you want a borderless fullscreen window, using DXGI flip model (FLIP_DISCARD instead of DISCARD), using DXGI_SCALING_ASPECT_RATIO_STRETCH. That's the only way I know of to get an aspect ratio preserve.
  10. Pretty sure your problem is that you're missing the DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH flag. Not sure what that looks like in SharpDX though.
  11. SoldierOfLight

    Failing to create shader - help

    Shader model 5.1 isn't supported by DX11 at all, only DX12. There is no FL11.3, and successfully querying the ID3D11Device3 interface indicates that your OS has "DX11.3" but you don't actually need to query that interface to use those features - unless they're only available on that interface.
  12. SoldierOfLight

    dx11 api dx12 implementation

    Pretty sure @ZachBethel is right: https://msdn.microsoft.com/en-us/library/windows/desktop/dn913195(v=vs.85).aspx
  13. The video memory manager I mentioned lives in DxgMms1.sys or DxgMms2.sys. It's responsible for allocating and managing memory, yes. I doubt that the 4GB limit is well-documented anywhere, considering that up until recently it wasn't a limitation that anybody could really run into.
  14. I believe that the graphics memory manager currently has a limit on any individual allocation being less than (4GB - 64KB), regardless of whether it's coming from system memory or video memory. Try using multiple heaps and mapping them into a reserved resource to get something larger than 4GB.
  15. SoldierOfLight

    VSSetConstantBuffers1 Problems

    That's correct, you need to use 256-byte offsets, which is 16 "constants" where each constant is 4 floats (16 bytes).
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!