Hi there,
Over the past few weeks I have been learning modern OpenGL (programmable pipeline) however there doesn't seem to be much coverage on 2d games.
What I would like to know is,
1. Is it best to use an orthographic projection or a perspective projection?
2. If using an Ortho projection, should you use your screen height and width or some other values?
3. Should you edit positions using shaders / translation matrices or edit values inside VBO's?
4. When using a Ortho projection and loading models (3d) from file, how can you translate the position from -1,1 to use it?
I think that's all for now. If I think of anything else I'll post it below.
Thanks
How to handle 2D OpenGL?
Moderator: Coders of Rage
- superLED
- Chaos Rift Junior
- Posts: 303
- Joined: Sun Nov 21, 2010 10:56 am
- Current Project: Engine
- Favorite Gaming Platforms: N64
- Programming Language of Choice: C++, PHP
- Location: Norway
Re: How to handle 2D OpenGL?
I am not even close at being comfortable with OpenGL, but I'll give it a shot anyway. (plz don't hate on me ^^)nickyc95 wrote:Hi there,
Over the past few weeks I have been learning modern OpenGL (programmable pipeline) however there doesn't seem to be much coverage on 2d games.
What I would like to know is,
1. Is it best to use an orthographic projection or a perspective projection?
2. If using an Ortho projection, should you use your screen height and width or some other values?
3. Should you edit positions using shaders / translation matrices or edit values inside VBO's?
4. When using a Ortho projection and loading models (3d) from file, how can you translate the position from -1,1 to use it?
I think that's all for now. If I think of anything else I'll post it below.
Thanks
1: Orthographic projection would be the way to go, if you want the classic 2D look.
2: I always use screen width/height, because those values are sooo much easier to work with, because you know better where 100px X 100px is on the screen, than where 2.435? X 5.23? is on the screen.
Though, if you zoom in and out (if your game allows that), that's another story, but you can still somehow imagine where 100px X 100px would be if you zoomed in x2 (50px X 50px)
3: It depends on how fancy you wanna be, and if your game is going to go hard on the CPU/GPU.
4: I don't understand the question... Your model is at -1, 1, and you want to move it into view/into the game space/room?
-
- Respected Programmer
- Posts: 387
- Joined: Fri Dec 19, 2008 3:33 pm
- Location: Dallas
- Contact:
Re: How to handle 2D OpenGL?
1. Is it best to use an orthographic projection or a perspective projection?
It's definitely easiest to deal with orthographic projections in the 2D space. Now what you want that space to be is just what's convenient for you. You can load up identity matrices into the pipeline and render directly to normalized device coordinates.
2. If using an Ortho projection, should you use your screen height and width or some other values?
Depends on what works for you, again. We try to stay away from screen coordinates generally because they don't have any intrinsically interesting information or value at all. We don't think in the world in terms of where things are on a screen. We think of them in relation to the world. Devising some meaningful world coordinate frame and making the transform to screen space seems much better and more robust.
3. Should you edit positions using shaders / translation matrices or edit values inside VBO's?
How often is this happening? We would expect certain positions to change every frame and this is certainly fine to do from the client side by editing the VBO. Interestingly if you have a VBO that changes once per frame it is generally better (due to the way the driver implements VBO) to simply re-upload the static data than to map it to dynamic memory and make the changes.
4. When using a Ortho projection and loading models (3d) from file, how can you translate the position from -1,1 to use it?
Look up coordinate systems and the transformation pipeline. When we start talking 3D then you have a few extra steps there.
It's definitely easiest to deal with orthographic projections in the 2D space. Now what you want that space to be is just what's convenient for you. You can load up identity matrices into the pipeline and render directly to normalized device coordinates.
2. If using an Ortho projection, should you use your screen height and width or some other values?
Depends on what works for you, again. We try to stay away from screen coordinates generally because they don't have any intrinsically interesting information or value at all. We don't think in the world in terms of where things are on a screen. We think of them in relation to the world. Devising some meaningful world coordinate frame and making the transform to screen space seems much better and more robust.
3. Should you edit positions using shaders / translation matrices or edit values inside VBO's?
How often is this happening? We would expect certain positions to change every frame and this is certainly fine to do from the client side by editing the VBO. Interestingly if you have a VBO that changes once per frame it is generally better (due to the way the driver implements VBO) to simply re-upload the static data than to map it to dynamic memory and make the changes.
4. When using a Ortho projection and loading models (3d) from file, how can you translate the position from -1,1 to use it?
Look up coordinate systems and the transformation pipeline. When we start talking 3D then you have a few extra steps there.
Re: How to handle 2D OpenGL?
qpHalcy0n wrote:1. Is it best to use an orthographic projection or a perspective projection?
It's definitely easiest to deal with orthographic projections in the 2D space. Now what you want that space to be is just what's convenient for you. You can load up identity matrices into the pipeline and render directly to normalized device coordinates.
2. If using an Ortho projection, should you use your screen height and width or some other values?
Depends on what works for you, again. We try to stay away from screen coordinates generally because they don't have any intrinsically interesting information or value at all. We don't think in the world in terms of where things are on a screen. We think of them in relation to the world. Devising some meaningful world coordinate frame and making the transform to screen space seems much better and more robust.
3. Should you edit positions using shaders / translation matrices or edit values inside VBO's?
How often is this happening? We would expect certain positions to change every frame and this is certainly fine to do from the client side by editing the VBO. Interestingly if you have a VBO that changes once per frame it is generally better (due to the way the driver implements VBO) to simply re-upload the static data than to map it to dynamic memory and make the changes.
4. When using a Ortho projection and loading models (3d) from file, how can you translate the position from -1,1 to use it?
Look up coordinate systems and the transformation pipeline. When we start talking 3D then you have a few extra steps there.
Thanks for the answer. For question 2 how are you supposed to accurately position objects? (Same thing as what the first reply mentions)
Thanks
- superLED
- Chaos Rift Junior
- Posts: 303
- Joined: Sun Nov 21, 2010 10:56 am
- Current Project: Engine
- Favorite Gaming Platforms: N64
- Programming Language of Choice: C++, PHP
- Location: Norway
Re: How to handle 2D OpenGL?
If you're using the method he's talking about, you could say that one tile is for example 0.5 x 0.5 meter, if that makes sense in your game, and just work your way from there (scale your models etc. to fit in these measurements).
So if you're going to add a tree in the map, you could just make it 3 meters tall, 1.5 meters wide... 5 meters left of the Blacksmiths' house.
This way, you don't have to remember that 32 pixels on screen is equivalent of 0.5 meters. You can just use logic.
So if you're going to add a tree in the map, you could just make it 3 meters tall, 1.5 meters wide... 5 meters left of the Blacksmiths' house.
This way, you don't have to remember that 32 pixels on screen is equivalent of 0.5 meters. You can just use logic.
Re: How to handle 2D OpenGL?
But wouldn't that make it more difficult to understand. If I have sprites or models that are exactly 16x16 pixels how do I determine that they are the size that they should be?superLED wrote:If you're using the method he's talking about, you could say that one tile is for example 0.5 x 0.5 meter, if that makes sense in your game, and just work your way from there (scale your models etc. to fit in these measurements).
So if you're going to add a tree in the map, you could just make it 3 meters tall, 1.5 meters wide... 5 meters left of the Blacksmiths' house.
This way, you don't have to remember that 32 pixels on screen is equivalent of 0.5 meters. You can just use logic.
Thanks
Re: How to handle 2D OpenGL?
Hey again, over the course of the day I have been looking into finding more info.
What I would like to know is, is it a good idea to use gluUnProject and pass in the screen coordinates to convert it into world coords?
Thanks
What I would like to know is, is it a good idea to use gluUnProject and pass in the screen coordinates to convert it into world coords?
Thanks
-
- Respected Programmer
- Posts: 387
- Joined: Fri Dec 19, 2008 3:33 pm
- Location: Dallas
- Contact:
Re: How to handle 2D OpenGL?
I think you're really thinking about this backwards.
gluUnProject is a pretty heavyweight function. I would avoid it.
gluUnProject is a pretty heavyweight function. I would avoid it.