Hello,
For our game (globulation 2), we have a multiple backend system that allow to
switch between plain SDL and GL. We are thinking about dropping the GL in
favour of glSDL (especially if integrated into SDL), but there is one problem
: GL supports lines directly, but SDL does not, so switching to glSDL won’t
improve line speed as our multiple backend do. Does someone plans to solve
this issue ? Because lines can be really usefull, even in today’s games.
Thanks,
Stephane
This is a good point, /however/, I am going to note that if you are
currently using GL_LINES you very likely ending up on software fallbacks
in most OpenGL drivers.
I suspect that you’ll find that a GL_QUAD with a width of 1 or so will
be much faster for you, and will very likely look the same.
(Nobody uses GL_LINES, so at least nVidia does not accelerate it,
software fallbacks suck speed wise.)On Sun, Oct 05, 2003 at 10:34:25AM +0200, Stephane Magnenat wrote:
Hello,
For our game (globulation 2), we have a multiple backend system that allow to
switch between plain SDL and GL. We are thinking about dropping the GL in
favour of glSDL (especially if integrated into SDL), but there is one problem
: GL supports lines directly, but SDL does not, so switching to glSDL won’t
improve line speed as our multiple backend do. Does someone plans to solve
this issue ? Because lines can be really usefull, even in today’s games.
–
1024D/E65A7801 Zephaniah E. Hull <@Zephaniah_E_Hull>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
Hey, if you’ve mlock’ed more than your available memory, there’s nothing
the VM layer can do. Except maybe a nice printk(“Kiss your *ss goodbye”);
– Linus
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20031007/4eaba08d/attachment.pgp
I’ve recently written a very simple program that just draws lines. I
have a version of it that uses my own software lines in a software
surface, my own software lines in a hardware surface, and I have a
version that uses GL_LINES in an OpenGL surface. I have only tested it
on NVidia cards because that is all I have. I can tell you the OpenGL
lines are many times faster than software drawn lines drawn into any
other kind of SDL surface. So, yes, they may be slow compared to quads,
but they are still much faster than you can get in software on the CPU.
In other words his point is valid. If you want to draw lines you should
use an OpenGL surface and not use glSDL. AFAIK glSDL is wonderful for
blitter dominant applications, but not what you want to use for geometry
dominant applications.
OTOH, it should be pretty straight forward to use OpenGL commands inside
a glSDL program. After all, the context is already there and
initialized. Proper use of context pushes and pops should allow you to
insert OpenGL commands without any serious problems. 
Bob PendletonOn Sun, 2003-10-05 at 17:55, Zephaniah E. Hull wrote:
On Sun, Oct 05, 2003 at 10:34:25AM +0200, Stephane Magnenat wrote:
Hello,
For our game (globulation 2), we have a multiple backend system that allow to
switch between plain SDL and GL. We are thinking about dropping the GL in
favour of glSDL (especially if integrated into SDL), but there is one problem
: GL supports lines directly, but SDL does not, so switching to glSDL won’t
improve line speed as our multiple backend do. Does someone plans to solve
this issue ? Because lines can be really usefull, even in today’s games.This is a good point, /however/, I am going to note that if you are
currently using GL_LINES you very likely ending up on software fallbacks
in most OpenGL drivers.I suspect that you’ll find that a GL_QUAD with a width of 1 or so will
be much faster for you, and will very likely look the same.(Nobody uses GL_LINES, so at least nVidia does not accelerate it,
software fallbacks suck speed wise.)
–
±----------------------------------+
Zephaniah E. Hull wrote:>On Sun, Oct 05, 2003 at 10:34:25AM +0200, Stephane Magnenat wrote:
Hello,
For our game (globulation 2), we have a multiple backend system that allow to
switch between plain SDL and GL. We are thinking about dropping the GL in
favour of glSDL (especially if integrated into SDL), but there is one problem
: GL supports lines directly, but SDL does not, so switching to glSDL won’t
improve line speed as our multiple backend do. Does someone plans to solve
this issue ? Because lines can be really usefull, even in today’s games.This is a good point, /however/, I am going to note that if you are
currently using GL_LINES you very likely ending up on software fallbacks
in most OpenGL drivers.I suspect that you’ll find that a GL_QUAD with a width of 1 or so will
be much faster for you, and will very likely look the same.(Nobody uses GL_LINES, so at least nVidia does not accelerate it,
software fallbacks suck speed wise.)
GL_LINES are hardware accelerated at least on every Nvidia card starting
with the geforce (and GL_LINES are especially fast on high end OpenGL
hardware). It was already the case with TNT2, IIRC, but I can’t say for
sure.
About the original problem, there might be some solutions :
Software line rendering will kill glSDL performance anyway, so it should
be avoided at all costs.
Stephane
[…]
GL_LINES are hardware accelerated at least on every Nvidia card
starting with the geforce (and GL_LINES are especially fast on high
end OpenGL hardware).
Yep - only unless I’m remembering wrong, you had to mess with the
registry or otherwise enable the feature, because the early
"consumer" drivers would use the s/w fallback by default.
I guess that was some sort of trick to get serious users to buy Quadro
cards instead, but soon, Google would come up with a couple of
suggestions for anyone wondering where the advanced features went.
It was already the case with TNT2, IIRC, but
I can’t say for sure.
I have no idea about those cards, but I would suspect you have to use
one of the later drivers that always use all available h/w features.
About the original problem, there might be some solutions :
- use thin rectangles for horizontal/vertical lines, that way
you’ll get hardware acceleration if available- add an SDL interface for drawing lines with an accelerated
capability flag
That might be interesting for 1.3 maybe - but I have a few questions:
1. How many other targets (beyond OpenGL and Direct3D)
can accelerate lines?
2. How about antialiazed lines, width control,
gradients and stuff? How far would we take it?
(No problem with glSDL or some future "D3DSDL",
but can any other target accelerate that?)
Software line rendering will kill glSDL performance anyway, so it
should be avoided at all costs.
Yep… (Requires locking of the display surface, which means full
screen copying back and forth. Not much we can do about that, AFAIK.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 07 October 2003 23.59, Stephane Marchesin wrote:
David Olofson wrote:
That might be interesting for 1.3 maybe - but I have a few questions:
- How many other targets (beyond OpenGL and Direct3D)
can accelerate lines?
DirectFB
David Olofson wrote:
It was already the case with TNT2, IIRC, but
I can’t say for sure.I have no idea about those cards, but I would suspect you have to use
one of the later drivers that always use all available h/w features.
I just checked, and GL_LINES are accelerated on my TNT2.
That might be interesting for 1.3 maybe - but I have a few questions:
- How many other targets (beyond OpenGL and Direct3D)
can accelerate lines?
Many targets can accelerate lines. For example, X & windows both have
support for drawing lines (although not always hardware accelerated).
At the hardware level, many cards can do hardware lines. Even my old S3
trio64 can, which means there’s good hope on the hardware side.
- How about antialiazed lines, width control,
gradients and stuff? How far would we take it?
(No problem with glSDL or some future “D3DSDL”,
but can any other target accelerate that?)
I think antialiazed lines are harder to support because they require
alpha blending support to be correctly rendered and/or emulated.
Gradient lines have, as far as I know, no hardware support except with
3D cards. So I suppose we’re out of lock ouside the 3D acceleration
world on those two points.
Stephane
OpenGL AA’d lines are well-supported, but not universally, and often
there’s no way of knowing when turning on line smoothing will get you
slow, unaccelerated rendering. (We use AA lines in StepMania, and we
have a small, hand-maintained video card database.)
D3D doesn’t support lines well; if I remember correctly, no AA and only
width 1.
There’s also the issue of overdraw with AA lines; if a line is drawn
many times per frame, then it won’t look right. (This is only an issue
when trying to turn on AA without the application being designed for it.)On Wed, Oct 08, 2003 at 05:59:36PM +0200, Stephane Marchesin wrote:
- How about antialiazed lines, width control,
gradients and stuff? How far would we take it?
(No problem with glSDL or some future “D3DSDL”,
but can any other target accelerate that?)I think antialiazed lines are harder to support because they require
alpha blending support to be correctly rendered and/or emulated.
Gradient lines have, as far as I know, no hardware support except with
3D cards. So I suppose we’re out of lock ouside the 3D acceleration
world on those two points.
–
Glenn Maynard