I?m programming on a client for altima (http://www.altima.org) using
SDL.
However I feel under X11, sdl is pretty slow:
Using SDL-0.9.9 (12/10/98)…
every object is in DisplayFormat converted by
SDL_DisplayFormat() earlier , for the screen i don?t get neither
HW_SURFACE
nor SDL_DOUBLEBUF:
here are the speeds I get on a P2 233 using SDL_BlitSurface
blitting surfaces to memory: 12500 blits / s (most at 70x36 pixels)
results in********************************************
blitting surfaces to memory 31,5MPixels / s
however blitting the memory-surface to “screen” takes 8ms and finally
update the
screen takes 32ms. thus:
blitting surface to screen: 25 blits / s (at 800x450 pixels) …
results in
blitting surfaces to screen (+updating) 9Mpixels / s
access to the screen seems to me too slow.
Do I handle sth. wrong ?
Karsten.
–
Karsten-O. Laux mailto:klaux at student.uni-kl.de
University of Kaiserslautern
Germany
I?m programming on a client for altima (http://www.altima.org) using
SDL.
However I feel under X11, sdl is pretty slow:
It’s relatively slow, but no slower than using X11 directly.
640x480 full-screen refresh at 30 FPS requires a P2/266 or similar system
with a good video card.
SDL will support MGL 4.1 or 5.0 when it’s released, for accelerated
full-screen display under Linux, a la SVGAlib or GGI. (MGL will be
free and much more robust than GGI or SVGAlib)
I’ll give you some tips here in a second…
Using SDL-0.9.9 (12/10/98)…
every object is in DisplayFormat converted by
SDL_DisplayFormat() earlier , for the screen i don?t get neither
HW_SURFACE nor SDL_DOUBLEBUF:
That’s because in a window you can’t touch the hardware memory.
If you are running fullscreen using DGA, you can get both hardware
memory and double-buffering. See the testsprite example in SDL 0.9.x
for an example of this.
here are the speeds I get on a P2 233 using SDL_BlitSurface
blitting surfaces to memory 31,5MPixels / s
That’s pretty good.
however blitting the memory-surface to “screen” takes 8ms and finally
update the screen takes 32ms.
You shouldn’t need to blit to a memory surface and then the screen,
you should be able to blit directly to display surface. If SDL_HWSURFACE
isn’t in the display flags, then your blit won’t be displayed until you
call SDL_UpdateRects().
Do I handle sth. wrong ?
Make sure you pass ‘0’ as the bits-per-pixel to SDL_SetVideoMode(),
otherwise SDL will convert from the requested bpp to the actual bpp.
That may be why the final update is taking so long.
…
SDL will support MGL 4.1 or 5.0 when it’s released, for accelerated
full-screen display under Linux, a la SVGAlib or GGI. (MGL will be
free and much more robust than GGI or SVGAlib)
is there a webpage for MGL ?
…
however blitting the memory-surface to “screen” takes 8ms and finally
update the screen takes 32ms.
You shouldn’t need to blit to a memory surface and then the screen,
you should be able to blit directly to display surface. If SDL_HWSURFACE
isn’t in the display flags, then your blit won’t be displayed until you
call SDL_UpdateRects().
however as I blit more than 300 objects it is faster to blit them first
to a
membuffer, before blitting the whole thing to the screen, since PCI is
slower than SDRAM…
another question: how?s about the ggi-implementation of SDL. can I get
faster blitting ? “real” direct videomem-access ? can I use it
transparently or are some features of the x11-implementation missing ?
Karsten.–
Karsten-O. Laux mailto:klaux at student.uni-kl.de
University of Kaiserslautern
Germany
however as I blit more than 300 objects it is faster to blit them first
to a
membuffer, before blitting the whole thing to the screen, since PCI is
slower than SDRAM…
If the SDL_HWSURFACE flag isn’t set, you are blitting to a memory buffer,
and then SDL_UpdateRects() actually copies it to VRAM. If SDL_HWSURFACE
were set in the surface flags (and it will never be set unless you request
it when setting a video mode) then you will be writing directly to video
memory.
another question: how?s about the ggi-implementation of SDL. can I get
faster blitting ? “real” direct videomem-access ? can I use it
transparently or are some features of the x11-implementation missing ?
The GGI implementation of SDL doesn’t work right now. I’m holding out
for a more mature API. When either GGI or fbcon or MGL is supported,
yes you’ll be able to use it transparently.
…
SDL will support MGL 4.1 or 5.0 when it’s released, for accelerated
full-screen display under Linux, a la SVGAlib or GGI. (MGL will be
free and much more robust than GGI or SVGAlib)
is there a webpage for MGL ?
…
however blitting the memory-surface to “screen” takes 8ms and finally
update the screen takes 32ms.
You shouldn’t need to blit to a memory surface and then the screen,
you should be able to blit directly to display surface. If SDL_HWSURFACE
isn’t in the display flags, then your blit won’t be displayed until you
call SDL_UpdateRects().
however as I blit more than 300 objects it is faster to blit them first
to a
membuffer, before blitting the whole thing to the screen, since PCI is
slower than SDRAM…
another question: how?s about the ggi-implementation of SDL. can I get
faster blitting ? “real” direct videomem-access ? can I use it
transparently or are some features of the x11-implementation missing ?
GGI doesn’t have support for most video cards, though… not really
practical right now.On Mon, 14 Dec 1998, Karsten Laux wrote:
Scott M. Stone <sstone at pht.com, sstone at pht.co.jp>
Head of TurboLinux Development/Systems Administrator
Pacific HiTech, Inc (USA) / Pacific HiTech, KK (Japan)
Scott Stone wrote:> On Mon, 14 Dec 1998, Karsten Laux wrote:
Sam Lantinga wrote:
…
SDL will support MGL 4.1 or 5.0 when it’s released, for accelerated
full-screen display under Linux, a la SVGAlib or GGI. (MGL will be
free and much more robust than GGI or SVGAlib)
is there a webpage for MGL ?
…
however blitting the memory-surface to “screen” takes 8ms and finally
update the screen takes 32ms.
You shouldn’t need to blit to a memory surface and then the screen,
you should be able to blit directly to display surface. If SDL_HWSURFACE
isn’t in the display flags, then your blit won’t be displayed until you
call SDL_UpdateRects().
however as I blit more than 300 objects it is faster to blit them first
to a
membuffer, before blitting the whole thing to the screen, since PCI is
slower than SDRAM…
another question: how?s about the ggi-implementation of SDL. can I get
faster blitting ? “real” direct videomem-access ? can I use it
transparently or are some features of the x11-implementation missing ?
GGI doesn’t have support for most video cards, though… not really
practical right now.
Umm… you’re thinking of KGI, which is only one part of GGI. LibGGI is a
general graphics library which lets you interface to any number of backends,
such as KGI, svgalib, fbcon, X11, X11DGA, glide, aalib, network display, memory,
file. If the SDL supported libggi, it would get support for all of the above for
free.
Umm… you’re thinking of KGI, which is only one part of GGI. LibGGI is a
general graphics library which lets you interface to any number of backends,
such as KGI, svgalib, fbcon, X11, X11DGA, glide, aalib, network display, memory,
file. If the SDL supported libggi, it would get support for all of the above for
free.
At the cost of an extra layer of API, and a library very much in flux.
SDL natively supports:
Win32 DIB
Win32 DirectX
Linux X11 (network and local display)
Linux X11DGA
BeOS BWindow
The main thing missing is fbcon support, which I’m just waiting for a stable
kernel release (2.2) to dig into.
Comments are welcome.
Umm… you’re thinking of KGI, which is only one part of GGI. LibGGI is a
general graphics library which lets you interface to any number of backends,
such as KGI, svgalib, fbcon, X11, X11DGA, glide, aalib, network display, memory,
file. If the SDL supported libggi, it would get support for all of the above for
free.
I seriously considered supporting GGI as a back-end, but I probably won’t
immediately because MGL looks like it’s going to be MUCH better.
Umm… you’re thinking of KGI, which is only one part of GGI. LibGGI is a
general graphics library which lets you interface to any number of backends,
such as KGI, svgalib, fbcon, X11, X11DGA, glide, aalib, network display, memory,
file. If the SDL supported libggi, it would get support for all of the above for
free.
At the cost of an extra layer of API, and a library very much in flux.
I think the library has stabilised again (the development version). You could ask the
ggi mailing list, see whether they think the api is stable now…
The stable tree API, has of course, been stable for some time
The extra layer doesn’t really matter that much. For the extra targets you get for
free the slowdown wouldn’t be too large a tradeoff. libggi isn’t too thick an API
layer either…
SDL natively supports:
Win32 DIB
Win32 DirectX
Linux X11 (network and local display)
Linux X11DGA
BeOS BWindow
The main thing missing is fbcon support, which I’m just waiting for a stable
kernel release (2.2) to dig into.
Not to mention svgalib and glide. Cmon! Where’s the aalib! I wanna play doom on a
text terminal! It’d be really cool if you did libggi support, cos then I could…
(in fact you already can via ggi-doom, but that’s not the point…).
I think the library has stabilised again (the development version). You could ask the
ggi mailing list, see whether they think the api is stable now…
I’ll take a look over the next few months.
The stable tree API, has of course, been stable for some time
But very limited in capability.
Not to mention svgalib and glide.
Glide? That’s intriguing. What kind of Glide support does it have?
Go ahead and move this to private e-mail.
Cmon! Where’s the aalib! I wanna play doom on a
text terminal! It’d be really cool if you did libggi support, cos then I could…
(in fact you already can via ggi-doom, but that’s not the point…).
Have you actually done it? It looks like crap^H^H^H^Hstuff.
Umm… you’re thinking of KGI, which is only one part of GGI. LibGGI is a
general graphics library which lets you interface to any number of backends,
such as KGI, svgalib, fbcon, X11, X11DGA, glide, aalib, network display, memory,
file. If the SDL supported libggi, it would get support for all of the above for
free.
I seriously considered supporting GGI as a back-end, but I probably won’t
immediately because MGL looks like it’s going to be MUCH better. http://www.scitechsoft.com/
Is it just me or will MGL cost money? If it it’s not LGPLed or similar, then there
isn’t a hope in hell that it will become popular in linux. I certainly wouldn’t pay
for a graphics toolkit which provides similar functionality to that already provided
by GGI and, for want of something better, Xfree86.
Umm… you’re thinking of KGI, which is only one part of GGI. LibGGI is a
general graphics library which lets you interface to any number of backends,
such as KGI, svgalib, fbcon, X11, X11DGA, glide, aalib, network display, memory,
file. If the SDL supported libggi, it would get support for all of the above for
free.
I seriously considered supporting GGI as a back-end, but I probably won’t
immediately because MGL looks like it’s going to be MUCH better. http://www.scitechsoft.com/
looking at the page, I see no mention of Linux WRT MGL. Where is it?On Mon, 14 Dec 1998, Sam Lantinga wrote:
Scott M. Stone <sstone at pht.com, sstone at pht.co.jp>
Head of TurboLinux Development/Systems Administrator
Pacific HiTech, Inc (USA) / Pacific HiTech, KK (Japan)
Is it just me or will MGL cost money? If it it’s not LGPLed or similar, then there
isn’t a hope in hell that it will become popular in linux. I certainly wouldn’t pay
for a graphics toolkit which provides similar functionality to that already provided
by GGI and, for want of something better, Xfree86.
I was concerned about this as well. MGL will have a free license, based on
the Netscape public license. As such, it can be installed and used freely
on all Linux systems. I spoke with Kendall Bennett about this, so no worries.
If the SDL_HWSURFACE flag isn’t set, you are blitting to a memory buffer,
and then SDL_UpdateRects() actually copies it to VRAM. If SDL_HWSURFACE
were set in the surface flags (and it will never be set unless you request
it when setting a video mode) then you will be writing directly to video
memory.
Is this true, even in a windowed mode? If so, does this work on remote X
displays?On Mon, Dec 14, 1998 at 03:53:30PM -0800, Sam Lantinga wrote:
If the SDL_HWSURFACE flag isn’t set, you are blitting to a memory buffer,
and then SDL_UpdateRects() actually copies it to VRAM. If SDL_HWSURFACE
were set in the surface flags (and it will never be set unless you request
it when setting a video mode) then you will be writing directly to video
memory.
Is this true, even in a windowed mode? If so, does this work on remote X
displays?
if the flag is set in the returned surface, yes.
It will never be set in windowed mode.
I think the library has stabilised again (the development version). You could ask the
ggi mailing list, see whether they think the api is stable now…
I’ll take a look over the next few months.
The stable tree API, has of course, been stable for some time
But very limited in capability.
Not to mention svgalib and glide.
Glide? That’s intriguing. What kind of Glide support does it have?
Reportedly the glide support is just to render a 2d image on a glide polygon. But it means
you can run X, etc. using your 3dfx card as a 2d display. This could be helpful if your 2d
card lacks any sort of decent support, or if it’s just a crap 2d card.
One of the crazy ideas I think the 3dfx guy in the libggi crew was having was to have each
virtual console as a seperate side of a six-sided cube, and when you switch consoles, the
cube rotates… He even had a demo of it.
I don’t have a 3dfx card, so I can’t confirm any of this. This is just what i’ve heard.
Go ahead and move this to private e-mail.
Cmon! Where’s the aalib! I wanna play doom on a
text terminal! It’d be really cool if you did libggi support, cos then I could…
(in fact you already can via ggi-doom, but that’s not the point…).
Have you actually done it? It looks like crap^H^H^H^Hstuff.
No, but I’ve seen screenshots of quake2 using aalib thus:
quake 2-> libggi svgalib wrapper -> libggi -> aalib
It’s a nice idea People also claim to have run X, etc. on a text console in this
way…
It’d be really cool if libggi support was in, cos then the SDL would have an
implementation of whatever whacky backends the ggi guys dream up.
Cmon! Where’s the aalib! I wanna play doom on a
text terminal! It’d be really cool if you did libggi support, cos then I could…
(in fact you already can via ggi-doom, but that’s not the point…).
Have you actually done it? It looks like crap^H^H^H^Hstuff.
I have played doom on a text console (well, the game was called ‘dumb’, but it
can load doom wad files), and it is great! aalib rocks, and provides a good
API, which is not unlike the SDL API.On Mon, Dec 14, 1998 at 06:06:13PM -0800, Sam Lantinga wrote:
Is this true, even in a windowed mode? If so, does this work on remote X
displays?
if the flag is set in the returned surface, yes.
It will never be set in windowed mode.
Hmm… this could get tricky… I’ll explain the problem:
I’m hacking the SDL driver for vMac, so I’ll be effectively blitting the
contents of the video RAM to the SDL_Surface. Running SDL_UpdateRects() is a
real kludge there, as then you’re effectively blitting it to the screen twice
(once by the emulated Mac, and once by SDL)
How can I gracefully handle this situation?On Mon, Dec 14, 1998 at 06:26:03PM -0800, Sam Lantinga wrote:
One of the crazy ideas I think the 3dfx guy in the libggi crew was having was to have each
virtual console as a seperate side of a six-sided cube, and when you switch consoles, the
cube rotates… He even had a demo of it.
Wow, that’s pretty cool.
It’d be really cool if libggi support was in, cos then the SDL would have an
implementation of whatever whacky backends the ggi guys dream up.
Not a bad idea. I’ll consider it, especially if the GGI development source
has stabilized.
Even if it hasn’t too seriously stabilised, if you get something that works with the current
snapshot, I’ll keep it up to date for you… ?
