SDL 1.3 progress update

SDL Development
21

groans, rubbing my temples a little

This is gonna be all sorts of fun to update my Delphi headers for the
new rendering API. The less stateful API is going to reduce bugs,
though, so that’s worthwhile I guess.

By “fixed the feature set” I certainly hope you don’t mean that the
feature set is now locked down (fixed) and won’t be added to. I still
don’t see anything about render targets here, and that’s absolutely
essential.

Also, if we’re supposed to use OpenGL directly to get at useful effects
such as rotation, there needs to be some way to query a texture for
its OpenGL handle. I need to rotate less than 1% of the images I’m
rendering, but those ones that do need rotation do need rotation,
and it’s not worth giving up all the high-level image management
routines that the rendering API provides just to deal with that <1% case.
I’d basically just end up reimplementing most of SDL’s rendering in
my own codebase, which is kinda pointless.

Mason> ----- Original Message -----

From: slouken@libsdl.org (Sam Lantinga)
Subject: [SDL] SDL 1.3 progress update

This week is a massive update on the rendering systems, simplifying
and improving them:
http://www.libsdl.org/tmp/SDL-1.3.zip

The theme has been focusing and streamlining the 2D rendering API so
that it is clear and easy to use.
To that end, I’ve fixed the feature set for this release, and removed
all partially functional renderers. I’ve also added the ability to
create an SDL surface for windows which aren’t using rendering or 3D
functionality, and made it possible to create a software renderer for
arbitrary SDL surfaces. Possibly the largest API change is that all
the rendering functions now take a rendering context as their first
parameter, so it’s clear what context they’re acting on.

You can also now create a texture of any format including YUV and SDL
will automatically take care of converting it into the formats
supported by the accelerated renderers. This means that new
accelerated renderers need only advertise the optimal texture formats.
Doing this resulted in a 50% speed boost on Mac OS X. :slight_smile:

I’ve also simplified the driver interfaces so if you are porting to a
new platform you only have to implement 3 functions to get SDL 1.2
functionality and a software renderer, and you only have to implement
them if your platform doesn’t already support OpenGL or OpenGL ES.

As you might imagine, this update has reams of new code. I’ve done a
bunch of testing but I’m sure there are bugs. If you run into them,
please report them at http://bugzilla.libsdl.org/

On the up side, I’m very comfortable with this API set and am going on
to other areas that need love before release. :slight_smile:

Here is the intro to the new SDL_render.h, and a complete list of API changes:

This API supports the following features:
* single pixel points
* single pixel lines
* filled rectangles
* texture images

The primitives may be drawn in opaque, blended, or additive modes.

The texture images may be drawn in opaque, blended, or additive modes.
They can have an additional color tint or alpha modulation applied to
them, and may also be stretched with linear interpolation.

This API is designed to accelerate simple 2D operations. You may
want more functionality such as rotation and particle effects and
in that case you should use SDL’s OpenGL/Direct3D support or one
of the many good 3D engines.

New functions:
SDL_AddEventWatch()
SDL_DelEventWatch()
SDL_GetWindowPixelFormat()
SDL_CreateSoftwareRenderer()
SDL_GetWindowSurface()
SDL_UpdateWindowSurface()
SDL_UpdateWindowSurfaceRects()

Removed functions:
SDL_SetTexturePalette()
SDL_GetTexturePalette()
SDL_SetDisplayPalette()
SDL_GetDisplayPalette()
SDL_RenderWritePixels()
SDL_DrawPoint()
SDL_DrawPoints()
SDL_BlendPoint()
SDL_BlendPoints()
SDL_DrawLine()
SDL_DrawLines()
SDL_BlendLine()
SDL_BlendLines()
SDL_DrawRect()
SDL_DrawRects()
SDL_BlendRect()
SDL_BlendRects()
SDL_BlendFillRect()
SDL_BlendFillRects()

Changed functions:
Most SDL_Render* functions now take a context as their first parameter.
SDL_CreateTextureFromSurface() no longer needs a format, it
automatically converts to the optimal texture format.
SDL_SetWindowData() and SDL_GetWindowData() handle arbitrary named pointers.

A full log can be found here:
http://hg.libsdl.org/SDL

See ya!

-Sam Lantinga, Founder and CEO, Galaxy Gameworks

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

22

Remember, the renderer might be implemented on Direct3D or running
software rendering, so you can’t guarantee an OpenGL texture is
backing an SDL renderer texture.

If you have gone to the trouble of guaranteeing that you’re using
hardware accelerated OpenGL in your application, you might as well use
it entirely. There’s only about 150 lines of OpenGL code in SDL’s
renderer implementation. :slight_smile:

As for rendering targets, Ken is looking at that right now. I’m
debating whether that falls in the "must have for 1.3 release"
category. Are you doing enough that using a software renderer to draw
on a surface and then updating a texture with that data isn’t fast
enough?

See ya!On Thu, Feb 3, 2011 at 5:03 PM, Mason Wheeler wrote:

groans, rubbing my temples a little

This is gonna be all sorts of fun to update my Delphi headers for the
new rendering API. ?The less stateful API is going to reduce bugs,
though, so that’s worthwhile I guess.

By “fixed the feature set” I certainly hope you don’t mean that the
feature set is now locked down (fixed) and won’t be added to. ?I still
don’t see anything about render targets here, and that’s absolutely
essential.

Also, if we’re supposed to use OpenGL directly to get at useful effects
such as rotation, there needs to be some way to query a texture for
its OpenGL handle. ?I need to rotate less than 1% of the images I’m
rendering, but those ones that do need rotation do need rotation,
and it’s not worth giving up all the high-level image management
routines that the rendering API provides just to deal with that <1% case.
I’d basically just end up reimplementing most of SDL’s rendering in
my own codebase, which is kinda pointless.

Mason

----- Original Message ----
From: Sam Lantinga <@slouken>
Subject: [SDL] SDL 1.3 progress update

This week is a massive update on the rendering systems, simplifying
and improving them:
http://www.libsdl.org/tmp/SDL-1.3.zip

The theme has been focusing and streamlining the 2D rendering API so
that it is clear and easy to use.
To that end, I’ve fixed the feature set for this release, and removed
all partially functional renderers. ?I’ve also added the ability to
create an SDL surface for windows which aren’t using rendering or 3D
functionality, and made it possible to create a software renderer for
arbitrary SDL surfaces. ?Possibly the largest API change is that all
the rendering functions now take a rendering context as their first
parameter, so it’s clear what context they’re acting on.

You can also now create a texture of any format including YUV and SDL
will automatically take care of converting it into the formats
supported by the accelerated renderers. ?This means that new
accelerated renderers need only advertise the optimal texture formats.
Doing this resulted in a 50% speed boost on Mac OS X. :slight_smile:

I’ve also simplified the driver interfaces so if you are porting to a
new platform you only have to implement 3 functions to get SDL 1.2
functionality and a software renderer, and you only have to implement
them if your platform doesn’t already support OpenGL or OpenGL ES.

As you might imagine, this update has reams of new code. ?I’ve done a
bunch of testing but I’m sure there are bugs. ?If you run into them,
please report them at http://bugzilla.libsdl.org/

On the up side, I’m very comfortable with this API set and am going on
to other areas that need love before release. :slight_smile:

Here is the intro to the new SDL_render.h, and a complete list of API changes:

This API supports the following features:
? ?* single pixel points
? ?* single pixel lines
? ?* filled rectangles
? ?* texture images

The primitives may be drawn in opaque, blended, or additive modes.

The texture images may be drawn in opaque, blended, or additive modes.
They can have an additional color tint or alpha modulation applied to
them, and may also be stretched with linear interpolation.

This API is designed to accelerate simple 2D operations. You may
want more functionality such as rotation and particle effects and
in that case you should use SDL’s OpenGL/Direct3D support or one
of the many good 3D engines.

New functions:
SDL_AddEventWatch()
SDL_DelEventWatch()
SDL_GetWindowPixelFormat()
SDL_CreateSoftwareRenderer()
SDL_GetWindowSurface()
SDL_UpdateWindowSurface()
SDL_UpdateWindowSurfaceRects()

Removed functions:
SDL_SetTexturePalette()
SDL_GetTexturePalette()
SDL_SetDisplayPalette()
SDL_GetDisplayPalette()
SDL_RenderWritePixels()
SDL_DrawPoint()
SDL_DrawPoints()
SDL_BlendPoint()
SDL_BlendPoints()
SDL_DrawLine()
SDL_DrawLines()
SDL_BlendLine()
SDL_BlendLines()
SDL_DrawRect()
SDL_DrawRects()
SDL_BlendRect()
SDL_BlendRects()
SDL_BlendFillRect()
SDL_BlendFillRects()

Changed functions:
Most SDL_Render* functions now take a context as their first parameter.
SDL_CreateTextureFromSurface() no longer needs a format, it
automatically converts to the optimal texture format.
SDL_SetWindowData() and SDL_GetWindowData() handle arbitrary named pointers.

A full log can be found here:
http://hg.libsdl.org/SDL

See ya!

? ?-Sam Lantinga, Founder and CEO, Galaxy Gameworks

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

–
? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks

23

Remember, the renderer might be implemented on Direct3D or running
software rendering, so you can’t guarantee an OpenGL texture is
backing an SDL renderer texture.

No, but there’s always some sort of internal handle to a driver-specific
texture.

If you have gone to the trouble of guaranteeing that you’re using
hardware accelerated OpenGL in your application, you might as well use
it entirely. There’s only about 150 lines of OpenGL code in SDL’s
renderer implementation. :slight_smile:

Perhaps, but that’s 150 lines of duplicate code that I don’t want cluttering
up my own codebase if a mature, well-tested library for them already
exists.

As for rendering targets, Ken is looking at that right now. I’m
debating whether that falls in the "must have for 1.3 release"
category. Are you doing enough that using a software renderer to draw
on a surface and then updating a texture with that data isn’t fast
enough?

Absolutely. I’m using render targets for two major things.

  1. Compositing. The original input comes from textures, not surfaces.
    Sometimes, depending on how complicated the compositing work is,
    the original input texture is a render target as well.
  2. Caching. For example, for screen transitions I need to render a
    snapshot of the entire screen and then gradually mutilate it over the
    course of a second or so. Depending on the complexity of the transition,
    this can require one or even two render targets.

Neither of these are things that can be done well with surfaces, because
in both cases the original input comes from textures.>----- Original Message ----

From: Sam Lantinga
Subject: Re: [SDL] SDL 1.3 progress update

24

Great job Sam!

I’m glad I didn’t try to add the DX render target support before all of
these changes to the API :slight_smile:

I’ll work on getting the Render Target support in this weekend.

Ken> ----- Original Message -----

From: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Mason Wheeler
Sent: Thursday, February 03, 2011 7:26 PM
To: SDL Development List
Subject: Re: [SDL] SDL 1.3 progress update

----- Original Message ----

From: Sam Lantinga
Subject: Re: [SDL] SDL 1.3 progress update

Remember, the renderer might be implemented on Direct3D or running
software rendering, so you can’t guarantee an OpenGL texture is
backing an SDL renderer texture.

No, but there’s always some sort of internal handle to a driver-specific
texture.

If you have gone to the trouble of guaranteeing that you’re using
hardware accelerated OpenGL in your application, you might as well use
it entirely. There’s only about 150 lines of OpenGL code in SDL’s
renderer implementation. :slight_smile:

Perhaps, but that’s 150 lines of duplicate code that I don’t want cluttering
up my own codebase if a mature, well-tested library for them already
exists.

As for rendering targets, Ken is looking at that right now. I’m
debating whether that falls in the "must have for 1.3 release"
category. Are you doing enough that using a software renderer to draw
on a surface and then updating a texture with that data isn’t fast
enough?

Absolutely. I’m using render targets for two major things.

  1. Compositing. The original input comes from textures, not surfaces.
    Sometimes, depending on how complicated the compositing work is,
    the original input texture is a render target as well.
  2. Caching. For example, for screen transitions I need to render a
    snapshot of the entire screen and then gradually mutilate it over the
    course of a second or so. Depending on the complexity of the transition,
    this can require one or even two render targets.

Neither of these are things that can be done well with surfaces, because
in both cases the original input comes from textures.

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

25

I’m guessing you’re also using shaders for some of those transitions? :slight_smile:

If you’re using shaders you’re definitely out of scope for the SDL 1.3
render API. :slight_smile:

See ya!On Thu, Feb 3, 2011 at 5:26 PM, Mason Wheeler wrote:

----- Original Message ----

From: Sam Lantinga <@slouken>
Subject: Re: [SDL] SDL 1.3 progress update

Remember, the renderer might be implemented on Direct3D or running
software rendering, so you can’t guarantee an OpenGL texture is
backing an SDL renderer texture.

No, but there’s always some sort of internal handle to a driver-specific
texture.

If you have gone to the trouble of guaranteeing that you’re using
hardware accelerated OpenGL in your application, you might as well use
it entirely. ?There’s only about 150 lines of OpenGL code in SDL’s
renderer implementation. :slight_smile:

Perhaps, but that’s 150 lines of duplicate code that I don’t want cluttering
up my own codebase if a mature, well-tested library for them already
exists.

As for rendering targets, Ken is looking at that right now. ?I’m
debating whether that falls in the "must have for 1.3 release"
category. ?Are you doing enough that using a software renderer to draw
on a surface and then updating a texture with that data isn’t fast
enough?

Absolutely. ?I’m using render targets for two major things.

  1. Compositing. ?The original input comes from textures, not surfaces.
    Sometimes, depending on how complicated the compositing work is,
    the original input texture is a render target as well.
  2. Caching. ?For example, for screen transitions I need to render a
    snapshot of the entire screen and then gradually mutilate it over the
    course of a second or so. Depending on the complexity of the transition,
    this can require one or even two render targets.

Neither of these are things that can be done well with surfaces, because
in both cases the original input comes from textures.

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

–
? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks

26

Actually, no, so far I’m able to implement all the transitions I need
without shaders. But there are other things shaders would be helpful
for. Being able to get the internal handle to my textures would
come in handy there, too. ;)>----- Original Message ----

From: Sam Lantinga
Subject: Re: [SDL] SDL 1.3 progress update

I’m guessing you’re also using shaders for some of those transitions? :slight_smile:

If you’re using shaders you’re definitely out of scope for the SDL 1.3
render API. :slight_smile:

See ya!

27

congrats for the update that brings us speed boost (and let’s hope
more stability as well)
what next on your todo list before release?

VittorioOn Fri, Feb 4, 2011 at 1:37 AM, Sam Lantinga wrote:

This week is a massive update on the rendering systems, simplifying
and improving them:
http://www.libsdl.org/tmp/SDL-1.3.zip

[…]

On the up side, I’m very comfortable with this API set and am going on
to other areas that need love before release. :slight_smile:

28

Hi Sam,

the simplification is very welcome! Unfortunately SDL_BLENDMODE_MOD has
been removed. This is extensively used by mame (www.mamedev.org). It’s
been working in prior svn versions as well.

If I am missing something, please let me know.

Kind regards,

CouriersudOn Thu, 2011-02-03 at 16:37 -0800, Sam Lantinga wrote:

This week is a massive update on the rendering systems, simplifying
and improving them:
http://www.libsdl.org/tmp/SDL-1.3.zip

The theme has been focusing and streamlining the 2D rendering API so
that it is clear and easy to use.
To that end, I’ve fixed the feature set for this release, and removed
all partially functional renderers. I’ve also added the ability to
create an SDL surface for windows which aren’t using rendering or 3D
functionality, and made it possible to create a software renderer for
arbitrary SDL surfaces. Possibly the largest API change is that all
the rendering functions now take a rendering context as their first
parameter, so it’s clear what context they’re acting on.

You can also now create a texture of any format including YUV and SDL
will automatically take care of converting it into the formats
supported by the accelerated renderers. This means that new
accelerated renderers need only advertise the optimal texture formats.
Doing this resulted in a 50% speed boost on Mac OS X. :slight_smile:

I’ve also simplified the driver interfaces so if you are porting to a
new platform you only have to implement 3 functions to get SDL 1.2
functionality and a software renderer, and you only have to implement
them if your platform doesn’t already support OpenGL or OpenGL ES.

As you might imagine, this update has reams of new code. I’ve done a
bunch of testing but I’m sure there are bugs. If you run into them,
please report them at http://bugzilla.libsdl.org/

On the up side, I’m very comfortable with this API set and am going on
to other areas that need love before release. :slight_smile:

Here is the intro to the new SDL_render.h, and a complete list of API changes:

This API supports the following features:
* single pixel points
* single pixel lines
* filled rectangles
* texture images

The primitives may be drawn in opaque, blended, or additive modes.

The texture images may be drawn in opaque, blended, or additive modes.
They can have an additional color tint or alpha modulation applied to
them, and may also be stretched with linear interpolation.

This API is designed to accelerate simple 2D operations. You may
want more functionality such as rotation and particle effects and
in that case you should use SDL’s OpenGL/Direct3D support or one
of the many good 3D engines.

New functions:
SDL_AddEventWatch()
SDL_DelEventWatch()
SDL_GetWindowPixelFormat()
SDL_CreateSoftwareRenderer()
SDL_GetWindowSurface()
SDL_UpdateWindowSurface()
SDL_UpdateWindowSurfaceRects()

Removed functions:
SDL_SetTexturePalette()
SDL_GetTexturePalette()
SDL_SetDisplayPalette()
SDL_GetDisplayPalette()
SDL_RenderWritePixels()
SDL_DrawPoint()
SDL_DrawPoints()
SDL_BlendPoint()
SDL_BlendPoints()
SDL_DrawLine()
SDL_DrawLines()
SDL_BlendLine()
SDL_BlendLines()
SDL_DrawRect()
SDL_DrawRects()
SDL_BlendRect()
SDL_BlendRects()
SDL_BlendFillRect()
SDL_BlendFillRects()

Changed functions:
Most SDL_Render* functions now take a context as their first parameter.
SDL_CreateTextureFromSurface() no longer needs a format, it
automatically converts to the optimal texture format.
SDL_SetWindowData() and SDL_GetWindowData() handle arbitrary named pointers.

A full log can be found here:
http://hg.libsdl.org/SDL

See ya!

-Sam Lantinga, Founder and CEO, Galaxy Gameworks
29

Good to hear that SDL 1.3 is really under heavy development and that nig speed increases have been found. For those of us who are thinking of using SDL in a commercial project, I guess we need some reassurance that the API won’t have any more changes on the scale of the new rendering stuff (until SDL 3.0 anyway :P) ?

Cheers
Ed

30

No, that was the last big API change planned. There are a few tweaks still
going on, but the video API is solid.

Thanks!On Sat, Feb 5, 2011 at 2:32 AM, ebyard <e_byard at yahoo.co.uk> wrote:

Good to hear that SDL 1.3 is really under heavy development and that nig
speed increases have been found. For those of us who are thinking of using
SDL in a commercial project, I guess we need some reassurance that the API
won’t have any more changes on the scale of the new rendering stuff (until
SDL 3.0 anyway [image: Razz]) ?

Cheers
Ed

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

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

31

In my engine I’ve had to modify SDL 1.3 to open a GLES2 context on iPhoneOS because I don’t support GLES1 and have no interest in it - the GLES1 chips are rather non-performant :slight_smile:

There ought to be a proper way to do this, perhaps checking the context major version?

The offending line:
src/video/uikit/SDL_uikitopenglview.m: context = [[EAGLContext alloc] initWithAPI: kEAGLRenderingAPIOpenGLES1];

Thanks.–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

32

wasn’t a gles2 render added, oh, like yesterday?
if i get i correctly you just need to select it when you create a
render for the window

ps: thanks for the addition Sam, 1.3 is becoming more and more mature every day!

VittorioOn Mon, Feb 7, 2011 at 8:12 AM, Forest Hale wrote:

In my engine I’ve had to modify SDL 1.3 to open a GLES2 context on iPhoneOS
because I don’t support GLES1 and have no interest in it - the GLES1 chips
are rather non-performant :slight_smile:

There ought to be a proper way to do this, perhaps checking the context
major version?

The offending line:
src/video/uikit/SDL_uikitopenglview.m: ? ? ? ?context = [[EAGLContext alloc]
initWithAPI: kEAGLRenderingAPIOpenGLES1];

Thanks.

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

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

33

laugh Yeah, I just fixed this yesterday.

SDL 1.3 should automatically select an OpenGL ES 2 context on iOS in
the next snapshot. You can specify whether you want GLES1 or 2 by
using:
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 1 or 2) in your iOS app.

See ya!On Sun, Feb 6, 2011 at 11:12 PM, Forest Hale wrote:

In my engine I’ve had to modify SDL 1.3 to open a GLES2 context on iPhoneOS
because I don’t support GLES1 and have no interest in it - the GLES1 chips
are rather non-performant :slight_smile:

There ought to be a proper way to do this, perhaps checking the context
major version?

The offending line:
src/video/uikit/SDL_uikitopenglview.m: ? ? ? ?context = [[EAGLContext alloc]
initWithAPI: kEAGLRenderingAPIOpenGLES1];

Thanks.

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

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

–
? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks

34

Okay, I just pushed this in the latest snapshot:
http://www.libsdl.org/tmp/SDL-1.3.zip

I changed to create the OpenGL ES 1 context by default so nobody is
surprised in the change of behavior, but all you have to do to get an
OpenGL ES 2 context is add this before you create your context:

SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);

See ya!On Mon, Feb 7, 2011 at 1:00 AM, Sam Lantinga <@slouken> wrote:

laugh ?Yeah, I just fixed this yesterday.

SDL 1.3 should automatically select an OpenGL ES 2 context on iOS in
the next snapshot. ?You can specify whether you want GLES1 or 2 by
using:
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 1 or 2) in your iOS app.

See ya!

On Sun, Feb 6, 2011 at 11:12 PM, Forest Hale wrote:

In my engine I’ve had to modify SDL 1.3 to open a GLES2 context on iPhoneOS
because I don’t support GLES1 and have no interest in it - the GLES1 chips
are rather non-performant :slight_smile:

There ought to be a proper way to do this, perhaps checking the context
major version?

The offending line:
src/video/uikit/SDL_uikitopenglview.m: ? ? ? ?context = [[EAGLContext alloc]
initWithAPI: kEAGLRenderingAPIOpenGLES1];

Thanks.

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

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

–
? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks

–
? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks

35

umh i did some experiments, but i got mixed results
i haven’t run any benchmark yet, but in a mixed sdl+opengl program if i do
SDLrender:= SDL_CreateRenderer(SDLwindow, -1, 1 and 2);
the opengles2 gets selected and at the first glMatrixMode i get an
error in glUnimplemented
i’m able to select a gles1.1 context by doing
SDL_CreateRenderer(SDLwindow, 1, 1 and 2);
perhaps i’m doing something wrong…

oh it’s really time to port our game to sdl 1.3 textures :slight_smile:
VittorioOn Mon, Feb 7, 2011 at 6:25 PM, Sam Lantinga wrote:

Okay, I just pushed this in the latest snapshot:
http://www.libsdl.org/tmp/SDL-1.3.zip

I changed to create the OpenGL ES 1 context by default so nobody is
surprised in the change of behavior, but all you have to do to get an
OpenGL ES 2 context is add this before you create your context:

SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);

See ya!

On Mon, Feb 7, 2011 at 1:00 AM, Sam Lantinga wrote:

laugh ?Yeah, I just fixed this yesterday.

SDL 1.3 should automatically select an OpenGL ES 2 context on iOS in
the next snapshot. ?You can specify whether you want GLES1 or 2 by
using:
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 1 or 2) in your iOS app.

See ya!

On Sun, Feb 6, 2011 at 11:12 PM, Forest Hale wrote:

In my engine I’ve had to modify SDL 1.3 to open a GLES2 context on iPhoneOS
because I don’t support GLES1 and have no interest in it - the GLES1 chips
are rather non-performant :slight_smile:

There ought to be a proper way to do this, perhaps checking the context
major version?

The offending line:
src/video/uikit/SDL_uikitopenglview.m: ? ? ? ?context = [[EAGLContext alloc]
initWithAPI: kEAGLRenderingAPIOpenGLES1];

Thanks.

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

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

–
? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks

–
? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks

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

36

OpenGL ES 2.0 is a completely different API from 1.1. glMatrixMode()
is not a part of OpenGL ES 2, instead you’re expected to handle all of
your state and transformation via vertex and fragment shaders.

FYI, I put the default back to OpenGL ES 1.1, so people don’t get
unexpectedly bitten by this (although the renderer will create a 2.0
context because it assumes you’re not doing other OpenGL rendering as
well) In that case you’ll need to set the SDL_HINT_RENDER_DRIVER hint
to “opengles”, which will pick the older renderer.

See ya!On Mon, Feb 7, 2011 at 1:53 PM, Vittorio G. <vitto.giova at yahoo.it> wrote:

umh i did some experiments, but i got mixed results
i haven’t run any benchmark yet, but in a mixed sdl+opengl program if i do
? ? ? ?SDLrender:= SDL_CreateRenderer(SDLwindow, -1, 1 and 2);
the opengles2 gets selected and at the first glMatrixMode i get an
error in glUnimplemented
i’m able to select a gles1.1 context by doing
SDL_CreateRenderer(SDLwindow, 1, 1 and 2);
perhaps i’m doing something wrong…

oh it’s really time to port our game to sdl 1.3 textures :slight_smile:
Vittorio

On Mon, Feb 7, 2011 at 6:25 PM, Sam Lantinga <@slouken> wrote:

Okay, I just pushed this in the latest snapshot:
http://www.libsdl.org/tmp/SDL-1.3.zip

I changed to create the OpenGL ES 1 context by default so nobody is
surprised in the change of behavior, but all you have to do to get an
OpenGL ES 2 context is add this before you create your context:

SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);

See ya!

On Mon, Feb 7, 2011 at 1:00 AM, Sam Lantinga <@slouken> wrote:

laugh ?Yeah, I just fixed this yesterday.

SDL 1.3 should automatically select an OpenGL ES 2 context on iOS in
the next snapshot. ?You can specify whether you want GLES1 or 2 by
using:
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 1 or 2) in your iOS app.

See ya!

On Sun, Feb 6, 2011 at 11:12 PM, Forest Hale wrote:

In my engine I’ve had to modify SDL 1.3 to open a GLES2 context on iPhoneOS
because I don’t support GLES1 and have no interest in it - the GLES1 chips
are rather non-performant :slight_smile:

There ought to be a proper way to do this, perhaps checking the context
major version?

The offending line:
src/video/uikit/SDL_uikitopenglview.m: ? ? ? ?context = [[EAGLContext alloc]
initWithAPI: kEAGLRenderingAPIOpenGLES1];

Thanks.

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

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

–
? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks

–
? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks

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

–
? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks

37

Just a small Question this time: Have you already begun to translate the
"new" headers to Delphi / Pascal-Code?

Cheers,
Alexander.Am 04.02.11 02:03, schrieb Mason Wheeler:

groans, rubbing my temples a little

This is gonna be all sorts of fun to update my Delphi headers for the
new rendering API. The less stateful API is going to reduce bugs,
though, so that’s worthwhile I guess.

By “fixed the feature set” I certainly hope you don’t mean that the
feature set is now locked down (fixed) and won’t be added to. I still
don’t see anything about render targets here, and that’s absolutely
essential.

Also, if we’re supposed to use OpenGL directly to get at useful effects
such as rotation, there needs to be some way to query a texture for
its OpenGL handle. I need to rotate less than 1% of the images I’m
rendering, but those ones that do need rotation do need rotation,
and it’s not worth giving up all the high-level image management
routines that the rendering API provides just to deal with that <1% case.
I’d basically just end up reimplementing most of SDL’s rendering in
my own codebase, which is kinda pointless.

Mason

----- Original Message ----
From: Sam Lantinga
Subject: [SDL] SDL 1.3 progress update

This week is a massive update on the rendering systems, simplifying
and improving them:
http://www.libsdl.org/tmp/SDL-1.3.zip

The theme has been focusing and streamlining the 2D rendering API so
that it is clear and easy to use.
To that end, I’ve fixed the feature set for this release, and removed
all partially functional renderers. I’ve also added the ability to
create an SDL surface for windows which aren’t using rendering or 3D
functionality, and made it possible to create a software renderer for
arbitrary SDL surfaces. Possibly the largest API change is that all
the rendering functions now take a rendering context as their first
parameter, so it’s clear what context they’re acting on.

You can also now create a texture of any format including YUV and SDL
will automatically take care of converting it into the formats
supported by the accelerated renderers. This means that new
accelerated renderers need only advertise the optimal texture formats.
Doing this resulted in a 50% speed boost on Mac OS X. :slight_smile:

I’ve also simplified the driver interfaces so if you are porting to a
new platform you only have to implement 3 functions to get SDL 1.2
functionality and a software renderer, and you only have to implement
them if your platform doesn’t already support OpenGL or OpenGL ES.

As you might imagine, this update has reams of new code. I’ve done a
bunch of testing but I’m sure there are bugs. If you run into them,
please report them at http://bugzilla.libsdl.org/

On the up side, I’m very comfortable with this API set and am going on
to other areas that need love before release. :slight_smile:

Here is the intro to the new SDL_render.h, and a complete list of API changes:

This API supports the following features:
* single pixel points
* single pixel lines
* filled rectangles
* texture images

The primitives may be drawn in opaque, blended, or additive modes.

The texture images may be drawn in opaque, blended, or additive modes.
They can have an additional color tint or alpha modulation applied to
them, and may also be stretched with linear interpolation.

This API is designed to accelerate simple 2D operations. You may
want more functionality such as rotation and particle effects and
in that case you should use SDL’s OpenGL/Direct3D support or one
of the many good 3D engines.

New functions:
SDL_AddEventWatch()
SDL_DelEventWatch()
SDL_GetWindowPixelFormat()
SDL_CreateSoftwareRenderer()
SDL_GetWindowSurface()
SDL_UpdateWindowSurface()
SDL_UpdateWindowSurfaceRects()

Removed functions:
SDL_SetTexturePalette()
SDL_GetTexturePalette()
SDL_SetDisplayPalette()
SDL_GetDisplayPalette()
SDL_RenderWritePixels()
SDL_DrawPoint()
SDL_DrawPoints()
SDL_BlendPoint()
SDL_BlendPoints()
SDL_DrawLine()
SDL_DrawLines()
SDL_BlendLine()
SDL_BlendLines()
SDL_DrawRect()
SDL_DrawRects()
SDL_BlendRect()
SDL_BlendRects()
SDL_BlendFillRect()
SDL_BlendFillRects()

Changed functions:
Most SDL_Render* functions now take a context as their first parameter.
SDL_CreateTextureFromSurface() no longer needs a format, it
automatically converts to the optimal texture format.
SDL_SetWindowData() and SDL_GetWindowData() handle arbitrary named pointers.

A full log can be found here:
http://hg.libsdl.org/SDL

See ya!

-Sam Lantinga, Founder and CEO, Galaxy Gameworks

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

-------------- next part --------------
A non-text attachment was scrubbed…
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110210/71419fd5/attachment.pgp

38

It’s been another busy week…
Here’s a summary of the things that have changed in the SDL snapshot
recently:
http://www.libsdl.org/tmp/SDL-1.3.zip

  • Added Win32 and X11 window surface implementations
  • Re-added SDL_BLENDMODE_MOD
  • Fixed SDL_SetTextureBlendMode()
  • Added a new configuration hint API in SDL_hints.h (
    http://hg.libsdl.org/SDL/file/default/include/SDL_hints.h), along with a
    bunch of render hints.
  • Added a new logging API in SDL_log.h (
    http://hg.libsdl.org/SDL/file/default/include/SDL_log.h)
  • Added an OpenGL ES renderer, contributed by itsnotabigtruck
  • Added function SDL_RenderSetClipRect()
  • Made it possible to disable the assembly atomic operations at a huge
    performance penalty.
  • Made it possible to disable the rendering system with --disable-render
  • Added an alternate OpenGL rendering path using GLSL shaders for a slight
    performance improvement
  • Added YV12 texture support to the OpenGL renderer using shaders for a 50x
    performance improvement
  • Added an example of using GLSL in an SDL application (
    http://hg.libsdl.org/SDL/file/default/test/testshader.c)
  • Added a scaling test program
  • Removed the gamma API since it’s not well supported nowadays.
  • Display mode functions now take an explicit display index parameter (0
    means the primary display)
  • Window coordinates are now in the global space, and windows are no longer
    bound to the display they are created on.
  • Fixed toggling fullscreen mode on Mac OS X (still not completely working
    on Windows and Linux)
  • Added an example of using texture streaming (
    http://hg.libsdl.org/SDL/file/default/test/teststreaming.c)
  • Updated CPU info API, removed Altivec, and 3DNow! queries, added SSE3,
    SSE4.1 and SSE4.1 queries.
  • Merged Eric Wing’s changes for a universal iOS library
  • Fixed crash trying to free the screen surface returned by
    SDL_SetVideoMode()
  • The screen surface returned by SDL_SetVideoMode() is centered in the
    window if the requested fullscreen mode isn’t available.
  • SDL_PixelFormat structure contains the appropriate SDL_PIXELFORMAT_*
    enumeration corresponding to its format.
  • The palette watch API is no longer needed and has been removed.

Whew! :slight_smile:

A full log can be found here:
http://hg.libsdl.org/SDL

See ya!–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

39

Just a reminder for anyone who wants more frequent updates on development
progress, I’ve started showing off the fun stuff as I do it on facebook and
twitter:
http://www.facebook.com/libsdl
http://twitter.com/libsdl

I also have a blog where I document some of the more interesting things I’m
learning:

See ya!–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

40

Lots of good stuff went in this past week:
http://www.libsdl.org/tmp/SDL-1.3.zip

  • Updates to the Nintendo DS support by Frank Zago.
  • Fixed crash while resizing a window on Mac OS X.
  • The screen created by SDL_SetVideoMode() is now centered if the
    requested video mode wasn’t available.
  • Updated the Visual Studio 2005 project.
  • Added SDL_BlitScaled() as a work in progress by Ken Rogoway -
    scaling works, clipping doesn’t.
  • Added SDL_RenderSetViewport() which replaces the previous
    SDL_RenderSetClipRect() API.
  • The viewport is automatically set when the window is resized to
    center the previous viewport. You can override this by calling
    SDL_RenderSetViewport() in response to the SDL_WINDOWEVENT_RESIZED
    event.
  • Fixed the API for SDL_RenderDrawRects(), SDL_RenderFillRects() and
    SDL_FillRects() - it should be a pointer to an array of rectangles,
    not an array of pointers to rectangles.
  • The order of parameters to SDL_UpdateWindowSurfaceRects() was fixed
    to be consistent with other multi-rectangle update functions (rects
    followed by numrects.)
  • Fixed a bug where the YV12 texture format was picked for RGB formats
    on the OpenGL renderer.
  • Fullscreen toggling is implemented on Mac OS X 10.6, Windows, and Linux.
  • Fixed bug #963 (Crash with OpenGL & window resizing)
  • Fixed bug #1085 (Jump to NULL function pointer on ALSA_OpenDevice)
  • Fixed bug #1121 (More than one device through SDL_JOYSTICK_DEVICE)
  • You can now disable SDL’s main() override by defining
    SDL_MAIN_HANDLED before including SDL.h. This still needs some work
    on iOS since there is already a main() in libSDL.a. In general I want
    to improve SDL’s native integration on various platforms.
  • You can now build directly from a fresh Mercurial checkout
  • If you want access to SDL_REVISION you must include SDL_revision.h
  • Fixed bug #1090 (SDL_BlitCopyOverlap() assumes memcpy() operates in order)
  • Renamed SDL_keysym.h to SDL_keycode.h to avoid confusion.
  • There are bindings to the Google “Go” language at
    https://github.com/banthar/Go-SDL
  • Fixed bug 1122 (spinlock fails to compile with -march=armv4t)
  • Fixed crash when drawing non-textured primitives on OpenGL ES
  • Fixed bug 1128 (improve performance of SDL_mutex on Windows)
  • You can pass SDL_RENDERER_SOFTWARE to SDL_CreateRenderer() to
    explicitly request the software renderer.
  • Streaming textures are initialized to 0
  • SDL_assert.h is now included in SDL.h
  • Added OpenGL state caching for a decent speed improvement.
  • Edgar Simo added a simple rumble API based on the existing haptic system:
    • SDL_HapticRumbleSupported()
    • SDL_HapticRumbleInit()
    • SDL_HapticRumblePlay()
    • SDL_HapticRumbleStop()

A full log can be found here:
http://hg.libsdl.org/SDL

See ya!–
? ? -Sam Lantinga, Founder and CEO, Galaxy Gameworks