|
DirectX VRAM-VRAM accelerated stretch blit |
Jens-Michael Kuhn
Member #6,298
October 2005
|
Quote: 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.
You're right, I tested the MEM, SYS and VRAM blitting to the screen and the SYS and VRAM blitting is now much faster.:) 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).:( |
A J
Member #3,025
December 2002
|
which DirectX SDK have you got ? ___________________________ |
Jens-Michael Kuhn
Member #6,298
October 2005
|
DirectX 9.0 SDK February 2005. |
A J
Member #3,025
December 2002
|
does this "DirectX Caps Viewer" under "BLT Caps" mention Alpha blitting ? ___________________________ |
Jens-Michael Kuhn
Member #6,298
October 2005
|
I didn't find anything about that. MSDN said:
Obsolete and unsupported flags
you can find it under http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/ddraw7/directdraw7/ddref_4b7b.asp |
A J
Member #3,025
December 2002
|
Do you see any issues with allegro using DX9 ? ___________________________ |
Thomas Fjellstrom
Member #476
June 2000
|
I don't see any. Evert might, no idea. -- |
Neil Walker
Member #210
April 2000
|
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? Neil. wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie |
GullRaDriel
Member #3,861
September 2003
|
I'm sure to have rode somewhere that Vista will 'pipe' OGL to his own grafic handler, so we'll loose some speed. "Code is like shit - it only smells if it is not yours" |
Thomas Fjellstrom
Member #476
June 2000
|
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. -- |
Thomas Harte
Member #33
April 2000
|
Quote: 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. [My site] [Tetrominoes] |
Elias
Member #358
May 2000
|
Quote: I don't see why. 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. -- |
Evert
Member #794
November 2000
|
Quote: With this roadblock in place for GL, allegro will need a DirectGraphics and/or Direct3d driver. 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. |
Jens-Michael Kuhn
Member #6,298
October 2005
|
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. But back to my hardware accelerated draw_sprite_*_flip(). Quote: The best you can do is to send your patch to the Allegro Developers mailing list. Read the readme.txt file for information on how to subscribe to this list. Alternatively, updated subscription instructions should always be available at http://alleg.sourceforge.net/maillist.html. 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? |
Thomas Harte
Member #33
April 2000
|
Quote: 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. [My site] [Tetrominoes] |
Evert
Member #794
November 2000
|
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. 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? |
A J
Member #3,025
December 2002
|
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 ___________________________ |
Jens-Michael Kuhn
Member #6,298
October 2005
|
Quote: As for the asm code in allegro, which routines need re-writing? 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. Quote: Have you tried things like VRAM->MEM blitting with this patch applied? Does that work as expected? 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. |
Thomas Fjellstrom
Member #476
June 2000
|
Quote: As for the asm code in allegro, which routines need re-writing? 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. -- |
A J
Member #3,025
December 2002
|
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 ? ___________________________ |
Evert
Member #794
November 2000
|
Quote: are all ports going to drop ASM ? That's the idea. Quote: does any of the mac code use ASM ? No. Only 32 bit Intel ports use ASM code (well, there is some in the AMD64 port, for cpuid mostly). Quote: how about the DJGPP port.. or is the DOS support going to get finally dropped ? 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. |
A J
Member #3,025
December 2002
|
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 ? ___________________________ |
Evert
Member #794
November 2000
|
Quote: 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... Quote: i've done some more stretchblit in C code, and im struggling to match the asm codes speed. 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). |
Thomas Harte
Member #33
April 2000
|
[quoete]althou there is no specific instructions that really assist in stretching 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. [My site] [Tetrominoes] |
A J
Member #3,025
December 2002
|
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. ___________________________ |
|
|