No everyone would not be happy.
more libs causes additional resource allocation that many embedded systems can’t afford.
Do you know for instance your typical Android app has about 100 mb of usable memory space available to it.
ICH1994 wrote:> Why dont make a extra lib for the Hardwareaccelerated Stuff? -> Everyone is happy.
Thos Guys who wnat that just add the lib those who dont just use only SDL
Sorry, I don’t understand.
Splitting the library would allow users to install only those parts they need, which would cause less memory usage for the majority of users. In contrast, loading two libraries instead of one library (that contains both libraries’ code) should make almost no difference at all in memory consumption. Probably none at all if we are talking about static libraries.
Regards,
UliOn Jan 21, 2011, at 11:32 PM, michelleC wrote:
No everyone would not be happy.
more libs causes additional resource allocation that many embedded systems can’t afford.
Do you know for instance your typical Android app has about 100 mb of usable memory space available to it.
ICH1994 wrote:
Why dont make a extra lib for the Hardwareaccelerated Stuff? -> Everyone is happy.Thos Guys who wnat that just add the lib those who dont just use only SDL
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Jabber: @Ulrich_von_Zadow
Skype: uzadow
Ulrich von Zadow wrote:
Sorry, I don’t understand.
Splitting the library would allow users to install only those parts they need, which would cause less memory usage for the majority of users. In contrast, loading two libraries instead of one library (that contains both libraries’ code) should make almost no difference at all in memory consumption. Probably none at all if we are talking about static libraries.
You are correct; but even more effective would be to require certain macros to be defined when compiling the library to use that feature of the library.
For example, SDL_BUILD_DISPLAY would be required to build windows and displays, SDL_BUILD_OPENGL would be required to build GL context support, SDL_BUILD_SOFTWARE_RENDERER would be required to build the software renderer, and SDL_BUILD_*_RENDERER would be required to build a specific rendering backend (IE, D3D or GL or GLES).------------------------
EM3 Nathaniel Fries, U.S. Navy
Is the size of SDL really that big a deal on most platforms? At least for
Windows, Mac, Linux, iPhone and Android the size of the SDL library (or DLL)
is insignificant compared to the application and its data.
I realize that on some other less popular or embedded platforms the size may
matter, but what percentage of SDL use is targeted for those platforms? I’d
hate to see a LOT of rework and restructuring happen to SDL to cater to a
couple of platforms that aren’t that popular. That being said, if there was
a way to handle this by defining or undefining certain macros, that seems
like a good solution that should work for everyone.
KenFrom: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Nathaniel J Fries
Sent: Friday, January 21, 2011 7:38 PM
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3
Ulrich von Zadow wrote:
Sorry, I don’t understand.
Splitting the library would allow users to install only those parts they
need, which would cause less memory usage for the majority of users. In
contrast, loading two libraries instead of one library (that contains both
libraries’ code) should make almost no difference at all in memory
consumption. Probably none at all if we are talking about static libraries.
You are correct; but even more effective would be to require certain macros
to be defined when compiling the library to use that feature of the library.
For example, SDL_BUILD_DISPLAY would be required to build windows and
displays, SDL_BUILD_OPENGL would be required to build GL context support,
SDL_BUILD_SOFTWARE_RENDERER would be required to build the software
renderer, and SDL_BUILD_*_RENDERER would be required to build a specific
rendering backend (IE, D3D or GL or GLES).
EM3 Nathaniel Fries, U.S. Navy
Hello !
I think Sam is on the right track. We need to look at what features are
necessary for a simple 2D graphics lib and implement those with HW
acceleration. The issue, though, is whether or not we can make it possible
to extend with fanciness. How could one rotate a SDL_Texture without SDL
doing it and without getting renderer-specific? Could I write a
line-drawing function for textures which performs as well as a built-in SDL
one? Can I use a pixel shader without SDL knowing?
This is exactly my point, how can somebody write an external library like SDL_rotozoom
with software- and hardware render parts.
The first part would be the software renderer :
SW_Rotozoom (…);
HW_OpenGL_Rotozoom (…);
HW_OpenGLES_Rotozoom (…);
HW_D9D_Rotozoom (…);
HW_D10D_Rotozoom (…);
Rotozoom (…);
checks if there is a hw accelerated function for the
actual renderer and if not uses SW_Rotozoom as a fallback.
SDL 1.3 needs a way to do something like this.
CU
Hello !
If anyone is still doubting that Linux has crappy graphics drivers,
I invite them to read this Slashdot thread
(http://news.slashdot.org/story/11/01/16/0657240/Why-Linux-Loses-Out-On-Hardware-Acceleration-In-Firefox)
(and maybe the article). In short:
nVidia’s closed-source drivers rockATI’s open-source drivers suck
developers that have expertise with 3D graphics drivers are few so
most 3D graphics drivers for Linux are buggy and not well maintained
I know it is offtopic for this discussion, but personally think
that there are important reasons for that :
If linux on a server is able to get a basic 2d framebuffer up,
the server company is happy.
There are only three major gfx card producers out there,
ATI / AMD, NVIDIA and Intel. Intel helps in making the open source
drivers better for their gfx chips, but they are designed for low energy
use cases and for real hardcore 3d games basically suck.
Nvidia is not willing to release infos about their gfx cards, to enable
coders to write good open source drivers for their cards.
ATI / AMD has released some information about some cards, but maybe not enough
to really get a complete driver going for their cards.
CU
SDL Digest, Vol 49, Issue 113
Message: 1
1.3
Message-ID: <ihcr0p$9m$1 at dough.gmane.org>There is never going to be a general consensus as to which features are
necessary for a 2D rendering API. You can keep adding features, all of
them useful features that somebody need, and soon you’ve exposed the
whole OpenGL API.I’m strongly in favor of keeping the rendering API minimal, and writing
more sophisticated rendering APIs as a separate layer on top of SDL.
SDL’s main purpose is to act as a cross-platform compatibility layer.
Let’s not confuse this purpose by adding features that could easily be
implemented in a platform-independent manner on top of SDL.
Message: 2
1.3
Message-ID: <754905.50255.qm at web161205.mail.bf1.yahoo.com>Sure, except there’s one little problem with that: it won’t work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That’s two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.
Message: 3
1.3
Message-ID:
<AANLkTi=uNyOF-AwzR-UqYW-0HD9EqAVL=HdgFeW3K4CZ at mail.gmail.com>They could be exposed… Then these features could be lifted to an
additional library instead of bothering everyone who feels affected.
Yes, this can be done. I’ve done something somewhat similar in SDLCP,
with the thread class’s native_handle() function. The trick is that it
can’t be done in a completely hardware-independant way. You design the
api something like this:
SDL_TextureBacking
{
Uint32 type;
};
SDL_TextureBacking* SDL_CreateBacking( SDL_Texture* );
void SDL_FreeBacking( SDL_TextureBacking* );
In the real word you won’t ever recieve an actual SDL_TextureBacking
instance, instead you’ll recieve a pointer to a SDL_TextureBacking
that’s embedded inside another, larger structure, in OO-style C. The
value of ->type actually identifies this larger structure, so that the
code calling these two functions can figure out if it can handle that
particular structure type, and if so make the appropriate cast(s). If
it can’t, then it releases the structure and returns an error message
of some sort. The actual structure that you recieve will, however, be
very platform-specific, which raises the question: is it worthwhile to
do this?> From: Rainer Deyke
Subject: Re: [SDL] Proposal: Drop support for software rendering in
From: Mason Wheeler
Subject: Re: [SDL] Proposal: Drop support for software rendering in
From: Jonathan Dearborn
Subject: Re: [SDL] Proposal: Drop support for software rendering in
- ATI / AMD has released some information about some cards, but maybe not enough
to really get a complete driver going for their cards.
That’s simply not true. ATi / AMD has released thousands of pages of specifications, microcode for almost all Radeon GPUs, tens of thousands of lines of sample source code, and more.
The reality is that writing drivers is hard work, and writing accelerated 2D/3D drivers is even harder.
It’s not something that the casual hacker can accomplish quickly, and it takes years of dedication, specialized knowledge, and (realistically) significant financial sponsorship.
-ShawnOn Jan 21, 2011, at 8:44 PM, Torsten Giebl wrote:
Sure, except there’s one little problem with that: it won’t work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That’s two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.The renderer would of course be implemented on top of OpenGL (or the
frame buffer interface for software rendering), not on top of SDL’s 2D
rendering API.The situation you’re describing is exactly why it’s a bad idea to add
too many features to SDL’s 2D rendering API. SDL’s 2D rendering API is
not extensible. Therefore, if you’re doing any sophisticated rendering,
you will eventually be forced to drop the 2D rendering API and switch to
OpenGL. Adding features to SDL’s 2D rendering API can only delay this
transition, thereby making the transition all the more painful.The only API that exposes the full power of OpenGL is OpenGL itself.
But, as many others have pointed out, there are a number of not insignificant platforms that have poor or no OpenGL support, even in this “modern era”.
My personal belief is that there is significant value in SDL retaining a software-only rendering backend for now, and in the sort of functionality SDL 1.3 is attempting to provide.
-ShawnOn Jan 21, 2011, at 1:43 PM, Rainer Deyke wrote:
On 1/21/2011 14:13, Mason Wheeler wrote:
Jared Maddox wrote:
Yes, this can be done. I’ve done something somewhat similar in SDLCP,
with the thread class’s native_handle() function. The trick is that it
can’t be done in a completely hardware-independant way. You design the
api something like this:SDL_TextureBacking
{
Uint32 type;
};
SDL_TextureBacking* SDL_CreateBacking( SDL_Texture* );
void SDL_FreeBacking( SDL_TextureBacking* );In the real word you won’t ever recieve an actual SDL_TextureBacking
instance, instead you’ll recieve a pointer to a SDL_TextureBacking
that’s embedded inside another, larger structure, in OO-style C. The
value of ->type actually identifies this larger structure, so that the
code calling these two functions can figure out if it can handle that
particular structure type, and if so make the appropriate cast(s). If
it can’t, then it releases the structure and returns an error message
of some sort. The actual structure that you recieve will, however, be
very platform-specific, which raises the question: is it worthwhile to
do this?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
What could be done is to make a vertex rendering function:
Code:
int SDL_RenderCopyVertices(SDL_Texture* texture, SDL_Point* srcpts, SDL_Point* dstpts, int count);
that will take care of some of the features desired (SDL_RenderCopy could literally just be a translation to this) and can be done easily with at least D3D and OGL.
it can just return on error “Not supported” on rendering backends that don’t support it.
Render targets is more complicated. They became core in OpenGL 3 and I believe they’ve always been a part of Direct3D9; they’re easily done in software and IIRC GDI can do it as well.
But if SDL can’t get an OpenGL 3.x context, it’ll need to emulate it in software (or maybe through a mix of SDL_UpdateTexture and software?).------------------------
EM3 Nathaniel Fries, U.S. Navy
Yes, I agree to make it a compilation option. Why not
have something like a configure option --enable-hwaccel
or --enable-swrenderer (with at least one of the enabled).
SW renderer could also be always compiled, and triggered
in case HW acceleration cannot be performed for some reason,
so that the rendering is done anyway, but with warnings
logged somewhere.
Of course it overloads the configuration and compilation
process but at the end the user is happy to have a
fine tuned SDL library instead of a big packet of things
which may never be used (so less memory used, more clarity).
I’m also aware it means more work in the side of the SDL
developers !
Julien Cl?ment.
Le 22 janv. 2011 ? 07:47, sdl-request at lists.libsdl.org a ?crit :> Send SDL mailing list submissions to
sdl at lists.libsdl.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
or, via email, send a message with subject or body ‘help’ to
sdl-request at lists.libsdl.orgYou can reach the person managing the list at
sdl-owner at lists.libsdl.orgWhen replying, please edit your Subject line so it is more specific
than “Re: Contents of SDL digest…”Today’s Topics:
- Re: problem with SDL_SetGammaRamp on SDL 1.2.14 on Windows
(Nathaniel J Fries)- Re: Build errors in Visual Studio 2008 Professional
(Nathaniel J Fries)- Re: Proposal: Drop support for software rendering in 1.3
(Torsten Giebl)- Re: [1.2+OGL]-“LettersFall 3” Game-Please Help Test On (Ananth A)
- Re: Proposal: Drop support for software rendering in 1.3
(Jared Maddox)- [off-topic] was Re: Proposal: Drop support for software
rendering in 1.3 (Shawn Walker)- Re: Proposal: Drop support for software rendering in 1.3
(Shawn Walker)
Message: 1
Date: Fri, 21 Jan 2011 20:29:38 -0800
From: “Nathaniel J Fries”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] problem with SDL_SetGammaRamp on SDL 1.2.14 on
Windows
Message-ID: <1295670578.m2f.26994 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”the issue with the HG repository is known, and Sam has contacted someone to fix it.
Try the snapshot from the site’s download page instead. It’s probably the exact same code.as for the actual SDL bug; that is a mystery to me.
EM3 Nathaniel Fries, U.S. Navy
-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110121/78da77bc/attachment-0001.htm
Message: 2
Date: Fri, 21 Jan 2011 20:31:59 -0800
From: “Nathaniel J Fries”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Build errors in Visual Studio 2008 Professional
Message-ID: <1295670719.m2f.26996 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”those errors are concerning, and unfortunely I don’t use MSVC and thus can’t help.
However, I can tell you that SDL 1.3 uses a very different API from SDL1.2 and all SDL 1.2 compatibility functions are in SDL_compat.h instead of their normal headers.
See if that doesn’t fix most of your non-totally-bizarre errors.
EM3 Nathaniel Fries, U.S. Navy
-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110121/74a05c75/attachment-0001.htm
Message: 3
Date: Sat, 22 Jan 2011 05:44:11 +0100
From: Torsten Giebl
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Message-ID: <4D3A609B.2090303 at syntheticsw.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowedHello !
If anyone is still doubting that Linux has crappy graphics drivers,
I invite them to read this Slashdot thread
(http://news.slashdot.org/story/11/01/16/0657240/Why-Linux-Loses-Out-On-Hardware-Acceleration-In-Firefox)
(and maybe the article). In short:
nVidia’s closed-source drivers rockATI’s open-source drivers suck
developers that have expertise with 3D graphics drivers are few so
most 3D graphics drivers for Linux are buggy and not well maintainedI know it is offtopic for this discussion, but personally think
that there are important reasons for that :
- Look on the kernel.org mailinglist, most of the people
there that do kernel work, are hired by companies, that
are interested in servers. Their interest lies in filesystems,
better network performance, better kernel scheduling and basically
everything else without sound and grafix.If linux on a server is able to get a basic 2d framebuffer up,
the server company is happy.
There are only three major gfx card producers out there,
ATI / AMD, NVIDIA and Intel. Intel helps in making the open source
drivers better for their gfx chips, but they are designed for low energy
use cases and for real hardcore 3d games basically suck.Nvidia is not willing to release infos about their gfx cards, to enable
coders to write good open source drivers for their cards.ATI / AMD has released some information about some cards, but maybe not enough
to really get a complete driver going for their cards.CU
Message: 4
Date: Fri, 21 Jan 2011 23:49:07 -0500
From: Ananth A
To: sdl at lists.libsdl.org
Subject: Re: [SDL] [1.2+OGL]-“LettersFall 3” Game-Please Help Test On
Message-ID:
<AANLkTi=dfFd8jmjgKdguHSBwtTy-r-K3Lx-W38KtyF1E at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1Hi,
I tried your game under win7 64bit. Unfortunately, i was not able to
play the game. the arrow keys (left/right/down) did nothing. I have a
usb keyboard. Also, the next character just randomly flickers and cant
read anything…also, in the how to play, you have written help for “down arrow” twice.
Good luck.
Regards,
AnanthOn 1/21/11, JeZ-l-Lee wrote:
Hi,
I added new high score name input!
This will be the last alpha version before the officially released beta…
Please download and help test it!
The people on the list/IRC that already helped
now have their name in the game’s [About] staff credits!!!Linux 32bit/64bit
http://16bitsoft.com/files/LF3/SOURCE/lettersfall-src_alpha2.98.zipMicrosoft® Windows® XP/Vista/7 32bit/64Bit
http://16bitsoft.com/files/LF3/Win32-64/LF3-Win32_Alpha2.98.zipPS- Anyone wish to port this to Apple’s iOS (iPhone/iPod Touch/iPad) ???
(let me know - I would share generously any profits on the Apple App Store)
JeZ+Lee
JessePalser <AT> Gmail <DOT> com
16BitSoft®
Video Game Design Studio
www.16BitSoft.com
Message: 5
Date: Sat, 22 Jan 2011 00:18:10 -0600
From: Jared Maddox
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Message-ID:
<AANLkTik88=kaHcOPrWiEhihG7zKDLUjC=e_1o3YqkZEg at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1SDL Digest, Vol 49, Issue 113
Message: 1
From: Rainer Deyke
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Message-ID: <ihcr0p$9m$1 at dough.gmane.org>There is never going to be a general consensus as to which features are
necessary for a 2D rendering API. You can keep adding features, all of
them useful features that somebody need, and soon you’ve exposed the
whole OpenGL API.I’m strongly in favor of keeping the rendering API minimal, and writing
more sophisticated rendering APIs as a separate layer on top of SDL.
SDL’s main purpose is to act as a cross-platform compatibility layer.
Let’s not confuse this purpose by adding features that could easily be
implemented in a platform-independent manner on top of SDL.Message: 2
From: Mason Wheeler
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Message-ID: <754905.50255.qm at web161205.mail.bf1.yahoo.com>Sure, except there’s one little problem with that: it won’t work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That’s two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.Message: 3
From: Jonathan Dearborn
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Message-ID:
<AANLkTi=uNyOF-AwzR-UqYW-0HD9EqAVL=HdgFeW3K4CZ at mail.gmail.com>They could be exposed… Then these features could be lifted to an
additional library instead of bothering everyone who feels affected.Yes, this can be done. I’ve done something somewhat similar in SDLCP,
with the thread class’s native_handle() function. The trick is that it
can’t be done in a completely hardware-independant way. You design the
api something like this:SDL_TextureBacking
{
Uint32 type;
};
SDL_TextureBacking* SDL_CreateBacking( SDL_Texture* );
void SDL_FreeBacking( SDL_TextureBacking* );In the real word you won’t ever recieve an actual SDL_TextureBacking
instance, instead you’ll recieve a pointer to a SDL_TextureBacking
that’s embedded inside another, larger structure, in OO-style C. The
value of ->type actually identifies this larger structure, so that the
code calling these two functions can figure out if it can handle that
particular structure type, and if so make the appropriate cast(s). If
it can’t, then it releases the structure and returns an error message
of some sort. The actual structure that you recieve will, however, be
very platform-specific, which raises the question: is it worthwhile to
do this?
Message: 6
Date: Fri, 21 Jan 2011 22:33:50 -0800
From: Shawn Walker
To: SDL Development List
Subject: [SDL] [off-topic] was Re: Proposal: Drop support for software
rendering in 1.3
Message-ID: <0324D8E7-7F49-465A-B181-967A474187EC at gmail.com>
Content-Type: text/plain; charset=us-asciiOn Jan 21, 2011, at 8:44 PM, Torsten Giebl wrote:
- ATI / AMD has released some information about some cards, but maybe not enough
to really get a complete driver going for their cards.That’s simply not true. ATi / AMD has released thousands of pages of specifications, microcode for almost all Radeon GPUs, tens of thousands of lines of sample source code, and more.
The reality is that writing drivers is hard work, and writing accelerated 2D/3D drivers is even harder.
It’s not something that the casual hacker can accomplish quickly, and it takes years of dedication, specialized knowledge, and (realistically) significant financial sponsorship.
-Shawn
Message: 7
Date: Fri, 21 Jan 2011 22:37:09 -0800
From: Shawn Walker
To: SDL Development List
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Message-ID:
Content-Type: text/plain; charset=us-asciiOn Jan 21, 2011, at 1:43 PM, Rainer Deyke wrote:
On 1/21/2011 14:13, Mason Wheeler wrote:
Sure, except there’s one little problem with that: it won’t work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That’s two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.The renderer would of course be implemented on top of OpenGL (or the
frame buffer interface for software rendering), not on top of SDL’s 2D
rendering API.The situation you’re describing is exactly why it’s a bad idea to add
too many features to SDL’s 2D rendering API. SDL’s 2D rendering API is
not extensible. Therefore, if you’re doing any sophisticated rendering,
you will eventually be forced to drop the 2D rendering API and switch to
OpenGL. Adding features to SDL’s 2D rendering API can only delay this
transition, thereby making the transition all the more painful.The only API that exposes the full power of OpenGL is OpenGL itself.
But, as many others have pointed out, there are a number of not insignificant platforms that have poor or no OpenGL support, even in this “modern era”.
My personal belief is that there is significant value in SDL retaining a software-only rendering backend for now, and in the sort of functionality SDL 1.3 is attempting to provide.
-Shawn
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.orgEnd of SDL Digest, Vol 49, Issue 117
Julien CLEMENT
@Julien_Clement1
[quote=“Julien CLEMENT”]Yes, I agree to make it a compilation option. Why not
have something like a configure option --enable-hwaccel
or --enable-swrenderer (with at least one of the enabled).
SW renderer could also be always compiled, and triggered
in case HW acceleration cannot be performed for some reason,
so that the rendering is done anyway, but with warnings
logged somewhere.
Of course it overloads the configuration and compilation
process but at the end the user is happy to have a
fine tuned SDL library instead of a big packet of things
which may never be used (so less memory used, more clarity).
I’m also aware it means more work in the side of the SDL
developers !
Julien Cl?ment.
Le 22 janv. 2011 ? 07:47, sdl-request at lists.libsdl.org a ?crit :
[\quote]
( y )
Making software/hardware support as a compiler flag seems convenient from a
developer standpoint, but is completely impractical from an end-user
perspective. Think, for instance, you are developing software for Mac OS X
(10.6), and are distributing binaries - if the binary is build against
hardware support but the users’ SDL library is build without hardware
support, there could be some linking issues. I don’t know for sure if
that’s true, but it would be something that should be taken into account.
-OzOn Sat, Jan 22, 2011 at 1:37 AM, Shawn Walker wrote:
On Jan 21, 2011, at 1:43 PM, Rainer Deyke wrote:
On 1/21/2011 14:13, Mason Wheeler wrote:
Sure, except there’s one little problem with that: it won’t work, at
leastnot the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That’s two missing levels of indirection
awayfrom the data you would need to implement any new image manipulation
or rendering features externally.The renderer would of course be implemented on top of OpenGL (or the
frame buffer interface for software rendering), not on top of SDL’s 2D
rendering API.The situation you’re describing is exactly why it’s a bad idea to add
too many features to SDL’s 2D rendering API. SDL’s 2D rendering API is
not extensible. Therefore, if you’re doing any sophisticated rendering,
you will eventually be forced to drop the 2D rendering API and switch to
OpenGL. Adding features to SDL’s 2D rendering API can only delay this
transition, thereby making the transition all the more painful.The only API that exposes the full power of OpenGL is OpenGL itself.
But, as many others have pointed out, there are a number of not
insignificant platforms that have poor or no OpenGL support, even in this
"modern era".My personal belief is that there is significant value in SDL retaining a
software-only rendering backend for now, and in the sort of functionality
SDL 1.3 is attempting to provide.-Shawn
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
MrOzBarry wrote:
Making software/hardware support as a compiler flag seems convenient from a developer standpoint, but is completely impractical from an end-user perspective.? Think, for instance, you are developing software for Mac OS X (10.6), and are distributing binaries - if the binary is build against hardware support but the users’ SDL library is build without hardware support, there could be some linking issues.? I don’t know for sure if that’s true, but it would be something that should be taken into account.
Only if the user’s binary is compiled without flags that yours is compiled with; which is highly unlikely and realistically unless you’re statically linking to SDL (or using it on Android) you should use a fully-featured build. This is especially true for any non-embedded system; you shouldn’t bother. The only real reason to do it is to decrease the disk size and memory use for the code (which a stripped (-s) SDL 1.3 on Windows compiles to roughly 900kb anyway; so it won’t have THAT much of an effect on any system).------------------------
EM3 Nathaniel Fries, U.S. Navy
Usually you would distribute your own copy of SDL along with your
application, at least on OS X and Windows.
That said, I am also opposed to the idea of making the software renderer
optional. The software renderer is small, and it’s always useful to
have a working fallback in case hardware rendering fails.On 1/22/2011 11:00, Alex Barry wrote:
Making software/hardware support as a compiler flag seems convenient from a
developer standpoint, but is completely impractical from an end-user
perspective. Think, for instance, you are developing software for Mac OS X
(10.6), and are distributing binaries - if the binary is build against
hardware support but the users’ SDL library is build without hardware
support, there could be some linking issues. I don’t know for sure if
that’s true, but it would be something that should be taken into account.
–
Rainer Deyke - rainerd at eldwood.com
Just another angle on the issue which comes from SDL 1.2.
There is this flag, SDL_HWSURFACE that has become an anachronism that
newbies keep insisting on using thinking it will give them more
performance while in fact that it now does quite the opposite.
So 10 years from now, will we find that the current hardware renderers
are obsolete and useless while the software renderer becomes the most
reliable and fastest implementation?
-Eric
Speaking from a package maintainer and distribution stand point,
compile time switches suck. Please don’t do this.
Speaking from a documentation writer stand point, this sucks too.
Barely anybody reads the documentation as it is. This will be a
terrible gotcha.
Speaking from a Q/A standpoint, this sucks for similar reasons as
documentation. For diagnosis, we now have to have more knowledge about
how SDL was specifically compiled. Most users won’t tell us and will
be confused when asked.
[quote=“Julien CLEMENT”]Yes, I agree to make it a compilation option. Why
not
have something like a configure option --enable-hwaccel
or --enable-swrenderer (with at least one of the enabled).
SW renderer could also be always compiled, and triggered
in case HW acceleration cannot be performed for some reason,
so that the rendering is done anyway, but with warnings
logged somewhere.Of course it overloads the configuration and compilation
process but at the end the user is happy to have a
fine tuned SDL library instead of a big packet of things
which may never be used (so less memory used, more clarity).I’m also aware it means more work in the side of the SDL
developers !Julien Cl?ment.
–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
I also have a proposal to improve performance of SDL’s software renderer on systems with multiple cores.
Simply; just make a dedicated blitter thread per processor. If you can’t get the number of processors, the system doesn’t support multiple threads (IE, Minix3), or it’s single core; rely on the current method.
The threads will be started by SDL_CreateRenderer or the first call to SDL_SetVideoMode, and receive blit requests from a thread-safe queue. SDL_Flip and SDL_RenderPresent will wait on worker threads to finish (use a semaphore).
You’ll need to implement a regional/rectangular lock on the screen surface, but that’s not terribly difficult to implement… just check for an intersection of the destination rectangle against all “locked rectangles” stored in a resizable array or linked list. I should be able to do this for Windows and POSIX if you guys think it’ll be too hard for yourselves, but I am a bit strapped on time recently.
In addition these worker threads could perform rotations and stretches, keeping the main thread free to continue sending requests.
What do you think?------------------------
EM3 Nathaniel Fries, U.S. Navy
Speaking from a package maintainer and distribution stand point,
compile time switches suck. Please don’t do this.Speaking from a documentation writer stand point, this sucks too.
Barely anybody reads the documentation as it is. This will be a
terrible gotcha.Speaking from a Q/A standpoint, this sucks for similar reasons as
documentation. For diagnosis, we now have to have more knowledge about
how SDL was specifically compiled. Most users won’t tell us and will
be confused when asked.
- Eric
I agree.
For the love of God, do NOT start splintering SDL into different
library-compile-time-build versionings. This will fragment the hell out of
things. If you think dependency hell with “1.2.9 vs 1.2.13” can be a big
deal… just wait until everyone and their uncle builds an SDL library with
what they think are preferred options.
If someone distributes game X with custom built libsdl using custom compile
flags… and if that libsdl doesn’t work on my system… what do I do then
? I can’t necessarily just delete it and my system wide libsdl can do its
thing. Recompiling a libsdl to match the custom one is also going to be
guess work.
Keep it SIMPLE guys.
-Will
Will Langford wrote:
I agree.
For the love of God, do NOT start splintering SDL into different library-compile-time-build versionings. ?This will fragment the hell out of things. ?If you think dependency hell with “1.2.9 vs 1.2.13” can be a big deal… just wait until everyone and their uncle builds an SDL library with what they think are preferred options.
If someone distributes game X with custom built libsdl using custom compile flags… and if that libsdl doesn’t work on my system… what do I do then ? ?I can’t necessarily just delete it and my system wide libsdl can do its thing. ?Recompiling a libsdl to match the custom one is also going to be guess work.
Keep it SIMPLE guys.
-Will?
Perhaps instead, modularize SDL itself into several smaller libraries? SFML does something like this.
For example, SDL_core (SDL’s standard c subset), SDL_system (threads, OS version, CPU features; depends on SDL_core), SDL_surface (SDL_Surface-based structures; depends on SDL_core and SDL_system for fast blitting), SDL_windows (SDL_CreateWindow*, SDL_Event), SDL_render (SDL_CreateRenderer, etc; this CAN be safely fragmented as was suggested before, since the public API is still the same)------------------------
EM3 Nathaniel Fries, U.S. Navy