Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Jason Z

Member Since 04 Feb 2004
Offline Last Active Today, 08:44 PM

#5162419 Direct3D 11 Swap-Chain Madness

Posted by Jason Z on 23 June 2014 - 04:33 PM

This is just a crazy first shot, but is the exception handled somewhere other than your code?  I have had cases where the first chance exception occurs, only to be handled in one of the underlying libraries (i.e. the exception is used as a normal part of one of the sub-systems).  If you set VS to not break on first chance exceptions then you would never even know it occurred.

 

Before digging into the nitty gritty details, have you tried that out?




#5162209 Why does this matrix multiplication order matter?

Posted by Jason Z on 22 June 2014 - 07:31 PM

 

 

Again, GLSL does not make distinction betweeen column or row vectors in its very code, but order of operations is explicit of course (order is actualy equivalent of majoring).

 

The difference in the order is whether to multiply the vector first, and have all the other matrixes multiply a vector (reducing the number of operations since a vector is only 4x1), or multiply all the matrixes in order and only multiply the vector at the end.

 

 

That only saves operations if you are doing only one or two transformations.  If you are processing lots of vectors, then the matrix concatenation is clearly more efficient.

 

Regarding your original question, are you having issues with only one or two shaders, but all of the others are working as you expected (using the same matrix multiplication order)?




#5162204 Per-instance data in (non-vertex) shaders

Posted by Jason Z on 22 June 2014 - 07:23 PM

You could do more or less the same thing as the constant buffer approach, but instead use an SRV to hold the data.  That allows you to have a variable sized resource that has a much larger potential size than a CB, and you can still access the data in a simple way.  You will have to test it out to see if there is a performance delta for your particular situation though, since you will be trading device memory accesses for interpolants.  It may or may not be a good trade off...




#5162203 Dynamic Shader Linkage and ShaderReflection

Posted by Jason Z on 22 June 2014 - 07:20 PM


How do i get the reflection interface for the default constant buffer?

