Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: Frame Rate Droppage

  1. #11

    Frame Rate Droppage

    Resorting to vsinc, may seem nice, but can leave some strange artifacts on the screen as well. Be carefull with that option!

    Creating high resolution (1024x76 games is of course possible. In fact, some time ago, I was working on something that could display 1500 images (like in tiles) on the screen and still maintaining an average framerate of 50.

    Note that for a game at that resolution it (only?) takes 768 tiles to fill the entire screen!

  2. #12

    Frame Rate Droppage

    Make sure you have SystemMemory property set to false on each indivdual image in your image lists. My current project was running around 30fps and doubled after setting all the images in the lists to false. It's easy to do with DXGEdit if you use DXGs, which I would suggest anyway. But using Alpha with delphix is painfully slow, regardless. I would avoid using it if posible.

  3. #13

    Frame Rate Droppage

    Funny you should say that. When I set the images to systemmemory = False I lose about 10 frames per second.

  4. #14

    Frame Rate Droppage

    I use UnDelphiX (which is mostly the same as DelphiX, but, as far as I recall, with optimized headers and little more) and my frame rate is mostly constant. It drops heavily if I do something wrong (like Sining and Cosing in every loop :> or just using DrawSub or DrawRotate which I definetly suggest not to use if there are any other possibilities - it slows down machine), but mostly its constant 75 (AMD 1600XP 256 DDRAM m/b 266 GF4Ti4200 Golden ed. 128 Mb 5400 HDD) in every resolution or colour setting (8, 16 bits). Its acctually rather weird, 'cuz other people with not so good video have 85 fps and more while others have 50 and less..once I had bug - it showed just 5 fps, then I reinstalled videodrivers and 75 were back again.
    Again, I suggest you check your code for every Strech or Rotate Draws, because I have encountered a very notificable slow-down when using them. And your game sounds not so complicated to have frame-rate lower than blank DirectX mode screen. ( OK, two or three fps could be bearable.) Maybe re-think every part of code? Cant anywhere be done any optimizations?
    And again - this all is just my damn opinion.
    ..and I think that Fallout2 is an example for us

  5. #15

    Frame Rate Droppage

    Kamaz, it looks like your game encountered v-synch. In short, DirectX is waiting until a monitor refresh starts before drawing the next frame, so it can only run as quickly as the monitor refresh rate (in your case, 75Hz, i.e., 75 updates per second). Other people will have different monitor refresh rates, so their game runs differently but at consistent speed. Your game is probably capable of running at hundreds of frames per second, but it's just obeying the speed limit in a way .

    I don't get why people worry about the FPS once it's over 60. Unless it hurts the physics (which it shouldn't) then anything above 60 is utterly playable. It's the discrepency between FPS (i.e., having it jump all over the place) that makes games seem jerky.

    So anyway, look out for the following "magic" values: 60, 70, 72, 75, 85, 100, 120. These are typical monitor refresh rates. If your game gets one of those values as its FPS then you can disable v-synch (somewhere in the DelphiX options probably - have a look around, since I've never used DelphiX). Also, if your game only gets exactly half of one of the above values then you may also be affected by v-synch, but your game main loop is taking _slightly_ too long and you're only catching every other monitor refresh, hence half the rate. In either case, disabling v-synch will make your game run faster (but may introduce a visual artifact, "tearing", if you scroll quickly - but that's mostly in first person 3d games when turning).

    Your frame rate probably dropped to ~5 FPS before as you undoubtedly use an nVidia chipset. Relatively recent nVidia drivers have screwed up DDraw performance for whatever reason - I waited a good few versions but they didn't seem to care enough to fix it. Hence, I'm with ATI now (and a happy customer, plug plug). You can temporarily fix that issue by rolling back to an older driver release (I can't remember when this issue first arose) or by disabling hardware acceleration in the DirectX/DDraw control panel (which is a bit of a rubbish solution). I don't know whether nVidia have un-screwed-up this screw-up of theirs yet.

    To the OP: any translucency effects will be implemented on the CPU rather than hardware because DDraw doesn't provide for alpha-blending, unfortunately. This means that translucency is typically a _big_ speed hit compared to other stuff - scaling can be done on hardware (dunno if it is on DelphiX, but I'd be surprised if it wasn't), as can rotation (but, I believe, _only_ on hardware - no software support, so maybe DelphiX took a safe route and emulated it in software). The DrawRotateAlpha will almost certainly be implemented in software.

    If you switch to a 2d-in-3d package then you'll get a big speed boost for rotation and alpha blending (a big, big, BIG speed boost). The trick, though, is finding one with the features of DelphiX.

    It is probably possible to hand-optimise the alpha-blending functions inside DelphiX if you really wanted to (maybe to include MMX and such) - the question is, can you be bothered? If yes, then have a look at www.optimalcode.com for the fast alpha blending examples (dunno where - somewhere on that site, honest), or see if you can dig up Mike Lischke's alpha blending code in his virtual treeview (is that the one with source? Can't remember).

    Keep in mind that reading from video memory is slooooooow with a capital "very". If you're manipulating surfaces by locking them and changing pixels (likely to be done for the alpha functions, and maybe the rotate ones - check the DelphiX source) then you want to use system memory. This means slower drawing-to-final-destination but much quicker pixel fiddling.
    "All paid jobs absorb and degrade the mind."
    <br />-- Aristotle

  6. #16

    Frame Rate Droppage

    What the hell happened to the optimalcode site?! :shock: Bloody domain squatters?! Trying going to http://www.archive.org and typing in http://www.optimalcode.com in there to find the alpha blending examples, if they're still around...

    Sigh, another useful resources bites the dust. I'm tempted to contact the guy who ran that site (Robert Lee?) to find out what the heck happened.
    "All paid jobs absorb and degrade the mind."
    <br />-- Aristotle

  7. #17

    Frame Rate Droppage

    Gosh, thnx for the tip, Ali-Monster - now I feel like seeing/knowing the Highest Truth. Damn, of course it is so. Everything seems just understandable and clear now..
    ..and I think that Fallout2 is an example for us

Page 2 of 2 FirstFirst 12

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •