The most useful feature i want from Allegro is VRAM to VRAM accelerated stretch blit. I dont think the current DirectX driver has this feature as its using dx3.

What versions of DirectX contain this feature ?
When would allegro get this DirectX version ?

if this is not likely to occur any time soon, does anyone know of other allegro-like libs that can do it ?

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.

As HoHo said, it'll be there when someone writes the code. I'm sure you're aware of the number of active Windows developers we have right now, so if you care to implement it that would be welcome.

Regarding OpenGL to do this, it's possible that AllegroGL already implements this functionality. I don't know for sure that it does, but it would be possible for it to support it. If it doesn't, I'm sure some help there is also appreciated.

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

No DirectDraw version has this, so upgrading Allegro's code to DirectDraw 7 would have no effect. The only way would be to replace the "DirectDraw" interface based driver by a "Direct3D" interface based one, which is the equivalent of OpenGL. Probably it would make most sense to use DX9. But it means, a complete driver rewrite is necessary. (Someone started such a driver once I think.. not sure what happened to it.)

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

Or in other words, doing the same with OpenGL would be much simplier and would work cross-platform everywhere

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, very nice, I didn't know that.

That's simply the case for memory bitmaps.. there is no DX function (well, again, to my knowledge) to blit a memory rectangle to a DX surface.

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?

CrossPlatform Issues ?

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?

Probably the original idea was to avoid overhead in the case where you do lots of direct manipulations on the memory bitmap. I think in the new API, we won't have the separation into "memory", "system" and "video" bitmaps.. it will all be managed internally. Probably with the possibility to set some extra flag if you want to override the default behavior.

[Edit:] And in my understanding, you get DX memory bitmaps as "system" bitmaps currently.

i'm trying it ...

GullRaDriel, have any luck ?

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.

It's just a global variable of type GFX_VTABLE. The element you'll want to change is
AL_METHOD(void, do_stretch_blit, (struct BITMAP *source, struct BITMAP *dest, int source_x, int source_y, int source_width, int source_height, int dest_x, int dest_y, int dest_width, int dest_height, int masked));
masked is a flag (true or false) that determines wether or not to do a masked blit or a normal blit.

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

Well in that case the code above won't work properly, but it should be easy to make something that does. This Sunday I'll try and get a working Windows/GCC install so that I can look into that + the clipping topics Neil Walker raised in the other thread. It seems that time I spent learning Windows/DirectDraw will not have been wasted.

i'm back

Any luck yet?

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 !

See my above post.

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.

Actually, stretch_blit, masked_stretch_blit and stretch_sprite all call the same do_stretch_blit(), which is actually called that in the asm version of the code; it's the infamous self-modifying code in Allegro; it's called _al_stretch_blit in the C version of the code. Neither function is exposed through the API and they're static to their respective sourcefiles (allegro/src/i386/istretch.c and allegro/src/c/cstretch.c). Pretty confusing, isn't it?
Anyway, do_stretch_blit() and _al_stretch_blit() both have

   /* vtable hook */   
   if (source->vtable->do_stretch_blit) {
      source->vtable->do_stretch_blit(source, dest, source_x, source_y, source_width, source_height, dest_x, dest_y, dest_width, dest_height, masked);
      return;
   }

So bottom line: they should all work.

EDIT: do we need a GFX_HW_STRETCH_BLIT flag for gfx_capabilities now?

Please, you seem to be both competent to modify and test those file.
I can leave you my access throught a VNC client, and you'll have all you need to do it.

Really, i think i'm not able to do this alone.

I'm not enough 'competent'

I lack a suitable operating system.

You couldn't make that an ssh remote login, could you? Anyway, I'll see about attaching a patched up file for you. in a moment.

EDIT: here you go! Replace allegro/src/win/wddaccel.c with the attached version and recompile Allegro.

i can grant you a telnet access, openssh isn't installed.

EDIT:
telnet installed, ready to receive you after a little router reboot.
Just PM me some IM where i can join you

See my above edit.

ok
i test

EDIT: it is still OK for the access, if even you wanna test yourself

This is the full patch I'm going to propose as soon as my provider's sendmail server is unblocked:

do you wanna me to post it for you ?

it's still compiling, i make a distclean before a make all

EDIT: compiled, i'm uploading the whole compiled.

Remember to change the draw_sprite code to remove the offsets when you do the stretch_blit update. I guess the mystery of the masked_blit working/the clipping code can remain so.

I don't know how often the CVS is updated but it would also be great to have a fix for it not crashing when you destroy a system sub-bitmap

who wanna test?

Download the sfx archive

It's the whole library including source and compiled version of allegro-patched

EDIT: when testing at my home, i just modify the exscale to load a pink masked pcx, and i use the masked_stretch_blit.

How can we check what does it use ? hardware or software ?

EDIT: attached is the modified exscale... i can ensure you that is it accelerated on my pc ! (now with source and modified mysha.pcx)

I can't see what the picture is now, it's too fast !

It doesn't work. I actually only tested it for the draw_sprite change, which works, but my sample code also does stretch_blit.

If you have a memory bitmap and a memory buffer all is well, if you have a system/video buffer and/or a system/video bitmap you either end up with a crash or (in the case of sub-bitmaps) instead of stretching it it actually makes the sub-bitmap bigger so you simply get a larger area of the master image!

Do you want a copy of my test program to try it, and you can modify the bitmap types easily to see?

Next time, don't! That's the point in using make: it only recompiles what it has to to safe time.

Normally I'd put printf() or trace statements in the code and see if I get output from those. That doesn't work in Windows though, so I guess you'd have to check the framerate.

Neil... please don't plug these things whenever you have a chance. Honestly, if it's know it's known. Don't start posting reminders for unapplied patches unless more than a week has passed since the last message about it or you get no feedback whatsoever. Also don't do it in threads about other topics. It's impolite.

The SVN repository gets updated whenever a patch is applied. I'm not sure what you mean?

EDIT:

That doesn't make sense. The code for stretch_blit() and the code for draw_sprite() (and masked_stretch_blit) is the same. So as far as I can see it either works, or it doesn't.

yeah, of course !

(even if we talk here of a masked_stretch_blit)

