DirectDraw isn't fast AT ALL 
Author Message
 DirectDraw isn't fast AT ALL

Hello,

I've written an Isometric Viewpoint Tile Based Engine.

Using BitBlt and other API functions, I achieved a framerate of about 6
average, so I decided to switch to DirectDraw.

When I didn't use a BackBuffer but drew directly to the primary surface
(using BltFast) I got framerates over 60! The only problem was all the
flickering, because I do at lot of transparancy stuff.

So I used a backbuffer to draw everything to. After a lot of hassles I
finally got it working. The flickering is completely gone, but at what cost:
the framerate is now 1, or maybe two if I'm lucky.

Does this mean DirectDraw sucks (unlikely) or does this mean I'm doing
something really, really wrong here?

Thanks,
- Wouter Lievens



Thu, 02 Dec 2004 22:27:38 GMT  
 DirectDraw isn't fast AT ALL
I've (partially) fixed my problem by changing the following:

  ddsdBack.ddsCaps.lCaps = DDSCAPS_OFFSCREENPLAIN Or DDSCAPS_SYSTEMMEMORY

To:

  ddsdBack.ddsCaps.lCaps = DDSCAPS_OFFSCREENPLAIN

I interpret this as forcing the backbuffer to use the video memory instead
of the RAM memory which speeds the whole thing up. Is that right?

Anyway, framerate is now from 30 to 46 which is GOOD. But, the rest of the
screen that is not drawn onto is _really_ screwed... is there a way to fix
that? I've done so for a part, by increasing the picture in which I draw.

Greets,
Wouter



Quote:
> Hello,

> I've written an Isometric Viewpoint Tile Based Engine.

> Using BitBlt and other API functions, I achieved a framerate of about 6
> average, so I decided to switch to DirectDraw.

> When I didn't use a BackBuffer but drew directly to the primary surface
> (using BltFast) I got framerates over 60! The only problem was all the
> flickering, because I do at lot of transparancy stuff.

> So I used a backbuffer to draw everything to. After a lot of hassles I
> finally got it working. The flickering is completely gone, but at what
cost:
> the framerate is now 1, or maybe two if I'm lucky.

> Does this mean DirectDraw sucks (unlikely) or does this mean I'm doing
> something really, really wrong here?

> Thanks,
> - Wouter Lievens



Thu, 02 Dec 2004 23:25:46 GMT  
 DirectDraw isn't fast AT ALL
no. offscreenplain doesnt imply video memory.

how do the ddraw  SDK samples operate?

perhaps examining them would be good?

--
Phil Taylor
PM : DirectX SDK, Managed DirectX, Windows XP Inbox 3D screensavers, and a
few more bits and bobs.
http://msdn.microsoft.com/directx
This posting is provided "AS IS" with no warranties, and confers no rights.

Quote:
> I've (partially) fixed my problem by changing the following:

>   ddsdBack.ddsCaps.lCaps = DDSCAPS_OFFSCREENPLAIN Or DDSCAPS_SYSTEMMEMORY

> To:

>   ddsdBack.ddsCaps.lCaps = DDSCAPS_OFFSCREENPLAIN

> I interpret this as forcing the backbuffer to use the video memory instead
> of the RAM memory which speeds the whole thing up. Is that right?

> Anyway, framerate is now from 30 to 46 which is GOOD. But, the rest of the
> screen that is not drawn onto is _really_ screwed... is there a way to fix
> that? I've done so for a part, by increasing the picture in which I draw.

> Greets,
> Wouter



> > Hello,

> > I've written an Isometric Viewpoint Tile Based Engine.

> > Using BitBlt and other API functions, I achieved a framerate of about 6
> > average, so I decided to switch to DirectDraw.

> > When I didn't use a BackBuffer but drew directly to the primary surface
> > (using BltFast) I got framerates over 60! The only problem was all the
> > flickering, because I do at lot of transparancy stuff.

> > So I used a backbuffer to draw everything to. After a lot of hassles I
> > finally got it working. The flickering is completely gone, but at what
> cost:
> > the framerate is now 1, or maybe two if I'm lucky.

> > Does this mean DirectDraw sucks (unlikely) or does this mean I'm doing
> > something really, really wrong here?

> > Thanks,
> > - Wouter Lievens



Fri, 03 Dec 2004 06:35:24 GMT  
 DirectDraw isn't fast AT ALL
Thanks for replying,

Actually, I do pretty much exactly the same thing as in the examples in the
SDK (exactly as in copy-paste!), but I draw several millions (30x30 tile in
3 layers, with transparancy, each being 48x144 pixels in size) of pixels
each loop, so I guess even the examples can't keep up to that speed as they
draw only one sprite or so :-)

Anyway, it's solved now, except for the scrambled part of the screen, but I
can hide that away with some tinkering.



Quote:
> no. offscreenplain doesnt imply video memory.

> how do the ddraw  SDK samples operate?

> perhaps examining them would be good?

> --
> Phil Taylor
> PM : DirectX SDK, Managed DirectX, Windows XP Inbox 3D screensavers, and a
> few more bits and bobs.
> http://msdn.microsoft.com/directx
> This posting is provided "AS IS" with no warranties, and confers no
rights.


> > I've (partially) fixed my problem by changing the following:

> >   ddsdBack.ddsCaps.lCaps = DDSCAPS_OFFSCREENPLAIN Or

DDSCAPS_SYSTEMMEMORY

- Show quoted text -

Quote:

> > To:

> >   ddsdBack.ddsCaps.lCaps = DDSCAPS_OFFSCREENPLAIN

> > I interpret this as forcing the backbuffer to use the video memory
instead
> > of the RAM memory which speeds the whole thing up. Is that right?

> > Anyway, framerate is now from 30 to 46 which is GOOD. But, the rest of
the
> > screen that is not drawn onto is _really_ screwed... is there a way to
fix
> > that? I've done so for a part, by increasing the picture in which I
draw.

> > Greets,
> > Wouter



> > > Hello,

> > > I've written an Isometric Viewpoint Tile Based Engine.

> > > Using BitBlt and other API functions, I achieved a framerate of about
6
> > > average, so I decided to switch to DirectDraw.

> > > When I didn't use a BackBuffer but drew directly to the primary
surface
> > > (using BltFast) I got framerates over 60! The only problem was all the
> > > flickering, because I do at lot of transparancy stuff.

> > > So I used a backbuffer to draw everything to. After a lot of hassles I
> > > finally got it working. The flickering is completely gone, but at what
> > cost:
> > > the framerate is now 1, or maybe two if I'm lucky.

> > > Does this mean DirectDraw sucks (unlikely) or does this mean I'm doing
> > > something really, really wrong here?

> > > Thanks,
> > > - Wouter Lievens



Fri, 03 Dec 2004 15:45:29 GMT  
 DirectDraw isn't fast AT ALL


Quote:
> Thanks for replying,

> Actually, I do pretty much exactly the same thing as in the examples in
the
> SDK (exactly as in copy-paste!), but I draw several millions (30x30 tile
in
> 3 layers, with transparancy, each being 48x144 pixels in size) of pixels
> each loop, so I guess even the examples can't keep up to that speed as
they
> draw only one sprite or so :-)

> Anyway, it's solved now, except for the scrambled part of the screen, but
I
> can hide that away with some tinkering.

Also, if you're using the Debug runtime, then switching to the Retail
runtime will significantly increase your frame rate, too.


Fri, 03 Dec 2004 23:58:51 GMT  
 DirectDraw isn't fast AT ALL
good point, always do perf testing under the retail runtime.

--
Phil Taylor
PM : DirectX SDK, Managed DirectX, Windows XP Inbox 3D screensavers, and a
few more bits and bobs.
http://msdn.microsoft.com/directx
This posting is provided "AS IS" with no warranties, and confers no rights.

Quote:



> > Thanks for replying,

> > Actually, I do pretty much exactly the same thing as in the examples in
> the
> > SDK (exactly as in copy-paste!), but I draw several millions (30x30 tile
> in
> > 3 layers, with transparancy, each being 48x144 pixels in size) of pixels
> > each loop, so I guess even the examples can't keep up to that speed as
> they
> > draw only one sprite or so :-)

> > Anyway, it's solved now, except for the scrambled part of the screen,
but
> I
> > can hide that away with some tinkering.

> Also, if you're using the Debug runtime, then switching to the Retail
> runtime will significantly increase your frame rate, too.



Sun, 05 Dec 2004 10:23:04 GMT  
 DirectDraw isn't fast AT ALL
What do you mean by that? I just check things from the Visual Basic Editor.
What did you mean about the runtime?

Sorry for all the dumb questions, I'm new to DirectX!

Quote:
> good point, always do perf testing under the retail runtime.

> --
> Phil Taylor
> PM : DirectX SDK, Managed DirectX, Windows XP Inbox 3D screensavers, and a
> few more bits and bobs.
> http://msdn.microsoft.com/directx
> This posting is provided "AS IS" with no warranties, and confers no
rights.




> > > Thanks for replying,

> > > Actually, I do pretty much exactly the same thing as in the examples
in
> > the
> > > SDK (exactly as in copy-paste!), but I draw several millions (30x30
tile
> > in
> > > 3 layers, with transparancy, each being 48x144 pixels in size) of
pixels
> > > each loop, so I guess even the examples can't keep up to that speed as
> > they
> > > draw only one sprite or so :-)

> > > Anyway, it's solved now, except for the scrambled part of the screen,
> but
> > I
> > > can hide that away with some tinkering.

> > Also, if you're using the Debug runtime, then switching to the Retail
> > runtime will significantly increase your frame rate, too.



Sun, 05 Dec 2004 15:43:40 GMT  
 DirectDraw isn't fast AT ALL
When you install the DX SDK, you're given a choice to install the Debug
(default) or Retail runtime. The debug runtime has extra checks internally
to make sure that you're using the API correctly. It also emit debug info
that is displayed on your IDE (this is what causes the slow down). Come to
think of it, I'm not sure if VB displays this info. But if you want to
switch between Debug or Runtime, go to Start -> Programs -> Microsoft
DirectX 8.1 SDK -> Runtime Installs.


