SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob PendletonOn Fri, Jan 6, 2012 at 9:53 PM, bala_48225 <bala_48225 at yahoo.com> wrote:

So far I haven’t used SDL 1.3, but as far as the proposed split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide multiple
    alpha blend modes for
    images, including multiply alpha, and 3) Provide something akin to SDL 1.2’s
    SDL_FillRect,
    perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t see why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------

Bob, I don’t think we’re quite ready to talk about this, unless you’re
talking about something you’d like to write and maintain separately from
SDL. :)On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton wrote:

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225 <bala_48225 at yahoo.com> wrote:

So far I haven’t used SDL 1.3, but as far as the proposed
split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide multiple
    alpha blend modes for
    images, including multiply alpha, and 3) Provide something akin to SDL
    1.2’s
    SDL_FillRect,
    perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t see
why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Guys,
I would suggest structuring it something similar to Qt’s
QGraphicsView/QGraphicsScene API. It is quite powerful, fairly simple to
understand, and a joy to use. Practically if not everything Bob has
mentioned is there. I dont use SDL for graphics anymore simply because
getting HW-accelerated graphics using SDL just simply isn’t “Simple”. I’ve
found the new Haptic API to be quite enjoyable, and I still use the
Joystick and SDL_mixer stuff, but the one thing that really excited me
about SDL2 that I was looking forward to was the HW Graphics API.

I’m probably reinventing the wheel (particularly wrt SDL2 renderers), but I
started writing a “simple” 2D abstraction lib for OpenGL and Direct3D. I’m
not going to link to it, since I think my last email with a link got lost
in moderation (we’ll probably see it in the next mailing burp).
Tentatively called SDL_gpu, you can find it on Google Code. I’d love help
with it in both design and implementation. However it works out, a library
on top of the core SDL is the way to go. I’m working off of SDL 1.2 right
now and it should be very easy to port to SDL2.

Any takers?

Jonny DOn Sun, Jan 8, 2012 at 4:15 AM, Jonathan Greig wrote:

Guys,
I would suggest structuring it something similar to Qt’s
QGraphicsView/QGraphicsScene API. It is quite powerful, fairly simple to
understand, and a joy to use. Practically if not everything Bob has
mentioned is there. I dont use SDL for graphics anymore simply because
getting HW-accelerated graphics using SDL just simply isn’t “Simple”. I’ve
found the new Haptic API to be quite enjoyable, and I still use the
Joystick and SDL_mixer stuff, but the one thing that really excited me
about SDL2 that I was looking forward to was the HW Graphics API.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Does SDL2 need any graphics support in it? It needs to be able to load
images, it needs to be able to do the kinds of image manipulation that
a graphics program needs to do to prepare images for use by a graphics
program, and it would be nice if it had helper functions to hand off
images to the OpenGL and DirectX and whatever other high level
graphics API you are using.

In my opinion, SDL2 should have functions to load and save images and
hand them off to OpenGL, DirectX, and what ever other high level
graphics APIs may be in use.

In my opinion, SDL2 should have enough graphics functions to do basic
rendering (load textures to video card from memory, NOT from files; display
textures on screen), an API for extension libraries (where I would put things
like line-drawing, AND render-to-texture), and that’s it for the
ACTUAL graphics. Everything else should be implemented in an extension
library, and if it can’t be, then that indicates the SDL2 api doesn’t
properly support extensions.

Whether rotation etc. belongs in SDL2 or in such an extension library
I’m not inclined to speak on. I will say that if it isn’t implemented
for the software renderer, then it shouldn’t be in the SDL core.

Regardless, I think it should always be possible to implement simple
graphical SDL programs with ONLY SDL, regardless of whether it’s SDL
1.2, SDL2, etc.> Date: Wed, 4 Jan 2012 17:17:10 -0600

From: Bob Pendleton
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

Date: Wed, 4 Jan 2012 19:58:23 -0500
From: Sam Lantinga
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

Mason is absolutely right that the current API doesn’t expose the things he
needs to extend the underlying rendering system. To some extent this is
intentional as the API user isn’t supposed to have to worry about whether
the underlying rendering system is OpenGL, Direct3D or software.

I think that some exposure of the underlying system will probably be
necessary, for the sake of library interoperability. Hopefully a
handful of functions, enums, and structures, all declared in an
optional header file. Maybe call it “extension_api.h” or something.

My feeling is that there are still one or two things that the API can use
to be really useful, such as render to texture, but I have drawn the line
at things that would expose 3D math - once you go there you’re better off
using a real 3D engine or going directly to OpenGL/Direct3D.

I personally would prefer render-to-texture to be in an official
extension library, but I have a smart-phone that doesn’t support it,
so I’m biased on this subject.

Date: Sun, 8 Jan 2012 00:28:21 -0600
From: Bob Pendleton
To: sdl at lists.libsdl.org
Subject: [SDL] SDL2 Graphics API, was Re: compiling with
SDL_NO_COMPAT
Message-ID:
<CAKabUS5zgoAeMixVjaie5841HSugn-42SPzcAW-hUGyL=TOFiA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Fair enough.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Doesn’t really strike me as sufficiently simple, but I’ve written
enough image-layering stuff that I’m willing to look at the current
software renderer, and attempt to add support, if Sam & the team
decide to go with it. It isn’t like it’s THAT complex if you aren’t
using MMX & co. (which would be enough for the reference/emergency
backup implementation that the software renderer optimistically is).

That having been said, an api that supported it would need to be
defined for, e.g., clearing a single layer.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

I’m in favor of using an official extension library (ala SDL_mixer)
for that, but see my note above :wink: .

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

My perspective on primitives is that the core graphics api should
provide textured triangles or rectangles and nothing else. With a good
extension interface you can do a low-level implementation of other
standards (lines, circles, etc.), and without it you can use the
textured triangle/rectangle function to implement them.

And, lets not forget fonts. People need fonts.

I’d say that should be kept separate, much as SDL_TTF currently is.
More prominent placement and mention of the ‘standard support
libraries’ (preferably mentioned and downloadable right beside the
core library) would be nice though.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

For the core Windowing/Graphics api, pixels make the most sense for
every platform where that’s the ‘native way’. For a richer Grahics api
that sits on top of SDL, instead of just extending it, I think the
field should be considered wide-open.

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

