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

Pages: 1 2 3 [4]
46
General / Re: Now to the ram "issues"
« on: October 26, 2017, 01:22:31 pm »
did you compile everything in debug mode or release mode
Release ofc

Just because you're attempting to re-make a game in C++/SFML from a game engine doesn't guarentee improved performance. A lot of these popular engines have invested a lot of resources (time, money etc..) into development and I'd imagine in a lot of cases out perform a lot of home-brew engines.

Anther thing to note, Game Maker does convert the "textures" into texture pages which can reduce the impact the texture sizes loaded in memory.

Probably my fault, i assumed true the "game maker has bad performance" statement you can see everywhere around, maybe it's just not that true after all.
Isn't a texture page just a bigger texture with more textures in it opposed to having multiple smaller textures?

47
General / Re: Now to the ram "issues"
« on: October 26, 2017, 04:43:12 am »
And what's your goal here? If you want everything to be like with game maker, maybe just use game maker? ;)
Memory "usage" is not very transparent and can have many different "origins".
Compressed texture sizes are worthless if you talk about memory.

I don't want everything to be like game maker. The exact opposite, i'd expect a C++ project to perform better than a Game Maker one. Here what i'm trying to understand is how comes this project requires more ram than its gm equivalent. I'd have expected it to require the same or even less. And i'm trying to understand where that memory usage comes from.

Quote
Do you have a system with only 100MB RAM?
The way of thinking implied by this question is the exact reason why instead of developing better hardware to get better content and performances, we develop better hardware to let lazy programmers code with always more laziness (hence java came to life ;D). It would be just fine for custom stuff etcc etcc, but the problem begins when this way of thinking is brought into software intended to be released.

Anyways again, all i'm trying to do is understanding where does this theorycally unneeded memory usage come from, since gm, which is not known for its performance, requires less; simple.

48
Feature requests / sf::Color single values modifier
« on: October 26, 2017, 02:05:06 am »
Greetings,
i wonder why single values of a color are not editable from the getter. I understand the "getColor()" method returns a constant to avoid deletion from memory. But then wouldn't it be viable to allow actively setting the values within that color?

If i only want to change something's "blue" component, why should i replace a color?
The only way i found till now was something like:
sprite.setColor(sprite.getColor().r, sprite.getColor().g, sprite.getColor().b + blue_variation, sprite.getColor().a + alpha_variation);
 
Wouldn't something like the following be more cpu-efficient, readable and clean?
sprite.getColor().setBlue(new_blue_value);
sprite.getColor().modifyBlue(blue_variation);
 

49
System / Re: SFML With no DLLS?
« on: October 26, 2017, 12:57:51 am »
When i make a small program and i want to send it to a friend or upload it i must include all the DLLs in a rar file. i just want a nice and simple .EXE file with no DLLs. (Well at least not send them)
i made a few games with Game maker studio and with that program you can
export just a single EXE file, really handy.
how do they do it?
they even pack the Textures inside the EXE.

what if someone just wants the game on their desktop. they would have to create a shortcut or put all the DLLs on their desktop. not really user friendly.

So you mean 99.99% of the games around are not user friendly? Since they all install inside a folder, with resources and stuff, and then add a shortcut in your desktop. You know, there's a folder called "program files" kindly delivered to you by Microsoft itself, which is there right for you to put your game folder with all its content ;)

Well unless you're using Linux. Linux is a real mess regarding where programs files are put. They appear not to follow any convention or standard (aside from using 3 characters folders which purpose cannot be easily understood), which is just a reason more not to use Linux.

A quick google search can help you finding how to create an installer for your program. Also note, Game Maker Studio specifies the "exe only export" as a kind of optional "fast tool". The regular game maker export for Windows does actually automatically generate for you a Windows installer for your program, which will, not surprisingly, extract your files in the install folder.

50
System / Re: Problem with threads on Linux
« on: October 26, 2017, 12:52:00 am »
Here are 2 bits of little knowledge from a new comer.
That's so bad. Using a thread to draw some objects, the same objects which values can be changing in the meanwhile in a totally different thread, without using any ward.
I've never done something thread-intensive in c++, but i've done so in c, and i can tell you this totally open approach is way too much open and unsafe. You'd rather have to add some mutexes here and there to prevent yourself from drawing something which is changing in the meanwhile.

