Software substitue for GL was, Re: OpenGL / SDL / GUI / Movie :-)

Charles Wardlaw wrote:

— Atrix Wolfe wrote:

most of that i cant answer, i do know however that you cant use SDL
2d drawing routines when you set GL mode. There are GL techniques
and functions to draw 2d but because of how GL works internaly, it
cant give you normal access to the video buffer when its initialized.

Has there been any talk of an invisible framework of 2D drawing
function replacements when you use OpenGL under SDL? For instance,
SDL_Init() would set up functions invisibly using function pointers,
etc. I’ve seen similar trickery done other places.

To completely replace OpenGL would require that SDL include a software
implementation of OpenGL. I personally, think that is a little extreme.
I do, however, think that it would be reasonable to define a set of 2D
graphic functions that is fairly small, but higher level than the
current SDL graphic functions that could be implemented in software and
layered on top of both OpenGL, and DirectX.

I would worry about the slow down that you would see when you moved code
based on a 2D API when you ran it on a machine without hardware
acceleration. And, I think a layer like that would go against the SDL,
lean and mean, keep it simple, philosophy.

	Bob Pendleton> 
  • Charles

Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com


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


±-----------------------------------+

  • Bob Pendleton, consultant for hire +
  • Resume: http://www.jump.net/~bobp +
  • Email: @Bob_Pendleton +
    ±-----------------------------------+

— Bob Pendleton wrote:

To completely replace OpenGL would require that SDL include a
software
implementation of OpenGL. I personally, think that is a little
extreme.
I do, however, think that it would be reasonable to define a set of
2D
graphic functions that is fairly small, but higher level than the
current SDL graphic functions that could be implemented in software
and
layered on top of both OpenGL, and DirectX.

Exactly. I didn’t mean to include a software replacement for OpenGL as
a part of SDL; rather, I was indicating a desire for accelerated 2D SDL
functions that use OpenGL when available. When not available, vanilla
SDL would still be used.

And, I think a layer like that would go against the SDL,
lean and mean, keep it simple, philosophy.

I disagree, but I’m not the author. ^.^ Personally, I’d like to see
SDL Image and SDL Mixer merged into the main library. ducks I think
that simplicity is good, but not at the cost of ease of use. OpenGL
happens to be on almost every platform under the sun by default these
days, and platforms with hardware acceleration would definitely see a
speed benefit if 3D cards were taken advantage of. However, I’m just
idly chatting now, as such a feat is well beyond the scope of my
programming ability. And glSDL is an interesting project in the vein
of what I had in mind.

  • Charles__________________________________________________
    Do You Yahoo!?
    Yahoo! Finance - Get real-time stock quotes
    http://finance.yahoo.com

As I understand it, SDL_mixer is about to be replaced with something
based on SDL_sound. As much as I understand the benifits of modularity,
I do see how all these little libraries can be annoying to developers
and worse for users… Perhaps it would be possible to (on Windows at
least) keep the APIs seperate, but release an official .dll that
contains all of the most-used SDL libraries in one file… any thoughts
on that?

-LorenOn Mon, 2002-08-26 at 14:17, Charles Wardlaw wrote:

I disagree, but I’m not the author. ^.^ Personally, I’d like to see
SDL Image and SDL Mixer merged into the main library. ducks I think
that simplicity is good, but not at the cost of ease of use. OpenGL
happens to be on almost every platform under the sun by default these
days, and platforms with hardware acceleration would definitely see a
speed benefit if 3D cards were taken advantage of. However, I’m just
idly chatting now, as such a feat is well beyond the scope of my
programming ability. And glSDL is an interesting project in the vein
of what I had in mind.

Why dont we just use Mesa? Mesa “isnt” opengl, and includes a half way decent software renderer. It isnt really fast, but software never is.On 26-Aug-2002, Bob Pendleton wrote:

Charles Wardlaw wrote:

— Atrix Wolfe wrote:

most of that i cant answer, i do know however that you cant use SDL
2d drawing routines when you set GL mode. There are GL techniques
and functions to draw 2d but because of how GL works internaly, it
cant give you normal access to the video buffer when its initialized.

