1,711 reputation
1029
bio website
location
age
visits member for 3 years, 1 month
seen Apr 10 at 23:08

Apr
17
comment A few questions about entity states
No. 1: Interesting solution, I'll consider it. :) | No. 2: You got me wrong, I never said the sprite should notify the entity. I'll edit my post to include some code to show how the entity and its sprite interact.
Apr
17
asked A few questions about entity states
Apr
10
awarded  Supporter
Mar
21
comment Graphics module: Am I going the right way?
[cont.] Friends vs inheritance: How would you suggest I make the ImageData available to the Renderer through interface inheritance? | Similarity of classes: I did notice that. | Reason for engine: To learn. It's my first 2D engine. Or do you mean what is its scope?
Mar
21
comment Graphics module: Am I going the right way?
What to review: The class hierarchy and/or interaction between classes. | Assumption: It's a wrong one to make. Why would I ever define a copy constr. and an assignment opr. otherwise, anyway?! | Ptsize: Yes, I know. It was a temporary solution to the limitations imposed by SDL. Now that I switched to SFML the problem is fixed. | Private: Others say 'everything should start out private and become more visible as needed. To me that personally makes more sense than everything should become as visible as needed and become more hidden as it becomes less needed. [contd.]
Mar
21
awarded  Editor
Mar
21
revised Graphics module: Am I going the right way?
Added some details
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 &mdash; 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.]