• 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.

SikCiv

Fullscreen blit or flip??

9 posts in this topic

I can't see any reason why blitting should be faster. All flip() does is to exchange a few HW registers - What might be fooling you is that flip will lock if a blit is in progress, and wait for that blit to complete (Thus making flip() seem slow).

It might be that the DDraw implemenation of flip() actually copies memory on videocards that doesn't support flip or have insufficient memory - But in either case, you should use flip() to get the best (average) performance and avoid tearing...

/Niels

(Obviously, if you copy to the backbuffer and then flip, it would be faster to simply copy to the front buffer, but in this case, the difference should be next to nothing)...

0

Share this post


Link to post
Share on other sites
Flipping is always faster than blitting when surfaces are in video memory. If for some reason your surfaces are in system memory then on all video cards (except ones with dma ram to vram coping) blitting is faster than flipping and a simple mmx copy loop is the fastest method (only if you have no hardware support for sysmem surfaces).
0

Share this post


Link to post
Share on other sites
I believe the reason why Flip is slower than BltFast is that on some hardware Flip waits for the monitor refresh. This limits your fps to the refresh rate of the monitor.

BltFast doesn't wait for the refresh, therefore it would be faster on some machines.

Someone correct me if I'm mistaken.

Josh

0

Share this post


Link to post
Share on other sites
In an ideal world, flip should always be faster, up to the refresh rate anyway since it does wait for the VRT. (Does anyone know if there is any hack to avoid the wait for VRT when flipping?).

But I do think that both methods should be supported, because often (possibly translated rarely ) the driver's flip method is buggy. I've seen cards that will NOT flip faster than 45 frames per sec. The flip call will wait an entire extra frame every third frame for no reason. Using a wait VRT/blit method, this problem doesn't arise. (Actually the waitvrt function is a little screwy too, but it misses about 1 in 20 frames only. Too bad many video drivers just plain suck).

Rock

0

Share this post


Link to post
Share on other sites
To do a Flip without waiting for VSYNC, just use the flag DDFLIP_NOVSYNC. You also have to make sure the surface actually supports the DDCAPS2_FLIPNOVSYNC flag in the DDCAPS structure for the surface.

------------------

-Kentamanos

0

Share this post


Link to post
Share on other sites
I am not anything of a guru of this but anyway...

As Niels says, the flip() waits for any blt to finish first and that makes the program slow, but then a little solution would be with two buffers instead of one, thus the flip() can always flip one buffer while you are blting to anotherone. And used with the DDFLIP_NOVSYNC flag, this could be brought to pretty good speeds. Never tried it myself though...

Christoffer Sandberg
todderod@algonet.se

0

Share this post


Link to post
Share on other sites
Rats, is DDFLIP_NOVSYNC part of DX6? I'm using DX5, and it isn't available. Which brings up another question that I'll try to squeeze into this discussion. If I program for DX5, and the user has DX6 runtime, is the DX code that is used still DX5? I know I still can't use the flip_novsync flag and what not, but if DX6 is faster or whatever, do I get any benefit for that, or would I have to use the DX6/7 interfaces to benefit?

And are video drivers somehow hooked to a DX version? If the card in question flips at 45FPS with DX5, as I mentioned above, might the problem not exist if I used DX6 interfaces? Do card manufacturers support the latest DX and that's all, or is this not an issue?

Rock

0

Share this post


Link to post
Share on other sites
There's no simple answer to all those questions , but I'll give it a shot:

You will benefit from DirectX improvements ONLY if these improvements are made on the interfaces you are using. As you've probably noticed, MS frequently adds new interfaces with names like xxxSurface2, xxxSurface3 etc. - Obviously, if all the improvements from one version of DX to the next is in new intefaces, your old code won't benefit from it.

DirectX as such is not tied directly to the hardware - it use a HW specific driver. I.e. a bug such as the one mentioned in flip() can be fixed with a new driver (regardless of the version of DX). IF, one is available, that is.

/Niels

(BTW. Interresting about the slow flip() when out of VMem - I figured it might work like that, but I've never seen it happen, or read about it for that matter. (Yep, I got a TNT2 so it's unlikely to happen in the 640x480 16-bit color mode I'm using )

0

Share this post


Link to post
Share on other sites
OK, DX is not tied to the hardware, but is a hardware driver tied to a DX version? If I wrote DX drivers, would I need a new driver for each version of DX? I would think SOMETHING needs to be added to the driver for any extra features that DX added. But it seems like a large burden on the driver coders too if this is the case. (Well, better them than us ).

And if drivers are written for DX7, would they perform differently than their DX5 versions if I as the end developer still used the DX5 interface instead of the new DX7 interface? Am I basically using an old driver if I use an old DX interface?

I'm just wondering if this flip bug I've seen (for a card that unfortunately doesn't have any new drivers that work correctly for me) might be a bug only in the driver for the DX5 interface, and if I went up to supporting DX6 or 7, maybe the driver written for DX6 won't have that bug? Are there different sections of the driver code that are used depending on what DX interface I use? If so, I guess it is VERY unwise to write a program for anything but the latest DX version, since card manufacturers aren't going to be as diligent about old driver code as they are about new code.

Am I making any sense anymore? I should probably start a new thread for this.

0

Share this post


Link to post
Share on other sites
When updating the screen, is flipping using ->flip(), or a fullscreen BlitFst better/safer???

I have tried it on various machines, and some are actually faster when using blitfst instead of flip!

Maybe its a good idea to pre-test the performance of both techniques on load up of my game/app, and use the faster one to ensure I am delivering maximum performance?!

0

Share this post


Link to post
Share on other sites