Issues with several samples

Oct 26, 2011 at 8:01 PM


I really appreciate your engine (framework?) as well as your new DX11 book (probably the best book on modern DirectX in general around).

However, since recent code revisions I am having serious issues with some sample programs. I will try to give the best information concerning them as possible.

Firstly, some general facts: I compile the code on Windows 7 SP1 64bit with Visual Studio 2010 SP1 Express (DirectX SDK June 2010) and run it on GeForce GTX460 1GB with 285.62 drivers (clean installation, before I had version 285.38 and problems were exactly the same). It doesn't matter if the build is Debug or Release - it doesn't change anything.

Since revision 70212 the AmbientOcclusionI renders the scene and on top of it some kind of buffer containing the scene colored mostly with green and kind of orange shade (sorry, I am the beginner in graphic programming, so I don't really know what exactly it is). What's more, the buffer is rendered like a 3D object that was put in the environment - other objects are clipping through it during the rotation of the whole scene (but this buffer doesn't actually move). Here is the image, I guess my description isn't really helpful:

Also while exiting the sample, if it was built in debug mode, the message appears:

---------------------------Microsoft Visual C++ Debug Library---------------------------Debug Error!
Program: ...0656\trunk\Hieroglyph3\Applications\Bin\AmbientOcclusionI.exe
HEAP CORRUPTION DETECTED: after Normal block (#1916) at 0x01F3BDE8.CRT detected that the application wrote to memory after end of heap buffer.

(Press Retry to debug the application)---------------------------Abort   Retry   Ignore   ---------------------------

Sometimes even after closing the sample the actual process doesn't shut down (AmbientOcclusionI.exe is still running).


Since revision 70256/70257 the DeferredRendering sample after launching it was showing only black screen and nothing else - sometimes just after it started I could see the correct image (rendered scene) for a fraction of a second. I could fix this issue by uncommenting this line: m_pRenderer11->SetMultiThreadingState( false ); in App.cpp file and rebuilding the project.


Since revision 70656 samples DeferredRendering and LightPrepass both crash as soon as I launch them (DeferredRendering.exe/LightPrepass.exe has stopped working, Windows is checking for a solution to the problem...) - window shows with black background and then the crash occurs. Uncommenting the line m_pRenderer11->SetMultiThreadingState( false ); doesn't help. Debug output from Visual Studio for DeferredRendering sample:

(...) First-chance exception at 0x0119d4f6 in DeferredRendering.exe: 0xC0000005: Access violation reading location 0x00000004.

Unhandled exception at 0x0119d4f6 in DeferredRendering.exe: 0xC0000005: Access violation reading location 0x00000004.

Call stack:

> DeferredRendering.exe!Glyph3::TArray<Glyph3::VertexElementDX11 *>::count()  Line 93 + 0x3 bytes C++ 

 DeferredRendering.exe!Glyph3::GeometryDX11::CalculateVertexCount()  Line 271 + 0xb bytes C++ 

 DeferredRendering.exe!Glyph3::GeometryDX11::LoadToBuffers()  Line 360 C++ 

DeferredRendering.exe!Glyph3::ViewLights::ViewLights(Glyph3::RendererDX11 & Renderer)  Line 124 C++ 

 DeferredRendering.exe!Glyph3::ViewDeferredRenderer::ViewDeferredRenderer(Glyph3::RendererDX11 & Renderer, std::tr1::shared_ptr<Glyph3::ResourceProxyDX11> RenderTarget)  Line 150 + 0x2f bytes C++ 

 DeferredRendering.exe!App::Initialize()  Line 232 + 0x4f bytes C++ 

 DeferredRendering.exe!WinMain(HINSTANCE__ * h_Inst, HINSTANCE__ * h_PrevInst, char * lpcmdline, int ncmdshow)  Line 72 + 0xf bytes C++ 

 DeferredRendering.exe!__tmainCRTStartup()  Line 547 + 0x2c bytes DeferredRendering.exe!WinMainCRTStartup()  Line 371 kernel32.dll!749a339a()   [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]   ntdll.dll!76fe9ed2()   ntdll.dll!76fe9ea5()


From autos window:

+ this 0x00000004 {m_iQuantity=??? m_iCapacity=??? m_aData=??? } const Glyph3::TArray<Glyph3::VertexElementDX11 *> * const


The line of code shown in the code window:

template <class T>

int TArray<T>::count() const


---------> return( m_iQuantity );



I hope I could help.


Oct 26, 2011 at 8:10 PM

Also, I forgot about one more issue:

SkinAndBones sample doesn't show the displaced skinned actor, though it seems that animation for it is played normally. One more problem is that help text in this sample is not visible.



Oct 26, 2011 at 9:20 PM

Hello Sephirothusi,

Thank you for bringing these issues to my attention.  I will start investigating them right away, and I'll update here as I correct them.  Since there has been quite a few changes lately with the shared_ptr setup, I suspect that is where the issue lies.

Regarding the AmbientOcclusion sample, that object is a visualization of the depth/normal buffer texture.  I had corrected a bug in its implementation and forgot to switch off the display of it... (sorry for that).  I'll disable it by default in the next release.

The other topics I will report on as I make progress on them.  Thanks again for letting me know, and if you see other issues please let me know as well!

- Jason

Oct 26, 2011 at 10:19 PM

I just pushed a new commit to the repository for the following two issues:

- I added a property to the render view for the ambient occlusion sample to allow switching the visualization object on and off.  This removed the strange floating box from the output rendering :)

- I also found the bug in GeometryDX11 class regarding the setting of the primitive type.  This was a recently changed area of the code, and I inadvertently introduced the bug...  It should be corrected in the latest release.

I'll continue looking into the other topics tomorrow...

- Jason

Oct 27, 2011 at 5:48 AM

I have tried the newest revision 70769 with the mentioned fixes and here's what I have observed:

- Yes, floating box in AmbientOcclusionI sample is now gone. :)

- Unfortunately it appears that the issue with SkinAndBones sample is still there, I get exactly same result as with previous revision. :( Could it be a problem with newer NVidia drivers (Battlefield 3 DX11 tweaks interfering with Hieroglyph 3 perhaps)?

Of course other issues mentioned previously are still there, but that's expected. ;)

Greetings and thank you for your help and hard work on the engine. :)

Oct 28, 2011 at 5:13 AM

It is quite possible that the issue is with the driver.  Have you tried running with the reference rasterizer yet?  There are instructions in the documentation tab of this site that describe how to do it.

Oct 28, 2011 at 4:05 PM

Well, I have just tried and actually after launching the sample with D3D_DRIVER_TYPE_REFERENCE driver type a window with black background shows (no image whatsoever) and to addition it's not responding (application hangs and needs to be closed).


Oct 28, 2011 at 8:47 PM

Believe it or not, that is actually what is supposed to be happening!  When you run with the reference device, the GPU is simulated with the CPU.  Due to the high amount of calculations required, it can take even a couple of minutes to generate a frame (it depends heavily on your CPU).  Try running it again and let it run for 5 or 10 minutes - and then check to see the contents of that window.  The scene will be generated, but you will be running at an extremely low frame rate (which is why it seems unresponsive too).  If the displaced cone appears on the right hand side, then the issue with the sample is likely a driver issue.

I expect this to be the case, since it seems to be running ok on my end.  I'll continue working on the other issues while I wait to hear about your results.

- Jason

Oct 28, 2011 at 9:04 PM

I have just done as you said and, of course, you were right - the image finally showed and was correct: the displaced cone was visible, as well as the white help text. So it seems that's really a driver issue. As a developer of the engine, do you have any possibility of correctly reporting this problem to NVidia?


Oct 30, 2011 at 7:35 AM

Sure, I can try to contact them and see how to report the driver bug.  Thus far I haven't had much success reaching them, but I'll try going through the developer channel and see if that works better.

I also posted another update that should correct the DeferredRendering and LightPrepass errors that you were seeing.  This was caused by a change introduced with the shared_ptr update, where some of the geometry objects weren't created.  I have also added error messages to indicate when this occurs.  Please try these samples out again, and let me know what you see.  Also, if you see similar issues as you saw with the SkinAndBones sample (i.e. the text not showing up) then try running it with the reference device once - since they all use the same basis for the rendering then it seems likely that they will also share the driver issue too.

Anyhow, I'll let you know what I find out on the Nvidia side...  Thanks again for reporting the bugs!

- Jason

Oct 30, 2011 at 5:19 PM

Thanks to the newest update DeferredRendering and LightPrepass samples don't crash anymore and situation is now the same as earlier - LightPrepass works just fine, while DeferredRendering shows only black window, although sometimes I can see the rendered image for less than a second. I have also checked DeferredRendering sample with reference device and it was working without problems, so the issue seems to be driver-related. As I mentioned before, the problem with DeferredRendering started with 70256/70257 revision, when it was refactored to make use of the multithreading system. Could it be that newer NVidia drivers have some problems with it (Driver Command Lists?)?

Greetings and thank you for all the help so far!

Oct 30, 2011 at 6:00 PM

That would be the most likely suspect, since when you disable MT mode it seems to work out ok.  Also, I haven't updated the LightPrepass sample to work in parallel yet, so that also makes sense.  I submitted the questions to Nvidia, and they promised a response within 24 hours (we'll see if that holds up).  For what its worth, there were also issues with the AMD driver, but they appear to have been corrected with their latest driver release...  Hopefully the same happens for the nvidia drivers!

