DX5 Headers

SDL Development
1

Where can I find the DirectX headers so I can compile with DirectX support
under the Cygwin environment?

Thanks,

  • Derrick
2

Where can I find the DirectX headers so I can compile with DirectX support
under the Cygwin environment?

Oh, I forgot to link them into the Xmingw32 page…
http://www.libsdl.org/Xmingw32/directx-cygwin.tar.gz

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

3

Hello,

sorry if this is a FAQ, but I have not found the answer in the archives.

Why SDL API does not support 2D blits with stretching? There is already some
sort of software stretching (used by overlays), but they are not exposed,
and there is no support for hardware accelerated stretching, that is
supported by PC graphic cards from a while.

Thanks—
Giovanni Bajo
Lead Programmer

Protonic Interactive
www.protonic.net

  • Black holes are generated when God divides by zero -
4

Why SDL API does not support 2D blits with stretching? There is already some
sort of software stretching (used by overlays), but they are not exposed,
and there is no support for hardware accelerated stretching, that is
supported by PC graphic cards from a while.

exactly what graphics hardware supports scaled blits as a 2d operation?
and what kind of scaling?

5

Why SDL API does not support 2D blits with stretching? There is already some
sort of software stretching (used by overlays), but they are not exposed,
and there is no support for hardware accelerated stretching, that is
supported by PC graphic cards from a while.

exactly what graphics hardware supports scaled blits as a 2d operation?
and what kind of scaling?

Most new PC hardware, actually. It’s on the TODO list for SDL 1.3

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

6

exactly what graphics hardware supports scaled blits as a 2d operation?
and what kind of scaling?

Most new PC hardware, actually. It’s on the TODO list for SDL 1.3

of course it is, but I wanted to know which ones and what they supported.
Even a voodoo3 supports some kind of scaling but it’s just a cheap
non-interpolated one

7

Supposedly there is a software MMX routine thing that does software bilinear
filtering at 43clocks/pixel. Plus UT has a technique that employs some
dither technique thats supposed to be pretty fast. A convenient fallback if
there is no hardware support.

Matt> >> exactly what graphics hardware supports scaled blits as a 2d operation?

and what kind of scaling?

Most new PC hardware, actually. It’s on the TODO list for SDL 1.3

of course it is, but I wanted to know which ones and what they supported.
Even a voodoo3 supports some kind of scaling but it’s just a cheap
non-interpolated one

8

I suppose that most graphic cards for PC that have been sold in last 2-3
years have it. Theorically, everything with texture mapping support should
support stretch blits, but then it is a driver support problem.

I would not care interpolated blit that much. It would be enough to just
stretch my little sprites without using software routines that must lock the
surfaces and manage them.

Of course, fast optimized software fallbacks are welcome :)—
Giovanni Bajo
Lead Programmer

Protonic Interactive
www.protonic.net

  • Black holes are generated when God divides by zero -

-----Messaggio originale-----
Da: owner-sdl at lokigames.com [mailto:owner-sdl at lokigames.com]Per conto di
Mattias Engdeg?rd
Inviato: gioved? 26 aprile 2001 19.38
A: sdl at lokigames.com
Oggetto: Re: [SDL] Stretch Blit support

exactly what graphics hardware supports scaled blits as a 2d operation?
and what kind of scaling?

Most new PC hardware, actually. It’s on the TODO list for SDL 1.3

of course it is, but I wanted to know which ones and what they supported.
Even a voodoo3 supports some kind of scaling but it’s just a cheap
non-interpolated one

9

43 clocks/pixel in L1 cache, L2 or memory ?
On which processor ?

According to the stream benchmarks
(http://www.cs.virginia.edu/stream/peecee/Bandwidth.html)
An athlon 500Mhz performs a copy of 373 500 000 Bytes each second.

Then a fast blit of a 32 bits surface without alpha or rle or colorkey
would takes 6 cycles per pixel when data doesn’t lie in data cache.

Ok there is much more work than in a simple copy, but is this claimed
performance of 43 cycles/pixels realy impressive ? It’s still 7 times slower
than a fast blit…

Perhaps a simple stretch without filtering would give the same performance
level
as a fast blit (the fixed point offset increment can be performed during the
data transfer).

Supposedly there is a software MMX routine thing that does software
bilinear
filtering at 43clocks/pixel. Plus UT has a technique that employs some
dither technique thats supposed to be pretty fast. A convenient fallback
if
there is no hardware support.

Matt

exactly what graphics hardware supports scaled blits as a 2d
operation?

and what kind of scaling?

Most new PC hardware, actually. It’s on the TODO list for SDL 1.3

of course it is, but I wanted to know which ones and what they
supported.> > Even a voodoo3 supports some kind of scaling but it’s just a cheap

non-interpolated one

10

43 clocks/pixel in L1 cache, L2 or memory ?
On which processor ?

Core clocks, I’d guess, and it shouldn’t matter much which processor you’re
using, as it’s processor bound; not memory bound.

According to the stream benchmarks
(http://www.cs.virginia.edu/stream/peecee/Bandwidth.html)
An athlon 500Mhz performs a copy of 373 500 000 Bytes each second.

Then a fast blit of a 32 bits surface without alpha or rle or colorkey
would takes 6 cycles per pixel when data doesn’t lie in data cache.

Ok there is much more work than in a simple copy, but is this claimed
performance of 43 cycles/pixels realy impressive ?

Yes.

It’s still 7 times
slower than a fast blit…

It’s also doing a lot more processing. Copying, and even "nearest pixel"
style scaling is just data shuffling, while bilinear interpolation is
actually real image processing, involving something like (in it’s simplest
form) 4 input pixels, at least 4 multiplications and at least 6 adds per
output pixel.

Perhaps a simple stretch without filtering would give the same performance
level
as a fast blit (the fixed point offset increment can be performed during
the data transfer).

Yes, it’s a lot faster than bilinear interpolation. Even faster if you’re
using various precalculation tricks, or even real time machine code
generation… (AFAIK, that’s exactly what SDL does on x86.)

//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 Friday 27 April 2001 10:26, Xavier Le Pasteur wrote: