Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Feb 2008
Offline Last Active Today, 03:10 PM

#5314754 Fast Approximation to memcpy()

Posted by on 11 October 2016 - 04:55 PM

Lets not care about anything :)

template<class T>
void memcpyApproximation(void* dest, void* src, size_t size)
    T::memcpy(dest, src);

#5310476 DX11 black screen when windowed.

Posted by on 12 September 2016 - 11:40 AM

It works perfectly now, thank you very much to both!

What I don't understand is why now, and not before. Anyway it's solved now, thank you.

I think the Windows 10 drivers got stricter with the inclusion of DX12, because the first time I noticed this happening was in the switch from WIn 8 to 10

#5310415 DX11 black screen when windowed.

Posted by on 12 September 2016 - 02:49 AM

If you dont pass it the actual GetClientRect window size the problem I was seeing with Dedicated GPUs was that the compositing and final output to the window was actually still happening on the iGPU instead of on the dGPU.


The DX11 adapter selection should be enough to select the dGPU and you dont need to add any of the NV or AMD apis to force the selection of the GPU.

#5308629 DirectX 11 Sharpdx - Instancing - ATI Vs Nvidia

Posted by on 30 August 2016 - 04:21 AM

Thanks bud, I have uncovered a raft of small issues that didnt seem to bother the ATI Driver but were showing up.  The worst being a data alignment issue on the Matrix instance buffer.  This wasn't an issue in one SetVertexBuffer call because I was setting the alignment correctly, BUT if I used the other call, the creation of the binding was incorrectly offset.  This was causing an issue.  


I've attached the code for Sharpdx for everyone's reference in future.

    D3D11.InfoQueue m_infoQueue = m_parentDevice.QueryInterface<D3D11.InfoQueue>();

        Context.DrawInstanced(vb.m_bufferRun, a_renderCount, vb.m_startingIndex, 0);
        for (int j = 0; j < m_infoQueue.NumStoredMessages; j++)
            D3D11.Message a = m_infoQueue.GetMessage(j);


On another note, I was not setting the backbuffer resolution to the correct resolution and leaving it to be set by the window handle, this also caused an exception in relation to setting the stencil buffer in SetRenderTargets.  This also was fixed.  Thanks for your help!

Added note: still have to wait on my colleague to test the changes :)  But I feel these issues were at the core of it.  Also, Sharpdx AppendAligned doesn't seem to work and was causing an issue!

YEah NVIdia can be a bit finicky when you dont set the backbuffers to the exact client rect size, I saw extreme slowdowns in those cases (a 970M ran at the same speeds of a 4600HD).

#5308628 Getting debug information using TextOut()

Posted by on 30 August 2016 - 04:14 AM

You can use OutputDebugString() which will print to your console window in the debugger if you are using Visual Studio or you can see this by using DebugView without a debugger.

When dealing with GDI as TextOut is you need a WM_PAINT or similar message to update the screen in.

#5301201 D3D11 - Bitmap Font Rendering

Posted by on 18 July 2016 - 07:28 AM

Do you create a buffer for each quad or are you using a buffer to hold multiple quads? (the text you wrote to me indicates that you create a buffer for each quad so just want to clear that up)


You should discard the content of the old buffer when you are filling it again with new data, you could create a quad data that contains all of the transformed vertex data and then just copy that into the vertex buffer for rendering. You would need a new VB if you change font or scaling size offcourse, and even that is fixable with instanced rendering.

#5294361 Selecting the actual GPU

Posted by on 31 May 2016 - 02:28 PM

This is the info I get from DXGI on Windows 10

[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(105) : 0
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(110) : vendor id: 8086
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(111) : device id: 416
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(112) : subsytem id: 11021462
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(113) : revision: 6
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(114) : Dedicated VRAM: 112 MiB
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(115) : Dedicated RAM: 0 MiB
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(116) : Shared RAM: 8150 MiB
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(119) : description: Intel(R) HD Graphics 4600
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(105) : 1
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(110) : vendor id: 10de
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(111) : device id: 13d8
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(112) : subsytem id: 11021462
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(113) : revision: 161
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(114) : Dedicated VRAM: 2991 MiB
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(115) : Dedicated RAM: 0 MiB
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(116) : Shared RAM: 8150 MiB
[RENDER SYSTEM ADAPTER INFO:] : ..\..\Graphics\RenderSystem.cpp(119) : description: NVIDIA GeForce GTX 970M

If you set the preffered adapter to be NVidia in the control panel of the driver than DXGI will report that adapter first.

#5294341 Selecting the actual GPU

Posted by on 31 May 2016 - 12:21 PM

What Oberon_Command mentions seems to be the issue once I used the GetClientRect and used does values all started working again and it actually selects the NV chip as the one to render on, thanks for that :)


It also makes it so you can just use DXGI to select your render device, no need to deal with the extern variables like further up in the thread :).

#5291262 Clarification about shaders and Directx11

Posted by on 12 May 2016 - 03:29 AM

