yquake2remaster/TODO
2012-06-14 10:49:08 +02:00

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.