OpenGL or not?

In my quest to learn game programming and SDL, I want to create a
top-down racing game (sort of like SuperSprint from the Atari and
arcades).

I’ve been reading all the fun about how X doesn’t give you hardware
surfaces, and timing problems, etc.

I’ve also read you can make OpenGL do 2D projections, and something
about making your games out of lots of quads (or triangles).

Does anyone have any recommendations on which I should use? Plain old
2D stuff, or OpenGL?–
The Christmas Pangeant does not stink
6AD6 865A BF6E 76BB 1FC2 | www.piku.org.uk/public-key.asc
E4C4 DEEA 7D08 D511 E149 | www.piku.org.uk wnzrf at cvxh.bet.hx (rot13’d)

If you think of doing it right like on those old machines, then OpenGL
would be something like your videochip, so I’d recommend you use it!
St0fF.

At 23:07 17.03.2002 +0000, you wrote:>In my quest to learn game programming and SDL, I want to create a

top-down racing game (sort of like SuperSprint from the Atari and
arcades).

I’ve been reading all the fun about how X doesn’t give you hardware
surfaces, and timing problems, etc.

I’ve also read you can make OpenGL do 2D projections, and something
about making your games out of lots of quads (or triangles).

Does anyone have any recommendations on which I should use? Plain old
2D stuff, or OpenGL?


The Christmas Pangeant does not stink
6AD6 865A BF6E 76BB 1FC2 | www.piku.org.uk/public-key.asc
E4C4 DEEA 7D08 D511 E149 | www.piku.org.uk wnzrf at cvxh.bet.hx (rot13’d)


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

In my quest to learn game programming and SDL, I want to create a
top-down racing game (sort of like SuperSprint from the Atari and
arcades).

Cool. :slight_smile:

I’ve been reading all the fun about how X doesn’t give you hardware
surfaces, and timing problems, etc.

Actually, it’s not as bad as it may sound - as some people don’t even
seem no notice the difference!

You have to know that a few of the persons discussing this (me included)
have extremely high demands on smoothness in animation, compared to the
current standards.

Call us “relics of the PAL/NTSC graphics era” or whatever - I still
maintain my position that things should improve over time, not the
other way around.

I’ve also read you can make OpenGL do 2D projections, and something
about making your games out of lots of quads (or triangles).

Actually, OpenGL solves only one of those problems: Speed. Still no
retrace sync.

Oh, and, you have no use for h/w surfaces (“SDL style”) with OpenGL
anyway, as the driver will do all the rendering for you, whether or not
you can touch the screen with the CPU. (Which you definitely should not
do anyway, if you can avoid it! Blitting from a h/w surface is
especially slow.)

Does anyone have any recommendations on which I should use? Plain old
2D stuff, or OpenGL?

If you don’t know your ways around OpenGL, it might be a good idea to use
SDL’s 2D operations for starters. They’re easy to use, and provide quite
decent speed, as long as you stick with sensible resolutions, or minimize
the screen area you update every frame.

You could throw in glSDL just to get an idea of the speed you could get
with “real” OpenGL, you could wait until I manage to turn it into a real
backend. Both options mean trivial, if any changes to your code - SDL
blitting still works as usual, although the work is in fact done by the
OpenGL driver.

Eventually, you could consider adding “real” OpenGL support. Provided
your code is reasonably well structured, this shouldn’t be too hard - but
of course, you have to ask yourself if it’s really worth the effort.

Note that SDL does support alpha blending, so you don’t really need
OpenGL for that - unless you’re going to do it all over the screen. (It’s
not h/w accelerated without glSDL, and thus it’s a great deal slower than
normal blitting.)

Also note that traditional “sprite” style blitting (pixels either opaque
or invisible) costs virtually nothing extra with SDL’s software blitters,
thanks to the RLE acceleration. It’s just as fast as plain rectangular
blitting, for all practical reasons.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Monday 18 March 2002 00:07, James wrote:

Actually, that’s a good point. The stuff that glSDL does internally
does in some way remind me of what you had to do to get the Amiga
blitter going… :slight_smile:

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Monday 18 March 2002 02:22, St0fF 64 wrote:

If you think of doing it right like on those old machines, then OpenGL
would be something like your videochip, so I’d recommend you use it!
St0fF.

| On Monday 18 March 2002 00:07, James wrote:
| > In my quest to learn game programming and SDL, I want to create a
| > top-down racing game (sort of like SuperSprint from the Atari and
| > arcades).
|
| Cool. :slight_smile:
|

