Messages

1

Graphics / Deleting a sprite

« on: September 27, 2009, 05:15:40 pm »

ugh, just ignore me, a other myth that lived in my head busted  :lol:
tutorial Window - Opening a window, but that one fits in the flow I gues.

2

Graphics / Deleting a sprite

« on: September 27, 2009, 04:26:56 pm »

sorry, wasn't sure you got what he ment and I got fixated on the pointer ... (din't notice that other thingy)

Try something like this ...

Code: [Select]


int main()
{
....
    bool running = true;
    while(running)
    {
        sf::Event Event;
        while(App.GetEvent(Event))
        {
            if(Event.Type == sf::Event::Closed || (Event.Type==sf::Event::KeyPressed && Event.Key.Code == sf::Key::Escape))
            {
                running = false;
            }
        }

        App.Clear();
        App.Draw(Sprite);
        App.Display();
    }

    App.Close();

    return EXIT_SUCCESS;
}


App.Close() makes one/some of those calls behind it invalid, can't remember witch one do.
Someone should adjust the tutorials, some use the boolean others use App.IsOpened() ... confusing.

3

Graphics / Deleting a sprite

« on: September 27, 2009, 11:46:28 am »

Like Hiura sais, your app hangs because your calling a NULL pointer. Your main loop will go on after you press A so your computer tries to draw the spirit after it is deleted ...

Code: [Select]


delete Sprite;
....
App.Draw((*Sprite));


To prevent that you could use 'if(pointer != NULL)'

Code: [Select]


delete Sprite;
Sprite = NULL;
....
if (Sprite != NULL)
    App.Draw((*Sprite));


If you don't need the pointer then don't use it, the code you posted doesn't need a pointer. If you really need that pointer then you have 2 options:
- use the if() statement to make sure you don't call a NULL pointer
- restructure your code and make 100% sure you don't call a invalid pointer.

4

General discussions / Vec3, Vec2 Speed Test

« on: September 15, 2009, 01:54:15 pm »

not sure what you mean Tank, -O0 would not optimize the code at all. We only use -O0 (default) to debug or test new code. My target was to figure out the max amount of verts we could animate and look for way's to up that amount. So I don't see the point in testing it with -O0 ?

edit: hmm maybe there are some benefits in testing it with -O0, make sure it's as fast as possible that way and then up it to -O3 to get final numbers ...

5

General discussions / Vec3, Vec2 Speed Test

« on: September 15, 2009, 11:54:04 am »

I'm back to my first finding ... using the keyword inline speeds up the app with gcc 3.5 and 4.4.

As for the member operator definition compared to the non-member version. I only see a difference for that in gcc 3.5, gcc 4.4 doesn't seem to care about it when the inline keyword is used. If your not using 'inline' then member functions will result in a small performance boost.

We where using gcc 3.5 because gcc 4.4 takes optimization a bit further then you want it to. Profiling bits of code in gcc 4.4 is tricky business, the tests I did where using default shapes and those shapes are hard coded in to the app so ...

gcc 4.4 changed the code around from something like

Code: [Select]


float x = 1.5f;
float y = 2.5f;

main() {
  float z = x + y;
  std::cout << z;
}


to

Code: [Select]


main() {
  std::cout << 4.0f;
}


nice one but not what you want when your trying to figure out the amount of operation your app can pull off. I should type up some code so you can test it your self but ... to lazy atm.

6

General discussions / Vec3, Vec2 Speed Test

« on: September 08, 2009, 07:08:19 pm »

However, I wonder why your compiler isn't able to optimize that...

That was a good one. I have no clue when it comes to that stuff so I just use the tools provided, never took a closer look at them before.
But for some reason we are still using gcc 3.5, I updated this to 4.4 on my windows machine and ...

- All 3 test are exactly the same, no difference in performance at all
- The .exe doubled in size but it was exactly the same for all tests mentioned.
- Performance is a lot better then the fastest test I got with gcc 3.5, at first glance it's more then twice as fast.

all it took was updating from gcc 3.5 to 4.4, thx for the hint

7

General discussions / Vec3, Vec2 Speed Test

« on: September 08, 2009, 02:03:07 pm »

I had to look it up but if my info is right inside vs outside the class will create 3 vs 2 temporary variables in the cpu's cash/register.
1 vs 2 from the variables passed to the function and 1 for the result.

And yha we use those operators a lot so the difference in sfml might be less but still every cpu cycle counts so …

np

8

General discussions / Vec3, Vec2 Speed Test

« on: September 08, 2009, 01:14:41 pm »

g++.exe -m32 -c -O3 -s -I./inc -I./lib/inc -MMD -MP -MF <files> -o <files>
g++.exe -o ./bin/test.exe -s <files> -L <libs>

9

General discussions / Vec3, Vec2 Speed Test

« on: September 08, 2009, 12:31:46 pm »

This weekend I spend some time looking for a performance boosts, one of the things I tested where our vec2/3/4 classes. First off we have our own, we are not using those provided by sfml, we only use sfml to open a window and manage input (atm). But sins the classes look alike I was left wondering way Vec3 and Vec2 are not declared inline and even further down way are some huge Unicode function inline ?

Below some of the different way's I tested …

Initial Code: Overload outside of the class

Code: [Select]

   template <typename T>
    class Vec2
    {
        public:
           ...
    };

    template <typename T>
    Vec2<T> operator* (const Vec2<T>& v1, const T& v2);

    ...
    template <typename T>
    inline Vec2<T> operator* (const T& v2)
    {
        return Vec2<T>(v[0]*v2, v[1]*v2);
    }

improvement 1: Overload inside the class

Code: [Select]

   template <typename T>
    class Vec2
    {
        public:
            ...
       Vec2<T> operator* (const Vec2<T>& v2);
            ...
    };

    ...
    template <typename T>
    Vec2<T> Vec2<T>::operator* (const T& v2)
    {
        return Vec2<T>(v[0]*v2, v[1]*v2);
    }

improvement 2: inline decelerations

Code: [Select]

   template <typename T>
    class Vec2
    {
        public:
            ...
       Vec2<T> operator* (const T& v2);
            ...
    };

    ...
    template <typename T>
    inline Vec2<T> Vec2<T>::operator* (const T& v2)
    {
        return Vec2<T>(v[0]*v2, v[1]*v2);
    }

- The actual test involved drawing 125k cubes and animating them, this lead to +-8 million operations with vec2/3 per frame. The test was repeated 100(frames) * 2 (linux, windows) * 3 different pc's …
- I tried a lot more then just the 2 above but those stood out and they did not break anything (in our engine)
- Only tested with gcc both on linux and windows …

So here are the results I got:

Initial Code = 100%
improvement 1 = 126,23% - 26% faster
improvement 2 = 277,60% - 177% faster

The classes in sfml kinda look like our initial code, so maybe it would be a boost for sfml as well ? Is there a specific reason sfml is overloading outside of the class ? Something I might have missed ?

 

10

SFML projects / [09.11.09] JeZ+Lee's"The Final Option 100%™"SOURCE

« on: September 08, 2009, 10:51:37 am »

First off, you make it sound like your after free beer, [censored my self here].

Sure it's all hard work, it's just a way of protecting parts of your app. Some people do it the other way around, they keep there source code hidden but allow people to mod scrips, art, music ... Ether way they don't think about sharing there work for *free*, they open up parts of there work as a marketing tool ...

11

SFML projects / [09.11.09] JeZ+Lee's"The Final Option 100%™"SOURCE

« on: September 08, 2009, 12:13:22 am »

But still, I think if you do the game open source, it's stupid to make only the code open source and copyright all the resources.

It's very common to open source the code but keep the story, art, music and in some cases even scripts under a more restrictive license. That way people can learn, use and improve your code. On the other hand it stops them from simply ripping your game and running of with your hard work ...

Nothing stupid about that  :roll:

12

General discussions / Sigvatr's Newbie Thread

« on: September 04, 2009, 08:11:32 pm »

hmm, just thinking out loud here. Way not something like ...

Code: [Select]

sf::Window win;
sf::Clock drawTimer;

while( win.IsOpened() )
{
    // Machine speed game logic here

    if(drawTimer.GetElapsedTime() > 0.016666)
    {
        drawTimer.Reset();

        // 60fps game logic here
        // Render code here
    }
}

If you need 0.001 timers you need to make sure your render/logic loop never takes longer then that. That said, separate threads sound like a better solution but this could do the trick if you don't wane mess with threads yet.

13

General / Re: Tutorial question

« on: August 30, 2009, 10:35:43 am »

they say to use a clock to make movement the same across different computers

GetFrameTime() is a *clock* but the result will be different depending on computers speed, so you would need a other variable/check to make sure different commuters animate at the same speed. Using a real clock you can make it more accurate with less math, then again maybe it's just me or the way you implement it.

14

Graphics / FPS to Graphical Font?

« on: August 30, 2009, 10:15:57 am »

we use something like ...

Code: [Select]


      // Outside of main loop
        unsigned int Frames = 0;
        float FPS, Time;

        sf::String FpsString;
        sf::Clock Timer;

      // inside main loop
        Frames++;
        Time = Timer.GetElapsedTime();
        if (Time >= 2)
        {
            FPS = Frames / Time;

            std::ostringstream os;
            if(os << (int)FPS)
               FpsString.SetText("FPS : " + os.str());

            Timer.Reset();
            Frames = 0;
        }


this updates every 2sec to give a general idea of the average fps, lower/increase the 2 in the if statement if you want it to update faster/slower. Just stay away from the usual sprintf() solution to convert float to string, it's a bad one if you ask me.

15

General / Tutorial question

« on: August 30, 2009, 09:16:14 am »

Duno but the tutorial I'm looking at doesn't use GetElapsedTime() or a clock ...
http://www.sfml-dev.org/tutorials/1.5/graphics-sprite.php ??

it uses sf::RenderWindow::GetFrameTime(), a special clock that returns the time elapsed since last frame, it resets every time a frame ends.

But yha I still agree that this isn't the way to get consistent movement.