OpenGL and SDL

Hey all,

I’m thinking of spending some time learning some 3D programming and the math
neede this summer, and make a small game in the prosess.

Now, OpenGL looks like the easiest and best option, and I also want
portability to my Mac, and PC running Linux and Windows, so SDL cought my
attention…

Now, just a few lazy questions about SDL and OPenGL combined:

  • Will I able to blit normal SDL surfaces on top of the OpenFL surface, for
    elements such as a self-defined GUI and informative text?
  • Does OpenGL run at full speed trough SDL? (HW.accl. included)
  • Is the full level of accelerated OpenGL available in the Mac version of
    SDL? (I remember last year, I think, when SDL was just capable of a few of
    the things on the Mac that it’s PC version could).

Thanks in advance (:

Mvh:

  • Knut S.
  • Does OpenGL run at full speed trough SDL? (HW.accl. included)

Yes. Every platform has nonportable code that gets an OpenGL
window/surface/screen/whatever created. On Linux, this is called glX. On
windows, this is wgl. OS/2 uses an API called PGL…the vast majority of
the OpenGL program is identical on each of these systems, but window
setup, configuration, buffer swapping, etc are all very platform
dependent.

What SDL does is wrap all that nonsense into a portable API. Once the
setup of the rendering context is done, the OpenGL calls are just your
system’s usual GL library…hardware acceleration included, if you’ve got
it configured correctly.

–ryan.

<traditional_back_in_my_days_crap>

Well, people like me, who learned programming the hard way, long before
visual RAD tools, usable 3D APIs, h/w accelerated blitting etc, usually say

"To learn 3D programming from the ground up, you should start by
 doing *everything* yourself, just to understand how things work,
 and why 3D APIs are designed the way they are. That is; start by
 writing a simple software rasterizing 3D engine."

(This is probably another way of saying “back when I learned this, it was
damn hard - it must be a Bad Thing ™ that it’s so easy nowadays!” :wink:

However, things are different now. 3D acceleration changes the rules quite a
bit. We’re actually talking about asymetric multiprocessor systems, and the
graphics processors on most 3D cards do things quite differently from a
software rasterizer.

ConclusionOn Wednesday 16 May 2001 14:04, Knut S. ?bj?rsbr?ten wrote:

Hey all,

I’m thinking of spending some time learning some 3D programming and the
math neede this summer, and make a small game in the prosess.

Now, OpenGL looks like the easiest and best option, and I also want
portability to my Mac, and PC running Linux and Windows, so SDL cought my
attention…


Sure, you can still learn a lot by writing a software engine, but if you want
to understand OpenGL, Direct3D or Glide programming that way, you should
probably write your own 3D accelerator driver as a next step! heh

Knowing a bit about how 3D accelerators and drivers do stuff is a good idea,
though. Makes it easier to understand why 3D APIs do some things in seemingly
strange ways.

</traditional_back_in_my_days_crap>

Now, just a few lazy questions about SDL and OPenGL combined:

  • Will I able to blit normal SDL surfaces on top of the OpenFL surface, for
    elements such as a self-defined GUI and informative text?

Whether or not this works the way you want, it’s not a good idea. Mixing 2D
and 3D acceleration is dog slow on some hardware, drivers and APIs, and
mixing h/w acceleration and direct (CPU) access to VRAM has similar problems.

(This is indeed one of those “strange” things with 3D acceleration… The
reason is that 3D acceleration is done asynchronously, using a "command FIFO"
between the CPU and the GPU. The side effect as that you have to make sure
the FIFO is empty and that no GPU operation is going on before you can access
the VRAM, or [on some hardware and drivers] switch between 2D and 3D mode.)

  • Does OpenGL run at full speed trough SDL? (HW.accl. included)

Yes. (SDL doesn’t “wrap” the OpenGL API or anything; it just manages
initialization of the screen.)

  • Is the full level of accelerated OpenGL available in the Mac version of
    SDL? (I remember last year, I think, when SDL was just capable of a few of
    the things on the Mac that it’s PC version could).

AFAIK, OpenGL as well as most (all?) other features work on Mac OS now.

And if OpenGL works at all, it works just as well as if you were initializing
it “manually”, without SDL. Should work fine, that is. :slight_smile:

Note: I don’t use or develop for Mac OS personally, so I don’t know much more
about SDL/MacOS specific stuff than what I’ve seen on this list. (Just
in case I should be totally wrong, or something! :wink:

//David

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

“Knut S. ?bj?rsbr?ten” wrote:

Hey all,

I’m thinking of spending some time learning some 3D programming and the math
neede this summer, and make a small game in the prosess.

Now, OpenGL looks like the easiest and best option, and I also want
portability to my Mac, and PC running Linux and Windows, so SDL cought my
attention…

Now, just a few lazy questions about SDL and OPenGL combined:

  • Will I able to blit normal SDL surfaces on top of the OpenFL surface, for
    elements such as a self-defined GUI and informative text?

You probably could, but you’re probably much better off doing all the
drawing through OpenGL.
Advantages:

  • You can take advantage of hardware blending support (eg
    transparancy/alpha channel)
  • You don’t have to worry about physical pixel size (eg you don’t have
    to worry about text being too small to read when you run in 1024x768).
    GL will do the required scaling for you.
  • You don’t stall the graphics pipeline by accessing the framebuffer
    pixels directly. It’s generally best (for performance reasons) to treat
    the graphics hardware as write-only.
  • You can use standard transformations for doing effects on your GUI. As
    an example, the GUI could shrink and contract depending on how much
    usful information it was displaying.

Ben.