Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rutin

Pages: [1]
1
Graphics / Re: Stuttering with Interpolation (Sprites + Views)
« on: July 06, 2018, 12:37:08 am »
I just did an update from SFML 2.4.2 to SFML 2.5.0 and the problem appears to be gone.... I looked more into this and I found that other people had this same issue due to joystick polling.

I noticed on the 2.5.0 change log:

[Windows] Replaced time-based joystick poll with a hardware event handler

This must've been my issue.

2
Graphics / Stuttering with Interpolation (Sprites + Views)
« on: July 05, 2018, 11:18:52 pm »
I'm having a problem with stutters during interpolation. Depending on what I'm doing it can happen every 10+ seconds, other times it will happen every few seconds, or more frequent.

I noticed when I use a view and move it the same thing will happen but more often.

In my sample code I have one sprite and background with interpolation, but the stutter will happen.

Now I'm wondering if this is an error in my code which I don't see, or is SFML clock causing an issue between frames which is causing a hiccup? It's not as noticeable with just a tiny sprite, but when you're drawing tiles and using a view for a camera the hiccup is every few seconds.

At the start of my Logic for Input I set the Prev Pos to the Current, then once in the Draw part I interpolate like so:

interpolation = float(mainClock.getElapsedTime().asMilliseconds() + skipTicks - nextTick) / float(skipTicks);

                        mySpritePositionDraw = mySpritePositionPrior + (interpolation * (mySpritePosition - mySpritePositionPrior));
                        mySprite.setPosition(sf::Vector2f(mySpritePositionDraw));
                        mainWindow.draw(mySprite);
 

Problem Fixed - was Joystick polling from SFML 2.4.2

3
Audio / [Solved] Music/Sound causes Major FPS Drop after 1 min
« on: March 29, 2018, 07:18:51 am »
I'm dealing with a strange issue using either sf::Sound + Buffer, or just using sf::Music.

My project renders Frames over over 1000+, yet when I load in either a wave or ogg file, it will stutter if I launch through Visual Studio, and sometimes not stutter if I run a debug.exe only, but usually does.

I'm on Windows 10, and I'm statically linking SFML. I'm using SFML 2.4.2.

As the window is in Windowed Mode, I can click and hold on the top bar, which returns the music to playing normally, but if I release it stutters and drops my render frames down to 11 from 1000+. If I also move the window the problem goes away until I stop moving the window very fast. Fullscreen mode also does the same thing. If I remove the audio, my render frames are back to normal.

I simply do this before my game loop:


sf::Music gameMusic;
gameMusic.openFromFile("song.ogg");
gameMusic.play();
 

I've never seen such an issue before, is this a Windows 10 conflict?

EDIT:

I did a quick test and only did this:

sf::Music gameMusic;
 

The program becomes very slow, and is fixed if I comment the line out. So it appears just declaring sf::Music is causing the issue.

I looked at my project again, and it wasn't working because I was using sf::Music prior to sf::RenderWindow. When I move the Audio code after, it works perfectly fine.

The problem still exists though, after exactly 1 MIN of run time the audio stutters and frames drop. If I don't have any audio and just declare sf::Music gameMusic; it still slows in 1 min of run time without playing.

Fixed: Apparently I was either using the wrong .dll for openal32, so I just re-copied it from SFML and it works fine now. Glad this is working now! I was confused why calling sf::Music before sf::RenderWindow would cause any issues as it should make zero difference... Little error, big problem. :D I noticed threads exiting like crazy prior so I thought to confirm the .dll

4
General / Dewitters Game Loop - Break Down Review
« on: July 04, 2017, 05:41:58 am »
--

5
General / Fix Your Time Step - New to SFML
« on: December 03, 2016, 03:35:21 am »
Hello everyone! I'm new to SFML, but come from using XNA, Allegro, and some SDL back in the day.

I've always been use to just having a function that kept my games at 60 FPS lock, and all game play, logic, rendering was done in the same loop, with no independent timers, 100% based on frames rendered.

I'm extremely interested in duplicating the Time Step as per the article: http://gafferongames.com/game-physics/fix-your-timestep/ but I'm running into some issues as I've never used Delta Time, or any methods prior, everything was handled for me before.

NOTE: I turned on VSYNC in my Window Class to keep the rate at 60 FPS.

My current code for main.cpp:

#include "Game.h"
#include <iostream>

int main()
{
        // Time Test
        sf::Clock MainClock;
        double Time = 0.0;
        const double DeltaTime = 0.01;

        double CurrentTime = MainClock.getElapsedTime().asSeconds();
        double Accumulator = 0.0;

        Game GameTest;

        while (GameTest.IsWindowOpen())
        {
                double NewTime = MainClock.getElapsedTime().asSeconds();
                double FrameTime = NewTime - CurrentTime;
                CurrentTime = NewTime;

                Accumulator += FrameTime;

                while (Accumulator >= DeltaTime)
                {
                        // Game Loop
                        GameTest.Input(DeltaTime);

                        GameTest.Logic(DeltaTime);

                        // AI
                        // Physics

                        Accumulator -= DeltaTime;
                        Time += DeltaTime;
                }
       
                // Render Graphics
                GameTest.Render();

                // FPS - Shows in Console Window
                std::cout << "FPS: " << 1.0f / FrameTime << std::endl;
        }

        return 0;
}
 

My game.cpp code for moving the sprite:

// Input
void Game::Input(double TempUpdatesPerSecond)
{
        // Keyboard Movement for guy1 --- TEST !!!
        if (sf::Keyboard::isKeyPressed(sf::Keyboard::Up))
        {
                guy1.move(0, -32 * TempUpdatesPerSecond);
        }

        if (sf::Keyboard::isKeyPressed(sf::Keyboard::Down))
        {
                guy1.move(0, 32 *TempUpdatesPerSecond);
        }

        if (sf::Keyboard::isKeyPressed(sf::Keyboard::Right))
        {
                guy1.move(32 * TempUpdatesPerSecond, 0);
        }

        if (sf::Keyboard::isKeyPressed(sf::Keyboard::Left))
        {
                guy1.move(-32 * TempUpdatesPerSecond, 0);
        }
}
 

In the article I'm having trouble understanding what I do with Time? Why is it passed into my Update function along with Delta Time? Do I have my variables set up properly?

From the Article - Second Last Code Snip:

double t = 0.0;
const double dt = 0.01;

double currentTime = hires_time_in_seconds();
double accumulator = 0.0;

while ( !quit )
{
    double newTime = hires_time_in_seconds();
    double frameTime = newTime - currentTime;
    currentTime = newTime;

    accumulator += frameTime;

    while ( accumulator >= dt )
    {
        integrate( state, t, dt );
        accumulator -= dt;
        t += dt;
    }

    render( state );
}

I also have a cout to show how many frames per second are being rendered out to make sure it matches with vsync.

Since DeltaTime = 0.01; does this mean I'm moving at 0.01 * units per frame, at a maximum of 0.06 * units per second assuming steady 60 FPS with Vsync?

I would like to get my code working properly as to match the second last part of the article before learning how to do the final step. I also have no idea about interpolation.

I was also reading online that Delta Time is a very poor technique to use, and you should only program based on a fixed amount of ticks? My issue is making sure my games run good on 60 Hz or 200+ hz monitors while keeping the logic at a fixed update rate, and using any left over time to render as many frames as possible, I just need some guidance along the way.

Thank you!

Pages: [1]