Recent

Author Topic: SDL vs OpenGL  (Read 56213 times)

Graeme

  • Hero Member
  • *****
  • Posts: 1428
    • Graeme on the web
SDL vs OpenGL
« on: January 24, 2017, 08:04:29 pm »
I’ve been reading up on 3D graphics and looking into game engine logic. This brought me to SDL. Could somebody confirm or correct my understanding of SDL+OpenGL.

1) From what I can see from SDL’s website, is that if you combine SDL with OpenGL in a application, you must run the application full-screen? Surely this is not good.

2) I thought SDL is a cross-platform wrapper framework over software rendering, OpenGL and DirectX. But from the sample code I viewed, it seems not to be the case. eg: You still need to call the OpenGL API’s directly in your SDL+OpenGL application. So why bother with SDL then?

3) What exact advantage does SDL actually give (if you decide to use OpenGL graphics acceleration)? Does it  incorporate the other parts like user input, application loop and sound. Though you get OpenAL (family member of OpenGL), so I guess if you use OpenAL with SDL, you will have to call the OpenAL API’s directly too, just like you do for OpenGL.

So again, what benefit is there in actually using SDL at all? I guess going the direct route of only using OpenGL and OpenAL seems better, and cuts out one extra dependency.

Did I understand this correctly, or am I simply not understanding the point of SDL at all?
« Last Edit: January 24, 2017, 08:06:38 pm by Graeme »
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

lainz

  • Hero Member
  • *****
  • Posts: 4468
    • https://lainz.github.io/
Re: SDL vs OpenGL
« Reply #1 on: January 24, 2017, 08:41:49 pm »
SDL helps you to code with easy to use functions, you don't need to know OpenGL to use it. But you get the benefit of a hardware accelerated 2D application.

Is like you can do with BGRABitmap OpenGL units, is a set of things that helps you to make an OpenGL application, with no coding of OpenGL stuff directly.

And yes, it contains input and more stuff.

mischi

  • Full Member
  • ***
  • Posts: 170
Re: SDL vs OpenGL
« Reply #2 on: January 24, 2017, 08:43:31 pm »
I am not really an expert on SDL and OpenGL, but let me point you to ultrastardx, which uses SDL and OpenGL. Besides that the game window can be scaled to different sizes or blown up to fullScreen I cannot tell much. Maybe you can find some answers by looking at the code. Regarding the choice for SDL, i should mention that the game was started before OpenAL was available. Therefore, it could well be worth to look into OpenAL.

MiSchi

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11453
  • FPC developer.
Re: SDL vs OpenGL
« Reply #3 on: January 24, 2017, 09:15:30 pm »
I assume SDL also acts as a kind of GLUT for OpenGL.

i.e. Opengl has very basic primitives and no helpers (e.g. loading a picture must be done by other means)

But a lot of that is initial work only, and the dglopengl header has some extra supporting features for e.g. opengl profile initialization.

An overview of my opengl work is in the signed distance font topic.

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: SDL vs OpenGL
« Reply #4 on: January 24, 2017, 09:27:15 pm »
1) From what I can see from SDL’s website, is that if you combine SDL with OpenGL in a application, you must run the application full-screen?
Where did you find it? Making OpenGL itself is not bound to being full-screen or windowed.

2) I thought SDL is a cross-platform wrapper framework over software rendering, OpenGL and DirectX. But from the sample code I viewed, it seems not to be the case. eg: You still need to call the OpenGL API’s directly in your SDL+OpenGL application. So why bother with SDL then?
(btw, you want to add OpenGLES to that list too.)
SDL itself provides wrappers to easily initialize the rendering.
It also provides some wrappers to draw 2d graphics. None 3d graphics at all. Thus if you'd need a 3d you'll need to make GL api calls yourself.

3) What exact advantage does SDL actually give (if you decide to use OpenGL graphics acceleration)? Does it  incorporate the other parts like user input, application loop and sound.
It does handles user input loop and sound. Though for sound I'd recommend to use SDL_Mixer. (SDL extension).

Though you get OpenAL (family member of OpenGL), so I guess if you use OpenAL with SDL, you will have to call the OpenAL API’s directly too, just like you do for OpenGL.
No. OpenAL, is not a family member of OpenGL. Despite of the fashioned "Open" prefix.
SDL as well might be using more system native APIs (i.e. DirectSound) rather than OpenAL.
No direct calls to OpenAL (or underlying sound api) are needed.

So again, what benefit is there in actually using SDL at all?
It safes a lot of time dealing with system specific routines (loop, input, rendering,audio).

SDL extensions also help you to load both different Image file formats as well as Audio file formats.
Neither OpenGL nor OpenAL have any functionality to do that, they only expect raw data (scan lines of pixels or uncompressed wave forms)
« Last Edit: January 24, 2017, 09:32:31 pm by skalogryz »

Graeme

  • Hero Member
  • *****
  • Posts: 1428
    • Graeme on the web
Re: SDL vs OpenGL
« Reply #5 on: January 24, 2017, 09:35:11 pm »
Thanks for the info thus far. So from what I can deduce is that GLUT is a “helper library” for extra things that OpenGL doesn’t do directly. OpenGL is only graphics rendering.