EDIT: Modified in 800x600 for Sev' attached

what you are saying is correct - none of them work when you are not using memory bitmaps, all of them work when you are using memory bitmaps. The errors you get are depenant upon whether you are using system/video for the graphics or the back-buffer or both and whether your graphics are sub-bitmaps

Attached is a test program that will show bitmaps and a stretched bitmap. The current version you see is using sub-bitmaps and memory bitmap/buffer only that works fine.

To change it to see how it crashes/fails then

To change the back-buffer edit config.xml, change graphicsmode="0" (0=double, 1=system double, 2=paged, 3=triple). Obviously 2/3 use video.

To change the graphics edit animations.xml and change bmp_type="1" (1 is memory, 2 is system, 3 is video).

It will fail in different ways when you use anything other than memory bitmaps.

After you've waded through those, rename the animations.xml file to animations.old or something and rename animations_single.xml to be animations.xml and repeat the tests. This will change the graphics from being sub-bitmaps to be individually loaded bitmaps. These have a different result again.

btw, don't worry about the crash when you use system bitmaps and buffer with sub-bitmaps. This is a known error.

Ok, I'll address the first point - all I was doing was reminding someone as it wasn't a definite CVS update, just a thread conversation. Secondly, I wasn't posting about other topics, the stretch blit problems are linked to the draw_sprite problems, which in turn are linked to the subbitmaps of system bitmaps crashing fault.

i'll try to compil it tomorrow with the modified allegro.
I test , and it is already a nice work.
I'm smoking my last before going to sleep.

See you tomorow for the tests, All.

EDIT: and for the 'windows' specific , i'm thinkin of providing a ssh access to my pc for AD. I'll keep you informed. I think i can easily provide a ftp-ssh-x11-vnc compliant access.

I've just this second modified my download file in the previous email as I included the wrong XML files, so if anyone has downloaded it before now you'll have to get it again. There is no compilation as it's a windows executable. See stretch working first then try the different modes by editing the xml files to see the new code fail.

Wait... you said

I read this as `It doesn't work, but draw_sprite works. When I use stretch_blit it doesn't work'. I don't think that's what you meant and it certainly doesn't make any sense (as I said). So do I understand you correctly if I understand that hardware accelerated VRAM->VRAM streched blits do not work for you?

Please keep it simple, or take a little more time to explain what you're doing!
Leave system bitmaps, subbitmaps and whatnot out of it for the moment as testing all of this at the same time is much, much too confusing. At least it is for me. One thing at a time. If you are doing too many things at once it just becomes too complicated and convoluted to keep track of what's going on.
All that needs to be tested in response to the patch I posted above is wether or not VRAM->VRAM stretched blits are now hardware accelerated or not.
GullRaDriel's post suggested that it works for him, I get the impression that it doesn't work for you? Have you tested his modified exscale?

Please keep the test case simple. As I said, there's far too much going on here to keep track of what's going on and what's failing and what isn't and why.

I fail to see what that has to do with saying `Remember to change the draw_sprite code to remove the offsets when you do the stretch_blit update.' The current test has nothing to do with draw_sprite. Maybe I'm missing something?

I don't see that. There are no subbitmaps or system bitmaps in sight for this thread. Anyway, if that's causing the problems you're seeing (which I'm not saying it isn't), you have a patched version of Allegro, right? Does it work properly with that?

Please try to describe in a clear, simple and concise manner if and when things work and when they don't. Don't try to test every possible case at once and if you do put some work in how you present the results (eg, make a table of the posibilities and results). As it is, I can't make heads or tails of it.

OT:

This started me thinking about possible enhancments of the X driver(s), Besides just using standard X functions, theres a few extensions that may help, though I'm not sure how much.. The XDamage extension allows you to get detailed info about damaged areas, XRender allows you to render the window to an off screen surface (and other windows as well) as well as use various rendering modes, and the Xcomposite extension works with the other two to give us fancy compositing eye candy.

I would be happy to work on integrating some of these (namely XDamage and XRender) into allegro, at least once the open source ATI drivers support XRender for my 9600xt. Though I probably won't beable to do it all myself.

Ahhh, I've found a potential problem. To cut a long story short:

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 */
      if (ddcaps.dwCaps&DDCAPS_BLTSTRETCH)
         _screen_vtable.do_stretch_blit = ddraw_do_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);
   }

A better solution would allow non-masked stretch blitting where wither of DDCAPS_COLORKEY or DDCKEYCAPS_SRCBLT are not set.

EDIT:

Yeah, the only reason I'm suddenly so up on where Allegro does what is that I've been researching improvements to the OS X driver...

Ok, how about the attached patch?
Copy it to the main Allegro directory (allegro/) and run patch -p0 < dx_stretch_blit.diff.
It should test the capabilities of the graphics card and separate the blit and masked_blit tests. The test programme should also report which of these two works (but it doesn't offer a way of testing either; that'll have to be fixed later).

ok, i'll make a simple table of what works and what doesn't with various bitmap types in windows, to try and make it easier to read. However, I don't have any CVS tools, any chance of someone doing the diff and sending me the three files or tell me where to find patch?

Do you want me to limit the tests to just stretch_blit, or include masked_stretch or (dare I say it) draw_sprite?

Will any of the pivot/rotate stretch blits be affected by the changes?

I found http://gnuwin32.sourceforge.net/packages/patch.htm. You can also get http://unxutils.sourceforge.net/ for more useful utilities, like diff, grep, sed and awk.

stretch_blit and masked_stretch_blit (or stretch_sprite). draw_sprite() is not affected by this patch so it's quite pointless to test anything with that.
Also check if the test programme lists `stretch blit' and `masked stretch blit' as hardware accelerated functions.

thanks to everyone for doing this, its fantastic !

trivia: this thread, appears in google, i was looking for something else, and this thread was top of the google results!

I've been looking into whether the IDirectDrawSurface2_Blt() can accept a alpha channel value.

Not by the current patches, but DirectDraw has the capability to accelerate this if the driver implements it. Certainly during the "classic" period of DirectDraw this was very rare, but perhaps things have changed now. I wouldn't be too surprised if modern DirectDraw isn't some sort of Microsoft generic implementation that utilises DirectGraphics, which should mean that rotation is there.

If no-one else does, I'll see if I can knock anything up for rotation/pivot/etc tomorrow.

Blt (and BltFast) certainly can't, I'm not sure if anything else exists that can which would not be too difficult to add into the existing code.

I just thought if the code for stretch_blit was being changed then maybe pivot/rotate stretch might call the same code and may be affected somehow.

Anyway, I get an error running patch. I'm using the standard 4.2 allegro source code. I get the following error:

I'll see if I can work out from the diff what the actual changes are and make them manually unless someone is reading this and responds sharpish

Zip with modified files attached [for 4.2].

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

I hit add reply instead of browse by accident. I know, they're not even close. Don't ask.

It appears that I neglected to include the display code in teh relevant location! You'll only see it reported in the logfile with the version I attached. Try the one I attacehd to this post (untested).
What you posted only says if normal blits are accelerated. It doesn't say anything about stretch_blit().

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:"

That's just weird.

I'm not at all sure what to make of these results though. Someone with Windows should have a look and try to isolate the problem. I may check if my XP64 license hasn't expired yet (I think it has), in which case I might check for myself. No promises though.

Your test is fairly exhaustive, which I'm sure will help eventually. However, you could have left out the mem->* and draw_sprite() tests since they are (should) be unaffected by the patch in this thread.

I know. I fixed it a minute after posting that but neglectied to attach the updated file.

EDIT: For the `bitmap size is wrong', I think you need to have

source_rect.right = source_x + source->x_ofs + source_width;
   source_rect.bottom = source_y + source->y_ofs + source_height;

instead of

source_rect.right = source_x + source->x_ofs + dest_width;
   source_rect.bottom = source_y + source->y_ofs + dest_height;

Please try it out and see if that helps.

EDIT2: In the test programme, add
"Mouse pointer:",
at line 1752 (before "stretch vram->vram blit:").

EDIT3:
Ok, I managed to boot into Windows after some tinkering with grub (I added a harddisk a few weeks ago and had to change some settings because of that) and apparently my licesense hasn't expired yet.
Try the following patch:

With it, the test programme correctly reports all stretch_blit related operations as being hardware accelerated. Modifying exscale to use a video bitmap (be sure to allocate a dummy one the size of the screen first) also seems to work fine.
Curiously enough, it appears to be slower on my system than if I do a mem->vram blit, except if I remove the vsync() call. Perhaps that's normal, but it's not what I was expecting. shrugs
\begin[off-topic]{rant}
How do you Windows people manage, though? I can't believe how unresponsive and klunky the interface feels and how badly the terminal works. That and not being able to trace with printf() is a real pain too. Man, am I glad I never have to use that system for anything serious...
\end{rant}

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've recompiled and done a few tests (not exhaustive, I'll do the grid later), however here are my findings with the new code posted above:

Things that work:
1. test.exe now works and shows the correct hardware acceleration flags
2. stretching of video/system bitmaps now shows the correct image rather than either nothing (for standard bitmaps) or simply resizing the bitmap (for sub-bitmaps)

So that's good.

However, the things that don't work:

1. When you are drawing stretched video/system bitmaps onto a memory buffer it still crashes
2. When you are drawing stretched single bitmaps (rather than sub-bitmaps) AND both your buffer and graphic are video (any other combination is ok, including system) it leaves a 1 pixel magenta (i.e. the mask colour) around the outline of the graphic (i.e. around the outermost pixels, not the rectangular border).

My only thought on (2) is it might be a bug in the dd function, e.g. stretching first and anti-aliasing the magenta edge? but then sub-bitmaps work ok.

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?

Maybe if you know the area of fault this might fix the problem of it crashing when destroying system bitmaps?

From memory all other permutations work, only vid->vid failed, but I'll check when I start up my laptop tonight as that's got the code on it, and do another grid.

I checked google for bugs on directdraw functions and blitting (for the magenta halo on stretching) but the only thing returned was Allegro.cc forum entries! I guess we must be the only people in the world still using DX3

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 (?)

Eh? I don't see what the one has to do with the other, to be honest!
The reason I thought it might crash is this: the stretch_blit (et al) code checks if the source bitmap says it can be hardware accelerated and if it can be it calls the function, from allegro/src/c/cstretch.c:

   /* vtable hook */   
   if (src->vtable->do_stretch_blit) {
      src->vtable->do_stretch_blit(src, dst, sx, sy, sw, sh, dx, dy, dw, dh, masked);
      return;
   }

while ddraw_do_stretch_blit does not check what sort of bitmap the destination is. Which I figured might be a problem if it's not a video or system bitmap, since that's what it's supposed to work with.

So the questions I'd like to know the answer to (just yes or no) are:
1) Does normal blit frim vid->mem work, even if vid->vid is accelared? (Asking because the code should be similar)
2) Does the old non-accelerated stretch_blit work properly if you go from vid->mem? (Asking because it immediately highlights the problem and suggests a way to fix it)

I don't think they are. If there's no function that does that in src/win/wddaccel.c then it isn't. If you need the vtable function name and prototype and haven't found where they're declared yet, they're in allegro/include/allegro/gfx.h in the GFX_VTABLE struct. If you want to take a shot at doing this, let me know. The plan is to release 4.2.1 soonish but I think we can puch it back a little for something like this.

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.

Ok, so vid->mem stretch blits crash with the hardware accelerated code. Does it work without (ie, did it work properly with the software stretcher)?
Did you test regular blits?

Shouldn't that lose the `!'?
You want to use that function if both source and dest are video surfaces (or possibly system bitmaps) and fall back on the original if they are not.

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.

Well, I'd prefer being able to detect it (somehow) and not report the accelerated blit as being possible, or work around it. What the code does with your change is always fall back on software stretching despite claiming that vid->vid is accelerated. This is worse than it is now.

Ok, so we can check if the destination bitmap is a video bitmap and use the software stretcher in that case?

Ok, in that case I'll have a look at how standard blits deal with vid->mem blits. I'm assuming they do something special if the accelerated vid->mem stretch_blit crashes.

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.

There's the outside possibility of an issue with clipping, that I vaguely alluded to before. Did you make a note either of the values of dest_rect and source_rect or of the parameters you passed to stretch_blit to make it crash?

You might as well post - I might get a go on a Windows machine later.

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?

Not nescessarily. To the best of my knowledge normal Allegro memory bitmaps don't have a DirectX drawing surface associated with them, so based on that idea (which I don't actually know if it's accurate or not) I would expect that code to crash if given a memory bitmap. I should have taken a little more time to explain what I was thinking when I asked if normal blits work.

The ddraw_stretch_blit and ddraw_blit functions are virtually identical, which suggests that the problem is not in there, but in blit() or stretch_blit() itself. What I was thinking is that maybe blit() checks if the destination surface is also a video bitmap before calling the hardware accelerated function. I know stretch_blit() does no such test and if that's the difference it can account for the one crashing and the other not.
Checking if this is really the difference is something I could do fairly quickly later on just by having a look at the source for blit().

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?

MPW is Macintosh Programmer's Workshop - it was Apple's IDE for development on Mac OS 'classic' i.e. version 9 and earlier. There was a partial Mac port but IIRC it was never complete. Any MPW code is obsolete now, of course.

Pete

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 depends: the code on src/c is compiled if Allegro is compiled without ASM code (it's the code that's always used when not using an i386 or compatible computer), the code in src/i386 is used when Allegro is compiled with assmebler code. The stretch_blit code is a bit of self-modifying code, which is sortof neat but also quite evil.
Both need to be fixed, but see below.

Yes. Actually, when I think about it this is the proper way to do it: this bitmap type (each bitmap type, memory, system and video, has its own vtable) has a dedicated special-purpose function that knows how to do stretch_blit better than the general purpose code. I feel that stretch_blit() itself should not try to guess when the vtable function should or should not be used. Instead, the vtable function should fall back on the software blitter in case it decides that it cannot use hardware acceleration. In this sense, I think blit() is at fault from an object-oriented point of view, but we'll leave it as is for 4.2.
So I think the proper fix would be to add

if (is_memory_bitmap(dest)) {
   _orig_stretch_blit(source, dest, source_x, source_y, source_width, source_height, dest_x, dest_y, dest_width, dest_height, masked);
   return;
}

to ddraw_do_stretch_blit before the first check.
Alternatively, only call the vtable function when dest is not a memory bitmap, but as I said, I think the check should be in the special-purpose function.

Yeah, we should probably remove it as we go. I don't think it ever actually worked anyway.

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?

That doesn't make sense if the original version worked. Does it also crash if you remove the vtable check and call?

The DirectX driver sets the vtable entry for do_stretch_blit() in the video-bitmap vtable to the DirectX hardware accelerated version.
When stretch_blit is called, it checks if the source bitmap vtable has an entry for do_stretch_blit() and if it does it calls it and returns, otherwise it calls the general-purpose software blitter.

That would be correct.

Have you disabled vsync?

If you're right it does make sense, but not because of speed gain. I would be highly surprised if that were measurable.

Not cleanly, no (hackishly, you can change the vtable manually in user code). You can switch to a non-hardware accelerated driver (the DX soft one; it's the same as the regular DX driver except that it doesn't activate any of the accelerated features).

You cannot change the flag. The gfx_capabilities are logically read only and should never be changed from user code.
In general, it wouldn't have any effect anyway (the functions should only be called if the flag is set, otherwise it's a bug in Allegro). For do_stretch_blit() I believe the flags are checked, but that is certainly not the general case.

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?

Ok, proposed patch attached. It's basically the same one as the previous one except that the accelerated function is never called if the destination surface is a memory bitmap.

I highly doubt it; moreso because the likely case is that the function does work properly. But if you can show some benchmarks that clearly show an improvement, then by all means share them!

sorry to appear like a complete moron, but i got somewhat lost in all the above banter, it all sounds good thou!

can you tell me: Does this patch do Vram->Vram accelerated bliting?

as far as i can decipher, some problem occured that has left it in a "depends on your grafix card" answer... which (vram-> sys-> mem->) acceleration is working, and which ones are "depends on your gfx card" ?

No, that's been in there since... forever.
It does do hardware accelerated vram->vram stretch blits though.

All of them, in principle. Some cards may have issues with {sys,vram}<->{sys,vram} blitting, but that's something someone else will need to look into to work around or fix.

sorry; thats what i meant; accelerated vram-vram strech blit... that is fantastic news, well done everyone.

It's done accelerated vram-vram for a while AJ, just there kept popping up new errors as I've been testing. This last fix, was to stop it from crashing when you mix memory and system/video bitmaps.

Thanks, Evert, I'll try the code tonight, I've been busy decorating to try much the last few days.

Once it's all working I was planning on doing some benchmarks on the various bitmap types (memory, system, video) and see how they cope under light and heavy stressing and how they work using different combinations (e.g. vram->memory, system->bitmap, etc).

Neil, not sure if you've been following my other thread
http://www.allegro.cc/forums/thread/560858
i have some SSE2 code that im trying out for mem->mem blit that is fast, and the rectfill stuff too.

I'd be very interested in seeing your benchmark results.
espeacially showing different stress levels.

That code change works, Evert, check the code in there are zero bugs for all permutations
:):):):):):):):):):):):):):):)

The only thing that doesn't work is the odd halo effect on vram-vram stretching. Thomas seems to think it is a bug. However, a bug is a bug is a thing that won't work for people. What to do?

Anyway, attached is a windows alleg42.dll (and updated gfx.h) if anyone wants to use the new accelerated stretching and correct destruction of system sub-bitmaps.

Neil, is this vram->vram stretching halo thing look bad ?

Yes. Do you want me to attach an example program showing it? It could be a good test to see if it is on some machines only.

Either way, it sort of defeats the object of accelerated stretching when you can't stretch vram-vram!

attach the example neil, i'll have time to test.

Attached is almost everything you need and it will start by default with video buffer (paging) and store the bitmaps to show as video.

On running you should see the larger three ufo's and they should have a magenta edge to them. The full magenta one is fine as that is a stretch_blit. The little sprites to the right should be fine as they aren't stretched.

The top line should also state that it is in paging mode. If it doesn't and says double buffer, it means creating screen video bitmaps failed.

