Results 1 to 5 of 5

Thread: Direct2D

  1. #1


    Hello, I am rewriting my game engine (using GDI BitBlt only) and doing my first steps now with Direct2D rendering and using TDirect2DCanvas and RenderTarget + rendering bitmaps.
    When rendering one frame is the correct way to go as follows?
    1. Canvas.BeginDraw
    2. Paint my stuff
    3. Canvas.EndDraw

    I noticed that step 2 is very fast, but the combined steps 1+2+3 together are slow.
    How to speed up this? What is the best strategy?

    Thank you.

  2. #2
    Some extra info: using a fullscreen bitblt is hundreds of times faster, which makes me think: direct2d is almost exactly at 60FPS: my monitor's refresh rate.
    How is that possible? BitBlt does not wait for VSync? Any experts in here?

  3. #3
    I never used DirectX so I have no idea, but:

    Maybe DirectX takes information from graphics driver and synced itself to the monitor's refresh rate. If you use drawing directly then it will wait for VSync each time you call a drawing function, but if you use BeginDraw I suspect it disables VSync until you call EndDraw. Maybe that's the issue.
    No signature provided yet.

  4. #4
    As far as I know in modern Windozes all this ancient stuff - *especially* DirectDraw - are wrappers around something else.
    Some of those operations probably use Direct3d 12 under the hood and obey the rules of double-buffering. As required by desktop composition in Windows Vista and up.

    For example, (I'm using openGL) I noticed that when a transparent window was overlaying my window, the wglSwapBuffers call duration jumped dramatically. I could only conclude it's because the driver had to reroute the rendering output to desktop composition and was forced to wait for vsync.

    Generally, such ancient technologies as DirectDraw or DirectSound are only supported to allow ancient applications run. Expect them to work but do not expect them work optimally.
    I myself have one of goals to add support for Core Audio/WASAPI because while DirectSound 8 still works, it doesn't provide low-latency access to hardware buffers as it was doing in WinXP.

  5. #5
    Quote Originally Posted by Chebmaster View Post
    I myself have one of goals to add support for Core Audio/WASAPI because while DirectSound 8 still works, it doesn't provide low-latency access to hardware buffers as it was doing in WinXP.
    As far as I know from Windows Vista onward you can no longer access your sound hardware directly without some custom drivers. Everything goes through WASAPI. And Windows has full control of this Core Audio. And if it decides that some other part has greater priority the audio will suffer.
    I still remember of how much problems with audio I had on my Acer Aspire laptop with Realtek Sound Card and Windows 7 installed. Main problem was that laptop comes equipped with Tuba speaker to generate some strong base sounds. But since this tuba speaker receives combined sound from both left and right speakers (boosted to generate more base sounds) it is imperative that left and right channels remain in sync. If they get out of sync then any sound that was to be played on both left and right speakers at the same time gets garbled.
    So how can it come to this desynchronization of left and right channel? Realtek sound drivers are designed to process each of the sound channels within its own thread. But since threads are controlled by Windows Core Audio easily one of them might get lower priority and thus not being able to proces its data fast enough thus it becomes lagging behind.

    Any way after installing Window XP on that laptop the problem went away because on Windows XP sound drivers have full control over their own threads and can even run them with Realtime priority. On Windows Vista and newer sound drivers are no longer able to run their own threads with Realtime priority as they could on Windows XP.

    PS: As for DirectDraw as far as I know it is now simulated through DirectX. And it is simulated poorly at best. Many DirectDraw based games won't even draw properly (garbled colors) due the fact that DirectDraw simulations is quite limited. There are several 3rd party fixes for DirectDraw that try to fix such problems. One day I even saw one that instead of simulating DirectDraw with DirectX actually simulates it using OpenGL but unfortunately it wasn't stable enough and ran only on specific hardware.
    Last edited by SilverWarior; 21-03-2021 at 08:33 PM.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Comodo SSL