Hey guys,
First up let me say I am new to Gamedev, I hope this is in the right section, if not, please let me know. Second up, I have not been coding that long, at least in C++.
My dilemma is that I am not sure if what I am doing is that feasible, since I'm running in to mountains of problems the more I try. I had an idea of having SDL running within a class, and passing any and all surfaces to that class to be handled, leaving the main() function for the calculation and movement of characters, and all that sort of thing. The more I seem to try, the more complicated and broken this seem to be. Example, my flatterAndRender function.
I have in place, in a System class, two SDL_Surfaces to start with. layer1, and buffer. I was going to have main() create surfaces, pass them to the System, and have flattenAndRender blit the layers on to the buffer in succession, though this is leading to errors with my pointers and just a huge mess. What is the best way to go about having a System class? I feel like I'm going about this the wrong way.
Hope you guys can *me in the right direction. xD
I actually feel kinda bad for that joke.
SDL running within a class
It really depends on the size and scope of your game.
You should be able to create the surfaces in main, and pass them to your class. Can you post the code that is causing you trouble? There is probably some minor error in it.
That said, I would advise against having a class named "System", as that is a rather vague name that could easily grow legs/tentacles/worse. Small classes that do well defined jobs are easier to write, read, maintain, debug and reason about in general. If your class concerns with rendering stuff to the screen, why not call it a Renderer?
You should be able to create the surfaces in main, and pass them to your class. Can you post the code that is causing you trouble? There is probably some minor error in it.
That said, I would advise against having a class named "System", as that is a rather vague name that could easily grow legs/tentacles/worse. Small classes that do well defined jobs are easier to write, read, maintain, debug and reason about in general. If your class concerns with rendering stuff to the screen, why not call it a Renderer?
Hey guys,
First up let me say I am new to Gamedev, I hope this is in the right section, if not, please let me know. Second up, I have not been coding that long, at least in C++.
If you want fast answers this is the right place... no offence game dev.
My dilemma is that I am not sure if what I am doing is that feasible, since I'm running in to mountains of problems the more I try. I had an idea of having SDL running within a class, and passing any and all surfaces to that class to be handled, leaving the main() function for the calculation and movement of characters, and all that sort of thing. The more I seem to try, the more complicated and broken this seem to be. Example, my flatterAndRender function.
[/quote]
Why? What was the thought process behind this descision? Not to be rude, but never code anything just because. You should have an idea for why you're doing what you're doing. It'll make it easier to stay on track.
I have in place, in a System class, two SDL_Surfaces to start with. layer1, and buffer. I was going to have main() create surfaces, pass them to the System, and have flattenAndRender blit the layers on to the buffer in succession, though this is leading to errors with my pointers and just a huge mess. What is the best way to go about having a System class? I feel like I'm going about this the wrong way.
[/quote]
pointers? Something probably went out of scope then you tried to use it. Is flattenAndRender part of the system class? Posting the code would be extremely helpful here.
Hope you guys can *me in the right direction. xD
[/quote]
Clever, almost gave ya a plus one for it ;P
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