I don’t know SVG, but from a quick glance at what appeared to be the
relevant info, I’d suggest the following for a library that USES SDL2:

  1. The ‘drawable area’ is always considered ‘1.0’ wide, and tall. If a
    3d library, then it also has a depth of ‘1.0’. Drawing & etc.
    functions always use this particular floating-point coordinate system.
    Resizing the drawable area does not modify this coordinate scheme: no
    matter what the size of the drawable area is, it’s dimensions are
    always 1.0*1.0(*1.0). After all, a viewport will ALWAYS be exactly 1
    viewport in width, and 1 viewport in height. From what I read, this is
    not what SVG does; the other two suggestions are:
  2. The drawable area can be queried for it’s dimensions in pixels (or
    voxels if a 3d library). This coordinate system is not used by
    graphics functions, it is only provided for informational purposes
    (e.g. to choose texture resolutions).
  3. The drawable area can be asked for it’s real-world dimensions
    (inches, centimeters, etc.) but is not required to provide them. This
    coordinate system is provided for the same purpose as the pixel
    coordinate system.

But, again, this wouldn’t be for SDL2 itself, just for a graphics
library sitting on top of it.

blink? OK, this is getting ridiculous.? What is with your obsession with putting all
possible functionality in extension libraries?? It’s like you’ve never heard the term
DLL Hell before!

It’s bad enough as it is.? Every bit of external code I use requires yet another DLL
in my deployment package.? The worst offender (in my game engine at least) is
Firebird. There’s no good reasonit should take 7 differentDLLs just to support a
simple embedded database, butit does!? But second on the list is SDL.? I need
two different DLLs just to open a ubiquitous file format such as PNG or JPEG
and draw it on the screen, plus an external library for each file format I want
to support, plus other dependencies for those libraries (zlib for libpng, etc.)
And heaven help me if I want to include music-playing capabilities! And now
you want to make it even worse?!?

Give me one good reason why fundamental functionality that every game
is going to need, such as loading images, rendering, playing audio and displaying
text should not be included as part of the basic package in a multimedia library
whose name proclaims that its goal is to make multimedia programming “simple”!

Sure, plugin support is a good idea, but let’s be realistic and save it for stuff that
really is only optional, not for core functionality that everyone is realistically
likely to need!________________________________
From: Jared Maddox
Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

Date: Wed, 4 Jan 2012 17:17:10 -0600
From: Bob Pendleton
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

Does SDL2 need any graphics support in it? It needs to be able to load
images, it needs to be able to do the kinds of image manipulation that
a graphics program needs to do to prepare images for use by a graphics
program, and it would be nice if it had helper functions to hand off
images to the OpenGL and DirectX and whatever other high level
graphics API you are using.

In my opinion, SDL2 should have functions to load and save images and
hand them off to OpenGL, DirectX, and what ever other high level
graphics APIs may be in use.

In my opinion, SDL2 should have enough graphics functions to do basic
rendering (load textures to video card from memory, NOT from files; display
textures on screen), an API for extension libraries (where I would put things
like line-drawing, AND render-to-texture), and that’s it for the
ACTUAL graphics. Everything else should be implemented in an extension
library, and if it can’t be, then that indicates the SDL2 api doesn’t
properly support extensions.

Whether rotation etc. belongs in SDL2 or in such an extension library
I’m not inclined to speak on. I will say that if it isn’t implemented
for the software renderer, then it shouldn’t be in the SDL core.

Regardless, I think it should always be possible to implement simple
graphical SDL programs with ONLY SDL, regardless of whether it’s SDL
1.2, SDL2, etc.

Date: Wed, 4 Jan 2012 19:58:23 -0500
From: Sam Lantinga
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

Mason is absolutely right that the current API doesn’t expose the things he
needs to extend the underlying rendering system.? To some extent this is
intentional as the API user isn’t supposed to have to worry about whether
the underlying rendering system is OpenGL, Direct3D or software.

I think that some exposure of the underlying system will probably be
necessary, for the sake of library interoperability. Hopefully a
handful of functions, enums, and structures, all declared in an
optional header file. Maybe call it “extension_api.h” or something.

My feeling is that there are still one or two things that the API can use
to be really useful, such as render to texture, but I have drawn the line
at things that would expose 3D math - once you go there you’re better off
using a real 3D engine or going directly to OpenGL/Direct3D.

I personally would prefer render-to-texture to be in an official
extension library, but I have a smart-phone that doesn’t support it,
so I’m biased on this subject.

Date: Sun, 8 Jan 2012 00:28:21 -0600
From: Bob Pendleton
To: sdl at lists.libsdl.org
Subject: [SDL] SDL2 Graphics API, was Re:? compiling with
??? SDL_NO_COMPAT
Message-ID:
??? <CAKabUS5zgoAeMixVjaie5841HSugn-42SPzcAW-hUGyL=TOFiA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Fair enough.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Doesn’t really strike me as sufficiently simple, but I’ve written
enough image-layering stuff that I’m willing to look at the current
software renderer, and attempt to add support, if Sam & the team
decide to go with it. It isn’t like it’s THAT complex if you aren’t
using MMX & co. (which would be enough for the reference/emergency
backup implementation that the software renderer optimistically is).

That having been said, an api that supported it would need to be
defined for, e.g., clearing a single layer.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

I’m in favor of using an official extension library (ala SDL_mixer)
for that, but see my note above :wink: .

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

My perspective on primitives is that the core graphics api should
provide textured triangles or rectangles and nothing else. With a good
extension interface you can do a low-level implementation of other
standards (lines, circles, etc.), and without it you can use the
textured triangle/rectangle function to implement them.

And, lets not forget fonts. People need fonts.

I’d say that should be kept separate, much as SDL_TTF currently is.
More prominent placement and mention of the ‘standard support
libraries’ (preferably mentioned and downloadable right beside the
core library) would be nice though.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

For the core Windowing/Graphics api, pixels make the most sense for
every platform where that’s the ‘native way’. For a richer Grahics api
that sits on top of SDL, instead of just extending it, I think the
field should be considered wide-open.

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

I don’t know SVG, but from a quick glance at what appeared to be the
relevant info, I’d suggest the following for a library that USES SDL2:

  1. The ‘drawable area’ is always considered ‘1.0’ wide, and tall. If a
    3d library, then it also has a depth of ‘1.0’. Drawing & etc.
    functions always use this particular floating-point coordinate system.
    Resizing the drawable area does not modify this coordinate scheme: no
    matter what the size of the drawable area is, it’s dimensions are
    always 1.0*1.0(*1.0). After all, a viewport will ALWAYS be exactly 1
    viewport in width, and 1 viewport in height. >From what I read, this is
    not what SVG does; the other two suggestions are:
  2. The drawable area can be queried for it’s dimensions in pixels (or
    voxels if a 3d library). This coordinate system is not used by
    graphics functions, it is only provided for informational purposes
    (e.g. to choose texture resolutions).
  3. The drawable area can be asked for it’s real-world dimensions
    (inches, centimeters, etc.) but is not required to provide them. This
    coordinate system is provided for the same purpose as the pixel
    coordinate system.

But, again, this wouldn’t be for SDL2 itself, just for a graphics
library sitting on top of it.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I can see the motivation for making it all modular from a library development
POV - but that doesn’t mean it has to literally build as separate
libs/modules.

Linux kernel module style solution; allow optional extensions to be compiled
in, built as external libs, or not built at all?

Pre-built SDL would normally come with everything compiled in. If you want to
save every last byte (which seems kind of ridiculous unless you’re aiming for
90% structured/procedural media - like me and like, five other gamedevs on the
planet), you either pick a modular build and drop in only the libs you need,
or you build your own single file version.

Not the most trivial solution, but one size does not fit all, obviously…On Thursday 12 January 2012, at 14.16.19, Mason Wheeler wrote:

blink OK, this is getting ridiculous. What is with your obsession with
putting all possible functionality in extension libraries? It’s like
you’ve never heard the term DLL Hell before!

It’s bad enough as it is. Every bit of external code I use requires yet
another DLL in my deployment package. The worst offender (in my game
engine at least) is Firebird. There’s no good reasonit should take 7
differentDLLs just to support a simple embedded database, butit does! But
second on the list is SDL. I need two different DLLs just to open a
ubiquitous file format such as PNG or JPEG and draw it on the screen, plus
an external library for each file format I want to support, plus other
dependencies for those libraries (zlib for libpng, etc.) And heaven help
me if I want to include music-playing capabilities! And now you want to
make it even worse?!?

Give me one good reason why fundamental functionality that every game
is going to need, such as loading images, rendering, playing audio and
displaying text should not be included as part of the basic package in a
multimedia library whose name proclaims that its goal is to make
multimedia programming “simple”!

Sure, plugin support is a good idea, but let’s be realistic and save it for
stuff that really is only optional, not for core functionality that
everyone is realistically likely to need!


From: Jared Maddox
Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

Date: Wed, 4 Jan 2012 17:17:10 -0600
From: Bob Pendleton
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

Does SDL2 need any graphics support in it? It needs to be able to load
images, it needs to be able to do the kinds of image manipulation that
a graphics program needs to do to prepare images for use by a graphics
program, and it would be nice if it had helper functions to hand off
images to the OpenGL and DirectX and whatever other high level
graphics API you are using.

In my opinion, SDL2 should have functions to load and save images and
hand them off to OpenGL, DirectX, and what ever other high level
graphics APIs may be in use.

In my opinion, SDL2 should have enough graphics functions to do basic
rendering (load textures to video card from memory, NOT from files; display
textures on screen), an API for extension libraries (where I would put
things like line-drawing, AND render-to-texture), and that’s it for the
ACTUAL graphics. Everything else should be implemented in an extension
library, and if it can’t be, then that indicates the SDL2 api doesn’t
properly support extensions.

Whether rotation etc. belongs in SDL2 or in such an extension library
I’m not inclined to speak on. I will say that if it isn’t implemented
for the software renderer, then it shouldn’t be in the SDL core.

Regardless, I think it should always be possible to implement simple
graphical SDL programs with ONLY SDL, regardless of whether it’s SDL
1.2, SDL2, etc.

Date: Wed, 4 Jan 2012 19:58:23 -0500
From: Sam Lantinga
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

Mason is absolutely right that the current API doesn’t expose the things
he needs to extend the underlying rendering system. To some extent this
is intentional as the API user isn’t supposed to have to worry about
whether the underlying rendering system is OpenGL, Direct3D or software.

I think that some exposure of the underlying system will probably be
necessary, for the sake of library interoperability. Hopefully a
handful of functions, enums, and structures, all declared in an
optional header file. Maybe call it “extension_api.h” or something.

My feeling is that there are still one or two things that the API can use
to be really useful, such as render to texture, but I have drawn the line
at things that would expose 3D math - once you go there you’re better off
using a real 3D engine or going directly to OpenGL/Direct3D.

I personally would prefer render-to-texture to be in an official
extension library, but I have a smart-phone that doesn’t support it,
so I’m biased on this subject.

Date: Sun, 8 Jan 2012 00:28:21 -0600
From: Bob Pendleton
To: sdl at lists.libsdl.org
Subject: [SDL] SDL2 Graphics API, was Re: compiling with
SDL_NO_COMPAT
Message-ID:
<CAKabUS5zgoAeMixVjaie5841HSugn-42SPzcAW-hUGyL=TOFiA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Fair enough.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Doesn’t really strike me as sufficiently simple, but I’ve written
enough image-layering stuff that I’m willing to look at the current
software renderer, and attempt to add support, if Sam & the team
decide to go with it. It isn’t like it’s THAT complex if you aren’t
using MMX & co. (which would be enough for the reference/emergency
backup implementation that the software renderer optimistically is).

That having been said, an api that supported it would need to be
defined for, e.g., clearing a single layer.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

I’m in favor of using an official extension library (ala SDL_mixer)
for that, but see my note above :wink: .

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

My perspective on primitives is that the core graphics api should
provide textured triangles or rectangles and nothing else. With a good
extension interface you can do a low-level implementation of other
standards (lines, circles, etc.), and without it you can use the
textured triangle/rectangle function to implement them.

And, lets not forget fonts. People need fonts.

I’d say that should be kept separate, much as SDL_TTF currently is.
More prominent placement and mention of the ‘standard support
libraries’ (preferably mentioned and downloadable right beside the
core library) would be nice though.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

For the core Windowing/Graphics api, pixels make the most sense for
every platform where that’s the ‘native way’. For a richer Grahics api
that sits on top of SDL, instead of just extending it, I think the
field should be considered wide-open.

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

I don’t know SVG, but from a quick glance at what appeared to be the
relevant info, I’d suggest the following for a library that USES SDL2:

  1. The ‘drawable area’ is always considered ‘1.0’ wide, and tall. If a
    3d library, then it also has a depth of ‘1.0’. Drawing & etc.
    functions always use this particular floating-point coordinate system.
    Resizing the drawable area does not modify this coordinate scheme: no
    matter what the size of the drawable area is, it’s dimensions are
    always 1.0*1.0(*1.0). After all, a viewport will ALWAYS be exactly 1
    viewport in width, and 1 viewport in height. From what I read, this is
    not what SVG does; the other two suggestions are:
  2. The drawable area can be queried for it’s dimensions in pixels (or
    voxels if a 3d library). This coordinate system is not used by
    graphics functions, it is only provided for informational purposes
    (e.g. to choose texture resolutions).
  3. The drawable area can be asked for it’s real-world dimensions
    (inches, centimeters, etc.) but is not required to provide them. This
    coordinate system is provided for the same purpose as the pixel
    coordinate system.

But, again, this wouldn’t be for SDL2 itself, just for a graphics
library sitting on top of it.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

Mason, what about licensing that allows static linking?

Jonny DOn Thu, Jan 12, 2012 at 8:47 AM, David Olofson wrote:

I can see the motivation for making it all modular from a library
development
POV - but that doesn’t mean it has to literally build as separate
libs/modules.

Linux kernel module style solution; allow optional extensions to be
compiled
in, built as external libs, or not built at all?

Pre-built SDL would normally come with everything compiled in. If you want
to
save every last byte (which seems kind of ridiculous unless you’re aiming
for
90% structured/procedural media - like me and like, five other gamedevs on
the
planet), you either pick a modular build and drop in only the libs you
need,
or you build your own single file version.

Not the most trivial solution, but one size does not fit all, obviously…

On Thursday 12 January 2012, at 14.16.19, Mason Wheeler wrote:

blink OK, this is getting ridiculous. What is with your obsession
with
putting all possible functionality in extension libraries? It’s like
you’ve never heard the term DLL Hell before!

It’s bad enough as it is. Every bit of external code I use requires yet
another DLL in my deployment package. The worst offender (in my game
engine at least) is Firebird. There’s no good reasonit should take 7
differentDLLs just to support a simple embedded database, butit does!
But
second on the list is SDL. I need two different DLLs just to open a
ubiquitous file format such as PNG or JPEG and draw it on the screen,
plus
an external library for each file format I want to support, plus other
dependencies for those libraries (zlib for libpng, etc.) And heaven help
me if I want to include music-playing capabilities! And now you want to
make it even worse?!?

Give me one good reason why fundamental functionality that every game
is going to need, such as loading images, rendering, playing audio and
displaying text should not be included as part of the basic package in
a
multimedia library whose name proclaims that its goal is to make
multimedia programming “simple”!

Sure, plugin support is a good idea, but let’s be realistic and save it
for
stuff that really is only optional, not for core functionality that
everyone is realistically likely to need!


From: Jared Maddox
Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with
SDL_NO_COMPAT

Date: Wed, 4 Jan 2012 17:17:10 -0600
From: Bob Pendleton
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

Does SDL2 need any graphics support in it? It needs to be able to load
images, it needs to be able to do the kinds of image manipulation that
a graphics program needs to do to prepare images for use by a graphics
program, and it would be nice if it had helper functions to hand off
images to the OpenGL and DirectX and whatever other high level
graphics API you are using.

In my opinion, SDL2 should have functions to load and save images and
hand them off to OpenGL, DirectX, and what ever other high level
graphics APIs may be in use.

In my opinion, SDL2 should have enough graphics functions to do basic
rendering (load textures to video card from memory, NOT from files;
display
textures on screen), an API for extension libraries (where I would put
things like line-drawing, AND render-to-texture), and that’s it for the
ACTUAL graphics. Everything else should be implemented in an extension
library, and if it can’t be, then that indicates the SDL2 api doesn’t
properly support extensions.

Whether rotation etc. belongs in SDL2 or in such an extension library
I’m not inclined to speak on. I will say that if it isn’t implemented
for the software renderer, then it shouldn’t be in the SDL core.

Regardless, I think it should always be possible to implement simple
graphical SDL programs with ONLY SDL, regardless of whether it’s SDL
1.2, SDL2, etc.

Date: Wed, 4 Jan 2012 19:58:23 -0500
From: Sam Lantinga
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

Mason is absolutely right that the current API doesn’t expose the
things

he needs to extend the underlying rendering system. To some extent
this

is intentional as the API user isn’t supposed to have to worry about
whether the underlying rendering system is OpenGL, Direct3D or
software.

I think that some exposure of the underlying system will probably be
necessary, for the sake of library interoperability. Hopefully a
handful of functions, enums, and structures, all declared in an
optional header file. Maybe call it “extension_api.h” or something.

My feeling is that there are still one or two things that the API can
use

to be really useful, such as render to texture, but I have drawn the
line

at things that would expose 3D math - once you go there you’re better
off

using a real 3D engine or going directly to OpenGL/Direct3D.

I personally would prefer render-to-texture to be in an official
extension library, but I have a smart-phone that doesn’t support it,
so I’m biased on this subject.

Date: Sun, 8 Jan 2012 00:28:21 -0600
From: Bob Pendleton
To: sdl at lists.libsdl.org
Subject: [SDL] SDL2 Graphics API, was Re: compiling with
SDL_NO_COMPAT
Message-ID:
<CAKabUS5zgoAeMixVjaie5841HSugn-42SPzcAW-hUGyL=
TOFiA at mail.gmail.com>

Content-Type: text/plain; charset=ISO-8859-1

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Fair enough.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Doesn’t really strike me as sufficiently simple, but I’ve written
enough image-layering stuff that I’m willing to look at the current
software renderer, and attempt to add support, if Sam & the team
decide to go with it. It isn’t like it’s THAT complex if you aren’t
using MMX & co. (which would be enough for the reference/emergency
backup implementation that the software renderer optimistically is).

That having been said, an api that supported it would need to be
defined for, e.g., clearing a single layer.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

I’m in favor of using an official extension library (ala SDL_mixer)
for that, but see my note above :wink: .

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

My perspective on primitives is that the core graphics api should
provide textured triangles or rectangles and nothing else. With a good
extension interface you can do a low-level implementation of other
standards (lines, circles, etc.), and without it you can use the
textured triangle/rectangle function to implement them.

And, lets not forget fonts. People need fonts.

I’d say that should be kept separate, much as SDL_TTF currently is.
More prominent placement and mention of the ‘standard support
libraries’ (preferably mentioned and downloadable right beside the
core library) would be nice though.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

For the core Windowing/Graphics api, pixels make the most sense for
every platform where that’s the ‘native way’. For a richer Grahics api
that sits on top of SDL, instead of just extending it, I think the
field should be considered wide-open.

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

I don’t know SVG, but from a quick glance at what appeared to be the
relevant info, I’d suggest the following for a library that USES SDL2:

  1. The ‘drawable area’ is always considered ‘1.0’ wide, and tall. If a
    3d library, then it also has a depth of ‘1.0’. Drawing & etc.
    functions always use this particular floating-point coordinate system.
    Resizing the drawable area does not modify this coordinate scheme: no
    matter what the size of the drawable area is, it’s dimensions are
    always 1.0*1.0(*1.0). After all, a viewport will ALWAYS be exactly 1
    viewport in width, and 1 viewport in height. From what I read, this is
    not what SVG does; the other two suggestions are:
  2. The drawable area can be queried for it’s dimensions in pixels (or
    voxels if a 3d library). This coordinate system is not used by
    graphics functions, it is only provided for informational purposes
    (e.g. to choose texture resolutions).
  3. The drawable area can be asked for it’s real-world dimensions
    (inches, centimeters, etc.) but is not required to provide them. This
    coordinate system is provided for the same purpose as the pixel
    coordinate system.

But, again, this wouldn’t be for SDL2 itself, just for a graphics
library sitting on top of it.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

What about it?? The current licensing does allow static linking, and I might actually end
up going that route.? Ideally, I’d like to be able to compile everything into the EXE.? Less
clutter to deal with, plus that way the smartlinker can analyze stuff and trim out unused
functions to help keep the download size down.? Never gonna happen, of course, but a
guy can dream, right?________________________________
From: Jonathan Dearborn
Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

Mason, what about licensing that allows static linking?

Jonny D

On Thu, Jan 12, 2012 at 8:47 AM, David Olofson wrote:

I can see the motivation for making it all modular from a library development
POV - but that doesn’t mean it has to literally build as separate
libs/modules.

Linux kernel module style solution; allow optional extensions to be compiled
in, built as external libs, or not built at all?

Pre-built SDL would normally come with everything compiled in. If you want to
save every last byte (which seems kind of ridiculous unless you’re aiming for
90% structured/procedural media - like me and like, five other gamedevs on the
planet), you either pick a modular build and drop in only the libs you need,
or you build your own single file version.

Not the most trivial solution, but one size does not fit all, obviously…

On Thursday 12 January 2012, at 14.16.19, Mason Wheeler <@Mason_Wheeler> wrote:

blink ?OK, this is getting ridiculous. ?What is with your obsession with
putting all possible functionality in extension libraries? ?It’s like
you’ve never heard the term DLL Hell before!

It’s bad enough as it is. ?Every bit of external code I use requires yet
another DLL in my deployment package. ?The worst offender (in my game
engine at least) is Firebird. There’s no good reasonit should take 7
differentDLLs just to support a simple embedded database, butit does! ?But

second on the list is SDL. ?I need two different DLLs just to open a
ubiquitous file format such as PNG or JPEG and draw it on the screen, plus
an external library for each file format I want to support, plus other
dependencies for those libraries (zlib for libpng, etc.) And heaven help
me if I want to include music-playing capabilities! And now you want to
make it even worse?!?

Give me one good reason why fundamental functionality that every game
is going to need, such as loading images, rendering, playing audio and
displaying text should not be included as part of the basic package in a
multimedia library whose name proclaims that its goal is to make
multimedia programming “simple”!

Sure, plugin support is a good idea, but let’s be realistic and save it for
stuff that really is only optional, not for core functionality that
everyone is realistically likely to need!


?From: Jared Maddox
Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

Date: Wed, 4 Jan 2012 17:17:10 -0600
From: Bob Pendleton
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

Does SDL2 need any graphics support in it? It needs to be able to load
images, it needs to be able to do the kinds of image manipulation that
a graphics program needs to do to prepare images for use by a graphics
program, and it would be nice if it had helper functions to hand off
images to the OpenGL and DirectX and whatever other high level
graphics API you are using.

In my opinion, SDL2 should have functions to load and save images and
hand them off to OpenGL, DirectX, and what ever other high level
graphics APIs may be in use.

In my opinion, SDL2 should have enough graphics functions to do basic
rendering (load textures to video card from memory, NOT from files; display
textures on screen), an API for extension libraries (where I would put
things like line-drawing, AND render-to-texture), and that’s it for the
ACTUAL graphics. Everything else should be implemented in an extension
library, and if it can’t be, then that indicates the SDL2 api doesn’t
properly support extensions.

Whether rotation etc. belongs in SDL2 or in such an extension library
I’m not inclined to speak on. I will say that if it isn’t implemented
for the software renderer, then it shouldn’t be in the SDL core.

Regardless, I think it should always be possible to implement simple
graphical SDL programs with ONLY SDL, regardless of whether it’s SDL
1.2, SDL2, etc.

Date: Wed, 4 Jan 2012 19:58:23 -0500
From: Sam Lantinga
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

Mason is absolutely right that the current API doesn’t expose the things
he needs to extend the underlying rendering system. ?To some extent this
is intentional as the API user isn’t supposed to have to worry about
whether the underlying rendering system is OpenGL, Direct3D or software.

I think that some exposure of the underlying system will probably be
necessary, for the sake of library interoperability. Hopefully a
handful of functions, enums, and structures, all declared in an
optional header file. Maybe call it “extension_api.h” or something.

My feeling is that there are still one or two things that the API can use
to be really useful, such as render to texture, but I have drawn the line
at things that would expose 3D math - once you go there you’re better off
using a real 3D engine or going directly to OpenGL/Direct3D.

I personally would prefer render-to-texture to be in an official
extension library, but I have a smart-phone that doesn’t support it,
so I’m biased on this subject.

Date: Sun, 8 Jan 2012 00:28:21 -0600
From: Bob Pendleton
To: sdl at lists.libsdl.org
Subject: [SDL] SDL2 Graphics API, was Re: ?compiling with
? ? SDL_NO_COMPAT
Message-ID:
? ? <CAKabUS5zgoAeMixVjaie5841HSugn-42SPzcAW-hUGyL=TOFiA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Fair enough.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Doesn’t really strike me as sufficiently simple, but I’ve written
enough image-layering stuff that I’m willing to look at the current
software renderer, and attempt to add support, if Sam & the team
decide to go with it. It isn’t like it’s THAT complex if you aren’t
using MMX & co. (which would be enough for the reference/emergency
backup implementation that the software renderer optimistically is).

That having been said, an api that supported it would need to be
defined for, e.g., clearing a single layer.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

I’m in favor of using an official extension library (ala SDL_mixer)
for that, but see my note above :wink: .

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

My perspective on primitives is that the core graphics api should
provide textured triangles or rectangles and nothing else. With a good
extension interface you can do a low-level implementation of other
standards (lines, circles, etc.), and without it you can use the
textured triangle/rectangle function to implement them.

And, lets not forget fonts. People need fonts.

