Hi! I downloaded 0.6m and got my various little test programs up and
running under it, and I must say I love DGA. Full-screen just feels
so right to me (for games).
But there’s one problemo: it flickers. I added double buffering
myself to one of my programs (simply cloned the visual surface, drwe
everything to that one instead of the actual visible one, and then
blitted the entire thing). But doing it that way adds one full-screen
blit per frame, which obviously is sub-optimal for performance.
So, Sam, am I missing out on something here, or is this the way it
is, right now? I’ve heard that DGA supports efficient double
buffering (change of pointers only), but I don’t think SDL supports
that. Or does it?
/Emil
But there’s one problemo: it flickers. I added double buffering
myself to one of my programs (simply cloned the visual surface, drwe
everything to that one instead of the actual visible one, and then
blitted the entire thing). But doing it that way adds one full-screen
blit per frame, which obviously is sub-optimal for performance.
If you specify SDL_SWSURFACE instead of SDL_HWSURFACE when setting the
video mode, SDL will effectively do this for you, keeping the visible
surface in system memory and copying the portions that have changed
when you call SDL_UpdateRects().
So, Sam, am I missing out on something here, or is this the way it
is, right now? I’ve heard that DGA supports efficient double
buffering (change of pointers only), but I don’t think SDL supports
that. Or does it?
Not yet. Here’s the problem: If you are not doing full-screen updates,
then when you do hardware double buffering (flipping, really), you need
to write the changed pixels on both video surfaces, which is slower than
if you write them once to system memory and then do memcpy to video memory.
If you are doing full-screen updates, then it may be faster to write directly
to video memory, but even then, on some video cards it’s actually faster
to write to system memory and let the hardware accelerated blitter on the
video card perform a block DMA transfer to the display memory. This is
currently only possible under DirectX, but …
So anyway, I’ve been lazy about implementing page flipping because often
it’s still faster to write to system memory and copy the changed areas.
I’ll probably put it into SDL 0.8 if enough people want it.
If you specify SDL_SWSURFACE instead of SDL_HWSURFACE when setting the
video mode, SDL will effectively do this for you, keeping the visible
surface in system memory and copying the portions that have changed
when you call SDL_UpdateRects().
By the way, this doesn’t add an extra layer when used under X11.
SDL knows the display surface resides in shared memory and so always
sets the SDL_SWSURFACE flag on X11 surfaces.
[whining about flicker]
If you specify SDL_SWSURFACE instead of SDL_HWSURFACE when setting the
video mode, SDL will effectively do this for you, keeping the visible
surface in system memory and copying the portions that have changed
when you call SDL_UpdateRects().
Aha. I’ll do that then.
So, Sam, am I missing out on something here, or is this the way it
is, right now? I’ve heard that DGA supports efficient double
buffering (change of pointers only), but I don’t think SDL supports
that. Or does it?
Not yet. Here’s the problem: If you are not doing full-screen updates,
then when you do hardware double buffering (flipping, really), you need
to write the changed pixels on both video surfaces, which is slower than
if you write them once to system memory and then do memcpy to video memory.
Um? That is not my experience. Doing partial updates on flipped
buffers is very possible, and I’ve done it several times (both on the
Amiga in days of olde and under DirectX). Works like a charm,
typically after loads of time debugging background-store ordering and
other fun things. Writing on two surfaces seems to defeat the point
of double buffering. Am I missing something, again?
If you are doing full-screen updates, then it may be faster to write directly
to video memory, but even then, on some video cards it’s actually faster
to write to system memory and let the hardware accelerated blitter on the
video card perform a block DMA transfer to the display memory. This is
currently only possible under DirectX, but …
Is it possible to get it accelerated under X?
/EmilOn Wed, 1 Jul 1998, Sam Lantinga wrote:
buffers is very possible, and I’ve done it several times (both on the
Amiga in days of olde and under DirectX). Works like a charm,
typically after loads of time debugging background-store ordering and
other fun things. Writing on two surfaces seems to defeat the point
of double buffering. Am I missing something, again?
Right. Sorry. There are two different ways of doing it:
The smart way:
Only change the portions on each that need to be changed
Keep track of everything – background-store ordering, etc. etc.
The usual way:
For full-frame rendering apps:
Update each frame – flip
For partial frame rendering apps:
Copy the portions that changed to the back buffer
Flip
Copy the portions that changed to the new back buffer
I’d love to see a good implementation of the smart way, since I’ve never
done it myself.
Is it possible to get it accelerated under X?
Nope. Not now, anyway.
See ya!
-Sam Lantinga (slouken at devolution.com)
I’m having a couple of terminology issues as of late and I was
wondering if you could clarify things.
Say I want to use either SDL or BeOS native APIs.
I know on the Amiga there was hardware sprites available.
Conceptually, what is the difference between a BBitmap drawn to
a BView in a BWindow from merely a sprite?
Best Regards,
David Sowsy
I know on the Amiga there was hardware sprites available.
Conceptually, what is the difference between a BBitmap drawn to
a BView in a BWindow from merely a sprite?
I’m going to qualify this with the fact that I have no familiarity
with the Amiga.
That said, I understand that Amiga hardware sprites are RLE encoded
and stored for hardware blitting on the video board. Right?
A BBitmap is essentially the same thing as a Windows DIB section
or an X11 pixmap – just a bunch of pixels organized in scanlines.
As I understand it, the SDL RLE accelerated surface is closer to
an Amiga sprite, but uses a software state-machine blitter instead
of hardware.
Anyone with more information, feel free to jump in. 
Fair enough…but do you have familiarity with sprites?
Yes.
A BBitmap is essentially the same thing as a Windows DIB section
or an X11 pixmap – just a bunch of pixels organized in scanlines.
So is a view a more accurate portrayal of a sprite?
No, a BView is just a BBitmap with the trimmings necessary for it to
interact as a display surface within a window. A BBitmap I suppose is
closer to a sprite. – more of a square sprite, really.
The closest thing that you’ll get to a sprite under BeOS is something
from a library, like the colorkey’ed surface from the SDL library.
This of course, could change as more video hardware acceleration
becomes available. I’m going to lazily track these as they come.
I hope so, this could lead to an interesting discussion.
Yep.
Um? That is not my experience. Doing partial updates on flipped
buffers is very possible, and I’ve done it several times (both on the
Amiga in days of olde and under DirectX). Works like a charm,
typically after loads of time debugging background-store ordering and
other fun things. Writing on two surfaces seems to defeat the point
of double buffering. Am I missing something, again?
Yeah, I was going to reply to this earlier - I always thought the idea of
double buffering was to prevent tearing - The way many games that update
the lot work is by drawing into the one SW buffer, then copying that to
alternate HW screens, then toggling to make the image appear all at once.
Anything beyond a rectangular copy should be performed in system memory
unless there is specific hardware accelleration for the job.
njhOn Thu, 2 Jul 1998, Emil Brink wrote:
I know on the Amiga there was hardware sprites available.
Conceptually, what is the difference between a BBitmap drawn to
a BView in a BWindow from merely a sprite?
Sprites never actually touch the buffer. The hardware checks each pixel
to see if it is within the sprite’s image, and then draws it. Hence the
rules regarding sprites size, position, movement, overlap withs other
sprites and colours are very restrictive! The Amiga also has a blitter,
which programs(even BASIC!) used to provide slower(i.e. not updated every
refresh) but unrestricted spritelike things(which were called BOBs or
Blitter OBjects).
The BBitmap -> BView is just a (perhaps hardware) image move, and thus
could only be considered a BOB, not a sprite.
njhOn Thu, 2 Jul 1998, David Sowsy wrote:
As I understand it, the SDL RLE accelerated surface is closer to
an Amiga sprite, but uses a software state-machine blitter instead
of hardware.
No, I don’t believe there is any hardware RLE on the amiga - it certainly
had an offset for the top of the sprite, but the hardware just checked
each pixel and left one colour clear(hences sprites were only 3 colours -
but not always the same 3 colours as the other sprites).
njhOn Thu, 2 Jul 1998, Sam Lantinga wrote:
Fair enough…but do you have familiarity with sprites?
We could get Geert U. In to argue the finer points if you like…
That said, I understand that Amiga hardware sprites are RLE encoded
and stored for hardware blitting on the video board. Right?
In custom chips, yes.
Hmmm, I didn’t think they bothered - with hardware (and memory faster than
the chips, in those days) it was easier to just check every pixel. Then
the program could change the shape without having to recompute the whole
mask. Because of this approach other data could be stored into the pixels
and decoded before it hit the screen, so extra bitplanes could be used to
detect collisions.
A BBitmap is essentially the same thing as a Windows DIB section
or an X11 pixmap – just a bunch of pixels organized in scanlines.
So is a view a more accurate portrayal of a sprite?
No, in Amiga BASIC parlance, it is a better portrayal of BOBs. Things is
that the meaning of sprite has been watered down from years of IBM PC
hackers writing ‘sprite libraries’ which are entirely software based.
Anyone with more information, feel free to jump in.
I hope so, this could lead to an interesting discussion.
We could distribute instructions on how to build an SDL accellerator
board…
njhOn Thu, 2 Jul 1998, David Sowsy wrote:
We could distribute instructions on how to build an SDL accellerator
board…
laugh
BTW, Maelstrom is looking really nice.
We could distribute instructions on how to build an SDL accellerator
board…
laugh
BTW, Maelstrom is looking really nice.
goofey on sometime! how can we have a serious chat otherwise?!
njhOn Thu, 2 Jul 1998, Sam Lantinga wrote:
I’ll goofey on though… syntax?
“goofey” right? I don’t need to do anything else?
goofey gets you on, I’ll tell the rest once you’re on
njhOn Thu, 2 Jul 1998, Sam Lantinga wrote:
goofey on sometime! how can we have a serious chat otherwise?!
I’m behind a firewall at work, and I won’t be home until later tonight.
I’ll goofey on though… syntax?
“goofey” right? I don’t need to do anything else?
Ok, in case I’m not there(possible, but unlikely…) goofey -ru to read
unread messages, goofey -s to send to that person, goofey -x to log
out.
njhOn Thu, 2 Jul 1998, Sam Lantinga wrote: