Hello I was wondering if it is possible to quick flip an image.
I do mean if i have a bitmap of a person looking to the right and i want
him to look to the left.
Can i do that quick and easy? Or is the only way to do that quick having
two images (left and right looking guy)?
Hello I was wondering if it is possible to quick flip an image.
I do mean if i have a bitmap of a person looking to the right and i want
him to look to the left.
Can i do that quick and easy? Or is the only way to do that quick having
two images (left and right looking guy)?
In plain SDL I don’t know any easy solution to this problem, ie. you pass flag and you get mirrored image on the screen. You could write function that reads all pixels and copies them to other SDL_Surface, which is then blitted on the screen… problem is, that would be horribly slow.
Of course, you could use OpenGL and sligthly change texture coordinates (that’s really easy), also you would gain hardware accelerated alpha blending etc. but you would need to learn new API. There’s also glSDL, maybe it could help…?
Probably this mail won’t be very helpful :-/
Koshmaar
Hello I was wondering if it is possible to quick flip an image.
I do mean if i have a bitmap of a person looking to the right and
i want him to look to the left.
Can i do that quick and easy? Or is the only way to do that quick
having two images (left and right looking guy)?In plain SDL I don’t know any easy solution to this problem, ie.
you pass flag and you get mirrored image on the screen.
No such features in SDL. Most of the time, you don’t want them anyway,
since it takes more than flipping images to make things look good.
Artwork is usually drawn or rendered with the light source in the top
left corner of the scene or something, so flipped images will look
weird.
You could
write function that reads all pixels and copies them to other
SDL_Surface, which is then blitted on the screen…
Easier and faster, but still not exactly lightning fast: Blit single
pixel wide strips looping the x coordinate in different directions on
the source and destination surfaces. That will work with or without
hardware acceleration, but it results in a great deal of function
call and blit setup overhead.
There’s also glSDL, maybe it could help…?
Nope, glSDL only aims to be a backend compatible with the normal SDL
2D API, to bring high performance hardware acceleration to "SDL 2D"
applications on any platform that provides accelerated OpenGL.
If you need advanced rendering features and/or need full hardware
acceleration for speed, OpenGL is a nice and portable API, which
works fine together with SDL. If you need what it provides, just use
it directly.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 28 December 2004 21.16, Koshmaar wrote:
No such features in SDL. Most of the time, you don’t want them anyway,
since it takes more than flipping images to make things look good.
Artwork is usually drawn or rendered with the light source in the top
left corner of the scene or something, so flipped images will look
weird.
Usually doesn’t mean always - ie. in my current game I will have characters that can run left or right, and ligtht source will be probably pointing straight down. Now, it wouldn’t make sense for me to have two images on the disk, one being exactly mirrored copy of the other, and it would be painfull to keep them synchronized, wastfull - twice as more memory for characters, my zips that I give to publicity would increase etc. In this situation, mirroring is very useful.
And when we’re not talking about blitting characters, tiles etc. (well, I would say that especially when we’re not talking about them!) it’s sometimes very good to be able to blit mirrored surface, I think you will agre 
Nope, glSDL only aims to be a backend compatible with the normal SDL
2D API, to bring high performance hardware acceleration to "SDL 2D"
applications on any platform that provides accelerated OpenGL.
Ah yes, I forgot about it… but in this case…
If you need advanced rendering features and/or need full hardware
acceleration for speed, OpenGL is a nice and portable API, which
works fine together with SDL. If you need what it provides, just use
it directly.
… I think I read somewhere that SDL 1.3 will add new, serious improvements to SDL API - ie. multiple windows, event queues, using OpenGL for much faster graphics rendering… would it make sense to add new “blitting” function, ie. SDL_BlitSurfaceEx (well, forgot the name, it’s not important now) where user could pass “float rotate” parameter, and surface would be blitted as rotated one, by rotate degrees? It would be annoying to have new, OpenGL based SDL API and not been able to rotate surface strictly by SDL - so a must for writing annoying wrappers, workarounds etc. would sadly arise. Also, mirroring (vertical and horizontal) would be pleased (all in one function?), I can send code of function that does all of this.
Only disadvantage to adding such function I can think about, is that SDL can eventually get bloated of too many helpful, wrapper functions… but I also think that’s not case in this situation, since there’s no good way to workaround it in current SDL API (David Olofson said only using OGL can help), and when we’ll get native OpenGL support in SDL, it would be annoying to query for GLuint of texture, call OpenGL functions etc.
In summary, if I am right that SDL 1.3 will use OpenGL for rendering, I would suggest adding function for rotating, mirroring and pivoting (see below), oh, now I realized that stretching would also be very useful! Probably you already planned adding it… though, I just wanted to remind it
(as a side note, since beginning, Allegro natively supports rotating, pivoting (I guess it’s called like this - rotating around arbitrary point, not necessary center) and mirroring in software)
Koshmaar
[…]
If you need advanced rendering features and/or need full hardware
acceleration for speed, OpenGL is a nice and portable API, which
works fine together with SDL. If you need what it provides, just
use it directly.
[…]
In summary, if I am right that SDL 1.3 will use OpenGL for
rendering, I would suggest adding function for rotating, mirroring
and pivoting (see below), oh, now I realized that stretching would
also be very useful! Probably you already planned adding it…
though, I just wanted to remind it
The problem is that anything added to the SDL API must also be
supported on all other backends - not just the glSDL-on-steroids of
the future SDL 1.3. That means software fallbacks, that are either
too slow for any form of real time use, or that use shortcuts that
make some artwork look horrible, or both. Adding just a few of these
features means opening up a gigantic can of worms with quality/speed
conflicts, countless special cases to optimize - and still, all you
get is a slow and/or horrible looking fallback for users who don’t
have accelerated OpenGL or Direct3D/DirectGraphics.
Viable or not? Well, it’s going to be more work than adding native s/w
rendering to a single game… (Can’t cut any corners, since we have
no idea what kind of data people will throw at us.) It would be a
cool thing to have, but who will hack, debug and optimize all that
s/w blitter code?
(as a side note, since beginning, Allegro natively supports
rotating, pivoting (I guess it’s called like this - rotating around
arbitrary point, not necessary center) and mirroring in software)
You can add this to SDL with add-on libraries, and there are a few…
How do these compare to Allegro? If you design a game that’s using
this stuff in real time (“OpenGL recommended”), is it even remotely
possible to play it using any of these s/w blitters?
If not, I think we’re talking about two different things here:
-
Real time rendering directly to the screen. For
transformations and blending, you need hardware
acceleration for usable performance. Off-screen
rendering and multi-stage operations may not be
important, or even possible to accelerate. -
Off-line rendering, to generate and process
graphics when installing or starting the game.
This is better done using software blitters, since
you generally want the best quality (not whatever
the user has configured the drivers for) and you
want the same results on every system. Hardware
acceleration may not even be usable for this at
all some times, due to API and/or implementation
restrictions.
If it’s OK to partition SDL into “fast” and “slow” feature sets; one
aimed at 1 and one aimed at 2, I guess it’s not all that much work to
do. Though one may claim that 2 is outside the scope of SDL, there is
an advantage to having the full range of tools in the same box, all
using the same data types and API style - and it allows at least some
level of softwar/acceleration transparency. Games will at least "run"
if you use low resolutions and enforce low quality - which is an easy
hack in a game if you’re using the new SDL API anyway. Some will be
totally playable with normal settings with or without h/w
acceleration.
So, we’d need a lot of blitter code for this to work, but I guess most
of it is out there already, in various add-on libraries and games…
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 29 December 2004 00.47, Koshmaar wrote:
SDL doesn’t have it, but there’s no reason you can’t code it.
I’ve already looked at what it takes to program an “old school”, with
really no realtime lighting mario style sidescroller where mirroring and
90 degree rotations are handy…and what I’ve decided to do is have one
image stored, and have the program, at startup, do all the rotations and
transformations and “expand” the image for me. (Left/Right for 4
"norths", up, down, left, and right is 8 images from one.)
You do it programatically so left is always the same number for every
image, and there you have it. With just a little more coding you save
on diskspace, and you get the fast blitting of a static image.
Not what you were looking for, but not too nasty to implement. Maybe a
little memory wasteful, but that’s the end users’s system that has to
worry about it, not your bandwidth…On Tue, 2004-12-28 at 14:23, Serjan Pruis wrote:
Hello I was wondering if it is possible to quick flip an image.
I do mean if i have a bitmap of a person looking to the right and i want
him to look to the left.
Can i do that quick and easy? Or is the only way to do that quick having
two images (left and right looking guy)?
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Memory shouldn’t be an issue, unless you have loads of graphics and/or
want smooth rotation of objects rather than just mirroring or 90?
turns.
Either way, when working on this level, it’s relatively easy to make
the code scalable all the way from load time rotation into 8
frames/sprite (the original Kobo Deluxe graphics, which I’m still
using, only uses 8 frames per rotation BTW) via lots of frames (say
256/rotation) through real time rotation directly to the screen.
This should mix well with an extended SDL 1.3 API, with "worst case"
fallbacks still usable for load time prerendering and OpenGL or
Direct3D rendering in the high end of the spectra.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 29 December 2004 03.55, Austin W. Dunham V wrote:
SDL doesn’t have it, but there’s no reason you can’t code it.
I’ve already looked at what it takes to program an “old school”,
with really no realtime lighting mario style sidescroller where
mirroring and 90 degree rotations are handy…and what I’ve decided
to do is have one image stored, and have the program, at startup,
do all the rotations and transformations and “expand” the image for
me. (Left/Right for 4 “norths”, up, down, left, and right is 8
images from one.)You do it programatically so left is always the same number for
every image, and there you have it. With just a little more
coding you save on diskspace, and you get the fast blitting of a
static image.Not what you were looking for, but not too nasty to implement.
Maybe a little memory wasteful, but that’s the end users’s system
that has to worry about it, not your bandwidth…
SDL doesn’t have it, but there’s no reason you can’t code it.
I’ve already looked at what it takes to program an “old school”,
with really no realtime lighting mario style sidescroller where
mirroring and 90 degree rotations are handy…and what I’ve decided
to do is have one image stored, and have the program, at startup,
do all the rotations and transformations and “expand” the image for
me. (Left/Right for 4 “norths”, up, down, left, and right is 8
images from one.)You do it programatically so left is always the same number for
every image, and there you have it. With just a little more
coding you save on diskspace, and you get the fast blitting of a
static image.Not what you were looking for, but not too nasty to implement.
Maybe a little memory wasteful, but that’s the end users’s system
that has to worry about it, not your bandwidth…Memory shouldn’t be an issue, unless you have loads of graphics and/or
want smooth rotation of objects rather than just mirroring or 90?
turns.Either way, when working on this level, it’s relatively easy to make
the code scalable all the way from load time rotation into 8
frames/sprite (the original Kobo Deluxe graphics, which I’m still
using, only uses 8 frames per rotation BTW) via lots of frames (say
256/rotation) through real time rotation directly to the screen.This should mix well with an extended SDL 1.3 API, with "worst case"
fallbacks still usable for load time prerendering and OpenGL or
Direct3D rendering in the high end of the spectra.
What about creating a new surface-like “object” that is a reference to
a surface plus some transformation matrix and possibly a color
transformation. For software-rendered surfaces, it could prerender the
given scale/rotation. For hardware accelerated surfaces, it would send
whatever is appropriate for the backend without worrying about
prerendering. The software renderer could analyze the matrix to see if
it’s lossless (90? rotation, mirroring) and choose a fast algorithm.
There should also be some (global?) way to tell the backend which
algorithm you want to use (probably generalized to “quality”) – which
may also apply to hardware accelerated backends as well.
Yes, of course, some people would take advantage of this in ways that
wouldn’t perform acceptably with a software renderer. However, as long
as those risks are documented and there is a way to query SDL to see if
these functions are accelerated or not, developers that want to support
the software renderer can provide some kind of alternate code path or
develop it in a way that caches a bunch of these objects representing
every state that the surface will be rendered with.
-bobOn Dec 28, 2004, at 10:04 PM, David Olofson wrote:
On Wednesday 29 December 2004 03.55, Austin W. Dunham V wrote:
[…]
What about creating a new surface-like “object” that is a reference
to a surface plus some transformation matrix and possibly a color
transformation.
That’s one way of adding information to the SDL_Surface struct. SDL
backends (including the new glSDL) do it internally through a
"private" pointer in the SDL_Surface struct. glSDL/wrapper does it by
abusing the ‘unused1’ field as an index into an array of pointers
that is populated with glSDL_TexInfo structs as needed.
glSDL/wrapper hides all this and “fakes” the SDL API by #defining over
affected SDL calls with glSDL equivalents. A proper add-on library
would do it cleaner and safer by having you use a new set of
rendering calls - which may of course take a new surface type instead
of SDL_Surface, avoiding application side "hook into SDL_Surface"
hacks of the kind I used in glSDL/wrapper.
Backends - of course - are completely invisible to applications as
they hook into SDL from the other side, as it’s meant to be done, and
thus, you always use the same calls and the same structs regardless
of what backend you’re using.
Just slightly different ways of doing the same thing… The code
that does the actual work remains very similar, give or take some
differences in the ability to make full use of the SDL internals and
the underlying API.
For software-rendered surfaces, it could prerender
the given scale/rotation.
When? Unless you somehow tell the “engine” what you’ll need
beforehand, it’ll have to do this rendering every now and then when
the application is running. (Assuming that rendered surfaces are
cached - or it would have to rerender whenever you change the
transformation properties!)
For hardware accelerated surfaces, it
would send whatever is appropriate for the backend without worrying
about prerendering. The software renderer could analyze the matrix
to see if it’s lossless (90? rotation, mirroring) and choose a fast
algorithm.
Typical optimizations… Problem is that there’s no end to the special
cases that may be useful - but it’s next to impossible to figure out
which ones actually make a difference unless you know exactly what
data you’ll be dealing with.
There should also be some (global?) way to tell the
backend which algorithm you want to use (probably generalized to
"quality") – which may also apply to hardware accelerated backends
as well.
Yeah, that’s pretty much a requirement for scalability, especially if
that includes both h/w and s/w rendering. It’s also a requirement for
automatic caching of frames, to figure out suitable granularities for
the transformation parameters. (Otherwise, a game that does
everything ultra smooth in floating point will run dog slow and
consume all available memory very quickly, generating frames that
will never be reused.)
Yes, of course, some people would take advantage of this in ways
that wouldn’t perform acceptably with a software renderer.
I suspect that with quantized transformation parameters and caching of
rendered frames, it would be pretty hard to make a game completely
unplayable. The user may have to play around with the transformation
granularity and rendering quality settings a bit, but pretty much
anything should sort of run, even though extreme cases may look like
crap before they reach playable frame rates. 
However, as long as those risks are documented and there is a way
to query SDL to see if these functions are accelerated or not,
developers that want to support the software renderer can provide
some kind of alternate code path or develop it in a way that caches
a bunch of these objects representing every state that the surface
will be rendered with.
If this is implemented as an add-on library (perhaps in combination
with future SDL API extensions), I think the caching and “scalability
tools” would be well within the scope of that library. If you don’t
want the default "render before first use, if it’s not in the cache"
behavior, just do dummy blits of all objects in all positions that
will occur - just like you do now to make SDL actually perform RLE
encoding and stuff.
Of course, you could add an API to tell the engine to prerender into
the cache, but that’s not going to be much simpler, and probably not
nearly as accurate and reliable. After all, actually doing what you
want the engine to prepare for has to be the most obvious and
fool-proof way of passing that kind of information, right? Possibly
add a feature to disable everything but the actual rendering into
cache, for maximum efficiency…
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 29 December 2004 06.13, Bob Ippolito wrote:
Try a library for image rendering, such as SGE ( SDL Graphics Extension
: http://www.etek.chalmers.se/~e8cal1/sge/ ). This seems to be a great
library, but I’ve never tried …
Regards;
Pedro Amaral Couto
Footnote:
Three/two years ago, when I was trying to deal with SDL API I made a few
rendering functions, such as flipping, scaling, rotating, pixel logic
handling ( or,and,xor,not, … ) … it is quite easy to code ( the only
problem is to find optimizations, performance and keep in mind all
SDL_Surface stuff - such as RLE and hardware acceleration ), but since
there’s libraries for these purposes and think this only have meaning if
you want to learn " how do its done " or to hack/found a better way to
do things. For fast blitting, it’s to low-level for my taste.
A Ter, 2004-12-28 ?s 19:23, Serjan Pruis escreveu:> Hello I was wondering if it is possible to quick flip an image.
I do mean if i have a bitmap of a person looking to the right and i want
him to look to the left.
Can i do that quick and easy? Or is the only way to do that quick having
two images (left and right looking guy)?
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
The problem is that anything added to the SDL API must also be
supported on all other backends - not just the glSDL-on-steroids of
the future SDL 1.3. That means software fallbacks, that are either
too slow for any form of real time use, or that use shortcuts that
make some artwork look horrible, or both. Adding just a few of these
features means opening up a gigantic can of worms with quality/speed
conflicts, countless special cases to optimize - and still, all you
get is a slow and/or horrible looking fallback for users who don’t
have accelerated OpenGL or Direct3D/DirectGraphics.
Ok, that’s enough; I thought that new SDL will support OpenGL on every possible platform - silly, but it’s true
In this case, it really would be bad idea to open this Pandora’s box. But (probably) better idea would be to give easy access to texture’s GLuint, so at least writing manual code for rotation would be much simplier.
You can add this to SDL with add-on libraries, and there are a few…
How do these compare to Allegro? If you design a game that’s using
this stuff in real time (“OpenGL recommended”), is it even remotely
possible to play it using any of these s/w blitters?
I don’t know, I just saw that they’re in documentation, didn’t tested them.
Koshmaar
The problem is that anything added to the SDL API must also be
supported on all other backends - not just the glSDL-on-steroids
of the future SDL 1.3. That means software fallbacks, that are
either too slow for any form of real time use, or that use
shortcuts that make some artwork look horrible, or both. Adding
just a few of these features means opening up a gigantic can of
worms with quality/speed conflicts, countless special cases to
optimize - and still, all you get is a slow and/or horrible
looking fallback for users who don’t have accelerated OpenGL or
Direct3D/DirectGraphics.Ok, that’s enough; I thought that new SDL will support OpenGL on
every possible platform - silly, but it’s true
It already does, AFAIK, and glSDL will (already does, if you’re
willing to use the wrapper or patch your SDL lib) allow the use of
OpenGL through the normal SDL 2D API.
The problem is that OpenGL isn’t available (at least not in
accelerated form) on all platforms (remember; SDL runs on PDAs, 16
bit computers and pre-3D-boom consoles!), and not even on all systems
based on platforms that do support OpenGL. (Many old Windows machines
have video cards and/or drivers without OpenGL support, and the
situation is even worse with Linux. For example, on my old Linux
workstation, OpenGL cannot be accelerated unless I disable the
secondary head.)
Besides, many implementations of OpenGL have limitations that render
them unable to perform some of the operations supported by the SDL
API (such as blitting between off-screen surfaces and blitting
without a visible display context), so even if there was OpenGL
everywhere, the software blitters would be needed.
In this case, it
really would be bad idea to open this Pandora’s box. But (probably)
better idea would be to give easy access to texture’s GLuint, so at
least writing manual code for rotation would be much simplier.
If you do that, all you get is inefficient code that depends on the
inner workings of glSDL (which may well change drastically at any
time, for SDL compatibility and/or performance reasons) and
requires OpenGL to work at all.
If the OpenGL requirement is ok, why not just use OpenGL directly, or
together with one of the many OpenGL wrappers/helpers out there…?
(Or roll your own, or fork glSDL and turn it into a dedicated OpenGL
2D rendering helper, or whatever.) Those are designed specifically to
make it easier to use OpenGL, whereas the only motivation for glSDL’s
existence is to provide hardware acceleration to pure "SDL 2D"
applications where available, without having to rewrite parts of the
aplications.
So, it’s either all or nothing. Any rendering extensions to glSDL will
be a side effect (and/or motivation) of API extensions implemented on
all backends. It doesn’t have to mean that all software fallbacks
must be lightning fast and suitable for real time use (see other
posts on caching and stuff), but I have a hard time seeing how
features that only work at all when OpenGL is available have any
place in the core SDL 2D API. If you care about performance, you can
do run-time checks and avoid features that are not accelerated - but
what do you do if some features you need completely go away on some
systems…?
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 29 December 2004 15.07, Koshmaar wrote:
It already does, AFAIK, and glSDL will (already does, if you’re
willing to use the wrapper or patch your SDL lib) allow the use of
OpenGL through the normal SDL 2D API.The problem is that OpenGL isn’t available (at least not in
accelerated form) on all platforms (remember; SDL runs on PDAs, 16
bit computers and pre-3D-boom consoles!), and not even on all systems
based on platforms that do support OpenGL. (Many old Windows machines
have video cards and/or drivers without OpenGL support, and the
situation is even worse with Linux. For example, on my old Linux
workstation, OpenGL cannot be accelerated unless I disable the
secondary head.)
When writing a 2d game, it’s possible to support both GL and non-GL.
Abstraction is needed ( warpers for SDL_Surface and functions - hint:
function pointers ), or/and preprocessing ( what support we want to
compile ). If programming with Object Oriented Language, this is natural
and easy.
I think glSDL would be a better idea with this approach
compile library depending on OpenGL machine/system support;
execute -> try OpenGL [: not supported -> disable GL] ) -> … -> end.
Have a look at GtkGlExt ( not related to SDL ) : it’s great - transforms
drawables ( or “images” ) to GL equivalent; this is possible because
GTK+ is object oriented ( not the language, only the approach … ).
I always program the logic part of the program independent of the video
part ( diferent files ) - the rendering functions depends on the logic
file, but thats ok.
main.c <-- *.h;
sdl.c;
sdl_video.c <-- (sdl.h);
sdl_events.c <-- (sdl.h);
sdl_scene.c <-- sdl_video.h, sdl_logic.h;
logic.c
This way, if someone wants to write an OpenGL version, it needs to
change sdl.c, sdl_video.c and sdl_scene.c:
main.c <-- *.h;
sdlgl.c;
sdlgl_video.c <-- (sdlgl.h);
sdl_events.c <-- (sdlgl.h);
sdlgl_scene.c <-- sdlgl_video.h, logic.h;
logic.c
Regards and Happy New Year;
Pedro Amaral Couto
[…]
When writing a 2d game, it’s possible to support both GL and
non-GL. Abstraction is needed ( warpers for SDL_Surface and
functions - hint: function pointers ), or/and preprocessing ( what
support we want to compile ). If programming with Object Oriented
Language, this is natural and easy.
I find it really rather easy in C as well… (See smoothscroll for a
simple example.)
It’s just that SDL already is a wrapper (for whatever API you’re
using at the moment), so it’s kind of silly to treat OpenGL
specially. If all you need is the SDL 2D API, you shouldn’t have to
hack your application just to get at the hardware acceleration that
OpenGL (or maybe also Direct3D in the future) provides. Preferably,
you shouldn’t even have to recompile; just upgrade the SDL lib.
I think glSDL would be a better idea with this approach
compile library depending on OpenGL machine/system support;
execute -> try OpenGL [: not supported -> disable GL] ) -> … ->
end.
This is exactly what it’s been doing from the very first version.
The backend and the last wrapper versions load OpenGL on demand, so
they’ll load and run whether or not OpenGL is installed on the target
system. (Older versions of the wrapper were just linked to OpenGL, so
they wouldn’t load without some OpenGL lib in place. That’s why some
Kobo Deluxe/Win32 releases come with two binaries.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 29 December 2004 17.06, PedroAC wrote:
[…]
What about creating a new surface-like “object” that is a reference
to a surface plus some transformation matrix and possibly a color
transformation.That’s one way of adding information to the SDL_Surface struct. SDL
backends (including the new glSDL) do it internally through a
"private" pointer in the SDL_Surface struct. glSDL/wrapper does it by
abusing the ‘unused1’ field as an index into an array of pointers
that is populated with glSDL_TexInfo structs as needed.glSDL/wrapper hides all this and “fakes” the SDL API by #defining over
affected SDL calls with glSDL equivalents. A proper add-on library
would do it cleaner and safer by having you use a new set of
rendering calls - which may of course take a new surface type instead
of SDL_Surface, avoiding application side "hook into SDL_Surface"
hacks of the kind I used in glSDL/wrapper.Backends - of course - are completely invisible to applications as
they hook into SDL from the other side, as it’s meant to be done, and
thus, you always use the same calls and the same structs regardless
of what backend you’re using.Just slightly different ways of doing the same thing…
that does the actual work remains very similar, give or take some
differences in the ability to make full use of the SDL internals and
the underlying API.
Changing the surface structure is the wrong way to do it in this case.
The whole point to adding this new structure is to support new API and
to keep a reference to the original surface. It’s not 1:1 with
surfaces, and keeping a reference to the original bitmap is important.
There will be some kind of “userdata” backend pointer in there so that
it can store a cached surface, a converted matrix, or whatever else it
feels is necessary. It can allocate this when the transformation is
finalized.
For software-rendered surfaces, it could prerender
the given scale/rotation.When? Unless you somehow tell the “engine” what you’ll need
beforehand, it’ll have to do this rendering every now and then when
the application is running. (Assuming that rendered surfaces are
cached - or it would have to rerender whenever you change the
transformation properties!)
Either on first blit or some explicit finalization function (which may
be a trivial blit as you mentioned elsehwere)… any change to the
transformation object should invalidate its underlying prerendered
surface if it has one.
Note that since transformation objects keep references to surfaces,
rerendering upon change to the transformation properties is not an
issue. If you care about software rendering, then you will have N
prerendered transformation objects representing the N states of your
surface that you want to have readily available. It would be crazy to
try and cache things automagically.
For hardware accelerated surfaces, it
would send whatever is appropriate for the backend without worrying
about prerendering. The software renderer could analyze the matrix
to see if it’s lossless (90? rotation, mirroring) and choose a fast
algorithm.Typical optimizations… Problem is that there’s no end to the special
cases that may be useful - but it’s next to impossible to figure out
which ones actually make a difference unless you know exactly what
data you’ll be dealing with.
Of course, but it is up to the backend to decide what it wants to
special case. I’m just saying that a separate API for the fast flips
and rotation probably shouldn’t be bothered with. However, some
constant transformation matrices that represent the most common
lossless transformations wouldn’t be a bad idea.
-bobOn Dec 29, 2004, at 2:20 AM, David Olofson wrote:
On Wednesday 29 December 2004 06.13, Bob Ippolito wrote:
[…]
Changing the surface structure is the wrong way to do it in this
case. The whole point to adding this new structure is to support
new API and to keep a reference to the original surface. It’s
not 1:1 with surfaces, and keeping a reference to the original
bitmap is important. There will be some kind of “userdata” backend
pointer in there so that it can store a cached surface, a converted
matrix, or whatever else it feels is necessary. It can allocate
this when the transformation is finalized.
Ah, you’re talking about a new “class”; some sort of transformation
object that is used instead of lots of arguments to rendering calls,
and allows percistent data for caching and stuff?
That’s an interesting idea. The current SDL API has the annoying side
effect that you have to make destructive changes to the SDL_Surface
to change full surface alpha, colorkey and other parameters, and you
have to clone the entire surface to avoid that. It’s no big deal now,
but it might start to get messy when transformation and blending
parameters are thrown in the mix.
[…]
Either on first blit or some explicit finalization function (which
may be a trivial blit as you mentioned elsehwere)… any change to
the transformation object should invalidate its underlying
prerendered surface if it has one.Note that since transformation objects keep references to
surfaces, rerendering upon change to the transformation properties
is not an issue. If you care about software rendering, then you
will have N prerendered transformation objects representing the N
states of your surface that you want to have readily available. It
would be crazy to try and cache things automagically.
Nice. Less work for SDL and more control to applications and add-on
libs.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 29 December 2004 18.12, Bob Ippolito wrote:
Ok, that’s enough; I thought that new SDL will support OpenGL on
every possible platform - silly, but it’s true
It already does, AFAIK, and glSDL will (already does, if you’re
willing to use the wrapper or patch your SDL lib) allow the use of
OpenGL through the normal SDL 2D API.
Ups, I really meant…
The problem is that OpenGL isn’t available (at least not in
accelerated form) on all platforms
… which could be transormed to: “if SDL would have working OGL implementations on all platforms it supports…”, sorry for not being clear.
If you do that, all you get is inefficient code that depends on the
inner workings of glSDL (which may well change drastically at any
time, for SDL compatibility and/or performance reasons) and
requires OpenGL to work at all.
Well, that would be used only by those who want it - ie, there’s unused member in SDL_Surface. It could be used as storage for GLuint returned by glGenTextures… or not. I’m just saying that there should be some fast and easy way to obtain this value, would it be SDL_Surface member or some new function in API… otherwise, it could be hard even for SDL extender library, that is assuming you’re using platform that fully supports OGL, to get this value without messing with internal workings of glSDL/SDL. It would be used only by those who are sure they want to use and will allways have OGL implementation (I know, sounds stupid).
Or if I don’t undestand some crucial point here, just tell and I will stop saying stupid things
If the OpenGL requirement is ok, why not just use OpenGL directly, or
together with one of the many OpenGL wrappers/helpers out there…?
(Or roll your own, or fork glSDL and turn it into a dedicated OpenGL
2D rendering helper, or whatever.)
I already written my own OGL wrapper long time ago, so it’s not for me :-]
Koshmaar
[…]
Changing the surface structure is the wrong way to do it in this
case. The whole point to adding this new structure is to support
new API and to keep a reference to the original surface. It’s
not 1:1 with surfaces, and keeping a reference to the original
bitmap is important. There will be some kind of “userdata” backend
pointer in there so that it can store a cached surface, a converted
matrix, or whatever else it feels is necessary. It can allocate
this when the transformation is finalized.Ah, you’re talking about a new “class”; some sort of transformation
object that is used instead of lots of arguments to rendering calls,
and allows percistent data for caching and stuff?
Yeah, exactly.
That’s an interesting idea. The current SDL API has the annoying side
effect that you have to make destructive changes to the SDL_Surface
to change full surface alpha, colorkey and other parameters, and you
have to clone the entire surface to avoid that. It’s no big deal now,
but it might start to get messy when transformation and blending
parameters are thrown in the mix.
Sounds like things that the proposed transformation “class” would
probably do better anyway. It may cost more in terms of memory if the
surfaces needed to be cached, but you can free that memory simply by
creating a new surface object and blitting to it (copy the cache, if it
exists) then getting rid of the transformation object. I doubt that
will often be necessary, because most of the time I think that people
do want this class of operations to be non-destructive.
-bobOn Dec 29, 2004, at 12:39 PM, David Olofson wrote:
On Wednesday 29 December 2004 18.12, Bob Ippolito wrote:
[…]
… which could be transormed to: “if SDL would have working OGL
implementations on all platforms it supports…”, sorry for not
being clear.
Well, it could theorletically, but it’s kind of pointless, since it’s
generally not possible to implement hardware acceleration on the
application/library level, and you definitely do not want to run
something like glSDL on top of a s/w OpenGL implementation!
(If you specifically need OpenGL for some off-line or background scene
rendering, there are stand-alone software implementations you can
use, so there’s no need to build that into SDL.)
If you do that, all you get is inefficient code that depends on
the inner workings of glSDL (which may well change drastically at
any time, for SDL compatibility and/or performance reasons) and
requires OpenGL to work at all.Well, that would be used only by those who want it - ie, there’s
unused member in SDL_Surface. It could be used as storage for
GLuint returned by glGenTextures… or not. I’m just saying that
there should be some fast and easy way to obtain this value, would
it be SDL_Surface member or some new function in API… otherwise,
it could be hard even for SDL extender library, that is assuming
you’re using platform that fully supports OGL, to get this value
without messing with internal workings of glSDL/SDL.
Problem is that you can’t safely use OpenGL directly at all while
using glSDL, since the relation between (gl)SDL calls and the OpenGL
state is undefined. glSDL may screw up your state, or you may screw
up glSDL’s state, or both.
It would be
used only by those who are sure they want to use and will allways
have OGL implementation (I know, sounds stupid).
An add-on library that needs OpenGL should stay far away from glSDL.
There isn’t much glSDL does that is of much use to an OpenGL wrapper,
and the few things that may be of use are hairy and hard to access
even if the relevant structures were to be set in stone and published
in the API. If you need that sort of stuff, just rip the code you
need from glSDL or roll your own.
The only possible exception would be some class of optional “backend
extenders” that add both API and backend features to one or more SDL
backends. For example, you could have an SDL_3D lib that adds basic
3D transformations to the SDL API, with hooks to OpenGL via glSDL as
well as software fallbacks for the other backends.
However, such things tend to sound great in theory, but turn out a
complete mess if you actually try to implement them. Getting that
kind of stuff working properly and efficiently is hard to do without
exposing the full internals of SDL to the “extender libs” - and if
you do that, you may as well merge the extender lib into the core
lib, since any core lib change potentially breaks the extender lib.
Just as an example, the way glSDL tiles huge textures may change at
any time. An extender lib would have to be updated whenever such
changes occur to be able to use the textures at all. Using the wrong
version would result in weird results or crashes.
Another example would be SDL’s RLE encoded surfaces. Whenever the
details of the RLE format changes, any libs messing with it will have
to be updated as well.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 29 December 2004 19.00, Koshmaar wrote:
Hi,
There’s been a lot of discussion about the pros and cons of image
flipping and whatnot in this thread, and to be honest I haven’t read all
of it, but the truth is that mirroring images is useful in a lot of
simple games. Since I’ve just written some code to do this, I might as
well post it here.
One catch: It’s in D, but the differences to C shouldn’t be so great.
Basically, replace the . with ->, replace uint with Uint32 and ubyte
with Uint8. And one line contains the copy of an array slice, which
would need to be reimplemented with memcpy in C.
The actual point is to show the principle; if you know the principle of
it, reimplementing it should be easy.
By the way, it doesn’t matter if it’s slow, because it should be done at
load time anyway (or at the time it’s first requested, but not at
every draw).
SDL_Surface* hmirror(SDL_Surface* sfc)
{
SDL_Surface* result = SDL_CreateRGBSurface(sfc.flags, sfc.w, sfc.h,
sfc.format.BytesPerPixel * 8, sfc.format.Rmask, sfc.format.Gmask,
sfc.format.Bmask, sfc.format.Amask);
ubyte* pixels = cast(ubyte*) sfc.pixels;
ubyte* rpixels = cast(ubyte*) result.pixels;
uint pitch = sfc.pitch;
uint pxlength = pitch*sfc.h;
uint bypp = sfc.format.BytesPerPixel;
assert(result != null);
for(uint col = 0; col < pitch; col += bypp) {
for(uint line = 0; line < sfc.h; ++line) {
uint rpos = line * pitch + col;
uint pos = line * pitch + (pitch - col - bypp);
rpixels[rpos..rpos+bypp] = pixels[pos..pos+bypp];
}
}
return result;
}
Here’s another one for vertical (upside-down) mirroring:
SDL_Surface* flipVert(SDL_Surface* sfc)
{
SDL_Surface* result = SDL_CreateRGBSurface(sfc.flags, sfc.w, sfc.h,
sfc.format.BytesPerPixel * 8, sfc.format.Rmask, sfc.format.Gmask,
sfc.format.Bmask, sfc.format.Amask);
ubyte* pixels = cast(ubyte*) sfc.pixels;
ubyte* rpixels = cast(ubyte*) result.pixels;
uint pitch = sfc.pitch;
uint pxlength = pitch*sfc.h;
assert(result != null);
for(uint line = 0; line < sfc.h; ++line) {
uint pos = line * pitch;
rpixels[pos..pos+pitch] =
pixels[(pxlength-pos)-pitch…pxlength-pos];
}
return result;
}
Sebastian
Serjan Pruis schrieb:> Hello I was wondering if it is possible to quick flip an image.
I do mean if i have a bitmap of a person looking to the right and i want
him to look to the left.
Can i do that quick and easy? Or is the only way to do that quick having
two images (left and right looking guy)?
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl