Now to the ram "issues"

[barnack]

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

[eXpl0it3r]

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.

Do you have a system with only 100MB RAM?

[barnack]

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.

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 ). 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.

[jamesL]

did you compile everything in debug mode or release mode

[Gleade]

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.

[eXpl0it3r]

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.

But letting other people solve your imaginary memory problem is not considered being a lazy developer?

If you're so keen on premature optimization, you should learn how to optimize things on your own. There are profilers for timing and for memory, check them out and learn how to use them, those are very useful tools even for none premature optimization.

[barnack]

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?

[Laurent]

Don't just count the bytes used by textures. There's much more than that behind the scenes. And textures are stored in GPU RAM so you will probably not see them in the app's memory consumption anyway.

As far as I remember, an OpenGL context can take (depending on your graphics driver) a few tenths of MB by itself. It's easy to see the "minimum amount of memory required by SFML", independently of what your own program will use, by running a simple example that just polls events and clears the screen.

[barnack]

uhm so it's an usage implied by OpenGL, that's good to know, thanks for the clear answer!

[Laurent]

It's not 100% sure, and depends on each environment, so you'd better check what I suggested to have a clear answer

[FRex]

If you're worried you should profile to see where those allocations come from in your C++ program. You should also compare an empty GM and SFML application to see the 'base' investment of memory each takes.

But really you shouldn't be worried.

If you write normal code in C++ with SFML and never do something bad (x^n algorithms, storing too much data in RAM at once, etc.) that'd kill your program in any language on one of these metrics then you have nothing to worry about.

C++ is very low level by today standards between all of Lua, Python, C#, Java, HTML5, Flash, Haxe, etc. Even few years old cheap laptops can handle a well written program in any of the newer stuffs so don't waste your time optimizing for budget PCs from late 90s.

SFML is also not crazily optimized, just reasonably written with some performance considerations but all in plain and good style C++, it's very easy to read and change because of that.

You're also making a mistake if the only reason you picked C++ is (imaginary?) GM performance and memory issues instead of actual willingness to 'graduate' into a real multi-purpose heavy duty language like C++ and become a better programmer.

[barnack]

But really you shouldn't be worried.

Not worried, just questioning

You're also making a mistake if the only reason you picked C++ is (imaginary?) GM performance and memory issues instead of actual willingness to 'graduate' into a real multi-purpose heavy duty language like C++ and become a better programmer.

I didn't switch to C++ right now with SFML, i used C++ for quite a decent amount of stuff (despite what you'd think from the stupid error i did in my first post  ), just without any effort in making applications with some little graphics since i had GM to do that. But then i've met gm's limits regarding os interaction, multiple windows not being allowed, the sandboxing mess they did in Studio and other various stuff, and that's why i came here, to add fancy glowing rectangles inside a window to my C++ applications.

My efforts in understanding where does cpu and memory usage come from is to answer a simple question: "could i have done it better"?
The application i'm working on right now is a sidebar with an analog clock and customizable buttons. It's purpose is to autorun at startup and stay there until system's shout down; and you don't want such an application to use more resources than required. I want to minimize that application's impact on resources and battery life for laptops, up to making it totally irrelevant.

You may not think in these terms when you make an application which purpose is to stick the user focused in, so most of computer's resources will not be required somewhere else.
But when you make a background application, or something which purpose is to stay opened, you sould NEVER think in these terms.
Guess if Open Broadcaster Software wasn't made with resources usage in mind for example. Good luck with recording your games

[barnack]

If you're worried you should profile to see where those allocations come from in your C++ program. You should also compare an empty GM and SFML application to see the 'base' investment of memory each takes.

Yeah thanks for the suggestion;
there's definitely plenty of difference between empty state projects, GM requiring 25.9MB whereas SFML requiring 46.8MB. So it all depends on the behind the scenes as Laurent suggested

[FRex]

Oh yes, I also hate the current trend of not caring and basically saving money by 'outsourcing' your programmer wages out to users' CPU, RAM and electricity, especially when done by always-on premium apps made by multi million/billion companies (*cough* Slack *cough*) that should really know better.

Perhaps some more GUI-ish language + toolkit combo like C with GTK+, C++ with Qt, Free Pascal with Lazarus, etc. would be better for a more utility-like OS-integrated application. They come with better OS integration, tray support, lazy redrawing, software rendering, drag and drop, copy paste, native-ish GUI components, etc. out of the box.

In Task Manager my Pascal* program Botes uses 8 megs of RAM and no CPU at rest despite storing like a meg of text plus having a GUI window with a code editor and few controls open. I'd never write such a program in SFML though.

OBS actually uses Qt which is of course heavier than pure WinAPI GUI would be but it's still good and small enough memory and CPU wise so it's OK. Going for top optimization makes no sense a lot of the time. I just opened obs64.exe and it takes 100 megs, and of course for recording or streaming you're supposed to actually have a beefy machine because these programs aren't cheap on memory, CPU and network/disk so using Qt and taking 100 megs at rest is meaningless in comparison.

In 'normal' consumer device world (i.e. not programming on an integrated controller that has half a KB of RAM) you need to strike a healthy balance instead of going off one deep end and frustrating performance aware users or another and wasting your time chasing optimizations that won't affect anyone in practice.

* I think Game Maker is or was in Delphi (another Pascal that Free Pascal and Lazarus are largely compatible with) actually.

[Gleade]

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?

I think you should really look further into why Game Maker has "bad performance" and where. I'm not saying it isn't true; but my point being, a company who has a huge amount of resources going into this engine versus a hobby programmer new to C++. Not to say it's impossible, but you should really get a better understanding of:

• Where GM lacks performance and why.
• What you actually want to achieve.
• C++ and SFML (if this is the right library for your task).
• Profiling.

Also, regarding the texture pages; they remove a lot of "empty space" and compact the textures, pretty much a texture atlas. The point of the texture page is indeed to have 1 texture instead of many - for sprite batching.