I want a better way of loading images. Currently I am using SDL2 with SDL_images. I would like to use it in a class and load it to my game. Currently mine is using pointers but I'd like to change that. I can supply the code I have so far if thats needed and maybe someone can explain a way of changing from pointers to something like "background.set_image("filehere");" "background.draw();"

What is your problem wit pointers? I think there is some misunderstanding about pointers. When you load some data to memory, you store it on the heap. You can't avoid using pointers to get that data.

What is your problem wit pointers? I think there is some misunderstanding about pointers. When you load some data to memory, you store it on the heap. You can't avoid using pointers to get that data.

Thing is, I havent learnt how to use pointers and I am use to sdl1 than sdl2 so I had to search up a tutorial in migrating over but the tutorial used pointers so I dont really understand it well so I am having problems doing simple things as I dont really understand it well enough.

What is your problem wit pointers? I think there is some misunderstanding about pointers. When you load some data to memory, you store it on the heap. You can't avoid using pointers to get that data.

Thing is, I havent learnt how to use pointers and I am use to sdl1 than sdl2 so I had to search up a tutorial in migrating over but the tutorial used pointers so I dont really understand it well so I am having problems doing simple things as I dont really understand it well enough.

I strongly recommend to learn pointers first. It is one of the basic thing about C/C++ programming you can't just bypass and start to learn SDL. Have a good basic knowledge of the programming language first, then start to learn libraries/frameworks.

What is your problem wit pointers? I think there is some misunderstanding about pointers. When you load some data to memory, you store it on the heap. You can't avoid using pointers to get that data.

Thing is, I havent learnt how to use pointers and I am use to sdl1 than sdl2 so I had to search up a tutorial in migrating over but the tutorial used pointers so I dont really understand it well so I am having problems doing simple things as I dont really understand it well enough.

I strongly recommend to learn pointers first. It is one of the basic thing about C/C++ programming you can't just bypass and start to learn SDL. Have a good basic knowledge of the programming language first, then start to learn libraries/frameworks.

So basically, for loading images, pointers are pretty much great? I guess I can carry on using them then :P

You might also want to look into the newer pointer "versions", which aim to make development easier and less bug-prone. These pointer types are called "smart pointers".

You can also track the dynamic memory allocation and release by overriding the new and delete operator but this is quite an advanced topic. First understand how pointers work, then learn smart pointers and after that look up for C++ memory leak detection.

If I am right, Visual Studio also can detect memory leaks in c++ applications so it might be an unnecessary work, but for fun and self improvement it is perfect.

You might also want to look into the newer pointer "versions", which aim to make development easier and less bug-prone. These pointer types are called "smart pointers".

You can also track the dynamic memory allocation and release by overriding the new and delete operator but this is quite an advanced topic. First understand how pointers work, then learn smart pointers and after that look up for C++ memory leak detection.

If I am right, Visual Studio also can detect memory leaks in c++ applications so it might be an unnecessary work, but for fun and self improvement it is perfect.

In my current code, I use the "delete player" in order to stop some memory leaks. I use this on my images.

The ways you would go about not using a pointer still involve using a pointer, so you must still become comfortable with the concept in order to go about abstracting away the detail (a fancy term for hiding the implementation details). You cannot (sanely) change the underlying implementation to not use pointers, but you certainly can hide the fact that it does use them. The most common method of going about doing what you want is by creating a "wrapper" class that maintains the SDL_Surface pointer and operates on it internally (the fancy term for this is, I believe, "encapsulation"), but exposes a public API for doing the things it needs to do -- 99% of the time without ever needing to deal with the pointer. Doing so also has the side benefits of being able to conveniently do other things related to the task of SDL_image (such as conversion of image surfaces). Most importantly of all, it allows you to do the Right Thing (TM) and perform the appropriate checks for error states that can occur.

For example, I have done just that in a class called Image (admittedly, not a great name for it!), that is really nothing more than a glorified SDL_Surface pointer with many convenience helper methods for working with the struct in a more pleasant manner, such as disk I/O, color keying, creation, etc. I would gladly share the source with you, but I'm afraid it would further compromise / post-pone learning about pointers, but if you insist... I suppose I would. It really does become obvious / trivial once you understand pointers a bit better.

In my current code, I use the "delete player" in order to stop some memory leaks. I use this on my images.

You are well upon your way to understanding, then! :-) Manually managing memory (pointers), in practice, often times boils down to: a) remembering to free it at the appropriate time; b) always ensure the pointer is valid (not NULL) before usage -- failure can include, but is not limited to, running out of memory, incorrect usage of the API and so forth. Easier said than done, sometimes. As for the first case (remembering to free) -- this is why **after** you have a solid understanding of pointers, people will often suggest considering the use of smart pointers when applicable; these help to eliminate the most common problem with pointers, and that is ... forgetting to free 'em! They aren't perfect, but no single programming tool ever is :-) (Note that "raw pointers" simply refer to the use of non-smart pointers). Whether you end up using them is purely preferential, in my opinion (that's probably going to be a very controversial opinion there...)

P.S. Although pointers may appear scary at first, I promise you that once that ah-ha! moment comes, you'll realize how beautifully simple they are :-) For me, I came to find out that it was just the syntax of the pointer that was "scary" (more like confusing in my case).

My ah-ha! moment came when I realized that everything in a program is represented by a sequence of memory offsets, filled with values that you've set (sometimes indirectly), executed in the fashion you've set forth by jumping to and fro the memory offsets. Pointers do not hide this "secret" implementation detail, and let you manipulate these values stored in the memory offsets directly, whereas other language constructs do the same but through hiding that detail, to help facilitate ease of use. I apologize if mentioning this was a waste of your time, I was just trying to help facilitate your ah-ha! moment in the way that it helped me.

(Sorry, that must be like the longest P.S. ever written lol)

The ways you would go about not using a pointer still involve using a pointer, so you must still become comfortable with the concept in order to go about abstracting away the detail (a fancy term for hiding the implementation details). You cannot (sanely) change the underlying implementation to not use pointers, but you certainly can hide the fact that it does use them. The most common method of going about doing what you want is by creating a "wrapper" class that maintains the SDL_Surface pointer and operates on it internally (the fancy term for this is, I believe, "encapsulation"), but exposes a public API for doing the things it needs to do -- 99% of the time without ever needing to deal with the pointer. Doing so also has the side benefits of being able to conveniently do other things related to the task of SDL_image (such as conversion of image surfaces). Most importantly of all, it allows you to do the Right Thing (TM) and perform the appropriate checks for error states that can occur.

For example, I have done just that in a class called Image (admittedly, not a great name for it!), that is really nothing more than a glorified SDL_Surface pointer with many convenience helper methods for working with the struct in a more pleasant manner, such as disk I/O, color keying, creation, etc. I would gladly share the source with you, but I'm afraid it would further compromise / post-pone learning about pointers, but if you insist... I suppose I would. It really does become obvious / trivial once you understand pointers a bit better.

In my current code, I use the "delete player" in order to stop some memory leaks. I use this on my images.

You are well upon your way to understanding, then! :-) Manually managing memory (pointers), in practice, often times boils down to: a) remembering to free it at the appropriate time; b) always ensure the pointer is valid (not NULL) before usage -- failure can include, but is not limited to, running out of memory, incorrect usage of the API and so forth. Easier said than done, sometimes. As for the first case (remembering to free) -- this is why **after** you have a solid understanding of pointers, people will often suggest considering the use of smart pointers when applicable; these help to eliminate the most common problem with pointers, and that is ... forgetting to free 'em! They aren't perfect, but no single programming tool ever is :-) (Note that "raw pointers" simply refer to the use of non-smart pointers). Whether you end up using them is purely preferential, in my opinion (that's probably going to be a very controversial opinion there...)

P.S. Although pointers may appear scary at first, I promise you that once that ah-ha! moment comes, you'll realize how beautifully simple they are :-) For me, I came to find out that it was just the syntax of the pointer that was "scary" (more like confusing in my case).

My ah-ha! moment came when I realized that everything in a program is represented by a sequence of memory offsets, filled with values that you've set (sometimes indirectly), executed in the fashion you've set forth by jumping to and fro the memory offsets. Pointers do not hide this "secret" implementation detail, and let you manipulate these values stored in the memory offsets directly, whereas other language constructs do the same but through hiding that detail, to help facilitate ease of use. I apologize if mentioning this was a waste of your time, I was just trying to help facilitate your ah-ha! moment in the way that it helped me.

(Sorry, that must be like the longest P.S. ever written lol)

That was a very interesting read. Thank you for this post :)