when someone implements it.

I personally think there is little point in improving current drivers. The main energy should go into developing a decent OpenGL driver. With that it would be possible to accelerate almost anything and it would be portable.

AJ: If you use OpenLayer you can effectively do this already (and with blending, roatation, etc..)

The problem with DX9 is, we would lose "ddraw.h", because the last directX version supporting standard 2D interfaces is DirectX8. DX9 is 3D interfaces only and that would require to emulate 2D through 3D interfaces. Another point for not using DX9 would be that there are a lot of video cards out there, who simply can not run DX9 games in hardware, so there would be a need for fallback drivers to DX8 and DX7 to support the most common video cards in use. (Otherwise those unsupported cards would use DX9 software interfaces, which would slow everything down and not utilize the acceleration potential of those cards.)

Sounds all nice and easy in theory. In practice that means a huge workload and i don't know if that's worth the trouble in the current Allegro version(which sources are horrible). Goes without saying that, if i knew HOW to do all of the above, i would long have started to implement it, but since i don't know anything about Direct3D and don't have the time to learn it, i have not.;D

With all due respect, every version of DirectDraw has this. It's the reason IDirectDrawSurface::Blt has a source RECT and a dest RECT. Microsoft aren't in the habit of keeping around old documentation, but I can still find IDirectDrawSurface5::Blt in MSDN and note particularly from the comments (emphasis added):

I can't find an MSDN source for it, but I can assert that this method was not changed as DirectDraw advanced. The ability to scale is what differentiates Blt from BltFast. Of course DirectDraw is able to use either of its blit functions for the equivalent of Allegro _blit and _sprite functionality.

To implement an accelerated stretch on Windows should be as simple as duplicating the hardware non-scaled blitter, changing the (hopefully) BltFast to a Blt and independently building a destination rectangle. It should be a quick enough modification. Although I don't have a suitable build chain, I'll go glance at the source.

EDIT:

Having found the non-accelerated version (src/win/wddaccel.c, line 88 onwards), what is the purpose of this clause at line 139:

   else {
      /* have to use the original software version */
      _orig_masked_blit(source, dest, source_x, source_y, dest_x, dest_y, width, height);
   }
}

I cannot imagine that the Allegro developers think they have implemented a faster software blit than that provided by DirectDraw? Perhaps it is to mask Allegro's continuing deficiencies with locking and unlocking?

EDIT2:
The following code should do:

Plus something analogous to ddraw_draw_sprite to map from stretch_sprite to masked_stretch_blit, and the flagging of this as an available accelerated routine at wherever that should be done (which I haven't quite found yet...)

EDIT3:
And why not use BltFast in masked blit? It is rarely faster, but it may be depending on driver and hardware, etc. i.e.

Oh, Allegro is maintaining it's own internal format for memory bitmaps? I'm curious - why would does it not just use DirectDraw memory surfaces?

I can't see how, if Allegro is flexible enough to be able to handle DirectDraw surfaces as BITMAPS where they are system/video resident, it could not handle DirectDraw surfaces as memory BITMAPS.

EDIT:
it seems the place to notify Allegro of a new accelerated function is in gfx_directx_enable_acceleration at line 453 of the same file as above - src/win/wddaccel.c. I haven't found the definition of _screen_vtable yet but at a guess you'd change the final if clause, currently:

   if ((ddcaps.dwCaps & DDCAPS_COLORKEY) &&
       (ddcaps.dwCKeyCaps & DDCKEYCAPS_SRCBLT)) {
      _screen_vtable.masked_blit = ddraw_masked_blit;
      _screen_vtable.draw_sprite = ddraw_draw_sprite;

      if (_screen_vtable.color_depth == 8)
   _screen_vtable.draw_256_sprite = ddraw_draw_sprite;

      gfx_capabilities |= (GFX_HW_VRAM_BLIT_MASKED | GFX_HW_SYS_TO_VRAM_BLIT_MASKED);
   }

To:

   if ((ddcaps.dwCaps & DDCAPS_COLORKEY) &&
       (ddcaps.dwCKeyCaps & DDCKEYCAPS_SRCBLT)) {
      _screen_vtable.masked_blit = ddraw_masked_blit;
      _screen_vtable.draw_sprite = ddraw_draw_sprite;

      /* new entry */
      _screen_vtable.masked_stretch_blit = ddraw_masked_stretch_blit

      if (_screen_vtable.color_depth == 8)
   _screen_vtable.draw_256_sprite = ddraw_draw_sprite;

      gfx_capabilities |= (GFX_HW_VRAM_BLIT_MASKED | GFX_HW_SYS_TO_VRAM_BLIT_MASKED);
   }

Does anybody have a Windows/GCC toolchain to try some of this stuff out?

i'm trying it ...

ddraw_masked_stretch_blit isn't declared.

i'm trying to use the Thomas's ddraw_masked_strech_blit.
I'm currently including it to fix the gcc issue (i'm dumb, i know)

EDIT: currently compiling... with no warning or error, i follow the AL_FUNC(...) and other allegro's specific way of implementing.

I'm leaving work but will try to to this when at home.
I'll keep you informed.

i'm back

i'm currently here:

any idea?

PS: if a someone is good at allegro-updating, i can provide a 'fast' vnc connection for him.

Also a ftp.

PM me !

Dump ddraw_masked_stretch_blit as suggested above and try the following:

And then bin:
_screen_vtable.masked_stretch_blit = ddraw_masked_stretch_blit;
For:
_screen_vtable.do_stretch_blit = ddraw_do_stretch_blit;
Note that this should only accelerate stretch_blit and masked_stretch_blit (or wherever masked is added to make that an Allegro function) - if it works then a simple thing to convert accelerated stretch_sprites to stretch_blits can be added.