My friend and I decided to make a game using SDL library and C++ language but we have a hard time starting out. We would like for the community here to pitch all they information they can have about 2D side scrolling game that would help us. Includes tips to make colision with terrain, enemies, AI, game loop etc.... anything that you think is pertinent will be appreciated Thanks
At 10/3/12 10:46 PM, MadaraXo wrote: We would like for the community here to pitch all they information they can have about 2D side scrolling game that would help us.
what knowledge do you have of C++, OOP, and prgramming?
Programming stuffs (tutorials and extras)
PM me (instead of MintPaw) if you're confuzzled.
thank Skaren for the sig :P
At 10/4/12 01:28 PM, polym wrote: Not everything has to be OOP. SDL is very procedural, but if you want to abuse OOP then use SFML instead.
http://www.sdltutorials.com/first-foray-into-sdl-opengl-with -csharp
it's C#, but that was literally the first tutorial I found on SDL. Looks like OOP to me.
Programming stuffs (tutorials and extras)
PM me (instead of MintPaw) if you're confuzzled.
thank Skaren for the sig :P
Programming stuffs (tutorials and extras)
PM me (instead of MintPaw) if you're confuzzled.
thank Skaren for the sig :P
At 10/5/12 01:12 AM, polym wrote: Your obsession with OOP, especially by name, makes me think that you're a noob.
compared to a lot of people, I very much am!
When people employ OOP concepts nobody actually calls it that, because they understand the concept without overusing the word. You can tell the difference between people who abuse OOP and those who don't simply by seeing whether or not they explicitly want to use it.
actually, I was attacking your argument that "not everything has to be OOP"
no, I suppose it doesn't, but why in the world would you want to program that way?
Sure, somebody writing a game is going to use an OOP approach, but if he's asking basic questions, rather than specific ones, chances are designing the game with OOP from the start is going to create a flawed design.
what flaws are you thinking of that could arise from the use of OOP? From my understanding (and I made an entire thread about this) it's a very well structured and organized method of programming.
It's a lot more straight forward to procedurally write it especially when dealing with events.
Actionscript 3 is event-driven, and people still very highly recommend the use of FlashDevelop, which forces you to use OOP concepts.
Programming stuffs (tutorials and extras)
PM me (instead of MintPaw) if you're confuzzled.
thank Skaren for the sig :P
At 10/5/12 08:50 AM, egg82 wrote: actually, I was attacking your argument that "not everything has to be OOP"
no, I suppose it doesn't, but why in the world would you want to program that way?
C is a hell of a lot faster if you know what you are doing, OOP in C++ is just an illusion that the compiler feeds you, in reality all your classes turn into structs at runtime and every member function will turn into a procedural function that receives the this pointer as an extra argument (visualc will pass it through rcx, gcc not sure). If you don't use virtual functions it's pretty much the same, but virtual tables and inheritance take their toll on memory management, every call to the new operator will also have to place the vtable pointer at the start of the object and overall there's stuff that happens in the background that make it more desirable for people to write code in C (extern "C" would be a good example for this)
Sure, somebody writing a game is going to use an OOP approach, but if he's asking basic questions, rather than specific ones, chances are designing the game with OOP from the start is going to create a flawed design.what flaws are you thinking of that could arise from the use of OOP? From my understanding (and I made an entire thread about this) it's a very well structured and organized method of programming.
God objects, strongly coupled components, plus that it's horribly easy to make wrong decisions like keeping a transform matrix as a part of an object as opposed to having it in a contiguous space where it can benefit from cache line locality, OOP is not without it's flaws.
It's a lot more straight forward to procedurally write it especially when dealing with events.Actionscript 3 is event-driven, and people still very highly recommend the use of FlashDevelop, which forces you to use OOP concepts.
I can't really see how this is an argument in favor of anything related to the C/C++ world, adding an ECMAScript implementation to the discussion will just prove what polym is trying to tell you, that you are blindly following a trend rather than acknowledge the benefits.
In this case, what polym is trying to say is that the SDL event API is procedural (reference and .h file), if you want to use OOP you have to add an abstraction layer, which depending on your setup isn't necessarily a good idea, why propagate an object reference when you can look for a specific event (SDL_HasEvent, not SDL_PollEvent).
At 10/5/12 06:51 PM, kiwi-kiwi wrote: C is a hell of a lot faster if you know what you are doing, OOP in C++ is just an illusion that the compiler feeds you, in reality all your classes turn into structs at runtime and every member function will turn into a procedural function that receives the this pointer as an extra argument (visualc will pass it through rcx, gcc not sure). If you don't use virtual functions it's pretty much the same, but virtual tables and inheritance take their toll on memory management, every call to the new operator will also have to place the vtable pointer at the start of the object and overall there's stuff that happens in the background that make it more desirable for people to write code in C (extern "C" would be a good example for this)
at runtime or buildtime? Seems more logical that everything would turn into crap at buildtime. Anyway, i'm not sure that it's terribly important that everything stays the same throughout. If you can understand it (human readability via OOP) and the computer can understand it (compiling to the executable) then what's there to worry about?
God objects, strongly coupled components, plus that it's horribly easy to make wrong decisions like keeping a transform matrix as a part of an object as opposed to having it in a contiguous space where it can benefit from cache line locality, OOP is not without it's flaws.
fair enough, I didn't know that.
I can't really see how this is an argument in favor of anything related to the C/C++ world, adding an ECMAScript implementation to the discussion will just prove what polym is trying to tell you, that you are blindly following a trend rather than acknowledge the benefits.
Here I was stating that "event-driven" does not mean "does not work with OOP", which is what I was getting from polym.
In this case, what polym is trying to say is that the SDL event API is procedural (reference and .h file), if you want to use OOP you have to add an abstraction layer, which depending on your setup isn't necessarily a good idea, why propagate an object reference when you can look for a specific event (SDL_HasEvent, not SDL_PollEvent).
ah, I see. Still, how exactly do you code that way without getting lost in spaghetti?
Programming stuffs (tutorials and extras)
PM me (instead of MintPaw) if you're confuzzled.
thank Skaren for the sig :P
At 10/5/12 09:54 PM, egg82 wrote:
at runtime or buildtime? Seems more logical that everything would turn into crap at buildtime. Anyway, i'm not sure that it's terribly important that everything stays the same throughout. If you can understand it (human readability via OOP) and the computer can understand it (compiling to the executable) then what's there to worry about?
I may be wrong about this, but when a C++ application is being built, this is when the either the compiler or the IDE is caching data of some kind. The IDE takes your application and creates makefiles, and possibly generates arguments for the compiler you've set up for your application to use. Build time does not, at all -- even in the slightest bit -- compile instructions.
ah, I see. Still, how exactly do you code that way without getting lost in spaghetti?
"Spaghetti code" can still exist in C++. The term "spaghetti code" arose from Assembler programmers where many application's source had no straight direction, and the program's instructions moved as if it were a pile of spaghetti in a bowl, interleaving with all kinds of bullshit. Languages like C have some design to evade spaghetti code, but that does not mean it can't happen. When you have a programmer who doesn't understand coding standards, or even basic code organization, or even can't code worth a damn, spaghetti code can still happen.