I’d say that should be kept separate, much as SDL_TTF currently is.
More prominent placement and mention of the ‘standard support
libraries’ (preferably mentioned and downloadable right beside the
core library) would be nice though.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

For the core Windowing/Graphics api, pixels make the most sense for
every platform where that’s the ‘native way’. For a richer Grahics api
that sits on top of SDL, instead of just extending it, I think the
field should be considered wide-open.

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

I don’t know SVG, but from a quick glance at what appeared to be the
relevant info, I’d suggest the following for a library that USES SDL2:

  1. The ‘drawable area’ is always considered ‘1.0’ wide, and tall. If a
    3d library, then it also has a depth of ‘1.0’. Drawing & etc.
    functions always use this particular floating-point coordinate system.
    Resizing the drawable area does not modify this coordinate scheme: no
    matter what the size of the drawable area is, it’s dimensions are
    always 1.0*1.0(*1.0). After all, a viewport will ALWAYS be exactly 1
    viewport in width, and 1 viewport in height. From what I read, this is
    not what SVG does; the other two suggestions are:
  2. The drawable area can be queried for it’s dimensions in pixels (or
    voxels if a 3d library). This coordinate system is not used by
    graphics functions, it is only provided for informational purposes
    (e.g. to choose texture resolutions).
  3. The drawable area can be asked for it’s real-world dimensions
    (inches, centimeters, etc.) but is not required to provide them. This
    coordinate system is provided for the same purpose as the pixel
    coordinate system.

But, again, this wouldn’t be for SDL2 itself, just for a graphics
library sitting on top of it.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| ? http://consulting.olofson.net ? ? ? ? ?http://olofsonarcade.com ? |
’---------------------------------------------------------------------’


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

What about it? The current licensing does allow static linking, and I
might actually end up going that route. Ideally, I’d like to be able to
compile everything into the EXE. Less clutter to deal with, plus that way
the smartlinker can analyze stuff and trim out unused functions to help
keep the download size down.

…and it’ll actually work without dirty tricks on Linux, where you normally
cannot just drop libs in the directory along with the executable.

OTOH, that would actually still work if the libs were loaded run-time, as one
normally does with OpenGL etc. So, either static or run-time - “normal” shared
libs is where the problems are.

Never gonna happen, of course, but a guy can dream, right?

Well, there is static linking + object files…


Mason, what about licensing that allows static linking?
[…]On Thursday 12 January 2012, at 16.17.53, Mason Wheeler wrote:
From: Jonathan Dearborn
Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

I don’t use the SDL extension libraries. I don’t need the SDL extension
libraries. I don’t want the functionality from the SDL extension
libraries in the SDL core.

The problem with including it all in the core is that this actually
increases DLL hell. If the SDL core included the functionality of
SDL_image, then the SDL core would inherit all of the dependenies of
SDL_image, for example. Why should I need to ship a libpng DLL if my
program doesn’t load PNG files?On 2012-01-12 14:16, Mason Wheeler wrote:

Give me one good reason why fundamental functionality that every game
is going to need, such as loading images, rendering, playing audio and displaying
text should not be included as part of the basic package in a multimedia library
whose name proclaims that its goal is to make multimedia programming “simple”!


Rainer Deyke (rainerd at eldwood.com)

Bob, I don’t think we’re quite ready to talk about this, unless you’re
talking about something you’d like to write and maintain separately from
SDL. :slight_smile:

I waited a long time to reply because I wanted to “stir the pot” and
see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob PendletonOn Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga wrote:

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton <@Bob_Pendleton> wrote:

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225 <bala_48225 at yahoo.com> wrote:

So far I haven’t used SDL 1.3, but as far as the proposed
split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide multiple
    alpha blend modes for
    images, including multiply alpha, and 3) Provide something akin to SDL
    1.2’s
    SDL_FillRect,
    perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t see
why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------

blink? OK, this is getting ridiculous.? What is with your obsession with
putting all
possible functionality in extension libraries?? It’s like you’ve never heard
the term
DLL Hell before!

It’s bad enough as it is.? Every bit of external code I use requires yet
another DLL
in my deployment package.? The worst offender (in my game engine at least)
is
Firebird. There’s no good reason it should take 7 different DLLs just to
support a
simple embedded database, but it does!? But second on the list is SDL.? I
need
two different DLLs just to open a ubiquitous file format such as PNG or JPEG
and draw it on the screen, plus an external library for each file format I
want
to support, plus other dependencies for those libraries (zlib for libpng,
etc.)
And heaven help me if I want to include music-playing capabilities! And now
you want to make it even worse?!?

Give me one good reason why fundamental functionality that every game
is going to need, such as loading images, rendering, playing audio and
displaying
text should not be included as part of the basic package in a multimedia
library
whose name proclaims that its goal is to make multimedia programming
"simple"!
Sure, plugin support is a good idea, but let’s be realistic and save it for
stuff that
really is only optional, not for core functionality that everyone is
realistically
likely to need!

I think that SDL is rather like the elephant in the story of the blind
men and the elephant. Each of us sees something different depending on
how we approach the elephant. I’ve seen a number of arguments on the
list over whether the Simple in SDL means that the library it self is
simple, as in small, or simple to use, or simple to understand, or…
May I propose that the Simple in SDL may mean that it makes it Simple
to write cross platform extension libraries? :slight_smile:

I have come to see SDL as an abstraction layer for interacting with
the human interface hardware and the multimedia hardware available on
modern computer based devices. Basically, Apple, Google, MS, et al. do
there best to provide incompatible APIs and SDL make them all
compatible.

Seriously, I understand your point of view. Can a single library ever
contain everything that every end user needs? More realistically, can
a single library, provide 80% of what everyone needs and 100% of what
they need to implement the rest? You can hope to get 80%, but never
100%.

So, what do you want in a 2D API?

Bob PendletonOn Thu, Jan 12, 2012 at 7:16 AM, Mason Wheeler wrote:


From: Jared Maddox
Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

Date: Wed, 4 Jan 2012 17:17:10 -0600
From: Bob Pendleton <@Bob_Pendleton>
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

Does SDL2 need any graphics support in it? It needs to be able to load
images, it needs to be able to do the kinds of image manipulation that
a graphics program needs to do to prepare images for use by a graphics
program, and it would be nice if it had helper functions to hand off
images to the OpenGL and DirectX and whatever other high level
graphics API you are using.

In my opinion, SDL2 should have functions to load and save images and
hand them off to OpenGL, DirectX, and what ever other high level
graphics APIs may be in use.

In my opinion, SDL2 should have enough graphics functions to do basic
rendering (load textures to video card from memory, NOT from files; display
textures on screen), an API for extension libraries (where I would put
things
like line-drawing, AND render-to-texture), and that’s it for the
ACTUAL graphics. Everything else should be implemented in an extension
library, and if it can’t be, then that indicates the SDL2 api doesn’t
properly support extensions.

Whether rotation etc. belongs in SDL2 or in such an extension library
I’m not inclined to speak on. I will say that if it isn’t implemented
for the software renderer, then it shouldn’t be in the SDL core.

Regardless, I think it should always be possible to implement simple
graphical SDL programs with ONLY SDL, regardless of whether it’s SDL
1.2, SDL2, etc.

Date: Wed, 4 Jan 2012 19:58:23 -0500
From: Sam Lantinga
Subject: Re: [SDL] compiling with SDL_NO_COMPAT

Mason is absolutely right that the current API doesn’t expose the things
he
needs to extend the underlying rendering system.? To some extent this is
intentional as the API user isn’t supposed to have to worry about whether
the underlying rendering system is OpenGL, Direct3D or software.

I think that some exposure of the underlying system will probably be
necessary, for the sake of library interoperability. Hopefully a
handful of functions, enums, and structures, all declared in an
optional header file. Maybe call it “extension_api.h” or something.

My feeling is that there are still one or two things that the API can use
to be really useful, such as render to texture, but I have drawn the line
at things that would expose 3D math - once you go there you’re better off
using a real 3D engine or going directly to OpenGL/Direct3D.

I personally would prefer render-to-texture to be in an official
extension library, but I have a smart-phone that doesn’t support it,
so I’m biased on this subject.

Date: Sun, 8 Jan 2012 00:28:21 -0600
From: Bob Pendleton <@Bob_Pendleton>
To: sdl at lists.libsdl.org
Subject: [SDL] SDL2 Graphics API, was Re:? compiling with
??? SDL_NO_COMPAT
Message-ID:
??? <CAKabUS5zgoAeMixVjaie5841HSugn-42SPzcAW-hUGyL=TOFiA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Fair enough.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Doesn’t really strike me as sufficiently simple, but I’ve written
enough image-layering stuff that I’m willing to look at the current
software renderer, and attempt to add support, if Sam & the team
decide to go with it. It isn’t like it’s THAT complex if you aren’t
using MMX & co. (which would be enough for the reference/emergency
backup implementation that the software renderer optimistically is).

That having been said, an api that supported it would need to be
defined for, e.g., clearing a single layer.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

I’m in favor of using an official extension library (ala SDL_mixer)
for that, but see my note above :wink: .

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

My perspective on primitives is that the core graphics api should
provide textured triangles or rectangles and nothing else. With a good
extension interface you can do a low-level implementation of other
standards (lines, circles, etc.), and without it you can use the
textured triangle/rectangle function to implement them.

And, lets not forget fonts. People need fonts.

I’d say that should be kept separate, much as SDL_TTF currently is.
More prominent placement and mention of the ‘standard support
libraries’ (preferably mentioned and downloadable right beside the
core library) would be nice though.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

For the core Windowing/Graphics api, pixels make the most sense for
every platform where that’s the ‘native way’. For a richer Grahics api
that sits on top of SDL, instead of just extending it, I think the
field should be considered wide-open.

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

I don’t know SVG, but from a quick glance at what appeared to be the
relevant info, I’d suggest the following for a library that USES SDL2:

  1. The ‘drawable area’ is always considered ‘1.0’ wide, and tall. If a
    3d library, then it also has a depth of ‘1.0’. Drawing & etc.
    functions always use this particular floating-point coordinate system.
    Resizing the drawable area does not modify this coordinate scheme: no
    matter what the size of the drawable area is, it’s dimensions are
    always 1.0*1.0(*1.0). After all, a viewport will ALWAYS be exactly 1
    viewport in width, and 1 viewport in height. From what I read, this is
    not what SVG does; the other two suggestions are:
  2. The drawable area can be queried for it’s dimensions in pixels (or
    voxels if a 3d library). This coordinate system is not used by
    graphics functions, it is only provided for informational purposes
    (e.g. to choose texture resolutions).
  3. The drawable area can be asked for it’s real-world dimensions
    (inches, centimeters, etc.) but is not required to provide them. This
    coordinate system is provided for the same purpose as the pixel
    coordinate system.

But, again, this wouldn’t be for SDL2 itself, just for a graphics
library sitting on top of it.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------

SDL2 = SDL1.3 + Code for Rotation & stretch blit simultaneously
Or
SDL provides a way for the user to get hold of the underlying graphics
API (DirectX/OpenGL) to allow me to implement the above code in my game
without touching SDL itself.
:)On 18-01-2012 10:42, Bob Pendleton wrote:

On Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga wrote:

Bob, I don’t think we’re quite ready to talk about this, unless you’re
talking about something you’d like to write and maintain separately from
SDL. :slight_smile:
I waited a long time to reply because I wanted to “stir the pot” and
see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob Pendleton

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton wrote:

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225<bala_48225 at yahoo.com> wrote:

So far I haven’t used SDL 1.3, but as far as the proposed
split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide multiple
    alpha blend modes for
    images, including multiply alpha, and 3) Provide something akin to SDL
    1.2’s
    SDL_FillRect,
    perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t see
why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Pallav Nawani
Game Designer/Writer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768

+1 for either ideas;
++1 for both ideas togetherOn Wed, Jan 18, 2012 at 11:21 AM, Pallav Nawani wrote:

SDL2 = SDL1.3 ?+ Code for Rotation & stretch blit simultaneously
Or
SDL provides a way for the user to get hold of the underlying graphics API
(DirectX/OpenGL) to allow me to implement the above code in my game without
touching SDL itself.
:slight_smile:

On 18-01-2012 10:42, Bob Pendleton wrote:

On Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga ?wrote:

Bob, I don’t think we’re quite ready to talk about this, unless you’re
talking about something you’d like to write and maintain separately from
SDL. :slight_smile:

I waited a long time to reply because I wanted to “stir the pot” and
see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob Pendleton

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton ?wrote:

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225<bala_48225 at yahoo.com> ?wrote:

So far I haven’t used SDL 1.3, but as far as the proposed
split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide multiple
    alpha blend modes for
    images, including multiply alpha, and 3) Provide something akin to SDL
    1.2’s
    SDL_FillRect,
    perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t see
why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Pallav Nawani
Game Designer/Writer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL already provides a way for the user to use the underlying graphics API.
The only reason the current code in SDL_render.h couldn’t be pulled out as
a separate library now is that SDL_video.c calls it to support
SDL_CreateWindowSurface() :slight_smile:

Cheers!On Wed, Jan 18, 2012 at 5:21 AM, Pallav Nawani wrote:

SDL2 = SDL1.3 + Code for Rotation & stretch blit simultaneously
Or
SDL provides a way for the user to get hold of the underlying graphics API
(DirectX/OpenGL) to allow me to implement the above code in my game without
touching SDL itself.
:slight_smile:

On 18-01-2012 10:42, Bob Pendleton wrote:

On Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga<@slouken> wrote:

Bob, I don’t think we’re quite ready to talk about this, unless you’re
talking about something you’d like to write and maintain separately from
SDL. :slight_smile:

I waited a long time to reply because I wanted to “stir the pot” and
see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob Pendleton

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton wrote:

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225<bala_48225 at yahoo.**com<bala_48225 at yahoo.com>> wrote:

So far I haven’t used SDL 1.3, but as far as the proposed
split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide multiple
    alpha blend modes for
    images, including multiply alpha, and 3) Provide something akin to SDL
    1.2’s
    SDL_FillRect,
    perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t see
why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------**------------------------------

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Pallav Nawani
Game Designer/Writer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_**Gaminghttp://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/**Ironcode.Gaminghttp://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi,

What I have seen, in my copious time spent helping people on on
www.gamedev.net, is a large scale migration from SDL for many tasks.
Where once users were actively pushing beginner game programmers
towards SDL and pygame, they now are pushing SFML and various OpenGL
based Python libraries (even when the beginner has already chosen an
API!). When challenged, their usual reason for this is performance
related. There is also a perception that SDL is unmaintained and out
of date.

To a non-member of this list, SDL is in danger of appearing
irrelevant, unless you want to support niche platforms. I believe this
trend is a threat to the size and sustainability of the SDL community,
and thus to SDL itself in the long run.

The people want hardware acceleration by default, and they do not wish
to drop into OpenGL to scale or rotate sprites.

My own opinion is that I’d like it if the latter two could be
separated from the core SDL library, into a more advanced library
(like SDL_gfx, but expanded and hardware accelerated). SDL’s built in
routines could then focus on axis aligned fast blitting and rectangle
filling, which can be implemented on pretty much any graphics
hardware.

Regards,
– BrianOn 18 January 2012 05:55, Bob Pendleton wrote:

So, what do you want in a 2D API?

Bob Pendleton

Is it too hard to change this and make SDL_render a separate API?

Sam Lantinga wrote:> SDL already provides a way for the user to use the underlying graphics API. ?The only reason the current code in SDL_render.h couldn’t be pulled out as a separate library now is that SDL_video.c calls it to support SDL_CreateWindowSurface() ?:slight_smile:

Cheers!

What do you mean? SDL does not already provide a way for the user to use the underlying graphics API, at least not in any meaningful way, since there is no way to obtain the native API handle of textures created through SDL, and nothing useful that a user of the library can do without that.________________________________
From: Sam Lantinga
To: SDL Development List
Sent: Wednesday, January 18, 2012 5:00 AM
Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

SDL already provides a way for the user to use the underlying graphics API. ?The only reason the current code in SDL_render.h couldn’t be pulled out as a separate library now is that SDL_video.c calls it to support SDL_CreateWindowSurface() ?:slight_smile:

Cheers!

On Wed, Jan 18, 2012 at 5:21 AM, Pallav Nawani wrote:

SDL2 = SDL1.3 ?+ Code for Rotation & stretch blit simultaneously
Or
SDL provides a way for the user to get hold of the underlying graphics API (DirectX/OpenGL) to allow me to implement the above code in my game without touching SDL itself.
:slight_smile:

On 18-01-2012 10:42, Bob Pendleton wrote:

On Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga ?wrote:

Bob, I don’t think we’re quite ready to talk about this, unless you’re

talking about something you’d like to write and maintain separately from
SDL. :slight_smile:

I waited a long time to reply because I wanted to “stir the pot” and

see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob Pendleton

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton ?wrote:

If we are going to start talking about what features should be in the

graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225<bala_48225 at yahoo.com> ?wrote:

So far I haven’t used SDL 1.3, but as far as the proposed

split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide multiple
    alpha blend modes for
    images, including multiply alpha, and 3) Provide something akin to SDL
    1.2’s
    SDL_FillRect,
    perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t see
why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Pallav Nawani
Game Designer/Writer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

As it shouldn’t. What’s the point of crossplatform if you want to get at
the API details. DX5 or SW or GL renderer? Who cares, if it works. Either
the API should do that for you, or it shouldn’t, but leaking implementation
details is a terrible plan.

PatrickOn Wed, Jan 18, 2012 at 1:12 PM, Mason Wheeler wrote:

What do you mean? SDL does not already provide a way for the user to use
the underlying graphics API, at least not in any meaningful way, since
there is no way to obtain the native API handle of textures created through
SDL, and nothing useful that a user of the library can do without that.


From: Sam Lantinga
To: SDL Development List
Sent: Wednesday, January 18, 2012 5:00 AM
Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with
SDL_NO_COMPAT

SDL already provides a way for the user to use the underlying graphics
API. The only reason the current code in SDL_render.h couldn’t be pulled
out as a separate library now is that SDL_video.c calls it to support
SDL_CreateWindowSurface() :slight_smile:

Cheers!

On Wed, Jan 18, 2012 at 5:21 AM, Pallav Nawani wrote:

SDL2 = SDL1.3 + Code for Rotation & stretch blit simultaneously
Or
SDL provides a way for the user to get hold of the underlying graphics API
(DirectX/OpenGL) to allow me to implement the above code in my game without
touching SDL itself.
:slight_smile:

On 18-01-2012 10:42, Bob Pendleton wrote:

On Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga wrote:

Bob, I don’t think we’re quite ready to talk about this, unless you’re
talking about something you’d like to write and maintain separately from
SDL. :slight_smile:

I waited a long time to reply because I wanted to “stir the pot” and
see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob Pendleton

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton wrote:

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225<bala_48225 at yahoo.**com<bala_48225 at yahoo.com>> wrote:

So far I haven’t used SDL 1.3, but as far as the proposed
split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide multiple
    alpha blend modes for
    images, including multiply alpha, and 3) Provide something akin to SDL
    1.2’s
    SDL_FillRect,
    perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t see
why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------**------------------------------

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Pallav Nawani
Game Designer/Writer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_**Gaminghttp://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/**Ironcode.Gaminghttp://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org