Blitting in XOR mode

Hi everybody,
I’m currently writing a simple GUI toolkit using SDL. I’d like to
know if there’s some way that I can access the XOR blitting capability (
plus any other modes available ) of the hardware if it exists - which is the
case in virtually all display hardware AFAIK. Is there a native method
within SDL to do so? and if not, how can I bypass SDL and access this
feature directly?

Thanks in advance,
Mahmoud Al Gammal
-------------- next part --------------
A non-text attachment was scrubbed…
Name: winmail.dat
Type: application/ms-tnef
Size: 3328 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011205/9499224f/attachment.bin

“Mahmoud Al Gammal” wrote:

I’m currently writing a simple GUI toolkit using SDL. I’d like to
know if there’s some way that I can access the XOR blitting capability (
plus any other modes available ) of the hardware if it exists - which is the
case in virtually all display hardware AFAIK. Is there a native method
within SDL to do so? and if not, how can I bypass SDL and access this
feature directly?

classic raster-ops blits like XOR turn out to be rather useless for game
purposes, so SDL do not support them. rethink your reason for wanting it

Well, I suppose you can dig out the “private” stuff from the SDL_Surface
structs, and then use the underlying target API.

However, sure, neraly all hardware supports logic operations (actually,
the 256 ROP as defined by Windoze seems to be some kind of standard that
some chips support natively) - but I’m not sure you can access them
through DirectX, DGA, or other “direct access” APIs…

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 04 December 2001 23:33, Mahmoud Al Gammal wrote:

Hi everybody,
I’m currently writing a simple GUI toolkit using SDL. I’d like to
know if there’s some way that I can access the XOR blitting capability
( plus any other modes available ) of the hardware if it exists - which
is the case in virtually all display hardware AFAIK. Is there a native
method within SDL to do so? and if not, how can I bypass SDL and access
this feature directly?

However, sure, neraly all hardware supports logic operations (actually,
the 256 ROP as defined by Windoze seems to be some kind of standard that
some chips support natively) - but I’m not sure you can access them
through DirectX, DGA, or other “direct access” APIs…

I think that if he uses a direct mode (xor has no utility if the mode is
not direct) also a simple midpoint algorithm that read/write memory from
the gfx card buffer will outperform the complete reblit of the rectangle
given by the two extremes of the line (except when the line is aligned with
X or Y :slight_smile: ).
Anyway I don’t see why SDL can’t have an API call like:

SDL_DrawLine(SDL_surface *,int x1,int y1,int x2, int y2, int drawmode)

It already has SDL_FillRect!

Bye,
Gabry (gabrielegreco at tin.it)

Gabriele Greco wrote:

Anyway I don’t see why SDL can’t have an API call like:

SDL_DrawLine(SDL_surface *,int x1,int y1,int x2, int y2, int drawmode)

thin lines are commonly accelerated by hardware but it’s of questionable
utility — how many games spend a significant amount of their time drawing
lines? For emulating old vector games (or making new ones) you probably
want antialiased and/or translucent lines anyway (MAME offers this), so a
simple line primitive wouldn’t help there.

In fact, some of the XFree developers claim that using the hardware for
thin line drawing isn’t always a win — it can take longer to set up the
registers for the operation than to do it by setting the pixels in the
framebuffer manually (the amount of data is comparatively small)

It already has SDL_FillRect!

This is very different: FillRect() can efficiently be done by hardware, but
is limited by the bus bandwidth when done manually. It is also a quite
common operation (mainly for clearing the screen or parts of it)

Anyway I don’t see why SDL can’t have an API call like:

SDL_DrawLine(SDL_surface *,int x1,int y1,int x2, int y2, int drawmode)

Michael Abrash’s variation on the Bresenham line algorithm could render
lines so fast that the VGA hardware couldn’t keep up on a 486. Surely in
the age of 2GHz CPUs we can get similar functionality at the framebuffer
level in portable C, and without adding it to the base SDL API.

(There are add-on libraries that build this on top of SDL if you refuse to
expend twenty lines of source code on a basic Bresenham.)

–ryan.

Anyway I don’t see why SDL can’t have an API call like:

SDL_DrawLine(SDL_surface *,int x1,int y1,int x2, int y2, int
drawmode)

Michael Abrash’s variation on the Bresenham line algorithm could render
lines so fast that the VGA hardware couldn’t keep up on a 486.

BTW, I hacked a software line algo for the Amiga once - on a 25 MHz
68030, it was slightly slower than the blitter on the actual rendering,
but was still beating the blitter in many real life situations thanks to
there being only two or three instructions to execute before the
rendering was going. (For those of you who haven’t programmed the Amiga
blitter; setting up line drawing took around two pages of asm code…)

Surely in the age of 2GHz CPUs we can get similar functionality at the
framebuffer level in portable C, and without adding it to the base SDL
API.

Yeah, but don’t forget the horrible CPU-access-over-PCI/AGP penalty.
Rendering to a software surface and then copying that to VRAM is probably
going to be faster as soon as you need to access more than some 20-30% of
the target buffer memory…

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 06 December 2001 19:45, Ryan C. Gordon wrote:

Yeah, but don’t forget the horrible CPU-access-over-PCI/AGP penalty.
Rendering to a software surface and then copying that to VRAM is probably
going to be faster as soon as you need to access more than some 20-30% of
the target buffer memory…

Dear lord, David, we almost made it a full 24 hours without you mentioning
that VRAM access is slow. I’m calling Guiness.

–ryan.

Damn, I’m not keeping up! :wink:

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 06 December 2001 21:55, Ryan C. Gordon wrote:

Yeah, but don’t forget the horrible CPU-access-over-PCI/AGP penalty.
Rendering to a software surface and then copying that to VRAM is
probably going to be faster as soon as you need to access more than
some 20-30% of the target buffer memory…

Dear lord, David, we almost made it a full 24 hours without you
mentioning that VRAM access is slow. I’m calling Guiness.

Someone mentioned drink?!On Thu, Dec 06, 2001 at 03:55:46PM -0500, Ryan C. Gordon wrote:

Yeah, but don’t forget the horrible CPU-access-over-PCI/AGP penalty.
Rendering to a software surface and then copying that to VRAM is probably
going to be faster as soon as you need to access more than some 20-30% of
the target buffer memory…

Dear lord, David, we almost made it a full 24 hours without you mentioning
that VRAM access is slow. I’m calling Guiness.

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Martin

Bother, said Pooh, as he learned that his symbiont detested hunny.