I’m developing a GUI application in SDL2. This is my first time using it but so far I’m really loving everything about it. I am however running into some weird problems when trying to render textures. Luckily I’ve found a fix but I hope to use SDL on future projects and since I don’t know why the problem is occurring or why my fix solves it I fear I might have a fundamental misunderstanding that will continue to cause problems in my SDL code.
Rather than making this post a million lines long I figure it might be cleaner to just post a link to where I’ve detailed the whole thing on Stack Overflow.
I checked around the site and read the FAQ and nothing seems to suggest that this is frowned upon, but if I am mistaken I can take out the link and replace it with an edited version of my post.
Hi Haxses!
I took the time to read the issue you described on SO.
The lazy foo tut is about using a texture as a render target, like here:
But I don’t see SDL_SetRenderTarget anywhere.
Cluttering huge parts of source code isn’t actually very helpful to ask a question in general.
I can’t grep or compile.
Even so I don’t really embrace OOP or hungarian notation I would look into your code if you set up a git repo, preferable on github. Just a fun Question did you do the tutorials 1-42? =)
Sorry if I get superlame now, but if a Texture is declared, it’s declared as a pointer: SDL_Texture *my_texture;
just like surfaces, well - C and C++ are a lot about Address-Pointers. If you allocate memory you are responsible to give it back before you exit.
The correct way to free a texture is: SDL_DestroyTexture(my_texture);
Awesome, thanks for taking the time to help me out!
Good to know about the usefulness of my source code blocks. It did seem like I was posting a bit too much pure code, but I also wanted to at least show enough to cover what I had mentioned in my description. Unfortunately some of the code that is required for a successful compile isn’t mine to distribute, which is why I couldn’t just put the whole project up on Github.
However, like I mentioned above I really have been enjoying SDL and have even started making a small game using SDL just for fun. I have a pretty similar structure in that and I recently ran into the same problem there. Once I get home I can push that up to a repository so it can be compiled and ran.
As for the Texture declaration part, first off, don’t worry about getting superlame, these are all things I really need to learn, especially if I’m doing it wrong. However I’m not quite grasping the context in which this was a response too.
If your talking about my comments on declaring Texture as a pointer or not, like you said SDL_Texture needs to be declared as a pointer, but my Texture class can be declared and handled directly as an object with the pointer abstracted out:
Texture my_texture
VS
Texture* my_texture
From all of my experience the top version is a totally valid declaration.
If you were just commenting on how I was handling the freeing of SDL_Textures then that’s totally fair and maybe something I need to look into. I will note that my Texture class frees it’s texture in the destructor (which wasn’t in my code block, really proves your point about those) so I figure I’m pretty safe as long as all of my textures are an instance of that class. That said this sort of manual memory management isn’t something I’m real experienced in yet so it’s very possible I’m missing some important steps.
I’ll set up that Github repository tonight, thanks again!
Alright, I got the project pushed up. First off I’m going to apologize in advance, this project is basically my SDL scratch paper to just try things. It’s not very clean and usually wouldn’t be anything I’d want to show someone but it’s the only instance of this problem that I can post for anyone to download.
It’s a VS project if you’re on windows and if you cd into prog2 you can run “bash make.sh” (not a real make file, just a g++ call) and it should compile to a Linux machine.
Like I mentioned it’s inconsistent in how it breaks, so you may have to run it a few times to get a visual result. When it runs you will have to click on the top button to get to the next screen. There it should show a dialogue visual with some text typing out. It’s at this point that you should see a very obvious distorted text texture (which is supposed to be a texture loaded from a PNG). If you don’t see it you will have to close and try again.
Alright =) Just started my work. Gonna look into it later. Don’t worry about the coding style atm. People will never stop moaning about other peoples style, no matter how clean the code is. If it’s not that, you use the wrong OS/Compiler/IDE/Editor or you just bought your car in the wrong color.
I am on Linux, but I can build a lot, even DOS stuff. Need to fix my github code for Windows/Mac whatever but as long nobody complains I sit that out.
Oh, and I wasn’t really referring to something specific with my pointer stuff. I just tried to have an entry point for the conversation. Not here to blame, I like the challenge and know the feeling of struggling with certain topics.
Your Texture class need a copy constructor and copy assignment operator (and a move constructor and a move assignment operator if you use c++11). Take a look at rule of three (or rule of five in c++11): http://en.cppreference.com/w/cpp/language/rule_of_three
Haha isn’t that the truth, people can have very strong opinions about stylistic ideas.
I gotcha with the pointer conversion. I certainly didn’t take it as blame, but I’m always down for some constructive criticism so I figured I would just confirm if there was a specific context I should be applying it to. That was something that I found interesting when I started SDL. When I tried to declare an SDL_Texture directly I got a bunch of “incomplete type” errors. I hadn’t encountered that behaviour from a C struct before.
Edit* Whoops, this was supposed to be a response to @es5804.
Fascinating, i hadn’t heard of this before. So the compiler will call the copy constructor and the copy assignment operator without them explicitly being used? Perhaps that’s my problem, it also explains why some of my object attributes seem to be preserved and some of them do not.
I am a little confused about why the compiler would need to call for a copy anywhere in my code though. In all of my problem cases I’m creating an object from scratch:
myObject = Object();
calling a load function:
myObject.loadFromFile(“file/path”);
and calling a render function:
muObject.render();
that mostly just passes it’s SDL_Texture atribute to SDL_RenderCopy.
None of these seem like they would induce any copying of my object. Maybe it has to do with the SDL_RenderCopy function, it does have copy in the name after all. But from my (extremely limited) understanding of that function it should only be copying the SDL_Texture from vram to the frame buffer, which I don’t believe would incur a copy of my custom object.
I guess the next step is to go create my two missing functions and see how it affects my output. This is also just a generally good thing to know, I’ll make sure to follow the rule of 3 from now on. Thanks!
So i noticed in your link the example has a ‘&’ in the copy assignment operator. I did some googleing to refresh myself on the syntax of operator overloading and that doesn’t seem to just be the inherent syntax of overloading operators. So in that case does this mean we are overloading = to act on assigning pointers, Object* rather than Object? In that case what about assigning objects directly, should I have a version with the & and without it?
This simple line of code does more thing than what you think. It first create a temporary object, then copy it to your variable. Note that a this point both the temporary object and your variable point to the same SDL_Texture*. Finally the temporary object is deleted and it frees its SDL_Texture*. Now your variable has a pointer to a freed texture.
Just put a printf in your copy constructor/assignment operator to see how many time they are called.