Al
Why won't this code work?
Author
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
Al
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
//TOOM
Edited by - toom on 1/24/00 8:55:25 PM
Author
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
Al
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):
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):
//TOOM
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
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.
Good Luck,
Nicodemus.
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!
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
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.
Author
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
// 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
Gotta use blt for that one or your own routine.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
