RenderWindow bounds?!

[bitano]

Hi there!

Not too long ago i made a game which progressed pretty well, but for some reason crashed after approximately 30 minutes (sometimes 40). It seemed like one of my functions / pointers was leaking somewhere but i couldn't find any cause. As far as i could tell, i made sure to clear up any unused pointers.

I started considering that the leak was caused by one of the SFML functions i might have misinterpreted...I tried to troubleshoot some but in the end let it rest...

-----

Now i'm starting on a new game and this still bugs (pun...lol) me. What i'm thinking at the moment is that the most used function while the game is running is the one drawing tiles to the RenderWindow.

I realized that i never found out whether i should set the outer bounds of a RenderWindow.

Should i define the outer bounds of the RenderWindow somewhere?
What are the size limits of RenderWindow (considering i'd want to use a huge tilemap) ?
What if a function ended up drawing something outside the boundaries of RenderWindow (for example starting from negative X,Y coords)?

I hope i was clear enough on this and that someone is able / willing to help me.

Thanks!

[G.]

The render window has no bounds. However, the sf::View (there's always one) has bounds, and it can be of any size. (same size as the window if you use the default view)
If you draw something out of what the render window shows, it stills takes (/wastes) time. Thus you should avoid drawing things that are outside the screen.

But drawing things outside the window isn't related to memory leaks.

[zsbzsb]

There is no "window bounds"... that isn't how it works. Of course there is a max value and that is limited to the maximum value of floats. But there is no limit to how much you can draw or how big your map is. However you may want to limit what you do draw however because of performance reasons.

[Nexus]

Not too long ago i made a game which progressed pretty well, but for some reason crashed after approximately 30 minutes (sometimes 40). It seemed like one of my functions / pointers was leaking somewhere but i couldn't find any cause. As far as i could tell, i made sure to clear up any unused pointers.

What you describe is undefined behavior, which can have many causes. Most common are:

• Dereferencing of invalid pointers/references/iterators
• Array out-of-bound access
• Wrong use of delete or delete[] operators
• Linking of incompatible libraries (compiled with different compiler versions/settings)

The occurrence of such bugs may be a hint that you use badly abstracted code. Modern C++ features (smart pointers, STL containers) as well as compiler debug support (assertions, checked iterators) often mitigate such issues -- make sure you use them. For example, using new and delete in your program is usually a bad idea.

I started considering that the leak was caused by one of the SFML functions i might have misinterpreted...I tried to troubleshoot some but in the end let it rest... [...] What i'm thinking at the moment is that the most used function while the game is running is the one drawing tiles to the RenderWindow.

SFML shouldn't cause such issues. And the number of times you call a function is no reliable bug indicator -- it is enough to call a function with UB once, and the error may manifest only half an hour later. That's why these things are terribly tedious to debug, and you'd better avoid them in the first place by writing good code. Some time ago, I assembled a list of C++ tips that may help you in this regard.

[bitano]

Excellent advice! Thanks.

Yes i am aware of drawing only the tiles / sprites that are actually visible in the view, but thanks for that :-).
My code could've been cleaner and was based on what i knew from older projects (actually did use new and delete, etc).

This too is the reason why i want to start all over and make the code as clean as possible from the get go. That's also why i raised this question. Not that i don't trust the SFML library (that would be silly), but that i might've made an incorrect assumption

Thanks again! I will certainly check out the provided links. Feel free to pass some other related links if you're aware of any :-)

[bitano]

Kind of hijacking my own thread here, but it felt silly to make a new post for such a small (and somewhat related) question:

For readability in the code i'd still like to use function-local pointers.

So instead of having to address this->that->stuffz->thingies[4]->id each time i want to access a property, i'd instead use thingy->id

Is it still the proper way to define a pointer like:

Code: [Select]

ThingyClass *thingy = &this->that->stuffz->thingies[4];

And am i correct in assuming i don't have to clean up this pointer at function end as it's only a reference and i have the actual contents stored elsewhere (in a vector array) anyways?

Thanks!

[Nexus]

And am i correct in assuming i don't have to clean up this pointer at function end as it's only a reference and i have the actual contents stored elsewhere (in a vector array) anyways?

Yes. In general, it's very simple: for every memory allocation, you need a corresponding deallocation.

The best is still if you use RAII and avoid new/delete completely. STL containers, smart pointers and other abstractions can do most of the work for you.

[bitano]

And am i correct in assuming i don't have to clean up this pointer at function end as it's only a reference and i have the actual contents stored elsewhere (in a vector array) anyways?

Yes. In general, it's very simple: for every memory allocation, you need a corresponding deallocation.

The best is still if you use RAII and avoid new/delete completely. STL containers, smart pointers and other abstractions can do most of the work for you.

I'm not quite following you. In my example i'm not allocating memory, am i? I'm just defining a function-local reference to data stored in another structure...Or so i thought.

Or are you referring to the vector array? I was under the impression those also get cleaned up in the destructor.
I'm not dismissing the use of RAII - i actually like it a lot. I'm not seeing its application though with regards to this specific question

[Nexus]

I'm not quite following you. In my example i'm not allocating memory, am i? I'm just defining a function-local reference to data stored in another structure...Or so i thought.

Exactly... That's why my answer to the question "am I correct in assuming..." was "yes"

To clarify, std::vector cleans up automatically (this is RAII), and you don't have to worry about pointers to its elements. Just keep them valid as long as you use them, but that's a different topic.

[bitano]

I'm not quite following you. In my example i'm not allocating memory, am i? I'm just defining a function-local reference to data stored in another structure...Or so i thought.

Exactly... That's why my answer to the question "am I correct in assuming..." was "yes"

To clarify, std::vector cleans up automatically (this is RAII), and you don't have to worry about pointers to its elements. Just keep them valid as long as you use them, but that's a different topic.

Ah right. Thanks for the clarification and your patience. It's really appreciated