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

Yelmond

Members
  • Content count

    7
  • Joined

  • Last visited

Community Reputation

110 Neutral

About Yelmond

  • Rank
    Newbie
  1. [quote name='Hodgman' timestamp='1346043064' post='4973664'] Out of interest, what kind of GPU and drivers are you using? [/quote] Card: GeForce GTX 480 Drivers: 301.42
  2. I managed to "fix" the issue by reducing my max vertex buffer size. I noticed that the size of the input layout didn't really matter. It was more to do with the stride size (size of my CPU vertex struct). But this is very much still magic for me as I don't understand how the maximum vertex buffer size is related to stride size. This also doesn't explain why I had still high frame rates before a device reset with the original vertex buffer sizes and only lost fps after the device reset. (I don't change vertex buffer sizes during device resets). It's no longer a pressing issue but I'm curious as to what's going on here.
  3. Hello, I have a trivial shader that simply draws quads. If the combined size of the vertex shader input struct (input layout) exceeds 52 bytes my application becomes signifcantly slower after a device reset (ie. resizing the window). When the application starts, I get close to ~600 fps, regardless of input layout size (within reason). As soon as I reset the device the frame rate goes down to ~50 fps. I know I've seen input layouts much larger than mine in use so I know it's not a limitation of DX9. What could I be doing wrong? Some of my code: The vertex shader input struct looks like this: [code] struct VS_IN { float3 posL : POSITION0; float3 tangentL : TANGENT0; float3 normalL : NORMAL0; float2 texC : TEXCOORD0; float4 colour : TEXCOORD1; }; [/code] and my input layout for it: [code] D3DVERTEXELEMENT9 genericVertexDesc_DX9[] = { { 0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0 }, { 0, 12, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_TANGENT, 0 }, { 0, 24, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0 }, { 0, 36, D3DDECLTYPE_FLOAT2, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_TEXCOORD, 0 }, { 0, 44, D3DDECLTYPE_FLOAT4, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_TEXCOORD, 1 }, D3DDECL_END() }; HR( AC3DX9Device->CreateVertexDeclaration( genericVertexDesc_DX9, &generic_DX9 ) ); [/code] If I change the size of "colour" to float2 frame rate no longer drops after a device reset. Thanks in advance.
  4. My textures are 400 by 400 each at the moment with only 1 MipLevel. They have DXGI_FORMAT_R32G32B32A32_FLOAT format. If I make them any larger the program will go into the unstable state without any other graphic app running. Regarding my references I create a fixed number (205) references in total and do not create more after that. I release on program exit along with the textures and this process has been tested and does indeed free all 205 references and textures.
  5. Sorry for the mixup. I do plan to draw on them during runtime; I just did not implement that part of the code yet so at this point I am not mapping them after initialization. I would like to figure this problem out first before I continue. My goal here is simply to have a large 3D surface that the user can draw on (with the mouse). It's way to large for a single texture to give me the quality I need so I need to do this dance with several dynamic textures. It's the best method I can come up with at the moment.
  6. Thanks for the quick reply. I only map each texture on creation and I create and initialize one texture each frame until all have been completed, after which, I do not map anything for the rest of the app's runtime. I will try creating one each 10 frames and report back but for now my question remains as to why my memory usage grows when I start another application well after all my initializations and mappings have been done and my app has been running for some time with a low stable memory usage. Also, if I close the second application my memory usage never decreases. As additional information, I create one resource for each of my textures at the same time I create the textures. I then store pointers for each in arrays. As the user moves the camera along the surface I load only 10 (out of 205) textures into the Effects file by choosing the appropriate resource pointers from the array. I mention this because memory usage (once in the unstable state) grows as I move the camera over the surface. Thanks again.
  7. Hello, I need to cover a large area with several D3D10_USAGE_DYNAMIC type textures. The problem I encounter is after a certain amount of texture data being initialized my application's Private Working Set explodes from a stable 40MB to over 1GB. This issue has the following behavior: 1. The number of textures is irrelevant, all that matters is the amount of memory they require so many combinations of texture size and number of textures reproduce this problem. 2. It seems stable under a certain graphic memory load and does not grow at all while using the application, however, above 40MB or so of memory load, the usage explodes and continues to grow while using the application. 3. The most curious of all, assuming I have the application in the stable state, is if I now start a new graphic intensive application alongside mine (both being windowed), MY application's memory usage explodes, without me touching my application. I can only guess that once graphic memory grows beyond a certain cacheable limit, virtual system memory goes insane but this only seems to affect my application. Is there anything I can do to alleviate this problem? --- I am running Windows 7 64-bit and my app is 32-bit. I am using VC++ 2010 Express and it detects no memory leaks; memory usage explodes well after everything has been initialized. For the memory readings I used Process Explorer. I know its not the most accurate measure but I'm not really comfortable for such high usage numbers regardless of accuracy. Thank you in advance for any help.