Hi everyone,
Hi, umm…my name is Mike and…I’m a lurker.
I’ve been lurking on this list for months and I finally have a
question: I’ve written a simple little program that layers a map 2 screens
wide with 32x32 tiles and scrolls from the left screen to the right
screen. Now I’m trying to speed it up a bit (“make it work FIRST, then
make it work FAST,” right?..
Anyway, it seems that video hardware should make blitting faster.
Yet, when I use the SDL_GetVideoInfo() function, it reports that there is
NO HW acceleration whatsoever. I have an ATI Mach64 server running. Is it
not yet supported under SDL yet?
Anyway, my basic experiment is to tile a 1024x384 map surface and
then blit a 512x384 region onto a 640x480 screen surface. Then I do an
SDL_Flip() on the screen. Am I doing anything redundant (or just plain
stupid) here? Is there any way to just blit a region of the map surface
straight to the display? Are there any general speed-up tips for SDL?
Thanks…
-The Mighty Mike Master
http://tmmm.simplenet.com
The Mighty Mike Master wrote:
Anyway, it seems that video hardware should make blitting faster.Yet, when I use the SDL_GetVideoInfo() function, it reports that there is
NO HW acceleration whatsoever. I have an ATI Mach64 server running. Is it
not yet supported under SDL yet?
I have also an ATI Mach64 and it does not support DGA (Direct GraphicsAccess)
under Linux. I believe that is the reason because you do not obtain
hardware acceleration.
Anyway, my basic experiment is to tile a 1024x384 map surface andthen blit a 512x384 region onto a 640x480 screen surface. Then I do an
SDL_Flip() on the screen. Am I doing anything redundant (or just plain
stupid) here? Is there any way to just blit a region of the map surface
straight to the display? Are there any general speed-up tips for SDL?
Thanks…
-The Mighty Mike Master
http://tmmm.simplenet.com
Greetings------------------
Alberto J. Fernandez
afgarcia at gmv.es
Anyway, it seems that video hardware should make blitting faster.
Someone had a suggestion to use pixmaps as hardware cached surfaces, and
this would allow the X server to perform hardware acceleration of blits,
but would make all other accesses to the surfaces very slow.
It’s on my list to add before 1.0, if people want it.
Here would be the new semantics:
If you want fast access to the video memory to do your own blitting, create
the video surface in software memory. SDL will take care of the blitting to
video memory.
If you want slow access to the video memory, and have most of your images
static and want them in video memory, create the video surface and map
surfaces with the (would-be new) flag SDL_HWCACHED. Accessing them would
be twice as slow as they are now, but blitting from one to the other should
be faster.
What do you think, everyone?
Yet, when I use the SDL_GetVideoInfo() function, it reports that there is
NO HW acceleration whatsoever. I have an ATI Mach64 server running. Is it
not yet supported under SDL yet?
There is no hardware acceleration available under the X11 driver.
Anyway, my basic experiment is to tile a 1024x384 map surface and
then blit a 512x384 region onto a 640x480 screen surface. Then I do an
SDL_Flip() on the screen. Am I doing anything redundant (or just plain
stupid) here? Is there any way to just blit a region of the map surface
straight to the display? Are there any general speed-up tips for SDL?
Well, first, make sure you pass SDL_ANYFORMAT in the flags to SDL_SetVideoMode()
so that SDL picks the “best” videomode based on your desired one and the modes
available in the server. Then, convert all your maps and sprites and so forth
to that format with SDL_DisplayFormat().
Second, make sure you are using the appropriate SDL_BlitSurface() variant.
If you really know what you are doing, you can bypass some clipping,
locking and software cursor overhead by calling SDL_UpperBlit(),
SDL_MiddleBlit(), or SDL_LowerBlit() as you need them. The overhead isn’t
that great, but if you want to squeeze the last ounce of speed out of your
application, that’s one place to look. If you have strange crashes when
you are using the lower blitting functions, it’s very possible that you
aren’t clipping the blit rectangles properly.
Third, um, well, 640x480 software scrolling won’t be very fast on anything
slower than a P2/266 or equivalent.
Thanks…
My pleasure.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Anyway, my basic experiment is to tile a 1024x384 map surface andthen blit a 512x384 region onto a 640x480 screen surface. Then I do an
SDL_Flip() on the screen. Am I doing anything redundant (or just plain
stupid) here? Is there any way to just blit a region of the map surface
straight to the display? Are there any general speed-up tips for SDL?
Well, first, blah blah…
By the way, I’m not the final word out there. If any of you have optimization
tips, feel free to jump in.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
on Die, 08 Jun 1999 Sam Lantinga wrote:
Anyway, it seems that video hardware should make blitting faster.Someone had a suggestion to use pixmaps as hardware cached surfaces, and
this would allow the X server to perform hardware acceleration of blits,
but would make all other accesses to the surfaces very slow.
It’s on my list to add before 1.0, if people want it.Here would be the new semantics:
If you want fast access to the video memory to do your own blitting, create
the video surface in software memory. SDL will take care of the blitting to
video memory.
If you want slow access to the video memory, and have most of your images
static and want them in video memory, create the video surface and map
surfaces with the (would-be new) flag SDL_HWCACHED. Accessing them would
be twice as slow as they are now, but blitting from one to the other should
be faster.
What do you think, everyone?
I would really appreciate this functionality. It would make software scrolling
much faster. One could use two buffers; one active, the second inactive. Normal
screenupdates are blit to the active buffer and updated to the screen. If you
want to scroll you blit the active buffer to the inactive buffer using some
offset. Now the inactive buffer becomes active and vice versa. (all this
blitting would be completely done in Video mem) One would only have to transfer
the row or col of the image which has been scrolled into view…
However … panning would be even better for this. Will / Is this possible with
SDL ? I mean the screen surface in fact being larger as the display and you
have an variable offset for the displayed area… This would enable scrolling
without any blitting (except for the newly exposed areas), you only have to
change the offset… this would be really fast.–
Karsten-O. Laux
klaux at student.uni-kl.de
http://www.rhrk.uni-kl.de/~klaux
UIN 21614933 (Bert)
Here would be the new semantics:
If you want fast access to the video memory to do your own blitting, create
the video surface in software memory. SDL will take care of the blitting to
video memory.
If you want slow access to the video memory, and have most of your images
static and want them in video memory, create the video surface and map
surfaces with the (would-be new) flag SDL_HWCACHED. Accessing them would
be twice as slow as they are now, but blitting from one to the other should
be faster.
What do you think, everyone?
I would really appreciate this functionality. It would make software scrolling
much faster. One could use two buffers; one active, the second inactive. Normal
screenupdates are blit to the active buffer and updated to the screen.
Unfortunately, the blits to the active buffer will be twice as slow with
the above outlined mechanism.
Here’s why:
If the surface is cached in the X server as a pixmap, then you
have to get the image from the server… unless you have X
shared memory pixmaps. Does anybody know if the server puts
X shared memory pixmaps in hardware memory? I doubt it, since
that would mean that the video memory is memory mapped into your
address space. I’ll ask on the XFree86 developer’s list.
Anyway, if you don’t have shared memory pixmaps, then to write
to the pixmap memory, you have to do a copy from the server,
local update, and then copy the contents to the server again.
However … panning would be even better for this. Will / Is this possible with
SDL ? I mean the screen surface in fact being larger as the display and you
have an variable offset for the displayed area… This would enable scrolling
without any blitting (except for the newly exposed areas), you only have to
change the offset… this would be really fast.
This isn’t currently supported, but is pretty easy to emulate in software
and support using DGA. I’ll see how to do it in DirectX…
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Alberto Jose Fernandez Garcia wrote:
The Mighty Mike Master wrote:
Anyway, it seems that video hardware should make blitting faster.Yet, when I use the SDL_GetVideoInfo() function, it reports that there is
NO HW acceleration whatsoever. I have an ATI Mach64 server running. Is it
not yet supported under SDL yet?I have also an ATI Mach64 and it does not support DGA (Direct GraphicsAccess)
under Linux. I believe that is the reason because you do not obtain
hardware acceleration.
?? The X11 Mach64 server supports DGA fine. What are you talking about?
Peter>
Anyway, my basic experiment is to tile a 1024x384 map surface andthen blit a 512x384 region onto a 640x480 screen surface. Then I do an
SDL_Flip() on the screen. Am I doing anything redundant (or just plain
stupid) here? Is there any way to just blit a region of the map surface
straight to the display? Are there any general speed-up tips for SDL?
Thanks…
-The Mighty Mike Master
http://tmmm.simplenet.comGreetings
Alberto J. Fernandez
afgarcia at gmv.es
–
Peter Hawkins
peterh at isa.net.au
Internet Solutions Australia (ACN 077 685 011)
Ph: 1300 369 990 - Fax: 02 6230 4455
To access the Pixmaps you can simply make a row-image in System-Mem
and copy it to the Server (so you dont need to get the Pixmap first)
Thats pretty bad for many single pixels, because of the Image - Overhead,
but for scrolling a line it would be quite nice, I think…
Or did I forget some important fact?
ManuelOn Tue, 08 Jun 1999, you wrote:
Here would be the new semantics:
If you want fast access to the video memory to do your own blitting, create
the video surface in software memory. SDL will take care of the blitting to
video memory.
If you want slow access to the video memory, and have most of your images
static and want them in video memory, create the video surface and map
surfaces with the (would-be new) flag SDL_HWCACHED. Accessing them would
be twice as slow as they are now, but blitting from one to the other should
be faster.
What do you think, everyone?I would really appreciate this functionality. It would make software scrolling
much faster. One could use two buffers; one active, the second inactive. Normal
screenupdates are blit to the active buffer and updated to the screen.Unfortunately, the blits to the active buffer will be twice as slow with
the above outlined mechanism.Here’s why:
If the surface is cached in the X server as a pixmap, then you
have to get the image from the server… unless you have X
shared memory pixmaps. Does anybody know if the server puts
X shared memory pixmaps in hardware memory? I doubt it, since
that would mean that the video memory is memory mapped into your
address space. I’ll ask on the XFree86 developer’s list.
Anyway, if you don’t have shared memory pixmaps, then to write
to the pixmap memory, you have to do a copy from the server,
local update, and then copy the contents to the server again.
Yet, when I use the SDL_GetVideoInfo() function, it reports that there is
NO HW acceleration whatsoever. I have an ATI Mach64 server running. Is it
not yet supported under SDL yet?
There is no hardware acceleration available under the X11 driver.
No hardware acceleration for Mach64 under Xfree? How can that be?
There’s a Mach64 server. Doesn’t that take advantage of Mach64
acceleration? Or were you referring to a different type of
acceleration?
Third, um, well, 640x480 software scrolling won’t be very fast on anything
slower than a P2/266 or equivalent.
I was under the impression that games like WarCraft 2, StarCraft, Total
Annihilation, SimCity, and others used software scrolling on screens as
large or larger than that… How is that possible if it’s not software
(And I’ve got some pretty crappy cards here that don’t have any
noticable acceleration on them). Or do you define "very fast"
differently than I do?
-KWOn 8 Jun, Sam Lantinga wrote:
Odd. One of my machines has an ATI Mach64 and I get DGA just fine
(Just got finished playing “alien” just to make sure).
-KWOn 8 Jun, Alberto Jose Fernandez Garcia wrote:
I have also an ATI Mach64 and it does not support DGA (Direct GraphicsAccess)
under Linux. I believe that is the reason because you do not obtain
hardware acceleration.
KW said:
I was under the impression that games like WarCraft 2, StarCraft, Total
Annihilation, SimCity, and others used software scrolling on screens as
large or larger than that… How is that possible if it’s not software
(And I’ve got some pretty crappy cards here that don’t have any
noticable acceleration on them). Or do you define "very fast"
differently than I do?
Not that I know anything about any of this, but he probably mean, like,
60fps full screen scrolling. Games like Craft and Sim don’t really
scroll very quickly, like your average jump-n-run (Super Mario) games.
-bill!
(I’ll be quiet now 
)
KW said:
I was under the impression that games like WarCraft 2, StarCraft, Total
Annihilation, SimCity, and others used software scrolling on screens as
large or larger than that… How is that possible if it’s not software
(And I’ve got some pretty crappy cards here that don’t have any
noticable acceleration on them). Or do you define "very fast"
differently than I do?
Not that I know anything about any of this, but he probably mean, like,
60fps full screen scrolling. Games like Craft and Sim don’t really
scroll very quickly, like your average jump-n-run (Super Mario) games.
Yup. I meant 30fps full screen scrolling, like Oddworld or Earthworm Jim.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec