Contents  What is PDL?  Using PDL Correctly  PDL Uses  Printable version  Discuss this article  in the forums

Using PDL Correctly

Like anything else in this freakish world, PDL can be easily abused. How sad. But to avoid this tragedy I'll cue you in on what to do and what not to do. Let's kick off this section by dumping you with an example of using PDL, then I'll break it down for you to understand, pointing out do's and dont's along the way. Shall we?

Here's a little excercise - look at examples A and B and see if you can discern which PDL code is correct and which is not.

Example A

Lock the drawing surface to prevent access by other programs and check for errors.
Get mem_pitch of the surface using (int)ddsd.lPitch.
Get *video_buffer to draw to using ddsd.lpSurface.

if pixel_mode == random then

	Create three random values for x, y and color.
else if pixel_mode == linear then
	Increment x value by 1.
	Create a random value for color.

end if
video_buffer[x+y*mempitch] = color

Unlock the surface and check for errors.
return 1

Example B

Prevent the drawing surface from being accessed by other programs while we draw.
Retrieve the memory pitch of the surface memory so we do not draw out of bounds.
Retrieve the location of the surface so that we can draw to it successfully.
If the pixel mode is set to random
	Create three random values that we can assign to the x, y and color attributes of the pixel.

Else if the pixel mode is set to linear
	Update the horizontal position of the pixel.
	Create a random value for the color of the pixel.

End If
Plot the pixel on the screen.

Release the surface for general use once again.
Return TRUE that the pixel was plotted.

Obviously the above two code examples document the plotting of a pixel on the screen. I chose this for an example because it is a basic task a lot of you should be familiar with. Now, were you able to figure out which was the bad PDL and which was the good? If not go back and read the end of the first section again, where I clue you in on a few of things that you should not find in PDL. Even still, I think I made the distinction rather obvious.

The answer is Example B. Surprised? I hope not. Example A could not possibly fit my current description of PDL in any way whatsoever. I specifically pointed out how PDL is considered a high-level language, and some of the lines in Example A are anything but. Here are some of the things that make Example A a PDL nightmare:

• Although you may not realize it, the term "Lock a surface" can easily be attributed to DirectX and its Lock() function. The same applies to the term Unlock. Since we want our PDL to be as ambiguous as possible, Example B cleans this up by using the terms prevent and release. Anyone who wants to argue that release is also DirectX specific will break their noses running into a brick wall - in this context, release does not describe the freeing of COM components.
• Direct reference to variable names in Example A is also a no-no. And following close behind them are direct code examples! Ack! Once again ambiguity must reign supreme, and there's no way you can use that code in Visual Basic or any other language.
• Also present is the reference to a language-specific feature - the C pointer. This immediatly kills any sense of ambuguity since all other language options for writing this routine fall out.
• Then we have another direct code example for plotting the pixel, again unnacceptable.
• Finally we have the ending "return 0". Another language-limiting statement, and one that explains absolutly nothing of its true purpose.

After going through above points, and comparing them to Example B, you'll fully understand what PDL should look like. If you really think about it, you could code the pixel-plotting routine in any language capable of handling the task. Wonderful! Notice how the routine is nothing but English - nor variable names, no comparison signs, no code whatsoever. Of course, this brings us to a final point about good PDL use.

It's very easy to go overboard when writing in PDL. You may get a bit too descriptive and realize that coding what you wrote may be a nightmare! Therefore writing PDL can be considered an iterative process. Write it once, then start to break it down as far as you can go without quite reaching code level and while maintaining the basic rules of PDL.

Next : PDL Uses