Messages

1

Graphics / Re: Texture not working from header c++

« on: July 31, 2014, 12:39:13 am »

This works

You should try passing the render window as a reference instead of a pointer to `GameObject::Draw` like you're doing here.

2

Graphics / Re: Completely Eliminating Jittery Movement

« on: October 22, 2013, 11:22:40 pm »

Stuttering isn't a result of any form of "time step method", it is the cause of something else in your code.

Just forget about using a fixed time step and focus on what matters: getting your game into a playable, fun state. That article is obviously geared to people who have passed that stage and are trying to polish their game, if what is mentioned in that article is even required, as I already explained above. Out of all the projects presented here on the SFML forum I haven't seen one that can realistically benefit from having a fixed time step, which is why I hate it when people recommend that article to beginners who are obviously struggling with other things and should better spend their time on those instead of this.

Do not recommend that article to beginners, please. Whoever understands why they would benefit from something like that will find it themselves when the time comes.

Just throw out that stuff, use a simple delta update and enjoy finishing the rest of your game. There are much more important issues... seriously...

As for optimizations, I'd recommend just learning to profile your code to speed up the things that need to be done and see what is unnecessary so you can get rid of them. The only way to make code faster, is to gather experience and get a feeling for writing efficient code. I'm helping you by not helping you, if that makes any sense.

I've actually been working on this game for the past 3 years or so, and it's gone through a lot of drastic changes throughout the course of that time.  I've found that a fixed time step provides the smoothest and most consistent physics simulations for my game, unlike with using delta time where I have difficulty making the physics and movement feel the same across multiple computers and hardware configurations.

I've been profiling my game every day, and I've noticed that most of the slowness & sluggish movement happens during the relevant ::draw functions.  It appears to be very random as well, with no correlation between the current running time.  It can very from 0.25 μs all the way to 120 μs as well, which should be marginally micro (hue hue) but that's the only location I can pin for the occasional sluggish movement and/or rendering.

3

Graphics / Re: Completely Eliminating Jittery Movement

« on: October 22, 2013, 09:37:15 pm »

If you want to follow that infamous article, you should really follow it all the way and more importantly understand what is said there. It was even explicitly mentioned that you would encounter stuttering if you didn't perform proper interpolation. I changed the last 2 methods of your player code to:

Thanks for your massive help and pointing me into the right direction!  It's working a lot better now, starting to add all of the other big elements back.  Did you happen to notice any other inefficiencies with my game loop?  I'm not sure if it's a bad idea to keep passing off an instance to my sf::RenderWindow for every ::draw function either. 

I agree, it's a bit silly for all of these micro-optimizations, but occasionally the stuttering is definitely noticeable whenever there isn't much going on, which is annoying and shouldn't be happening at all.

4

Graphics / Re: Completely Eliminating Jittery Movement

« on: October 22, 2013, 12:24:55 am »

Unfortunately that code isn't complete so all I can really do is guess and say you should try doing things differently in your update() function and see what happens.  As just one example, we can't see where left/right get set.

Plus, for semi-subjective issues like this, it's extremely helpful (even more so than usual) if we can compile your code and actually see the problem.

Here's a very minimal example on a public github repository.  I stripped away all the unnecessary things like animation classes and everything else to re-create the issue with the least amount of code.

It might be hard to notice at first without using any command line arguments, you might even need to look extra hard if you're running higher-end hardware.  I'm able to reproduce it if I move all the way to the right edge of the screen and all the way back to the left edge of the screen over and over again.

It's a lot more noticeable as soon as you use the "--force-fps ##" and the "--enable-vsync" command line arguments when running the example.

Thanks for any help with optimizing or helping me alter things to become more efficient!

5

Graphics / Completely Eliminating Jittery Movement

« on: October 21, 2013, 09:16:22 pm »

First, before getting started, I'd like to define what I mean by jittery movement — every 500 ticks or so, the sprite being moved might jerk forward a little bit, and then snap back in place, thus appearing to be jittery/stuttering while moving.

The stuttering is a lot more apparent if I force hard vertical synchronization or specify a capped frame rate limit using the SFML API, which I assume is because I've already implemented a fixed timestep and interpolation that might not work well with these limits.

The stuttering is hardly noticeable for me, but it's a lot more apparent for my friends with lower-end hardware, so I think I'm just doing things inefficiently.  Currently, I've turned off everything except for x movement for the player class to make the scope of the problem easier to manage. 

Game Loop:

void Application::initialize()
{
        videoMode.width = 1067;
        videoMode.height = 600;
        videoMode.bitsPerPixel = 32;
       
        dt = 1.0f / 60.0f;
        timeNow = gameClock.getElapsedTime().asSeconds();
        timeFrame = 0.0f;
        timeActual = 0.0f;
        accumulator = 0.0f;
       
        enableVSync = false;
        doForceFPS = false;
        forceFPS = 60;
}

int Application::run(int argc, char **argv)
{      
        ...

        pushWorld(new TownlevelWorld());
       
        while (rwin.isOpen())
        {              
                sf::Event event;
                while (rwin.pollEvent(event))
                {
                        cont_worlds.top()->input(event);
                        ...
                }

                timeNow = gameClock.getElapsedTime().asSeconds();
                timeFrame = timeNow - timeActual;
               
                if (timeFrame > 0.25f)
                        timeFrame = 0.25f;
               
                timeActual = timeNow;
                accumulator += timeFrame;
               
                while (accumulator >= dt)
                {
                        cont_worlds.top()->update(dt);
                        accumulator -= dt;
                }
               
                const float interpolation = accumulator / dt;

                rwin.clear();
                cont_worlds.top()->draw(rwin, interpolation);
                rwin.display();
        }
        release();
        return 0;
}

Player.cpp:

void Player::draw(sf::RenderWindow &rwin, float interp)
{
        rwin.draw(self);

        sf::Vector2f posInterp = pos;
       
        if (pos.x != lastPos.x)
                posInterp.x += interp;
        if (pos.y != lastPos.y)
                posInterp.y += interp;
       
        self.setPosition(posInterp.x, posInterp.y);
        lastPos = pos; 
}

void Player::update(float dt)
{      
        if (right == true && left == false)
        {
                xs += speed;
        }
       
        if (right == false && left == true)
        {
                xs -= speed;
        }

        if (!sf::Keyboard::isKeyPressed(sf::Keyboard::Right) && !sf::Keyboard::isKeyPressed(sf::Keyboard::Left))
        {
                right = false;
                left = false;

        }
       
        pos.x += clamp(xs, -6, 6);
        xs /= fric;
}
 

I'd appreciate any help to see if I'm doing things inefficiently, or what else might be causing the occasional stuttering.

6

Graphics / Re: probably problem with linux nvidia driver

« on: September 02, 2013, 05:27:35 pm »

I tried to compile your app but there are some errors, to be exact:
/home/kuba/cpp/smooth-movement-test-master/src/Application.cpp: In member function ‘void Application::popWorld()’:
/home/kuba/cpp/smooth-movement-test-master/src/Application.cpp:45:21: error: ‘cont_worlds’ was not declared in this scope

Ah, sorry about that!  I can't believe I didn't notice that as I thought that I was able to successfully compile the complete example before pushing the source code.

Change all occurrences of "cont_worlds" to just "world" in Application.hpp and Application.cpp to hopefully resolve the build errors.

7

Graphics / Re: probably problem with linux nvidia driver

« on: September 01, 2013, 06:23:53 pm »

I went a little overboard creating an example to see how well this works for you:
https://github.com/fatumlegion/smooth-movement-test

You can also use the various command line flags to test various settings.  By default, the program limits the FPS to 60 frames per second.  However, you can use --force-fps off, --force-fps x, and --enable-vsync to test how various setups might effect you.

If it still doesn't work work as expected, then it's either an issue with your compositor, your nvidia card doesn't work well with the newest driver, or my example is broken.

I'm using an nVidia GeForce GTS 450 graphics card with the 325.15 driver.  Here's my configuration:


You could also try turning off the "Sync to VBlank" setting in the nvidia control panel, but this might cause tearing if your compositor doesn't automatically turn on vsync for you.

Let me know!

8

Graphics / Re: probably problem with linux nvidia driver

« on: August 31, 2013, 02:24:50 am »

I'm using Arch with the stable nvidia package (325.15) with KDE, and honestly I get better results whenever I test my game on GNU/Linux than I do whenever I test it on Windows with the same hardware, and I hardly ever use my Windows partition either.  It's smooth on both platforms, but I notice occasionally every so often that it skips a little bit on Windows.  Strange.

Are you using a fixed time step for updating your physics and interpolation for drawing sprites on the screen?  That can make a big difference.

9

SFML projects / Re: SFML Light System - Let There Be Light

« on: June 13, 2013, 06:33:35 am »

Currently I'm trying to use LTBL in my project like this:

Code: [Select]

private:
ltbl::LightSystem *ls;
ltbl::Light_Point *testLight;


Code: [Select]

World::World(sf::RenderWindow &rwin)
{
ls = new ltbl::LightSystem(AABB(Vec2f(0.0f, 0.0f), Vec2f(static_cast<float>(screenWidth), static_cast<float>(screenHeight))), &rwin, "res/images/lightFin.png", "res/shaders/lightAttenuationShader.frag");

testLight = new ltbl::Light_Point();
testLight->SetCenter(Vec2f(400.0f, 400.0f));
testLight->SetRadius(500.05f);
testLight->m_size = 30.f;
testLight->m_spreadAngle = 2.f * static_cast<float>(M_PI);
testLight->m_softSpreadAngle = 0.f;
testLight->CalculateAABB();

ls->AddLight(testLight);
}

void World::draw(sf::RenderWindow &rwin)
{
rwin.setView(vw_main);
//Drawing logic (background, player, etc)
ls->RenderLights();
ls->RenderLightTexture();
}

However, there haven't been any changes to my scene after adding all of the necessary functions.  How could I further troubleshoot this?  Thanks for any help!

10

General / Re: How to make things happen for a duration of time? / Pokémon movement

« on: February 08, 2013, 12:43:46 pm »

You could use an sf::Clock object before you call your sprite's setTextureRect(); method.  Here's an example:

Code: [Select]

sf::Clock animateTime;

if (animateTime.getElapsedTime().asMilliseconds() >= 50)
{
        player.setTextureRect(sf::IntRect(src.x, src.y, spritesheet.getSize().x / 4, spritesheet.getSize().y / 4));
animateTime.restart();
}

Good luck!

11

Graphics / Failed to create texture, its internal size is too high

« on: February 08, 2013, 12:13:44 pm »

I decided to test my game on older hardware, and this issue was returned:

Code: [Select]

Failed to create texture, its internal size is too high
I noticed the documentation suggests using 512px wide textures for supporting older hardware.  I've started breaking up my giant textures into smaller, more manageable 512px wide textures, which is fine, but how could I make them seamlessly connect with each other?

Currently I have an std::map object that contains each "chunk" of the texture, and draws them side by side, which works just fine, except whenever I try to move them (there's a small gap in between each texture for a split second before they move).  I can fix this by offsetting each chunk by -1px, but then they don't tile properly.  Here's what my update method looks like:

Code: [Select]

for (int i = 0; i < spr_objs.size(); i++)
{
spr_objs[i].move(-(dt * 0.3f), 0);
}
Thanks for any help!

12

General / Compiling SFML 2.0 with Windows XP (Unsupported Compiler)

« on: December 22, 2012, 10:14:33 pm »

I'm using a Windows XP guest with VirtualBox on Arch Linux, but I don't think that's relevant because I got it working just fine on the same setup on my desktop.

Here's how I'm trying to compile:

Code: [Select]

cmake -G "MinGW Makefiles" .
Here's the output:

Code: [Select]

-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of void*
-- Check size of void* - done
CMake Error at cmake/Config.make:62 (message):
 Unsupported compiler
Call Stack (most recent call first):
  CMakeLists.txt:20 (include)


-- Configuring incomplete, errors occurred!
How could I troubleshoot this?  C:\MinGW\bin exists in my $PATH variable, and typing this returns the expected result:

Code: [Select]

> g++
g++: fatal error: no input files
compilation terminated
Thanks for any help!

13

General / Fixed time step (now that GetFrameTime() has been removed)

« on: February 01, 2012, 04:44:09 am »

You always have to preserve additional time that has been passed. My game right now runs at 100 updates per second and with the new Time stuff in SFML2 it runs very smooth at a constant rate of 100 updates per second.

Thanks for the help!  However, I'm still having trouble getting everything at the same speed it was whenever I was using RenderWindow.GetFrameTime(); in my fixed time step.  Currently everything moves a lot faster than it did before.

What was GetFrameTime() doing?  Initially I thought it returned the difference in time between the current tick and the previous tick, but I'm not entirely sure if that's true.

14

General / Fixed time step (now that GetFrameTime() has been removed)

« on: January 31, 2012, 11:12:44 am »

Currently I'm trying something like this:

Code: [Select]


const int gameTime = 10;
sf::Clock gameClock;

...

while (gameClock.GetElapsedTime().AsMilliseconds() > gameTime)
{
     gameClock.Restart();
     //update game
}


This doesn't quite work the same way as it did previously with GetFrameTime() in replace of the sf::Clock.  I'm having quite a bit of difficulty syncing up everything again after I updated to the newest SFML 2 build.

Would there be a better method for handling a fixed time step?

Thanks for any help!

15

General / Problems with building SFML 2.0 on Debian Sid

« on: January 03, 2012, 08:17:41 pm »

Hmm, it seems that the libGL symlink is broken.  I'm not entirely sure what to make out of this, however I've been able to determine this by using:

Code: [Select]


tim@debian:/usr/lib/x86_64-linux-gnu$ file libGL.so
libGL.so: broken symbolic link to `libGL.so.1'
tim@debian:/usr/lib/x86_64-linux-gnu$ cd ..
tim@debian:/usr/lib$ file libGL.so.1
libGL.so.1: symbolic link to `libGL.so.290.10'