Thanks for hanging in there, and I'm sure we will work out the bugs sooner or later ;)

Oct 30, 2011 at 11:56 PM

Ok, I will wait patiently for further information, hopefully NVidia will be able to fix the issue. :)

In the meantime, I would like to ask about few things (I don't want to make a separate discussion for them, because it's nothing really important or urgent). Namely:

- converting LightPrepass sample to multithreaded rendering

- finishing Hieroglyph documentation

- x64 build target

- adding hlsl files to respective VS projects (it seems that the next version of Visual Studio will associate itself with hlsl type files, so this would be a good step for the future)

- converting all functions and references to MaterialDX11 objects to use smart pointers instead of naked pointers

- converting all samples to use the new way of setting up basic engine parameters (still not all samples use this cleaner method of doing this)

bool App::ConfigureEngineComponents()
	return( ConfigureRenderingEngineComponents( 800, 600, D3D_FEATURE_LEVEL_11_0 ) );


I am not pushing you or demanding anything. Some of those things are relatively easy and quite fast to do (adding hlsl files, converting samples to the new way of setting up startup parameters...), some others are not (well, at least for me, like converting LightPrepass sample to multithreaded rendering), some are less needed, while some would be really very welcomed (documentation :)). I also know that some of them were already brought up earlier by others (adding hlsl files, x64 build target...) and some are already planned by you for a very near future (MaterialDX11 shared pointer...). Of course, some of those changes could be easily done by users, but it would be nice to have them out of the box, especially when downloading clean revision of code. I know that you probably have much more important things to do, I just wanted to remind about some little changes that would be nice, to show there are more people interested in them and just hope you will find time in the future to finish them. But I want to say this again: I am not demanding anything nor pushing you, those are just my (and of course not only my) little suggestions, you can ignore them and take care of something more important. ;)

Also, I have 2 questions: where does number 3 come from in Hieroglyph 3 name and do you plan to upgrade your engine (well, mainly it possibilities and maybe adding some useful samples) to DX11.1 in the future (next year, Windows 8 release?)?

Greetings, sorry for the off-topic, I hope I haven't irritated you with this post.

Oct 31, 2011 at 6:11 AM


Thank you for bringing the list up - there is indeed some things to finish up, and I will be progressing on these topics as time allows.  The next couple of days should see some good progress, but as you mentioned, there are some things that are long term (the documentation will take a bit more time than adding the hlsl files to the projects!).  However, don't be afraid to let me know about these things - there is nothing wrong with pointing out open issues!

The 3 in Hieroglyph 3 refers to the fact that it is the third major revision of the library.  It started out with D3D9, then moved to D3D9/11, and finally to its current form with D3D11 only.  It has been in development for a long time now (around 10 years...) with progress usually coming in spurts, but overall progress more or less all along the way.  I do indeed plan to support D3D11.1 and Win8, but that will be a little bit closer to the release date before I start dabbling with that.

I also have some other samples in mind to add, but just haven't found the time to do them yet.  If you have any wishlist samples, then let me know!

Oct 31, 2011 at 11:12 AM

Well, there are actually two things that I would find very helpful - sample implementing tile-based deferred rendering which utilizes compute shaders (and it would be great if there would be DX10/CS4.0 compatible rendering path) and sample showing how to implement the dirty lens effect as in Battlefield 3 (by that I mean dirt/dust/water/etc particles that are visible on those parts of the camera that are directly lit by a light source/lens flare. I know that may be trivial, but as I said before, I am a beginner in the world of graphics programming and actually I couldn't find any information how to implement this effect. I only suppose that there should be some bokeh texture that is rendered on final image with alpha channel somehow controlled by visible light sources - but how to do this is an unknown to me. How can I check whether the given pixel is affected directly by light?).

Also, I would like to ask about two performance considerations - as far as I know using smart pointers and especially exceptions (both enabling them in compiler options and using them in the code) are very bad ideas when it comes to engine programming (performance-wise). Am I right or maybe the difference in speed of resulting code/program isn't really affected that much?

10 years of development, I am impressed and bet it was a great way of gaining experience. :)


Oct 31, 2011 at 9:35 PM
Edited Oct 31, 2011 at 9:36 PM

I have been thinking of writing a sample that uses the tile based rendering - so that is likely at some point in the future.  I haven't seen the dirty lens effect (I haven't gotten a copy of BF3 yet) so if you can link to a picture of it then it would be helpful.

Regarding the performance topics, I haven't ever used exceptions on any of my projects so it is hard for me to say how much of an impact it will have.  The general knowledge is that it does degrade performance, but I don't have any experience with it.

Regarding smart pointers, I think it depends on what you are talking about.  If you use a smart pointer to reference an item that is only accessed once per frame, then it will have a relatively negligible effect on performance.  If you use it for all of your matrices in the engine, then it might be a different story.  You pay a small penalty for each access of the pointer, but gain the productivity and safety of the automatic memory management.  If I find it to be a bottle neck at some point in the future, then i could of course switch back to standard references / naked pointers.

And yes, the engine has been an enormous learning experience :)

Oct 31, 2011 at 10:44 PM

Thanks for the information. :)

Here's a screenshot on which the effect is very visible - it's because I am looking directly at strong light, so those dust particles are shown on large part of the screen. I don't know if my description actually tells you anything, it's the easiest to see this effect in motion. Basically the dirt on the camera is visible only in those parts of the screen that are directly affected/lit by light sources.

Can I ask what are you planning to implement in the nearest future? Some kind of list/queue roughly showing your plans? I'm just courious, I know that everything can change and there are no ETAs.

In the changelog of revision 70454 you have written: "Added an InputAssemblerStateDX11 class, to encapsulate the entire IA state in one area. This is used by the InputAssemblerStageDX11 class to maintain the current state, and to set any desired changes. In the future this will be used to cache the state and reduce the number of unneeded state changes by the engine." - how much is that going to affect performance? Is it rather serious change or maybe some cosmetic improvement? 

Also, it seems that there is no response from NVidia yet? Well, I will just wait and have hope for quick and effective solution, I kind of hoped for reaction within promised 24 hours. ;)


Nov 1, 2011 at 8:20 AM
Edited Nov 1, 2011 at 3:22 PM

That effect looks like you said - a dirty lens :)  Honestly I don't know how they do it, but I assume they have some decals applied to the camera lens, and then based on the relative intensity of the scene they perform an area lighting of the decals.  Looks really interesting, and would be worthwhile to try to implement.

My plans for the coming weeks are not set in stone, but in general I try to give improvements equal development time as new features.  Here is a short list of things that I see happening in the near future:

  1. Convert LightPrepass to multithreaded
  2. Converting MaterialDX11 to smart pointer references (this is done!)
  3. Update the sample applications w.r.t. the ConfigureEngineComponents method
  4. Related to #3, implement the ability to switch to fullscreen and dynamically update the swap chain resolution to match (DXGI work).
  5. Implement 'state' objects for each pipeline stage, which will be used to cache the pipeline state.

New content / features to be coming include the following:

  1. Develop some basic shape actors, such as boxes, spheres, etc...
  2. Develop some standard material implementations, such as Gouraud, Phong, Ward, etc...
  3. Add a Texture2D class that can be used to mirror a GPU resource with a system memory copy (see recent topic started by fpiette).
  4. Add a sample based on tile based rendering.
  5. Add some dirty lens effects :)
  6. Add other samples...

And finally, things on the back burner that are not likely in the near future, but sometime later on:

  1. Adding x64 build targets.
  2. Adding D3D11.1 support + samples.

Regarding the Input Assembler stuff, this is related to the #5 from above.  In general, there isn't much checking currently done to minimize the number of API calls that are being used.  However, the possibilities are fairly well understood - it just takes time to get the changes implemented.  I would like to take a PIX frame capture before and after this optimization, and then count the difference in the number of API calls...  My assumption is that it will help performance, but how much is hard to say.  In general extra API calls steal CPU performance, so I would expect a bigger improvement in single threaded mode than in multithreaded mode.

Nov 1, 2011 at 3:46 PM

Thank you for clarifying everything and it's nice to see progress. :)


Nov 5, 2011 at 5:51 PM

Sorry to bother, but has Nvidia given any answer yet?


Nov 5, 2011 at 8:02 PM


They actually pointed me to the developer channel - apparently the contact that I made was with a consumer tech support line.  I have tried to register as a developer, but haven't heard back about being accepted...  If anyone knows of a way to speed up this process, please let us know!

Sorry it is taking so long - I wish there was something I could do to improve their drivers...  AMD has been much easier to work with regarding the driver issues thus far.

- Jason

Nov 5, 2011 at 8:43 PM

From this page - - I understand that there are 2 kinds of developer account - I don't know which one is needed to contact Nvidia about the issue and which option you chose, I never actually used this developer zone for contacting Nvidia. There is official Nvidia forum with special GeForce GTX & ION Drivers section: Users are reporting there various drivers issues and actually there is one person (nick: ManuelG) who is from Nvidia and he collects the feedback and then fills bug reports to the driver team. Maybe he could help?


Nov 6, 2011 at 7:47 AM

I have signed up for the registered developer under the link that you sent.  The response is that you have to wait up to 5 business days, so I should hear back within a week.  This would be the preferred mechanism, since I would be able to directly talk to the developer support teams instead of trying to post it to the general driver section of the forum.  If the registered developer account doesn't work, then I will try to post on these forums and see what we end up with.

If there is some way to private message users, you could try to poke ManuelG and try to link him to this conversation - that might be the fastest way to get their attention...

- Jason

Nov 21, 2011 at 9:44 PM

Hello again,

I have some good news! With the newest revision of code, 71597, it seems that (almost) everything is working fine now! Here are my observations so far:

- there are two missing files in LightPrepass project: ViewLightPrepassRenderer.h and ViewLightPrepassRenderer.cpp (so I am unable to test the new multithreaded LightPrepass sample).

- SkindAndBones sample is mostly working like it should: now in both debug and release builds I can see the white helping text overlay and the displaced actor is visible in the release build, however it is not visible in the debug build.

- the DeferredRendering sample is running without any problems in debug as well as in release build, the image and scene are perfectly visible.

- I noticed something new in this revision: before, in previous versions of the engine, while I was testing DeferredRendering sample's debug build it had the same or at least very close performance as its release build, now there is a huge difference in performance between them, that's not really a problem, it just caught my attention.

I use newest NVidia 285.79 drivers.

Greetings and thank you very much for everything, that's a really magnificent work! :)

Nov 21, 2011 at 9:56 PM

I almost forgot:

The DeferredRendering sample is working just fine with the line "m_pRenderer11->SetMultiThreadingState( false );" both active as well as commented out (in App.cpp).

Also, it seems that the performance of this sample is actually higher when this line is not commented out. So, if I am right, the performance is better when the sample is not using multithreaded rendering, but singlethreaded rendering instead?


Nov 22, 2011 at 5:16 AM


Thanks for the updates - I'm really happy that rendering issues are beginning to be resolved.  I suspect that the fix that I made in the GeometryDX11 class was the reason it wasn't working properly before.  This is especially difficult to debug since the reference device works properly, but its threading characteristics are much different than a normal running program.  This makes some bugs 'hide' when running in the reference device, while the issue actually isn't corrected.  So much for easy debugging :)

I also see the performance characteristics that you mentioned - simply because it is done in parallel doesn't mean it will be faster.  In fact, most of the samples run faster in singlethreaded mode since there is lower overhead to getting the commands into the API.  So this is to be expected, at least until the drivers are optimized for the MT use case!

Thanks also for pointing out the missing files - I uploaded them just now.

- Jason