No, you misunderstand. The goal is to have software fallback, not to
drop HW support anywhere.On Mon, Mar 1, 2010 at 6:56 PM, hardcoder wrote:
Rainer Deyke wrote:
You don’t need to go back in time at all, you just need to download the
latest version of qemu.Lets be reasonable here… You would rather drop HW support on target
platform in favor of emulator?
Rainer Deyke wrote:
Really, the problem isn’t computers without 3D hardware. The problem is
broken drivers, missing drivers, outdated drivers, graphics cards that
aren’t supported at all by a given OS, and graphics cards that don’t
support the right version of the right graphics API.(That said, I don’t really care about the SDL 2D graphics API. Give me
OpenGL or give me a simple framebuffer.)No, it is not the problem. We do not discuss Direct3D 10, OpenGL 3.2 or
Shader Model 5 here. We talk about rotation which is as basic as scaling
or even doing a quad for rendering itself. Drivers are not a problem. It is
OpenGL 1.0 feature which I believe my kitchen sink implements.
Exactly! And OpenGL came out in 1992. If some computer out there
somewhere still doesn’t have support for an OpenGL 1.0 feature that has
been around for EIGHTEEN YEARS, do we really need to care about it?>From: hardcoder
Subject: Re: [SDL] Rotation API
Once upon a time, SDL supported many of the most obscure platforms. To
this day SDL’s website claims:
"The code contains support for AmigaOS, Dreamcast, Atari, AIX,
OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially
supported."On Mon, Mar 1, 2010 at 7:10 PM, Mason Wheeler wrote:
No, it is not the problem. We do not discuss Direct3D 10, OpenGL 3.2 or
Shader Model 5 here. We talk about rotation which is as basic as scaling
or even doing a quad for rendering itself. Drivers are not a problem. It is
OpenGL 1.0 feature which I believe my kitchen sink implements.Exactly! ?And OpenGL came out in 1992. If some computer out there
somewhere still doesn’t have support for an OpenGL 1.0 feature that has
been around for EIGHTEEN YEARS, do we really need to care about it?
No, it is not the problem. We do not discuss Direct3D 10, OpenGL 3.2 or
Shader Model 5 here. We talk about rotation which is as basic as scaling
or even doing a quad for rendering itself. Drivers are not a problem. It is
OpenGL 1.0 feature which I believe my kitchen sink implements.Exactly! And OpenGL came out in 1992. If some computer out there
somewhere still doesn’t have support for an OpenGL 1.0 feature that has
been around for EIGHTEEN YEARS, do we really need to care about it?Once upon a time, SDL supported many of the most obscure platforms. To
this day SDL’s website claims:“The code contains support for AmigaOS, Dreamcast, Atari, AIX,
OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially
supported.”
And SDL can continue to unofficially support them, especially in 1.2. I’m fine
with that. If whoever maintains them wants to set the SDL 1.3 features up,
they’re free to. But again, this shouldn’t shackle SDL 1.3 development on the
core platforms (Windows, Linux and OSX) and stand in the way of the
implementation of basic functionality like rotation and render targets.>----- Original Message ----
From: Donny Viszneki <donny.viszneki at gmail.com>
Subject: Re: [SDL] Rotation API
On Mon, Mar 1, 2010 at 7:10 PM, Mason Wheeler <@Mason_Wheeler> wrote:
I don’t think any more useful discussion can be had about which choice
people would prefer to make if they had to make a choice. Prove me
wrong if you disagree. Otherwise there is a meaningful technical
discussion to be had about whether or not we even have to make such a
choice.
Also it would be nice if some SDL scholar could provide an overview of
just what the state of platform support looks like in SDL 1.3 right
now.On Mon, Mar 1, 2010 at 7:35 PM, Mason Wheeler wrote:
again, this shouldn’t shackle SDL 1.3 development on the
core platforms (Windows, Linux and OSX) and stand in the way of the
implementation of basic functionality like rotation and render targets.
I don’t know where you’re getting that from, because I haven’t said
anything of the sort. To summarize my position:
Rainer Deyke wrote:
You don’t need to go back in time at all, you just need to download
the latest version of qemu.Lets be reasonable here… You would rather drop HW support on target
platform in favor of emulator?
–
Rainer Deyke - rainerd at eldwood.com
Donny Viszneki wrote:
Once upon a time, SDL supported many of the most obscure platforms. To
this day SDL’s website claims:“The code contains support for AmigaOS, Dreamcast, Atari, AIX,
OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially
supported.”
You may have mistaken the libraries. It is about this one (http://www.galaxygameworks.com/):
“Special Features:
Full 3D hardware acceleration”
“Supported Platforms:
Windows 2000/XP/Vista/7
Mac OS X
Linux
FreeBSD, NetBSD, OpenBSD
iPhone, iPod Touch
Nintendo DS”
Rainer Deyke wrote:
I don’t know where you’re getting that from, because I haven’t said
anything of the sort. To summarize my position:
- Computers without working hardware 3D support matter. (If they
didn’t, then I’d just use OpenGL directly. Which I do, but I also like
having a software fallback.)- Rotation in software is fast enough, therefore the speed of software
rotation should not be used as an argument against hardware accelerated
rotation in SDL.- I’d rather have the flexibility of a software framebuffer than a
complicated 2D rendering API. If I need rotation, I can implement it
myself.
No, they do not matter. Check out the listed supported platforms and most important features of SDL 1.3. If you need software bitting library with additional ability to create OpenGL rendering context for HW support, you already have it, it is called SDL 1.2. From my POV SDL 1.3 should not contain software renderer at all. “Full 3D hardware acceleration” doesn’t “partial” or “optional” it is SDL’s next step.
But OK, lets say SW renderer would also contain rotation code, no harm for HW users. Who would wrote that? And it is not added to SW renderer should it not also be in HW renderer?
This artificial consistency requirement is also weird for me for other reason: I am now writing a game for Win/Mac and iPhone and software renderer (under Win) does not produce correct output already and of course I am not using rotation.
You’ve already experienced the benefit software rendering has to offer. Look
how quickly you’re finding bugs. Doesn’t this excite you? You could be the
hero of SDL.
Software rendering is more than just a fallback. Its the worst speed/minimal
features you can expect from SDL. I would even go so far to say, its the
foundation.
A 2D api with no framebuffer support feels pretty naked. SDL needs to hold
on its on with or without acceleration. Because this is it. Its not like
there’s a bunch of cross-platform alternatives for accessing a framebuffer
across different operating systems/hardware.
Otherwise I wouldn’t even really care about software rendering, like you do.
I want it to stay, because no other library does it better.On Tue, Mar 2, 2010 at 4:39 AM, hardcoder wrote:
This artificial consistency requirement is also weird for me for other
reason: I am now writing a game for Win/Mac and iPhone and software renderer
(under Win) does not produce correct output already and of course I am not
using rotation.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Rainer Deyke wrote:
Really, the problem isn’t computers without 3D hardware. The problem is
broken drivers, missing drivers, outdated drivers, graphics cards that
aren’t supported at all by a given OS, and graphics cards that don’t
support the right version of the right graphics API.
This is the only non-debatable point here.
When I first tried GNU/Linux (my babysteps into the use of Open Source Software, btw) in '05, I couldn’t find Linux drivers for my graphics card to save my life.
Even now I occasionally hear from a friend or colleague trying Linux for the first time that for some reason their high-end graphics card isn’t working well at all, probably due to wrong/low quality/unavailable drivers.
Since GNU/Linux is certainly one of the bigger systems supported by SDL, I think this scenario is something that shouldn’t be overlooked. In the case of a generic 2D SDL application, it would most likely work better with SDL’s software renderer than with SDL wrapping a software implementation of a 3D graphics renderer like OpenGL.
I am not in favor of removing the software implementation entirely, nor of removing it from the SDL_Renderer abstraction and making it explicit (which is the better of the two options).
I don’t need a software blitter, I just need a framebuffer. And clean
consistent keyboard input, which SDL 1.2 does /not/ provide.On 3/2/2010 02:39, hardcoder wrote:
If you need software bitting
library with additional ability to create OpenGL rendering context
for HW support, you already have it, it is called SDL 1.2.
–
Rainer Deyke - rainerd at eldwood.com