Author Topic: Dive: Why does not this work  (Read 1043 times)

Lars

  • Hero Member
  • *****
  • Posts: 1276
  • Karma: +65/-0
    • View Profile
Re: Dive: Why does not this work
« Reply #15 on: April 22, 2024, 12:27:08 pm »
The samples seem to indicate that you are forbidden to drive screen updates in between calls WM_VRNDISABLED and WM_VRNENABLED. That is, there is a timespan where you are not allowed to blit anything to the screen, that means, the Classicube draw buffer function should do nothing during that timespan.
That in turn means, the proper point in time to call DiveSetupBlitter are WM_VRNDISABLED and WM_VRNENABLED. The "Remarks" section for DiveSetupBlitter even states that DiveSetupBlitter is "not intended to be called at high frequency".

This would be even more relevant for direct screen updates (that is, if you used DiveAcquireFrameBuffer / DiveDeacquireFrameBuffer / DiveSwitchBank / DiveCalcFrameBufferAddress and direct writes to the video aperture "ppFrameBuffer" as returned by DiveOpen) but for already mentioned reasons you should not do that anyways.

Still, it looks as if DIVE still needs to be notified via DiveSetupBlitter when WM_VRNDISABLED and WM_VRNENABLED are called for a specific window even if you do not do direct screen updates.

Jochen Schäfer

  • Sr. Member
  • ****
  • Posts: 339
  • Karma: +28/-0
    • View Profile
Re: Dive: Why does not this work
« Reply #16 on: April 22, 2024, 12:35:44 pm »
I wonder then, how SDL work then. There is not one mention of WM_VRN*. It just blits the whole SDL surface to the buffer (no direct VRAM access).

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4807
  • Karma: +100/-1
    • View Profile
Re: Dive: Why does not this work
« Reply #17 on: April 22, 2024, 05:26:38 pm »
I wonder then, how SDL work then. There is not one mention of WM_VRN*. It just blits the whole SDL surface to the buffer (no direct VRAM access).

Cairo does the same. A comment in the code,
Code: [Select]
* This function uses DIVE to write those portions of the surface identified
* by @rect directly to the screen buffer.  It only supports 32- or 24-bit
* full-color video modes.  To avoid painting overlapping or child windows,
* it must perform all of the visible-region calculations that GPI normally
* handles.  Despite this, it provides a significant improvement in speed
* compared to using GPI functions.