#### Archived

This topic is now archived and is closed to further replies.

This topic is 5880 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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

##### Share on other sites
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

##### Share on other sites
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...

##### Share on other sites
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..

##### Share on other sites
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]

##### Share on other sites
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.

##### Share on other sites
quote:

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.

Ummm, no. Going back quite a ways in DX versions, you could see in the SDK docs how pitch was calculated. The SDK also allowed you to allocate buffers yourself for use as surfaces, as long as you used the padding to keep the alignment on specific boundries (page or k boundries - can''t remember which). And, if a driver remains complient, it will still use that same method, although newer versions of DX (8+) drivers may try to optimize memory a bit by using smaller pitch values, which the driver will compensate for when you''re trying to access it. Typically, you''ll see this when dealing with depth buffer surfaces.

quote:

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

Any resize of the window means you have to reconstruct the buffer anyway to match, otherwise you get stretching, which uses the same resolution as when constructed. The only reason memory will change is when surfaces are paged in/out or moved to faster memory.

quote:

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.

More than likely, that was at the beginning of DX , where video card manufacturers were reluctant to get going. Still, very few drivers had problems like that.

quote:

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

Correct. If you are using pitch, than you should always lock the surface and grab the current pitch (never assume it''s fixed), as drivers can relocate surface memory at any time due to paging or any other reason. The speed hit is very small, as you have to lock the surface to ensure it''s in memory anyway.

home.att.net/~rpgbook
Author, Programming Role-Playing Games with DirectX

##### Share on other sites
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.

##### Share on other sites
Cool Jim Adams posted a message! If you are still cruising around here i''m reading your book Programming Role-Playing Games With DirectX and am loving it!

##### Share on other sites
quote:
Original post by silentrob66
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.

Please don''t do this. This is the sort of thing that leads to developers releasing products which crash on other people''s machine, and in defends the developer responds with "Well, it worked on my machine". "It worked on my machine" only matters if that''s the only place you''re going to run it. If you''re releasing it to the public, it isn''t acceptable.

Stay Casual,

Ken
Drunken Hyena

##### Share on other sites

This topic is 5880 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

This topic is now closed to further replies.

1. 1
Rutin
23
2. 2
3. 3
JoeJ
20
4. 4
5. 5

• 9
• 33
• 41
• 23
• 13
• ### Forum Statistics

• Total Topics
631744
• Total Posts
3001997
×