NewDisplayName

Though I was trying to think of way to do this cross platform and didn't think the C++ standard had a way to do this. Would boost::filesystem be best for this?

Yes, nothing beats boost::filesystem so far. Go ahead with it.

Even though what you're saying is highly debatable (and trust me, I have tried fiddling with pointers way too much over all these years) lets just leave it at that.

I have absolutely no intention of entering this debate, following in the footsteps of many of our esteemed predecessors.

To each his own. cheers.

There is a reason why second method (using pointers) is faster than the first one.
Processor doesn't have to calculate the memory offset of each member of the structure when using pointers which makes things run faster.
From personal experience, generally everyone knows why pointers are fast, but few people understand why.

 

Late to the party, but no, that is not why pointers are faster.

 

The pointer version of the function is faster only because it accesses and modifies the initial object in place, whereas the non-pointer version copies the entire object twice (once when passed as a parameter by-value, and once when returned by-value).

That's just another reason, and not the only reason. Two people can still be right with different facts sir, doesn't mean one needs to diss the other. 

To add to above solution, it isn't possible to "average" out the colors the way you are trying to achieve it in the colorbar fashion. So you do need separate buffer for each bar and use a color value for that. Ofcourse, getting the value of color to fill up each bar is easier to achieve by simply taking the leftmost and rightmost bar's color and breaking up into N components for N bars using Arithmetic progression logic or whatever suits you.

There is a reason why second method (using pointers) is faster than the first one.

Processor doesn't have to calculate the memory offset of each member of the structure when using pointers which makes things run faster.

From personal experience, generally everyone knows why pointers are fast, but few people understand why.

But, like GeneralQuery mentioned above, optimisation is bound by many more factors and world peace is a myth.

However, for the question at hand, go ahead and use the second one.

I think you're troubled by aliasing right now. Put a basic sampler state with min,mag,mip all LINEAR, in your shader, and then see if something changes.

For that your need to set your D3DFVF flags right.

Basically, without shaders your CUSTOMVERTEX structure needs to be setup with FVFs in such a manner that the color associated with that vertex gets bypassed.

Check this out for further reference --> http://msdn.microsoft.com/en-us/library/windows/desktop/bb172559(v=vs.85).aspx

I still don't get it.

Why are you passing this --> PixelShaderInput input

when you should be passing this --> VertexShaderOutput input

Also, please post your final code with the current status of problem.

Yura,

Just check this method in your shader and see if you think this is how it should be (because I definitely don't think so).

float4 PixelShaderFunction(PixelShaderInput input) : COLOR0  // Use VertexShaderOutput
{
float4 back = float4(200.0f, 0.0f, 0.0f, 0.0f); // why?
//input.Color.a = 0.0f;
 
if(input.face>0)
{
return input.Color; // nothing
}
else
{
return input.Color; // nothing
}
 
}

I believe his actual query is not about algorithms to solve the Rubic's cube, but how to keep the colours of the mini-squares on the surface intact while rotations.

I think, peeling and re-applying is the best option from rendering complexity perspective.

Basically, it's easier to shade subsequent colour changes for the mini quares on each cube solving step, for very obvious reasons.

Check this line :

glColor4f(1.0f, 0.0f, 0.0f, 0.0f);

How can you see anything when your alpha component is 0? Set it to 1 for opaque.

Use multimaps to store possible caps values for a particular d3dcap (Use d3dcap name as the key, if you please). It has several advantages.

1) No more iterations to find out a particular capacity. Just a "find" will do.

2) Easy to take different combinations from various multimaps to support different combos in future.

3) Looks much more systematic and better than static arrays and for loops. :-)

I think you're a bit confused about /clr option. It works even for an application which doesn't have managed data. You may want to read more about both nullptr and /clr. But anyhow, that isn't the problem at hand.

I think you're already quite close to the solution.

Unfortunately, I am unable to try out your code on my setup and check this issue firsthand.

But maybe you should get some pointers from this code here --> http://www.csh.rit.edu/~oguns/src/graphics.cpp

Hope this helps.

First of all, you won't need IDXGIAdapter2. From the problem statement that you have put forth, this just seems to be "too much info".

Regarding something like "EnumAdapters2", there is no separate method for Factory2, when it already inherits these methods from Factory1.

There is a separate list of methods, that Factory2 additionally provides, but like I said before, looking at your needs it's just TMI.

Looking at Test_DXGI_1 method, I don't see any obvious issues but I can give you some pointers for debugging it properly.

I think you should first check for values that are being pushed into the vector. If Enum itself is not working fine, then GetDesc can't do much.

Your Enum needs to work before GetDesc, so you should focus more on that and begin trying from 1.0 and then move onto 1.1 or 2.0.

Just one more thing to confirm is that you're building your project with /clr. I'm curious about nullptr behaviour if built without /clr. Ideally, it shouldn't do any damage but jic.

Structure padding is always better, but if you don't want it then use the pragma directive to overcome memory alignment for each object..

From my experience with MSDN, it generally addresses only whatever is introduced as part of Microsoft's code.

Worldview is more of a graphics concept and they seem to assume that it is already known to programmers, by default.

Glad you could solve the issue on your own!