Maybe the driver is injecting the FF emulation shaders that it puts in for any D3D9 call, that would bind a VS at least that could just be a pass through shader seeing no MVP is set either. Which then would mean that as long as you keep the vertex coordinates in screen view you will see the triangle on screen. This would off course only work with a driver that still has support for D3D9.


This is all speculation of course.


Have you tried doing a VS graphics/Renderdoc/Intel Graphics analyser/NSight capture to see what the GPU is actually doing?

#5278324 How to find the cause of framedrops

Posted by on 26 February 2016 - 11:15 AM

You can use Renderdoc, INtel GPA, AMD codeXL or NVidia Nsight for GPU profiling. They all give you GPU timings, some will give you more info than others depending on the hardware you run it on. Renderdoc doesnt do DX9 though although I never checked this.

#5276543 They called me crazy!

Posted by on 18 February 2016 - 09:47 AM

But does it support FILE_NOT_FOUND?

I believe boosts tribool still does this wrong as well, by not defining the third states value.

#5276141 DXGI format question.

Posted by on 17 February 2016 - 10:23 AM

Beware though that clears in D3D11 don't respect the write mask.


Thats why you dont clear in this case, most of the games I work on that have shipped dont use clears if they dont have to. So if your SSAO target will cover the whole RTV dont clear it.

#5275248 Lumberyard Engine; Building a VS Solution File

Posted by on 11 February 2016 - 04:02 AM

This should tell you how to do this: https://s3.amazonaws.com/gamedev-tutorials/Tutorials/Programming-Basics-%2801%29_Setting_up_your_development_environment_v1.pdf

#5274825 Constructor + putting into an array

Posted by on 08 February 2016 - 03:28 AM

The non C++11 way is to stick the code in the constructor instead of the initialiser list, no need for 6 extra vars in that case either.

#5272017 Unique ID per type

Posted by on 20 January 2016 - 09:21 AM


That should work (except there is no such thing as raw_name in std::type_info, it's just name).


A few notes:

  • As it stands, your approach will generally "work fine" but the program is ill-formed because you don't include <typeinfo> prior to evaluating a typeid expression (your compiler should warn about that?).
  • You are caching the hash in a static variable. Keep it that way. The temptation exists to instead make the hash function constexpr. Don't do that because it will not work on the stricter compilers as the name is not a constant expression (it sure is, how could it possibly not be... but the standard and the compiler think differently) and will be vastly inferior on the more forgiving compilers (which will compile fine, but evaluate at runtime).
  • std::type_info has a member function hash_code which just looks like what you want, only better, faster, and standard. Yeah right. Don't fall for that. The hash provided by the standard not only isn't portable (that would be quite hard to do, admittedly), but it does not even guarantee that the value stays the same between different runs of the same executable. Which, frankly, is total shit.
  • The standard also provides std::type_index, which suggests by its name and its description that it could be very useful (index? as in unique number? great!), but it is really just a wrapper around std::type_info which adds operators <= and >= in terms of std::type_info.before(). Other than for using it as key in unordered standard containers, it's pretty useless.
  • Instead of using std::type_info.name(), you could use the well-known hack with a helper class that contains a static function which evaluates some flavour of __func__ or __PRETTY_FUNCTION__ or whatever you want to use, optionally adding an offset into the string constant to strip off the ugly mangling. These string constants are not constexpr either (although I think they should be, unless the name of a type can change during a program's execution which would be a big WTF, they are pretty darn constant expressions), but it is less bloat than using std::type_info (especially with GCC which has a very poor implementation), and you save yourself from including another header. I seem to remember someone even posted a complete, usable implementation of the __func__ hack on this site not long ago.
  • From the most pedantic point of view, using the __func__ hack even makes your program a little more robust. The typeid operator does not guarantee that the same type_info object is returned for different invocations in the same program with the same type. This sounds like something you could take for granted, and this is probably what happens anyway, but in the strictest sense, that's not the case. The standard merely says that some type_info (or derived) object with static storage duration is returned (and leaving unspecified whether destructors are called), and that the objects from different typeid expressions with the same type compare equal. That doesn't mean that they are equal, or that that name() returns the same value (or even the same pointer).


I wouldnt use type info for this, you can do this through the preprocessor with something like:

//create a hash based of a type name
inline uint64_t HashTypeName(const char* str)
  //djb2 algorithm from here:
  uint64_t hash = 5381;
  int c;
  while((c = *str++) != 0)
    hash = ((hash << 5) + hash) + c; /* hash * 33 + c */
  return hash;
#define HASHTYPE(type)\
    inline TypeHash HashType()\
      //a way of generating a hash that is cross platform\
      static TypeHash hash = HashTypeName(#type);\
      return hash;\
Class MyType

This needs less template magic than your solution and is generally easier to use because typeid names contain namespaces and such which can make it hard to figure out what a hash belongs too when you are debugging the code. In my case you can just run the HashTypeName("MyType") function in the watch window to find the hash of your type when on a breakpoint.


Alot of game engines have stuff like Runtime type info turned off in compile settings which will make typeid not work for dynamic types.


If you use a constexpr hash function all of the preprocessor stuff and dynamic lookup of typeid at runtime will be change to static compile time implementations.