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

artisticdude

Members
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

126 Neutral

About artisticdude

  • Rank
    Newbie

Personal Information

  • Location
    Somewhere in the middle of everything
  1. 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

    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): http://timjones.tw/blog/archive/2011/03/08/marshalling-c-structures-into-directd-cbuffers-using
  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. Try Clint Bellanger's isometric math tutorial: http://clintbellanger.net/articles/isometric_math/ (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. This gamedev tuts+ article is a really nice introduction to isometric perspective in video games: http://gamedev.tutsplus.com/tutorials/implementation/creating-isometric-worlds-a-primer-for-game-developers/ 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: http://clintbellanger.net/articles/isometric_math/ 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. :)