DxWnd v2.05.89.rc1

[gho]

Again, before I lose control, a release candidate with all the last fixes, plus something more.
Compared with the last leaked beta, this one has:

• alignment of the CDA proxy (winmm.dll) to the last fixed made in DxWnd CDA
• renaming of "FULLSCREENONLY" to "FORCEWINDOWING", as requested
• CDPlayer now saves the last volume level (small fix, but handy).

For sure, what's currently missing is an alignment of all man pages and .ini descriptions.

I'm not going to post two files for sources and build: the build is in the "build" folder of this single archive.
Hopefully I didn't mess with sources, but in case please tell me.

[huh]

fix: [mciwrapper.cpp] now sending MM_MCINOTIFY message also when target hWnd is NULL

I'd like to know your opinion that this behavior should ONLY be present in the "CDAudio-CD audio emulation-Win 9x MCI" flag (if it's not already, I haven't had time to try). Since Messiah does not work correctly in WinXP, as confirmed by me and later by BEEN_Nath_58 in the link below, this Messiah behavior was already illegal in WinXP.
https://sourceforge.net/p/dxwnd/discussion/general/thread/0d852410/?page=66#7381

[gho]

I don't know. Microsoft is very stingy on comments about this aspect. When the MCI_NOTIFY option is set, a message is requested for the window handle specified into the argument specified. Nowhere is said that the value should correspond to a valid window handle and in effect it seems that the conventional value 0xFFFF refers to the topmost window. But I wonder if 0x0000 could correspond to some other sort of conventional value and, in that case, in what conditions.
In theory, if that wouldn't be true, 0x0000 would simply be a wrong window handle and Messiah.exe would never receive a notification message, so it wouldn't work in any Window versions. But since it worked (so it seems) and the logs tell that the window handle is still 0x0000, that should mean that the MCI Window system knows how to treat this special case.
A possible and plausible guess could be that 0x0000 identifies the main window in all situations where a window doesn't really exists, that is when the game sets the video for fullscreen mode, but again it would be nice to get this confirmed by facts or documentation.
In any case, so far the replacement of 0x0000 with either 0xFFFF or the actual window handle seems a working choice, so I would stick to this until the contrary is proven.
By the way, also the 0xFFFF handle has a strange behavior because I made this experiment: I set the configuration with The MCINotifyTopmost tweak and then moved the focus to another window while the game was running (in these conditions the focus is lost, the game stops but the CDA still keeps playing) and I waited for the end of the track, expecting that the notification message would be lost. Instead, the game received the notification and repeated the track all the same.

[BEEN_Nath_58]

The strange behaviour that you explained with lost focus also happens on Windows XP. As I wrote somewhere earlier, I believe the message gets sent to whatever the topmost windows is, even if it's not a game.

I said this because on my Windows XP, the game continues to play the CD audio for quite some time and then stops.

Also you told you replaced 0x0000 with 0xFFFF but you already did that on 2.05.89.messiah.rar, so what changed in 2.05.89.messiah2.rar that fixed the issue (I know the following release was bug fix for something)?

The only thing I would like to check is if the game on Win98 plays music when Windows button is pressed. And if it's applicable to XP too.

Don't delete that game, we have some windowed mode things to fix...

[dippy dipper]

By the way, also the 0xFFFF handle has a strange behavior because I made this experiment: I set the configuration with The MCINotifyTopmost tweak and then moved the focus to another window while the game was running (in these conditions the focus is lost, the game stops but the CDA still keeps playing) and I waited for the end of the track, expecting that the notification message would be lost. Instead, the game received the notification and repeated the track all the same.

That is likely because the message is caught by the topmost window that has a message handler for the notify message. So you would need to have some other program running that had a message que with the appropriate code for receiving the notify message.

/* Message handling: */
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
    switch(msg)
    {
        case MM_MCINOTIFY:
        {
            if (msg==MM_MCINOTIFY && wParam==MCI_NOTIFY_SUCCESSFUL)
            printf("Notify message caught!");
        }
        break;
    }
    return 0;
}

