Back to Hands-On Interactive Game Development

04.03 - Pixel Manipulation

Teej · 2001-12-29T16:46:05

Starting With the Basics So far, we’ve looked at our game template code and how it uses DirectDraw to get us into a full-screen mode with our desired resolution and color depth. We then created DirectDrawSurface objects for the primary display (video card), and a backbuffer for our actual drawing. You know, I really like the overhead projector analogy with transparencies (clear plastic sheets). Our primary surface is the transparency currently on the overhead projector, and our backbuffer is an extra sheet on our desk. We’ll draw whatever we want onto this backbuffer, and quickly trade transparencies so that the backbuffer becomes the active display, and we start drawing all over again on the new backbuffer. We’re going to start drawing things on surfaces, and we’re going to start from scratch. What that means is that you take the contents of Game_Main() and clean it out so that it looks like this: void Game_Main() { } You can go ahead and run this program, and as you’d expect, nothing will be displayed. Thankfully the ESC key press is intercepted by Windows and passed to our template code via WindowProc() so that the program can terminate properly. Remember now, this function gets called over and over so long as the program is running. We know that there’s a primary DirectDrawSurface object for the active display and a secondary DirectDrawSurface object that’s our backbuffer. We also know that the plan is to draw onto the backbuffer and flip the two DirectDraw surfaces so that the backbuffer surface becomes the active display surface. Okay, so let’s paint some pixels! Pixel Painting Our first objective is to get our hands on the memory held by the backbuffer DirectDrawSurface object. The online SDK docs tell us that there are two methods for this purpose, Lock() and Unlock() . Okay, so let’s take a look at Lock() : HRESULT Lock ( LPRECT lpDestRect; LPDDSURFACEDESC2 lpDDSurfaceDesc; DWORD dwFlags, HANDLE hEvent ); You really need to have the online SDK docs open in order to be able to fill out method calls like this correctly – especially when flags are involved. We’ll fill in the parameters together, assuming that you are reading along: We can ask for a particular region of surface memory to lock, but we really want the entire thing, so we use NULL (as per the doc directions). This method requires a pointer to a valid DDSURFACEDESC2 structure. Lock() will fill in certain fields in this structure for us to use. So, we create a DDSURFACEDESC2 variable on the stack (‘on the stack’ means a local variable) and pass a pointer to it to the Lock() method as our second parameter. Taking a look at the possible flags in the docs, we see that DDLOCK_SURFACEMEMORYPTR is a must-have. Later in the tutorial we’ll explore the use of other flags, but for now this is all we need. We are told to use NULL here. No problem. Here’s the finished product: DDSURFACEDESC2 ddsd; // Lock the backbuffer surface ZeroMemory(&ddsd, sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); G.lpDDSBack->Lock(NULL, &ddsd, DDLOCK_SURFACEMEMORYPTR | DDLOCK_WAIT, NULL); First, I’ve cleared the DDSURFACEDESC2 structure using ZeroMemory() , which is the same thing as calling memset() – we’re just setting the entire structure to zeros. Then, we’re placing the size of the structure into the structure itself in the dwSize field. This is important, as many DirectX methods use structures as parameters and require us to supply the size in this field. Although it’s not important to us why, it’s worth mentioning that this is the only way a DirectX method can tell what structure we’re giving it is to provide the structure’s size. If you consider the fact that there’s a DDSURFACEDESC structure and a DDSURFACEDESC2 structure available, you can see why telling the difference might be important. And then, we call Lock() with our parameters. All DirectX methods returns values of type HRESULT, but for simplicity’s sake I’m not taking the return values into account for now. Rest assured however that we’ll need to, because so many things can go wrong and if you’re not checking the results of method calls, you get what you deserve in terms of headaches when things don’t work right (or worse yet, crash). There are two fields inside of the DDSURFACEDESC2 structure that we’re interested in, lpSurface and lPitch . With these two fields, we have everything we need to draw onto the backbuffer. Before I get to their use however, I’d like to get the rest of the DirectDraw methods out of the way. Okay, so assuming we’ve done our drawing, we are then supposed to unlock the backbuffer. This is done with Unlock() , which looks like this: HRESULT Unlock ( LPRECT lpRect ); This one’s easy – if you used a RECT in the call to Lock() , give it here as well. For us, we’ve locked the entire buffer, so we simply use NULL here as well: G.lpDDSBack->Unlock(NULL); The last thing we need to do is to actually get the backbuffer onto the active display. The method is called Flip() , and its prototype looks like this: HRESULT Flip ( LPDIRECTDRAWSURFACE7 lpDDSurfaceTargetOverride, DWORD dwFlags ); If you read the paragraph in the SDK docs describing the first parameter, you quickly realize that it’s an advanced feature we don’t need. For us, the default action is to flip the primary and secondary buffer, so we use NULL here. As for the flags, we don’t need any of them, so we’ll use 0. That’s it for DirectDraw calls! If you were to run the program now, you’d still see nothing (maybe some memory garbage), but the template for pixel manipulation is in place. Our last task in Game_Main() now is to actually alter the backbuffer memory using the surface pointer provided by Lock() . Accessing Surface Memory How large do you think the area of memory is that we now have access to? Well, what’s involved in figuring it out? Here’s the criteria: screen width in pixels screen height in pixels color depth (in bits) The logic is as follows: If I have 10 pixels across and 10 pixels down, I therefore have 100 pixels on the display. If each pixel needs 16 bits (= 2 bytes) of memory, then I’d need 100 pixels * 2 bytes = 200 bytes of memory. In our particular case, we’d like to use a 640x480 screen with 16-bit color, which would make our memory needs 614,400 bytes. For this article, I’m going to assume that your video card can handle 16-bit color. I’m also going to assume that it maps 5 bits for red and blue, and 6 bits for green (the most popular combination). Some video cards prefer to use 5 bits for each color component and use the remaining bit as an alpha component, and there’s a way to check in your code for what type of video card you have, but it’s really outside of the scope of this article. Now, it’s a fact that pointers to areas of memory can also be used as arrays. As a matter of fact, an array name is equivalent to a pointer. What we’d like to do is take our surface memory pointer and use it like an array, with each array element corresponding to a single pixel. This way, pixels would be accessed like this: buffer[0] = color; // First pixel (0,0) buffer[10] = color; // (10,0) So, the first row of pixels in a 640x480 display would be numbered 0-639. Therefore, the first pixel in the second row would be number 640: buffer[640] = color; // (0,1) …and the first pixel in the third row would be 640 + 640 = 1280. Generalizing, we can use the following: int x, y; buffer[y * SCREEN_WIDTH + x] = color; // (x,y) Make sure that the above line makes perfect sense to you. Every time we go SCREEN_WIDTH pixels across, we end up directly underneath ourselves, so we move an additional x pixels over to get to any location on the display. There are two outstanding issues at this point: the surface memory pointer and the actual color value composition. We’re almost there… Typecasting the Buffer Pointer The surface memory pointer given to us by Lock() is of type LPVOID. In other words, it can’t be used until it is ‘cast’ to a proper data type. Just like with an array, the pointer needs a type so that when we do something like this: buffer[3] = color; …the compiler knows how far over in memory the fourth element is (0,1,2,3 = 4th). Is it a byte? Ten bytes? Forty-three? When we declare an array like this: int Array[20]; …the compiler knows that each element is four bytes wide because that’s how large an int is. The answer here is to figure out how big a pixel is, and typecast our surface pointer to some data type that matches. Since we’re playing with 16-bit color, any 16-bit unsigned data type will do (there are no negative color values). Now, I realize that some people would like assistance with all of these data types, so check in 03.03 – Selected C Topics for an overview. I can tell you that either USHORT* or WORD* would work fine, so let’s use WORD. It’s now time to take possession of the surface pointer hidden in that DDSURFACEDESC2 structure we got back from Lock() : WORD *pwBuffer; pwBuffer = (WORD *)ddsd.lpSurface; That’s it! The (WORD *) is the typecast that changes the pointer from LPVOID (VOID*) to WORD*. Now, every time we access pwBuffer elements, we’ll be moving 16-bits at a time – exactly the size of a pixel in 16-bit color mode. Using the Memory Pitch In our illustrations, screen memory (in bytes) is exactly 640x480 multiplied by the number of bytes per pixel. In reality however, there’s a notable difference – the video adapter may reserve some extra memory for itself. If you picture the surface memory as being a rectangle (just like the monitor screen), then picture the video card’s private memory as being a rectangular ‘growth’ coming out of the right-hand side of the monitor. In other words, the number of bytes per horizontal line is equal to the number of pixels per line times the number of bytes per pixel, PLUS the video card’s reserved memory. This is where the lPitch field comes in. This value represents the total number of bytes used by the video card of each horizontal line of memory for the display (which equals the visible display memory plus the reserved memory). Don’t let it bake your brain too much; just read this next line a few times over: buffer[ y * lPitch + x] = color; Of course, this assumes that the pitch is in pixels. DirectDraw gives it to us in bytes, so if you’re not using 8-bit color you’d better fix that value like so: long lPitch; // Get the pitch for 16-bit pixels lPitch = ddsd.lPitch / 2; The reasoning is like this: If there are x bytes in each row, then there are x / 2 WORDs in each row. It’s like in math – if your unit of measurement is metres, make sure you convert any miles and inches before evaluating anything. For us, we’ve decided that a pixel is one WORD wide, so we need our pitch in WORDs, not bytes. Put another way, think: “If the video card uses x bytes per row, how many pixels per row is that?”. Color Composition To some extent, I’ve already covered this subject in the Learning Ladder series, but I’ll reiterate some of it here for clarity. Our pixels are 16-bits wide, and out buffer has been typecast to 16-bit elements. This means that whatever we assign to an array element will be 16 bits wide. Recall that in 5,6,5 16-bit color mode we have 5 bits available for red (intensity (brightness) from 0-31), 6 bits for green (0-63), and 5 bits for blue (0-31). Once you’ve decided on your values for these three, you need to combine them into a 16-bit number. Since I’ve already discussed how this is done, I’ll just show you a macro that’s included in GAMEMAIN.CPP to make life a little easier: // This converts an R,G,B set to a 16-bit color (565) #define RGB16(r,g,b) ((r << 11) + (g << 5) + b) Here’s how you would use it with a buffer: buffer[0] = RGB16(0, 0, 0); // Black buffer[1] = RGB16(31, 63, 31); // White buffer[2] = RGB16(31, 0, 0); // Red buffer[3] = RGB16(031, 0, 31); // Purple (Red + Blue) Just think of each color component as a brightness knob that you adjust from 0% to 100%. The color component’s highest allowed value is 100% bright, and 0 is always 0%. It may seem odd that green has an extra bit to it, and therefore can produce a higher maximum value, but don’t forget that 0 is 0, 63 is 100% brightness, and 50% brightness is ~32, just like ~16 is 50% bright for red or blue. Putting it all Together Let’s bring out the complete Game_Main() as it stands: void Game_Main() { DDSURFACEDESC2 ddsd; WORD *buffer; long lPitch; // Prepare a DDSURFACEDESC2 structure for Lock() ZeroMemory(&ddsd, sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); // Lock the backbuffer surface G.lpDDSBack->Lock(NULL, &ddsd, DDLOCK_SURFACEMEMORYPTR | DDLOCK_WAIT, NULL); // Get the surface pointer and the memory pitch (in WORDs) buffer = (WORD *)ddsd.lpSurface; lPitch = ddsd.lPitch / 2; // (bytes / 2 = WORDs) // Draw onto the display // Fill the entire screen with white pixels int x, y; for (y = 0; y < SCREEN_HEIGHT; y++) { for (x = 0; x < SCREEN_WIDTH; x++) { buffer[y * lPitch + x] = RGB16(31, 63, 31); } } // Unlock the surface G.lpDDSBack->Unlock(NULL); // Flip the surfaces G.lpDDSPrimary->Flip(NULL, 0); } Pop that into your GAMEMAIN.CPP, and take a quick look at GLOBALS.H to make sure that you’re in 16-bit color mode (i.e. SCREEN_BITDEPTH is 16). As it says, this function will color every pixel on the display white. Go Play With Yourself It’s absolutely vital that you take the time (the more the better) to really play with this function – especially the actual pixel coloring. I can think of dozens of cool effects to try and create right off the top of my head, so there’s plenty that can be done here with a few simple variables and some creative thinking. Here’s some little tidbits that might come in handy in your adventures: The rand() function returns a pseudo-random number between 0 and 32,767. When used with the modulo operator (%), you can get a number in any range. Here’s an example: buffer[0] = RGB16(rand()%32, rand()%64, rand()%32); Since % gives you a remainder, something like rand()%32 will give you a number between 0 and 31, which is the exact range for a 5-bit color component. You might be interested in 'seeding' the random-number generator, which basically gives you fresh, unique streams of random numbers -- look in your online help for more information. The static keyword, when used with a local variable (i.e. a variable declared inside of a function) will retain its value between function calls. A function like this: void SomeFunction() { static int i = 0; printf(“Number = %d”, i); i++; } …will output increasing values for i with every call, instead of always printing zeros if the variable wasn’t static. With variables of this type, you can do some interesting things with Game_Main() . SCREEN_WIDTH and SCREEN_HEIGHT are your friends. Never use hard-coded values in Game_Main() . Also, many interesting effects can be generated by using these definitions in your drawing code. Some Things to Try If you’re feeling like a challenge, try the following: Create solid diagonal lines of varying color on the display Create a sequence of boxes around the screen, steadily decreasing in size down to the middle Emulate gray-scale “off-air” television noise (think Poltergeist) Have single pixels or lines race from the top-left to the bottom right of the display Scatter pixels on the display that pulsate in varying colors We don’t want to get too complicated here, but I’d love to have anyone who comes up with a cool creation using simple variables, loops and math functions to submit it for everyone to see and try. Questions? Comments? Do you have a wicked demo to show off? Please reply to this topic! Edited by - teej on May 10, 2001 10:59:32 AM

Hands-On Interactive Game Development Workshops

Started by Teej May 08, 2001 02:43 PM

47 comments, last by Teej 22 years, 4 months ago

Dionysis

122

May 09, 2001 11:48 PM

Biere et punk,
Ok ya that's what I thought

Piotyr,
I ran into the same problem as you, but i found a solution that worked for me.

The problem seems to be in the order of the for loops. Try switching them around so the x variable is the outer for loop and the y variable is the inner one.

eg.

for (x = 0; x < SCREEN_WIDTH; x++){   for (y = 0; y < SCREEN_HEIGHT; y++)       buffer[x + y*lPitch] = color;}

The pixels will now be drawn in vertical lines on the screen instead of horizontally. I'm not sure why it would cause a problem the other way, maybe someone can shed some light on the topic?

Edited by - Dionysis on May 9, 2001 12:49:14 AM

zenic

122

May 10, 2001 12:08 AM

Hello everyone... Just browsing through here because i LOVE the idea, teej

wish this was around when i first met DDraw!

thought i might throw in some code for determining the pixels in 16bit mode.

during initialization, call:

ZeroMemory(&ddPF, sizeof(ddPF));
ddPF.dwSize = sizeof(ddPF);

// get the information from the back surface
ddret = lpSurface->GetPixelFormat(&ddPF);
if (ddret != DD_OK)
return FALSE;

