I’m using SDL 1.3 and trying to draw an image mirrored (with it’s X coordinates reversed). But the doesn’t seem to be any way to do this. OpenGL wouldn’t have any trouble with receiving texture coordinates where x2 < x1, but if I pass SDL_RenderCopy a SrcRect where W is negative, then it short-circuits at the call to SDL_IntersectRect.
How can I draw an image mirrored horizontally? (Or vertically, for that matter?)
SDL currently doesn’t support this. It would involve lots of hacking
of blitters (though it could be done!)
If you think this is a really important feature, feel free to submit a
patch. The real trick here is supporting things besides OpenGL.On Sun, Jul 11, 2010 at 7:03 PM, Mason Wheeler wrote:
I’m using SDL 1.3 and trying to draw an image mirrored (with it’s X coordinates reversed). ?But the doesn’t seem to be any way to do this. ?OpenGL wouldn’t have any trouble with receiving texture coordinates where x2 < x1, but if I pass SDL_RenderCopy a SrcRect where W is negative, then it short-circuits at the call to SDL_IntersectRect.
How can I draw an image mirrored horizontally? ?(Or vertically, for that matter?)
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL currently doesn’t support this. It would involve lots of hacking
of blitters (though it could be done!)If you think this is a really important feature, feel free to submit a
patch. The real trick here is supporting things besides OpenGL.
It’s definitely an important feature, since I can’t implement what I’m
trying to implement without it. It shouldn’t be too hard to write up
a patch. The “real trick” is a stumbling block, though.
I still don’t understand that part. AFAIK no new personal computer
sold this century has been without hardware-accelerated video. No
non-personal computer platform we’re going to target (smartphones
and video game consoles) comes without hardware-accelerated
OpenGL or GL ES. It’s becoming more and more apparent that
trying to support other backends is holding SDL back.
Since SDL 1.3 isn’t going to be used on any system without
hardware acceleration, is there any reason for it to support any
backends other than OpenGL, OpenGL ES and Direct3D? Any
reason at all? A couple years ago, when SDL 1.3 was still in the
planning and early development phase, there was a lot of talk on here
about removing unnecessary features (CD audio, for example) and
breaking backwards compatibility where it would hold SDL back. Let’s
put that into practice WRT renderer backends and make SDL 1.3 a
library for the 2010s, not the 1990s.>From: Sam Lantinga
Subject: Re: [SDL] how to draw an image mirrored?
Mason, you seem to be ignoring one fact - that’s all new devices. The
average joe usually doesn’t have the most up-to-date system, and may or may
not have a hardware accelerated system available to them. I would say it’s
a safe bet that if they don’t have a computer that’s hardware accelerated,
they likely don’t have a hand-held device that is either.
Flipping an image is almost certainly not hardware dependent - it’s all
about pixel order. All Sam is saying is that mirroring an image takes a few
more steps than just saying SDL_MirrorTexture( source, dest, flags );
Right now, I’m not using 1.3 for the sake that I’m awaiting the official
release, so I’m not sure on the exact setup, but your best bet is to go into
the win32/linux/mac native code, using their respective backends, and seeing
if it’s possible to mirror a surface with those APIs, in which case, it’ll
take care of all the dirty work.
Take care,
-AexOn Mon, Jul 12, 2010 at 1:08 PM, Mason Wheeler wrote:
From: Sam Lantinga
Subject: Re: [SDL] how to draw an image mirrored?SDL currently doesn’t support this. It would involve lots of hacking
of blitters (though it could be done!)If you think this is a really important feature, feel free to submit a
patch. The real trick here is supporting things besides OpenGL.It’s definitely an important feature, since I can’t implement what I’m
trying to implement without it. It shouldn’t be too hard to write up
a patch. The “real trick” is a stumbling block, though.I still don’t understand that part. AFAIK no new personal computer
sold this century has been without hardware-accelerated video. No
non-personal computer platform we’re going to target (smartphones
and video game consoles) comes without hardware-accelerated
OpenGL or GL ES. It’s becoming more and more apparent that
trying to support other backends is holding SDL back.Since SDL 1.3 isn’t going to be used on any system without
hardware acceleration, is there any reason for it to support any
backends other than OpenGL, OpenGL ES and Direct3D? Any
reason at all? A couple years ago, when SDL 1.3 was still in the
planning and early development phase, there was a lot of talk on here
about removing unnecessary features (CD audio, for example) and
breaking backwards compatibility where it would hold SDL back. Let’s
put that into practice WRT renderer backends and make SDL 1.3 a
library for the 2010s, not the 1990s.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Mason, you seem to be ignoring one fact - that’s all new devices. The average
joe usually doesn’t have the most up-to-date system, and may or may not have a
hardware accelerated system available to them. I would say it’s a safe bet thatif they don’t have a computer that’s hardware accelerated, they likely don’t
have a hand-held device that is either.
I’m not ignoring that. I’m taking it into account. Like I said, all computers
that
were new since before the turn of the century have 3D acceleration. Sure, not
everyone has a brand new system, but how many people are still using systems
from the 90s. And how many of those who are actually expect to be able to play
games created today on them? If the answer’s not “zero” it’s close enough as to
make no difference.
Bottom line, in 2010 “the average joe” is running Windows XP, and has Direct3D
and OpenGL both installed out of the box whether he knows it or not.>From: Alex Barry <alex.barry at gmail.com>
Subject: Re: [SDL] how to draw an image mirrored?
Arguing about whether or not SDL should have that functionality isn’t going
to change the fact that it doesn’t. Sam told you that if you want to
provide a patch he would gladly consider integrating it into SDL.
If you want a simple and quick solution at a higher level, just write a
trivial routine to do the following:
This approach has two drawbacks:
However, the big advantage is that blits using the mirrored texture will be
as fast as blits using the original image, regardless if the platform
supports hardware accelerated blitting.
Ken Rogoway> ----- Original Message -----
From: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Mason Wheeler
Sent: Monday, July 12, 2010 12:28 PM
To: SDL Development List
Subject: Re: [SDL] how to draw an image mirrored?From: Alex Barry <alex.barry at gmail.com>
Subject: Re: [SDL] how to draw an image mirrored?Mason, you seem to be ignoring one fact - that’s all new devices. The
average
joe usually doesn’t have the most up-to-date system, and may or may not
have a
hardware accelerated system available to them. I would say it’s a safe bet
thatif they don’t have a computer that’s hardware accelerated, they likely
don’t
have a hand-held device that is either.I’m not ignoring that. I’m taking it into account. Like I said, all
computers
that
were new since before the turn of the century have 3D acceleration. Sure,
not
everyone has a brand new system, but how many people are still using systems
from the 90s. And how many of those who are actually expect to be able to
play
games created today on them? If the answer’s not “zero” it’s close enough
as to
make no difference.Bottom line, in 2010 “the average joe” is running Windows XP, and has
Direct3D
and OpenGL both installed out of the box whether he knows it or not.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Well, if you’re using SDL for the purpose of making games, yes, it’s good to
assume that your audience is people who have some sort of hardware
acceleration.
Most computers are capable of hardware acceleration in terms of operating
system and software ability, but the next deciding factor is if all systems
have hardware to do it. Most built in cards have very minimum capability,
and that’s just for basic functionality.On Mon, Jul 12, 2010 at 1:27 PM, Mason Wheeler wrote:
From: Alex Barry <@Alex_Barry>
Subject: Re: [SDL] how to draw an image mirrored?Mason, you seem to be ignoring one fact - that’s all new devices. The
average
joe usually doesn’t have the most up-to-date system, and may or may not
have a
hardware accelerated system available to them. I would say it’s a safe
bet thatif they don’t have a computer that’s hardware accelerated, they likely
don’t
have a hand-held device that is either.I’m not ignoring that. I’m taking it into account. Like I said, all
computers
that
were new since before the turn of the century have 3D acceleration. Sure,
not
everyone has a brand new system, but how many people are still using
systems
from the 90s. And how many of those who are actually expect to be able to
play
games created today on them? If the answer’s not “zero” it’s close enough
as to
make no difference.Bottom line, in 2010 “the average joe” is running Windows XP, and has
Direct3D
and OpenGL both installed out of the box whether he knows it or not.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Mason the points you have made are absolutely correct. The problem is
that they do not address the reason why SDL has a software based image
processing library built into it. The software blitters are used to
manipulating images in main memory, they just happen to be usable for
rendering. Another thing to consider is that the word “game” does not
appear anywhere in Simple Direct Media Library. SDL is used for a lot
of things besides game development.
A lot of the decisions that Sam makes (IMHO) are based on his
understanding of the breadth of applications that use SDL plus an deep
belief in orthogonality. Again, IMHO, it is more important that the
API be orthogonal than anything else.
The simplest way to solve your problem is to use OpenGL or to write a
simple pixel level image swapper.
Bob PendletonOn Mon, Jul 12, 2010 at 12:27 PM, Mason Wheeler wrote:
From: Alex Barry <alex.barry at gmail.com>
Subject: Re: [SDL] how to draw an image mirrored?Mason, you seem to be ignoring one fact - that’s all new devices. ?The average
joe usually doesn’t have the most up-to-date system, and may or may not have a
hardware accelerated system available to them. ?I would say it’s a safe bet thatif they don’t have a computer that’s hardware accelerated, they likely don’t
have a hand-held device that is either.I’m not ignoring that. ?I’m taking it into account. ?Like I said, all computers
that
were new since before the turn of the century have 3D acceleration. ?Sure, not
everyone has a brand new system, but how many people are still using systems
from the 90s. ?And how many of those who are actually expect to be able to play
games created today on them? ?If the answer’s not “zero” it’s close enough as to
make no difference.Bottom line, in 2010 “the average joe” is running Windows XP, and has Direct3D
and OpenGL both installed out of the box whether he knows it or not.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
Not sure what’s going on with your mailer, Bob, but that came out as gibberish.________________________________
From: bob@pendleton.com (Bob Pendleton)
To: SDL Development List
Sent: Tue, July 13, 2010 7:02:08 PM
Subject: Re: [SDL] how to draw an image mirrored?
x?U]o?6}???K6?v>?0???8?e??)??PP????"??????K?i???5?!K?_??{?U?;J-S??K?&?P???:??T?o???7iA?% ??rG&V?UI?L?=9?Hi8??8p?1??_? y$E???(?kY????+dle????? ??????'s??9???8 ??&??S???UI?????F?p??4+?>1???g???? ???*???bA??r@?d????h???f?F4?U?G??? PIrH?iD?>?M????i??(?)?.2<H?GA??"????=J?HR?4???}?.-?j#G)?G??m???U????????3^wp???A??I9-3?? N?V?bk??=?v{;
I think this design debate over basic assumptions in SDL 2D rendering has raged on for quite some time.
If designing a 2D convenience library that wraps 3D APIs (GL/D3D/etc) then one naturally assumes certain things are easy, and exposes them as easy in that API, for example rotation, scaling, and
flipping would be exposed as conveniently available options in such an API.
If designing a 2D convenience library that writes directly to software surfaces, then one naturally assumes certain things are fast, certain things are slow, and avoids designing an API that offers
the slow things - for example, rotation being a heavy operation, flipping being a heavy operation, these operations may not be available or may require extra steps to make use of, because the API
designer did not want to encourage their use.
A fine example of these underlying assumptions is that on many of the sprite-based game consoles, they had X and Y flip options on all sprites (and also background tiles for that matter), some even
had rotation and scaling on sprites. So games written for these consoles made the assumption that this functionality was free and beneficial to use, hence the art was designed for this…
Where as in a more basic rendering system without this functionality, for example on the Amiga blitter hardware there was no X flip (Y flip could be performed by reversing the pitch register, so that
was supported but almost never used in that way), games that were adapted to the Amiga blitter hardware after coming from another platform, found themselves having to have a specialized routine to
flip a sprite’s image to emulate this functionality, rather than doing so during the blit itself, they did it beforehand on the CPU and then invoked their regular blitting function.
More commonly they DID store X flipped versions of such images, to avoid this extra cost, and the images may even be different (appropriate shading, for example), so the X flip issue became a
non-issue once it was worked around with the basic approach of duplicating all the images that could be viewed both ways…
Getting back to the subject at hand, SDL 2D rendering has a software implementation, and its 2D API is designed around that software implementation, so it does not expose things that are hard/slow to
do in software (scaling, flipping, rotation, blending), but at the same time it also exposes features that are hard/slow to do in hardware, for example color key masking (rather than alpha testing) is
simple in software but in hardware it requires special functionality to emulate the missing color key masking operation, because the 3D hardware was designed for a different set of basic assumptions.
Good luck with finding a solution to your problem, but I think the workarounds proposed were appropriate given the limited information provided.
If duplicating the images is not an option, then you may have to write your own routine to do the flip into a new surface before blittering, and see what the hardware performance is like.
P.S. yes I am aware of rotation/zoom functionality, but it is obviously not an encouraged API feature.On 07/12/2010 10:35 AM, Alex Barry wrote:
Well, if you’re using SDL for the purpose of making games, yes, it’s
good to assume that your audience is people who have some sort of
hardware acceleration.
Most computers are capable of hardware acceleration in terms of
operating system and software ability, but the next deciding factor is
if all systems have hardware to do it. Most built in cards have very
minimum capability, and that’s just for basic functionality.On Mon, Jul 12, 2010 at 1:27 PM, Mason Wheeler <masonwheeler at yahoo.com <mailto:masonwheeler at yahoo.com>> wrote:
>From: Alex Barry <alex.barry at gmail.com <mailto:alex.barry at gmail.com>> >Subject: Re: [SDL] how to draw an image mirrored? > >Mason, you seem to be ignoring one fact - that's all new devices. The average >joe usually doesn't have the most up-to-date system, and may or may not have a >hardware accelerated system available to them. I would say it's a safe bet that > >if they don't have a computer that's hardware accelerated, they likely don't >have a hand-held device that is either. I'm not ignoring that. I'm taking it into account. Like I said, all computers that were new since before the turn of the century have 3D acceleration. Sure, not everyone has a brand new system, but how many people are still using systems from the 90s. And how many of those who are actually expect to be able to play games created today on them? If the answer's not "zero" it's close enough as to make no difference. Bottom line, in 2010 "the average joe" is running Windows XP, and has Direct3D and OpenGL both installed out of the box whether he knows it or not. _______________________________________________ SDL mailing list SDL at lists.libsdl.org <mailto: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
–
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
Getting back to the subject at hand, SDL 2D rendering has a software
implementation, and its 2D API is designed around that software implementation,
so it does not expose things that are hard/slow to
do in software (scaling, flipping, rotation, blending), but at the same time it
also exposes features that are hard/slow to do in hardware, for example color
key masking (rather than alpha testing) is
simple in software but in hardware it requires special functionality to emulate
the missing color key masking operation, because the 3D hardware was designed
for a different set of basic assumptions.
Are you still using SDL 1.2? Because I’m talking about SDL 1.3, which has
scaling and blending support built in. Heck, scaling is implicitly a part of
the fundamental blitting routine, SDL_RenderCopy, which allows you to set source
and destination rects of different sizes and uses the Scale Mode on the texture
to determine how to interpolate.
Also, color keys do not exist in SDL_texture, only an alpha blend layer. If you
load a SDL_surface that has a color key, it converts it to an alpha channel. I
know this because I’ve been inside the code that does that and fixed a few bugs
in it. By your own logic, SDL 1.3 is clearly designed with hardware rendering in
mind, not software, and I agree that this is the proper way to proceed… I’m
simply proposing that it be taken to the logical conclusion by eliminating (or
at least deprecating) software renderers that interfere with the implementation
of important features that are easy to set up with hardware-oriented APIs.From: havoc@ghdigital.com (Forest Hale)
To: SDL Development List
Sent: Tue, July 13, 2010 7:19:28 PM
Subject: Re: [SDL] how to draw an image mirrored?
Do it in strips of 1px wide by surface->h px high.
-bill!On Sun, Jul 11, 2010 at 07:03:51PM -0700, Mason Wheeler wrote:
I’m using SDL 1.3 and trying to draw an image mirrored (with it’s X coordinates reversed).
While I do agree that the software backend is holding back quite a few nice things (rotation, flipping, etc), I don’t think it’s a good idea to drop it to move forward.
Okay, so most modern systems have hardware support for OpenGL or similar. But what about Minix3, which is a powerful and promising little system but doesn’t have proper drivers for pretty much any GPU? What if I decided to write an operating system and maintained a port of SDL 1.3 to help getting developers to port their own projects to it, but I still don’t have these drivers? Then we’re working on software OpenGL, which of course is better than nothing but nowhere near as good as a proper 2D software API like SDL provides.
In short: It’s definitely important to focus on the big guys, but the little guys shouldn’t be overlooked either.------------------------
EM3 Nathaniel Fries, U.S. Navy
I think the API development should be driven with a hardware-accelerated
focus. If the software implementation lags behind, that’s fine. We’ll
deal.
Jonny DOn Wed, Jul 14, 2010 at 2:40 AM, Nathaniel J Fries wrote:
While I do agree that the software backend is holding back quite a few
nice things (rotation, flipping, etc), I don’t think it’s a good idea to
drop it to move forward.Okay, so most modern systems have hardware support for OpenGL or similar.
But what about Minix3, which is a powerful and promising little system but
doesn’t have proper drivers for pretty much any GPU? What if I decided to
write an operating system and maintained a port of SDL 1.3 to help getting
developers to port their own projects to it, but I still don’t have these
drivers? Then we’re working on software OpenGL, which of course is better
than nothing but nowhere near as good as a proper 2D software API like SDL
provides.In short: It’s definitely important to focus on the big guys, but the
little guys shouldn’t be overlooked either.
EM3 Nathaniel Fries, U.S. Navy
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
If designing a 2D convenience library that wraps 3D APIs (GL/D3D/etc) then one naturally assumes certain things are easy, and exposes them as easy in that API, for example rotation, scaling, and
flipping would be exposed as conveniently available options in such an API.
If you’re going that route, you might as well make texture mapped
polygons (albeit constrained to two dimensions) the fundamental
primitive.
For what it’s worth, I’m suspicious of SDL 1.3’s efforts to integrate
more sophisticated graphics functions, being accustomed to using SDL
in its traditional modes of either a dumb frame buffer or a dumb
OpenGL container, rather than constrained to the least common
denominator provided by someone else’s portability layer. My doubts
are borne out by the regularity with which calls for help arrive at
this list to perform conceptually trivial drawing operations such as
this.
Such an effort seems particularly dubious if still confined within
SDL’s window and event management, when it might be more useful
factored into a separate component depending only on the underlying
API (GL/D3D/etc) it wraps. I might change my tune given evidence it
can be done well (specifically, being reliably/predictably efficient,
sufficiently powerful, and consistent across backends and hardware
configurations), but based on both the frequency with which I write
small custom drawing routines while in software mode, and the
ever-growing number of different blending, filtering, and multitexture
configurations I’m using in a small OpenGL program just doing
straightforward 2D graphics, I have my doubts. Then again, I’m
ignorant of the philosophy behind SDL 1.3’s design, perhaps missing
the big picture, puzzling over features like multiple windows (a
solution in search of a problem?) while fretting over
instability/brokenness and incompatibilities with version 1.2.
If designing a 2D convenience library that writes directly to software surfaces, then one
naturally assumes certain things are fast, certain things are slow, and avoids designing
an API that offers the slow things - for example, rotation being a heavy operation,
flipping being a heavy operation,
Surely not. Flipping is a simple matter of scanning the input in the
opposite direction. This is basically free, if you don’t mind having
an alternate path of code to handle this case.
Getting back to the subject at hand, SDL 2D rendering has a software implementation,
and its 2D API is designed around that software implementation, so it does not expose
things that are hard/slow to do in software (scaling, flipping, rotation, blending)
Unfortunately, if you omit any feature that is hard to implement, you
end up with a library that doesn’t do anything useful. :)On Wed, Jul 14, 2010 at 9:19 AM, Forest Hale wrote:
I’m using gmail. Let me know if this is gibberish too:
Mason, the points you have made are absolutely correct. The problem is
that they do not address the reason why SDL has a software based image
processing library built into it. The software blitters are used to
manipulating images in main memory, they just happen to be usable for
rendering. Another thing to consider is that the word “game” does not
appear anywhere in Simple Direct Media Library. SDL is used for a lot
of things besides game development.
A lot of the decisions that Sam makes (IMHO) are based on his
understanding of the breadth of applications that use SDL plus an deep
belief in orthogonality. Again, IMHO, it is more important that the
API be orthogonal than anything else.
The simplest way to solve your problem is to use OpenGL or to write a
simple pixel level image swapper.On Tue, Jul 13, 2010 at 9:12 PM, Mason Wheeler wrote:
Not sure what’s going on with your mailer, Bob, but that came out as
gibberish.
From: Bob Pendleton <@Bob_Pendleton>
To: SDL Development List
Sent: Tue, July 13, 2010 7:02:08 PM
Subject: Re: [SDL] how to draw an image mirrored?x?U]o?6}???K6?v>?0???8?e??
)??PP????"??????K?i???5?!K?_??{?U?;J-S??K?&?P???:??T?o???7iA?% ??rG&V?UI?L?=9?Hi8??8p?1??_? y$E???(?kY????+dle????? ??????'s??9???8 ??&??S???UI?????F?p??4+?>1???g???? ???*???bA??r@?d????h???f?F4?U?G????PIrH?iD?>?M????i??(?)?.2<H?GA??"????=J?HR?4???}?.-?j#G)?G??m???U????????3^wp???A??I9-3?? N?V?bk??=?v{;
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
Dunno about anyone else, but neither email came out gibberish for me…
Bob Pendleton wrote:> I’m using gmail. Let me know if this is gibberish too:
On Tue, Jul 13, 2010 at 9:12 PM, Mason Wheeler wrote:
Not sure what’s going on with your mailer, Bob, but that came out as
gibberish.
From: Bob Pendleton
To: SDL Development List
Sent: Tue, July 13, 2010 7:02:08 PM
Subject: Re: [SDL] how to draw an image mirrored?x?U]o?6}???K6?v>?0???8?e??
)??PP????"??????K?i???5?!K?_??{?U?;J-S??K?&?P???:??T?o???7iA?% ??rG&V?UI?L?=9?Hi8??8p?1??_? y$E???(?kY????+dle????? ??????'s??9???8 ??&??S???UI?????F?p??4+?>1???g???? ???*???bA??r@?d????h???f?F4?U?G??? PIrH?iD?>?M????i??(?)?.2<H?GA??"????=J?HR?4???}?.-?j#G)?G??m???U????????3^wp???A??I9-3?? N?V?bk??=?v{;
Ditto.On Wednesday 14 July 2010 22:01, The Novice Coder wrote:
Dunno about anyone else, but neither email came out gibberish for me…