Jump to content

  • Log In with Google      Sign In   
  • Create Account

Jason Z

Member Since 04 Feb 2004
Offline Last Active Today, 07:48 PM

#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.

#5159399 C++ resources

Posted by Jason Z on 09 June 2014 - 07:43 PM

You can always check out some of the resources on isocpp.org, which is the official website for the ISO language.  Many of the famous C++ authors have content there, and lots of modern code and examples get posted there.

#5158962 Vertex Shader vs Pixel Shader - Where to do processing?

Posted by Jason Z on 07 June 2014 - 03:01 PM

1. Like the others already said, these will not give you the same mathematic result. 

2. This depends on lots of factors.  In general, you should try to pull calculations towards the beginning of the pipeline for the reason you mentioned.  However, if you rendered object appears small on the screen, it is quite possible for you to have more vertices than pixels, so there is lots of variations there.

3. I think this one is also a maybe.  If you are loading textures in the pixel shader, it is quite possible that a normalization can be nearly hidden due to the latency of the memory access.  In addition, if the pixel shader is not your bottleneck, then making this change shouldn't produce any speed changes at all - it all depends on your system, what else you are doing in the scene, and how much of the system's resources you are using!


In short, there are no hard answers to these questions - as always, it depends!

#5157774 [DirectX] Particle Systems - Compute Shader

Posted by Jason Z on 03 June 2014 - 04:41 AM

Looks pretty good - how about a description of your rendering setup?  Are you using append/consume buffers?  Are the particles living forever or are they dynamically created and destroyed?

#5157699 Passing and getting const refs (XMFLOATxxx)

Posted by Jason Z on 02 June 2014 - 07:38 PM

Have you tried out using a static code analyzer?  There is one available in Visual Studio, which can most likely catch it if you try to return a reference to a temporary object.  Other than using something like this to check your code, then you pretty much just have to make sure you don't return a reference unless the data is a member or (gasp) a global variable.


The arguments should be passed by constant reference if you don't plan to modify them.  Like you said, the return value should be a value and not a reference, unless you intend for the returned data to be modified outside of the class.