Daunting Design Decisions
Contrary to the melodramatic title (I just wanted to alliterate), this thread is simply a request for advice on whether the engine* of my game using SFML should wrap SFML or not. At the moment it does, but it's such a thin wrapper that I'm beginning to question the value. Also, it's inconsistent, because sometimes I'm subclassing SFML objects (e.g. my drawtarget class which derives sf::RenderTarget), sometimes I'm wrapping them (e.g. my sprite class which manages a sf::Sprite object) and sometimes I'm converting between them (e.g. my rgba and vector classes which can convert to/from sf::Color and sf::Vector2 respectively). I originally did it so that I could keep game logic and SFML code separate but I'm starting to wonder whether it's worth it, especially seeing as how I'm writing so much code for converting to and from SFML stuff.
Should I stick to my guns or should I remove probably about 1.5 kLOC and just use SFML directly?
Code is here: https://github.com/ChrisSwinchatt/DemonGame
DemonGame is just a working title, obviously.
* before anyone comes in here with "make games not engines", I'm doing both at the same time, writing all the classes I need and separating them into "engine" and "game" namespaces as I go along.
Should I stick to my guns or should I remove probably about 1.5 kLOC and just use SFML directly?
Code is here: https://github.com/ChrisSwinchatt/DemonGame
DemonGame is just a working title, obviously.
* before anyone comes in here with "make games not engines", I'm doing both at the same time, writing all the classes I need and separating them into "engine" and "game" namespaces as I go along.
closed account (o1vk4iN6)
Well from the main.cpp file I can already see some naming issues:
|
|
Haha, yeah, I need to work on that. It was worse when I had a demon_game::engine::game class as well.
closed account (3qX21hU5)
I would say stick with it. Personally I find whenever I start going back and reworking my base framework I never actually get anything done. Because after I rework it I find something else I don't like then do it again and again ;p. So I tend to just stick with my original plan and keep on pushing through, the code might get a little sloppy but at least I have something to show for my efforts.
Though that could just be me.
Though that could just be me.
closed account (o1vk4iN6)
Yah you have too many namespaces I think, you only really need one, and that's to differentiate it from any other library that might also happen to use the same name for a class named something generic, like "Game" in this instance.
For example.
should suffice.
For example.
|
|
should suffice.
Last edited on
| Zereo wrote: |
|---|
| I find whenever I start going back and reworking my base framework I never actually get anything done. Because after I rework it I find something else I don't like then do it again and again |
That's exactly what I end up doing. I think it's good to refactor your code from time-to-time but I don't want to get trapped in that cycle of endless rewrites where you never actually implement anything new.
I am going to be reworking some stuff to put a resource managing class in.
@xerzi
In C++ namespaces were intended to be used like that but in C# they were extended to a way of structuring programs and libraries into distinct modules, and I like that model and apply it to C++ as well as C#. I did take out the sub-namespaces of the engine module so that there were no demon_game::engine::<audio/game/input/ui/utils/video> namespaces but I ended up putting it back (and took a lot of time.
Also I like to put little tongue-in-cheek jokes like that in on purpose. For example, there's an error message for not passing the right command-line arguments that says "--assets option not optional" (the --assets option tells the engine where the resource directory structure is).
Last edited on
New question.
At the moment, my sprite class stores an sf::Image (in system memory). When it's time to draw the sprite, the sf::Image is converted to an sf::Texture (in video memory) which is then loaded into an sf::Sprite for drawing. Is this too inefficient? I can't imagine copying the image into video memory every frame is very efficient. Should I just store all my sprites in video memory (using sf::Texture)?
At the moment, my sprite class stores an sf::Image (in system memory). When it's time to draw the sprite, the sf::Image is converted to an sf::Texture (in video memory) which is then loaded into an sf::Sprite for drawing. Is this too inefficient? I can't imagine copying the image into video memory every frame is very efficient. Should I just store all my sprites in video memory (using sf::Texture)?
| When it's time to draw the sprite, the sf::Image is converted to an sf::Texture (in video memory) which is then loaded into an sf::Sprite for drawing. Is this too inefficient? |
That is extremely inefficient, yes.
Really, you shouldn't need sf::Image at all unless you are doing manual pixel manipulation.
closed account (3qX21hU5)
Creating a sf::Texture is a very expensive operation since it is what is called heavyweight a resource (Whereas a sf::Sprite will be a lightweight resource).
Ideally you will want to load all the textures you will be using for your current state at the beginning of that state and keep them around until the end of that state (Or when you know for sure that they won't be used again and need the memory) when you will free them.
So for example lets say we are loading the Level 1 state of the game. We would load up all the textures, font's, sound effects, shaders and what have you at the beginning of that state (If it is taking awhile you can add in a loading screen) and keep them in memory until level 1 ends.
Ideally you will want to load all the textures you will be using for your current state at the beginning of that state and keep them around until the end of that state (Or when you know for sure that they won't be used again and need the memory) when you will free them.
So for example lets say we are loading the Level 1 state of the game. We would load up all the textures, font's, sound effects, shaders and what have you at the beginning of that state (If it is taking awhile you can add in a loading screen) and keep them in memory until level 1 ends.
Last edited on
Okay, I'll go back to just using sf::Texture and loading it when the state begins. I was using sf::Image to save on video memory but now I realise that if I'm only loading those textures that are being rendered, they have to be in video memory.
I'm going to cache sf::Images though because sf::Texture::loadFromFile is equivalent to sf::Image::loadFromFile followed by sf::Texture::loadFromImage, so caching the textures in system memory as sf::Images will prevent unnecessary disk access which has to be way slower than copying an image from system to video memory.
I'm going to cache sf::Images though because sf::Texture::loadFromFile is equivalent to sf::Image::loadFromFile followed by sf::Texture::loadFromImage, so caching the textures in system memory as sf::Images will prevent unnecessary disk access which has to be way slower than copying an image from system to video memory.
Topic archived. No new replies allowed.