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?

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

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?

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.

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.

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!

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

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

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.

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.

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

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