e.g. an event's evaluation includes updating something's x and y coordinates. In the function you can think about it as an instant-action. But in assembly level that action is split into many instructions.
Now, it can happen you draw that object in the same "moment" the other thread is changing it, leading to weird things happening, if not errors.
For example, your "update" thread has completed the update of your object's x coordinate, then the task scheduler pauses that thread, the draw thread goes on drawing your object into its new x and its old y, then the task scheduler restores your update thread, and it finally updates the y coord.
Now, this one was a really optimistic one, and still a huge sync problem. That's why, with multi-threading, you WANT to spam mutexes wherever you're dealing with any kind of data which is shared between two or more threads. (sometimes leading yourself to understand that in many cases a second thread will just reduce overall performances).


51
General / Now to the ram "issues"
« on: October 25, 2017, 09:14:40 pm »
https://en.sfml-dev.org/forums/index.php?topic=22694.0
Context: redeveloping an app previously made on GM:Studio in SFML
Hello guys, i've resolved all the stupid coding errors i made, and now the cpu usage *almost* just fine (it still uses 0.2-0.4 more than the same program made with Game Maker, which is actually weird).
But now the issue is ram usage.
The GM version only uses 22mb of ram in front of the 63.9 being used by the sfml one. This can really be related to the compiledr, i'm not sure.
I've updated the project (first version loaded buttons textures multiple times).
Now the textures i load are sized as follows:
10.5 kb
279 bytes
329 bytes
9.01 kb
plus a single font
1085 kb
Even with rgba decompressed they shouldn't be much of a trouble...

The entire application files aside from resources (exe, dlls) is little, as i'd expect
1.33mb.

Ps.
i've checked for memory leaks but none found, the memory just starts at 60+ and then stays stable as expected

52
General / Re: I'm new | Problem with cpu usage
« on: October 25, 2017, 08:59:32 pm »
Ok everything's solved, thanks a lot for the quick answers and sorry a lot for the stupid errors i made and didn't see; i'll ask about ram usage in a new topic

53
General / Re: I'm new | Problem with cpu usage
« on: October 25, 2017, 03:12:22 pm »
PS: but yeah, changing the cycle really saved a lot of cpu (of course), i'm just sorry i did such a nooby error and didn't see it... so the main "issue" is solved, now i just have to find out what's wrong with my poor buttons

54
General / Re: I'm new | Problem with cpu usage
« on: October 25, 2017, 03:10:16 pm »
Ok, sorry for the edits;
now all the code in main is cycling by reference.
But i have weird reults when the draw is called by this way.
Main:
for (BarButton& btn : buttons)
        {
        window.draw(btn);
        }
 

Button draw:
void BarButton::draw(sf::RenderTarget& target, sf::RenderStates states) const
        {
        target.draw(sprite);
        //target.draw(text);
        }
 
(the rest of button code is unchanged, cfr first post^)
If i do it this way, buttons sprites are strangely vertically stretched (?)
Whereas, if the "target.draw(text)" is not commented, the whole window isn't shown at all. There must be something wrong in the button, but i don't manage to see what it is.

55
General / Re: I'm new | Problem with cpu usage
« on: October 25, 2017, 02:51:31 pm »
Oh thanks i forgot it gets copyed o.o
I should have sticked with the conventional "for (size_t i = 0; i<buttons.size(); i++)"...
but then why window.draw(btn) only work when i cycled the buttons with "for(type btn : buttons)"?

If i use "for (size_t i = 0; i<buttons.size(); i++){window.draw(buttons[ i ]);}" the window doesn't even appear... that's weird. and i don't see the fault
If i use "for (size_t i = 0; i<buttons.size(); i++){buttons[ i ].mouse_released())" the window doesn't even appear... that's weird. and i don't see the fault, while it works when creating new ones
If i use "for(size_t i = 0; i<buttons.size(); i++){buttons[ i ].mouse_released())" or "for (size_t i = 0; i<buttons.size(); i++){window.draw(buttons[ i ]);}" the window doesn't even appear... that's weird. and i don't see the fault, while it works when creating new ones

EDIT: about the second point i know, this is just temporary, and it should only affect ram, not cpu...

56
General / I'm new | Problem with cpu usage
« on: October 25, 2017, 02:15:14 pm »
Hello,
i'm new here; i started using SFML for the first time two days ago. After 2 years of active developing with both Game Maker: Studio and terminal-only C++ applications, i found myself being too much limited by GM's restriction, but sticking to GM for its magical internal resource management. Until i couldn't stand the restrictions anymore. Then i found this library, SFML, which should think about the graphics stuff while i focus on the real application (as a sidenote, i wasn't making actual games with gamemaker, but i needed it to give a nice graphical appeal to my programs).
Two days ago i started re-developing an utility i made for myself in the past with GM, which is an auto-hiding sidebar for windows 10 (i don't care about portability really) with an analog clock and a customizable array of buttons which can either open a website, run a program or execute a shell script (basically they call Window's "ExecuteShell" function), and a soft slow moving particle effect as background.
Now, while the Game Maker version also had a tetris and a minesweeper built in, the one i made with sfml only has the clock, the buttons and the particle effect.
It was all going fine, untill i said myself "let's see how much less cpu does a good old c++ equivalent to an heavily scripted gamemaker project". Had i never done that check!
My GM sidebar has a constant 0.6-1.2% cpu usage, and requires 26 MB of ram at fixed 60 steps per second.
SFML version, with less features, requires 6.0-12.0% cpu when using window.setFramerateLimit(60);. Same amount if i write a custom sleep-per-step. This happens with 8 buttons, i found out if the buttons are 2 it drops to 5.0-6.0 cpu usage (maybe rendering text is an issue?)
Without buttons at all the cpu usage drops to 0.6-1.0.

Which means, the SFML version has the same cpu usage as the GM version only if it has particles and clock going on. GM requires the same cpu to handle a bunch of buttons, tetris and minesweeper all together.

P.s. SFML version also requires almost 2 times the ram, it's reported usage is of 44.7MB, but i don't think it's an issue since i still have to optimize the texture part, and i have many small textures loaded, of which some repeated, instead of a bigger one (which in theory should perform better)

