Anyway around SDL_UpdateRect?

SDL Development
1

The speed problem is definetly in SDL_UpdateRects. My graphics card
doesn’t support SDL’s DoubleBuffer so I will have to add native double
buffer support back to powerpak, but that will be just as slow because I
will have to call update rects. I even tried a memcpy directly to
screen->pixels and still have to call SDL_UpdateRects. Isn’t there
anyway at all to directly access the screen and still have the features
of SDL.

The best you’ll be able to do is passing SDL_HWSURFACE to SDL_SetVideoMode().
On systems that support it (DirectX, X11/DGA) you’ll get direct access to
video memory. This is not a limitation of SDL, as much as a limitation of
the underlying driver capabilities.

I don’t know how to support multiple depths and alpha values and
stuff so it is not at all feasible for me to write it all over from
scratch.

If you need to convert from a pixel format you expect, you need to
draw to an internal buffer and convert that to the video format.
There’s no way around that. SDL provides this transparently, but
if you pass SDL_ANYFORMAT in the flags to SDL_SetVideoMode(), SDL
will not perform any conversions, it will give you the closest
depth supported by the underlying driver.

I realize that a dirty rectangles type situation would greatly
speed things up, but there are engines (tile based, voxel graphics, 3d
graphics) that have to update the entire screen everytime and being
stuck in a 27fps framerate with a 400mhz isn’t very good.

Unfortunately, until Linux has direct hardware acceleration, you’ll
have to live with it. 27 fps sounds a little slow, but you probably
won’t get more than 30-40 FPS on PentiumII 350 MHz class systems.

Doesn’t CivCTP use SDL? How come that is so fast on my computer (Yes, I
know you can’t reveal that Sam :)) Actually I guess I know the answer
Civ doesn’t need to update the whole screen until scrolling time comes
around. Still CivCTP’s isometric engine scrolls ten times faster than my
simple square tile based implementation. Dos Loki use a 'suped up’
version of SDL?

Nope, it uses stock SDL. If you look closely, you’ll see that the
framerate isn’t really that high, but it scrolls in large jumps.

There are all sorts of techniques to get around low framerate.

Does anybody have any examples of a doublebuffer implementation in SDL?

If I get a chance, I’ll whip up an example.

All I want to to have people stop insulting that which have have
practically dedicated the past 2 and half months of my live to.

I know the feeling. :slight_smile:

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

2

John Garrison wrote:

I really hate to be a pain and sound like I am complaining, but I have
had several people complain about PowerPak being slow and it is really
beginning to annoy me.

Did you advertise your product? don’t be surprised if you did.

When I created it I just wanted to help
beginners program games on an environment like I had a few years back
(Allegro for DOS) I had no idea that people would actually complain
about it, I mean if they don’t like my work that I am give away free and
spent all my valuable time on, why don’t they just write their own code?

Cuz they want something easy, but fast.

If they can’t write thier own code then they have no business
complaining that mine is slow.

Sure they can. They can bitch about it if they think it could be better,
lots of people complain about DirectX all the time.

The speed problem is definetly in SDL_UpdateRects.

Dirty rectangle updates suck man. Use a framebuffer.

My graphics card
doesn’t support SDL’s DoubleBuffer so I will have to add native double
buffer support back to powerpak, but that will be just as slow because I
will have to call update rects. I even tried a memcpy directly to
screen->pixels and still have to call SDL_UpdateRects. Isn’t there
anyway at all to directly access the screen and still have the features
of SDL.

Write everything to screen->pixels, use SDL_UpdateRect, USE A FRAMEBUFFER!
If you want the most speed possible, ultimate speed, you could write your
own blit routines.

I don’t know how to support multiple depths and alpha values and
stuff so it is not at all feasible for me to write it all over from
scratch.

Specialize in one bit depth. Such as I did with my graphix lib which is 16
bits only. That way it’s streamlined and optimized and you’ll get the max
speed.

I realize that a dirty rectangles type situation would greatly
speed things up, but there are engines (tile based, voxel graphics, 3d
graphics) that have to update the entire screen everytime and being
stuck in a 27fps framerate with a 400mhz isn’t very good.

Consider bit depth here dude. 8 bits goes fast. But 32 and 24 are perty
slow.

You can get more than 27 fps. What depth are you running your X server in?
What depth is your program running in? 32 bpp is some heavy shit, 8 is fast
but limited, that’s why I chose 16. Lots of games today are 16 bits too.
Conversion will slow you down a lot too.