Has there been any talk of an invisible framework of 2D drawing
function replacements when you use OpenGL under SDL? For instance,
SDL_Init() would set up functions invisibly using function pointers,
etc. I’ve seen similar trickery done other places.

To completely replace OpenGL would require that SDL include a software
implementation of OpenGL. I personally, think that is a little extreme.
I do, however, think that it would be reasonable to define a set of 2D
graphic functions that is fairly small, but higher level than the
current SDL graphic functions that could be implemented in software and
layered on top of both OpenGL, and DirectX.

I would worry about the slow down that you would see when you moved code
based on a 2D API when you ran it on a machine without hardware
acceleration. And, I think a layer like that would go against the SDL,
lean and mean, keep it simple, philosophy.

  Bob Pendleton
  • Charles

Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com


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


±-----------------------------------+


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


Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989

— Bob Pendleton wrote:

[…s/w OpenGL…]
Exactly. I didn’t mean to include a software replacement for OpenGL as
a part of SDL; rather, I was indicating a desire for accelerated 2D SDL
functions that use OpenGL when available. When not available, vanilla
SDL would still be used.

And, I think a layer like that would go against the SDL,
lean and mean, keep it simple, philosophy.

I disagree, but I’m not the author. ^.^ Personally, I’d like to see
SDL Image and SDL Mixer merged into the main library.

throws the first hard object within reach at Charles

ducks

Well, I’d rather not have to load two audio engines… (Can’t stay
away from DSP stuff, so I’m rolling my own. :slight_smile:

I think
that simplicity is good, but not at the cost of ease of use.

Yeah, but these things don’t really compare. Audio mixing can easilly
be built on top of the low level SDL audio API, whereas transparent
SDL 2D rendering over OpenGL or DirectX cannot, and thus has to be
implemented as a part of SDL. (Or as a separate library, using a
different API - but that sort of misses the target, unless it’s
implementing a higher level API, as well as a software rendering
fallback…)

OpenGL
happens to be on almost every platform under the sun by default these
days, and platforms with hardware acceleration would definitely see a
speed benefit if 3D cards were taken advantage of.

…and for those without acceleration, custom s/w rendering code is a must. Just try to run even the simplest OpenGL application (be it 2D or 3D - never seen an implementation with shortcuts for simple 2D blits) using a s/w OpenGL driver on any platform, and you’ll get the idea. heh

However, I’m just
idly chatting now, as such a feat is well beyond the scope of my
programming ability. And glSDL is an interesting project in the vein
of what I had in mind.

Well, if (almost completely) transparent portable h/w acceleration of
SDL rendering calls is what you want, glSDL probably is (or rather,
will be) what you’re looking for. (Not much hacking time lately, but
there is some progress.)

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn Mon, 26/08/2002 14:17:57 , Charles Wardlaw wrote:

That could be handy - although I don’t quite see what difference a
few files more or less will do in binary distro… And the majority
of gamers don’t even get the tools to build from source with their
OS, so the “getting developer packages for all libs” deal is not
really an issue, IMHO.

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn 26/08/2002 14:42:24 , Loren Osborn <linux_dr at yahoo.com> wrote:

On Mon, 2002-08-26 at 14:17, Charles Wardlaw wrote:

[…merging SDL_Mixer into SDL…]

As I understand it, SDL_mixer is about to be replaced with something
based on SDL_sound. As much as I understand the benifits of modularity,
I do see how all these little libraries can be annoying to developers
and worse for users… Perhaps it would be possible to (on Windows at
least) keep the APIs seperate, but release an official .dll that
contains all of the most-used SDL libraries in one file… any thoughts
on that?

Software can be quite fast enough for playable 3D games (Wolfenstein
3D, Doom, Duke Nukem 3D, Quake…), but that’s not the case with
any truly OpenGL compatible implementation I know of. The CPU power
required for real time OpenGL without countless shortcuts is still
far beyond that of your average PC.

That said, software OpenGL could be handy for install time or load
time rendering of graphics - but why not just use Mesa directly for
such applications? (Possibly with the option to use OpenGL through
SDL if available. If you dare trust it to render accurately
enough, that is…)

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn Tue, 27/08/2002 08:48:08 , Patrick McFarland wrote:

Why dont we just use Mesa? Mesa “isnt” opengl, and includes a half
way decent software renderer. It isnt really fast, but software
never is.

As I see it, the problem is that all these libraries are in seperate
packages. Distributions often have recent SDL packages, but not so recent
(or even lacking) SDL_net, SDL_sound, SDL_whatever packages.
In fact, I have more than once decided not to use these libraries for this
exact reason (which is really a shame).

The easiest way to fix this is to put the most important additional
libraries (SDL_net, SDL_mixer/SDL_sound and SDL_image are referenced the
most I think) into the main SDL source package, so distributors can’t
"forget" about them.

If you’re worried about loading unnecessary libraries at run-time - well, it
would still be possible to build seperate SDL, SDL_sound, etc… libraries
from that One Source Package.

Granted that’s a bit quirky, but IMO it’s the best way to solve the library
mess that normal users encounter.

cu,
NicolaiOn Tuesday 27 August 2002 15:47, David Olofson wrote:

On 26/08/2002 14:42:24 , Loren Osborn <linux_dr at yahoo.com> wrote:

On Mon, 2002-08-26 at 14:17, Charles Wardlaw wrote:

[…merging SDL_Mixer into SDL…]

As I understand it, SDL_mixer is about to be replaced with something
based on SDL_sound. As much as I understand the benifits of modularity,
I do see how all these little libraries can be annoying to developers
and worse for users… Perhaps it would be possible to (on Windows at
least) keep the APIs seperate, but release an official .dll that
contains all of the most-used SDL libraries in one file… any thoughts
on that?

That could be handy - although I don’t quite see what difference a
few files more or less will do in binary distro… And the majority
of gamers don’t even get the tools to build from source with their
OS, so the “getting developer packages for all libs” deal is not
really an issue, IMHO.

Patrick McFarland wrote:

Why dont we just use Mesa? Mesa “isnt” opengl, and includes a half way decent software renderer. It isnt really fast, but software never is.

I don’t see the point. If your game needs 3D it probably needs hardware
acceleration. If it is 2D then you don’t want the code weight of a
complete 3D package which won’t accelerate 2D operations. It seems like
going through Mesa to get to a 2D blitter is not going to be faster than
just using a 2D software blit directly.

Like I said, I like the idea of a simple minimal 2D API that can use
OpenGL or DirectX if it is there but is also fully implemented in
software. But, while I like the idea I’m not sure that it is
reasonable to add this to SDL.

The hard part of designing a graphics API is knowing when to stop.
Nothing grows bells, whistles, and warts, like a graphics API.

	Bob Pendleton> On 26-Aug-2002, Bob Pendleton wrote:

Charles Wardlaw wrote:

— Atrix Wolfe wrote:

most of that i cant answer, i do know however that you cant use SDL
2d drawing routines when you set GL mode. There are GL techniques
and functions to draw 2d but because of how GL works internaly, it
cant give you normal access to the video buffer when its initialized.

Has there been any talk of an invisible framework of 2D drawing
function replacements when you use OpenGL under SDL? For instance,
SDL_Init() would set up functions invisibly using function pointers,
etc. I’ve seen similar trickery done other places.

To completely replace OpenGL would require that SDL include a software
implementation of OpenGL. I personally, think that is a little extreme.
I do, however, think that it would be reasonable to define a set of 2D
graphic functions that is fairly small, but higher level than the
current SDL graphic functions that could be implemented in software and
layered on top of both OpenGL, and DirectX.

I would worry about the slow down that you would see when you moved code
based on a 2D API when you ran it on a machine without hardware
acceleration. And, I think a layer like that would go against the SDL,
lean and mean, keep it simple, philosophy.

  Bob Pendleton
  • Charles

Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com


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


±-----------------------------------+

  • Bob Pendleton, consultant for hire +
  • Resume: http://www.jump.net/~bobp +
  • Email: @Bob_Pendleton +
    ±-----------------------------------+

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


±-----------------------------------+

  • Bob Pendleton, consultant for hire +
  • Resume: http://www.jump.net/~bobp +
  • Email: @Bob_Pendleton +
    ±-----------------------------------+