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

Lars

  • Hero Member
  • *****
  • Posts: 1277
  • 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: 342
  • Karma: +29/-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: 4808
  • 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.

Jochen Schäfer

  • Sr. Member
  • ****
  • Posts: 342
  • Karma: +29/-0
    • View Profile
Re: Dive: Why does not this work
« Reply #18 on: Today at 08:23:02 am »
Update: I got it working by setting up the RECTL in SETUP_BLITTER::pVisDstRects correctly.
Now, a picture is shown.

Lars

  • Hero Member
  • *****
  • Posts: 1277
  • Karma: +65/-0
    • View Profile
Re: Dive: Why does not this work
« Reply #19 on: Today at 02:28:43 pm »
I suppose it should be:

 rect.xLeft = 0;
 rect.yTop = r.Height;
 rect.xRight = r.Width;
 rect.yBottom = 0;

because I assume that the coordinate system to be used is still the OS/2 PM coordinate system [bottom left is (0,0)], correct ?

By the way:
setupBlitter.lDstPosX          = 0;
setupBlitter.lDstPosY          = 0;

You would only ever set these to anything else if you blitted into a memory buffer (also allocated via DiveAllocImageBuffer) instead of to the screen. But maybe DIVE ignores this anyway if you specify DIVE_BUFFER_SCREEN as the destination blit buffer in "DiveBlitImage".
« Last Edit: Today at 02:31:10 pm by Lars »

Jochen Schäfer

  • Sr. Member
  • ****
  • Posts: 342
  • Karma: +29/-0
    • View Profile
Re: Dive: Why does not this work
« Reply #20 on: Today at 05:15:48 pm »
I now do a
Code: [Select]
WinGetWindowRect(hwndClient, &rect); and it works.