Doesn’t CivCTP use SDL? How come that is so fast on my computer (Yes, I
know you can’t reveal that Sam :)) Actually I guess I know the answer
Civ doesn’t need to update the whole screen until scrolling time comes
around. Still CivCTP’s isometric engine scrolls ten times faster than my
simple square tile based implementation. Dos Loki use a 'suped up’
version of SDL?

Civ scrolls at a blocky rate ( I mean it scrolls in large amounts, not by 2
pixels at a time ) StarCraft is an example, it scrolls at about one tile per
frame of scroll, which is pretty jerky, but you don’t notice it.

Does anybody have any examples of a doublebuffer implementation in SDL?
All I want to to have people stop insulting that which have have
practically dedicated the past 2 and half months of my live to.

People will continue to insult if you boast an inferior product (I’ve never
used PowerPacker so I don’t know if it’s good or not), but they don’t need
to insult, they could be polite and use constructive criticism.

Thanks for any help,

Take my advice / talk with a grain of salt :slight_smile:

Paul Lowe
spazz at ulink.net

3

Paul Lowe wrote:

Did you advertise your product? don’t be surprised if you did.

Most of the news sites that list if found out about it on their own.
All I did was post some help wanted listings which if I am not mistaken
implies a slow/unfinished product.

Cuz they want something easy, but fast.

If they are incapable of writing something easy and fast then they have
no business complaining about my code quality. If they are no better
than me then who are they to insult.

Sure they can. They can bitch about it if they think it could be better,
lots of people complain about DirectX all the time.

Hmmmm, 100 billion dollar 10,000 employee company releasing slow
proprietery bloatware, one lone amatuer releasing fully open sourced if
you don’t like it quit complaining and fix it code.
Hmmmm, an API that is quite a few years old, an API that just hit it’s
two month anniversary a week ago.
Hmmmm, an API targeted specifically at commercial quality products and
developers, an API designed for the open source hobbyist.
I am having a really really hard time understanding how I am supposed to
be compared to DirectX. The bottom line is Microsoft has the
money/resources and damn sure at least pretends to have the knowledge to
create a better DirectX “technology” Give me a couple billion dollars
and I’ll see what I can do.
That is like saying that it is OK to complain that my old High School’s
varsity football team couldn’t win the SuperBowl because Bill’s fans
complained when they lost.

Dirty rectangle updates suck man. Use a framebuffer.

That is what I was asking how to do. I said is there anyway around
SDL_UpdateRects and SDL_Flip() / SDL_DOUBLEBUF does not work on my
computer. The answer to “How do I do this?” isn’t “do it”

Write everything to screen->pixels, use SDL_UpdateRect, USE A FRAMEBUFFER!
If you want the most speed possible, ultimate speed, you could write your
own blit routines.

I had it like that from the very begining. I switched it over to
SDL_Flip() because that would have been faster if my hardware supported
it. Please read this next line carefully, I am beginning to feel
redundant “SDL_UPDATERECT LOCKS ME AT 27FPS” It is the exact same speed
whether I draw a pixel or a huge rectangle. That is why I want a way
around SDL_UpdateRects.

As I also said I am using SDL because I don’t know exactly how to do all
of the nifty effects its has taken Sam all this time to be kind enough
to write for us. It wouldn’t make since for me to use my own blits.

Specialize in one bit depth. Such as I did with my graphix lib which is 16
bits only. That way it’s streamlined and optimized and you’ll get the max
speed.

I don’t like that idea I want the author of a program to be able to
choose which depth to use. The author should have the power of deciding
which sacrifices to make and which ones not to. This is just personal
opinion and no need to argue against me on this as you won’t change my
mind.

Consider bit depth here dude. 8 bits goes fast. But 32 and 24 are perty
slow.

You can get more than 27 fps. What depth are you running your X server in?
What depth is your program running in? 32 bpp is some heavy shit, 8 is fast
but limited, that’s why I chose 16. Lots of games today are 16 bits too.
Conversion will slow you down a lot too.

I am running in 16 bits. A simple loop with nothing but clearscreen and
updaterects yields 27fps. as I said before SDL_UPDATERECT LOCKS ME AT
27FPS

People will continue to insult if you boast an inferior product (I’ve never
used PowerPacker so I don’t know if it’s good or not), but they don’t need
to insult, they could be polite and use constructive criticism.

When the HELL did I “Boast” my product. I have said it was young, I
have said I wasn’t worried about speed just yet I have said it is slow!!
What am I supposed to do put a big ‘ole sign on it that says "THIS
F****IN’ SUCKS DON’T USE IT!!!"

Take my advice / talk with a grain of salt :slight_smile:

Look, I am really sorry if I seem hostile but as I said all I wanted to
do was help people. I am not a professional I don’t have endless capital
to sink into it and except for Karl and Sam nobody even seems willing to
hint at how to speed it up, and if they do they do as you did and say
things that I already know and in fact were asking about.
It just seems that it is such a simple concept to me. If you don’t like
my lib don’t use it or at least wait for it to get faster. It’s not
like I released it just to say “HaHa look at this slow lib I am forcing
on people” In fact I wasn’t going to release it at all until is was
much further into the project but you see that is the beauty of “Open
Source” that one person doesn’t have to do it all. If people want me to
do all the work and let them just reap the benefits then they just need
to get rid of Linux reinstall Winblows and pay for a commercial API.>

Paul Lowe
spazz at ulink.net

4

The best you’ll be able to do is passing SDL_HWSURFACE to SDL_SetVideoMode().
On systems that support it (DirectX, X11/DGA) you’ll get direct access to
video memory. This is not a limitation of SDL, as much as a limitation of
the underlying driver capabilities.

Yeah I have added that in as well but still seem to be locked at 27fps.
Maybe it is just a hardware problem, maybe I see if a new Mach64 Xserver
is out as well I am using 3.3.3.1-1.1 Maybe there have been some
improvements? I don’t know why an ATI Rage Pro wouldn’t support hardware
blitting :frowning:

If you need to convert from a pixel format you expect, you need to
draw to an internal buffer and convert that to the video format.
There’s no way around that. SDL provides this transparently, but
if you pass SDL_ANYFORMAT in the flags to SDL_SetVideoMode(), SDL
will not perform any conversions, it will give you the closest
depth supported by the underlying driver.

SDL provide much more transparently too, I could use hermes or something
for just the pixel format but I would have to add transparency and alpha
and all sorts of stuff that you have already done better than I could
ever do anyway :slight_smile: If I were to write my own it would probably end up
slower anyway.

I realize that a dirty rectangles type situation would greatly
speed things up, but there are engines (tile based, voxel graphics, 3d
graphics) that have to update the entire screen everytime and being
stuck in a 27fps framerate with a 400mhz isn’t very good.

Unfortunately, until Linux has direct hardware acceleration, you’ll
have to live with it. 27 fps sounds a little slow, but you probably
won’t get more than 30-40 FPS on PentiumII 350 MHz class systems.

Is this the same type of direct hardware acceleration that is coming in
the next X-server release?
Actually 27fps was just my example program that moves a little 10,20
rectangle across the screen. The tile engine gives 13fps but is not
optimized, just some code a guy sent me and needed help on, I could
probably get it up to close to 27fps and I know I could get it playable
as the map doesn’t constantly have to tile.

Nope, it uses stock SDL. If you look closely, you’ll see that the
framerate isn’t really that high, but it scrolls in large jumps.

Yeah, I realize that now I did a DOS tile engine and it moved one block
per frame so it appeared to be faster/smoother as well.

Does anybody have any examples of a doublebuffer implementation in SDL?

If I get a chance, I’ll whip up an example.

I had one but I had to use SDL_UpdateRects which locked me at that
27fps.

All I want to to have people stop insulting that which have have
practically dedicated the past 2 and half months of my live to.

I know the feeling. :slight_smile:

I am sorry if I have came across as complaining and am sorry for getting
a little hostile with other members of the group this time, but I just
had a $60,000 a year job oppurtunity fall through (I don’t know Cold
Fusion or Object Oriented Perl) and I really thought that the increased
visitors to my site would help me bolster my confidence back up a
little. They’ve done the opposite, and to be honest for quite a while
now I’ve been skipping right past sad to angry and tend to lash out when
maybe I shouldn’t.

Again sorry

John

5

I really hate to be a pain and sound like I am complaining, but I have
had several people complain about PowerPak being slow and it is really
beginning to annoy me. When I created it I just wanted to help
beginners program games on an environment like I had a few years back
(Allegro for DOS) I had no idea that people would actually complain
about it, I mean if they don’t like my work that I am give away free and
spent all my valuable time on, why don’t they just write their own code?
If they can’t write thier own code then they have no business
complaining that mine is slow.
The speed problem is definetly in SDL_UpdateRects. My graphics card
doesn’t support SDL’s DoubleBuffer so I will have to add native double
buffer support back to powerpak, but that will be just as slow because I
will have to call update rects. I even tried a memcpy directly to
screen->pixels and still have to call SDL_UpdateRects. Isn’t there
anyway at all to directly access the screen and still have the features
of SDL. I don’t know how to support multiple depths and alpha values and
stuff so it is not at all feasible for me to write it all over from
scratch. I realize that a dirty rectangles type situation would greatly
speed things up, but there are engines (tile based, voxel graphics, 3d
graphics) that have to update the entire screen everytime and being
stuck in a 27fps framerate with a 400mhz isn’t very good.
Doesn’t CivCTP use SDL? How come that is so fast on my computer (Yes, I
know you can’t reveal that Sam :)) Actually I guess I know the answer
Civ doesn’t need to update the whole screen until scrolling time comes
around. Still CivCTP’s isometric engine scrolls ten times faster than my
simple square tile based implementation. Dos Loki use a 'suped up’
version of SDL?

Does anybody have any examples of a doublebuffer implementation in SDL?
All I want to to have people stop insulting that which have have
practically dedicated the past 2 and half months of my live to.

Thanks for any help,

John

6

Is this the same type of direct hardware acceleration that is coming in
the next X-server release?

Yup, XFree86 4.0

Does anybody have any examples of a doublebuffer implementation in SDL?

If I get a chance, I’ll whip up an example.

I had one but I had to use SDL_UpdateRects which locked me at that
27fps.

You shouldn’t need to do both update rects and a flip.
The flip takes the place of a fullscreen update.
BTW, I got 40 FPS on your example program, using my Pentium 300.

Again sorry

Thanks, its nice that the SDL list is a usually welcoming forum.
I do completely understand your feeling. :slight_smile:

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

7

John Garrison wrote:

I had one but I had to use SDL_UpdateRects which locked me at that
27fps.

Hi,

I’ve been able to get up to 45 fps with you example2 program on my K6
300, with a 3Dfx Voodoo 3 2000 pci. I wish I could help speed it up,
but my skills are not up to par. My game has been running pretty
smooth, using you library, so I’ve had no complaints. Just keep up the
good work.

Mike

8

You shouldn’t need to do both update rects and a flip.
The flip takes the place of a fullscreen update.
BTW, I got 40 FPS on your example program, using my Pentium 300.

See, I don’t really understand for the most part why people complain
about speed. I mean the ex2 demos could be alot faster with selective
updating but I’ve always thought that that kind of thing was up to the
libs users, well I guess I was wrong so as I said before now my sprite
routines will use selective updating. (also ex2.c only moves on pixel
per frame so It might look slow)

9

OK, the code I just implemented into the sprite routines for dirty
rectangle type support has been a DRAMATIC improvement. As you may know
the ex2 demo draws a rectangle on the screen and does a complete screen
clear/redraw to move the rectangle across the screen. It does this a
27fps on my computer.
Well my sprite structure has enough info that with a little added I
could implement transparent (to users) dirty rectangles. instead of
using the showdoublebuffer routine they wrap thier sprite displays in
between PD_SpriteBegin and PD_SpriteEnd lines. a new example program
with a sprite the same size as the rectangle in ex2 (10,20) went over
640fps on my computer.
Ya’ll probably don’t really care about this and it will be more on topic
on my mailing list, but since you have been so kind as to listen to me
complain I thought I would share.
Maybe now, finally all the people to lazy to actually optimize thier own
PowerPak game code will stop complaining :slight_smile:

Oh by the way, SDL doesn’t support console mode does it? When the Linux
Game Tome picked up PowerPak they said it supported console mode and
sound, it doesn’t support either, but when I submit the new update I
guess I’ll have them fix it.

10

OK, the code I just implemented into the sprite routines for dirty
rectangle type support has been a DRAMATIC improvement. As you may know
the ex2 demo draws a rectangle on the screen and does a complete screen
clear/redraw to move the rectangle across the screen. It does this a
27fps on my computer.
Well my sprite structure has enough info that with a little added I
could implement transparent (to users) dirty rectangles. instead of
using the showdoublebuffer routine they wrap thier sprite displays in
between PD_SpriteBegin and PD_SpriteEnd lines. a new example program
with a sprite the same size as the rectangle in ex2 (10,20) went over
640fps on my computer.
Ya’ll probably don’t really care about this and it will be more on topic
on my mailing list, but since you have been so kind as to listen to me
complain I thought I would share.
Maybe now, finally all the people to lazy to actually optimize thier own
PowerPak game code will stop complaining :slight_smile:

I’m glad you’ve solved that headache. :slight_smile:

Oh by the way, SDL doesn’t support console mode does it? When the Linux
Game Tome picked up PowerPak they said it supported console mode and
sound, it doesn’t support either, but when I submit the new update I
guess I’ll have them fix it.

SDL has alpha support for SVGAlib, and I’m working on fbcon.
To enable SVGAlib support, you have to edit the bottom of make/linux/functions

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec