• 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

236 Neutral

About gchewood

  • Rank
  1. Yep, fixed the issue with the indices and it's sticking at pretty close to 5ms even with the dynamic vertex buffer at around 10,000 vertices. Once again, thanks for everyone's help and patience.
  2. No, sorry. That's my mistake for not making it clear. The vertex buffer is around 20,000 vertices as the array 'vertices' at that point is of size 200. It's that size as that's around the maximum it will need to be.       Hmmmm, ok. This is a potential problem. Just checked the index buffer for when I'm up to about 10,000 vertices. The index buffer is at about 200,000. Right. So that seems problematic.  Yep, the issue is with the code I'm using the create the base vertex and index arrays. They're being extracted from a .X model. I just checked, the vertices, normals and texture coordinates are all fine. But it's just creating a hideous number of indices for some reason. Right, at least I know where the issue is. I'm glad my intuition was right. Thanks for all of the help, given my very vaguely described problem everyone. If anyone has ever extracted the index data from a model in xna before, please post with any info. Otherwise, I'm sure I'll figure it out. Thanks
  3. Yeah, I'm gonna run through some tutorials with PIX and see if that can help me. I'm also gonna see if I can cut the polycount a bit and then try geometry instancing instead. If I'm really not making any big mistakes in my use of the vertex buffer, it just seems that's not the ideal solution to my problem. It's that last comparison though that's still making me skeptical. My, admittedly uninformed, intuition doesn't seem to accept that a dynamic vertex buffer which is supposedly created for this very purpose, is slower than drawing each piece independently.
  4. Lol, well everyone else's responses don't seem to match your certainty on that?    I thought I already did show you the code used to create the vertex buffer. Again: vb=new DynamicVertexBuffer(GraphicsDevice, VertexPositionNormalTexture.VertexDeclaration, vertices.Length*100, BufferUsage.WriteOnly); and then to set the vertices: vb.SetData(activeVertices, 0, activeVertices.Length, SetDataOptions.Discard); And that performs the same no matter what I set for SetDataOptions. That's what you were asking for right?  So why is a dynamic vertex buffer with just 1 draw call slower than doing like 20 or so from the individual models? That doesn't seem right?
  5. If the only thing I draw is the dynamic vertex buffer, it jumps to 10ms (for the same 10,000 vertex buffer). Isn't that to be expected? There were various other things going on as well.   Yes, the models use the identical textures. They're using the same shader, which is where the sampling states are set. So the same. If I change the shader to not use textures, the outcome is more or less the same, only slightly better performance which I guess is to be expected. I'm completely new to using PIX so I'll certainly try that but it'll take a while to familiarise myself with it!
  6. @phi_t   Ok, yep tried just updating the vertex buffer in 1 big jump. Same outcome. Around 100fps.   @L.Spiro   Yes, I realise fps isn't a linear measurement. But I assumed everyone knows that and therefore there would be no issue? Or am I missing something other than the semantic preference?   By occasional, I mean it's not a set time interval. It's based on the user input. Like in something like minecraft. Yet the framerate remains entirely proportional to the vertex count. Whether or not it's being constantly updated or left for a few minutes.   Yes, I'm using an index buffer. And the code for the vertex buffer is  vb = new DynamicVertexBuffer(GraphicsDevice, VertexPositionNormalTexture.VertexDeclaration, vertices.Length*100, BufferUsage.WriteOnly); By 'single model', I mean it was loaded as the standard XNA model and only uses a single material. That means just 1 draw call right? Yes, I realise that uses a vertex buffer too, I meant 'vertex buffer' for the explicit one that I created, as opposed to the one generated automatically by an XNA model. And I'm pretty sure the number of state changes was identical in both situations. Why do you say I added multiple draw calls and state changes? As for you not having much information, obviously the issue is that it's currently part of a fairly complicated program. Distilling the part that's problematic so I could show you the code takes time, so I was hoping it would be resolved easily without requiring that. But now that it hasn't, maybe I should just upload some code?
  7. Thanks for the response Matias. I'm quite shocked that you say that's not a big drop actually.    Further evidence to support my general suspicion that I'm fundamentally doing something wrong:   I just re-ran the game and drew each of the individual pieces (the base pieces I mentioned previously) separately with the appropriate locations and the same shader. As I'd mentioned before, if I drew everything as a single model, I got 200fps. With the vertex buffer I was getting 100fps. With this new test I just ran (which I would think should be the most inefficient by far), I got about 180fps.    So yeah, I'm not buying that it's a necessary cost at all, there must be something else to it!
  8. Yeah, I'm combining them into an array and then copying that to the vertex buffer. But that's not every frame, it's just when the model is occasionally updated. So I assumed that couldn't be the cause of the frame rate issue? As for your suggestion, can you explain that a little more in depth. It sounds like you just said the same thing twice. How is copying them to a locked vertex buffer different than locking the buffer then writing directly to the locked memory?
  9. What do you mean by the draw timings? As in, the number of ms taken in the Present() function?  Why will that give any more info than the FPS I've already mentioned? Everything else about the solution is identical.
  10. Cool, I'll have a read through that page.   Yep, those flags are all set (or their equivalents in XNA) and I've tried with the Discard option.  I'm not calling createvertexbuffer every frame, just once at the beginning. I'm not entirely clear on the part where you say "careful that you don't attempt to read from the buffer while you have it locked". What do you mean by 'read' in this context? As I say, the model is dynamically being added to. But not each frame.    The vertex creation CPU side it quite simple. There are about 4-6 base models that I'm combining to make a larger structure. Those base models are loaded into vertex and index arrays at the beginning. Based on the user input, these base arrays are then combined into the larger array which is set to the vertex/index buffers when it's changed.
  11. Thanks for the reply Shaun, even if you called me cute (maybe I should change my avatar) No, the SetData function is only called when necessary. Not every frame. No, I didn't create the vertex buffer similarly for both models. I just use the inbuilt approach for rendering a model in the pre-fabricated example. I wasn't making the comparison to say they should be identical in the frame rate. If the run-time version was at 180fps or something, I'd just assume that was a necessary price to pay. But 100fps seems criminal. Otherwise, the vertex types and shaders are the same. I don't think Microsofts codes are necessarily the best. But the fact that I've used that particular 3D particle sample a lot, and have found it performs very nicely, seems to be a good sign.
  12. No, I'm not setting up any debug warnings. Like I say, I'm just using the same code found in the 3D particles sample from microsoft so there's really no room for me to be doing anything wrong in that sense. It must be more of a conceptual problem that I'm fundamentally missing.  And I've also tried using the 'NoOverwrite' option as described in Shawn Hargreaves' blog. No change.
  13. I'm using XNA but I assume the problem is analogous in DX9?   So I'm having a huge problem rendering a model that's created dynamically at runtime. It renders fine but it's creating a huge lag.   Here's the issue illustrated through a comparison:   1) Model with 10,000 vertices created in 3ds max and rendered with shader X in XNA ---> 200fps (after everything else has happened in the game)   2) Similar 10,000 vertex model constructed at runtime with a dynamic vertex buffer and rendered with shader X ---> 100fps This is a completely unacceptable drop and I assume I'm doing something wrong. Something like minecraft would be impossible to run if this was a necessary drop. I can post my code if necessary but I'm just using the same approach used by the 3D particles sample. I've profiled the projected with NProf and all of the time is being spent in GraphicsDevice.Present()    Help?
  14. Sorry about the delay, busy week. Thanks for pointing out that 900 will be truncated to 8. I guess that makes sense.    Haha and yes, I understand what multisampling does. I'm just drawing a regular scene with an environment (trees, bridges etc) and some characters. But no noticable difference (in visuals OR framerate).   Whereas in something like Unity, the difference between 2x and 8x is incredibly clear. If anyone can post screenshots of a noticeable difference in XNA 4, I'd love to hear from them!   Thanks
  15. Yeah, I've seen that you can (supposedly) set the multisample count when you instantiate a rendertarget2D.    I'm rather suspicious as to whether it's doing anything (or maybe I'm missing something else) because I've compared screenshots between supposed 2 and 8 multisample counts and they look identical. Also, it doesn't throw any kind of exception if you stick in a 900 count or something ridiculous.   So I'd conclude that there's either a bug that it's far too late to expect a solution to or you have to do something else on top of that that I'm missing?