It''s known that lPitch may be not equal to surface width, because width aligned by directx to "good" number. But if i create surface with already good width = 512 or 256, can i be sure that lPitch will be equal width in any computers, or directx can set it to 511 or 513,514...???

It MIGHT, but it is never safe to assume anything. Usinl the lPitch isn''t that hard, I just have a loop that increments the Y value and then processes the X (the scanline) with pointer incrementation. The pointer is recreated for each scanline

Cybertron is right. Using lPitch isn''t that hard. But if you must know, I don''t believe that directX will make the lPitch something odd, like 511 or 513... there''s no optimizations in doing that... having it aligned at 256, 512, or 1024 has it''s benifits when it comes to blitting, i.e. directX can then use bit shifters to calculate the beginning of a line instead of straight multiplication... just my take on it, though...

I agree, but in some cases when time of working become very important some additional operations like organizing cycle
and additional increments are not allowed.If lPicth = Width and
Width is known then surface is linear memory, and i can fill in
one cycle ( not two dimension ) or use ''rep STOPSW'' in assembler
to copy data in it.
Real LPitch calculated by directx, and this calculations doing by some alghoritm , which - is unknown. If know how it deside
what value of lPitch must be, so we can exactly say - Always LPitch = Width when Width = 2^N or Not.
To my mind its no reasons give lPitch other when Width = 2^N, but how it''s real, i not sure..

I think I can see the benifit to what you're trying to do, if you were writing your own blitter. Personaly, I think blitting is best left to the hardware.

However, my way of thinking is this: if the width == 2^N, then lpitch 'should' always = width(no benifit or reason for doing otherwise).

The only way to find out for sure is to try it, though. Try creating a random number of surfaces, with random widths. Than compare the widths to the lpitches. In the end, it doesn't matter how anyone 'thinks' directx or video hardware will behave. The only thing that matters is how it 'truely' behaves, under real-world circumstances, and the only way to find that out is to see firsthand. Also, I'm not sure if the video hardware is responsible for the 'lpitch factor' or if it's a directx thing, so behavior may change on different hardware/directx versions....

But ultimately, my opinion is to bite the bullet and assume that lpitch never equals width, and use lpitch accordingly. That's just me, though...

[edit - spelling and grammar]

[edited by - silentrob66 on June 10, 2002 11:08:23 PM]

You read pitch from the surface description and use that to calculate offset to next scanline. Period.

It''s not because some people suggested that it''s "faster" for blitter to blit if the scanline widths are powers of two. That''s mostly irrelevant for performance.

What is more relevant is that think of nVidia, they do multiple pixels at once. Think of architechtures with tiling. If the framebuffer is accessed in, for example as 4x1, 16x8 or other size blocks at a time, it would take extra silicon to implement special case where framebuffer has odd-number of pixels in the last block on the right side of the buffer.

It''s so much simpler to allocate whole blocks and just leave the few odd pixels unused/undefined. When resizing window, also, operation will be quicker when we don''t have to resize for each pixel-size resize, rather only physically change size when we cross certain block size .. if we use logically 64x64 blocks, we need to resize only every 64 pixels. Users will still see smooth resizing taking place. Most of the time window *does* just logically map piece of physical videomemory and no memory re-allocation per-se is taking place, but that''s still how it goes. Imagine rendering buffer for DirectX or OpenGL where rendering is taking place, and which is BLIT into the visible part (or soon-to-be-visible) part of videomemory. It''s quite sure that the driver doesn''t want to resize the memory all the time (or waste memory, but can, if that is fit).

Point being.. nice power-of-two width for framebuffer hardly is the primary reason. Heck, most devices use pitch == width*bpp anyway. It''s some odd Matrox and ATI cards mostly where you might experience otherwise.

Then there used to be drivers where pitch was set to width in visible pixels (not even multiplied by the pixel width in bytes) which gave a lot of gray hair to developers (who did care) back then. Usually applications which (incorrectly) calculated pitch manually got away with it and only Matrox folks experienced difficulty. This happened with VESA VBE aswell.. too bad.. specs are clear about it, but still driver authors make errors. But as application writers it''s OUR responsibility to write CORRECT code, and inform the hardware manufacturer of their driver errors. This way things work out smoothly in the end.

So write correct code. Don''t assume anything about pitch. Read the value back, and use it as it should be used. Thank you.

Ofcourse I said *drivers*, they were free to set pitch to anything they thought appropriate - thus - user sholdn''t count on it being anything specific. Read it, use it, right?

I just gave plenty of reasons why pitch != width*bpp, and I still think that power-of-two dimensions is least likely reason in practise to be of consideration.

For client it''s marginally useful.. if you know your trade, raster routines don''t have to calculat address of pixels too frequently anyway (*1). If you doing triangle filler, once per triangle is sufficient (for example for the topmost vertex). If it''s a 2D sprite, same thing, one of the corners is sufficient, etc. etc.

SO IMHO, the power-of-two doesn''t weight much at all in the cup based on my experience.


(*1) Going right? ++address; Going down? address += pitch; As you can agree, this makes the power-of-two not very factorial.