It's ok, I've done the change manually, the diff file is self-explanatory (btw, you haven't included the file anyway!) [edit]I see you now have. I'll recompile[/edit].

Before I do my tests, here are the results of the new test.exe, which I guess says my card is doing acceleration for video/system graphics.

vram->vram blit: yes
masked vram->vram blit: yes
mem->screen blit: no
masked mem->screen blit: no
system->screen blit: yes
masked system->screen blit: yes

Ok, updated test as well and my system is fully hardware accelerated except for memory to screen blits and stretched vram-vram (though masked stretched vram-vram is), which I guess is fairly normal. Here are my results. I tested it with all permutations of video/system/memory bitmaps onto memory/system/video buffers using both single graphics and sub-bitmaps. I also tested them as a base with the original 4.2 DLL and the new changes:

Tests are :
A. draw buffer is memory. graphics are memory (normal, not sub-bitmap)
B. draw buffer is memory. graphics are system (normal, not sub-bitmap)
C. draw buffer is memory. graphics are video (normal, not sub-bitmap)
D. draw buffer is system. graphics are memory (normal, not sub-bitmap)
E. draw buffer is system. graphics are system (normal, not sub-bitmap)
F. draw buffer is system. graphics are video (normal, not sub-bitmap)
G. draw buffer is video. graphics are memory (normal, not sub-bitmap)
H. draw buffer is video. graphics are system (normal, not sub-bitmap)
I. draw buffer is video. graphics are video (normal, not sub-bitmap)

Firstly, as a base, I tested all the above using the standard allegro 4.2 dll. All the stretch functions works. draw_sprite is as my other emails so I won't mention it.

Using the new DLL the results are as follows,
Y - works fine
Nx - fails, number corresponds to the errors below the table.

test  stretch_blit  masked_stretch_blit  stretch_sprite  draw_sprite
A    Y    Y      Y    Y
B    N1    N1      N1    Y
C    N1    N1      N1    Y
D    Y    Y      Y    Y
E    N2    N2      N2    Y
F    N2    N2      N2    Y
G    Y    Y      Y    Y
H    N2    N2      N2    Y
I    N2    N2      N2    Y

Failure types
N1: crash on calling function
N2: sprite is not shown

Using the new code and single bitmaps it's pretty clear that stretch only works when the buffer being drawn onto is memory. Where it fails the majority must be failing to draw, but when you draw memory bitmaps onto accelerated buffer it crashes.

------------------------------------
I then repeated all the tests again, but this time the graphics being shown are sub-bitmaps of a master sheet. I will only show below the results that are different (i.e. a different result blitting sub-bitmaps rather than normal bitmaps)

test  stretch_blit  masked_stretch_blit  stretch_sprite  draw_sprite
B                  N3
E    N4    N4      N4    N3
F    N4    N4      N4    N3
H    N4    N4      N4    N3
I    N4    N4      N4    Y

Failure types
N3 Crashes on destroying the subbitmap (this is already documented by me earlier)
N4 This is a freaky error! instead of drawing the bitmap stretched it is increasing the size of the bitmap (i.e. if my sprite was 32x32, instead of stretching it to 64x64 as in the code, it actually simply changes the size of the sub-bitmap to 64x64 - showing simply a larger part of the master bitmap)

So it looks like when your graphic being drawn is a subbitmap and your drawing buffer is a system or video bitmap and your graphic is a system or video you get the bitmap being enlarged not stretched.

Hope this helps

btw, in the test code you popped up, you forgot a comma in this line and the one bwlow:
"stretch vram->vram blit:"

Can anyone confirm or deny that ddraw_do_stretch_blit obeys set_clip_rect? I can't think how it does and I'm particularly concerned that if DDCAPS_CANCLIPSTRETCHED is not set then some sort of memory overflow may occur. I have no idea what that would do in global terms but I'd imagine at least graphics corruption.

Yes, I'm having a few issues with it. I'd definitely either GNUstep or ROX Desktop/Zero Install if I left the Mac world. Anyway can anyone recommend a Windows/GCC setup that includes a graphical debugger that could be used to trace into a (suitably built) version of the Allegro DLL?

I figured the other day that it might. I don't think there's a special check for that in the code. The fix is probably to only call the HW-accelerated version if the target is a video/system bitmap.
I'm curious now: does a normal blit from video->mem work if vid->vid is hardware accelerated or does that also crash?

Without really being able to explain the sub-bitmap thing, I guess a relevant question is whether you see a "colour 0" border in 8bpp mode? Does generating a sub-bitmap that is actually exactly the same proportions as a parent bitmap fix the problem?

EDIT: Hmmm, it seems others have had the same problem and not found a solution. Do you see the main body of your sprite being filtered? I guess we need to play about with a DDBLTFX structure - in particular it seems to have stuff like dwAlphaEdgeBlend, although not particularly clear from a brief reading. It also allows flipped and mirrored blits, so things like draw_sprite_v_flip (or whatever Allegro calls it) could be accelerated if they aren't already (?)

Gamasutra has this to say about this about stretching/mirroring/shrinking, 'These features, however, are often driver-dependent and are supported to different extents on different video hardware, providing inconsistent results if used.'

Perhaps to make it consistent in the case of vid->vid then do a fallback to the _orig_stretch_blit(...), e.g. in ddraw_do_stretch_blit():

   if ( ( (masked && (gfx_capabilities & GFX_HW_STRETCH_BLIT_MASKED)) ||
  (!masked && (gfx_capabilities & GFX_HW_STRETCH_BLIT)) 
) && ( (is_video_bitmap(source) && !is_video_bitmap(dest)) || is_system_bitmap(source) ) 
                                  ********************

If you look at the attached image you'll see it doing what we thought. It seems to be stretching then removing the mask, leaving an anti-aliased artifact.

Back to the tests, I've tested all the things as above and updated the table.

A. draw buffer is memory. graphics are memory (normal, not sub-bitmap)
B. draw buffer is memory. graphics are system (normal, not sub-bitmap)
C. draw buffer is memory. graphics are video (normal, not sub-bitmap)
D. draw buffer is system. graphics are memory (normal, not sub-bitmap)
E. draw buffer is system. graphics are system (normal, not sub-bitmap)
F. draw buffer is system. graphics are video (normal, not sub-bitmap)
G. draw buffer is video. graphics are memory (normal, not sub-bitmap)
H. draw buffer is video. graphics are system (normal, not sub-bitmap)
I. draw buffer is video. graphics are video (normal, not sub-bitmap)

So it looks like things are almost there with the only fault now being drawing system/video bitmaps onto memory bitmaps. The other two faults are on destroying sub-bitmaps that are system bitmaps (but that isn't a stretch fault) and the odd halo fault that might be a ddraw bug.

to answer the questions:

No, that bit of code was to avoid vid->vid which is the only one which seems to be a ddraw bug and not a coding problem, so cannot be fixed, or made to work consistently in Windows. this isn't a big thing as it's currently software only anyway.

The software stretcher works fine (i.e. using the unchanged code).

Standard blits are fine, it is just any of the stretch functions.

As far as I can see there is hardly any difference between ddraw_masked_blit() and ddraw_do_stretch_blit(), nothing worth noting anyway. In order to state the obvious I debugged the stretch_blit at the point of crash and it fails on the draw:

hr = IDirectDrawSurface2_Blt(DDRAW_SURFACE_OF(dest_parent)->id, &dest_rect,
DDRAW_SURFACE_OF(source_parent)->id, &source_rect,
(masked ? DDBLT_KEYSRC : 0) | DDBLT_WAIT, NULL);

I can only summise that it must be a bug inside the _Blt function or perhaps my video card has a fault? If someone offers (they haven't the past few times I did) I'll post the exe for them to test.

Neil.

I didn't check the data in the function (I'll do it tonight and update the post when done - I don't have a JIT debugger on this build) but for my source image I tried both 24x24 and 32x32, and tried doubling the size and keeping the same size.

So thinking about it, there is no difference between the standard masked_blit call and the stretched_mask_blit when your destination size is the same as the source as they both call the same IDirectDrawSurface2_Blt with the same parameters, don't they?

In blit.c in the src directory blit() does this:

      /* drawing onto memory bitmaps */
      if ((is_video_bitmap(src)) || (is_system_bitmap(src)))
         src->vtable->blit_to_memory(src, dest, s_x, s_y, d_x, d_y, w, h);
      else
         dest->vtable->blit_to_self(src, dest, s_x, s_y, d_x, d_y, w, h);

This is the code for blitting video/system onto memory, which is as you say, checks what to do, which I guess is why standard blit works.

I got a bit confused as to stretch_blit as the only obvious place was cstretch.c in src\c and istretch.c in the i386 directory. I don't know which is being called.

However, in istretch.c it does say that the code is a bit dodgy, but it does no checks on bitmap type, however if source->vtable->do_stretch_blit is set then it just calls do_stretch_blit() which doesn't have any checks either on whether the source/dest are video->memory.

In cstretch.c it does:

   #ifdef ALLEGRO_MPW
      if (is_system_bitmap(src) && is_system_bitmap(dst))
         system_stretch_blit(src, dst, sx, sy, sw, sh, dx, dy, dw, dh);
      else
   #endif
         _al_stretch_blit(src, dst, sx, sy, sw, sh, dx, dy, dw, dh, 0);

I don't know what ALLEGRO_MPW is or whether either function does dst bitmap type checks.

Guessing I say it is calling the function in istretch.c because the vtable function is getting called and that does no checks?

In that case, the function in istretch.c must be the fault like Evert said. I'll give the code a tweak tonight (unless Evert beats me to it) and see if it works.

It still crashes. Even if I put the _orig function at the top of the do_stretch function and call it regardless. I can't really follow all the vtable stuff so I guess something is going wrong somewhere as it works with the non-accelerated code changes. I put the change in ddraw_do_stretch_blit.

btw, it isn't exactly a huge speed increase, but at the top of most of the ddraw blit functions there are about 10 lines of calculations for dest_rect and source_rect and src_key. They are only used when the acceleration check is made, so I guess it would make sense to move them into the statement to gain a teeny weeny increase in speed. I tried it and it works fine.

Is it possible to make unaccelerated calls to the blit, etc. functions when code would normally route it to the accelerated functions? is it just a matter of changing the gfx flag at runtime to disable the feature, or is this a bad thing to do?

Well, that's what happened. I put the _orig as the first line of code in the function and it crashed. To make sure I was using the right file and the right thing was being called, I simply put in a return as the first statement and it worked (i.e. nothing was displayed). Anyway, I'll recompile with debug and see where it falls over.

A little bit here, a little bit there I guess if you call the function 60 times a second for each of 300 sprites on your screen, those 10 lines of additions might add up to a tiny saving?