#### Archived

This topic is now archived and is closed to further replies.

# Antialiasing sprites with DirectDraw<=7

This topic is 5800 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

For 2D games. 1.Have you done it? 2.How did you handle it? 3.For which system? (microprocessor, videocard) 4.How many sprites and what performance did you achieved? I know these days you can use 3D hardware, but also these days you have Gigs of processing power to handle this without 3D hardware, and since DirectX 8.1 doesn''t support Software Rendering anymore there are still lots of people who will be unable to play a game with 3D hardware requirements.

##### Share on other sites
quote:
1.Have you done it?

Yes
quote:
2.How did you handle it?

(Q[ick])BASIC, (Turbo) Pascal + BGI, C (using my own VESA libray
completly written in assembly), C++ using DirectX 8
quote:
3.For which system? (microprocessor, videocard)

80x286 + custom VGA chipset (b/w laptop), 80x486 + S3 card, Pentium class (P90, Cyrix 80x686, Celeron, Athlon) + ATI RagePro, RivaTNT, GeForce, GeForceIII
quote:
4.How many sprites and what performance did you achieved?

In all cases: *many* - I mean really, no matter what platform you''re hooked on you can always get the best (more than 256 sprites of various sizes that is) out of it when carefully taking into consideration the capabilities of your hardware.
Example: my early DOS games used 16 color sprites (on the 286) and 256 palettized sprites for VESA and VGA modes.

Today you can use libraries like Allegro or SDL and just test out what you can get out of them in term of number and quality (size, effects) of sprites and backgrounds.

quote:

[...] since DirectX 8.1 doesn''t support Software Rendering anymore there are still lots of people who will be unable to play a game with 3D hardware requirements.

I disagree. Almost all graphic adapters sold after - say 1995 - do have a certain degree of 3D hardware capabilities.
Not enough to play QIII maybe, but sufficient for DX8 or OGL driven 2D games (if you don''t mess with alpha blending, stencil buffers and other hardware dependent effects). Even if they don''t support DX8 you can still use DirectDraw since DX is backwards compatible.

If you use one of libraries mentioned above, you don''t have to worry about that anyway, since they will take care for that.

Cheers,
Pat

##### Share on other sites
I missed the point I think
Using pre-antialiased sprites was my first approach, later I used somewhat optimized assembly routines (DOS platform).

When I started migrating to win32, I used OpenGL (DX8 later) and never messed with DirectDraw or Direct3D versions prior to DX8, so I can''t give any hints about that

Egde anti-aliasing for small objects, however, isn''t that much of a performance hit and can be done in software. If you want to do anti-alias the whole sprite, I''d recommend not to try that in real-time - IMO it just doesn''t make any sense at all since non of your content is generated on-the-fly anyway.

Just my .02€
Pat

##### Share on other sites
Thanks for the replies.

quote:
Original post by Prototype

Sorry, isn''t it properly written? If so, please correct me.

quote:
Original post by darookie
In all cases: *many* - I mean really, no matter what platform you''re hooked on you can always get the best (more than 256 sprites of various sizes that is) out of it when carefully taking into consideration the capabilities of your hardware.
Example: my early DOS games used 16 color sprites (on the 286) and 256 palettized sprites for VESA and VGA modes.

Cool. What about doing it on 16bit mode without using 3d hardware? What kind of system could be able to do it acceptably? (256+ sprites at 24+ FPS)

quote:
Original post by darookie
Today you can use libraries like Allegro or SDL and just test out what you can get out of them in term of number and quality (size, effects) of sprites and backgrounds.

Yes, I know there are good libs arround, but I''m trying to do it by my self with DirectDraw (just a challenge), I would like to cover the most number of computers (from Pentium 100 to etc) but only for 16bit+ modes.

##### Share on other sites
quote:
Original post by darookie
I missed the point I think

I think you didn''t

quote:
Original post by darookie
Using pre-antialiased sprites was my first approach, later I used somewhat optimized assembly routines (DOS platform).

Egde anti-aliasing for small objects, however, isn''t that much of a performance hit and can be done in software. If you want to do anti-alias the whole sprite, I''d recommend not to try that in real-time - IMO it just doesn''t make any sense at all since non of your content is generated on-the-fly anyway.

Yes, I''m trying to do ''Edge anti-aliasing'' on sprites not bigger than 64x64 pixels, on 16bit mode, over a nice 16bit background at runtime. But I don''t know much about messing with pixels.

I would like to know if it is possible on older systems like Pentium 100, or at least, to know from which kind of systems this is possible for a game... I''m completely ignorant about this.

##### Share on other sites
quote:
Original post by xaxa
Thanks for the replies.
Sorry, isn't it properly written? If so, please correct me.

I misinterpreted the title.

[edited by - Prototype on December 1, 2002 12:53:22 AM]

