The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Here's a summary of the things that have changed in the SDL snapshot recently:
http://www.libsdl.org/tmp/SDL-1.3.zip

* Removed glu.h from SDL_opengl.h
* Fixed mouse events on Windows, thanks to John Wilson
* Removed PS3 Linux code, since that platform is no more...
* Removed Framebuffer Console and SVGAlib drivers due to lack of maintainers
* Fixed potential event queue overflow with window move events on Windows
* Fixed detecting and using the native iconv library
* The Visual Studio 2008 and 2010 projects were updated to use the debug C runtime when built in Debug configuration
* The Visual Studio 2008 and 2010 projects were updated to copy SDL.dll and necessary data when building tests
* Fixed building with the latest Xcode on Mac OS X and iOS* Completely revised the atomic API, pending industry expert review
* Reviewed and greatly improved the Android support  (working 2D renderer, working audio, keycode translation, improved documentation in README.android etc.)
* Fixed texture format bugs in OpenGL ES renderer
* Fixed restoring the desktop resolution on Mac OS X
* Fixed crash resizing non-shaped windows

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

See ya!
--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

I am unable to compile/link it on MingW + msys (32bit compilers, 64bit-processor).

It says:

Creating library file: build/.libs/libSDL.dll.a
build/.libs/SDL_atomic.o: In function `SDL_AtomicSetPtr':
C:\MinGW\msys\1.0\home\Jos\SDL-1.3.0-5050/src/atomic/SDL_atomic.c:148: undefined
reference to `__sync_bool_compare_and_swap_4'

How can I fix this? Compile without the atomic internals?


With kind regards,

Jos

From: [mailto:] On Behalf Of Sam Lantinga
Sent: donderdag 20 januari 2011 8:09
To: SDL
Subject: [SDL] SDL 1.3 progress update

Here's a summary of the things that have changed in the SDL snapshot recently:
http://www.libsdl.org/tmp/SDL-1.3.zip

* Removed glu.h from SDL_opengl.h
* Fixed mouse events on Windows, thanks to John Wilson
* Removed PS3 Linux code, since that platform is no more...
* Removed Framebuffer Console and SVGAlib drivers due to lack of maintainers
* Fixed potential event queue overflow with window move events on Windows
* Fixed detecting and using the native iconv library
* The Visual Studio 2008 and 2010 projects were updated to use the debug C runtime when built in Debug configuration
* The Visual Studio 2008 and 2010 projects were updated to copy SDL.dll and necessary data when building tests
* Fixed building with the latest Xcode on Mac OS X and iOS* Completely revised the atomic API, pending industry expert review
* Reviewed and greatly improved the Android support (working 2D renderer, working audio, keycode translation, improved documentation in README.android etc.)
* Fixed texture format bugs in OpenGL ES renderer
* Fixed restoring the desktop resolution on Mac OS X
* Fixed crash resizing non-shaped windows

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

See ya!
--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1191 / Virus Database: 1435/3390 - Release Date: 01/19/11

I tried compiling with –disable-gcc-atomics and with that one plus –disable-atomic, same result:

src/atomic/SDL_spinlock.c: In functie 'SDL_AtomicTryLock':
src/atomic/SDL_spinlock.c:58:5: fout: '__need_spinlock_implementation__' undecla
red (first use in this function)
src/atomic/SDL_spinlock.c:58:5: note: each undeclared identifier is reported onl
y once for each function it appears in
src/atomic/SDL_spinlock.c:60:1: fout: expected ';' before '}' token
make: *** [build/SDL_spinlock.lo] Error 1

Is this a build bug?

Jos


From: [mailto:] On Behalf Of Jos Kuijpers
Sent: donderdag 20 januari 2011 13:31
To: 'SDL Development List'
Subject: Re: [SDL] SDL 1.3 progress update



I am unable to compile/link it on MingW + msys (32bit compilers, 64bit-processor).

It says:

Creating library file: build/.libs/libSDL.dll.a
build/.libs/SDL_atomic.o: In function `SDL_AtomicSetPtr':
C:\MinGW\msys\1.0\home\Jos\SDL-1.3.0-5050/src/atomic/SDL_atomic.c:148: undefined
reference to `__sync_bool_compare_and_swap_4'

How can I fix this? Compile without the atomic internals?


With kind regards,

Jos

From: [mailto:] On Behalf Of Sam Lantinga
Sent: donderdag 20 januari 2011 8:09
To: SDL
Subject: [SDL] SDL 1.3 progress update

Here's a summary of the things that have changed in the SDL snapshot recently:
http://www.libsdl.org/tmp/SDL-1.3.zip

* Removed glu.h from SDL_opengl.h
* Fixed mouse events on Windows, thanks to John Wilson
* Removed PS3 Linux code, since that platform is no more...
* Removed Framebuffer Console and SVGAlib drivers due to lack of maintainers
* Fixed potential event queue overflow with window move events on Windows
* Fixed detecting and using the native iconv library
* The Visual Studio 2008 and 2010 projects were updated to use the debug C runtime when built in Debug configuration
* The Visual Studio 2008 and 2010 projects were updated to copy SDL.dll and necessary data when building tests
* Fixed building with the latest Xcode on Mac OS X and iOS* Completely revised the atomic API, pending industry expert review
* Reviewed and greatly improved the Android support (working 2D renderer, working audio, keycode translation, improved documentation in README.android etc.)
* Fixed texture format bugs in OpenGL ES renderer
* Fixed restoring the desktop resolution on Mac OS X
* Fixed crash resizing non-shaped windows

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

See ya!
--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1191 / Virus Database: 1435/3390 - Release Date: 01/19/11

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1191 / Virus Database: 1435/3391 - Release Date: 01/19/11

For the time being, just add CFLAGS="-march=i686" (or add that to
whatever CFLAGS you're already passing) when you run configure.

I've provided a more automagical fix, but there are concerns about
that fix. Hopefully we can come up with a good clean fix that makes
everyone happy soon!

On Thu, Jan 20, 2011 at 06:30, Jos Kuijpers wrote:



--
Do what you can, where you are, with what you have. - T. Roosevelt
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Ok, Thanks. That works.
The windows mouse buttons work too now J
Just the keyboard, key repetition is turned on by default now. Was not the case 30 revisions ago.

Jos


From: [mailto:] On Behalf Of Greg Jandl
Sent: donderdag 20 januari 2011 15:17
To: SDL Development List
Subject: Re: [SDL] SDL 1.3 progress update



For the time being, just add CFLAGS="-march=i686" (or add that to
whatever CFLAGS you're already passing) when you run configure.

I've provided a more automagical fix, but there are concerns about
that fix. Hopefully we can come up with a good clean fix that makes
everyone happy soon!

On Thu, Jan 20, 2011 at 06:30, Jos Kuijpers wrote:



--
Do what you can, where you are, with what you have. - T. Roosevelt
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1191 / Virus Database: 1435/3391 - Release Date: 01/19/11

Hi Sam, Hi guys,

I which to complain on PS3 Linux code removal :p

It's not completly true that the plateform is no more:
- I believe some guys didn't upgrade their PS3 just to keep the ability to run Linux
- marcan42 got Linux running on PS3 without the otheros. He didn't release the tools to let anyone do that, but he will some day.

I don't know what is your position about "homebrew SDL support", but if you don't mind supporting "not constructor based" plateform (i.e. Wii Homebrew & PS3 homebrew Linux), maybe you could leave the PS3 code for a couple of month ? just give some time to hackers like marcan to bring back Linux on PS3.

While some drivers are a outdated, and brought me a lot of confusion when porting the SDL to PSL1GHT, the PS3 code on the other gave me a lot of clues (like the beos and nds driver). Last thing, for people who port the SDL to other plateforms, the PS3 code is also interesting because it uses the SPUs, so it can give clues on how to use a coprocessor that hasn't the same ISA then the main CPU.

Anyway, I will need the PS3 code to use the SPU on the PSL1GHT port (for sound stuff for instance), so if you really can't stand the PS3 Code, maybe I can keep it on my fork (for experiments and just in case some day someone needs).

Anyway thanks for for your work ^^

On Thu, Jan 20, 2011 at 8:08 AM, Sam Lantinga wrote:

On Thu, Jan 20, 2011 at 11:29 PM, Seb DA ROCHA wrote:

I also think that will be very interesting (even more interesting than
running on Linux to me), and will help future port of programs like XBMC.

- Jiang
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I'm happy to bring it back if someone is willing to maintain it.  I just can't test it and don't currently have anyone who's said they're willing to improve it.

See ya!

On Thu, Jan 20, 2011 at 2:29 PM, Seb DA ROCHA wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

[snip]


If you don't mind using a dirty, dirty hack, you could try specifying
a preprocessor define that, if provided on the command line, will be
used as a file name for the include directive at some particular
point. That way external groups could add backends in a somewhat
seamless way.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I can't test it either... for now. But as soon as Linux will be available, I would be happy to maintain it.

I don't think I'll have much time to improve it, but I can at least maintain it :)

I won't have enough time to improve

On Fri, Jan 21, 2011 at 12:34 AM, Sam Lantinga wrote:

For the xcode project of SDL1.3
I could built it (even the first 2 projets for SDK10.4 and 10.6) but ...
as SDL_scanmode. h and SDL_blendmode.h are not "public" they are not copied to the framework and they are needed if you want to include SDL_video.h ...

Il giorno 20/gen/2011 08.08, "Sam Lantinga" ha scritto:
Hi,
I wanted to ask about the haiku port: in the sdl 1.3 code, there is still a beos platform (which haiku is compatible with), though it doesn't build because the video part is a full copy of the 1.2 code. I was wondering if it'd be better for 1.3 to drop the beos platform and introduce a haiku platform.
Reasons to do this: beos isn't developed any more, and haiku is a complete replacement for it.

Here's a summary of the things that have changed in the SDL snapshot recently:
http://www.libsdl.org/tmp/SDL-1.3.zip

* Redesigned the SDL atomic operation API in SDL_atomic.h
* Completely rewritten and improved timer implementation
* Removed unmaintained RISC OS code
* SDL now builds with Visual Studio 2008 and the Windows Mobile 5.0 SDK
* Renamed SDL_keysym to SDL_KeySym for consistency
* Fixed application name in PulseAudio sound preferences dialog
* Fixed double-mouse motion events on Mac OS X
* Fixed mouse wheel events in fullscreen mode on Mac OS X
* Added the ability to get the UIKit window through the SDL API for completeness
* Fixed UIKit double-free error
* Fixed pitch handling in GLES_UpdateTexture()
* Improved OpenGL ES performance

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

See ya!
--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

FYI, this is fixed in the latest snapshot.

On Sat, Jan 22, 2011 at 12:42 AM, vernier wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Interesting. Improved how?


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

* Completely rewritten and improved timer implementation

Much higher resolution, better multi-threading characteristics.

On Thu, Jan 27, 2011 at 3:55 PM, Mason Wheeler wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Is there a way to build SDL_timer and SDL_assert without atomic
support? Trying with it, and the Nintendo DS build gives "hardware
does not support" XYZ error. I tried building the library with the
following in the nds config file:

#define SDL_ATOMIC_DISABLED 1
#define SDL_HAPTIC_DISABLED 1
#define SDL_TOUCH_DISABLED 1
#define SDL_DISABLE_ATOMIC_INLINE 1

but still get undefined reference to SDL_Atomic* errors when building
the test program.

thoughts?

John

On Thu, Jan 27, 2011 at 5:56 PM, Sam Lantinga wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

That's next on my list to hit.

On Fri, Jan 28, 2011 at 8:33 PM, John Magnotti wrote:



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

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. :)

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. :)

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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

