mirror of
https://github.com/yquake2/yquake2remaster.git
synced 2024-11-25 22:10:59 +00:00
c0e9a6f045
This changes employs a horrible hack to connect the ASCII Quake II to the UTF-16 WinAPI. The path to "My Documentes" is read in UTF-16, then converted to a old "DOS style path" with 8.3 characters. This DOS path has by convention no UTF-16 characters in it and can be converted into a normal ASCII string. This ASCII string is the path used by Yamagi Quake II. The conversion logic will fail if the "Windows to DOS filename transistion" is deactivated in the registry (it's on by default). In that case no homedir is used and the "Windows Roaming Mechanism" kicks in.
67 lines
3.1 KiB
Text
67 lines
3.1 KiB
Text
Long term TODO list for Quake II on Windows
|
|
-------------------------------------------
|
|
|
|
1. Test various windows version in different
|
|
localizations. At least:
|
|
- Windows XP [done]
|
|
- Windows XP 64
|
|
- Windows 2003
|
|
- Windows Vista
|
|
- Windows 2008
|
|
- Windows 7 [done]
|
|
- Windows 8 Preview [done]
|
|
|
|
2. The "dsound" sound system issue:
|
|
By default SDL uses the "waveout" sound driver which
|
|
needs to many buffers to be usable with Quake II. There
|
|
is no easy way to work around this, we can neither call
|
|
the sound system more often nor generate more sound per
|
|
call. The short term solution is to force the DirectX 5
|
|
based "dsound" driver. But "dsound" is unavailable for
|
|
64 bit applications on 64 bit Windows and on Windows 8.
|
|
SDL 2.0 has the new DirectX 8 based "directsound" driver
|
|
but that would require a port of Yamagi Quake II to the
|
|
still unstable SDL 2.0. Another soultion would be a
|
|
custom SDL.dll with the new driver backported to SDL
|
|
1.2.15. Be aware, that this problem only affects the
|
|
SDL sound-backend and not the default OpenAL backend!
|
|
|
|
3. The keyboard layout issue:
|
|
SDL 1.2 has a bug which results in untranslated keycodes
|
|
on non qwerty layouts. The consequence is, that Quake II
|
|
uses always the english keyboard layout, regardless of it's
|
|
real layout and the layout setting in the windows control
|
|
pannel. The recommendet work around is to switch SDL into
|
|
unicode mode and read unicode characters instead of the
|
|
raw keycodes. But implementing this into Quake II would
|
|
be a real PITA due to the rather complex differences
|
|
between the internal input system and SDL. ioQuake3 uses
|
|
unicode input for the console and raw input for the key
|
|
bingings, has therefor a correct layout in the console
|
|
but an english layout on normal key bindings. Their
|
|
implementation is rather invasive into the console
|
|
subsystem and I don't think that it's worth the efford.
|
|
|
|
4. The debug / stdout issue:
|
|
At the moment no stdout is readable on windows, the only
|
|
way is to scroll in the console. This is a problem, because
|
|
without the game output problems are hard to debug. Enabling
|
|
the console log by default might migitate the problem, but
|
|
the early startup is not convered by it. One solution would
|
|
be to redirect stdout into a file (like dhewm). Daniel
|
|
suggested to implement a console window like the orginal
|
|
Quake III Arena client had.
|
|
It would be nice, if the Windows crash handler would be
|
|
invoced at every crash and not only sometimes. In theory
|
|
the crash handler is able to create crash dumps and send
|
|
them to a remore location (only Micorsoft or anybody?).
|
|
While I'm not sure that gdb can read Windows crashdumps,
|
|
it may be worth to take a deeper look into this.
|
|
|
|
5. The CR-LF issue:
|
|
At the moment all files have LF line endings, which are
|
|
incompatible with most Windows software. This isn't a
|
|
problem for the code itself (at least with MinGW), but
|
|
for the documentation. A possible solution is to use git
|
|
to convert the file endings at checkout. This would leave
|
|
the repo at LF and enable CR-LF for Windows.
|