Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 43

Thread: Library recommendation?

  1. #31
    Hello,

    I have second code.

    DirectX speed is ok, OpenGL not.

    Game isn't bad, I like this decent style and graphics is ok.

    some hints
    - graphics/zoom level is maybe too big
    - music is bit stereotypic
    - scrolling, moving, jumping isn't 100% smooth, e.g. cloud effect on background - effect itself is nice but there is tearing
    - game over effect is weird
    - text can be badly readable for kids, pixelatization isn't great for it

    If you have game speed limited by VSync it's not good approach, you can use some fixed limit for game update/logic or another solution.
    Last edited by JC_; 05-02-2018 at 12:46 AM.

  2. #32
    Thanks for trying it out!

    I just updated the game with a new version that checks if enough time has passed since the last frame in OpenGL mode. Could you please try if that makes it playable?

    @JC_, thanks for your hints, however this game was originally written in 1998-2001, first intended for DOS, later I added a kind of "emulation" layer for Windows, internally it is still using 320x200 mode with a 256 color palette. I would do many things differently if I wrote the game from scratch now (and I'm working on Charlie III). But here I'm just trying to get my old game onto Steam.

    BTW: during the game you can Ctrl+Shift+R to show the framerate.

  3. #33
    Still same and I'm not sure if new version was downloaded, put some version info there. OpenGL shows around 350 FPS, DirectX 60 FPS.

  4. #34
    Quote Originally Posted by Wiering View Post
    I just updated the game with a new version that checks if enough time has passed since the last frame in OpenGL mode. Could you please try if that makes it playable?
    When ran in OpenGL the gam is still way to fast. In OpenGL the game is actually running with 290 FPS while in DirectX the game is running nicely with 60 FPS.
    So now either your waiting code doesn't work or there is an error somewhere in your math.

  5. #35
    Sorry, I guess your computers must be so fast that they do the entire frame within 1 ms then. I had a little check of delta time > 0 (in case it would wrap around), but now changed it to >= 0.
    It should now be a little over 60 fps. If I try to get it exactly at 60 fps, it will stutter on systems where OpenGL does wait for the retrace.
    New build ID is: 2498995

  6. #36
    Now is speed ok, OpenGL have 64 FPS, but there is bad tearing in fullscreen when is screen scrolling. In windowed + maximized mode (OpenGL) it's ok.

    DirectX is in fullscreen ok, it is not completely smooth but playable without any problems.

  7. #37
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    Use V-sync, the tearing is because you're not. 60hz is likely the refresh rate of your display hence the 60fps of DirectX. This whole 'disable v-sync' deal is a total myth. The only reason it ever improves 'performance' of a game is because developers rarely handle it correctly and waste vast amounts of time spinning in a swap call. When you disable v-sync, it's not the rendering that makes things 'smoother' - the screen can only display (in this case) 60fps - it's the fact that all the other game code in the main thread gets called a lot more which superficially improves 'performance' because you're no longer wasting time waiting for a v-sync when you could be processing input and everything else.

    The correct way to get silky smooth performance with no screen tearing - is to use v-sync and make sure you spend the minimum amount of time blocked in a swap call.

    So if the refresh rate of the display is 60hz, that gives you 16ms per frame to do everything before you call swap. You should time each frame and try to spend (for example) 15ms running your game loop - you only break out and call swap JUST BEFORE the 16ms swap window. Miss the window and you drop a frame. If you drop a frame then you increase your margin to say 2ms - you find the right amount of time to spend processing so you always hit that swap window.

    Bad game loop :

    Do stuff.
    render stuff.
    call swap.
    swap waits.
    swap waits.
    swap waits.
    swap waits.
    swap waits.
    etc etc

    Good game loop :

    Render stuff.
    Do stuff.
    do we have some time left this frame? yes > do stuff, repeat.
    do we have some time left this frame? no > call the swap function.

    Do this properly and you'll have silky smooth, v-synced graphics.

    I render before I do any processing personally. This does mean I introduce a potential delay from input to displayed output - there's no reason you can't call render just before swap and decrease this potential delay - in fact it's probably best for most people - I only do this because the amount of time it takes to render a given frame is variable and can spike causing you to drop frames if you weren't expecting it - I have far more control over how much time I spend doing other things - so I leave them until last so I don't miss my swap window. A (at worst) 16ms delay between an input event and the potential response on the display is nothing to worry about - most guitar effect pedals introduce a greater delay from plucking the string to hearing the sound and believe me - no matter what gamers like to think, if it's good enough for a death metal guitarist? it's good enough for a head shot

    Disabling V-sync to improve performance only works on flawed code and it introduces screen tearing.
    Last edited by phibermon; 07-02-2018 at 01:15 PM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  8. #38
    I've done something like that in the old days in DOS and it worked perfectly, but in Windows from my experience it only works if you don't have any other programs running and even then not 100% reliable (that was in Win7, haven't tried 10).

    But the problem I have with OpenGL is that I don't seem to have control over V-sync. On the computers I've worked with personally, SwapBuffers() always uses V-sync and I can get a steady 60 fps, but as it turns out, for some people there is no V-sync and they get like 300 fps. I think it is even a setting that people can configure for their video card and even force. So I'm adding a little sleep function just in case V-sync doesn't work (and in that case people will get tearing).

    I've added a note in the description that if people experience tearing they should try DirectX instead of OpenGL.

  9. #39
    Quote Originally Posted by Wiering View Post
    But the problem I have with OpenGL is that I don't seem to have control over V-sync. On the computers I've worked with personally, SwapBuffers() always uses V-sync and I can get a steady 60 fps, but as it turns out, for some people there is no V-sync and they get like 300 fps. I think it is even a setting that people can configure for their video card and even force.
    The thing about VSync is that most graphical drivers have it off by default. So if you want to use VSync in your application then your application must request to enable it. Now there are some graphical drivers out there which have VSync enabled by default (I have most often seen this on laptops) but they still allow for applications to request disabling of VSync. Rarely you encounter computer which is forcing either enabled or disabled VSync and even then this is because users chose so.
    So you need to make sure that your application requests enabling of VSync feature in order for it to be used on most computers.

  10. #40
    Thanks, I can now test this at home by changing the video card settings and I finally got it to work.

    I was using wglSwapInterval(1) and it never seemed to work, but I was just calling it once after OpenGL initialization. Now I call it every frame just before SwapBuffers() and it works great!

Page 4 of 5 FirstFirst ... 2345 LastLast

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
  •  
Comodo SSL