If you compile your shader with FXC, and then check the output listing for the name of the buffer you should be able to use that name to reflect the constant buffer.  Regarding the performance, I think there is a penalty for using the dynamic linkage (although I've never heard hard numbers on this before).  Most of the systems I have heard of just generate the appropriate shader code and compile the needed variants accordingly.

 

Is that something that isn't a usable solution for you?




#5162199 Visual Programming

Posted by Jason Z on 22 June 2014 - 07:14 PM

Have you seen the visual editor in UE4?  I think it targets the same or similar functionality that you are implementing.  That should tell you that there is at least some demand for such a feature - most likely to allow designers to get in on behavior modification and things like that.

 

Would you ever see yourself using such a system?  Are you planning to make a product or to provide an open source library?  I would say that if you are learning while you are building the system, then keep on going!




#5162096 Dynamic Shader Linkage and ShaderReflection

Posted by Jason Z on 22 June 2014 - 08:22 AM

But the constant buffer is the same regardless of which interface you are using, right?  I haven't ever used the interface mechanism, but I thought it was a way to swap out implementations of a 'class'.  It doesn't modify the constant buffers though, does it?




#5161904 Learning Game engine or Programming first

Posted by Jason Z on 21 June 2014 - 07:22 AM


Thanks a lot .. damn i really wanted to try unreal 4 though .. its a lot cheaper too ... unity is 70 dollars a month without the mobile stuff i believe... unreal gives you full access at just only 20 dollars



I believe C# is only for unity though right ? i believe unreal uses C++



Nonetheless, you are suggesting to learn C# from scratch and then use Unity ? or learn along the way while making the game ?

I think you need to take a step back and think about things in more detail.  The licensing models are different between UE4 and Unity.  Unity gives you free access up front, but if you pass a certain amount of revenue then you have to purchase the pro license (the addons for mobile development may require the upfront purchase, I'm not familiar with that).  UE4 is only $19 a month, but they will take a cut of your revenue.  If you make tons of money on your game, Unity is way better from a financial model.  If you make little or no money, then UE4 will probably be better.  But you need to make a realistic plan about your expected income before making a financial decision.

 

If you don't have any programming experience, then the faster way to get started is probably C# with Unity.  I have seen some of the UE4 stuff and there is lots of visual editors for most tasks, including for scripting, but sooner or later you will have to dip down into C++.  The general consensus is that C++ is harder to learn initially than C#, but is also more widely used in the game industry.

 

If you are planning to make a game, you will need to know at least the basics of the language you are using - otherwise you are just asking for pain and suffering...




#5161562 Too large shaders - micro specializations.

Posted by Jason Z on 19 June 2014 - 02:34 PM

I am not giving you my opinion. I am giving you my experience.

My render loop can draw 80+ materials, over 20k tris total without even pulling the CPU out of the energy saving mode.

You are cracking your head open, spending your time which will never came back... to optimize for an API which is dead in the water and has been for quite a while.

But... you are free to make your choices.

 

There are lots of people that are still supporting DX9, and I think it makes perfect sense to optimize a rendering sequence in an existing program.  The algorithm runs on the same GPU regardless of which API you use, it is just a different API so I don't really see why you are pushing so hard about DX9 being dead.  The API still exists, and will continue to exist more or less forever in the Desktop environment.  Small batches cause issues at some point in DX9, but there are many ways to address those types of problems.

 

@Promit: You are right of course.  The general case is that in D3D9 if you are doing lots of small batches that the CPU will become the bottleneck pretty quickly.  However, in some cases it could be possible that you are also causing the GPU to be inefficient.  I guess this is why you need to profile before you can find and fix the problems!




#5161554 First time DX11

Posted by Jason Z on 19 June 2014 - 02:04 PM

SeanMiddleditch has it right - you should seriously consider getting out of the D3DX library and instead use an alternative.  It is possible to continue using it, but you will run into issues like these until you just get rid of the DXSDK.  Embrace the change!




#5161285 Question about game events

Posted by Jason Z on 18 June 2014 - 05:49 AM

What will the events be used for?  If they will be used for sending information about the game state, then it should probably come from the game.  If it is for sending data to the game to cause a change in game state, then it should be able to come from the game itself or other systems.

 

So you need to clarify what these objects are supposed to be doing, and then make the design decision based on that!




#5161188 Orthographic camera

Posted by Jason Z on 17 June 2014 - 06:43 PM

#1: You could do it that way, but if you plan to do anything even moderately interesting with your camera, then you should consider option 2.

#2: It needs to be done in the shaders, as there is no fixed function pipeline anymore.  You can take a look at the old D3DX functions for inspiration in making the orthographic and view matrices though: D3DXMatrixOrthoLH and D3DXMatrixLookAtLH.




#5161013 Too large shaders - micro specializations.

Posted by Jason Z on 17 June 2014 - 04:25 AM

Have you profiled your application to see if the CPU is the bottleneck?  If it isn't the bottleneck, then reducing draw calls probably won't help much - so you should start there.  Regarding your question about having a number of similar effects being soaked up into one, I would take a close look at the effects and see why they are different.  Is it a substantial difference, or is it something that is just a superficial difference?  The effort and effects of combining them depend greatly on how similar they are, so it is hard to give a good answer to your question...




#5160957 Why does this code snippet not work when i take it out of function scope

Posted by Jason Z on 16 June 2014 - 07:24 PM


1. If you need an array of a small number of chars, I would default to putting them on the stack, i.e. "unsigned char buf[4]", instead of using new. Your sizeof would work if you did that.

You could also use std::array for a fixed size array.  That makes it much harder to forget to release the dynamic memory, and sizing should work properly there too.  But I agree, for small stuff like this, stack allocation would probably be fine.




#5160544 What to do now?

Posted by Jason Z on 14 June 2014 - 01:56 PM


Thanks for the advice but I didn't had experience with DirectX Graphics API when I started the project. I was learning plus making the game at same time so it took that much time.

 

You shouldn't have to justify yourself - if you want to take 5 months doing graphics, then that is perfectly fine.  Maybe you only get to work on it once in a while, maybe you had an interruption, or maybe you are just learning how to do it.  It doesn't really matter, but what does matter is that you stay motivated.  If you are looking to learn about sound and network programming, then take another few months and learn about them.  Don't just your progress based only on the game - if you are doing this to learn, then judge yourself by how much you have learned in the project.

 

I like to keep a hand written journal of the work that I am doing, and document some successes and some failures too.  It helps to keep me realistic, and to see how much I have done over the past month or so.  Give it a try and see if it works for you too.




#5160480 [DX11] Why we need sRGB back buffer

Posted by Jason Z on 14 June 2014 - 06:08 AM

Have you read the article "The Importance of Being Linear"?  It does a pretty good job of explaining why you need gamma correction, including the situations when you should use it and when you shouldn't.  I applaud the OP's willingness to experiment, but in this case it seems like you don't get the high level concept just yet - so please try to read through that article and come to a mathematic reasoning for doing this and then the correct operation will be quite clear.






PARTNERS