Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Performance cost of preparing off-screen

Author
Message
BatVink
Moderator
23
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 25th Aug 2011 13:11
Link
I asked this question in another thread and then lost track of the thread

There is a technique used by some developers where they prepare their display off-screen, then paste it in before a Sync. I have seen various, similar methods:

To a bitmap
To the camera
To a render target
to an image which is used as a sprite texture

Does anyone have any information about how efficient this is, performance loss, best way to do it etc? I have a situation where my 2D/3D combination is proving difficult in terms of layering.

Back to top
Profile PM Email
Grog Grueslayer
Valued Member
21
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 25th Aug 2011 17:38
Link
Back when I programmed in Quickbasic 4.5 it was the preferred method to prepare everything on another page. It was that way because the main screen was always seen by the user so they would actually see the menus/game being drawn otherwise. In QB it was called page flipping but it's basically set up like Darkbasic's bitmap commands.

The best way to do it you probably already know. Just create bitmap 1 as the same screen size, draw everything you want the user to see and use COPY BITMAP 1,0 to put it on the main view screen. And of course only redraw the bitmap as needed.

Back to top
Profile PM Email
DVader
22
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 25th Aug 2011 18:13
Link
I have used the method a fair bit in DB for the reasons Grog outlines. Also for colour sprite collision methods. I haven't noticed any major issues with speed, at least on the systems I have tested on.
I am getting a slight tearing effect on netbooks, with my first AppGameKit project. I imagine it is probably because I am having to draw everything to the main screen on the fly, and it can't quite keep up to speed. Reducing it down to 50 fps, it clears but then moves a little jerkily for my tastes.
It was a major advantage on Amiga systems many moons ago over the (supposedly) more powerful PC counterparts of the day. Any scrolling game in the early 90's tended to move better on the Amiga due to this double buffering technique.
The idea is fairly simple, draw your graphics on screen 1, and when done copy to screen 0 using the copy bitmap command. Rinse and repeat. You can use get image and paste image, but copy bitmap is way faster. You could also use this method for having multiple game windows and copying parts of the bitmap over.

http://s6.bitefight.org/c.php?uid=103081
Back to top
Profile PM Website
WLGfx
18
Years of Service
User Offline
Joined: 1st Nov 2007
Location: NW United Kingdom
Posted: 25th Aug 2011 20:23
Link
From what I remember the actual syncing gives the engine two options depending on the setup of the graphics card itself. It can either flip the screen, which is the faster method, or it will blit the screen. That's when you're using a back buffer. Preparing your screen and then pasting/copying it to the back buffer seems a complete waste of time in both cases as your taking the time to blit the entire screen contents first.

DVadar has covered already what I've said.

Some programmers (me also) used to use triple buffering for even higher frame rates on the old Amiga using the flip method.

Warning! May contain Nuts!
Back to top
Profile PM Email Website
enderleit
19
Years of Service
User Offline
Joined: 30th May 2007
Location: Denmark
Posted: 25th Aug 2011 22:59
Link
I believe DBPro (or rather DirectX) enforces double buffering. Stuff is ALWAYS drawn to the backbuffer and then copied/flipped to the front buffer when you use Sync. You will likely have tearing no matter what unless you lock the sync rate to the screens refresh rate, by using set display mode WIDTH, HEIGHT, DEPTH, 1

Tearing occurs because when you sync and the rate is not locked the back buffer will be copied/flipped immediately without waiting for the screens vertical retrace period. (When the "beam" reaches the bottom)

- Martin Enderleit
http://sites.google.com/site/menderleit
Back to top
Profile PM Email Website
BatVink
Moderator
23
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 26th Aug 2011 11:32
Link
Thanks all, I think the discussion is a little off-track though. I'm quite happy with the way things "normally" work, and DirectX handles all the double-buffering etc etc.

What I'm looking at is where you use off-screen construction of your screen for other reasons. For example, I want to compress a few layers of objects into one 2D backdrop. Then I want to transfer this to the ourput along with some other objects. So the question is about what kind of performance hit I can expect.

So far it sounds like using a bitmap is the best option for speed? But is this the most versatile?

Back to top
Profile PM Email
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 26th Aug 2011 13:01
Link
Images would probably be more versatile - you can't 'paste' a bitmap with transparency for instance, apply pixel shader effects or otherwise manipulate the 'copy' other than resizing - all of which can be done with images and Image Kit

Get the latest Matrix1Utility plug-ins (20-APR-2011)
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2026-07-11 10:26:17
Your offset time is: 2026-07-11 10:26:17