Some relevant code:
int main()
        {
        //first inits
        int WINDOW_WIDTH = 160;
        int WINDOW_HEIGHT = Screen::get_height();
        int WINDOW_MIN_X = Screen::get_width() - WINDOW_WIDTH;
        int WINDOW_SPEED = 6;
        int VERTICAL_SPACING = 8;
        int PART_AMOUNT = 8;
        int MAIN_RR = 0;
        int MAIN_GG = 240;
        int MAIN_BB = 255;
        int SEC_RR = 0;
        int SEC_GG = 0;
        int SEC_BB = 50;
        //Here i read the settings from an xml file, upper ones are defaults.

        //Window stuff
        sf::RenderWindow window(sf::VideoMode(WINDOW_WIDTH, WINDOW_HEIGHT), "Test", sf::Style::None);
        window.setPosition({ (Screen::get_width() - WINDOW_WIDTH), 0 } );
        window.setFramerateLimit(60);
        window.setVerticalSyncEnabled(true);
        //Get windows window handle to add some options
        HWND windows_window = window.getSystemHandle();
                //always on top
                SetWindowPos(windows_window, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
                //do not show in toolbar
                SetWindowLong(windows_window, GWL_EXSTYLE, WS_EX_TOOLWINDOW);

                //Transparent window
                MARGINS margins;
                margins.cxLeftWidth = -1;
                SetWindowLong(windows_window, GWL_STYLE, WS_POPUP | WS_VISIBLE);
                DwmExtendFrameIntoClientArea(window.getSystemHandle(), &margins);

        //Background as a texture fading right to left
                sf::Texture bg_texture;
                if (not bg_texture.loadFromFile("textures/t_bg.png"))
                        {/*handle error*/}
                sf::Sprite bg_sprite(bg_texture);
                bg_sprite.setScale(1, WINDOW_HEIGHT);
                bg_sprite.setColor(sf::Color(SEC_RR, SEC_GG, SEC_BB, 255));

        //Init my own particle system
        //not relevant since particles do not affect performance much, as expected from particles.
       
        //Add elements to the bar
                BarnackClock clock = BarnackClock((WINDOW_WIDTH/2), 84, MAIN_RR, MAIN_GG, MAIN_BB);
                std::vector<BarButton> buttons = std::vector<BarButton>();

                //Add buttons
                //here i read buttons text and action from an xml file.
                {
                xml::XMLDocument file;
                xml::XMLError res = file.LoadFile("files/buttons.xml");
                xml::XMLNode* root = file.FirstChild();
                xml::XMLNode* buttons_list = root->FirstChildElement("list");
                usi yy = 200;
                for (xml::XMLElement* e = buttons_list->FirstChildElement("button"); e != NULL; e = e->NextSiblingElement("button"))
                        {
                        buttons.push_back(BarButton(e->Attribute("text"), e->Attribute("action"), 96, yy));
                        yy += 32 + VERTICAL_SPACING;
                        }
                }

        //Main cycle
        while (window.isOpen())
                {
                //Window move ment
                //move the window outside of the screen if the mouse is not over it
                        {
                        int mx = sf::Mouse::getPosition().x;
                        int wx = window.getPosition().x;
                        if (mx >= wx - 1)
                                {
                                if (wx > WINDOW_MIN_X)
                                        {
                                        wx -= WINDOW_SPEED;
                                        if (wx < WINDOW_MIN_X)
                                                {
                                                wx = WINDOW_MIN_X;
                                                }
                                        }
                                }
                        else if (wx < Screen::get_width())
                                {
                                wx += WINDOW_SPEED;
                                if (wx > Screen::get_width())
                                        {
                                        wx = Screen::get_width();
                                        }
                                }
                        window.setPosition(sf::Vector2i(wx, 0));
                        }

                //EVENTS CHECKING
                sf::Event event;
                while (window.pollEvent(event))
                        {
                        // "close requested" event: we close the window
                        sf::Vector2f mouse_pos = window.mapPixelToCoords(sf::Mouse::getPosition(window));
                        if (event.type == sf::Event::Closed)
                                window.close();
                        else if (event.type == sf::Event::MouseMoved)
                                {
                                for (BarButton btn : buttons)
                                        {
                                        btn.mouse_moved(mouse_pos);
                                        }
                                }
                        else if (event.type == sf::Event::MouseButtonPressed)
                                {
                                for (BarButton btn : buttons)
                                        {
                                        btn.mouse_pressed(mouse_pos);
                                        }
                                }
                        else if (event.type == sf::Event::MouseButtonReleased)
                                {
                                for (BarButton btn : buttons)
                                        {
                                        btn.mouse_released(mouse_pos);
                                        }
                                }
                        }

                //STEP
                ps.step();
                for (size_t i = 0; i<buttons.size(); i++)
                        {
                        buttons[i].step();
                        }
                clock.step();

                //DRAW
                window.clear(sf::Color::Transparent);
                window.draw(bg_sprite);


                window.draw(ps);
                window.draw(clock);
                for (BarButton btn : buttons)
                        {
                        window.draw(btn);
                        }
                window.display();
                }
        }
 

In the main cycle i used the same order used by GM: 1st actions, 2nd step adjustments, 3rd draw.


now the button.h
class BarButton : public sf::Drawable
{
private:
        sf::Texture texture;
        std::vector<sf::IntRect> anim;
        sf::Sprite sprite;
        sf::Font font;
        sf::Text text;
        usi current;
        int changing;
        std::string action;

        virtual void draw(sf::RenderTarget& target, sf::RenderStates states) const;

public:
        BarButton(std::string text, std::string action, double x, double y);
        ~BarButton();

        void mouse_moved(sf::Vector2f mouse_pos);
        void mouse_pressed(sf::Vector2f mouse_pos);
        void mouse_released(sf::Vector2f mouse_pos);

        void step();
};
 


and the button.cc
BarButton::BarButton(std::string str, std::string action, double x, double y)
        {
        this->action = action;

        if (not texture.loadFromFile("textures/t_button.png"))
                {/*handle error*/
                }
        texture.setSmooth(true);

        if (!font.loadFromFile("fonts/times.ttf"))
                {/*handle herror*/
                }
        //SPRITES
        current = 0;
        changing = 0;

        sprite = sf::Sprite();
        sprite.setTexture(texture);
        sprite.setTextureRect(sf::IntRect(0, 0, 142, 48));
        sprite.setOrigin(142 / 2, 48 / 2);
        sprite.setPosition(x, y);
        sprite.setColor(sf::Color(000, 240, 255, 255));

        int xx = 0;
        anim = std::vector<sf::IntRect>();
        for (usi i = 0; i < 16; i++)
                {
                //std::cout << xx << std::endl;
                anim.push_back(sf::IntRect(xx, 0, 142, 48));
                xx += 142;
                }

        //TEXTS
        text.setFont(font);
        text.setColor(sf::Color(000, 0, 50, 255));
        text.setCharacterSize(12);
        text.setString(str);
        text.setOrigin(58, 7);
        text.setPosition(x, y);
        }


BarButton::~BarButton()
        {}

void BarButton::mouse_moved(sf::Vector2f mouse_pos)
        {
        if (sprite.getGlobalBounds().contains(mouse_pos))
                {
                if (current < (anim.size() - 1))
                        {
                        changing = +1;
                        }
                /*else
                        {
                        changing = 0;
                        }*/

                }
        else
                {
                if (current > 0)
                        {
                        changing = -1;
                        }
                /*else
                        {
                        changing = 0;
                        }*/

                }
        }

void BarButton::mouse_pressed(sf::Vector2f mouse_pos)
        {}

void BarButton::mouse_released(sf::Vector2f mouse_pos)
        {
        if (sprite.getGlobalBounds().contains(mouse_pos))
                {
                CA2W ca2w(action.c_str());
                //std::cout << "opening " << text.getString().toAnsiString() << std::endl;
                ShellExecute(null, L"open", ca2w, null, null, SW_SHOW);
                }
        }

void BarButton::step()
        {
        if (changing)
                {
                if (changing == 1)
                        {
                        if (current == anim.size() - 1)
                                {
                                changing = 0;
                                }
                        else
                                {
                                current++;
                                sprite.setPosition(sprite.getPosition().x - 0.75, sprite.getPosition().y);
                                text.setPosition(sprite.getPosition());
                                }
                        }
                else if (changing == -1)
                        {
                        if (current == 0)
                                {
                                changing = 0;
                                }
                        else
                                {
                                current--;
                                sprite.setPosition(sprite.getPosition().x + 0.75, sprite.getPosition().y);
                                text.setPosition(sprite.getPosition());
                                }
                        }
                }
        sprite.setTextureRect(anim[current]);
        }

void BarButton::draw(sf::RenderTarget& target, sf::RenderStates states) const
        {
        target.draw(sprite);
        target.draw(text);
        }
 
What's your OS? Graphics card? - Windows 10, AMD Radeon HD 7800
Which version of SFML are you using? lastest stable version
Are you showing all the relevant source code? particles and clock alone appear not to be an issue, whereas each button kills the cpu. Even though even without buttons cpu is slightly higher than expected and ram is still double as GM.
Have you ran the debugger? Directly from the profiler, 75% of cpu time is spent in BarButton::BarButton

Thanks,
Barnack

EDIT:
Apparently it's not the amount of textures which is causing the excessive ram usage, since even without buttons (which were guilty of reloading the same texture for each button), the ram is still at 46-47MB

Also i wonder why when testing within visual studio the application is laggy as hell, while when running the compiled on it works just fine...

EDIT EDIT:
i've also noticed a strange behavior;
Let's call this cycle "conventional"
for (size_t i = 0; i<buttons.size(); i++)
{btn = buttons[i]; ...}
 
and this one "foreach"
for (BarButton btn : buttons)
 

The btn.mouse_moved and btn.step only work when called with the "conventional" cycle (aren't called at all with the foreach cycle), whereas the btn.mouse_released and the btn.draw functions only work when called with the foreach cycle. That's really strange and makes me think i've coded something weird i don't see in button.cpp... O.o

Pages: 1 2 3 [4]