| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 2 years, 2 months |
| seen | May 13 at 13:14 | |
| stats | profile views | 217 |
|
Mar 21 |
comment |
Graphics module: Am I going the right way? [cont.] SFML: Indeed, I just discovered this library and I like it a lot more. | Bottom line: What I've shown here is only the core (loading, and rendering). Other details I considered unimportant to show. Also, I won't start implementing any features (rotation, skewing, scaling) unless I later find I need them. It'll be easy to do that anyway. |
|
Mar 21 |
comment |
Graphics module: Am I going the right way? Interface: Yes, it is an interface. It's the API kind of interface, not the virtual class type of interface. Void-pointer: Already sorted out. See my comments on jv42's answer. | Image copying: You make that assumption based on what? | Manipulation: A lot of details of the classes I haven't yet implemented or I considered only a distraction to the question. Also, you seem to be asking be for things like image rotation, getting the name of the font, etc. I'll implement those when and if the need arises, not now. [contd.] |
|
Mar 21 |
awarded | Commentator |
|
Mar 21 |
comment |
Graphics module: Am I going the right way? Load: No, it should be an Image class' job to load itself, the same way it's std::ifstream's job to load itself. This is not the place to do mem management: it will be done in a separate ResourceManager class. | Strings: It's not hard converting std::string to char*, so that's not the reason. the reason is simply that std::string would provide no advantage. |
|
Mar 20 |
comment |
Graphics module: Am I going the right way? After some of the comments I decided that I will define a private struct FontData and have a std::shared_ptr<FontData> as a private member instead of the void*. This means I can avoid forward declaration too, which means there's no mention of the library in the header file. :) |
|
Mar 20 |
comment |
Graphics module: Am I going the right way? Is that like an acknowledgement that the design isn't so bad or more like "you're too dumb to be bothered with"? :)) |
|
Mar 20 |
comment |
Graphics module: Am I going the right way? Other components [contd.]: GR initializes only the video component of SDL (because that's the one it uses). Other classes will initialize other components that they may need. |
|
Mar 20 |
comment |
Graphics module: Am I going the right way? Your point would be perfectly valid, but I'm not going to have more than one thread. This is a simple 2D game. |
|
Mar 20 |
comment |
Graphics module: Am I going the right way? Other components: I would initialize them separately, in the components that need those parts. | Initialization: The main engine (GameManager, usually) shouldn't care about details such as what library I'm using. In my current setup I don't have to worry about initialization one bit, everything happens automatically (and is ensured to happen exactly when I need it to happen, not later, not sooner). | Header: Yes, there's no real technical advantage. I do find the code to be neater when the underlying library isn't exposed to me in the class interface, however. |
|
Mar 20 |
comment |
Graphics module: Am I going the right way? Thanks for showing me std::shared_ptr, though. Thanks definitely going to come in handy. |
|
Mar 20 |
comment |
Graphics module: Am I going the right way? Void-pointer: I don't need it. It's a way for me to limit the number of files that include SDL.h (void* data_ is just an SDL_Surface* cast to void*). | Strings: Do I have any reason not to use them? I don't do any manipulations, I just need a string. I'm free to use std::string outside of these classes, if I so desire. | Singletons: Yes, more than one GR will break my code. GR initializes SDL. Having it a singleton I don't have to worry about when SDL gets initialized or exited. |
|
Mar 20 |
comment |
Graphics module: Am I going the right way? [cont.] Inheritance: I don't understand how I could use inheritance here. | Void-pointer: Why shouldn't it be used? I thought it's a good way to limit the number of files that have access to the 3rd-party library. data_ is just an SDL_Surface* cast to void*. Whenever I use it I cast it back to SDL_Surface*. | Blit [contd.]: Another way of thinking about this is, the image doesn't draw itself — the renderer draws it. The image simply exists. |
|
Mar 20 |
comment |
Graphics module: Am I going the right way? Singleton: Singletons aren't bad if they're used right. Basically, the renderer hasn't any state to speak of so singleton is okay here (it's more complex than that, though). | Free: Deallocation is handled in the destructor. The free() function is there for the same reason the ifstream::close() function exists. | Blit: I'm trying to separate the data from the mechanism that uses the data. | Sprites: This is just the graphics module. Sprites are to be handled in the higher levels of the engine, in a manner similar to what you described. [contd.] |
|
Mar 20 |
asked | Graphics module: Am I going the right way? |
|
Mar 19 |
awarded | Student |
|
Mar 19 |
asked | Animation file format |