[dippy dipper]

Attached is a small test program (source files only since everything I compile nowadays is considered viral) that catches the notify successful message.

[gho]

The discussion reminds me that you can create a window with hWndParent == HWND_MESSAGE that, if I understood correctly, is not visible but has the only purpose of to create a message queue. I wonder if in such a case, that is a game that has a visible window and creates an additional message window to handle mci notifications, could make the difference between the default handle and 0xFFFF. Well, I would worry about this when we meet such a case, if we ever will ...

[gho]

A first addendum for the help pages, about the renamed FORCEWINDOWING flag.

[huh]

OK, at least from what I understand, placing the patch only in "Windows 9x MCI" is ambiguous (we don't know if it's correct).

@BEEN_Nath_58

The only thing I would like to check is if the game on Win98 plays music when Windows button is pressed.

I can try it, but not until Monday.

[BEEN_Nath_58]

I can try it, but not until Monday.

I can confirm that on Windows 98, the game runs on Desktop as well. It wasn't the perfect test. Since Win98 doesn't allow Windows button function on everything, I used the following trick.

• Anywhere in the game, menu or mission, I pressed the Windows button (a few times).
• When I pressed escape or went to another screen, the game goes to Desktop for a second and then returns back.
• I did this in mission; when the game was running and I pressed Escape, the game went to Desktop with no music and I came to menu. When I pressed Esc again to resume the game, it went to Desktop again with music now and resumed, proving the game runs in Desktop with music.
• If that isn't enough, I pressed Alt+Tab a lot of times to toggle the screen and the music always played.
• All my steps may be because of a limitation of Voodoo3, but @huh2 should be able to confirm my tests.

[huh]

OK, so the expected behavior is that the music will play even if I press the windows button (in W98)?

[BEEN_Nath_58]

Not necessarily the windows button, if you toggle to the Desktop in some way, yes it will play it.

[gho]

@Dippy dipper: I hope you don't mind, but your piece of code is intriguing and I'm testing the possibility to adapt and integrate it in DxWnd. But before I'll have to investigate some oddities, though it's too early now to talk about them. Please, stay tuned, sooner or later I'll report on this.

[BEEN_Nath_58]

@ghotik Could you please explain the Force windowing flag?

For sure, what's currently missing is an alignment of all man pages and .ini descriptions.

There's more: you haven't added a description for many tweaks. Then there are a lot of spelling and grammatical mistakes and extra spaces in the description already present. I can probably correct most of them.

Which source file contains the descriptions?

[BEEN_Nath_58]

... followup:

@dippy-dipper2:

Can you provide Windows 10 screenshots for:
dxwnd_global_settings3.png, dxwnd_configuration_timing2.png, fullmoon.jpg, fullmoon.png, dxwnd_configuration_main6.png, dxwnd_configuration_3d.png.

Note that the dxwnd_configuration_3d.png is old and doesn't have the set 3D color flag in it.

@ghotik, you'll need a description for Set fog color.

Also I need a better explanation for "Force setting gamma ramp"/Direct3D.

[gho]

I wouldn't tie Dippy Dipper to these pictures: I can do them myself and they will be fine even if the window style could be slightly different.

[gho]

Preliminary update, just see the added text. There would be hyperlinks and other fancy stuff, maybe later ...

[gho]

Another preliminary fix on the Debug page. The final version may change because I now realized that the Highlight color used for the different operations are not too rational, I may then change some color coding (but this should be done both on the help and in the source code). Also, I may have forgotten some operation, so I'd better check.

[gho]

Some other issues were fixed (I believe also all change requests about the help pages from Been Nath), but now I can't risk losing fixes, so I posted the new v2.05.89 release in the download area.
Among other things I now realized that it is no good to mix screenshots taken with different DPI values because this way the pictures have different sizes. But it seems that some size constrains still have to be fixed, maybe. Anyway, that will be in the next release.
For any comments about DxWnd behavior and documentation, please refer now to the last release v2.05.89 in the download area.