I think it’ll be fun to try. I’m just no good at drawing graphics, so
is there anywhere that offers free graphics I can use? I eventually
found Spritelib, which appears to have been abandoned by its creator,
but I’d need tiles for the road and stuff.

| > I’ve been reading all the fun about how X doesn’t give you hardware
| > surfaces, and timing problems, etc.
|
| Actually, it’s not as bad as it may sound - as some people don’t even
| seem no notice the difference!

I wrote a really simple Snake game, and there’s a noticeable 'jerk’
every few seconds. That’s the Linux scheduler doing its thing, isn’t
it?

| You have to know that a few of the persons discussing this (me included)
| have extremely high demands on smoothness in animation, compared to the
| current standards.

Yeah, I’ve seen the Amiga demos that show full-screen smooth scrolling
too :slight_smile:

| Call us “relics of the PAL/NTSC graphics era” or whatever - I still
| maintain my position that things should improve over time, not the
| other way around.

Well things should improve. If a cranky old Atari ST with a 16Mhz cpu
can draw smooth animations, so should my 500Mhz Celeron.

|
| > I’ve also read you can make OpenGL do 2D projections, and something
| > about making your games out of lots of quads (or triangles).
|
| Actually, OpenGL solves only one of those problems: Speed. Still no
| retrace sync.

The NVIDIA drivers (which have now a nasty habit of totally crashing my
PC every morning) have a retrace-sync environment variable you can set.

| > Does anyone have any recommendations on which I should use? Plain old
| > 2D stuff, or OpenGL?
|
| If you don’t know your ways around OpenGL, it might be a good idea to use
| SDL’s 2D operations for starters. They’re easy to use, and provide quite
| decent speed, as long as you stick with sensible resolutions, or minimize
| the screen area you update every frame.

I think I’ll try normal 2D SDL. At least until NVIDIA fix their X
server. 640x480x8bit is a sensible resolution, isn’t it?

I’ll have a look on Amazon for some of those books I’ve seen mentioned
here. I’m not after one full of code, I can already program, I like to
know why I’m using a particular algorithm or technique instead…On Tue, Mar 19, 2002 at 02:51:34AM +0100, David Olofson wrote:


I did not see Elvis
6AD6 865A BF6E 76BB 1FC2 | www.piku.org.uk/public-key.asc
E4C4 DEEA 7D08 D511 E149 | www.piku.org.uk wnzrf at cvxh.bet.hx (rot13’d)

| On Monday 18 March 2002 00:07, James wrote:
| > In my quest to learn game programming and SDL, I want to create a
| > top-down racing game (sort of like SuperSprint from the Atari and
| > arcades).
|
| Cool. :slight_smile:
|

I think it’ll be fun to try. I’m just no good at drawing graphics, so
is there anywhere that offers free graphics I can use? I eventually
found Spritelib, which appears to have been abandoned by its creator,
but I’d need tiles for the road and stuff.

I’m not sure the original SuperSprint was tiled really. In any case, if the
whole track will fit on the screen at once like the original, you could just
get away with one big background image instead and not worry about the
tiling stuff. Assuming 2D at least, and not OpenGL.

| > I’ve been reading all the fun about how X doesn’t give you hardware
| > surfaces, and timing problems, etc.
|
| Actually, it’s not as bad as it may sound - as some people don’t even
| seem no notice the difference!

I wrote a really simple Snake game, and there’s a noticeable 'jerk’
every few seconds. That’s the Linux scheduler doing its thing, isn’t
it?

Could be. Could be something else too. If other games show this kind of
behavior, that ya, probably is.

| Call us “relics of the PAL/NTSC graphics era” or whatever - I still
| maintain my position that things should improve over time, not the
| other way around.

Well things should improve. If a cranky old Atari ST with a 16Mhz cpu
can draw smooth animations, so should my 500Mhz Celeron.

You’d think so, huh? So many improvements in technology, yet so hard to
accomplish what was so common in the past? Seems kinda strange to me
personally.

| > Does anyone have any recommendations on which I should use? Plain old
| > 2D stuff, or OpenGL?
|
| If you don’t know your ways around OpenGL, it might be a good idea to
use
| SDL’s 2D operations for starters. They’re easy to use, and provide quite
| decent speed, as long as you stick with sensible resolutions, or
minimize
| the screen area you update every frame.

I think I’ll try normal 2D SDL. At least until NVIDIA fix their X
server. 640x480x8bit is a sensible resolution, isn’t it?

Ya. Could go with 16 bit instead, and then you wouldn’t need to bother with
the hassles of palettes. SuperSprint was a game I remember having
exceptionally high resolution for it’s time, though, so maybe you should go
with really high resolution too maybe. :slight_smile: If most of the screen is static
anyway, shouldn’t present a problem, since you don’t have to update very
much of it each frame.

I’ll have a look on Amazon for some of those books I’ve seen mentioned
here. I’m not after one full of code, I can already program, I like to
know why I’m using a particular algorithm or technique instead…

Heh, you should look at a problem and select an algorithm for it, rather
than use an algorithm and try and figure out why you are using it.

-Jason

----- Original Message -----
From: james@piku.org.uk (James)
To:
Sent: Tuesday, March 19, 2002 4:39 AM
Subject: Re: [SDL] OpenGL or not?
On Tue, Mar 19, 2002 at 02:51:34AM +0100, David Olofson wrote:

At 03:20 19.03.2002 +0100, you wrote:

If you think of doing it right like on those old machines, then OpenGL
would be something like your videochip, so I’d recommend you use it!
St0fF.

Actually, that’s a good point. The stuff that glSDL does internally
does in some way remind me of what you had to do to get the Amiga
blitter going… :slight_smile:

Yes, and StateVariables remember me of VIC-Registers … also there are
parallels from the OGL-lighting-engine to the sprite-engine of the VIC …
if I looked deeper I’d probably find even more parallels …
So what are the main differences between VIC, Copper and OpenGL? Of course
it’s the age, the speed, and the functionality, so basically it’s the age!
St0fF.>On Monday 18 March 2002 02:22, St0fF 64 wrote:

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -’


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

[…]

| > I’ve been reading all the fun about how X doesn’t give you hardware
| > surfaces, and timing problems, etc.
|
| Actually, it’s not as bad as it may sound - as some people don’t even
| seem no notice the difference!

I wrote a really simple Snake game, and there’s a noticeable 'jerk’
every few seconds. That’s the Linux scheduler doing its thing, isn’t
it?

Probably. Depends a bit on what’s running in the background on your
system. (That is, what is being kept away from the CPU by your game -
until the scheduler decides it should be allowed to breathe.)

| You have to know that a few of the persons discussing this (me
| included) have extremely high demands on smoothness in animation,
| compared to the current standards.

Yeah, I’ve seen the Amiga demos that show full-screen smooth scrolling
too :slight_smile:

Well, I’ve actually seen that kind of stuff - including overscan
scrolling even on the C64.

Either way, both machines had hardware scrolling. We do not - but then
again, h/w scrolling is pretty limited anyway, unless you have multiple
layers like on some arcade machines and consoles. (Right the Amiga had
two, and could be “tricked” into generating a third layer, but that would
reduce depth to 8 colors… heh)

| Call us “relics of the PAL/NTSC graphics era” or whatever - I still
| maintain my position that things should improve over time, not the
| other way around.

Well things should improve. If a cranky old Atari ST with a 16Mhz cpu

8 MHz, actually. :slight_smile: (Well, I had an STE once…)

can draw smooth animations, so should my 500Mhz Celeron.

Yeah.

| > I’ve also read you can make OpenGL do 2D projections, and something
| > about making your games out of lots of quads (or triangles).
|
| Actually, OpenGL solves only one of those problems: Speed. Still no
| retrace sync.

The NVIDIA drivers (which have now a nasty habit of totally crashing my
PC every morning) have a retrace-sync environment variable you can set.

Yep, I know.

| > Does anyone have any recommendations on which I should use? Plain
| > old 2D stuff, or OpenGL?
|
| If you don’t know your ways around OpenGL, it might be a good idea to
| use SDL’s 2D operations for starters. They’re easy to use, and
| provide quite decent speed, as long as you stick with sensible
| resolutions, or minimize the screen area you update every frame.

I think I’ll try normal 2D SDL. At least until NVIDIA fix their X
server. 640x480x8bit is a sensible resolution, isn’t it?

Perhaps, but you have to be aware that

* ...you probably won't get 8 bits on most systems
  (more likely 16 or 32)

* ...that anything more than 8 bits in 640x480 will be
  rather slow on some platforms, including Linux, unless
  you can get away with updating less than about 50% of
  the screen area per frame.

* ...there's no way that 640x480 full screen animation
  will run at a playable speed on a Pentium [MMX].
  Celeron, P-II or better is needed.

