I used the really neato source code from that really old article that was posted on here a while back about alpha blending and MMX and such. Only problem is, it drastically slows down my game when I want to put down a 320x240x16bpp sprite every frame. I am using MSVC++6.0, DXSDK7.0a, and I want to know how to make a REALLY REALLY fast translucent blit. Any idears? -Ben Dilts PS I need to use stretch/shrink at the same time... Edited by - BeanDog on 3/10/00 12:53:04 PM

i don''t know if that helps, but try creating your offscreen surface in system memory.
but remember: alpha blits without 3d-acceleration are always slow, no matter how optimized.
if anyone can oppose that, be sure to send me the source

I assume the article uses assembler.

The only way to beat assembler is by using hardware acceleration. I suggest you try rendering a polygon with D3D.

Or, even better (easier) yet, use OpenGL. =)

OK I''m working my way into D3DIM. Oh man. 20 mins of hard work and I STILL have nothing to show for it.

Here''s my init routine:

HRESULT D3DInit(LPDIRECTDRAW7 ⅅ, LPDIRECTDRAWSURFACE7 &Back, LPDIRECT3D7 &D3D, LPDIRECT3DDEVICE7 d3dDevice)
{
HRESULT hr;
DDSURFACEDESC2 ddsd;
D3DVIEWPORT7 vp = { 0, 0, 640, 480, 0.0f, 1.0f };

// Query DirectDraw for access to Direct3D
DD->QueryInterface( IID_IDirect3D7, (VOID**)&D3D );
if( FAILED( hr) )
return hr;

// Check the display mode, and
ddsd.dwSize = sizeof(DDSURFACEDESC2);
g_pDD->GetDisplayMode( &ddsd );
if( ddsd.ddpfPixelFormat.dwRGBBitCount <= 8 )
return DDERR_INVALIDMODE;

// The GUID here is hard coded. In a real-world application
// this should be retrieved by enumerating devices.
hr = D3D->CreateDevice( IID_IDirect3DHALDevice, Back,
&d3dDevice );
if( FAILED( hr ) )
{
// If the hardware GUID doesn''t work, try a software device.
hr = D3D->CreateDevice( IID_IDirect3DRGBDevice, Back,
&g_pd3dDevice );
if( FAILED( hr ) )
return hr;
}

hr = g_pd3dDevice->SetViewport( &vp );
if( FAILED( hr ) )
return hr;

d3dDevice->SetRenderState( D3DRENDERSTATE_AMBIENT, 0xffffffff );//white ambient light


return DD_OK;
}

Anything wrong here? Just pass in your devices and such, and set up the Direct3D device.

Question: Can you render using D3D onto the same surface you already have other stuff on using DDraw?

Question: Now what is the easiest way to put down a rectangular bitmap sprite on top of my other 2D stuff?

Question: Am I the only one who thinks MS made this DX stuff way to complicated to be useful whatsoever?

As merlin suggested, openGL is a lot easier to use. (and in my opinion better designed) I have used parts of DirectX for my coding (when I REALLY have to), and I''ve always found it like pulling out my fingernails one by one. I recommend you use opengl. If you want a place to start from, go to www.opengl.org

The idea here is straight speed.

I want to use the GDI that will give the most speed and portability. Ease of use can be overcome (i hope). If you can show me a list of things that will outperform ALL of the following items, I will completely give up on DirectX and use them.

*DirectDraw

*Direct3DIM

*DirectInput (this one''s the problem - if I''m going to use this, I figure I''ll stick with the rest of DirectX as they are all related)

*DirectSound

*DirectMusic

*DirectPlay (Another stickler - any good networking APIs?)

Thanx everyone.

I recommend you take a look at the following source codes that come with DXSDK7:

Mssdk\Samples\Multimedia\D3dx\Src\TrivWin
Mssdk\Samples\Multimedia\D3dx\Src\TrivFS

The first initializes a windowed D3D App and the second a fullscreen D3D App. Both of these render a rotating triangle on the screen.

For all OpenGL lovers, both of these have as little initialization code as any OpenGL program I have seen. So I would say that with the D3DX utility library, there really is no justification anymore for saying that OpenGL is easier to implement. It is easier to use with glVertex, glNormal and so on, but if you want speed in your application you shouldn''t use these anyway, instead you want to use vertex arrays and whatever else. Which makes it just as complicated programming with OpenGL as with DirectX.

Now, before people start flaming me for this statement I would like to add that I''m in the process of learning OpenGL myself, mostly out of curiousity. What I have learned so far I like, but I wouldn''t say it''s easier to use than Direct3D. They are in fact very similar to each other, in my opinion.

BeanDog: It's nothing wrong with just using parts of DirectX as they don't interact with each other (Except for DDraw and D3D). I believe most OpenGL games on the windows platform uses DInput and DSound, even though they use OpenGL. Most network games don't use DPlay however, it's said that it introduces some unnecessary overhead that most fastpaced games don't need, those games probably use WinSock instead. (Network programming is something that I don't know much about so that part is pure speculation from my side.)

Oh, and DirectX is an API (Application Programming Interface) and not a GDI (Graphic Device Interface).

Edited by - Spellbound on 3/10/00 3:53:42 PM

Before you throw away your neato MMX alpha blending code. See if you can modify it to never read video memory. If your video card is on a PCI bus reading from video memory can slow down the code an order of magnitude

trivialy handling areas that have full alpha or no alpha can speed up code. It may even be possible to modify the code to handle alpha as you stretch/shrink.

Optimizing for specific features of your situation can give great results, but makes the code less flexible.