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 - Ganado

Pages: 1 [2] 3
16
General discussions / Re: SFML 3 - What is your vision?
« on: June 25, 2014, 07:24:25 pm »
@Kojay
Wait, I still don't get why doing that overload is a bad thing. Why not have give the option to write it either way?

17
Yep, calling
game.getRooms()[game.getCurrentRoom()].getInnerWalls();
every update is what's causing the issues, I will make it a const reference for each vector accessor instead when I have time.

18
Thanks for reading,
at the beginning of the Player::update() function, I added this local variable
std::vector<sf::RectangleShape> inner_walls_copy = game.getRooms()[game.getCurrentRoom()].getInnerWalls();
It isn't a const reference, I should be able to change that later, but I understand.
Is there ever a danger of returning a const reference for something like this?
Anyway,
    ...
    int num_walls = inner_walls_copy.size();
    for (unsigned int i = 0; i < num_walls; i++)
    //for (unsigned int i = 0; i < game.getRooms()[currentRoom].getInnerWalls().size(); i++)
    {
        if (mBody.getGlobalBounds().intersects(inner_walls_copy[i].getGlobalBounds()))
        {

            if (mIsMovingLeft)
            {
                difference = inner_walls_copy[i].getGlobalBounds().left
                             + inner_walls_copy[i].getGlobalBounds().width
                             - currPlayerRect.left;
                mBody.move(difference, 0);
            ...
    }
     ...
This code seems to now make the game run with any stuttering, even when in debug mode (which should be expected for such a simple simulation). Thanks a lot for the help! I think I need to think of a better way to structure my code maybe... at least I'm not making a copy of the game itself every update ;p


Edit: Upon further testing (increasing the number of walls to 1040), this one line, even if just called once per update cycle, causes a load of performance loss.
std::vector<sf::RectangleShape> inner_walls_copy = game.getRooms()[game.getCurrentRoom()].getInnerWalls();
So yeah I definitely need to make it start returning a const reference in Game::getRooms() and in Room::getInnerWalls(). Hopefully that will fix the problem..

19
General discussions / Re: SFML 3 - What is your vision?
« on: June 24, 2014, 02:11:48 am »
Very small feature:
Just as a sf::Transformable has a setPosition(float x, float y) as well as a setPosition(const sf::Vector2f& position),
it'd be nice if the setSize(const sf::Vector2f& position) function could also be setSize(float x, float y).

20
Before you read anything, note that this probably isn't what you'd call a "complete and minimal example" (at least, not the second spoiler of code, although both aren't terribly long), so if you don't feel like trying to figure out why my performance is horrible, please don't waste your time for me, I understand!

This is the Object Collision I've been working on.
  • mPlayer is an sf::RectangleShape
  • mWalls is an std::vector<sf::RectangleShape>
This may look long, but it is an example is for a very basic case:
The player is a direct member of the game class.
The walls are direct members of the game class.
This handles top-down, 8-directional movement.
For both x-axis movment and y-axis movement, if it is colliding with a wall, it finds how far the Player is into the wall, and moves it back by that difference amount.

(click to show/hide)

The X- and Y-Axis movements are separated to allow for sliding. I'm not sure if there's a better way to do this, but that isn't really the problem right now.

Basically, the above code works great. It seems to be handle 10,000 sf::RectangleShape objects (the walls) just fine (the problem with 10000 rectangles is drawing them all, but that's unrelated, and was just a performance test).


HOWEVER, when I tried to "apply" this code to a more complicated project, the performance is unbearable against even a not-so-high number of walls (I believe around 40 or 80 rectangles).

(click to show/hide)

I am sure that it's the Object Collision part of the code that's causing the unplayable performance in the second block of code, it can handle the draw calls just fine when I comment out the X- and Y-collision segments. I understand that implementing a Quad-tree or something would increase performance, but the problem here is definitely something that should be fixed at its source instead of trying to cut around, especially with so little walls.

Anyway, so, if you have the time, please look through and compare the two blocks of code I have. I can see why the second block of code is more complicated, but the performance hit is unbearable, and I don't understand why this disparity exists!





EDIT:

Okay, so I've been tinkering with it some more, and so far it seems to be that the accessor "getter" methods that are causing the most problems.
doing this:
    int num_walls = game.getRooms()[currentRoom].getInnerWalls().size();
    for (unsigned int i = 0; i < num_walls; i++)
    { /*commented out code*/}
compared to this:
   for (unsigned int i = 0; i < game.getRooms()[currentRoom].getInnerWalls().size(); i++)
   { /*commented out code*/}
seems to give a huge performance boost right off the bat...

my get___() methods are currently returning the member itself, nothing special.
ex:
std::vector<sf::RectangleShape> Game::getRooms()
{
    return mRooms;
}
Would returning a reference instead really save that much performance? Sorry if that's more of a C++ question than an SFML one...

21
General / Re: Processor usage, using the Intro's fixed timestep code
« on: June 03, 2014, 06:47:18 pm »
Alright, then I think I have it set up good. Thanks for reading my walls of text!

22
General / Re: Processor usage, using the Intro's fixed timestep code
« on: June 03, 2014, 06:35:27 pm »
I guess I wasn't being clear, whether I'm using Vsync or (exclusive) the framerateLimit, I just want to confirm that this shouldn't mess with the update logic in the fixed timestep because of the sf::sleep inaccuracies.

23
General / Re: Processor usage, using the Intro's fixed timestep code
« on: June 03, 2014, 06:28:35 pm »
I downloaded Sleepy, I'm still trying to decipher what some of it means... if I find anything from it I'll post it here.

Adding
mWindow.setVerticalSyncEnabled(true);
before the main loop did solve the processor issue, but as you said in your linked page, that shouldn't really be a "solution", should it?

And, I partially understood that, but I thought having a function that called sf::sleep would make the fixed timestep become inaccurate, or defeat the purpose of it.
Quote from: Book
Sleeping is not very accurate, so you should not use it for exact timing purposes. The method sf::RenderWindow::setFramerateLimit() tries to achieve the specified frame rate by calling sf::sleep() internally. It is a nice function for testing purposes, but it also lacks precision.

I thought that using the Window.setFramerateLimit(unsigned int limit) function negated the fixed timestep, or something. But if using both on top of each other makes it limit the frame rate while still providing a fixed update, then I will use that. Without making inaccuracies?

Right now I'm using the aforementioned function set at 60, and it's giving me a frame rate of 50-51 instead of the 700 in the previous picture (and the image does still move at the same rate, as far as I can tell, in case that wasn't clear).
Using Vsync gives it a 60-61 framerate, but both significantly limit the processing.

Thanks for the help. Could you confirm that using the tutorial's fixed timestep while also using the setFramerateLimit function does not decrease the accuracy of the logic?

24
General / Processor usage, using the Intro's fixed timestep code
« on: June 03, 2014, 04:43:46 pm »
I know there's been threads on stuff like fixed timestep, but my question derives from that but is not talking about it in itself.

http://en.sfml-dev.org/forums/index.php?topic=3423.msg22221#msg22221
My issue is similar to the above link. It's not using up 50%, but it's still the most CPU-used program in the Task Manager (Windows 7).

The code I am using is verbatim https://github.com/SFML/SFML-Game-Development-Book/tree/master/01_Intro except I just have all the .cpp/.hpp files in one folder. Also, I read that mentioned article on a fixed physics timestep.

My problem is why such a simple program makes the processor work hard. I have made other programs in my free time, but I have set a max frame rate in the program, and using this, it runs almost silently like other low-power games.

Is there something simple I can change to the Intro's code to make it still have a fixed timestep but also limit the processor (this is done through sf::sleep when the MaxFrameRate setting is set)? Edit: Would having the maxFrameRate function on top of the fixed timestep part of the run/update cycle make it still have a fixed timestep but not run as hard? I feel like that would cause inaccuracies or defeat the point.

Image:
(click to show/hide)

25
Graphics / Help with rectangle collision into walls while going diagonal
« on: December 27, 2013, 09:43:38 pm »
Hello, been a while since I've been able to use SFML for stuff, feels good to use it again, anyway:

The program I started working on yesterday basically makes 100 random rectangles that act as "rooms", creating random passages between the rooms each time the program is run. The player can navigate through these paths.

I have basic object collision set up, but my problem is determining the best way to go about letting the player move after hitting a vertical or horizontal wall.

The important code is here:
        ...
            case sf::Event::KeyPressed:
                if      (event.key.code == sf::Keyboard::W)
                    up    = true;
                else if (event.key.code == sf::Keyboard::A)
                    left  = true;
                else if (event.key.code == sf::Keyboard::S)
                    down  = true;
                else if (event.key.code == sf::Keyboard::D)
                    right = true;
                break;
 
            case sf::Event::KeyReleased:
                if      (event.key.code == sf::Keyboard::W)
                    up = false;
                else if (event.key.code == sf::Keyboard::A)
                    left = false;
                else if (event.key.code == sf::Keyboard::S)
                    down = false;
                else if (event.key.code == sf::Keyboard::D)
                    right = false;
                break;
            }
        }
 
        //////////////////
        ///  Movement  ///
        //////////////////
        last_x = player.getPosition().x;
        last_y = player.getPosition().y;
 
        if (right == true && left == false) // D
            player.move(SPEED, 0);
        else if (right == false && left == true) // A
            player.move(-SPEED, 0);
        if (up == true && down == false) // W
            player.move(0, -SPEED);
        else if (up == false && down == true) // S
            player.move(0, SPEED);
 
        for (int i = 0; i < NUM_ROOMS; i++)
        {
            if (player.getGlobalBounds().intersects(rooms[i].rectangle.getGlobalBounds()))
            {
                player.setPosition(last_x, last_y);
                break;
            }
        }
    ...


The problem I have right now is that if the player uses keys to go diagonal (ex:, the W+D keys, WASD keys) while against a vertical wall, it prevents the player from moving up/down. Same situation with horizontal walls, it prevents the player from moving left/right while pressing (S+D) or (A+S). The method I'm currently using it keeps track of the last position of the player before hitting the wall, and if it collides, the player goes back to the position it was at before.

Most other basic games I've played allow the player to still move even if they are technically going diagonal while against a wall; it simply makes the player go down instead. I hope that makes sense, please tell me if it doesn't.

Here is a link to the program I made:
http://www.sendspace.com/file/od07v5
If you don't trust opening that file, please feel free to compile the code yourself:
http://pastebin.com/fK0QePp7

You are the red square. Uses WASD keys by default to move.

If you play it and try to move diagonally inward to a wall, you'll see you can't move at all. I would appreiciate it very much if someone could guide me on how to fix this.

EDIT:
I got it to work as I wanted it to by splitting it into two For loops between x and y movement, although I doubt this is the most efficient method, probably quite inefficient, but "it works".
        last_x = player.getPosition().x;
        last_y = player.getPosition().y;

        if (right == true && left == false) // D
            player.move(SPEED, 0); //make it an elapsed time "time-step"?
        else if (right == false && left == true) // A
            player.move(-SPEED, 0);

        for (int i = 0; i < NUM_ROOMS; i++)
        {
            if (player.getGlobalBounds().intersects(rooms[i].rectangle.getGlobalBounds()))
            {
                player.setPosition(last_x, player.getPosition().y);
                break;
            }
        }

        if (up == true && down == false) // W
                player.move(0, -SPEED);
        else if (up == false && down == true) // S
                player.move(0, SPEED);

        for (int i = 0; i < NUM_ROOMS; i++)
        {
            if (player.getGlobalBounds().intersects(rooms[i].rectangle.getGlobalBounds()))
            {
                player.setPosition(player.getPosition().x, last_y);
                break;
            }
        }

So, I guess this is solved as far as I can tell, but if you have a suggestion as to a better way to let you "slide" against the wall while going diagonal (or movement in general), please reply!

26
Graphics / Re: sf::Sprite::getColor() return value problem
« on: September 09, 2013, 06:48:14 am »
Ah okay, I can't try it right now, but Nexus' answer makes sense. My preliminary search before making the thread was searching for keywords like getcolor, so I didn't find anything good. Anyway, thanks.

27
Graphics / sf::Sprite::getColor() return value problem
« on: September 09, 2013, 06:13:25 am »
Okay so the problem I have right now is that when I use getColor().r on a sprite object (.r, .g, or .b, it doesn't matter which), I have the console output the return value, but the value it returns is a mystery.

I thought it would return an integer value between 0 and 255, yet it only seems to return weird characters.

Here's my cut-down code:
#include <SFML/Graphics.hpp>
#include <iostream>

int main()
{
    srand((unsigned)time(NULL));
    sf::RenderWindow Window;
    Window.create(sf::VideoMode(400, 255), "My Title", sf::Style::Close);
    Window.setVerticalSyncEnabled(true);
    Window.setKeyRepeatEnabled(false);

    sf::Texture tileTexture;
    if (!tileTexture.loadFromFile("tile.png"))
        {std::cout << "Error: Could not load block_grid image" << std::endl; return -1;}

    std::vector<sf::Sprite> tileSprites(10, sf::Sprite(tileTexture));

    tileSprites[0].setColor(sf::Color(rand()%256, rand()%256, rand()%256));
    std::cout << tileSprites[0].getColor().r; // this returns a random symbol, such as Greek character
    // For example, if I make the first parameter of the sf::Color(2, #, #), getColor().r returns a smiley face symbol.
    //the rest of the code isn't important
}
 

So, am I doing something wrong, or is getColor() supposed to return its value like that? Thank you for reading.

28
Graphics / Re: Small sprite displayed, not correct pixels shown
« on: August 14, 2013, 03:51:34 am »
Thanks for the replies and the info, I think I understand now.

29
Graphics / Re: Small sprite displayed, not correct pixels shown
« on: August 13, 2013, 04:09:11 am »
That does appear to be the problem, but could you explain why? Considering 1024 and 576 are both divisible by 2, why does it still make a round-off error? If I make the initial position, for example,
    playerSprite.setPosition(512, 288);
it does display the sprite correctly. Sorry if that's a more basic C++ question as opposed to SFML.

Anyway, so I changed it to
    playerSprite.setPosition(int(WINDOW_WIDTH/2 + 0.5), int(WINDOW_HEIGHT/2 + 0.5));
and it also displays the sprite correctly, thanks.

EDIT:
Also, obviously the round-off issue applies to the origin as well.
playerSprite.setOrigin(playerSprite.getLocalBounds().width/2, playerSprite.getLocalBounds().height/2);
If I comment this line, the sprite shows up correctly, but if I keep it active, then it's the old problem again. Why does the origin position affect what my sprite looks like when it is displayed?

30
Graphics / Small sprite displayed, not correct pixels shown
« on: August 13, 2013, 12:57:07 am »
Using SFML 2.1, Code::Blocks 12.11, minGW gcc-4.7.1-tdm, "ThinkPad Display 1366x768" monitor

My issue is how a certain sprite looks by default when generated on the screen.

Here's the necessary code:
    const int WINDOW_WIDTH = 1024;
    const int WINDOW_HEIGHT = 576;

    sf::RenderWindow Window;
    Window.create(sf::VideoMode(WINDOW_WIDTH, WINDOW_HEIGHT), "azertyqwerty", sf::Style::Close);

    sf::Texture playerTexture;
    sf::Sprite playerSprite;
    if (!playerTexture.loadFromFile("player.png"))
        std::cout << "Error: Could not load player image" << std::endl;
    playerSprite.setTexture(playerTexture);
    playerSprite.setOrigin(playerSprite.getLocalBounds().width/2, playerSprite.getLocalBounds().height/2);
    playerSprite.setPosition(WINDOW_WIDTH/2, WINDOW_HEIGHT/2);

    while (Window.isOpen())
    {
        Window.clear();
        Window.draw(playerSprite);
        Window.display();
    }



Here's the original image file used: http://i1093.photobucket.com/albums/i434/GanadoFO/player.png

It is a 5x5 square image. The border is red and the center pixel is a golden color.

Here's what the sprite looks like when displayed, no scaling or other transformations:

Here's the same picture enlarged (externally in Paint, not via the scale function) to clearly show the error:

You can see the weird displacement of the pixels compared to the original image. This is the problem.

If I use the scale function to blow-up the image in program run-time, it becomes the intended look, albeit very big:


So, my questions:
Why does it not correctly display the image file the way it is? Why does it displace the border pixels, and how can I fix it?
Is it due to SFML itself or my monitor/gpu?

If someone can test my image to see if it does the same thing on their program, I would appreciate it, thanks.

Pages: 1 [2] 3