That's really awesome, Sam, I can't wait to give it a run :)

On Thu, Feb 3, 2011 at 7:37 PM, Sam Lantinga 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
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. :)

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. :)

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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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. :)

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:



--
    -Sam Lantinga, Founder and CEO, Galaxy Gameworks
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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


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.


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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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 :)

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

Ken

-----Original Message-----
From: [mailto:] 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



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


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.


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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I'm guessing you're also using shaders for some of those transitions? :)

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

See ya!

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



--
    -Sam Lantinga, Founder and CEO, Galaxy Gameworks
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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. ;)




_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

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?

Vittorio
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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,

Couriersud




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


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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 ) ?

Cheers
Ed

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 wrote:



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

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:



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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! :)

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

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

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:
http://slouken.blogspot.com/

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

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
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Sun, 13 Feb 2011, Sam Lantinga wrote:


why was altivec and 3dnow removed, were these only used for software
rendering which i think was removed too ?
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Software rendering wasn't removed, but the altivec and 3dnow
instruction sets aren't used much now, and I was cleaning up the API.

On Sun, Feb 20, 2011 at 4:35 PM, wrote:



--
    -Sam Lantinga, Founder and CEO, Galaxy Gameworks
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Sun, 2011-02-20 at 18:46 -0800, Sam Lantinga wrote:

I assume your reasoning is that any new apps/games developed using SDL
1.3 will not be programmed for 3dnow and Altivec? Were they really that
much of a maintenance burden?

There are to people still using these instructions such as myself with
an Athlon XP where BlitRGBtoRGBPixelAlphaMMX3DNOW within SDL still
provided a speed up.

Alan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi,

Also, OLPC is the main modern 'modern' CPU which supports 3dnow but not(much) SSE.


For that platform you need all the performance you can get :)


I guess xbox360 supporting altivec is still quite common, even if the amount of PPC macs floating around isn't.




cya.



On Mon, Feb 21, 2011 at 8:56 AM, Alan Swanson wrote:

On the PS3 too, but i hope stop using software renderer soon

On the other hand i believe what slows down the most is the throughput of the CPU/Mem -> GPU, not the CPU power...

On Mon, Feb 21, 2011 at 12:59 PM, René Dudfield wrote:

Hey Sam

This is all really cool, I'm really impressed with the work being done on SDL 1.3. Only question is, how is the documentation (the wiki specifically) going to be managed? With the new rendering stuff, there are sure to be a lot of questions for people, and the wiki is going to need a lot of work. I guess it needs a GSoC type thing where people write (boo) instead of code (yay!) with some kind of mentor/project manager overseeing each part of the API. Maybe something to think about?

With a top-class wiki I am sure SDL will become even more popular.

Ed

Okay, I'll add those back in when I get a chance.

Thanks for the feedback!

On Mon, Feb 21, 2011 at 3:59 AM, René Dudfield wrote:



--
    -Sam Lantinga, Founder and CEO, Galaxy Gameworks
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Okay, the 3DNow! and AltiVec instruction support is back!

I've also added the appropriate intrinsic includes into SDL_cpuinfo.h
so you can directly start using the intrinsics if they're supported by
your compiler.

On Mon, Feb 21, 2011 at 5:26 PM, Sam Lantinga wrote:



--
    -Sam Lantinga, Founder and CEO, Galaxy Gameworks
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Here's a summary of the things that have changed in the SDL snapshot recently:
http://www.libsdl.org/tmp/SDL-1.3.zip

* Fixed compiling on Mac OS X 10.4.
* Fixed bug 1136 (problems with testgles on iOS)
* Fixed bug 1137, updated the iOS keyboard demo with latest rendering
API changes.
* Fixed the iOS fireworks demo.
* Fixed bug 1105 (SDL_GetMouseState returns wrong location upon window
re-activation)
* Fixed mouse coordinate clipping (valid range is 0,0 -> w-1,h-1)
* Fixed building SDL for iOS 3.1.3.
* Implemented Mac OS X icon support.
* Implemented Mac OS X cursor support.
* Implemented Mac OS X mouse warp/relative mode support.
* Added SDL_ConvertSurfaceFormat() utility function.
* Added disabled "Preferences" menu option so SDL application menu
looks more correct on Mac OS X.
* Windows are shown by default, you can pass SDL_WINDOW_HIDDEN to
SDL_CreateWindow() to override this behavior.
* Re-added the 3DNow! and AltiVec instruction support.
* Fixed bug 1145 (GL Context creation fails for OpenGL 3.2 + Alpha
buffer with X11 BadMatch)
* Fixed crashes on Mac OS X with multiple streaming textures
* The windowed size and position are restored when returning from
fullscreen mode.
* Fixed removing the title bar on fullscreen windows on Mac OS X.
* Fixed minimizing fullscreen windows (needed to restore the video mode first)
* The Xinerama and xf86vmode extensions are now dynamically loaded.
* OSF and IRIX are no longer supported.

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

See ya!
--
    -Sam Lantinga, Founder and CEO, Galaxy Gameworks
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Here's a summary of the things that have changed in the SDL snapshot recently:
http://www.libsdl.org/tmp/SDL-1.3.zip

* Fullscreen doesn't automatically grab the cursor, for multi-monitor configurations
* Finished support for cursors on Windows and Linux
* Updated 2D render code for Nintendo DS (thanks Frank Zago!)
* Fixed bitmap order interpretation; SDL defaults to MSB ordering so a bitstream corresponds to a pixel stream.
* Fixed blitting to ARGB1555 surfaces
* Enabled mult-touch support on iOS
* Fixed bug 1161 (Setting GL_ACCELERATED_VISUAL to 1 forces software rendering in Windows XP)
* Fixed compiling all targets in Visual Studio 2010 (Debug/Release, Win32/x64)
* Fixed testgesture so it works on the iPhone with reasonable performance
* Fixed bug 1163 (SDL_TEXTINPUT not being received on iPhoneOS)
* Include an updated Version.rc in Visual Studio builds
* Added screenshot hotkey support for all tests using common.c.
* Fixed bug 1162 (Error calling SDL_RenderReadPixels() with format=0)
* Gamma support is back, with new functions for multi-window support:
 - SDL_SetWindowBrightness()
 - SDL_GetWindowBrightness()
 - SDL_SetWindowGammaRamp()
 - SDL_GetWindowGammaRamp()
 - SDL_CalculateGammaRamp()
* Added a function to create color cursors: SDL_CreateColorCursor()

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

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