As for SDL. I guess I was under the wrong impression of what it does. I thought it would automatically select the best rendering option available on my system. I looked at an SDL sample that renders a 320x200 animation - a 3D looking tunnel effect. Flying though a tunnel made out of boxes. It was very smooth, and used raycasting from what I can see. I then modified the demo to run at 800x600 and it became choppy as hell. So clearly everything was done via software rendering (via the CPU) and no hardware acceleration (GPU).

This is where I’m getting confused about SDL. I thought there is some switch or parameter I can pass the initialization API call to tell it to use hardware acceleration. But from the SDL+OpenGL examples I could find (not the flying box tunnel I referred to earlier), they all seem to initialize and use OpenGL via actual OpenGL APIs - not SDL API. Yet it is a sdl application.

Here is a simple snippet of SDL+OpenGL I found
Code: C++  [Select][+][-]
  1.     /* This makes our buffer swap syncronized with the monitor’s vertical refresh */
  2.     SDL_GL_SetSwapInterval(1);
  3.  
  4.     /* Clear our buffer with a red background */
  5.     glClearColor ( 1.0, 0.0, 0.0, 1.0 );
  6.     glClear ( GL_COLOR_BUFFER_BIT );
  7.     /* Swap our back buffer to the front */
  8.     SDL_GL_SwapWindow(mainwindow);
  9.  

The first and last API calls are clearly SDL ones. But the “what to render” code is pure OpenGL API calls.

Maybe the examples I’m looking at are bad ones. I’ll keep searching the net.
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

Graeme

  • Hero Member
  • *****
  • Posts: 1428
    • Graeme on the web
Re: SDL vs OpenGL
« Reply #6 on: January 24, 2017, 09:43:00 pm »
1) From what I can see from SDL’s website, is that if you combine SDL with OpenGL in a application, you must run the application full-screen?
Where did you find it? Making OpenGL itself is not bound to being full-screen or windowed.

I’ll try and find that information again. But I remember clearly reading that if you use SDL+OpenGL on a X11 system (Linux, FreeBSD etc) then the application needs to be fullscreen, otherwise hardware acceleration doesn’t work. I thought this weird though, because the well known glxgears demo included with many X11 systems run hardware accelerated in a window.

Quote
It safes a lot of time dealing with system specific routines (loop, input, rendering,audio).
SDL extensions also help you to load both different Image file formats as well as Audio file formats.

Ah, okay.

Many thanks for all the very useful information. I’ll keep exploring with SDL and see how it goes.
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

Graeme

  • Hero Member
  • *****
  • Posts: 1428
    • Graeme on the web
Re: SDL vs OpenGL
« Reply #7 on: January 24, 2017, 09:45:13 pm »
By the way, is GLU (OpenGL Utilitilies) and GLUT the same thing?
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: SDL vs OpenGL
« Reply #8 on: January 24, 2017, 09:46:15 pm »
The first and last API calls are clearly SDL ones. But the “what to render” code is pure OpenGL API calls.
Yet again, for 3d - you'll have to use OpenGL calls, since SDL doesn't provide any counterparts.
For 2d, you can easily go with SDL only and achieve results like this:

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: SDL vs OpenGL
« Reply #9 on: January 24, 2017, 09:48:11 pm »
By the way, is GLU (OpenGL Utilitilies) and GLUT the same thing?
No :)

Graeme

  • Hero Member
  • *****
  • Posts: 1428
    • Graeme on the web
Re: SDL vs OpenGL
« Reply #10 on: January 24, 2017, 10:08:58 pm »
@skalogryz: Many thanks for that link explaining all the terms. That was super useful! :)
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: SDL vs OpenGL
« Reply #11 on: January 24, 2017, 10:12:22 pm »
I then modified the demo to run at 800x600 and it became choppy as hell. So clearly everything was done via software rendering (via the CPU) and no hardware acceleration (GPU).
Maybe you don't have proper drivers?
or it might be a conflict in Windows, where you need to have (or instead not to have) the manifest.

jmpessoa

  • Hero Member
  • *****
  • Posts: 2301
Re: SDL vs OpenGL
« Reply #12 on: January 24, 2017, 10:12:54 pm »
Lamw: Lazarus Android Module Wizard
https://github.com/jmpessoa/lazandroidmodulewizard

lainz

  • Hero Member
  • *****
  • Posts: 4468
    • https://lainz.github.io/
Re: SDL vs OpenGL
« Reply #13 on: January 24, 2017, 10:24:59 pm »
I then modified the demo to run at 800x600 and it became choppy as hell. So clearly everything was done via software rendering (via the CPU) and no hardware acceleration (GPU).
Maybe you don't have proper drivers?
or it might be a conflict in Windows, where you need to have (or instead not to have) the manifest.

SDL has both software and hardware, maybe the demo is for software only.

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: SDL vs OpenGL
« Reply #14 on: January 24, 2017, 10:48:21 pm »
SDL has both software and hardware, maybe the demo is for software only.
I seriously doubt that OpenGL functions called are declared in SDL headers.
Whenever an opengl routine is called, they are executed by the system.

The only issue with SDL that could be - it failed to find hardware accelerated descriptor.
However, Windows itself might cause the issue, because of the manifest settings and it might prevent an application from getting the hardware accelerated interface.

 

TinyPortal © 2005-2018