* ...that alpha blending and 8 bit modes don't really
  mix. (It's theoretically *possible* of course, but
  AFAIK, SDL doesn't bother.)

320x240 reasonably fast on practically anything, but of course, it’s a
very low resolution for modern monitors, and some targets don’t even come
with such a mode. Has to be added manually by the user, or he/she will
have to put up with a small box in the center of a 640x480 screen.

That said, Kobo Deluxe is a 100% 320x240 game, and just scales the
320x240 graphics to higher resolutions. I can’t really recommend creating
a serious new game project with lots of graphics in 320x240 these days,
but for a smaller project, it’s an easy way to get decent speed on all
targets.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 19 March 2002 10:39, James wrote:

[…]

Well things should improve. If a cranky old Atari ST with a 16Mhz cpu
can draw smooth animations, so should my 500Mhz Celeron.

You’d think so, huh? So many improvements in technology, yet so hard
to accomplish what was so common in the past? Seems kinda strange to
me personally.

Two reasons, mainly:

1) The introduction of basic timesharing (ie not real time
   capable) multitasking operating systems in PCs.

2) Standard refresh rates going away.

However, CPU speed and OS improvements are reducing the effect of the
former, and there’s quite enough power in today’s video cards to deal
with the latter.

[…]

I think I’ll try normal 2D SDL. At least until NVIDIA fix their X
server. 640x480x8bit is a sensible resolution, isn’t it?

Ya. Could go with 16 bit instead, and then you wouldn’t need to bother
with the hassles of palettes. SuperSprint was a game I remember having
exceptionally high resolution for it’s time, though, so maybe you
should go with really high resolution too maybe. :slight_smile: If most of the
screen is static anyway, shouldn’t present a problem, since you don’t
have to update very much of it each frame.

Right. No scrolling ==> no problems, basically.

However, you do have to keep in mind that if you enable double buffering,
you have to keep track of both buffers (ie two frames back), rather
than just where your sprites were in the last frame.

I’ll have a look on Amazon for some of those books I’ve seen
mentioned here. I’m not after one full of code, I can already
program, I like to know why I’m using a particular algorithm or
technique instead…

Heh, you should look at a problem and select an algorithm for it,
rather than use an algorithm and try and figure out why you are using
it.

This kind of reminds me of the backwards way of thinking you’re exposed
to in school and uni sometimes… heh

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 19 March 2002 11:49, Jason Hoffoss wrote:

Suppose I have a threaded application that does not use SDL as such. It
does however have plugins that use SDL. This leads to multiple calls to
SDL_init all in the same address space.

Is it safe to call SDL_init() multiple times? What happens if it is
called with different options?

Is it ok if two calls to SDL_init() are made concurrently in different
threads?

– Arnar

Suppose I have a threaded application that does not use SDL as such. It
does however have plugins that use SDL. This leads to multiple calls to
SDL_init all in the same address space.

Not necessarily. You could check if SDL is already initialized by using
"SDL_WasInit".–
Qui e’ Jack Burton, del Pork-Chop Express,
che parla a chiunque sia in ascolto.

Good call. I was under the impression that such a function
didn’t exsist after reading this:

http://sdldoc.csn.ul.ie/sdlinit.php

“This should be called before all other SDL functions.”

It’s probably a good idea to add SDL_WasInit() under See Also.

– Arnar.

This should be called before all other SDL functions.On Tue, 19 Mar 2002, Jack Burton wrote:

Suppose I have a threaded application that does not use SDL as such. It
does however have plugins that use SDL. This leads to multiple calls to
SDL_init all in the same address space.

Not necessarily. You could check if SDL is already initialized by using
"SDL_WasInit".


Qui e’ Jack Burton, del Pork-Chop Express,
che parla a chiunque sia in ascolto.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL is not thread safe, and it does not support multiple windows. The
latter issue will probably be fixed in 1.3 (as a side effect of adding
multihead support), but I don’t know about the threading issue. A thread
safe library will nearly always be slower, and it’s much more complicated
to develop and maintain.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 19 March 2002 20:59, Arnar Mar Hrafnkelsson wrote:

Suppose I have a threaded application that does not use SDL as such.
It does however have plugins that use SDL. This leads to multiple
calls to SDL_init all in the same address space.

Is it safe to call SDL_init() multiple times? What happens if it is
called with different options?

Is it ok if two calls to SDL_init() are made concurrently in different
threads?