##### Share on other sites
If you are going for DirectDraw, you can even use plain C to do egde anti-aliasing for the sprites if they''re that small.

16 bit mode should be ok. You can even do alpha-blending with your sprites and still have a bunch of them @24FPS.
For some efficient algorithms and approaches using DDraw7 just google around - since I never messed with it I''m not that much of help

As for your pixel question - it''s not that hard in 16 bit mode.
If you use 5-6-5 format (5 bits red, 6 bits green, 6 bit blue),
you can extract color component like this:

  // assuming RGB ordering, red component starting at LSB#define RED_MASK    0x001f#define RED_SHIFT   0#define GREEN_MASK   0x07e#define GREEN_SHIFT  5#define BLUE_MASK    0xf800#define BLUE_SHIFT   11#define RED_VALUE(x) \        ((x) & RED_MASK) >> RED_SHIFT#define GREEN_VALUE(x) \        ((x) & GREEN_MASK) >> GREEN_SHIFT#define BLUE_VALUE(x) \        ((x) & BLUE_MASK) >> BLUE_SHIFT#define RGB(r,g,b) \        (((r) << RED_SHIFT)|((g) << GREEN_SHIFT)|((b) << BLUE_SHIFT))

Hope that helps a little,
Pat

##### Share on other sites
I done edge antialiasing not very long ago.. in software ddraw 7 :-) 16 bit.. I''ll try to explain.. Lets say you have a sprite 64x64 in 16bit 565 color with color 0 as the transparent color (the one you use for color keying :-).. okay fire up VC and write a loop which loops trough every pixel in the sprite.. you also need to have your backbuffer ready and filled with some background:

1. if the color at the current x,y in the sprite is 0 (colorkey) and the color next to it (to the right, left, up or down) is not.. antialias the pixel (extract the colors using darookies macros for all the adjecent pixels.. average them, and store the average as the new pixel color).. this is a little tricky because if any of the pixels you average is zero (the colorkey) you will need to get the pixel value, to use in averaging, from the backbuffer (or source picture) instead of the sprite itself.
2. goto 1

You should start the loop from 1,1 to 62,62 (if your sprite is 64x64) to avoid using values outside the bitmap..

there is probably a much better way of doing this.. just what I thought up..

damn I am a bad teacher :-).. well I tried

##### Share on other sites
quote:
Original post by darookie
As for your pixel question - it''s not that hard in 16 bit mode.
If you use 5-6-5 format (5 bits red, 6 bits green, 6 bit blue),
you can extract color component like this:

    // assuming RGB ordering, red component starting at LSB#define RED_MASK    0x001f#define RED_SHIFT   0#define GREEN_MASK   0x07e#define GREEN_SHIFT  5#define BLUE_MASK    0xf800#define BLUE_SHIFT   11#define RED_VALUE(x) \        ((x) & RED_MASK) >> RED_SHIFT#define GREEN_VALUE(x) \        ((x) & GREEN_MASK) >> GREEN_SHIFT#define BLUE_VALUE(x) \        ((x) & BLUE_MASK) >> BLUE_SHIFT#define RGB(r,g,b) \        (((r) << RED_SHIFT)|((g) << GREEN_SHIFT)|((b) << BLUE_SHIFT))

Hope that helps a little,
Pat
Hey thanks for the code

quote:
Original post by smokes
I done edge antialiasing not very long ago.. in software ddraw 7 :-) 16 bit..

Cool

quote:
Original post by smokes
I''ll try to explain.. Lets say you have a sprite 64x64 in 16bit 565 color with color 0 as the transparent color (the one you use for color keying :-).. okay fire up VC and write a loop which loops trough every pixel in the sprite.. you also need to have your backbuffer ready and filled with some background:
1. if the color at the current x,y in the sprite is 0 (colorkey) and the color next to it (to the right, left, up or down) is not.. antialias the pixel (extract the colors using darookies macros for all the adjecent pixels.. average them, and store the average as the new pixel color).. this is a little tricky because if any of the pixels you average is zero (the colorkey) you will need to get the pixel value, to use in averaging, from the backbuffer (or source picture) instead of the sprite itself.
2. goto 1

You should start the loop from 1,1 to 62,62 (if your sprite is 64x64) to avoid using values outside the bitmap..

there is probably a much better way of doing this.. just what I thought up..

Wow, thank you for completing the picture, I''m about to try it out.

quote:
Original post by smokes
damn I am a bad teacher :-).. well I tried

Well you and darookie are the only I have so I think you''re great, thank you

1. 1
Rutin
32
2. 2
3. 3
4. 4
5. 5

• 11
• 13
• 91
• 11
• 10
• ### Forum Statistics

• Total Topics
632973
• Total Posts
3009621
• ### Who's Online (See full list)

There are no registered users currently online

×