Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » DirectX VRAM-VRAM accelerated stretch blit

This thread is locked; no one can reply to it. rss feed Print
DirectX VRAM-VRAM accelerated stretch blit
Thomas Harte
Member #33
April 2000
avatar

Quote:

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?

Neil Walker
Member #210
April 2000
avatar

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?

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

Evert
Member #794
November 2000
avatar

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

Neil Walker
Member #210
April 2000
avatar

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 ;)

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

GullRaDriel
Member #3,861
September 2003
avatar

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

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Thomas Harte
Member #33
April 2000
avatar

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?

Neil Walker
Member #210
April 2000
avatar

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?

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

Thomas Harte
Member #33
April 2000
avatar

Quote:

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.

A J
Member #3,025
December 2002
avatar

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

___________________________
The more you talk, the more AJ is right. - ML

Evert
Member #794
November 2000
avatar

Quote:

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 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.

Neil Walker
Member #210
April 2000
avatar

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

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

Thomas Harte
Member #33
April 2000
avatar

Quote:

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!

A J
Member #3,025
December 2002
avatar

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

___________________________
The more you talk, the more AJ is right. - ML

Thomas Harte
Member #33
April 2000
avatar

Quote:

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.

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

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

cough*AllegroGL*cough

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

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

A J
Member #3,025
December 2002
avatar

Quote:

But DirectDraw can't achieve either of these

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

___________________________
The more you talk, the more AJ is right. - ML

Jens-Michael Kuhn
Member #6,298
October 2005
avatar

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.

Evert
Member #794
November 2000
avatar

Looks good!

Quote:

After I made a draw_sprite_*_flip from a VRAM sprite to the screen, it was extremly slow (only 500 sprites/s!!)

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

A J
Member #3,025
December 2002
avatar

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

___________________________
The more you talk, the more AJ is right. - ML

Jens-Michael Kuhn
Member #6,298
October 2005
avatar

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.

Evert
Member #794
November 2000
avatar

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.

Neil Walker
Member #210
April 2000
avatar

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

Quote:

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

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

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

Jens-Michael Kuhn
Member #6,298
October 2005
avatar

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

1#pragma warning( disable : 4312) //ignore the warnings in alconfig.h and draw.inl
2#include <allegro.h>
3#include <winalleg.h>
4#include <mmsystem.h> //for timeGetTime() routine
5 
6int main(int argc, char *argv[])
7{
8 BITMAP *sourcemem, *destmem; //memory testing bitmaps
9 BITMAP *sourcesys, *destsys; //system testing bitmaps
10 BITMAP *sourcevram, *destvram; //video ram testing bitmaps
11 DWORD startTime, endTime; //time before blitting and time after blitting
12 unsigned spritesDone = 0; //the sprite blit counter
13 // init allegro
14 allegro_init();
15 install_keyboard();
16 // switch to 640x480x32
17 set_color_depth(32);
18 set_gfx_mode(GFX_AUTODETECT_WINDOWED, 640, 480, 0, 0);
19 // create bitmaps
20 destmem = create_bitmap(64,64); //memory bitmap
21 sourcesys = create_system_bitmap(64,64); //system bitmap
22 destsys = create_system_bitmap(64,64);
23 sourcevram = create_video_bitmap(64,64); //video bitmap
24 destvram = create_video_bitmap(64,64);
25 // load test image
26 sourcemem = load_bitmap("fliptest.tga",NULL);
27 // and copy it to the other sources
28 blit(sourcemem, sourcesys, 0, 0, 0, 0, 64, 64);
29 blit(sourcemem, sourcevram, 0, 0, 0, 0, 64, 64);
30 // get time before blitting
31 startTime = timeGetTime();
32 // start blitting
33 do
34 {
35 // here is the test loop. Uncomment the function you want to check and comment the other draw_sprite_v_flip functions
36 
37 draw_sprite_v_flip(destvram, sourcemem, 0, 0); // RAM -> VRAM
38 //draw_sprite_v_flip(destvram, sourcesys, 0, 0); // SYS -> VRAM
39 //draw_sprite_v_flip(destvram, sourcevram, 0, 0); // VRAM -> VRAM
40 //draw_sprite_v_flip(destsys, sourcemem, 0, 0); // RAM -> SYS
41 //draw_sprite_v_flip(destsys, sourcesys, 0, 0); // SYS -> SYS
42 //draw_sprite_v_flip(destsys, sourcevram, 0, 0); // VRAM -> SYS
43 //draw_sprite_v_flip(destmem, sourcemem, 0, 0); // RAM -> RAM
44 //draw_sprite_v_flip(destmem, sourcesys, 0, 0); // SYS -> RAM
45 //draw_sprite_v_flip(destmem, sourcevram, 0, 0); // VRAM -> RAM
46 
47 spritesDone++; // count the blits
48 }
49 while (!keypressed());
50 readkey();
51 // get time after blitting
52 endTime = timeGetTime();
53 // print the result on screen
54 textprintf(screen, font, 0, 0, makecol(255,255,255), "%d sprites in %d milliseconds: %f sprites/s", spritesDone, endTime - startTime, (float(spritesDone)/float(endTime - startTime))*1000);
55 // wait for a pressed key
56 do {}
57 while (!keypressed());
58 // destroy bitmaps
59 destroy_bitmap(sourcemem);
60 destroy_bitmap(destmem);
61 destroy_bitmap(sourcesys);
62 destroy_bitmap(destsys);
63 destroy_bitmap(sourcevram);
64 destroy_bitmap(destvram);
65 // shut down allegro
66 allegro_exit();
67 return 0;
68}
69END_OF_MAIN();

Quote:

You're not acquiring the screen before blitting to it, are you?

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

Quote:

Also, make sure that your function is called, eg by having it print some output.

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.

Evert
Member #794
November 2000
avatar

Quote:

no, I don't, I never used this function acquire_bitmap before.

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

Neil Walker
Member #210
April 2000
avatar

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.

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie



Go to: