mirror of
https://github.com/yquake2/yquake2remaster.git
synced 2024-11-10 07:12:07 +00:00
79 lines
3.7 KiB
Text
79 lines
3.7 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 unicode issue:
|
|
Quake II only allows ASCII characters, internally all
|
|
characters are represented as "char". But Windows uses
|
|
unicode quite often. This may lead to problems. The big
|
|
question is: "What happens, if the path to the home dir
|
|
contains unicode characters?" At what can we do to prevent
|
|
problems without rewriting the whole game to be unicode
|
|
aware? This may be a problem on Linux and FreeBSD too,
|
|
but at least on FreeBSD unicode characters in the user-
|
|
name are a bad idea and for things to work correctly
|
|
the homedir-name should be the same as the username...
|
|
|
|
5. 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.
|
|
|
|
6. 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.
|