Easier graphics API for 2D game development?

Started by
25 comments, last by suckxez 17 years, 3 months ago
Quote:Original post by IKG
Alright, well I guess I might as well give it a shot. It's not that I can't stand SDL and never want to use it. It's just that I would rather use it with a 3D game than a 2D game since it can basically do it all for me without having to touch OpenGL.

Are there any good 2D OpenGL/SDL tutorials that show how to use them together?


again, check out Lazy Foo' Productions. I think he recently got a OpenGL and SDL tutorial up. I'm still looking for that other OpenGL and SDL tutorial for you though.

EDIT: AHA! found one of them!
David Olofson's SDL page
and find the one called 'smoothscroll'. there was one more, that was quite a bit simpler, but since I can't get onto libsdl.org, I can't find it :(
sorry

hope that helps though.
-Wynter Woods(aka Zerotri)
Advertisement
Quote:Original post by IKG
Actually, is there a small simple library for input too? I know it's just more work to use 3 seperate libraries instead of just OpenGL and SDL, but SDL just seems like too much of an "easy way out" with less credibilty - seeing how image functions can be done with it alone. Please no lectures lol.. I know what I'm doing is unnecessary but it's for practice so it can't hurt.


Alright, here's your lecture. You're being stupid and you aren't thinking this all the way through. You want a library that doesn't give you an easy way out? Well, then OpenGL is out the window. After all, OpenGL is an easy way out, a replacement for lower-level graphics control which is tooooo haaaaaard. Ditto with Direct3D, of course. Oh, and quit using the Windows API, which gathers input and graphics and all that into one "easy way out." You don't need it. You can make BIOS calls instead. That way, things will be nice and difficult and you'll get sick and tired of all this game development crap and quit.

On the other hand, maybe the reason you want to do things without an "easy way out" is that you really want to get experince with how things work under the hood, but without having to get endlessly bogged down in hardware-specific stuff. Good idea. Don't listen to anybody who tells you that you don't need to care about what's happening, because it isn't true. There isn't a single successful game developer out there who can't do things close to the metal when it's needed. So congrats on taking the right path.

The only problem is, you screwed up a little. You lumped SDL into the category of "libraries which keep me from seeing what's really going on", instead of the category of "libraries which let me worry about stuff that really matters". I can assure you, it is not in the former category. SDL is actually really good at stepping out of the way when you want to do things it doesn't support. In fact, SDL's support for OpenGL pretty much IS it stepping out of the way; with the exception of a couple of WGL calls, SDL has no idea how to do OpenGL. You do that yourself.

And let's generalize a bit from your mistake there, since the only real way to learn from mistakes is to apply their lessons as generally as possible. When evaluating a library to figure out which of those categories to put something into, it is a Bad Idea to look negatively at libraries which make things conventient. Convenient libraries are convenient because they are the result of experience. I have seen inconvenient libraries, and they are the result of people who shouldn't be writing them. And they take you further from what's really going on, not closer. Instead of looking negatively on convenience, look negatively on lock-in. SDL doesn't make you use SDL for image loading; you can do your own thing. It doesn't make itself the only way to do 2D graphics; in a pinch you can grab the HWND and use it yourself. This is quite unlike something like DarkBasic, which makes itself the only way to do things. The perfect library--both for learning, and for using--is one which will do things for you but will step out of the way and let you do them yourself if you want it to. SDL fits that mold.
Quote:Original post by SneftelThe only problem is, you screwed up a little. You lumped SDL into the category of "libraries which keep me from seeing what's really going on", instead of the category of "libraries which let me worry about stuff that really matters". I can assure you, it is not in the former category.


That's exactly how I was thinking. Thanks for clearing that up :)

And thanks a lot zerotri. I found that tutorial and it looks like a great place to start.

Thanks again everyone. Happy holidays too :D
Why didn't anyone ever mention GLUT? I didn't know much about it until now.

Is it harder to use than SDL? I looked through the documentation real quick and it looks pretty simple.

Also as a side question: Couldn't I theoretically use OpenGL to do the rendering (draw textures) for a ray casting engine? I know that would kind of ruin the purpose since OGL can be used for 3D and ray casting is for using hardware only, but would it work? If yes, would it be faster?
last bump
Quote:Original post by IKG
Why didn't anyone ever mention GLUT? I didn't know much about it until now.

Is it harder to use than SDL? I looked through the documentation real quick and it looks pretty simple.

Also as a side question: Couldn't I theoretically use OpenGL to do the rendering (draw textures) for a ray casting engine? I know that would kind of ruin the purpose since OGL can be used for 3D and ray casting is for using hardware only, but would it work? If yes, would it be faster?



Nobody mentioned glut because its a dead library. I think the last time glut was updated was in 1998, and thats ALONG time ago - its old, and it really shows its age. It is pretty good for learning (I learnt OpenGL useing it) but practically everyone who uses glut moves onto SDL in the end. Glut has some very handy functions but in the end SDL is more flexible and in my oppinion better organised. Glut is still good, but most people (myself included) would agree SDL is way better.

And yes you can use openGL to render your raytraced image. But the raytracing to get your image will be very slow. OpenGL might actually blit the image to the screen faster that pure SDL or Win32 call, but if it takes you 10 seconds to raytrace your image, the few microseconds you'll gain from useing OpenGL to render the output won't make that much difference.

Besides - if your doing this for technical reasons because you like a challenge then make a demo. Something that'll draw cool colours in pretty patterns to the screen. If your going to be making a game, trust me that setting up a window is the least of your problems. Useing Allegro, SDL or Win32 won't make the sleightest bit of difference after the first two weeks because the hard bit is actually organising your game logic, collision detection, physics and all that. The bit your worried about is the bit you'll only ever write once then cut+paste into every other project. Much better use of your time is to worry about your game being fun!
Perhaps HGE is what you are looking for.
It's an very easy to use 2D hardware accelerated engine which uses DirectX.
http://hge.relishgames.com/

This topic is closed to new replies.

Advertisement