Also, if you do not get the effect, press ESCape and open up the produced 'animation.log' file. You should see an entry that says how the graphics were created, i.e.

normal: Animation Frame Constructor: sheet.bmp
normal: sheet.bmp Image: 0xacc3c0
normal: Bitmap wanted to be Video
normal: Got video

Now, to see it working properly, edit the config.xml file and change the entry: graphicsmode="2" to graphicsmode="0". This will change the buffer from video paging to memory double buffering.

If you want to see how other permutations work you can change this to 1 for system double buffering, 3 for triple buffering (though you will have to change the 'autodetect' to 'fullscreen'), and you can edit the animations.xml file to change teh actual bitmaps, i.e. find the global/bmp_type and change it from 3 to another value. 1 is memory, 2 is system, 3 is video.

I don't see the wrong pixel, even in fullscreen mode.

animation:

animationslogdebug:

config:

Test log only says started and finished :p

Do you see something anormal ? do you wanna me make some test with special graficmode || bitmap value ?

It's my understanding that the purple outline is a DX bug that may or may not show up on your system.
Maybe there's something like anti-aliasing or smoothing that can be switched off to get it to work properly?

It seems then that the 'this feature is card specific and may or may not work as expected' property of the stretch function is active, i.e. it may or may not work on all computers. Maybe more people testing would help? Either way, do we (i.e. the Allegro coders) need to address this? maybe a flag in the stretch function to say whether to use accelerated stretching? This fault was found by Thomas Harte in a DX forum so I can't be alone.

I can't seem to find any old DX reference guides to look for any disable anti-alias type flags.

I've got a GeForce 5200.

As an aside, this line seems odd though (its a call to get refresh rate):

system returned the refresh rate as 59

I thought all monitors/displays would return the usual 60, 70, 72, 75, 85, etc.

I got a laptop. It's the refresh of the LCD screen, i can force it to 60 if you want.

I got a GeForce FX 5700 go. (maybe it can help to know where is the problem)

Can it be a driver issue ?

Have you test rolling back your drivers ?

You mean, DX may or may not support it properly despite claiming that it does?

Maybe.

I say we (as in the developers) should do `something' with this. Either we need a reliable way to detect if the bug will show up or not, or we need a way to work around it. There might be some settings you can pass to DX (having to do with things like anti-aliasing or smoothing) to make it behave sanely. That, however, is something that someone who is using Windows will need to investigate and look into (as in, I'm not going to do it any time soon).

Right now, I think the code is such that you actually can disable it by masking it from gfx_capabilities. This is a hack though and if it works at all it's more by accident than a feature. There is no way in Allegro for the user to specify that he wants to use acceleration for some functions but not for others.

Windows and DX versions are probably relevant too.

OK so,

It is working under my WindowsXpPro SP2,DirectX 9.0C

Grafic Card: GeForce Fx 5700 GO with 6.14.10.6212 drivers from nvidia.

I've got dual boot XP, one with SP1 and one with SP2, one with DX8 and one with DX9 and they both fail. Sadly I can't try a different GeForce driver as I'm limited to what Toshiba supply.

It would be nice, however, if Allegro let you choose displays (will this ever be a feature?) as I have two outputs but allegro always forces itself to the primary display, I could then try it with a different video driver as each display has it's own driver installed (though fair enough the same card).

Nah, it got nothing to do with the test, it just seemed odd that your laptop is saying 59 and not 60.

Working nice on my WindowsXpPro SP1 Directx9c , Intel 8215G Express

I've had it tested on:
Integrated Intel 82852 Graphics Controller
GeForce 7800 GTX
ATI Radeon X800XL

and they all work too.

hmmm perhaps more a driver issue than a specific card or other.
Can you give me a link where i can download your non-working card drivers ?

Firstly, someone tried it and it failed (hurrah, I'm not alone!). It was a NVIDIA Quatro NVS.

I changed the Windows display property/'Troubleshoot' option to disable all DirectDraw accelerations and it worked fine. It still created and used video bitmaps though. Sounds like a bug in something or other to me

Anyway, It is a GeForce FX go5200 (i.e. the mobile version of 5200 series). The problem is I've tried downloading the latest from nvidia but it crashes my computer so I don't know whether it is a modified driver for the Toshiba M2 I've got or they've kept using an older driver because of bugs. Anyway the version I use is:

http://support.toshiba-tro.de/tools/Tecra/tm2/display-tm2-4644.zip

According to the property page, it is version 6.14 of the driver.

Humpf. Have you tried to use one laptopvideo2go.com drivers ?

Try download one of them , you can found them there

And this topic
seems to be helpfull for your grafic driver.

Searching in the forum gave me this link where i found latest modded GeForce FX 5200 drivers

i just tested in on a Nvidia Geforce4 MX 440 AGPx8 desktop. AMD64
DX9.0c and it looks fine.

i also then tried it on my laptop:
Nvidia Geforce4 4200 Go (Dell Mobile) AGP x4 64MB
on a Pentium M.

and it looks fine, no halo, no purple crap anyway; looks good !

also tested an Geforce2 MX 100/200 and it was fine.

I think this effect is visible in OpenGL with alpha channel rotated quads (at least it's visible in OpenLayer). I think Flad is going to add a function to preprocess the image to expand the edges so the edge blends to the normal colour rather than purple.

Would it not be possible to use something like this as a fallback option?

No, the problem with DirectDraw is that it doesn't seem to support an alpha channel, so the same fix doesn't work. If pixel colours are changed then they simply cease to be transparent. DirectDraw allows an arbitrary range of numerically contiguous colours to be transparent but unless the sprite has a fairly consistent edge colour I can't see how that can necessarily be much use. If the comparison allows for non visible parts of pixels, I guess we could use the unused space in 15 and 32bpp modes to produce an on/off alpha channel and recolour neighbouring pixels for an OpenLayer type effect.

In terms of figuring out when there are potential problems, presumably nobody sees any "purple crap" in 8bpp mode?

FUCK ME WITH A LARGE BARGE POLE!

Thanks gulladriel, I downloaded the nvidia update with the special 'modded inf' file to get the standard drivers to work with laptops, and it works

So this thread can now be closed and we can lead happy allegro lives again.

The only odd thing, and hopefully someone can explain, is now when I use paging or triple buffering instead of the usual immediate start I get a black screen for maybe 3 seconds before anything starts?

Ok, so we can just tell people who get a purple outline when using the accelerated stretch_blit() to upgrade their drivers?

Yep. Hurrah

Any thoughts on the long pause? I'll try a few of the settings, maybe it has some crazy DX settings for optimising the display, or maybe it died of shock finding something that still used DX3

The only think i know is that with some modded drivers, i experienced problems using opengl. I try other ones, and it was OK. I sometimes got those black-screen too.

If someone have some test to make for solving or finding what can cause this, i think this is the right thread.

EDIT: Evert ++ , I'm OK to say that with or without a black screen, when there is the pink border, they should try to upgrade their drivers. If it don't work, try downgrade them. I'm ok it seems to be silly. But drivers have sometimes these 'MagicPowaYouDontKnowWhatTheDriverDeveloperHasSmokeBeforeWork.'

Fiou.

Gull ;-D

I'm glad most (all?) of the remaining issues with this code seem to be clearing up. Now it surely is time to get accelerated rotations and flipped sprites in there! Any chance of at least getting flags for these things in 4.2.1? How far advanced is 4.2.1 anyway? There seem to have been at least a couple of genuine bug fixes since 4.2.0 so presumably the plan is a new code lockdown and release sooner rather than later?

Well count me out for testing, I've done my national service and want my life back

I can see the point for accelerated rotation, but not flipping. Care to give some useful examples?

I've probably not been clear - I mean acceleration draw_sprite_v_flip and so on. So a benefit is keeping your sprites in VRAM and having the ability to make them face the other way without hugely expensive VRAM reads and writes. And more hardware acceleration generally.

If I'm not mistaken, support for rotation and flips would mean that the entire Allegro sprite/bitmap functionality can be farmed out to hardware on Windows if the hardware is present - for the first time ever.

I also want to at least investigate Core Image in OS X v10.4 onwards as it looks, without any in depth investigation, as though it could do the same on that OS without the work of an OpenGL implementation which, for example, requires a lot of effort if you want to blit from one video bitmap to another where the latter isn't the screen and/or the former is.

id like to see 421 out sooner than later; if its going to contain this new accelerated stretchblit code.

I think I was supposed to pack it up for internal beta testing last week, but I was more or less waiting for this to settle down.
I'm planning to wrap up this weekend and get some people to stress-test it before public release (adding acceleration doesn't count as a bugfix, so we're bending the rules a bit by including it in 4.2.1, but since 4.3 is a very different beast anyway and it's such a useful thing to have, it'll be in there).
I'll also have to see if the release system works properly with the new SVN-based repository; that's something I haven't really looked into yet.

That's what I meant Thomas, I just can't think of many examples where I'd want to flip images.

I can't think of many individual examples but if you take just the example of a character in a 2d platform game and multiply it by the number of Allegro users who attempt or produce a work featuring that example it becomes a quite significant use.

Anyway, it's easy enough to add where supported - certainly easier than rotation because it can just be an extra flag to the existing stretched and non-stretched blitters, as all it is to DirectDraw is an extra flag - so I think it's worth writing the code for. Almost certainly not in time for 4.2.1 though!

i think alpha blitting, or anti-alising would be a better next feature

But DirectDraw can't achieve either of these, whereas flipping/rotating is quite easy to add.

cough*AllegroGL*cough

I'm sure the OpenGL driver would appreciate having that ability, then it can be benefitted by all platforms.

Is that a limitation of DX3? I think DX7 can do it.

After I read yesterday in the MSDN, I felt to be able to add the accelerated sprite flipping to allegro.
The result is a new version of wddaccel.c with accelerated draw_sprite_v_flip, draw_sprite_h_flip and draw_sprite_vh_flip (see attachment for the .diff file).
It seems to do, what it have to do, but after I tested the sprites per second, it seems to be not much more faster than before (ca. 11.000.000 sprites/s MEM->VRAM, 17.000.000 sprites/s VRAM->VRAM), but it is faster.
After I made a draw_sprite_*_flip from a VRAM sprite to the screen, it was extremly slow (only 500 sprites/s!!), but flipped sprite drawing on offscreen VRAM->VRAM is fast (17.000.000 sprites/s). Has anyone an explanation for this ?
I don't know, if the code is really bugless, so can somebody test it?

@ A J:
DX7 doesn't support alpha blitting, there are entries in the DDBLTFX struct, but they are not implemented in the Blt function.

Looks good!

Could this be a vsync() issue? Try to run without using vsync if you haven't already tried that and see if that helps.

Whats the minimum DirectX for the new allegro graphics API ?
Will it be DX7 ?

Ohh, forget what I have said about the speed of my sprite flip routines. There was an error in my test program.
The new results disappoint me, here is a list I made during the test:

old v_flip      from -> to        new v_flip    accelerated blit
(sprites/s)                       (sprites/s)
13400           RAM -> VRAM       13400         no
24000           SYS -> VRAM       7400          yes
370             VRAM -> VRAM      370           yes
60000           RAM -> SYS        60000         no
60000           SYS -> SYS        36000         yes
350             VRAM -> SYS       350           yes
70000           RAM -> RAM        70000         no
70000           SYS -> RAM        70000         no
360             VRAM -> RAM       360           no

this results were made with a 64x64 sprite on a 640x480x32 screen using the debug version of the stable allegro 4.2.0 (with my changes).
With some trace statements (in MSVC7 it works) I got a message, when the sprite flip entered my function and when it did the directx or the original blitting.
"yes" under "accelerated blit" means, that the function uses the directdraw Blt function. If the Blt function crashes, there will be no sprite blitted. But it blits a sprite with the right effects (v-flipped), so the Blt function works correctly.

So it seems I have made a "decelerating" routine for the sprite flip

What could be wrong???

I can't imagine, that the VRAM->VRAM flipped blitting is in directdraw as fast as the software functions from allegro.

How are you testing things (post your testing programme)? You're not acquiring the screen before blitting to it, are you?
EDIT: Also, make sure that your function is called, eg by having it print some output.

Why not post your test code then we can all test it?

Apparently you can dump DX3 and move straight to DX9 with the current version
http://www.gamedev.net/reference/articles/article2283.asp

OK, I wrote a new more clearly test program, where you can test the v-flip (for the function timeGetTime() you need the winmm.lib):

no, I don't, I never used this function acquire_bitmap before. If I use this in my test code, there aren't any speed changes, but it is possible, that I used it on the wrong bitmap (the target vram bitmap, I think) or at the wrong time (every time I blit?)

After the line, where the DirectDraw blitting is executed, I print out the result of the Blt function with a trace statement. The SYS->VRAM, VRAM->VRAM, SYS->SYS and VRAM->SYS are blitted by the DirectDraw Blt function.

Good. You shouldn't acquier anything if you're using hardware acceleration.

I know it's all relative and such, but that code isn't representative of real blitting or a real program as you are just chucking out tiny sprites between each other and not onwards to the screen or another buffer.

Perhaps a better test would be to blit a large number to a proper buffer and time it there, for example if you're using VRAM for your sprites you're more likely using paging/triple buffering whereas with a memory buffer you're going memory all the way.

You're right, I tested the MEM, SYS and VRAM blitting to the screen and the SYS and VRAM blitting is now much faster.:)
I tested it on another PC and especially the VRAM to VRAM blit is very fast related to the old software routine (more than 5x faster than memory blitting to the screen and 32x faster than the old VRAM->VRAM blitting). The source sprite is the same 64 x 64 pixel bitmap.
I don't know, why my computer was so slow in VRAM->VRAM blitting, perhaps because I have installed the DirectX SDK and had configured DirectX as a debug or software (without hardware acceleration) version.???

EDIT: I tested this at home again, but there it runs as slowly as in the allegro software functions (and slower). I think my DirectDraw acceleration is broken (perhaps a bug in the nvidia drivers or a wrong option in the DirectX SDK).:(

which DirectX SDK have you got ?

DirectX 9.0 SDK February 2005.
But the settings for DirectDraw are right, I think, because the hardware acceleration is enabled. In the "DirectX Caps Viewer" under "BLT Caps" the FX "DDFXCAPS_BLTMIRRORLEFTRIGHT" and "DDFXCAPS_BLTMIRRORUPDOWN", which are nessecary for vertical and horizontal flipped sprites, are hardware accelerated for System -> Video, Video -> Video, System -> System and Video -> System.

does this "DirectX Caps Viewer" under "BLT Caps" mention Alpha blitting ?

I didn't find anything about that.
But I think it is not implemented in DirectDraw and will never be, because the last version is from DirectX7.
In the MSDN library there is a documentation to the IDirectDrawSurface7::Blt function. That is the newest and last version of DirectDraw Blt:

you can find it under http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/ddraw7/directdraw7/ddref_4b7b.asp
If we want hardware accelerated alpha blending (and many more accelerations), we have to update the DirectX driver of Allegro to DirectX9 (from DirectDraw -> DirectGraphics). Then we have a simulated 2d screen on a Direct3d-Interface, which supports hardware accelerated alpha blending and I think, also hardware accelerated primitives (circle, line etc.)

Do you see any issues with allegro using DX9 ?

I don't see any. Evert might, no idea.

What's the point in going down the DX9 route, I thought by the time this would become a reality, allegro will be OpenGL. Or is this a bad thing now Vista is looming?

I'm sure to have rode somewhere that Vista will 'pipe' OGL to his own grafic handler, so we'll loose some speed.

The whole GL/Vista issue is MS's idea of "fair play". I recall hearing from a reputable source that NVidia had a working composite driver for Vista that worked allong side GL, and didn't hurt either's speed, then MS locked them out, and forced everyone to "do it thier way".

There is no valid reason why GL on Vista should be slower than DX.

With this roadblock in place for GL, allegro will need a DirectGraphics and/or Direct3d driver.

I don't see why. There's about a million other things Allegro does in software that could be done in hardware if there were an API change and everybody has seemed "happy" so far. Here on OS X everything is done in software despite a flawlessly supported OpenGL driver.

Of course, nothing is needed. Still, as much performance as possible should be one of the design goals - so we may wish for such a driver at least - if it gives better performance than a software or OpenGL one.

Actually, what I think Allegro needs is good platform-independent code (for the same reason that the assembler code should go). Something that the people who actually work on Allegro can work on and debug and which will actually work in Windows.

I'm not saying that it'd be pointless to have a DX 9 or D3D driver, but unless someone is interested in writing one, it's just not going to happen.

Is there any tutorial for writing a gfx driver (how the driver have to be connected to allegro)? At present I'm learning, who to use Direct3d for 2d games and I'm interested in writing the driver, if I am ever practiced enough.
I had a look at the current DirectDraw driver and tried to understand the driver management of allegro. I think, I have understood the most, but I'm not sure, if I understood all, e.g. how to add the driver to the global driverlist.

But back to my hardware accelerated draw_sprite_*_flip().
After I updated my test program to make a "real" test (blitting to screen or a screensized system and memory bitmap), in comparison to the old software function my hardware accelerated function was much faster in SYS->VRAM and about 32x faster in VRAM->VRAM blitting (see my last posts).
So the code works, but this is my first patch for Allegro, so what have I to do now, that this code will be taken up in future Allegro releases?
I read the ahack.htm and found this:

I have already published the code in this thread (and it has not changed since the post). Must I send a copy- or diff-file to the allegro developers mailing list, too?

Just posting here should have been enough - Evert is definitely a developer and I believe Elias is too, so your patches should make their way into the main release code. Whenever I've had a bug or patch to suggest, posting here seems to have accomplished the right effect.

I think most of us also have an e-mail subscription to the Allegro Development forum (whence my frequent requests for moving threads that are off-topic here to another forum). All the same, I will post and send the patch on the mailinglist before applying it. I'm not sure if everyone on the mailinglist reads the forums (it certainly wasn't so in the past) and besides, the mailinglist is a bit easier to keep track off: threads don't get distracted so much and if they do someone will usually change the topic description.
This second patch, for instance, should really be posted and discussed in a separate thread. The reason is that this makes it easier to keep track of where the patch is posted and which version supersedes which. This is a bit more cumbersome with the forums, even in the e-mail form.

Long message short: if you feel like posting the diff on the mailinglist, please do (be sure to hang around for questions and comments). If you don't, that's ok too, but it'll take a bit longer for the message to get posted there and applied.

As for applying it - I'll have to be sure all things were properly tested. Have you tried things like VRAM->MEM blitting with this patch applied? Does that work as expected?

Thats good to hear we have someone intested in writing a DX9 driver.

As for the asm code in allegro, which routines need re-writing?

I've made several attempts at writing stretch_blit and blit in C, and now also blit in SSE2.

i noticed in iblit32.s there is a #ifdef ALLEGRO_SSE
so perhaps adding #ifdef ALLEGRO_SSE2 can also be done

There is a big difference between DirectDraw and DirectGraphics (Direct3D), so I have to write a new driver and all routines, which are implemented in the directDraw driver need to be re-written.

I testet all 9 blittings (VRAM,SYS,MEM->VRAM,SYS,MEM) and after the test I blitted the system and memory destination bitmaps to the screen to see, if they are working correctly. The routine is working correctly (it draws flipped sprites) with all variations. If no hardware acceleration is supported for one variation, the routine calls the original routine (like the other ddraw_* routines). If the destination bitmap is MEM, then draw_sprite_*_flip does not call the ddraw_draw_sprite_*_flip routine anyway.

AFAIK, all of them. The "Plan"™ seems to be just to dump all ASM, and use C equivelents, as your average compiler generates better code for most processors than the current asm. Its also more portable.

are all ports going to drop ASM ?

does any of the mac code use ASM ?

how about the DJGPP port.. or is the DOS support going to get finally dropped ?

That's the idea.

No. Only 32 bit Intel ports use ASM code (well, there is some in the AMD64 port, for cpuid mostly).

Hasn't this been answered ten times already? If no one updates the DOS port to work with the new API, then it's effectively dropped when it stops compiling and no one can be bothered to fix it.

i've done some more stretchblit in C code, and im struggling to match the asm codes speed. even with cache instructions, althou there is no specific instructions that really assist in stretching.

Has anyone had any luck writing stretch_blit in C ?

What do you mean? Allegro comes with a C version of stretch_blit (otherwise it wouldn't work at all on non-Intel machines)... obviously someone has had some luck...

Allegro uses self-modifying code to stretch sprites on Intel machines (more accurately put, it assembles a piece of code in memory to do the stretching and then calls it). I can imagine that that can still be an efficient way of doing it on modern machines (even if the code generated is i386 oriented).

[quoete]althou there is no specific instructions that really assist in stretching
</quote>
You could use the vector unit to calculate source positions for four pixels at a time rather than one, which would hopefully bring you closer to the inevitable memory bandwidth bottleneck.

You also probably need to invent fairer tests. I have informally found that the most obvious C implementation usually beats stretch_blit for horizontally thin outputs, outputs that are shrunk vertically and the special case of outputs that are only one row high.

Evert, my entire post is one statement, i wasn't expecting to have individually sentences picked apart, reading the post backwards takes it out of context.

Thomas, the tests i've done, were i build the stretcher first and then apply it to the image, building the stretcher is a trivial amount of time, its the only place i can see the possibly use for vectors to calcuate the positions, and im not so sure it would be worth the swizzling overhead for such a trivial part of the equation.

Im keen to have the asm code removed, but i'd also like to replace it with something as fast or better.

I thought I'd structure my reply in such a way that I could individually comment on the things I have questions about. I also thought that I'd just put the quick question in front, before the one where I would put a bit more discussion or clarification to what I was saying. But if you prefer it the other way around (and you might bother answering the question this time):

Allegro uses self-modifying code to stretch sprites on Intel machines (more accurately put, it assembles a piece of code in memory to do the stretching and then calls it). I can imagine that that can still be an efficient way of doing it on modern machines (even if the code generated is i386 oriented). And what do you mean be `luck making a stretch_blit in C'? Allegro already has one; have you looked at that?

