The main exits are initiated from code that cannot filter this back to D_DoomMain easily so the exception is the only way to get there.
The 3 main points of exit are:
* quit/exit CCMD
* quitting the menu through ST_Endoom
* receiving a quit message on the main window.
The current menu system simply does not work that well with 320x200, rendering the game hard to use at that tiny screen size. This is a clear case where the work required to keep it operational stands in no relation to the benefit.
With localization for non-Latin languages on the support list the multibyte API doesn't cut it anymore. It neither can handle system text output outside the local code page nor can an ANSI window receive text input outside its own code page.
Similar problems exist for file names. With the multibyte API it is impossible to handle any file containing characters outside the active local code page.
So as of now, everything that may pass along some Unicode text will use the Unicode API with some text conversion functions. The only places where calls to the multibyte API were left are those where known string literals are passed or where the information is not used for anything but comparing it to other return values from the same API.
Having everything lumped together made this a maintenance hassle because it affected how the level has to be stored.
This hasn't been tested yet, so it may not work as intended!
The original place in I_CheckNativeMouse is unsafe because that function can get called from the system message queue which can result in a bad global state of the VM for such a call because it can be recursively invoked from code that may temporarily alter some settings.
This one was particularly nasty because Windows also defines a DWORD, but in Windows it is an unsigned long, not an unsigned int so changing types caused type conflicts and not all could be removed.
Those referring to the Windows type have to be kept, fortunately they are mostly in the Win32 directory, with a handful of exceptions elsewhere.
According to Blzut3:
The issue happens when the fullscreen resolution is the same as the desktop resolution. In this case WM_DISPLAYCHANGE doesn't occur so the editor never appears. This appears to be fixable by also catching WM_STYLECHANGED since at the very least the window caption will appear/disappear.
- Fixed: If you enlarged the game window (in windowed mode) so that the
window is bigger than the selected resolution, the menu would still take
its inputs from the portion in the upper left that matched the
resolution.
- GetSystemMetrics can lie about the window border sizes, so we can't
trust it if the executable is flagged as Vista-targetting
(default behavior for VS2012/2013).
Windows sends some when the mouseis ungrabbed even when it does not move.
This caused the currently selected menu item to get unselected.
SVN r2803 (trunk)
example. Do not modify the window class pointer. I still had an instance where I was left with
an invisible pointer no matter where I moved it, so hopefully this takes care of that. (edit:
it doesn't.)
SVN r2496 (trunk)
machines, so when an NPC need to show the "enough" response, it has enough
information available to do so.
- Some new Strife Teaser fixes I forgot to commit are in here.
- Moved norawinput check into FindRawInputFunctions().
SVN r2120 (trunk)
