ClassiCube porting thread

[Lars]

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]

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]

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]

Update: I got it working by setting up the RECTL in SETUP_BLITTER::pVisDstRects correctly.
Now, a picture is shown.

[Lars]

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".

[Jochen Schäfer]

I now do a

Code: [Select]

WinGetWindowRect(hwndClient, &rect); and it works.

[Jochen Schäfer]

For the sound support, I open an audio device and created a Dart mixer.
As I understand it, I can only open one mixer and then have to mix different sound myself. Is this understanding correct, or is there a way to let OS/2 do the mixing.

[KO Myung-Hun]

Hi/2.

libkai can mixer multiple audio streams. How about consider it ?

KO Myung-Hun

[Jochen Schäfer]

Sure, I could use that. But I just wanted to understand DART.

[KO Myung-Hun]

DART itself support multiple streams with sharable mode if an audio driver supports it like SBLive!. Unfortunately, however, Uniaud does not support multiple streams. I'm not sure USB audio driver by Lars support it.

[Lars]

USB audio does not support multiple streams in general as far as the standard goes.Effectively, it only has one isochronous streaming input pipe (and potentially an additional streaming output pipe for recording) and its capability is adjustable to the necessary bandwidth.
At least I have never seen an USB audio sound device that would provide more than one streaming input pipe.

[Jochen Schäfer]

Thanks for explanations.

Another question: I assume, that sound buffers want its data in Little Endian layout. Am I correct?

[Lars]

DART was IBM's half-baked effort to provide some sophsticated sound processing. What it ended up with is the ability to control streaming to an audio device largely by the application (instead of trusting the streaming manager). That's about it.

yes, you are correct, sound data always is in little endian format.

[Jochen Schäfer]

So I'm getting along, but I noticed some behaviour, I can't explain and I haven't find any clue in the Toolkit help.
While in the Launcher window or while in Game window with the menu open, the pointer isn't captured, so ALT+F4 works.
But in Game window with the menu closed, the pointer is captured, and then ALT+F4 will not work, while other keypresses are sending WM_CHARs.
Has someone a hint, what is happpening here?

[Lars]

I can just guess but Alt+F4 is a special key combination (to close a window) that might not be passed on verbatim to the Window Procedure in the WM_CHAR message.

Maybe you have to catch the WM_TRANSLATEACCEL message and handle that special key combination there.

Or, reading the help for WM_CHAR, Alt-F4 might be translated into a WM_COMMAND or WM_SYSCOMMAND message (likely a WM_SYSCOMMAND message with uscmd = SC_CLOSE).