• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

162 Neutral

About Moeller

  • Rank
  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. 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. 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. 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. 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. Have you created your Direct3D9 device with CreateFlags.Multithreaded?
  7. 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. 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. 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. 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

    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

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