Quote:
> What do you mean by that? I just check things from the Visual Basic
Editor.
> What did you mean about the runtime?

> Sorry for all the dumb questions, I'm new to DirectX!

> > good point, always do perf testing under the retail runtime.

> > --
> > Phil Taylor
> > PM : DirectX SDK, Managed DirectX, Windows XP Inbox 3D screensavers, and
a
> > few more bits and bobs.
> > http://msdn.microsoft.com/directx
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.




> > > > Thanks for replying,

> > > > Actually, I do pretty much exactly the same thing as in the examples
> in
> > > the
> > > > SDK (exactly as in copy-paste!), but I draw several millions (30x30
> tile
> > > in
> > > > 3 layers, with transparancy, each being 48x144 pixels in size) of
> pixels
> > > > each loop, so I guess even the examples can't keep up to that speed
as
> > > they
> > > > draw only one sprite or so :-)

> > > > Anyway, it's solved now, except for the scrambled part of the
screen,
> > but
> > > I
> > > > can hide that away with some tinkering.

> > > Also, if you're using the Debug runtime, then switching to the Retail
> > > runtime will significantly increase your frame rate, too.



Sun, 05 Dec 2004 22:35:30 GMT  
 DirectDraw isn't fast AT ALL
Thank you!



Quote:
> When you install the DX SDK, you're given a choice to install the Debug
> (default) or Retail runtime. The debug runtime has extra checks internally
> to make sure that you're using the API correctly. It also emit debug info
> that is displayed on your IDE (this is what causes the slow down). Come to
> think of it, I'm not sure if VB displays this info. But if you want to
> switch between Debug or Runtime, go to Start -> Programs -> Microsoft
> DirectX 8.1 SDK -> Runtime Installs.



> > What do you mean by that? I just check things from the Visual Basic
> Editor.
> > What did you mean about the runtime?

> > Sorry for all the dumb questions, I'm new to DirectX!

> > > good point, always do perf testing under the retail runtime.

> > > --
> > > Phil Taylor
> > > PM : DirectX SDK, Managed DirectX, Windows XP Inbox 3D screensavers,
and
> a
> > > few more bits and bobs.
> > > http://msdn.microsoft.com/directx
> > > This posting is provided "AS IS" with no warranties, and confers no
> > rights.




> > > > > Thanks for replying,

> > > > > Actually, I do pretty much exactly the same thing as in the
examples
> > in
> > > > the
> > > > > SDK (exactly as in copy-paste!), but I draw several millions
(30x30
> > tile
> > > > in
> > > > > 3 layers, with transparancy, each being 48x144 pixels in size) of
> > pixels
> > > > > each loop, so I guess even the examples can't keep up to that
speed
> as
> > > > they
> > > > > draw only one sprite or so :-)

> > > > > Anyway, it's solved now, except for the scrambled part of the
> screen,
> > > but
> > > > I
> > > > > can hide that away with some tinkering.

> > > > Also, if you're using the Debug runtime, then switching to the
Retail
> > > > runtime will significantly increase your frame rate, too.



Mon, 06 Dec 2004 15:29:31 GMT  
 DirectDraw isn't fast AT ALL
Quote:
> What do you mean by that? I just check things from the Visual Basic

Editor.

I just thought I would add that VB programs run faster as an .exe, than when
in the editor.

--
Eric DeBrosse
http://www.mvps.org/vbdx/
Microsoft Visual Basic DirectX MVP

The opinions expressed in this message are my own personal views and
do not reflect the official views of Microsoft Corporation. The MVP program
does not constitute employment or contractual obligation with Microsoft.



Wed, 08 Dec 2004 09:40:42 GMT  
 DirectDraw isn't fast AT ALL
        One thing you might want to try is implement a "dirty rectangle"
approach to drawing your tiles. Meaning, only draw the tiles that have
been updated, since the previous frame. Drawing every tile over on every
frame will have a -HUGE- impact on your frame rate, and with multiple
layers, the frame rate decrease is exponential.

Hope this helps,
Matt Rudder



Quote:
> Thanks for replying,

> Actually, I do pretty much exactly the same thing as in the examples
> in the SDK (exactly as in copy-paste!), but I draw several millions
> (30x30 tile in 3 layers, with transparancy, each being 48x144 pixels
> in size) of pixels each loop, so I guess even the examples can't keep
> up to that speed as they draw only one sprite or so :-)

> Anyway, it's solved now, except for the scrambled part of the screen,
> but I can hide that away with some tinkering.



Sun, 03 Apr 2005 13:01:26 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. Microsoft's OLE DB Simple Provider 1.5 Library isn't cutting it :(

2. Seek Method isn't working...

3. Why isn't my code working?

4. Help! by VBA isn't working

5. On Error GoTo isn't working

6. OLE server isn't registered

7. Error 3075: function isn't available in expressions in query expression

8. Function isn't available in expressions in qyeryexpression

9. There isn't enough free memory to update the display

10. ACC97: There isn't enought disk space or memory

11. Ensuring a Database Isn't Corrupted (ACC95)

12. Function isn't available in expressions in query expression

 

 
Powered by phpBB® Forum Software