What Graphics Library to use?

Started by
13 comments, last by XDaWNeDX 12 years, 11 months ago
Powerful enough? It's not inefficient for a 2D library and has the basic rendering features as well as pixel shaders, Audio and Keyboard and Gamepad support. Graphics and Audio file loading is simple, and sprite rotation, scaling, and the like are all easily implemented and for your average 2D game I'd consider it more than apt, yes. It does lack built-in render-to-texture functionality though which does limit the flexibility of pixel shaders somewhat, though somebody may have implemented that as a 3rd party library, or it could be in the next-version beta.

"Power" isn't exactly a measurable element...

"Game physics" on the other hand is a very wide ranging subject. For example, collision detection and handling falls under the field of game physics. Jumping, gravity, friction, explosions, systems can become very complicated or be very simple. Generic physics systems, such as Box2D exist but it's up to you to decide if so flexible a system is what you desire based on the type of game.

Asteroids, Super Mario Brothers and Portal 2 all have very different physics systems after all.
Advertisement

Powerful enough? It's not inefficient for a 2D library and has the basic rendering features as well as pixel shaders, Audio and Keyboard and Gamepad support. Graphics and Audio file loading is simple, and sprite rotation, scaling, and the like are all easily implemented and for your average 2D game I'd consider it more than apt, yes. It does lack built-in render-to-texture functionality though which does limit the flexibility of pixel shaders somewhat, though somebody may have implemented that as a 3rd party library, or it could be in the next-version beta.

"Power" isn't exactly a measurable element...

"Game physics" on the other hand is a very wide ranging subject. For example, collision detection and handling falls under the field of game physics. Jumping, gravity, friction, explosions, systems can become very complicated or be very simple. Generic physics systems, such as Box2D exist but it's up to you to decide if so flexible a system is what you desire based on the type of game.

Asteroids, Super Mario Brothers and Portal 2 all have very different physics systems after all.



So SFML would be a good choice for making an extremely large MMORPG?

I don't have high hopes, just I want to stick to one graphics API throughout my programming career, so every small and large project. Although I understand I'm probably going to make a few games in one, some in another etc.
I am a sesquipidalian.

Go not where the path leads, but rather walk somewhere new and leave a trail.

So SFML would be a good choice for making an extremely large MMORPG?

I don't have high hopes, just I want to stick to one graphics API throughout my programming career, so every small and large project. Although I understand I'm probably going to make a few games in one, some in another etc.


It would probably be possible to write an 'extremely large' MMORPG in SFML, but it would be ridiculously hard
In fact, writing such a game wouldn't be easy no matter which engine you choose

Sticking to one API throughout your career would be close to impossible, and it wouldn't be wise in general to limit yourself like this
Being able to use multiple API's is a huge benefit, you'll never know in what kind of project you will end up and what their requirements will be

I gets all your texture budgets!


[quote name='MrMorley' timestamp='1305670925' post='4812126']
Powerful enough? It's not inefficient for a 2D library and has the basic rendering features as well as pixel shaders, Audio and Keyboard and Gamepad support. Graphics and Audio file loading is simple, and sprite rotation, scaling, and the like are all easily implemented and for your average 2D game I'd consider it more than apt, yes. It does lack built-in render-to-texture functionality though which does limit the flexibility of pixel shaders somewhat, though somebody may have implemented that as a 3rd party library, or it could be in the next-version beta.

"Power" isn't exactly a measurable element...

"Game physics" on the other hand is a very wide ranging subject. For example, collision detection and handling falls under the field of game physics. Jumping, gravity, friction, explosions, systems can become very complicated or be very simple. Generic physics systems, such as Box2D exist but it's up to you to decide if so flexible a system is what you desire based on the type of game.

Asteroids, Super Mario Brothers and Portal 2 all have very different physics systems after all.



So SFML would be a good choice for making an extremely large MMORPG?

I don't have high hopes, just I want to stick to one graphics API throughout my programming career, so every small and large project. Although I understand I'm probably going to make a few games in one, some in another etc.
[/quote]

You will get to your goals faster if you just grab an api and start hacking away. Don't sit on the fence about every detail you deem important today, as you will surely not tomorrow.

[quote name='XDaWNeDX' timestamp='1305673331' post='4812143']
So SFML would be a good choice for making an extremely large MMORPG?

I don't have high hopes, just I want to stick to one graphics API throughout my programming career, so every small and large project. Although I understand I'm probably going to make a few games in one, some in another etc.


It would probably be possible to write an 'extremely large' MMORPG in SFML, but it would be ridiculously hard
In fact, writing such a game wouldn't be easy no matter which engine you choose

Sticking to one API throughout your career would be close to impossible, and it wouldn't be wise in general to limit yourself like this
Being able to use multiple API's is a huge benefit, you'll never know in what kind of project you will end up and what their requirements will be
[/quote]


So SFML would be a good choice for making an extremely large MMORPG?

I don't have high hopes, just I want to stick to one graphics API throughout my programming career, so every small and large project. Although I understand I'm probably going to make a few games in one, some in another etc.

I know I will use multiple APIs, however I have a specific game I wish to create, and until I create that game (and all games to teach myself HOW to make that game) I won't be differing from my plan at all.


[quote name='XDaWNeDX' timestamp='1305673331' post='4812143']
[quote name='MrMorley' timestamp='1305670925' post='4812126']
Powerful enough? It's not inefficient for a 2D library and has the basic rendering features as well as pixel shaders, Audio and Keyboard and Gamepad support. Graphics and Audio file loading is simple, and sprite rotation, scaling, and the like are all easily implemented and for your average 2D game I'd consider it more than apt, yes. It does lack built-in render-to-texture functionality though which does limit the flexibility of pixel shaders somewhat, though somebody may have implemented that as a 3rd party library, or it could be in the next-version beta.

"Power" isn't exactly a measurable element...

"Game physics" on the other hand is a very wide ranging subject. For example, collision detection and handling falls under the field of game physics. Jumping, gravity, friction, explosions, systems can become very complicated or be very simple. Generic physics systems, such as Box2D exist but it's up to you to decide if so flexible a system is what you desire based on the type of game.

Asteroids, Super Mario Brothers and Portal 2 all have very different physics systems after all.



So SFML would be a good choice for making an extremely large MMORPG?

I don't have high hopes, just I want to stick to one graphics API throughout my programming career, so every small and large project. Although I understand I'm probably going to make a few games in one, some in another etc.
[/quote]

You will get to your goals faster if you just grab an api and start hacking away. Don't sit on the fence about every detail you deem important today, as you will surely not tomorrow.
[/quote]


Well of course. That's why I'm thinking ahead. I'm taking a break from learning C++ and researching what to do AFTER I read my c++ books and understand everything in it. So I will weed out the details now, so when I get to decision making time I waste less time. Although, I could just keep learning and pick a random API, that would require nearly 24/7 learning without any breaks.

I know where I am, what I'm doing, and where I'll go. I just don't know when I'll be there, or what I'll use to get there.
I am a sesquipidalian.

Go not where the path leads, but rather walk somewhere new and leave a trail.

This topic is closed to new replies.

Advertisement