By the way, as this has nothing to do with the original topic (VRAM->VRAM accelerated stretch blits), I'd prefer the discussion be moved to its own thread to make it easier to track.

I mean, has anyone made a stretch_blit in C, not asm, that can compile on all the supported compilers, and is as fast or faster than the current asm stretch_blit code ?

It has? where?
Im confused, as when i asked "As for the asm code in allegro, which routines need re-writing?" i didn't get a specific answer, but i did get a hint "Only 32 bit Intel ports use ASM code"

Getting a straight answer seems to be really difficult, so all i can do is ask lots of questions; and pick apart a few answers to try to establish what is going on, and at the moment, it seems that there is consensus about droping the asm code ASAP, in favour of C equivalents. I can't establish the current state of that work, for direct and specific questions like "As for the asm code in allegro, which routines need re-writing?", the answer i got was "all of them".

As i have already written a fast SSE2 blit, and we all seem to be in agreement about memcpy() being a suffecient blit replacement; i thought i might try asking about the status of stretch_blit and wether anyone had written a C equivalant of it.

i'll obviously answer when i could be bothered

A J, Evert is trying to say that Allegro already has a C version of stretch_blit, which is used in all platforms except for the x86 CPUs. You can use that as a base trying to develop a possibly faster version.

allegro/src/c/cstretch.c

Well, what are you asking? What routines need to be rewritten in C because there's only an ASM version of the code? or If I want to make more efficient ASM code routines, which routines should I rewrite?
The answer to the first question is none, or else Allegro would not work at all on non-i386 machines. The answer to the second question is probably `all of them'.

Yes. The main reason being, if and when things are changed in the API, we don't want to simultaneously be developing an ASM and a C version of the code. We need the C version anyway, so let's stick with that, at least for now.

Did you submit a patch for that?

Yes, of course someone has - or Allegro would not work on non-i386 machines.
Now if you can optimise it more than it is now, that would be great. Personally, I can't even test it against the ASM code, so I have no idea how much slower it is (if at all).

Well, I assumed you were aware that Allegro works on non-Intel machines (G4/G5 Mac's, say), so I assumed you were aware of the Allegro C-only port. If you weren't, fair enough. If you were, I still don't understand your question.