• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

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

Bigshot

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites