• ### Announcements

#### Archived

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

# Why won't this code work?

## 19 posts in this topic

If you read my last post, you know I was trying to copy a background buffer to the back buffer in DirectDraw helluva fast. I finally decided to use a DirectDraw surface for the background buffer but now the code doesn''t work! To copy the background buffer to the back buffer I''m using the following code: // set up a RECT structure for bg buffer based on pan in x-axis RECT bg_rect = {Screen_Pan_X, 0, Screen_Pan_X + 641, 481}; // make the blitter call if(FAILED(lpddsback->BltFast(0,0,bg_surface,&bg_rect,DDBLTFAST_NOCOLORKEY))) return(0); ............................................................ This code should copy the background to the back buffer, but when I try to display it the background doesn''t show up at all. The computer doesn''t crash or anything, but background never gets displayed. I''ve also tried blitting directly to the primary buffer and using the slower Blt instead of BltFast but i get the same results. I think I setup the new surface correctly, but I''m not sure. Could someone please help me out? I''d appreciate it. Thanks, Al
0

##### Share on other sites
What are the sizes of the surfaces involved? If your background surface is bigger than your primary surface, e.g. if your background is 1280x1024 and your screen resolution is 640x480, then you will have to employ clipping to only Blt a subsection of the total background image. You can do this with the DIRECTDRAWCLIPPER interface. Note that once you attach a clipper object to a surface, you cannot use BltFast to display that surface (The BltFast function does not support clipping).
0

##### Share on other sites
Does the Blt return an error? If so what is it?

Breakaway Games
0

##### Share on other sites
Well, I don''t know if this would do it, but you should change the 641 to 640 and the 481 to 480. The way you have it set up now is 1 pixel too far in each direction. This could cause the blit to fail.

If that doesn''t work, see if the actual blit call is failing or suceeding. If it''s failing, what is the return value?
0

##### Share on other sites

Gandalf the White
0

##### Share on other sites
Well if the image is surpacing even by 1 pixel of the image wont show. Do you have a clipper attached??
0

##### Share on other sites
I ended up using the normal Blt function instead of BltFast. It''s not helluva fast but I guess it will have to suffice. I suppose it''s better than using memcpy. I don''t understand why it won''t work with bltfast, though... do I really need clipping? All I''m doing is copying a portion of the background buffer to the back buffer. The RECTs are the same size, so why would I need clipping? It should work as is. I already had a clipper attached to the back buffer but it''s really just for sprites. Anyway...Thanks for everyone''s advice.

Al
0

##### Share on other sites
Aw... You know what? I just figured it out. If you know a little about DirectX you should already know what I''m about to say because I mentioned it in my last reply. BltFast won''t work because I have a clipper attached to the back buffer. I took it out and then tried bltfast and it worked... but then my sprites wouldn''t clip anymore. Dammit! I guess I''m stuck with the normal Blt (bacon lettuce and tomatoes) and my game won''t be helluva fast. Oh well... I guess it''s the best i can do.
0

##### Share on other sites
Although I don''t have any direct knowledge that this is true, MOST, if not all, new video cards should perform identically performance-wise with both the Blt and BltFast methods, so you''re not losing anything. I could be wrong though.

0

##### Share on other sites
quote:
Original post by Bigshot

I guess I''m stuck with the normal Blt (bacon lettuce and tomatoes) and my game won''t be helluva fast. Oh well... I guess it''s the best i can do.

Use BltFast() and do your own clipping. It''s quite a bit faster as far as I can tell. I just posted a routine to do this in the Isometric Land forum earlier today.

//TOOM
0

##### Share on other sites
Hey. I was just reading about doing a software clipper. I''ll check out your code, but I have a question first. Wouldn''t using software clipping be slower than using DirectDraw''s hardware clipper? However, even if software clipping is slower (i''m not sure), the speed gain of using BltFast might outweigh the disadvantage of slower clipping. I really don''t have that many sprites on the screen so your solution would probably work better... and my game will be helluva fast!

Al
0

##### Share on other sites
Unless you need to do something more complex than a single rectangular clipping region, it's as simple as eight integer comparisons. I almost doubled the frame rate in my iso engine by moving from Blt() to BltFast(). The more sprites I have on screen the bigger the difference.

//TOOM

Edited by - toom on 1/24/00 8:55:25 PM
0

##### Share on other sites
Thanks a lot for your advice. I''m going to write the software clipper right now, dump the DirectDraw clipper, and use BltFast!!! I couldn''t find your post about software clipping, but i''ll just write it myself. One more question, if you''re still online... do you know how to implement triple buffering and is it worth it? I would have to create another surface, right? How difficult is it to implement?

Al
0

##### Share on other sites
To do triple buffering in DirectX simple set dwBackBufferCount to 2 in the DDSURFACEDESC2 structure that you use when creating the primary surface. I''m not sure that it''d be worth the extra video ram it takes up though.

Here''s my post on manual clipping:

In my game library I have the following structure defined (my most basic Graphic OBject, aka a Sprite):

typedef struct gob{   int width;   int height;   LPDIRECTDRAWSURFACE7 surface;} GOB;

I also have four global variables called ClipX, ClipY, ClipX2, and ClipY2 which define the clipping region. I set these via another function.

Then I have this routine to blit the GOB onto the back buffer (which is a global variable):

void glBlitGOB( GOB* g, int x, int y ){   RECT src;    // First I eliminate GOBs that are totally outside   // the clipping region.   if( x > ClipX2 )      return;   if( y > ClipY2 )      return;   if( x + g->width < ClipX )      return;   if( y + g->height < ClipY )      return;   // By default I want to blit the entire GOB   src.left = 0;   src.top = 0;   src.right = g->width;   src.bottom = g->height;   // But then I adjust the area to be blitted based on   // whether or not parts fall outside the clipping   // region.   if( x + src.right > ClipX2 )      src.right -= x + src.right - ClipX2 - 1;   if( y + src.bottom > ClipY2 )      src.bottom -= y + src.bottom - ClipY2 - 1;   if( x < ClipX )   {      src.left += ClipX - x;      x = ClipX;   }   if( y < ClipY )   {      src.top += ClipY - y;      y = ClipY;   }   // Then I blit it.   BackBuffer->BltFast( x, y, g->surface, &src, DDBLTFAST_SRCCOLORKEY / DDBLTFAST_WAIT );}

//TOOM
0

##### Share on other sites
To implement triple buffering all you have to do is to set the dwBackBufferCount to 2, and DirectX handles everything for you. But it will help you only if you''re blitting fast, and having some time idle while waiting for the flip, otherwise it wont help you too much... but triple buffering also costs vram so just use if it''s worthy. Try some benchmarks.

Good Luck,
Nicodemus.
0

##### Share on other sites
I guess you can write your own clipper code. But what I have read or seen and been told blt fast is only faster in software, not hardware in hardware it''s as fast!
0

##### Share on other sites
quote:
Original post by voodoo

I guess you can write your own clipper code. But what I have read or seen and been told blt fast is only faster in software, not hardware in hardware it''s as fast!

Not in my (admittedly limited) experience. I have a Diamond Viper 550 with 16 megs. As far as I know it''s using hardware blitting/clipping. With a few dozen sprites there was no difference, but when I populated my iso map with thousands of tree sprites my frame rate almost doubled by using BltFast() instead of Blt() with no other changes to the code.

It''s easy enough to test for yourself though.

//TOOM
0

##### Share on other sites
Ok, you probably have already solved this, but the screen is not RECT {0,0,640,480}. Try counting 0 to 640, including 0. You get 641. So have your ScreenRect = {0,0,639,479}. Then you have 640 x 480 pixels and it will work fine. Using a clipper to blit a background pic will just slow your program down a tiny bit.
0

##### Share on other sites
Yeah, I solved the problem a while ago. Using a RECT with {0,0,640,480} is actually the way to do it I''ve found. It seems that the rectangle numbers are inclusive for the bottom and right values so by setting the values to that the rectangles actually end up being 0,0,639,479... and it blits perfectly using BltFast. If I decrease the right and bottom values to 639 and 479 then the rectangle will only be 0,0,638,478 and a sliver of the screen won''t be rendered. Also, I''m not using Blt at all in my engine now. Everything is done with BltFast instead and for clipping sprites I just use software clipping. Here''s the exact code I used for blitting the background image (which is 1280x480) if anybody wants to know:

// copy background to screen helluva fast
RECT bg_rect = {Screen_Pan_X, 0, Screen_Pan_X + 640, 480};
lpddsback->BltFast(0,0,bg_surface,&bg_rect, DDBLTFAST_NOCOLORKEY / DDBLTFAST_WAIT);

Al
0

##### Share on other sites
To bad bltfast cant mirror images Gotta use blt for that one or your own routine.
0