Upcoming Events
Unite 2010
11/10 - 11/12 @ Montréal, Canada

GDC China
12/5 - 12/7 @ Shanghai, China

Asia Game Show 2010
12/24 - 12/27  

GDC 2011
2/28 - 3/4 @ San Francisco, CA

More events...
Quick Stats
66 people currently visiting GDNet.
2406 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!
Link to us Events 4 Gamers
Intel sponsors gamedev.net search:

Contents
 What is PDL?
 Using PDL Correctly
 PDL Uses

 Printable version
 Discuss this article
 in the forums


PDL Uses

Part 1: Routine Review

Now thay we know how to construct PDL routines correctly, we can learn how best to use them. One of their uses is routine review. Project managers and lead programmers don't like to waste time going over endless lines of code to learn whether or not the routine does what they want it to, or what it's spec'd out to do. Consider how much easier it would be for a lead to be able to read through PDL and decide whether the programmer is on the right track. Of course this won't catch programming flaws, but programming flaws can be avoiding by finding design flaws - so it's all good.

On top of that is the ease of which you can modify PDL - anybody can do it! People who don't know jack about coding but are seasoned designers can easily change the wordings of a routine to better match specification. This is the cheapest and most effective way to change a program architecture. Think of how hard it would be to have to rip out a few lines of code that could easily constitute only one line of PDL. Saving money is always a good thing, and PDL can help you do that.

Part 2: Code Documentation

Ahh, here we go - the reason I decided to write this whole article in the first place. I think another acceptable translation of PDL would be Program Documenting Language. Why? Easy - check out what I did with Example B.

// Prevent the drawing surface from being accessed by other programs while we draw.
lpdds7->Lock(NULL, &ddsd, DDLFLAGS, NULL);

// Retrieve the memory pitch of the surface memory so we do not draw out of bounds.
int mempitch = (int)ddsd.lPitch;

// Retrieve the location of the surface so that we can draw to it successfully.
UCHAR *video_buffer	= (UCHAR *)ddsd.lpSurface;

// If the pixel mode is set to random
if (pixel_mode == RANDOM) {
	// Create three random values that we can assign to the x, y and color attributes of the pixel.
	UCHAR color	= rand()%256;
	int x		= rand()%800;
	int y		= rand()%600;
}
//Else if the pixel mode is set to linear
else if (pixel_mode == LINEAR) {
	// Update the horizontal position of the pixel.
	pixel_x++;

	// Create a random value for the color of the pixel.
	UCHAR color	= rand()%256;
} // End If

// Plot the pixel on the screen.
video_buffer[x+y*mempitch] = color;

// Release the surface for general use once again.
lpdds7->Unlock(NULL);

// Return TRUE that the pixel was plotted.
return 1;

Check that out. In all my past experiences I've always coded first, commented second. Who'd ever thought the other way around was better? Obviously somebody did. What an easy way to code and comment at the same time. For all you people against taking the time to comment you code (you'd be surprised how many people actually hate to comment, check out this thread for proof), this is the excuse that you need. You don't even have to think of it as commenting, just write out the routine in PDL to get the architecture and implementation straight, then just code it and don't delete the PDL, because it turns right into comments!

Conclusion

Well that's about it. PDL, as you can see, is a tool than belongs in any designer's and coder's toolbox. I'm sure glad I stumbled upon it, because it's streamlined my coding a lot. Writing out a whole routine in PDL and then just adding the code after perfecting it has saved me countless hours. I hope I did a good job explaining to you the correct way to use PDL to save you time and effort. Any questions and/or comments can be directed to gaiiden@hotmail.com - I'd love to hear from you. Until next time...