Hello.
I realise this may be one of those questions that gets
asked repeatedly, but I couldn’t find an answer in the
archives.
Is it likely that SDL will ever sprout scaling and
rotation functions for surfaces?
I find myself wanting to use OpenGL for everything due
to the fact that I’d have to implement a ton of scaling
and rotation code otherwise and I don’t know of any
existing library that takes pre-allocation into account
(I tend to allocate as much memory as possible up-front,
so allocating and then deallocating a surface just to do a
rotation isn’t acceptable). Of course the massive
disadvantage of using OpenGL is that it makes the
program unusable on any machine lacking acceleration.
Annoying when I’m not even doing “3D”, to speak of.
I’d love to see this in SDL. I’m surprised that they
don’t already exist as these features are so fundamental
to most multimedia/game projects.
thanks,
MC
Well, there is the SDL_gfx library… it has built-in rotozoomer functions
that you can use to scale and rotate.
The other thing is that OpenGL is compatible on computers without hardware
acceleration, right? It slows down a lot, because you do a lot of extra work
on the CPU, but it would still work… Windows comes standard with OpenGL
drivers, and Linux has Mesa. Also, for rotating and scaling, just about any
3D graphics card with any OpenGL features at all will work - the
incompatibilities come from OpenGL extensions. Rotating and scaling is just
a key part of all 3D graphics.On 6/8/07, mal content <artifact.one at googlemail.com> wrote:
Hello.
I realise this may be one of those questions that gets
asked repeatedly, but I couldn’t find an answer in the
archives.
Is it likely that SDL will ever sprout scaling and
rotation functions for surfaces?
I find myself wanting to use OpenGL for everything due
to the fact that I’d have to implement a ton of scaling
and rotation code otherwise and I don’t know of any
existing library that takes pre-allocation into account
(I tend to allocate as much memory as possible up-front,
so allocating and then deallocating a surface just to do a
rotation isn’t acceptable). Of course the massive
disadvantage of using OpenGL is that it makes the
program unusable on any machine lacking acceleration.
Annoying when I’m not even doing “3D”, to speak of.
I’d love to see this in SDL. I’m surprised that they
don’t already exist as these features are so fundamental
to most multimedia/game projects.
thanks,
MC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
“If you see somebody who you don’t know getting into a crop duster that
doesn’t belong to you, report them.” – President George W. Bush
Well, there is the SDL_gfx library… it has built-in rotozoomer functions
that you can use to scale and rotate.
I didn’t know about SDL_gfx. Somehow I managed to miss
it on the list of libraries. I’ll take a look at it.
The other thing is that OpenGL is compatible on computers without hardware
acceleration, right? It slows down a lot, because you do a lot of extra work
on the CPU, but it would still work… Windows comes standard with OpenGL
drivers, and Linux has Mesa. Also, for rotating and scaling, just about any
3D graphics card with any OpenGL features at all will work - the
incompatibilities come from OpenGL extensions. Rotating and scaling is just
a key part of all 3D graphics.
Yes, I agree it does still work, but it’s too slow to
be usable. I tested some very simple OpenGL code on a
Pentium III 933 with an NVIDIA card lacking binary
drivers (no acceleration) and managed to get 2-3fps
at best. A Pentium M 1.6ghz didn’t do much better
(I’d expect 30fps minimum for purely “2D” textured
quads). I think the problem is that software GL
implementations strive for accuracy over speed - the
intended use is different.
It’s almost acceptable if no texturing is
involved, but then that sort of defeats the object…
MCOn 08/06/07, James Buchwald wrote:
Yes, I agree it does still work, but it’s too slow to
be usable. I tested some very simple OpenGL code on a
Pentium III 933 with an NVIDIA card lacking binary
drivers (no acceleration) and managed to get 2-3fps
at best. A Pentium M 1.6ghz didn’t do much better
(I’d expect 30fps minimum for purely “2D” textured
quads). I think the problem is that software GL
implementations strive for accuracy over speed - the
intended use is different.
It’s almost acceptable if no texturing is
involved, but then that sort of defeats the object…
I’ve had correct results with software render and opengl using a
P3 at 450Mhz, maybe you are not optimizing your scene properly? Like if
you have just quads, you just have one glBegin and one glEnd, that’s
it. Having many polygons will also cost way much more.
When programming for software renders, you have to plan and design
your code so it works well (and so if you have good drivers then it
works better). Having code that works with good card and trying to
force it down is asking for headaches.
But if you just want to do rotations and scalings, then look into
sdl_gfx that should make things simple. But note that having a
SRCimage -> rotate -> DSTimage will cost something too (why not cache
the result)?
Good luck!
The code was very, very simple. Four textured quads moving
horizontally across the screen in a loop to simulate the
"parallax" effect. I still have the code somewhere, I might
see if I can unearth it.
What size textures were you using on the P3 at 450? I believe
I was using 128x128 textures and that was pretty agonizing
using drivers without acceleration.
MCOn 08/06/07, Simon <simon.xhz at gmail.com> wrote:
Yes, I agree it does still work, but it’s too slow to
be usable. I tested some very simple OpenGL code on a
Pentium III 933 with an NVIDIA card lacking binary
drivers (no acceleration) and managed to get 2-3fps
at best. A Pentium M 1.6ghz didn’t do much better
(I’d expect 30fps minimum for purely “2D” textured
quads). I think the problem is that software GL
implementations strive for accuracy over speed - the
intended use is different.
It’s almost acceptable if no texturing is
involved, but then that sort of defeats the object…
I’ve had correct results with software render and opengl using a
P3 at 450Mhz, maybe you are not optimizing your scene properly? Like if
you have just quads, you just have one glBegin and one glEnd, that’s
it. Having many polygons will also cost way much more.
The code was very, very simple. Four textured quads moving
horizontally across the screen in a loop to simulate the
"parallax" effect. I still have the code somewhere, I might
see if I can unearth it.
What size textures were you using on the P3 at 450? I believe
I was using 128x128 textures and that was pretty agonizing
using drivers without acceleration.
Focusing on GL makes this thread move a bit OT, but since GL and SDL
are close friends, shouldn’t be an issue.
In software mode, i would not have used textures and would have got
more than 20fps, using textures are killers. My only suggestion to
have quick graphics is to have texture quality lower than the output
(ie if your quad is 128x128 pixels, then using a tex of 64x64 might
help, etc).
In all the tests I’ve done, when you increase gradually the quality of
the render, it starts with high fps but low polygon count and no
effects, then you move up the number of polygons until fps is too low.
Do the same with textures turned on, and do this for every special
effect you use (blending, antialising/dynamic render, etc). You
should be able to findout what is causing the issue.
One last detail to put in account is the screen size. OpenGL
refreshes the whole screen every frame. Depending on the software
drivers, the refresh is handled differently. But in software mode,
they all have in common the difficulty of refreshing large areas. (Try
lowering resolution of the screen).
And for more support on using OpenGL in software mode, try contacting
the mesagl mailing list if the community still exists they should be
more helpful for these specifics.—
However, this scene should be very quick and easy using just SDL!