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

ArcticHammer

Members
  • Content count

    34
  • Joined

  • Last visited

Community Reputation

123 Neutral

About ArcticHammer

  • Rank
    Member

Personal Information

  1. I would agree with this question - is it really not an option?  The APIs are quite different, but the concepts that they support aren't that different, and should be able to be converted in a reasonable amount of time...     Jason Z,  Just ordered your DX11 book. Let's see if helps us making a parallel DX11 rendering engine. It's going to be painful road though. 
  2. Thanks for all your help. We've have buried the idea of WinRT version. Probably farming carrots would be a simpler way to make a living than DirectX programming. 
  3. Does Windows RT support DirectX 9.0 c (SM3) applications? We are programming scientific graphics with SharpDX and converting our existing mammoth engine for DX10 or 11 is not an option.     
  4.   this, since early atom CPUs had old IGPs...   Try also to disable the driver optimization in the intel graphic control panel     Thanks for trying to help me.    Setting software vertex processing instead of hardware vertex processing doesn't help.    This Intel graphics control panel doesn't allow changing any settings, it just shows info. This clearly a stripped-down version of the intel grahics control panel found in laptops.  [attachment=18245:intel_settings.png]         GPU-Z shows "Intel(R) Grpahics Media Accelerator" as the name of the GPU. It may be Power VR inside, but is Intel GMA to the DirectX and to me.  [attachment=18244:GPUZ.png]
  5. It renders correctly with the reference rasterizer. HLSL transformations all work correctly. But not with hardware driver.    I'm contacting Intel.
  6. I'm pulling my hair off with one specific hardware.  This is an Acer Iconia w3-810 tablet, with Windows 8,  Intel Atom Z2760, and GMA "GPU".     Newest driver pack has been installed.    I'm developing with DirectX9 and HLSL. Some objects I render with  DirectX 9 pipeline but some objects requiring advanced coloring render with HLSL vertex and pixel shaders. The problem is coordinate conversion in the HLSL, from object space to screen coords. I suspect this must be some kind of floating point accuracy thing.    In vertex shader, this works with all other computers:  vout.Pos_ps = mul(position, WorldViewProjection);   //WorldViewProjection has all transformations    [attachment=18188:amd.jpg]   It's taken with AMD GPU, this is all OK.    But compare it to Atom's screenshot:  [attachment=18189:spectrogram_iconia.jpg]   All other objects are in place, but not the one  I render with HLSL, the colorful spectrogram surface.     If I convert the coordinates in CPU side with WorldViewProjection matrix, and don't convert it all in GPU side, it renders OK with Atom too. But the matrix multiplication has to be done as follows:    Vector3 TransformCoordinate( Vector3 coord, Matrix transform )    {    Vector4 vector;    vector.X = (((coord.X * transform.M11) + (coord.Y * transform.M21)) + (coord.Z * transform.M31)) + transform.M41;    vector.Y = (((coord.X * transform.M12) + (coord.Y * transform.M22)) + (coord.Z * transform.M32)) + transform.M42;    vector.Z = (((coord.X * transform.M13) + (coord.Y * transform.M23)) + (coord.Z * transform.M33)) + transform.M43;    vector.W = 1.0f / ((((coord.X * transform.M14) + (coord.Y * transform.M24)) + (coord.Z * transform.M34)) + transform.M44);             Vector3 v3 = new Vector3(vector.X * vector.W, vector.Y * vector.W, vector.Z * vector.W );             return v3;     } which is in fact similar to SlimDx's Vector3.TransformCoordinate method.    Then I tried to implement the similar coordinate conversion in HLSL:   vout.Pos_ps = TransformCoord(position); float4 TransformCoord(float4 pos) { float4 tr;  tr.x = (((pos.x * WorldViewProjection._11) + (pos.y * WorldViewProjection._21)) + (pos.z * WorldViewProjection._31)) + WorldViewProjection._41; tr.y = (((pos.x * WorldViewProjection._12) + (pos.y * WorldViewProjection._22)) + (pos.z * WorldViewProjection._32)) + WorldViewProjection._42; tr.z = (((pos.x * WorldViewProjection._13) + (pos.y * WorldViewProjection._23)) + (pos.z * WorldViewProjection._33)) + WorldViewProjection._43; tr.w = 1.0f / ((((pos.x * WorldViewProjection._14) + (pos.y * WorldViewProjection._24)) + (pos.z * WorldViewProjection._34)) + WorldViewProjection._44); return float4 (tr.x * tr.w, tr.y * tr.w, tr.z * tr.w, 1.0f);  } Well, it works fine with other computers, but with Atom it doesn't. The result is even worse than mul(vector, matrix) I used originally, the transformed coordinates are typically in the center of the screen in tip of the needle size, but badly warped.    I really don't want to move all coordinate conversions to CPU side, that would be a massive task as we have so many different data visualization stuff implemented.    What am I missing? Is there any way to improve floating point accuracy on this this machine? Should I forward resolving of this case to Intel?      
  7. mhagain, that's wrong, yes. No software should mess up with the DirectX DLLs directly. Our software certainly doesn't. I'm just telling that some (yet unidentified) software is messing up the DLL. And that causes our software to not work.
  8. Received all D3D*.DLLs from customer's PC, from both c:\windows\System32 and c:\windows\SysWOW64 folders today. System32-folder is the place where 64-bit DirectX DLLs exist in 64-bit machine. But that's not the case regarding D3DX9_43.DLL in this specific system. By using Visual Studio's command prompt, dumpbin /headers c:\windows\System32\d3dx9_43.dll it revealed it is 32-bit (x86 in file file header section). All other D3D DLLs are 64-bit (x64). Found also a file named "D3DX9_43.old", which in fact is the correct 64-bit DLL. It is still a big mystery which software has explicitly tried to update the DLL into wrong folder, and also time stamped it to 30th November 2012.
  9. Hi Mike, I just got the listing from the user. M$ seems to have updated d3dx9_43.dll, it's dated 30th November 2012! A week ago. I assume it is not anymore compatible with SlimDX January 2012? I'm sure we'll get a lot angry users soon... when they update their windows. Do you have any suggestions, Mike?
  10. Hi Mike, thanks for the tip. I already asked for d3*.dll listing from windows folder and it's subfolders... customer hasn't yet replied. I believe it's D3DX9_43.dll, dated May 26, 2010 is the correct one that is compatible with SlimDX January 2012?
  11. Dear all, we have a 3D software component written by using SlimDX January 2012 .NET4. It's a DirectX 9.0c app. One of our users have now reported a problem after windows update. It's a Win 7 machine. The software was working correctly but after Windows update that was run about 2 weeks ago, the following exception is thrown: System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception. at D3DXMatrixLookAtLH(D3DXMATRIX* , D3DXVECTOR3* , D3DXVECTOR3* , D3DXVECTOR3* ) at SlimDX.Matrix.LookAtLH(Vector3 eye, Vector3 target, Vector3 up) The windows updates were uninstalled but it didn't fix the problem. SlimDx runtime for x86 and x64 were both removed and reinstalled. It didn't fix anything. Newest GPU drivers were also updated for AMD FireGL V7900. I think you are going to propose reinstalling Windows, but we certainly want to avoid that! Any clue, anybody? I'm clueless :-(
  12. I was in long discussion with NVidia. They came in conclusion that NVidia render targets textures do not have support for multisampling when reusing is needed :-( So I have to create a new render target texture with multisampling support, and render the old texture in it.
  13. Thanks TheOrestes, It really must have something to do with Multisample anti-alias. When setting MultiSampling to None, re-using texture works with NVidia too. Before rendering into the render target texture, I use Clear command with Stencil flag. It gets rid of the Debug message of non-matching multisample types, and has hidden the actual problem. device.Clear(ClearFlags.Stencil, Color.Transparent,0, 0); But disabling AA is not option, because of loss of visual appearance. Is there any way to adjust multisampling type on-the-fly, without recreating the device?
  14. I'm rendering into same texture incrementally. Each refresh round I'm adding some details in the texture. Texture is set as render target. In the end of the round, I'm finally displaying the texture in the screen. By using Ati/AMD adapters, it works just fine. By using Nvidia (Quadro FX370 and GT9500 for example), I can only render 1 time for the texture. When I try to render into it again next round, it won't render any additinal graphics on it, is just remains the same. If I recreate the texture, I can render on it again, but only 1 time. For NVidia, I have made a special logic that it first creates a new texture and then renders old texture in it and then the new graphics. Like this, it works but causes significant extra overhead. I'm wondering if anybody has tangled with the same issue? BTW, there's no errors in DirectX debug output. DirectX runtime is in debug mode and working. Thanks in advance for any help...
  15. Hi everyone, We are successfully using compact vertex structure for Ati(AMD) Radeon GPUs, they work in all models about 5 years old or newer. We want to minimize the data amount to be written to the GPU for maximizing the performance, we are rendering 2D graphics with D3D9. The same vertex structure type doesn't work with any nVidia or Intel GPU in our app. We can successfully use the following struct for Ati(AMD): [size="2"][color="#0000ff"][size="2"][color="#0000ff"]internal[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]struct[/color][/size][/color][/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]CompactVertex[/color][/size][/color][/size] [size="2"]{[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]public[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]float[/color][/size][/color][/size][size="2"] X;[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]public[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]float[/color][/size][/color][/size][size="2"] Y;[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]public[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]int[/color][/size][/color][/size][size="2"] Color;[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]public[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]static[/color][/size][/color][/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]VertexFormat[/color][/size][/color][/size][size="2"] Format = [/size][size="2"][color="#2b91af"][size="2"][color="#2b91af"]VertexFormat[/color][/size][/color][/size][size="2"].None;[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]public[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]const[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]int[/color][/size][/color][/size][size="2"] StrideSize = 12;[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]public[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]static[/color][/size][/color][/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]VertexElement[/color][/size][/color][/size][size="2"][] VertexElements = [/size] [size="2"]{[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]new[/color][/size][/color][/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]VertexElement[/color][/size][/color][/size][size="2"](0, 0, [/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]DeclarationType[/color][/size][/color][/size][size="2"].Float2, [/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]DeclarationMethod[/color][/size][/color][/size][size="2"].Default, [/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]DeclarationUsage[/color][/size][/color][/size][size="2"].PositionTransformed,0),[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]new[/color][/size][/color][/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]VertexElement[/color][/size][/color][/size][size="2"](0, 8, [/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]DeclarationType[/color][/size][/color][/size][size="2"].Color, [/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]DeclarationMethod[/color][/size][/color][/size][size="2"].Default, [/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]DeclarationUsage[/color][/size][/color][/size][size="2"].Color, 0),[/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]VertexElement[/color][/size][/color][/size][size="2"].VertexDeclarationEnd[/size] [size="2"]};[/size] [size="2"]}[/size] And for nVidia and Intel, we have to use larger one: [size="2"][color="#0000ff"][size="2"][color="#0000ff"]internal[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]struct[/color][/size][/color][/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]LargeVertex[/color][/size][/color][/size] [size="2"]{[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]public[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]float[/color][/size][/color][/size][size="2"] X;[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]public[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]float[/color][/size][/color][/size][size="2"] Y;[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]public[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]float[/color][/size][/color][/size][size="2"] Z;[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]public[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]float[/color][/size][/color][/size][size="2"] RHW;[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]public[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]int[/color][/size][/color][/size][size="2"] Color;[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]public[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]static[/color][/size][/color][/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]VertexFormat[/color][/size][/color][/size][size="2"] Format = [/size][size="2"][color="#2b91af"][size="2"][color="#2b91af"]VertexFormat[/color][/size][/color][/size][size="2"].PositionRhw | [/size][size="2"][color="#2b91af"][size="2"][color="#2b91af"]VertexFormat[/color][/size][/color][/size][size="2"].Diffuse;[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]public[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]const[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]int[/color][/size][/color][/size][size="2"] StrideSize = 20;[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]public[/color][/size][/color][/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]static[/color][/size][/color][/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]VertexElement[/color][/size][/color][/size][size="2"][] VertexElements = [/size] [size="2"]{[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]new[/color][/size][/color][/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]VertexElement[/color][/size][/color][/size][size="2"](0, 0, [/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]DeclarationType[/color][/size][/color][/size][size="2"].Float4, [/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]DeclarationMethod[/color][/size][/color][/size][size="2"].Default, [/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]DeclarationUsage[/color][/size][/color][/size][size="2"].PositionTransformed,0),[/size] [size="2"][color="#0000ff"][size="2"][color="#0000ff"]new[/color][/size][/color][/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]VertexElement[/color][/size][/color][/size][size="2"](0, 16, [/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]DeclarationType[/color][/size][/color][/size][size="2"].Color, [/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]DeclarationMethod[/color][/size][/color][/size][size="2"].Default, [/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]DeclarationUsage[/color][/size][/color][/size][size="2"].Color, 0),[/size] [size="2"][color="#2b91af"][size="2"][color="#2b91af"]VertexElement[/color][/size][/color][/size][size="2"].VertexDeclarationEnd[/size] [size="2"]};[/size] [size="2"]}[/size] [size="2"]We have tried to detect the compatible type by investigating [/size] [size="2"][size="2"]bool compactSupported = (caps.FVFCaps & [/size][size="2"][color="#2b91af"][size="2"][color="#2b91af"]VertexFormatCaps[/color][/size][/color][/size][size="2"].DoNotStripElements) == 0;[/size][/size] [size="2"][size="2"]Ati/AMD has flag value set to 0, Intel and nVidia 1. [/size][/size] and also tried to force the compact format into use in nVidia and Intel, but they fail to render it. [size="2"]It's very difficult for me to believe that nVidia wouldn't support this kind of compact vertex type. [/size] [size="2"]So, can you say what are we doing wrong, and how to get a compact vertex type (x,y,color) working with nVidia? [/size] [size="2"]Thanks for any help... [/size]