OpenGL, Scrolling and Split Screens

Since we’ve been on the topics of 2D using OpenGL and split-screens and
such, I thought it might be appropriate to mention that using glViewPort,
you can naturally split the screen into halves or quarters and let OpenGL
handle clipping. The prototype is the following:

void glViewport(
GLint x,
GLint y,
GLsizei width,
GLsizei height
);

For example, if you’re running 800x600 and want a split across the middle,
you’d call glViewport(0,0,800,300) to draw the top, and
glViewport(0,300,800,300) to do the bottom (I believe).

The key here, in terms of performance, is to clip the tiles outside of the
viewing volume before sending them to OpenGL. If anyone has a fast
algorith for this, preferably with an arbitrary camera position, it would be
very welcome.

Brent Schartung

Brent Schartung wrote:

The key here, in terms of performance, is to clip the tiles outside of the
viewing volume before sending them to OpenGL. If anyone has a fast
algorith for this, preferably with an arbitrary camera position, it would be
very welcome.

Brent Schartung

Try glScissor.

Proff–
Florian ‘Proff’ Schulze - @Florian_Schulze
Homepage: - http://proff.fly.to
PGP-Key available from - http://www.keyserver.net/en/

Since we’ve been on the topics of 2D using OpenGL and split-screens and
such, I thought it might be appropriate to mention that using glViewPort,
you can naturally split the screen into halves or quarters and let OpenGL
handle clipping. The prototype is the following:

void glViewport(
GLint x,
GLint y,
GLsizei width,
GLsizei height
);

For example, if you’re running 800x600 and want a split across the middle,
you’d call glViewport(0,0,800,300) to draw the top, and
glViewport(0,300,800,300) to do the bottom (I believe).

That would be the way to emulate splitscreen - and some other things

  • in 3D games. I’d guess no special SDL support would be required to
    use that.

Anyway, nothing is a serious problem with OpenGL, really, at least
nothing to do with speed and screen layout flexibility. The issue
here is optimizing 2D on targets without accelerated OpenGL - that’s
where it gets complicated…

The key here, in terms of performance, is to clip the tiles outside of the
viewing volume before sending them to OpenGL. If anyone has a fast
algorith for this, preferably with an arbitrary camera position, it would be
very welcome.

When it comes to tiles I usually just store these in a somewhat
coordinate oriented structure, such as (the simplest one) an array
with X columns of Y tiles, which is what I’m using in that old gami
I’m porting. Getting the tiles for any area of the screen (or rather
map) is just a matter of shifting down the coords into tile coords,
and then indexing away.

It gets slightly more complicated with iso 3D views, and a lot more
complicated if you can rotate the camera.

As to sprites, unless there are sufficiently few of thew to just
check them all (and all sprites in the world are active until
"killed" - there are reasons to do it that way in some games), just
hook them up to the map using linked lists. That way, you can easiy
check for sprites in any area of the map, simply indexing map tiles,
and following any lists of sprites you find.

//David

.- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter |
-----> http://www.linuxdj.com/mucos -'—> david at linuxdj.com -'On Sat, 18 Nov 2000, Brent Schartung wrote: