1
Programming / Re: Dive: Why does not this work
« 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.
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.