Hello guys. I am knowledgeable in C++ and am using Visual Studio right now, but I’m fairly new to SDl and I’m coming over from GameMaker Studio, so a lot of my logic when it comes to organization is based on how I organized my projects in GameMaker. However, because of this, I’ve run into some issues, and I was hoping you guys could give me some tricks and tips on organization.
As of now, I have a texture class and a seperate “object” class that holds stuff like object coordinates and functions to move the objects around and such. Y’know the drill. However, when it comes to textures and objects, I’m finding it difficult to make them work together. A lot of the functions I use in my object class I’d like to use in my Texture class, like moving an object across the speed at a given pace. So, my thought was to reconstruct the texture class to make it a derived class of the object class so all those functions carry over and I don’t have to rewrite them. However, this obviously prevents me from using instances of my texture class in my object instances.
I really want to try to learn SDL by myself as much as I can, but I really am having trouble finding online resources that address these specific issues, and I was hoping you guys could give me some tips on how to resolve this.
What you are saying makes complete sense, and actually that’s why I created the texture class so I could just call on the texture instance and a member. Also yes I am using C++ sorry I should’ve mentioned that. Anyways though, since I am able to accomplish everything you mentioned through the class creation, are there any other reasons why I should not use a texture class? Honestly, GameMaker kinda took care of everything behind the scenes, so while I personally don’t see an issue with creating a separate texture class (hence, why I did it), maybe there’s something in the background with classes that may slow down my program or something that I just don’t know of. Thank you for your response.
If you want you could create a Texture class that is essentially just a wrapper around SDL_Texture but I don’t think you should add much more to it than that. Let a Texture represent a texture (without position, speed, etc). Instead create other classes that contains/uses the textures. That way you keep things better separated and organized.
When I have written games in SDL 1.2 (which didn’t have SDL_Texture so used SDL_Surface instead) I have created a Surface/Image class which was essentially just a wrapper around SDL_Surface. Then I created a Sprite class to represent an image on the screen. It contained a “surface”, a position and a z-order (plus some additional stuff for clipping because I might not want to display the whole surface). The Sprite class could then essentially be used in any part of the game where I want to display an image but this depends very much on the game and the situation. In one game I have a GameObject class that contains a Sprite object but it could also be used in a menu that wants to display an image. Note that the logical position of the game objects don’t necessarily have to be exactly the same as the position of the sprites.
I don’t claim the above is necessarily the “best” way to do it. My main point is just that you should not try to cram everything into one giant class that does everything. Think about what the class is actually representing and prefer composition over inheritance.
This seems perfect because that’s exactly what I wanted to accomplish. Thank you for explaining how you approached it. However, one question I had was why not just make the sprite class with the coordinates and such instead of making two separate classes?
Oh wait now I think I understand after giving it some thought. It’s so you can make functions exclusive to a sprite but not to an object right? Like a tile sprite option you may not want to have in a class? Or am I overthinking it lol.
The Sprite class had coordinates. It’s just that they don’t necessarily have to be the same as that of the game object.
Now that I think about it, I think a big reason why I used a Sprite class was because SDL 1.2 didn’t have SDL_Texture (and “hardware surfaces” wasn’t implemented on Linux) so I was doing “software rendering” and in order to get satisfactory performance I had to implement a “dirty rectangle” system where I only updated the parts of the screen that had changed. The Sprite class helped with that because it contained a “dirty” flag that kept track of whether the Sprite had been updated and it also had an “old rect” that was the area that the sprite had covered previously. That way I could essentially just loop through all the active Sprites each frame and collect the dirty rects and update those instead of the whole screen.
When using SDL_Texture I don’t think you need to care about “dirty rectangles”. You probably just render everything every frame and the performance will probably be good enough. That means there might be less reasons to use a Sprite class.
It’s part of the reason. Inheritance is said to represent an “is-a” relationship, while composition represents a “has-a” relationship. For me, a game object is not a sprite, it has a sprite.
Keeping them separate was less confusing because the position of the game objects was not necessarily the same as the positions of the images on the screen. In one game, changing the y-coordinate of a game object would affect both the y-coordinate and the z-index of the sprite. The game object also had an “altitude” that would only affect the sprite’s y-coordinate but not the z-index. You were not supposed to modify the sprite directly from outside the class because it would make it out of sync with the game object.
And it wasn’t only “game objects” that could have sprites. For me a “game object” was a very in-game specific entity that contained a lot of other information. I didn’t necessarily want to have to create a “game object” every time I wanted to just display an image on the screen.
If you look at SFML (a C++ library with many of the same capabilities as SDL) it also contains separate Texture and Sprite classes, so it’s not just me…