// now we interpret the return values
if (ddPF.dwFlags & DDPF_RGB) {
switch (ddPF.dwRGBBitCount) {
case 16: {
DWORD dwRBM = ddPF.dwRBitMask;
DWORD dwGBM = ddPF.dwGBitMask;
DWORD dwBBM = ddPF.dwBBitMask;
// calculate shift left amount
for (iRSHL=0; (dwRBM&1)!=1; iRSHL++) dwRBM>>=1;
for (iGSHL=0; (dwGBM&1)!=1; iGSHL++) dwGBM>>=1;
for (iBSHL=0; (dwBBM&1)!=1; iBSHL++) dwBBM>>=1;
// calculate shift right amount
for (iRSHR=8; (dwRBM&1)==1; iRSHR--) dwRBM>>=1;
for (iGSHR=8; (dwGBM&1)==1; iGSHR--) dwGBM>>=1;
for (iBSHR=8; (dwBBM&1)==1; iBSHR--) dwBBM>>=1;
// calculate the mask to use for merging colors
// merge means taking the average of two pixels, giving a 'translucent' effect
dwMergeMask = 0xFFFFFFFF;
if (iRSHL>0)
dwMergeMask ^= 1<<(iRSHL+15) | 1<<(iRSHL-1);
if (iGSHL>0)
dwMergeMask ^= 1<<(iGSHL+15) | 1<<(iGSHL-1);
if (iBSHL>0)
dwMergeMask ^= 1<<(iBSHL+15) | 1<<(iBSHL-1);
dwMergeMask ^= 1<<31 | 1<<15;
break;
}

(that was a quick cut and paste, so there is probably braces missing)

then, when you want to write the pixel, use:

  buffer[offset]= (red >>iRSHR<<iRSHL) | (green >>iGSHR<<iGSHL) | (blue >>iBSHR<<iBSHL);

this way, red green and blue are values from 0 to 255 and it will always work, whether 5-5-5 or 5-6-5 or whatever format.

erm... i don't want to intrude on what teej is telling you so just ignore the dwMergeMask for the moment

Edited by - zenic on May 10, 2001 1:27:49 AM

White Knight

122

May 10, 2001 12:21 AM

Hey Teej

First of all I would like to say you are doing a great job. Secondly I think I have found an error in your document. You say that the pitch is the number of extra bytes use by the screen card, but in fact it is the total of the width plus extra bytes used by the screen card. The source code it correct, but in your article under "Using the Memory Pitch" you have the formula "buffer[ y * (SCREEN_WIDTH + lPitch) + x] = color;" which is wrong. It should be buffer[y*lPitch + x] = colour;

I hope this helps.

Edited by - White Knight on May 10, 2001 6:28:51 AM

Morgan123

122

May 10, 2001 12:50 AM

First time I''ve visited here and this whole thing looks like a really good idea. But I have a query if anyone can help.

I''ve locked two surfaces (one off screen and one a back buffer for the primary surface) running in 32 bit colour and i''m trying to copy data between them. (I''m not bliting ''cos I''m performing a few operations of the data). My basic code is:

//Lock surfaces
lpDDSOffScreen->Lock(pSourceRECT, &DDSDSource, DDLOCK_WAIT | DDLOCK_READONLY, NULL);
lpDDSBackBuffer->Lock(pDestRECT, &DDSDDest, DDLOCK_WAIT | DDLOCK_WRITEONLY, NULL);
//Devide pitches by 4 to adjust for double words
DDSDSource.lPitch/=4;
DDSDDest.lPitch/=4;
//Extract pointers to surface areas
pDWORDSource=(DWORD *)DDSDSource.lSurface;
pDWORDDest=(DWORD *)DDSDDest.lpSurface;
//Loop through surface area
for(int nCountY=0; nCountYbottom-pSourceRECT->top; nCountY++)
{
for(int nCountX; nCountXright-pSourceRECT->left; nCountX++)
{
//Move data (Obviously I do more than this in reality or I''d just use a blit)
*(pDWORDDest+nCountX)=*(pDWORDSource+nCountX);
}
//Move to next rows in surfaces
pDWORDSource+=DDSDSource.lPitch;
pDWORDDest+=DDSDDest.lPitch;
}
//Unlock surface
lpDDSBackBuffer->Unlock(pDestRECT);
lpDDSOffScreen->UnLock(pSourceRECT);

If I do the same thing with words or bytes it works fine, just not with double words. (Adjusting the devision on lPitch to match.) And it is definately using 32bit colour. (I''ve check all the values in my DDSURFACEDESC structers.)

Can anyone please help me?

Morgan123

122

May 10, 2001 12:57 AM

Sorry, I forgot to mention what went wrong just above (it is early morning at the moment here y''know). Anyway I get a sort of blue hue to everything.

Thats everything (I''m sure of it)

Anonymous

May 10, 2001 02:38 AM

First, teej great thing you are doing here

.

And then, a cool program that all of you can try out.
First pick a random point on the screens. Then start drawing a square of which the center is at the specific point. The width of the square increases with every entrance in the Game_Main function. When the square reaches one of the edges of the screen, start over again with a new randomly choosen point.

How I did it:

  int Game_Main(){  DWORD *buffer;  long lPitch;  static POINT p;         // the random center of the square  static WORD color;      // square color  static int squarewidth; // the half of the width of the square  // the code below will fill our entire surface with one color  DDBLTFX ddbltfx;  ZeroMemory(&ddbltfx, sizeof(ddbltfx));  ddbltfx.dwSize = sizeof(ddbltfx);  // fill with black  ddbltfx.dwFillColor = 0;  G.lpDDSBack->Blt(NULL,NULL,NULL,                   DDBLT_COLORFILL | DDBLT_WAIT,                   &ddbltfx);    // check if we are touching one of the edges  if (p.y-squarewidth <= 0 ||      p.y+squarewidth >= SCREEN_HEIGHT ||      p.x-squarewidth <= 0 ||      p.x+squarewidth >= SCREEN_WIDTH)  {    p.x = rand()%SCREEN_WIDTH;    p.y = rand()%SCREEN_HEIGHT;    color = RGB16(rand()%32,rand()%64,rand()%32));    squarewidth = 0;  }  else  {    DDSURFACEDESC2 ddsd;    ZeroMemory(&ddsd, sizeof(ddsd));    ddsd.dwSize = sizeof(ddsd);    // lock surface    G.plDDSBack->Lock(NULL, &ddsd,                      DDLOCK_SURFACEMEMORYPTR | DDLOCK_WAIT,                      NULL);    buffer = (WORD *)ddsd.lpSurface;    lPitch = ddsd.lPitch >> 1;    // put the square onto the surface    int x, y;    for (y=p.y-squarewidth; y<p.y+squarewidth; y++)    {      for (x=p.x-squarewidth; x<p.x+squarewidth; x++)      {        buffer[y*lPitch+x] = color;      }    }    // unlock the surface again    G.lpDDSBack->Unlock(NULL);  }  // enlarge the square  squarewidth++;  // flip backbuffer to primary  G.lpDDSPrimary->Flip(NULL, 0);}

Well, this should work. There can be some errors in it, because I don''t have the code with me.

Teej

176

Author

May 10, 2001 10:53 AM

ErrorX: Who knows where the tutorial will end. There''s much to learn and practice on in the world of 2D games, and then there''s 3D...

Dionysis: Will get back to you with a better explaination shortly (busy at the moment).

White Knight: Thanks for spotting the error...I was typing madly when I wrote it, and lost track there. I''ve fixed the article.

Anon: Will try your code this evening...

Teej

Teej

176

Author

May 11, 2001 12:59 PM

Anon: I''ve tried the code...very nice, indeed!

For anyone who wants to try it, I''ve added it to this post and corrected any subtle typos that Anon made (recognizing the fact that he typed it from memory so there''s bound to be some little thing off here and there):

  void Game_Main(){    WORD *buffer;    long lPitch;    static POINT p;         // the random center of the square      static WORD color;      // square color      static int squarewidth; // the half of the width of the square          // the code below will fill our entire surface with one color      DDBLTFX ddbltfx;    ZeroMemory(&ddbltfx, sizeof(ddbltfx));    ddbltfx.dwSize = sizeof(ddbltfx);    // fill with black      ddbltfx.dwFillColor = 0;      G.lpDDSBack->Blt(NULL,NULL,NULL,                     DDBLT_COLORFILL | DDBLT_WAIT,                     &ddbltfx);        // check if we are touching one of the edges      if (p.y-squarewidth <= 0 ||        p.y+squarewidth >= SCREEN_HEIGHT ||        p.x-squarewidth <= 0 ||        p.x+squarewidth >= SCREEN_WIDTH)    {            p.x = rand()%SCREEN_WIDTH;        p.y = rand()%SCREEN_HEIGHT;        color = RGB16(rand()%32,rand()%64,rand()%32);        squarewidth = 0;    }    else    {        DDSURFACEDESC2 ddsd;        ZeroMemory(&ddsd, sizeof(ddsd));        ddsd.dwSize = sizeof(ddsd);        // lock surface        G.lpDDSBack->Lock(NULL, &ddsd,                          DDLOCK_SURFACEMEMORYPTR | DDLOCK_WAIT,                          NULL);        buffer = (WORD *)ddsd.lpSurface;        lPitch = ddsd.lPitch >> 1;        // put the square onto the surface         int x, y;        for (y=p.y-squarewidth; y<p.y+squarewidth; y++)        {            for (x=p.x-squarewidth; x<p.x+squarewidth; x++)            {                buffer[y*lPitch+x] = color;            }        }        // unlock the surface again        G.lpDDSBack->Unlock(NULL);    }    // enlarge the square    squarewidth++;    // flip backbuffer to primary    G.lpDDSPrimary->Flip(NULL, 0);}

Anyone else?

Teej

PS: Anon, get yourself registered with GameDev.net so we know who you are!

ManOCheese

122

May 12, 2001 05:46 PM

Weyhey, were back up! Geez this site is cool, I spent 6 hours last night getting from the start to this point and am anxoius to carry on. I''ve been brushing up on trig and stuff and playing with DirectX coz I''m terminally impatiant

Thanx Teej.

Sad day today, mourning the loss of Douglas Adams........

FragLegs

122

May 12, 2001 07:32 PM

For you fractal lovers, check this out:

    #define NUM_POINTS 3int pointsX[NUM_POINTS] = {SCREEN_WIDTH / 2, 50, SCREEN_WIDTH - 50};int pointsY[NUM_POINTS] = {50, SCREEN_HEIGHT - 50, SCREEN_HEIGHT - 50};int myX = rand() % SCREEN_WIDTH;int myY = rand() % SCREEN_HEIGHT;int i = 0;//////////////////////////////////////////////////////////////////////////////// Game_Main//// This function is called once per frame.//void Game_Main(){	   int pick = rand() % NUM_POINTS;	   myX = (myX + pointsX[pick]) / 2;	   myY = (myY + pointsY[pick]) / 2;	   if(i > 1000)	   {		   DDSURFACEDESC2 ddsd;		   WORD *buffer; 		   long lPitch;  		   // Prepare a DDSURFACEDESC2 structure for Lock() 		   ZeroMemory(&ddsd, sizeof(ddsd));		   ddsd.dwSize = sizeof(ddsd);		   // Lock the backbuffer surface		   G.lpDDSPrimary->Lock(NULL, &ddsd,			   DDLOCK_SURFACEMEMORYPTR | DDLOCK_WAIT, NULL);  		   // Get the surface pointer and the memory pitch (in WORDs)		   buffer = (WORD *)ddsd.lpSurface;		   lPitch = ddsd.lPitch / 2;		   // (bytes / 2 = WORDs)		   // Draw onto the display 		   buffer[myY*lPitch + myX] = RGB16(0,3,25);		  		   // Unlock the surface 		   G.lpDDSPrimary->Unlock(NULL); 	   }	   else		i++;}

Edited by - FragLegs on May 12, 2001 9:00:05 PM

Edited by - FragLegs on May 12, 2001 9:01:32 PM

04.03 - Pixel Manipulation

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

04.03 - Pixel Manipulation

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines