Re: GDI can be fast!

o//annabee wrote:
This is a test I am running.

I use a sprite that is moving across the screen, horizontally.
This sprite is a bitmap of size 143x40 pixels. The bitmap has been given a keycolor (1, 0, 255), and is not rectangular.

each time the sprite move, it is redrawn, with transparency. E.g. every pixel is written seperatly, and tested if it is the transparent color, and if so, it is skipped.
Also, each time it moves, the background are redrawn under it, and behind it.
And any other sprites below it will also redraw.

I was not expecting this to be fast enough for a game, but it is quite fast. Considering that there is every way of making it even faster, take a look at the numbers below.

When I moved the sprite one pixel at a time, it moved much to fast to be useful.
So I had to subdivide that pixel, and even dividing by 10000 was to fast.
in order to get the sprite to move at a speed where it floats a cross the screen taking about a second for the full travel, I had to update the counter 100000 times before advancing the sprite a single pixel.

And it make little diffrence if placing about 10 other sprites on top of each other in the path of the animating sprite.

I say this is very promising. Doing all this to move the sprite is faster than using the scrolling APIs :))) *MUCH* faster. And its not even fully properly clipped yet. All the sprites are 100% redrawn if any part of the DELTA movement happens inside that sprites rectangle, even if the sprite is invisible, and should be culled because of it, it is redrawn in full, when the moving sprite enters its rectangle, each single time the moving sprite moves.


[fraction: 0]
ThisApp.GameLoop:
test D$ThisApp.States ThisAppState_Animate | jz L0>
mov edi D$LastSprite

inc D$fraction
cmp D$fraction 100000 | jb L1>
mov D$fraction 0

mov ecx 1, ebx 0 | call Section.Move
lea eax D$edi+Section.ClientRect
mov ecx D$esi+Window.Width

test D$eax+Rect.Left ForNegative32bit | jnz L1>
cmp D$eax+Rect.Left ecx | jb L1>
neg ecx | mov ebx 0 | call Section.Move
L1:


L0:
ret
Hi,

The GDI, depending on which version you are using, makes pretty fair use of hardware acceleration so yes, if you choose your functions carefully it can be relatively quick, though not ever "fast" in my opinion. The BitBlt function can be fast as it is essentially a built in compiler that compiles based on the ROP code.

Ofcourse using 32 bit images and DWORD transfers or MMX will be faster than just about any GDI call, I have routines that have tested 10x faster than the GDI (ie GrayScaling) using this method (without MMX). The problem is displaying the updated image on a DC that is not 32 bit as the conversion is slow.

Donkey
.

Relevant Pages

  • Re: GDI can be fast!
    ... I use a sprite that is moving across the screen, ... Also, each time it moves, the background are redrawn under it, and behind ... When I moved the sprite one pixel at a time, it moved much to fast to be ... mov edi D$LastSprite ...
    (alt.lang.asm)
  • Re: Surely a simple prob i hope
    ... Just in response to the 790/800 pixel issue. ... i find when i move th emouse to the far right edge of my window it goes ... Next i draw a sprite at position 500,0,0 ... Then draw some 2d text at the same position 500,0 ...
    (microsoft.public.win32.programmer.directx.managed)
  • GDI can be fast!
    ... I use a sprite that is moving across the screen, ... E.g. every pixel is written seperatly, and tested if it is the transparent color, and if so, it is skipped. ... Also, each time it moves, the background are redrawn under it, and behind it. ... mov edi D$LastSprite ...
    (alt.lang.asm)
  • RE: Surely a simple prob i hope
    ... Just in response to the 790/800 pixel issue. ... and although i never really looked into it, i think it was due to the window ... Then draw some 2d text at the same position 500,0 ... So why does my sprite not position correctly? ...
    (microsoft.public.win32.programmer.directx.managed)
  • Re: DirectX texture loading, texture gets resized
    ... I have a windowed direct3d surface, 1024x768, 4 bytes per pixel ... This bitmap contains blocks with sprite images. ... The pixel tests on the background bitmap didn't have that problem. ... I guess this resized texture will take up more memory than is required. ...
    (microsoft.public.win32.programmer.directx.managed)