Moeller

Member
  • Content count

    41
  • Joined

  • Last visited

Community Reputation

162 Neutral

About Moeller

  • Rank
    Member
  1. You could compile the nvapi.lib into a dll and then import it using DllImport. If you want to avoid an additional dll, you can take a look at the implementation used in the Open Hardware Monitor: http://code.google.com/p/open-hardware-monitor/source/browse/trunk/Hardware/Nvidia/NVAPI.cs This gets the corresponding function pointers directly from the nvapi.dll. It has also the advantage of running in x86 and x64 mode (the correct dll is chosen at runtime, something that is a bit tricky when using DllImport). The required keys to get the function pointers directly can be found e.g. in this Pascal translation of the NVAPI http://mantis.freepascal.org/bug_view_page.php?bug_id=15771&history=1
  2. Game programming starting languages

    As far as professional game programming goes, I think the core of most games are still written in C++. Tools are sometimes done in C# as well. Content code is often done in some kind of scripting language. But of course many more languages have been used, even in the professional world. I (personally) would use C#, C++, Java or FreePascal (in this preference). I would not recommend using any runtime interpreted (script) languages (Python, PHP, Tcl, ...) for the core of a project.
  3. Desiding upon a language?

    I would start with C# or Java if you want things to be simple and clean. Both languages are easy to learn and very usefull. I would not recommend learning any Basic dialect. If you want a language closer to the hardware then you could learn Delphi/(Free)Pascal or C++. But especially C++ can be difficult, and I personally find it a bit "ugly" (in the sense that the programmer needs to take care of things which the computer can do a lot better). For C# you can download Visual Studio 2008 C# Express free of charge. For Java I would recommend using Eclipse and the of course the Java SDK from Sun (both free of charge as well). To learn, just go to the next public library near you and grab some books that teach you the basics of the language.
  4. SlimDX texture problem

    He is accessing Direct3D from two different threads Quote:Original post by zcpzzy... and create two thread for working, one thread for render and another for update ... so without thread safty (CreateFlags.Multithreaded) many strange things can happen. Thats at least what I would expect.
  5. Measuring image similarity

    I would define first a constant which relates a displacement error to a color error. For example 1 pixel distance = 0.05 color distance (in the unit rgb cube or another color space). Lets call this 0.05 = c in the following. Then you basically sum the squared color distances per pixel. But if you find a color distance that is larger than 0, you calculate the corresponding pixel distance (= color_distance / c) from it. Then you search a circular disc around your pixel for a pixel in the reference image that would yield a smaller error if you sum the pixel distance (times c) and the color distance. So, finally the error for that pixel is min(pixel_distance * c + color_distance) over a large enough circular area around each pixel. The radius of the disc you need to search can be estimated from the color_distance at the center as mentioned above (because a larger pixel_distance would yield a worse result anyway, even with identical color). You can even further optimize it, by incrementally increasing your search radius while calculating the maximum radius from your current best match. Of course this technique does not perfectly measure all cases. If a straight line is turned into a zig-zag line this could be considered worse than just moving the line by one pixel. But this is the same for colors for the simple squared difference. A dithering pattern with positive and negative differences can be also worse than just a slight (but uniform) shift in color.
  6. SlimDX texture problem

    Have you created your Direct3D9 device with CreateFlags.Multithreaded?
  7. Using Unmanaged DLLs in C#

    The DllImport is for native dlls, while Managed C++ creates managed .NET dlls which you can use directly in C#. Beside this Managed C++ is already deprecated and replaced by C++/CLI. In general you have to be carefull about performance when going to the unmanaged world just for a few SSE instructions, because the overhead can be pretty high. Maybe take a look at SlimGen as well which tries to solve the same problem.
  8. If you need more freedom you can use a vector map instead of a height map. That means you do not only store a heightmap (z-displacement), but also an east-west-map (x-displacement) and a south-north-map (y-displacement). For a heightmap the final position is float3(x, y, h(x, y)). For a vector map the final position is float3(x + f(x, y), y + g(x, y), h(x, y)) In general you need 3 times the memory for that, but for the x and y displacement you don't need the same resolution usually, so you can save there a bit. You can still use the same basic ideas like chunked lod for heightmaps. And with vector maps you can create overhanging cliffs.
  9. [DX9+Cg] Pixel Shader Not Working?

    First, in your input vertices the w component should be 1.0 and not 0.0. And of course the result depends not only on the projection matrix, but also on the view matrix and the world matrix.
  10. [DX9+Cg] Pixel Shader Not Working?

    From the vertices you posted it looks like they are all (just a bit) behind the far-clipping plane. If I remember right then z/w of the transformed vertices should be within [0.0 ... 1.0] to be visible. Maybe change/corret your world matrix, or the far plane distance.
  11. The texture formats supported for render to texture can be different for different hardware/systems. I would check if you really have support for the format you want to use. You can do this either with the d3d api or by checking hardware specs, or by looking at dxcaps. Beside this you can always install the debug runtime of d3d9 and and read the ourput with DebugView. There you should see if direct3d detects anything that fails.
  12. you should calculate the size of your image with this formula size = blockSize * ceil(width / 4) * ceil(height / 4) where blockSize = 8 for DXT1. your code could fail there if the width and height of your texture is not a multiple of 4. and of course you need to use GL_COMPRESSED_RGB_S3TC_DXT1_EXT
  13. HLSL Texture Splatting Question

    If you want to stay with ps_2_0 then using a few different shaders is the only way. Note that you do not need a different shader for every possible combination. Maybe one unused texture lookup here and there can be ok if it helps to reduce the number of differnt shaders used. And of course group by shader when drawing. The problem with ps_2_0 is, that you can't have conditional texture lookups. So the 16 lookups will happen for every pixel in your frame and many will just drop the lookup results. But the performance cost for the 16 lookups are always there. So either you have to use a higher shader model (where lookups can be conditional) or you need to split into different shaders. And of course making 16 texture lookups takes a lot longer than doing just 3.
  14. DX11 Error Creating Effect in D3D11

    In the other thread they seem to get the _com_error exception as well. I am not sure if this is good or bad. Anyway, since you have the source to the effects 11 stuff, have you tried stepping through with a debugger? There you should see where the "Effects11: Effect version is unrecognized. This runtime supports fx_5_0 to fx_5_0." is thrown and if changing to effectBlob->GetBufferPointer() really helps or makes things only worse. So if the first problem is solved and the _com_error is thrown because of a second problem, or if using effectBlob->GetBufferPointer() is just wrong.
  15. DX11 Error Creating Effect in D3D11

    try to replace hr = D3DX11CreateEffectFromMemory(effectBlob, effectBlob->GetBufferSize(), 0, device, &effect); with hr = D3DX11CreateEffectFromMemory(effectBlob->GetBufferPointer(), effectBlob->GetBufferSize(), 0, device, &effect); I am not sure what the memory layout of the effectBlob wrapper is, but from what the effect11 code does, it looks like it expects a pointer to the actual blob data instead of the blob wrapper. The error you see is thrown when effect11 tries to read the effect version from the header, which comes first in the blob. Reading from a wrong location in memory could explain why it can't give support (for an invalid version).