If I specify the bit depth using SDL_GL_GREEN_SIZE, etc…, do I have to use
SDL_GL_BUFFERSIZE and viceversa?–
Marco Iannaccone @Marco_Iannaccone
ICQ: 18748121 MetalCoder
"What is real? How do you define real? If you’re talking about your
senses, what you feel, taste, smell, or see, then all you’re talking about
are electrical signals interpreted by your brain."
Morpheus - The Matrix
I would recommend never setting BUFFERSIZE, and just setting the component
color sizes.
m.> ----- Original Message -----
From: marciann@tin.it (Marco Iannaccone)
To:
Sent: Tuesday, February 13, 2001 10:56 AM
Subject: [SDL] SDL_GL_SetAttribute()If I specify the bit depth using SDL_GL_GREEN_SIZE, etc…, do I have to
use
SDL_GL_BUFFERSIZE and viceversa?
Of Michael Vance
I would recommend never setting BUFFERSIZE, and just setting the component
color sizes.
Why?
From: owner-sdl at lokigames.com [mailto:owner-sdl at lokigames.com]On Behalf
Sent: Tuesday, February 13, 2001 2:23 PM
To: sdl at lokigames.com
Subject: Re: [SDL] SDL_GL_SetAttribute()
I would recommend never setting BUFFERSIZE, and just setting the
componentcolor sizes.
Why?
Is just setting BUFFERSIZE a faster and less precise way of setting the
pixel format, isn’t it?–
Marco Iannaccone @Marco_Iannaccone
ICQ: 18748121 MetalCoder
"What is real? How do you define real? If you’re talking about your
senses, what you feel, taste, smell, or see, then all you’re talking about
are electrical signals interpreted by your brain."
Morpheus - The Matrix
I would recommend never setting BUFFERSIZE, and just setting the
componentcolor sizes.
Why?
Because there’s no sense twiddling bits that don’t need to be.
m.
Why?
Because there’s no sense twiddling bits that don’t need to be.
Right, that’s why I usually set BUFFERSIZE to either 15 or 24 and don’t
bother with the bit twiddling for component color sizes 
I guess it pretty
much is personal preference.
As a side note. Don’t request a 32 bit color buffer size. As the values are
minimal values there is no harm requesting 24. And especially when
requesting depth for the Z buffer. NVIDIA cards have a 24 bit Z buffer at
most. Some cards out there support a 32 bit Z buffer IIRC so you don’t want
to overshoot.
Because there’s no sense twiddling bits that don’t need to be.
Right, that’s why I usually set BUFFERSIZE to either 15 or 24 and don’t
bother with the bit twiddling for component color sizes
pretty
much is personal preference.
I was wondering if 32-bit surfaces (and routines that used 32 bits) would be
faster than using, say, 15/16-bit surfaces, since with a 32-bit surface,
pixels are aligned and you don’t need to do any shifting to create a pixel.
However, with 16 bits, that half the memory and hence half the memory writes
so that might be faster than the “flat” 32-bit, especially since most people
are running at 16-bit, so there would be no need to convert the surface as
it is blitted?
Olivier A. Dagenais - Software Architect and Developer
Well, if you’re using software rendering, that might be the case, at least
when doing blending effects (as they require operations on pixels), but any
decent GPU is already using 64 bits or more, and doesn’t care much about
alignment anyway, as it’s designed solely for pumping pixels; not for generic
processing.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Wednesday 14 February 2001 05:49, Olivier Dagenais wrote:
Because there’s no sense twiddling bits that don’t need to be.
Right, that’s why I usually set BUFFERSIZE to either 15 or 24 and don’t
bother with the bit twiddling for component color sizespretty
much is personal preference.
I was wondering if 32-bit surfaces (and routines that used 32 bits) would
be faster than using, say, 15/16-bit surfaces, since with a 32-bit surface,
pixels are aligned and you don’t need to do any shifting to create a pixel.
However, with 16 bits, that half the memory and hence half the memory
writes so that might be faster than the “flat” 32-bit, especially since
most people are running at 16-bit, so there would be no need to convert the
surface as it is blitted?
Well, if you’re using software rendering, that might be the case, at least
when doing blending effects (as they require operations on pixels), but any
decent GPU is already using 64 bits or more, and doesn’t care much about
alignment anyway, as it’s designed solely for pumping pixels; not for generic
processing.
FYI, there are a lot of high end graphics cards that still have to worry
about alignment for lots of things.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I should have clarified, I was talking about 2D on the current generation
of graphics cards. For 3D, they often have subpixel precision.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I was wondering if 32-bit surfaces (and routines that used 32 bits)
wouldbe faster than using, say, 15/16-bit surfaces, since with a 32-bit
surface,pixels are aligned and you don’t need to do any shifting to create a
pixel.However, with 16 bits, that half the memory and hence half the memory
writes so that might be faster than the “flat” 32-bit, especially since
most people are running at 16-bit, so there would be no need to convert
thesurface as it is blitted?
Well, if you’re using software rendering, that might be the case, at least
when doing blending effects (as they require operations on pixels), but
any
decent GPU is already using 64 bits or more, and doesn’t care much about
alignment anyway, as it’s designed solely for pumping pixels; not for
generic
processing.
“that might be the case”… what? That 32-bit is faster or 16-bit is
faster?
Olivier A. Dagenais - Software Architect and Developer
Yeah, I was thinking about 3D…
However, what about textures and alignment? As soon as you rotate a source in relation to the destination, you get non sequential memory access somewhere. (Usually in the source data I guess, as the usual method is doing scan conversion and then rendering horizontal lines.)If the texture RAM is 64 bits or wider, you don’t hit “in between” memory
words (ie have to read two words to get one pixel) too often with 24 bits,
but 32 bits would eliminate the problem. Sure, 24 bits would mean lower
bandwidth when doing sequential access - but that’s not the general case in
3D.
Conclusion: For 3D acceleration, evenly aligned texel sizes should be
used at all times.
Note: One wouldn’t see this from the outside, except when dealing with
procedural textures, real time texture caching systems and similar
stuff - OpenGL drivers convert to internal formats as required.)
Is this what most cards and drivers do?
(Just in case someone happens to know the facts for some real cards. 
As to more practical matters; does anyone have some ideas about how to
reliably set up SDL_Surfaces with the same hardware format as the 3D card is
using internally for textures?
I don’t want the OpenGL driver to silently and transparently convert
everything when uploading, as I need the full speed - using busmaster DMA
whenever possible.
I’m thinking about using a dynamically updated “big tiles” to deal with any
sort of 2D background maps without ending up with tons of triangles.
Uploading bandwidth requirements would be low for “normal” scrolling speeds
(just a few thousand texels/frame), but of course, I’d like to make it as
efficient as possible. (I’ve seen some older games with hysterically fast
scrolling at times, and it would be pretty disappointing if that wasn’t
possible to do with modern hardware…
The main reason why I don’t want to stick with the current solution of
rendering “map tiles” individually as textured quads is that it’s h*ll when
it comes to antialiazing. Generating larger RGBA textures with the CPU would
be simpler, more flexible WRT map formats, multilayered maps, would allow
real time procedural background generation, would allow more graphics data
without depending on the VRAM size etc, etc… (It’s also a more interesting
solution from the tecnical POV.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Wednesday 14 February 2001 07:17, Sam Lantinga wrote:
I should have clarified, I was talking about 2D on the current generation
of graphics cards. For 3D, they often have subpixel precision.
[…]
Well, if you’re using software rendering, that might be the case, at
least when doing blending effects (as they require operations on pixels),
but any
decent GPU is already using 64 bits or more, and doesn’t care much about
alignment anyway, as it’s designed solely for pumping pixels; not for
generic processing.“that might be the case”… what? That 32-bit is faster or 16-bit is
faster?
Sorry, 32 bits would be faster, as you can do byte operations rather than bit
manipulation.
Yes, it would be for software effects to go with 3D effects (either on top
of 3D or as textures for 3D)…
…or if you don’t have hardware acceleration at all. (However, in that case,
you probably shouldn’t use OpenGL at all. It seems very hard to do implement
in software without being either terribly slow or too inacurrate to be
usable. Most games have custom s/w rasterizers - or just aren’t playble
without h/w acceleration.)
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Wednesday 14 February 2001 14:49, Olivier Dagenais wrote:
“that might be the case”… what? That 32-bit is faster or 16-bit is
faster?
Sorry, 32 bits would be faster, as you can do byte operations rather than
bit
manipulation.
Even though it means there are more bytes and hence less room for caching or
more memory consumed?? What about if you include blitting times?
…and what about if I use OpenGL surfaces? Do most video cards support
32-bit color output? What about textures? Is the video card just going to
convert textures to 16 bits when I hand them over? Do all accelerators only
use textures that are in their on-board memory? (I really need to catch up
on HW 3D acceleration…)
Olivier A. Dagenais - Software Architect and Developer
“that might be the case”… what? That 32-bit is faster or
16-bit is faster?Sorry, 32 bits would be faster, as you can do byte operations
rather thanbit
manipulation.
Even though it means there are more bytes and hence less room for
caching or more memory consumed?? What about if you include
blitting times?
That depends on your code, and the CPU speed / memory speed ratio. So
far, x86 CPUs have been rather inefficient when it comes to bit field
manipulation (blending with saturation in particular), so your best
bet is MMX - which works only with 8, 16 and 32 bit words packed in
64 bit registers. Sure, you can have the MMX code work with bit
fields internally, but that will likely cut performance enough to
make it CPU bound rather than memory bound. (If it isn’t already,
that is.)
…and what about if I use OpenGL surfaces? Do most video cards
support 32-bit color output?
How do you mean? As long as you let the card do all rendering, it’s
hard to say which format will be the fastest, but it’s usually the
one with the lowest bandwidth; ie 16 bit textures and 16 bit display.
Some cards that are still popular cannot accelerate 24 or 32 bits at
all, while on others, it hardly makes a difference what format you
use, at least for “sane” display resolutions. Don’t make any fixed
assumptions here, that is…
What about textures? Is the video
card just going to convert textures to 16 bits when I hand them
over?
That depends on the card. Some cards seem to support multiple texture
formats doing conversion on the fly without penalty, while others may
be entirely hardcoded to 5:6:5 and 4:4:4:4, for example.
As to conversion when uploading; the Utah-GLX drivers seem to do all
conversion on the host CPU rather than letting the accelerator do it.
This is probably the best way for procedural textures on fast CPUs,
but I’m not sure about slow CPUs and fast GPUs… Texture caching
algos are usually have some missed deadline tolerances (load smaller
mipmaps first and use them if the right ones haven’t alived yet), so
it’s probably better to keep the GPU rendering in that case as well.
Anyway, I’m not even sure the majority of video cards can do any
useful texture format conversions at all - it might actually be
faster doing it with the CPU. It certainly is more flexible WRT range
of formats supported, at least.
Do all accelerators only use textures that are in their
on-board memory? (I really need to catch up on HW 3D
acceleration…)
No, many cards can do busmaster transfers. AFAIK, (nearly?) all AGP
cards can render directly from the AGP aperture.
I guess I could provide 16-bit and 32-bit versions and let the user
pick their poison (and maybe even run a typical set of routines and
benchmark them?)…
Yeah, that’s basically it. You always have to provide a few versions
of you code to get absolute top performance on all machines.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 15 February 2001 06:31, Olivier Dagenais wrote:
Some cards that are still popular cannot accelerate 24 or 32 bits at
all, while on others, it hardly makes a difference what format you
use, at least for “sane” display resolutions. Don’t make any fixed
assumptions here, that is…
Yeah, I remember reading about ATI’s claims that 24-bit or 32-bit rendering
wasn’t much slower than 16-bit, but that only worked until 1024x768 or
something…
That depends on the card. Some cards seem to support multiple texture
formats doing conversion on the fly without penalty, while others may
be entirely hardcoded to 5:6:5 and 4:4:4:4, for example.
I don’t suppose there is some way to detect this, is there? What do most
games do?
I guess I could provide 16-bit and 32-bit versions and let the user
pick their poison (and maybe even run a typical set of routines and
benchmark them?)…
Yeah, that’s basically it. You always have to provide a few versions
of you code to get absolute top performance on all machines.
Olivier A. Dagenais - Software Architect and Developer
Some cards that are still popular cannot accelerate 24 or 32 bits at
all, while on others, it hardly makes a difference what format you
use, at least for “sane” display resolutions. Don’t make any fixed
assumptions here, that is…Yeah, I remember reading about ATI’s claims that 24-bit or 32-bit rendering
wasn’t much slower than 16-bit, but that only worked until 1024x768 or
something…
That would be where the rendering switches from GPU bound to VRAM bound…
For the G400 MAX, there doesn’t seem to be much difference between 16 and 32
bit modes on Quake III, but it seems that the bandwidth get exhausted quickly
above 800x600 with that game and card.
My general impression of the G400 is that it renders with very high quality
and pretty fast regardless of blending modes and stuff, but that it quickly
gets bandwidth problems with higher resolutions. Shame on a card that’s so
incredibly good at precisely that; high resolution displays… (Ok, I’m
considering a drop below full frame rate a significant slow-down here, which
isn’t really fair to a previous generation card with very high quality
rendering. I chose the card mainly for it’s excellent RAMDAC, and not for 3D
gaming. Does that too pretty well, considering it as a bonus.
Anyway, this “resolution limit” also depends on actual draw area (with and
without actual drawing, modulated by the Z-buffer - which also consumes some
VRAM bandwidth), texture resolution and overdraw.
That depends on the card. Some cards seem to support multiple texture
formats doing conversion on the fly without penalty, while others may
be entirely hardcoded to 5:6:5 and 4:4:4:4, for example.I don’t suppose there is some way to detect this, is there? What do most
games do?
I think there is on most 3D APIs! I was actually asking about a good way to
do that using OpenGL in some earlier post…
Alternatively, I could just read those darn OpenGL docs I downloaded the
other week!
I guess I could provide 16-bit and 32-bit versions and let the user
pick their poison (and maybe even run a typical set of routines and
benchmark them?)…Yeah, that’s basically it. You always have to provide a few versions
of you code to get absolute top performance on all machines.Cool, thanks for your answers, David!
Not particularly cool being forced to write multiple versions, I think, but
other than that, you’re welcome. ;-D
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 15 February 2001 15:04, Olivier Dagenais wrote: