• Content count

  • Joined

  • Last visited

Community Reputation

126 Neutral

About artisticdude

  • Rank
  1. Limiting Cpu Usage

    Ideally you would decouple your logic and render loops so that the logic updates occur in discrete timesteps, while the rendering occurs as fast as it can (usually constrained by vsync).   If you're looking for an algorithm to predict framerate, you could maintain a list of the update times for the last x number of updates, and then average those times to predict the future update time. You could even go a step further and track changes to the scene (adding new sprites, deleting old sprites, any other state changes that would change the update time), and then add some adjustment to the predicted time based on those state changes.   However, it doesn't make sense that you would experience notably heavier CPU usage while in a menu gamestate. Obviously I have no idea how you handle your logic updates, but maybe the excessive CPU usage you're seeing in those situations is a sign that you should rewire your update logic calls in those states to only update the portions of the game logic that are relevant to the current state?
  2. DX11 Cannot Create A Constant Buffer

    You can skip the headache of manual padding and dummy variables by using attributes to explicitly set the structure size and field offsets:   //Explicit layout kind, specify size (which must be a multiple of 16) [StructLayout(LayoutKind.Explicit, Size = 16)] public struct PerFrameTextureInfo {     [FieldOffset(0)]     public float Width;     [FieldOffset(4)]     public float Height; }   Source (and also a resource I highly recommend reading):
  3. Hi all, I'm trying to create a geometry shader with a stream-output in the SharpDX DirectX11 wrapper, but for some reason the code I have refuses to create the geometry shader (it throws an unhelpful exception about being initialized to null).   For broader context, I'm trying to create a (very simple) GPU-side particle system where the vertices are passed to the pipeline, the vertex shader shifts their positions by a delta-time variable passed in via a constant buffer, then the pass-through geometry shader streams the updated vertex positions back to the CPU via the stream-output stage. Then for the next frame I use the contents of the stream-output buffer (which contains the updated vertex positions) from the previous frame as the new vertex buffer.   A few ideas about the source of the error: Are my semantics right? In the StreamOutputElement I specify the SV_Position semantic, because that's the semantic used in the PS_IN structure that the Geometry shader outputs. I've tried changing this to Position both in the initialization code and in the shader, but it hasn't made a difference. Should the GS function in the shader be returning void? I'm operating under the assumption that appending the output to the stream also sends it down the pipeline to the pixel shader, but come to think of it, this may not be correct... I'm going to go play around with that. I don't see why that would make the geometry shader fail to initialize though.   Here's how I'm attempting to create the geometry shader: using (var geometryShaderByteCode = ShaderBytecode.CompileFromFile("shaders.hlsl", "GS", "gs_4_0", ShaderFlags.Debug)) { SharpDX.Direct3D11.StreamOutputElement[] outputElements = new SharpDX.Direct3D11.StreamOutputElement[] { new SharpDX.Direct3D11.StreamOutputElement(0, "SV_POSITION", 0, 0, 1, 0) }; //the following line is the troublesome one geometryShader = new SharpDX.Direct3D11.GeometryShader(defaultDevice, geometryShaderByteCode, outputElements, null, 0); } And my shaders.hlsl: // Constant Buffer cbuffer CbChangesEveryFrame : register(b0)    // register b0 is slot 0 for constant buffers {     float time; }; // Shader input types struct VS_IN {     float4 pos : POSITION; }; struct GS_IN {     float4 pos : POSITION; }; struct PS_IN {     float4 pos : SV_POSITION; }; // Vertex Shader GS_IN VS(VS_IN input) {     GS_IN output;     output.pos = input.pos;     output.pos.x += time; //adjust the x-position by the timestep in the constant buffer     return output; } // Geometry Shader [maxvertexcount(1)] void GS(point GS_IN input[1], inout PointStream<PS_IN> pointStream) {     PS_IN output;     output.pos = input[0].pos;     pointStream.Append(output); } // Pixel Shader float4 PS(PS_IN input) : SV_TARGET {     float4 color = float4(1.0, 0.0, 0.0, 1.0);     return color; } And the entirety of my code can be found here, if anyone wants to look at the full picture.
  4. Math and/or Tutorials for Isometric perspective?

    Try Clint Bellanger's isometric math tutorial: (second time this week I've linked to that tutorial! :D ). That article was the key to my current understanding of isometric perspective/math, and I've used it myself and seen it used in real-world applications, so I can vouch for the accuracy of the information it gives.
  5. C++ 2D Isometric map problem

    This gamedev tuts+ article is a really nice introduction to isometric perspective in video games: Not C++ specifically, but the underlying theory remains pretty much constant for whatever language you choose to work in. If it's specifically the coordinate conversion formulas you're having trouble with, check this article out: It was written by Clint Bellanger, the lead developer of the FLARE (Free/Libre Role-Playing Engine) project, and it's unquestionably one of the best resources I've ever found on the subject. It helped me immensely when I was trying to figure out isometric math. :)