Clipping bltFast().
I''m working on a side-scrolling platform game and I''ve been having trouble blitting tiles. I tried using the normal blt() and using a clipper but it was incredibly slow (640x480x16 resolution). Then I changed it to bltFast and it was much faster, however the tiles at the edge of the screen disapear since there is no clipper. I tried an algorithm that checks if the blit is at the edge of the screen and moves the source rectangle and keeps the x = 0 to create the illusion that it is moving. Is this right? I''d also apreciate some info on how to do pixel-perfect collision detection using directX and how to make something solid (eg ground tiles so the character doesn''t fall through). I''m using windows NT (don''t ask why) so I have to use directX 3.0. That''s about all.
-Xargon, master of the Infinite Void.
-Xargon, Master of the Infinite Void.
I have only one thing to say, Why in the bloody hell are you using directx 3, LMAO.
Possibility
Possibility
You need to make sure that the rects you send to BltFast fit entirely on the screen (i.e. clip them yourself). However, there shouldn''t really be any difference between BltFast and Blit (although it depends on the gfx card, and maybe DX3 had problems here - I don''t know)
how to clip yourself and use bltfast:
//in: x,y are unclipped destination, rcSrc is source rect before clipping, rcClip is clipping rect
//out: x,y are clipped destination, rcSrc is source rect
//BEGIN
RECT rcDst;//need destination rect for clipping
CopyRect(&rcDst,&rcSrc);//copy dst from src
OffsetRect(&rcDst,x-rcSrc.left,y-rcSrc.top);//offset dst to proper position
int dx=rcSrc.left-rcDst.left;//calculate difference in x from dst to src
int dy=rcSrc.top-rcDst.left;//calculate difference in y from dst to src
IntersectRect(&rcDst,&rcDst,&rcClip);//clip the dst rect
CopyRect(&rcSrc,&rcDst);//copy dst to src
OffsetRect(&rcSrc,dx,dy);//offset to proper position
x=rcDst.left;//grab x dst
y=rcDst.top;//grab y dst
//END
//in: x,y are unclipped destination, rcSrc is source rect before clipping, rcClip is clipping rect
//out: x,y are clipped destination, rcSrc is source rect
//BEGIN
RECT rcDst;//need destination rect for clipping
CopyRect(&rcDst,&rcSrc);//copy dst from src
OffsetRect(&rcDst,x-rcSrc.left,y-rcSrc.top);//offset dst to proper position
int dx=rcSrc.left-rcDst.left;//calculate difference in x from dst to src
int dy=rcSrc.top-rcDst.left;//calculate difference in y from dst to src
IntersectRect(&rcDst,&rcDst,&rcClip);//clip the dst rect
CopyRect(&rcSrc,&rcDst);//copy dst to src
OffsetRect(&rcSrc,dx,dy);//offset to proper position
x=rcDst.left;//grab x dst
y=rcDst.top;//grab y dst
//END
Get off my lawn!
I find that it''s generally better to blit to a larger off-screen surface then flip only the visible portion to the screen rather than actually clipping on a per-tile bases. But this only really works is your tiles are of uniform size. If you''re video card supports wide surfaces this is easy (and most do). I simply shrunk my gamescreen by a tile''s width if no wide surface support was detected.
assuming 32x32 tiles and only side (horizontal) scrolling:
My off screen surface was 672x480 if wide-srufaces were available and my drawto rectangle was 0,0,640,48 and my number of tiles drawn across was 21.
If wide screen surfaces were not available my surface was 640x480, but my drawto rectangle was 16,0,624,480 and my number of tiles draw across was 20.
Often one can hide the border with display panels and what-not and not worry about wide-surfaces. I worried about them for keeping things resolution independent.
-m
mat williams
Lead Programmer, Designer
Zero Sum Software
www.zero-sum.com
assuming 32x32 tiles and only side (horizontal) scrolling:
My off screen surface was 672x480 if wide-srufaces were available and my drawto rectangle was 0,0,640,48 and my number of tiles drawn across was 21.
If wide screen surfaces were not available my surface was 640x480, but my drawto rectangle was 16,0,624,480 and my number of tiles draw across was 20.
Often one can hide the border with display panels and what-not and not worry about wide-surfaces. I worried about them for keeping things resolution independent.
-m
mat williams
Lead Programmer, Designer
Zero Sum Software
www.zero-sum.com
mat williamsLead Programmer, DesignerZero Sum Softwarewww.zero-sum.com
NT is NOT limited to Directx3, get the service packs, they are free, you can update to like dx5 i know for sure, and I beleive you can probably get dx7 now for NT. So there is absolutely no excuse for using dx3, lol.
Possibility
Possibility
NT only supports DX3a. (Even with SP 6)
Windows 95/98/ME/2000 supports upto DX8.
.
Take the time to read the DX FAQ
Namely the part that says:
Q. Is DirectX compatible with Windows NT 4.0?
A. Yes. However, the only version supported on Windows NT 4.0 is DirectX 3.0a. You must also install Windows NT 4.0 Service Pack 6.
Windows 95/98/ME/2000 supports upto DX8.
.
Take the time to read the DX FAQ
Namely the part that says:
Q. Is DirectX compatible with Windows NT 4.0?
A. Yes. However, the only version supported on Windows NT 4.0 is DirectX 3.0a. You must also install Windows NT 4.0 Service Pack 6.
I agree with the other people in this thread.
Why use NT4 at all? W2k is MUCH nicer and it is built on the NT kernel...so you still get the same stability. Plus, it supports more cards that NT4.
-Coleco
Rock the cradle of love!
You stupid WANKER!
mmmmmmmmmmkay
--HASBRO SUCKS--
Why use NT4 at all? W2k is MUCH nicer and it is built on the NT kernel...so you still get the same stability. Plus, it supports more cards that NT4.
-Coleco
~ c o l ec o ~
Rock the cradle of love!
You stupid WANKER!
mmmmmmmmmmkay
--HASBRO SUCKS--
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement