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

Pages: [1]
1
Graphics / Re: NPOT artefacts on .Repeated = true texture?
« on: January 16, 2014, 08:00:57 pm »
Do you think that the way I'm initialising the view rect could be causing these problems?
Why not try?

Why manually set sf::View::Center at all? A quick look at sf::View()'s source tells you SFML does it in your stead automatically, without flooring (casting)...

2
Graphics / Re: Freeing memory and sf::Texture
« on: December 07, 2013, 11:02:43 am »
Secondly the task managed is not the way to monitor memory consumption. Allocating memory via OS is an expensive operation and since one allocation often doesn't comd alone, the OS is "smart" and assignes more memory than requested to your application and "frees" the memory only when either needed by the OS/other applications or when the unused memory is big enough.

Explains, thanks.

And actually I'm originally using the std smart pointers and co for the resource manager. Just had to make it as simple as possible. Thanks again ;)

3
Graphics / Re: Shader performance
« on: December 07, 2013, 10:24:32 am »
By any chance, could it be that you're loading the shader from file every single frame? Also, what kind of graphics card do you have? Does it run the shaders' example smoothly?

4
Graphics / [Solved] Freeing memory and sf::Texture
« on: December 07, 2013, 10:22:39 am »
Hello,

Given the minimal code below, at first run, in the Windows' task manager, my application is getting around 7000K memory, and after pressing a key (loading a texture), it takes 9000K. The problem is that memory stays at 9000K forever after, even when i free the texture memory, and reload it. Is this normal?:

#include <SFML/Graphics.hpp>
int main(int argc, char* argv[])
{
    sf::RenderWindow window( { 800, 600 }, "Testwindow" );
    window.setFramerateLimit( 60 );

    sf::Texture* tex{ nullptr };
    sf::Sprite sprite;

    while( window.isOpen() ) {
        sf::Event event;
        while( window.pollEvent( event ) ) {
                if ( event.type == sf::Event::Closed ) {
                        window.close();
                }
                else if ( event.type == sf::Event::KeyReleased ) {
                        if ( tex ) {
                                delete tex;
                                tex = nullptr;
                                sprite = sf::Sprite();
                        }
                        else {
                                tex = new sf::Texture();
                                tex->loadFromFile( "test.png" );
                                sprite.setTexture( *tex );
                        }
                }
        }

        window.clear();
        if ( tex ) {
                window.draw( sprite );
        }
        window.display();
    }

    if ( tex ) delete tex;
    return 0;
}

I'm using SFML2.1. Thanks.

5
Graphics / Re: Is clear() that necessary?
« on: November 01, 2013, 06:56:23 pm »
^ I must have missed that part.

Thanks everyone! Sorry for the dumb question...

6
Graphics / [Solved] Is clear() that necessary?
« on: November 01, 2013, 10:58:24 am »
Hello,

I have a case where I fill up the entire screen, opaque pixels and all, at every frame, so I don't use clear() for the microscopic performance gain i could have?

Just wondering if this is alright since i might be missing something, if ever it's going to cause problems on others computers or something.

Thanks.

7
Graphics / Re: Optimization while using SFML
« on: March 21, 2013, 11:16:11 am »
Make all frames of the animation in one single big texture, and use SubRects, pointing to a different part of the texture each frame of the animation.

Performance-wise, this won't be much different from the method you mentioned, but it is way much easy to handle and is a big plus to resource management.

A faster way, is to let the vertex shader handle the animation (using SubRects too), but it might be just as slow on old graphic cards than it is fast on newer ones, but it's not really worth it on small projects.

8
General / Re: GUI rendering frequency
« on: November 05, 2012, 09:22:02 am »
Oh, Forgot to mention that it's a GUI for game, jQuery was just an example to show how easing and animations are handled :)

I've looked onto other GUIs and they either don't have what I need or have way more than what I need (just like every library out there anyway), so I decided to make my own which didn't seem that hard afterall.

Well, after I've done a few tests, it seems that i'll drop the lazy-rendering option since I noticed that the GUI will be still re-rendered the most of the regions since there will be animations most of the time, and now this topic seems like a waste  ::)

Thanks!

9
General / Re: Getting Started: Runtime Crash
« on: November 04, 2012, 04:58:38 pm »
Make sure that the corresponding dlls (libsfml- ones) are in the same directory as the executables, since you're using the dynamic libs ;)

10
General / Re: Turn basesd games and sf::Keyboard
« on: November 04, 2012, 04:56:56 pm »

sf::Keyboard gives the current state of key, regardless of when it was pressed or since how much time.

Assuming your game runs at 60FPS, then your game loop runs at about 60 times per second, so when you press a key for exactly 1 second, this code
if (sf::Keyboard::isKeyPressed(sf::Keyboard::Left)) {
    moveLeft();
}
is called 60 times and so your character moves 60 steps.

What you actually need is to use sf::Events, a sample code would be :
sf::Event event;
while (mWindow.pollEvent(event)) {
    if (event.type == sf::Event::KeyPressed) {
        sf::Uint32 keyCode = event.key.code;
        if (keyCode == sf::Keyboard::Left) {
            moveLeft();
        }
        else if (keyCode == sf::Keyboard::Right) {
            moveRight();
        }
        else if (keyCode == sf::Keyboard::Up) {
            enterRoom();
        }
    }
    else if (event.type == sf::Event::Closed) {
        mWindow.close();
    }
}

In this code, our functions are only called the moment when the keys are just pressed, so in order to activate them again, one must release the key then press it again. So instead of asking the keyboard : "Hey, is the left key currently pressed?" we ask him "Hey, did the player just press the left key this frame?" ;)

11
General / GUI rendering frequency
« on: November 04, 2012, 04:32:39 pm »
Hello,

I'm planning to write some personal GUI that mainly focuses on a jQuery-like animation functions, but i'm having some questions concerning render frequency :

  • Render every GUI element each frame.
  • Render only when an element requests un update, on a screen-sized texture that is rendered on the screen every frame.

The latter seems rather interesting, however I had read somewhere that rendering big textures is slow, not to mention that there would be quite a number of updates since there would be animations all the time (hovering, screen transition).

Being unable to do any tests (since I hadn't wrote anything yet), I wanted to ask for advice if ever someone already tried.

Thanks!

Pages: [1]
anything