Jump to content

  • Log In with Google      Sign In   
  • Create Account

N.I.B.

Member Since 21 Jun 2009
Offline Last Active Yesterday, 10:21 AM

#5179832 Mip mapping issue

Posted by N.I.B. on 12 September 2014 - 04:20 AM


0 isn't a valid value for MaxAnisotropy; it needs to be between 1 and 16: http://msdn.microsoft.com/en-us/library/windows/desktop/ff476207%28v=vs.85%29.aspx
(Note that 1, not 0, is for anisotropic filtering disabled).
I suggest correcting this first, then see if the problems still happen.

 

This value is ignored in case the filter type is not anisotropic.

Appraently, 0 is indeed a valid value even if the filter type is anisotropic.

D3D11 ERROR: ID3D11Device::CreateSamplerState: MaxAnisotropy must be in the range [0 to 16].  20 specified. [ STATE_CREATION ERROR #226: CREATESAMPLERSTATE_INVALIDMAXANISOTROPY]



#5179636 Mip mapping issue

Posted by N.I.B. on 11 September 2014 - 11:37 AM

Can you provide the code that shows how you generate and use the texture?

 

Why aren't you using DirectX functions (When creating the resource or with GenerateMipMaps)?

 

Also, make sure you're rendering state is correct - you didn't specify which DX version you are using, but it can be due to incorrect ShaderResourceView::MipLevels and SamplerState::MaxLod fields.




#5179158 Where do I go beyond Graphics Programming?

Posted by N.I.B. on 09 September 2014 - 02:26 PM

You start by saying that you are working on a game, yet the rest of your post is about engine development.

I suggest you start by reading the "Write Games, Not Engines" post (old, but still very relevant).

 

If you want to write a game, I suggest you pick a game engine off the shelf. There are numerous options - some proprietary like Unity, other open-source like Torque3D and Panda3D. By using an existing engine, you can spend more time on developing the game itself. There are other benefits like OS portability, engine robustness, existing resources, etc.

 

If you want to write an engine, Game Engine Architecture is a decent book. Writing a good game engine takes a lot of time, as modern engine contains a lot of components. It's not just graphics - you also need audio, networking, input, file services and many more.

 

You can decide that all you want to do is focus on the graphics engine (not to be confused with game engine) - that's a huge topic on its own.

You can decide that you want to focus on graphics programming (not to be confused with graphics engine) - another huge topic.

And the list of options is very long...

 

So - first decide what you really want to do. If it's making a game you are really after - than use an existing engine and make your game.




#5178871 std::unique_ptr issues

Posted by N.I.B. on 08 September 2014 - 09:25 AM


This is unfortunate, because otherwise it would have been like this:

// Foo.h

struct Bar;

struct Foo
{
~Foo(void);

Bar* m_pBar;
}

// Foo.cpp
#include "Bar.h"

Foo::~Foo(void)
{
delete m_bar;
}

Not sure why you are saying that. Which compiler are you using?

 

This works with VS2013 update 3

//////Test.h

#include <memory>

struct Bar;
struct Foo
{
	~Foo(void);
	std::unique_ptr<Bar> m_pBar;
};

/////Test.cpp
#include "test.h"

struct Bar
{

};

int main()
{
	Foo f;
}

I actually use unique_ptr with forward declarations a lot. Works great.




#5178860 HLSL compiler weird performance behavior

Posted by N.I.B. on 08 September 2014 - 08:39 AM


What shader model do you compile with?

 

5.0.

Still, that doesn't explain the performance hit. All the compiler has to do is:

- Verify that sizeof(matrix)*256 < MAX_ALLOWED_CB_SIZE

- Create the SM 5 instruction 'dcl_constantbuffer cb1[41], dynamicIndexed'

 

And that's it. No need to optimize anything.

Weird. I'll never understand what compilers think.




#5175048 So... C++14 is done :O

Posted by N.I.B. on 20 August 2014 - 10:24 AM

Am I the only one that thinks that all those new features makes C++11 look and feel completely different than C++?

Seriously, that's practicality a different language, why keep calling it C++?


#5174708 So... C++14 is done :O

Posted by N.I.B. on 19 August 2014 - 06:50 AM


And those are not only that it's less work to type auto than to type std::foo>::blah::iterator when you actually don't care about what the type is exactly, as long as it's correct.

That's one of the sparse cases where I do find 'auto' useful.

 

 

 


auto requires that the type is exactly known, and it results in a precisely defined type (which you don't see in your code, but the compiler knows it!) that is properly checked as if you typed it out by hand.

That's the problem. The compiler will deduce what the type should be, and so you lose compile time checks of type-mismatches. The programmer will never get compilation error, even in cases where the behavior changed significantly.

 

I also read Herb's article. I disagree with most of his reasons for using auto:

- He suggest that using 'auto' guarantees that a variable will be initialized. All modern compilers have 'uninitialized variable' warning, and in any case that's just a by-product of 'auto', so can't be a strong argument for why use it.

- He claims that 'auto' is more efficient than explicit type declaration (due to implicit conversions, temporary objects, wrapper indirection.). But - compiler will warn you about implicit conversions(including narrowing). Plus - all the issues he shows are actually user errors - you thought that you are doing something when in fact something else happens. 'auto' doesn't eliminate your misunderstanding, it just hides it. Relying on 'auto' to help solve performance issues doesn't sound like a good practice.

 

I can tackle almost all of what he says there, though I do agree with him on some uses.

If you look at his GOTW #93 and GOTW #94 examples for auto - it doesn't look or feel like C++ - why write

auto w = widget{ get_gadget() }; // Unless you understand C++11, you'll wonder what this code is doing

when you want to commit to a type instead of writing:

widget w = get_gadget(); // Most people in the world understand this.

Actually - the hiding part is my main issue with 'auto'. Hiding things was never a part of C++'s DNA. Where most people see a minor, nice to have a feature, I see a major idiom change in the language.

 

But maybe I'm just too old and grumpy to like 'auto'...




#5174683 So... C++14 is done :O

Posted by N.I.B. on 19 August 2014 - 05:23 AM


Although generally, based on the old/new discussion, the question shouldn't be "what do I gain by using the new way" but rather "what do i lose by doing so?". People tend to flavor that which they are used to, so unless there is a huge loss and virtually no gain for doing it with a new option, I'd say pick the new one.

 

I actually think the question is "in how many ways can someone else screw-up the code?". And in C++11 the answer is a lot more then with the "old" C++.

If you are an experienced programmer, who understands the pros and cons of the new feature - then use whatever you want. The problem is that there are way too many inexperienced programmers who (unintentional?) abuse things, or will understand what you are doing.

 

Take 'auto' for example - it's great when used with caution (and very very sparsely). But I saw some programmers who just decided that it would be great to use it as much as possible (even a very experienced one), regardless of minor things like code readability and type safety.

[EDIT] - 'type safety' should be 'compile time type checks'.

 

C++ is not a scripting language, nor is it a high-level abstracted language with powerful RTTI like Java. And it shouldn't be. Most of the new features seem to solve very minor problems and do not provide great benefit over the legacy C++.




#5174670 So... C++14 is done :O

Posted by N.I.B. on 19 August 2014 - 04:38 AM

nullptr is just about the only feature of C++11 I actually use (though I was fine with the plain-old NULL). Ctr delegation is also nice, but again - syntactic sugar.

Seems to me like C++11/14 features are mostly beneficial if you are writing an STL like library (See Bjorn's FAQ, a lot of the examples are STL related).

 

I agree with frob - C++11 and C++14 are moving away from the minimalist approach, which isn't a good thing (and don't get me started on the dangers of 'auto').




#5174316 using other dc's than the main window's dc

Posted by N.I.B. on 17 August 2014 - 01:56 PM

PFD_DRAW_TO_BITMAP is not HW accelerated.

If you want HW accelerated off-screen rendering, you can use pbuffer or better yet - frame buffer objects.




#5174302 How to build a virtual machine

Posted by N.I.B. on 17 August 2014 - 12:38 PM

Well, the first question you want to ask yourself is what is the purpose of the VM? Or what do you want to emulate?

VM doesn't necessarily means writing assembly code. In the context of games, there are 2 common emulation concepts:

 

  1. Emulating hardware - could be old game system such as NES emulator, other computer architecture such as commodore 64. For this type you really need to know the architecture you are planning to emulate - basically learn the assembly language, how it is encoded, memory architecture, video and sound systems, etc. Depending on your choice of HW to emulate, this can become really tricky.
  2. Emulating game engines - this type is similar to ScummVM. In this case, you write an emulator for a scripting language. There are some similarities to the first kind, but the main difference is that you don't need to understand the hardware internals, which greatly simplifies the problem. For old game systems (Scumm, SCI) - it's a simple mapping of the scripting instructions to some high-level Java/C++ calls, no need for assembly.

There are also other kind of VMs - for example, one can write a virtual machine for HLSL/GLSL shader execution. Very simple, but limited and pretty useless without proper context.

 

There's really no reason to learn x86 assembly (at least not at the beginning). If you are targeting some old architecture/game engine - your current PC is thousands of times more powerful, so even a decent interpreter would do.

 

Java will do just fine (in fact, Java runs on VM with JIT compilation).

You can take a look at the ScummVM source code and use it as an example (C++, uses OpenGL for the video system).

 

If you are just starting, I suggest that you:

- Work on Scumm. You have reference code for it, which means it's well documented.

- Start with basic interpreter, just to make sure you understand how the system work.

- Once it's working, identify the performance bottlenecks and optimize them (use HW accelerators for graphics/sound system, learn and apply x86 optimizations, etc.).

- That should basically do. If you still feel unsatisfied, start learning JIT compilation(JIT == Just In Time). This takes you to a whole new level of x86 low-level understanding.




#5126722 Highly confused about simple quad texturing

Posted by N.I.B. on 27 January 2014 - 08:28 AM

1. Create a correct vertex buffer, no need for color declaration

struct SVertex
{
    D3DXVECTOR2 PosS;   // Screen space position
    D3DXVECTOR2 TexC;   // Texture coordinates
};

static const SVertex gFullScreenQuadVertices[] = 
{
    {D3DXVECTOR2(-1.0f, -1.0f), D3DXVECTOR2(0.0f,  1.0f)},
    {D3DXVECTOR2(-1.0f,  1.0f), D3DXVECTOR2(0.0f,  0.0f)},
    {D3DXVECTOR2( 1.0f, -1.0f), D3DXVECTOR2(1.0f,  1.0f)},
    {D3DXVECTOR2( 1.0f,  1.0f), D3DXVECTOR2(1.0f,  0.0f)},
};

2. Input layout is

    D3D11_INPUT_ELEMENT_DESC layoutDesc[] = 
    {
        {"POSITION", 0, DXGI_FORMAT_R32G32_FLOAT, 0, offsetof(SVertex, PosS), D3D11_INPUT_PER_VERTEX_DATA, 0},                
        {"TEXCOORD", 0, DXGI_FORMAT_R32G32_FLOAT,0, offsetof(SVertex, TexC), D3D11_INPUT_PER_VERTEX_DATA, 0},                
    };

3. VS should be pass-through:

void VS(float4 PosL : POSITION, inout float2 TexC : TEXCOORD, out float4 svPos : SV_POSITION)
{
    svPos = PosL;
}

Note the TexC is declared as inout, so the compiler will create a code to pass it to the PS.

 

4. PS needs to do texture sampling:

SamplerState gSampler : register(s0);
Texture2D gSRV : register(t0);

float4 PS(float2 TexC : TEXCOORD) : SV_TARGET
{
    float3 c = gSRV.Sample(gSampler, TexC).rgb;
    return float4(c, 1);
}

Note that in order to do this you need to create a sample state. Check CreateSamplerState() for documentation. Basic tri-linear sampler is

// Create point sampler state
    D3D11_SAMPLER_DESC desc;
    desc.AddressU = desc.AddressV = desc.AddressW = D3D11_TEXTURE_ADDRESS_WARP;
    desc.Filter = D3D11_FILTER_MIN_MAG_MIP_LINEAR;
    desc.MinLOD = 0;
    desc.MaxLOD = D3D11_FLOAT32_MAX;
    desc.MipLODBias = 0;
    desc.MaxAnisotropy = 0;
    V(pDevice->CreateSamplerState(&desc, &LinearSampler));

Then set it before the draw call using PSSetSamplers().




#5116188 directx as a blitter

Posted by N.I.B. on 11 December 2013 - 06:58 AM

The fastest way would be to load your texture into a staging resource, then copy it into the back-buffer. Something like:

This is probably the fastest way to do it using D3D11.




#5116184 Saving files with std::ofstream checking if filename alredy exists to prompt...

Posted by N.I.B. on 11 December 2013 - 06:49 AM

Using Google to search for an answer is much shorter. There you go.




#5115633 DX11 - Disabling depth testing?

Posted by N.I.B. on 09 December 2013 - 06:56 AM


AFAIK, in DX11 depth-stencil testing is off by default

Wrong. Here is the default state (which applies to setting depth state with NULL). User still has to create a DepthStencilView and bind it, but no need to create a DepthStencilState to enable depth test.

 

 


Otherwise, you have to create a ID3D11DepthStencilView from your ID3D11DepthStencilState

I can't remember if ID3D11DepthStencilView holds a reference to the ID3D11DepthStencilState.

There's no connection between the two. You create each of them separately. To create a DSV, you first need to create a resource with D3D11_BIND_DEPTH_STENCIL flag, than create a DSV into that resource.






PARTNERS