• Advertisement

RuneLancer

Member
  • Content count

    1557
  • Joined

  • Last visited

Everything posted by RuneLancer

  1. 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?
  2. 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)?
  3. Handling static meshes

    Hmm. Nobody knows?
  4. 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]
  5. 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.
  6. 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!
  7. 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.
  8. Handling dynamic vertex buffer

    I'm using DX9.
  9. 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.
  10. 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?
  11. Every once in a while, my project will start slowing down after being compiled, crash with a message in the compiler's output window, and then crash every following attempt to run it. Even closing and reopening MSVC won't fix things (oddly enough, other DX-using apps don't seem affected). The problem is rather spontaneous - everything may run fine, I'll re-run my project and do the exact same things and... bam. The message it gives me is, "All POOL_MANAGED resources in this device freed. No further video memory available." My first thought was (and still is) that some graphical resource is created on the card and is never freed once my project stops running, eventually leaving no memory free for new resources. Since other programs aren't affected (as far as I can tell), I'm not so sure though. Googling for some info turned up very little help: this can happen if textures are too big, but that's not the problem here. It can also occure when mixing up D3DPOOL_MANAGED and D3DPOOL_DEFAULT resources, but AFAIK this isn't what I'm experiencing either. So, I'm a little stumped. It's no big deal since I can just reboot my PC (and I don't think it's ever occurred with a compiled release-mode application outside of MSVC but not knowing the cause makes it difficult to confirm) but I do feel like I may be doing something wrong.
  12. 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...
  13. 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)
  14. 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.
  15. 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... :)
  16. 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.
  17. Working on my game

    It largely depends on the graphical API you'll be using, not the IDE... You can work with any kind of image format, even one of your own creation. You will, however, need a way to load the image. The Windows API supports a few common formats natively and there exist a good number of image-loading libraries and classes for the rest. How are you planning on rendering? With DirectX or OpenGL? Or a 2D library of some sort like SDL or Allegro?
  18. Why Inline asm in C++/CLI creates horrible problem?

    Shouldn't your pIDispatch be initialized somewhere before you try to read the address it points to?
  19. Tilemap question?

    If this is the approach you intend to use, look into dirty rects. They can further speed things up if you don't find yourself scrolling the entire map very frequently. Dirty rects are basically rectangles that frame an area of the screen that needs to be redrawn because it's been invalidated (for instance, a sprite is moving across a certain region of the map and the area underneath it needs to be redrawn). They can drastically reduce the amount of pixels being updated each frame but are next to useless in other situations (for instance, if you scroll the entire map, then obviously everything needs to be redrawn). Basically, the more pixels you change (wether the change shows up in your final rendering or not), the more work your game is doing, the longer it takes for a frame to render. You want to avoid overdrawing. When a map has several layers and you pre-build each layer as a bitmap, there's little you can do to avoid this: your upper layers will overlap your lower layers. With the tile-based approach, you can attempt to detect if a completely opaque tiles overlaps the tile you're currently drawing (perhaps via a flag in your tileset) and skip it entirely if that's the case. Not "drawing" fully transparent tiles (ie, skipping them instead of drawing "nothing") can also speed things up, depend on how Allegro handles its transparency (sorry, I'm not very familiar with Allego ;) With the Windows GDI, you need to do a few binary operations to fit a "mask" to your image, and it's a lot of wasted effort when the mask is fully transparent. Allegro may be smart enough to detect the case on its own though.)
  20. IG Maker? Anyone?

    Out of curiosity, what are the tutorials you look up? It sounds like you are tackling problems that are out of your reach; it's unreasonable to expect to understand a tutorial on rendering a 2D tile-based map if you're struggling with arrays and properly building classes, for example. Rather than what you can't do or have trouble understanding, what do you understand right now? Could you write (for example) a small program that fills an array with numbers from 1 to 10? (Edit: I'm aware this is a little off-topic, though it does seem a little to me like you're trying to reap rewards without any investment. I hope I'm not coming off as a dick or anything. ;) )
  21. A question on design philosophy.

    I've run across the exact same problem quite a lot until I started laying out at least basic plans for my projects ahead of time. Just a quick list of game objects and how they loosely work is enough to make you spot a few things that may be missing in your overall logic/design. Typically, I'll create a main "game" class to run my games under. I'll make a text file containing this object (in plain english, not C++) and a brief list of members and methods (starting with an update method, at least). Then, I'll expand my list of objects and their contents until I've covered my entire game logic, clean things up a bit, and use it as a template to write my classes. The more the plan looks like a plain-english description of my game in list form, the better. No need to go into much detail at this point. It's often hard to anticipate everything, so without planning it's real easy to paint yourself into a corner...
  22. What you learn, mostly, are algorithms you can apply to different situations. It's all good and well to know that "this block of code" is used to display the player's character on-screen but it's even more meaningful if you know why "this block of code" does what it does. You will have to memorize the instructions and special quirks of your language. That's no different than memorizing words and grammatical constructs in another language (non-programming; english-kind language I mean). What you don't need to memorize are each and every library function, class, etc. made available to you. There probably isn't a single developer who can tell you every function in the Windows API without having to look it up. Again, like with learning a new language, learning a new programming language doesn't happen overnight (particularly if it's your first). You start remembering things easier over time as you encounter the same concepts over and over again in varying forms.
  23. In some older projects, I've encountered an unusual timing issue that I've been meaning to patch up. The main update function of the game is called in response to a WM_TIMER message, which has been set up during initialization with SetTimer (15ms-ish delay, generally). Oddly enough, this causes (for instance) objects moving in a straight line at a constant velocity to appear to slow down then speed back up constantly (not in an extreme way but enough to be noticeable; seems to alternate every second or so). That is to say, the whole game slows down and then go back to normal on a regular basis. I'm pretty sure this is because of the timer, as every project I've written this way does this regardless of how much work the game is actually doing. So... 1- This is a problem regarding the way that I'm setting up or managing the timer. 2- The timer has nothing to do with it (ie, back to the drawing board). 3- This is to be expected when using timers and there exists no simple fix. (In which case, well, they're old projects anyhow; I'm exactly not up for a major rewrite of anything, such as making it non-frame-based. :) ) So, has anyone encountered this?
  24. Windows timers and timing problems

    I seem to have run across something interesting while experimenting with a more recent project. The older projects I was messing around with were written using the GDI. However, it seems that DirectX (when running windowed) doesn't simply lock up the application while waiting for vsync, but also returns control to Windows while it waits (at least I think that's what it is - it's the only thing being done any different) Without timers or any other delaying mechanism, I hardly go past 2-3% in terms of processor usage in most cases. Can't believe I've never noticed that yet, assuming that's what it is. :D
  25. Just starting out, multiple simple questions.

    Yes, that's generally something you do in code. The code part pretty much begins as soon as you're doing something with the image (like displaying it on-screen). There exists a number of tools with which you can make a game and skip most of the coding part. I've heard mostly good comments about GameMaker and played a few fun games made with it (Spelunky! :D), for instance. RPGMaker is also well-known for RPG-type games. It's essential when following a tutorial to understand what you're copy-pasting rather than just copy-pasting blindly. Even if it involves going back and re-reading. If you intend to use a programming language rather than a tool to make your game, you'll have to write your own code at some point after all.
  • Advertisement