This is killing my brain...

[Pornomag]

Okay basically I've gone into this stage where I have no idea what to do anymore. OK here's my situation and tell me your opinion on what you would do.

Okay, so far I've been designing classes with SDL for images, font's, sounds, a window and such. Now so far, I haven't been working with OpenGL at all. Then I look at SFML and it's classes and I see it and feel all depressed like I should have learnt that library instead of SDL. I also tried linking SDL and SFML for the Mac OS X Lion with Xcode 4.1 and I just cant do it??

Now, if you were me, would you stick with SDL and keep writing a tonne of classes? Or move onto SFML and use the classes that already has been provided? Which one would I benefit from the most?

I was thinking of staying with SDL until I implement OpenGL stuff into there, and have File I/O for basically all of my classes so it is a crap load more customize-able.

Also another thing I might mention instead of making another thread is: whenever I try to create a std::ofstream object inside the .cpp of a class's implementation in DEBUG mode it will give me linker errors? S: It's in the subsystem CONSOLE for easier debugging, but it works when I put the subsystem to WINDOWS. Any ideas?

[Falco Girgis]

Jesus Christ... Here is a great example of the OO dilemma.

The constant that I've seen in all of your confusion is the word "classes." Sounds like you were wrapping the shit out of SDL into pretty little classes, then realized that SFML is already a pretty little C++ library? So now you're wondering if 1) you're wasting your time wrapping SDL and 2) if SFML is better structured anyway?

Honestly? Who gives a fuck. You're using C++ and making classes to make your life EASIER to begin with. OO and C++ is supposed to facilitate your development, not cause barriers like this. Just because MDK and I were talking about it, look at this straight-C demo on the Android (complete with C-style fake inheritance):
http://developer.android.com/reference/ ... ivity.html

There's not a single class, and it's still beautiful and works fine. The day that you spend more time making problems with OO in C++ than you do SOLVING them, is the day that you're going about OO programming incorrectly.

I also tried linking SDL and SFML for the Mac OS X Lion with Xcode 4.1 and I just cant do it??

I just ported all of our ES stuff to XCode 4.1 the other day as well... and you can't do it probably because the IDE is a pain in the ass. It's extremely complex. It takes a lot of time for ME to do anything in it. Don't beat yourself up. Post specific questions, and we'll help getting it built.

I was thinking of staying with SDL until I implement OpenGL stuff into there

Well there's something... You realize OpenGL does not handle Window management, input, or audio? So you would still NEED a library like SDL to interface with OpenGL. I use both in ES. And you also realize that OpenGL is an ANSI C library that you're going to be "wrapping the shit out of" in C++ as well?

Or move onto SFML and use the classes that already has been provided? Which one would I benefit from the most?

Depends. There are multiple scenarios. SDL and OpenGL are C libraries, so you are free to work them into your own OO paradigm. Personally, I like having this freedom, so that I can structure the OO design of my own engine in any manner that I like. SFML is already OO, and you are going to be following their paradigm to some extent or another. It saves a lot of time (for some people), but it is also more restrictive.

Which one is going to get you to your end-goal faster? Are you going to spend more time wrapping the shit out of SDL and OpenGL than you are actually USING them? Are you going to spend more time fighting against SFML's paradigm than you are actually using it? Both technologies can make equally kickass games...

have File I/O for basically all of my classes so it is a crap load more customize-able.

I honestly don't know why EVERY CLASS having file IO is more "customizable" than an alternative (sounds more inefficient to me). Sounds like you're falling into the OO-obsessed trap.

Also another thing I might mention instead of making another thread is: whenever I try to create a std::ofstream object inside the .cpp of a class's implementation in DEBUG mode it will give me linker errors? S: It's in the subsystem CONSOLE for easier debugging, but it works when I put the subsystem to WINDOWS. Any ideas?

If it works on Windows, what operating system does it NOT work on?

[Falco Girgis]

O. And moving to Programming discussion...

[dandymcgee]

O. And moving to Programming discussion...

Lmao, you must be really bored lately.

[Falco Girgis]

O. And moving to Programming discussion...

Lmao, you must be really bored lately.

I have begun developing OCD about whether posts are categorized correctly or not.

[Live-Dimension]

Or move onto SFML and use the classes that already has been provided? Which one would I benefit from the most?

Depends. There are multiple scenarios. SDL and OpenGL are C libraries, so you are free to work them into your own OO paradigm. Personally, I like having this freedom, so that I can structure the OO design of my own engine in any manner that I like. SFML is already OO, and you are going to be following their paradigm to some extent or another. It saves a lot of time (for some people), but it is also more restrictive.

I've run into the same areas as Gyro - sfml's OOP design conflicts sometimes with what I desire. There is a c port that I have to mess around with sometime, which will probably let you structure the engine alot more to your likeing.

have File I/O for basically all of my classes so it is a crap load more customize-able.

I handle all the data structures internally - there is only a few classes that even touch the File I/O which handle writing and reading the data to and from the internal data structures. There is no reason to have sprites and sounds load up thier own files from thier own class, as all you'll end up doing is writing more code for what?

tl;dr version: Your beginning games will likely be structured horribly. This is normal. There's no right way to structure an engine, and you shouldn't be worrying about it now. Just make some games, try out different ideas, research around abit. You're worrying too much about OOP and it's getting you no where. You just tend to evovle your own style and engine over time, just keep making games. That's all there is too it.