RuneLancer

Members
  • Content count

    1557
  • Joined

  • Last visited

Community Reputation

253 Neutral

About RuneLancer

  • Rank
    Contributor
  1. Handling static meshes

    Thanks for the reply! That pretty much answers my questions - I think I've got this thing figured out. My current graphic engine handles 2D only at the moment but I'm planning on reusing it in other projects and wasn't too sure if I was going the right way with things. I'm getting pretty darn good performance out of it as it is but there's still a bit of work to be done. Still, so far so good! I'm not sure I understand what you mean by changing static buffers several frames before using them. I'm assuming from that that I should favor creating static buffer in a game's "loading" phase, and that I should (generally) favor using dynamic buffers for any object likely to change its vertices (regardless of how frequently it does so)?
  2. Handling static meshes

    Hmm. Nobody knows?
  3. Problems with my 2D animation

    Well, for one... [code]aEnemy[i].y > BulletPosition.Y && aEnemy[i].y < BulletPosition.Y[/code] This here will always fail as the enemy's y position cannot be larger AND smaller than the bullet's y position at the same time. Check to see if the enemy's position falls within a range instead. For example... [code]aEnemy[i].y > (BulletPosition.Y + 8) && aEnemy[i].y < (BulletPosition.Y - 8)[/code] Or simpler still, just test to see if the difference between the bullet and the enemy's positions is less than a certain size. [code]abs(aEnemy[i].y - BulletPosition.Y) < 8[/code]
  4. Let's suppose I'm building a 2D sprite-based game engine and wish to proceed in one of two ways... 1- I create a large dynamic VB and dump all of my sprites into it each frame with their absolute screen position as their coordinates. (1 draw call total) 2- I create a static buffer and use model transformations to position the sprites. (1 draw call per buffer) The research I've done seems to show that creating a large dynamic VB would be the best way to go. Would this also hold true if, instead of a 2D engine, I were dealing with static models in a 3D engine? (I don't really see why not but I figure other things may play into this...) And is there some "tradeoff point" where exceeding a certain arbitrary amount of vertices would make the other solution better, or something similare? Thanks! Edit: Actually, now that I think of it, what constitutes a "static" mesh? I can't seem to find a better explanation than "vertices that don't change very often at all", but how permissive is that? Would a mesh that changes once every couple of seconds (like the score display in a game) be better suited for a dynamic VB, for instance, or is that infrequent enough to use a static VB?
  5. Odd behavior with D3DLOCK_DISCARD...

    [quote name='CodingCat' timestamp='1296984426' post='4770338'] Therefore, instead of clearing your vertex buffer, you should rather make sure that the number of primitives you are specifying matches the current number of valid primitives in your vertex buffer. [/quote] Arrrrgh. That's exactly what the problem was. I was using my vertex count rather than my primitive count. I can't believe I hadn't seen it sooner. Well, that's what I get for debugging until the wee hours of morning... Thanks; probably would've kept trying to figure this one out for a while if it weren't for your reply!
  6. I've noticed an unusual problem in my current project: polygons that should have been removed from the renderer seemed to stay there despite no longer being stored anywhere in my game. If a scene took (say) 200 polygons to render, some object (say a label whose caption changes) ends up changing and the scene takes 180 polygons, the 20 polygons that should have been deleted would sometimes "stick" as if they were still in the rendering queue. Only, they weren't. Eventually I found that they were in my VB. After locking it and before dumping vertices into it, if I memset it to 0 the problem is now completely gone. Only, I lock with D3DLOCK_DISCARD, which in my understanding is supposed to discard the contents of the buffer. Either I'm doing something very wrong, or I've misunderstood what's intended by this flag. I don't see other people doing this either, so I very much doubt this is what I'm expected to be doing... For the record, I have a single dynamic vertex buffer created with D3DUSAGE_DYNAMIC | D3DUSAGE_WRITEONLY and D3DPOOL_DEFAULT at initialization. Each call to the renderer locks this buffer with D3DLOCK_DISCARD, memsets the contents to 0 (seeing as the buffer contains the data from the previous frame otherwise... for some reason...), fills it with vertices, unlocks the buffer, and draws primitives. Nothing too fancy, really.
  7. Handling dynamic vertex buffer

    I'm using DX9.
  8. Load VERY BIG image onto texture

    Is resizing the source image a possibility? It sounds like you have a specific image in mind (given the specific dimensions) and want it to scale to the screen so unless you intend to support really huge resolutions, there's nothing to gain from keeping the source image at that size.
  9. Handling dynamic vertex buffer

    Thanks, that was highly informative! After doing a bit more research and with your post, I'm starting to think I may have overestimated the purpose of a dynamic vertex buffer - a lot of my meshes rarely change much (ex, windows, text labels, background images... most of my games are 2D and mainly alter texture coordinates rather than manipulating the mesh). Assuming I try to handle everything without having to touch the buffer as much as possible, it seems like a static buffer might be preferable in my case. Aside from locking the buffer, is there any way of modifying the texture coordinates and the vertices' colors? If so, I could get away with never having to touch the buffer again once it has been created. I'm guessing tbat's what you meant when you were talking about creative use of shaders?
  10. I've recently started refactoring my renderer to use dynamic vertex buffers instead of creating a static vertex buffer per mesh and destroying/recreating it everytime the object is changed. I'm not sure why, but I think that should improve the renderer's performance slightly. ;) I do want to write something efficient rather than just having "dynamic vertex bufferz loel!!" in my games, though. What I understand is that I'm to create a large dynamic VB, write vertices into it, dump it once it's full, and then flush the contents and start over. So that means I need to have a local copy of my meshes at all times. I'm under the impression it'd be better to keep any mesh in the scene loaded in the buffer and for the object to store an index to its vertices. That way, the overhead of copying the vertices into the buffer each frame wouldn't be incurred and all updating could be done by locking the buffer only once. But somehow this doesn't feel right (I understand a dynamic VB's contents are intended to be regularly discarded...) and I feel like I'd run into unpleasant problems (such as dealing with buffer "fragmentation" as objects are moved in and out of it)... So, I suppose I'm just looking for some advice as to how to proceed, really.
  11. Video memory not being freed up?

    It may be old, but I haven't had any cause to change it yet. :) My older one (ATI RAGE something or other) on the other hand blew its fan... It's hard to test anything given the time it takes for the bug to trigger, but next time it occures I'll see if I can run any of the samples. If those run but not my project, I suppose I can eliminate things one by one and see what I'm doing that the samples aren't (or vice-versa as the case may be). I'll double-check if I'm not creating something but never releasing it under certain (rare?) circumstances. Typically I'll have my destructors take care of releasing anything that may have been created, but I suppose it's not impossible the object itself is never being released (and by extension, all the stuff it reserves/creates). I'll see what that turns up. :) I've been unable to trigger anything while running in release mode so if nothing turns up I guess it's not that big a deal (but since I'm usually just running in debug mode it could simply be due to chance, too). Come to think of it, I've never tried switching to a release build once I start getting the problem...
  12. Video memory not being freed up?

    All of my textures are loaded through the same function. D3DXCreateTextureFromFileExA(device, path, 0, 0, 0, 0, D3DFMT_A8R8G8B8, D3DPOOL_MANAGED, D3DX_FILTER_NONE | D3DX_FILTER_MIRROR, D3DX_FILTER_BOX | D3DX_FILTER_MIRROR, 0xFFFF00FF, 0, 0, &res->texture); Same goes with all of my meshes. if(!SUCCEEDED(m_device->CreateVertexBuffer(p_verticeCount * POLY_SIZE_FLAT, D3DUSAGE_WRITEONLY, D3D8T_CUSTOMVERTEXFLAT, D3DPOOL_MANAGED, &vertexBuffer, NULL))) return; (...and...) if(!SUCCEEDED(m_device->CreateVertexBuffer(p_verticeCount * POLY_SIZE, D3DUSAGE_WRITEONLY, D3D8T_CUSTOMVERTEX, D3DPOOL_MANAGED, &vertexBuffer, NULL))) return; These can be loaded/created at runtime, but they're all D3DPOOL_MANAGED. My card is, admittedly, a bit old (ATI RADEON X800 - but my drivers were updated a little less than a year ago). I suppose it could be at fault, though it's hard to test this in any way because of how infrequently the problem occures... :/ (Edit: broke up a few lines of source for clarity)
  13. Game Design

    Technically, you could code a top of the line game that'd blow away even the best commercial game on the market all by yourself. But... ;) It depends a lot on the time you intend to invest in it and the scale of your project. It can be easy after working on the same thing for a few months to start losing interest and wanting to try out some newer ideas you've had in the intervening time. It can be particularly demotivating to start pumping your project full of "awesome ideas" and finding yourself going nowhere after a few months of work. If you're willing to stick to it and to keep reasonable aims though, there's no reason why a big and professional-looking project would be impossible. Start by a small, simple project first. You'll be amazed by how much you'll learn from it and, frankly, if you can't put together a small game, you probably won't do much better with a big one.
  14. Video memory not being freed up?

    Got it to trigger just now. :D Here's what I get. Direct3D9: :DoneExclusiveMode Direct3D9: (INFO) :Failed to create driver indexbuffer Direct3D9: (INFO) :Using P4 PSGP Direct3D9: (WARN) :Ignoring redundant SetRenderState - 7 // (up until here, everything's fine) Direct3D9: (WARN) :Texture cache thrashing. Removing MRU texture. // (boom, we're done...) Direct3D9: (INFO) :Removed texture with timestamp 0,0 (current = 2). Direct3D9: (ERROR) :All POOL_MANAGED resources in this device freed. No further video memory available. src.exe has triggered a breakpoint After last running (not recompiling; there were no changes in my source at the time) my project, it very quickly slowed to a crawl and crashed. And now, every attempt to launch it results in the above message in my output window as soon as I try to render. As I understand it, it tries to fit a texture into memory and fails because of a lack of space. It seems more like the memory is being reserved and never freed up rather than my code trying to load too many textures or an unsupported texture size because I'd be able to reproduce it every time otherwise. Do DirectX-related things become invalidated after my app terminates? I'm pretty sure it would (not that I don't release everything I create at the end anyhow) but if not then that's probably where I should start looking... And now, if I want to keep working on my project, I'm gonna have to reboot this old heap... :)
  15. Working on my game

    Depending on how comfortable you are with C++, you could look up the APIs/libraries I've mentionned in my earlier post. They provide ways of drawing things onscreen and usually support a few common image formats natively. I don't mean to discourage you, but it sounds like you're getting a little ahead of yourself if you're already meeting up with someone to work on a game at this stage. You should wait until you've made at least a simple game of your own before working on a larger-scale project with someone else. Picking up graphical programming with no prior experience does not happen overnight.