178 lines
6.7 KiB
Plaintext
178 lines
6.7 KiB
Plaintext
This is mostly a scrap pad for my TODO's, in a place others can see them.
|
|
Feel free to add--preferably signed--comments, though actual discussion
|
|
is better held on the list than in a CVS document. :)
|
|
|
|
Some of this is stuff I'm not quite sure how to deal with, but too
|
|
low-pri to bother bringing up on the list.
|
|
|
|
********
|
|
|
|
All of our graphics are scaled for 640x480. We should have some way
|
|
to specify the native resolution of graphics, so we can have 1024x768 or
|
|
higher graphics when it's useful. (For example, the radar kanji could
|
|
look a lot better.)
|
|
|
|
Maybe eg "200%" to specify the image is scaled twice as large as other images?
|
|
|
|
Actually, entire thremes could be high-res, so it might be useful to
|
|
have a more general way to do this (perhaps a way to specify a hint
|
|
for a whole directory?)
|
|
|
|
********
|
|
|
|
Enable antialiasing for the radar lines. It's extremely cheap for
|
|
simple lines, and the aliasing makes the radar look really ugly.
|
|
|
|
********
|
|
|
|
Stuff in the song cache never dies unless the version changes. We don't
|
|
want to erase songs we didn't load; I frequently move song paths out of
|
|
the search path while debugging (for fast loads) and I don't want that
|
|
to lose cache. Hmm. Access time?
|
|
|
|
Similar problem with high scores; I don't load all of my songs when
|
|
debugging, and I lose my scores.
|
|
|
|
(Not sure how to do this either.)
|
|
|
|
********
|
|
|
|
Triple-buffering.
|
|
|
|
Is there an easier way to switch buffers on vsync in parallel with
|
|
rendering without starting another thread?
|
|
|
|
(Wait for OpenGL.)
|
|
|
|
********
|
|
|
|
It'd be nice if we could go straight from one screen to another, tweening
|
|
one off and the other on simultaneously (with a delay so it doesn't
|
|
look like a jumble, but in parallel).
|
|
|
|
Here's the idea:
|
|
|
|
Old menu displays its keepalive, and preps the new screen. Then, add
|
|
the new screen to the top of the screen stack, the old menu hides its
|
|
keepalive, then the old screen tweens out while the new screen tweens
|
|
in. (This will need some tuning; they shouldn't both start at once, since
|
|
there'll be too much onscreen and it'll just look like a jumble.)
|
|
|
|
********
|
|
|
|
We have different kinds of things we want to trace, and different
|
|
places to put them.
|
|
|
|
We have normal debug traces. There are lots of these, and they go to
|
|
the console and log.txt. Since there are so many, we only want to
|
|
include recent ones in crash dumps. (All other types of output should
|
|
also go here.)
|
|
|
|
We have at least two kinds of warnings:
|
|
1. Things that are possibly our fault, that we want to receive bug
|
|
reports about, but that aren't fatal. DirectShow failing to start
|
|
for an unknown reason (this does not include missing codecs), unexpected
|
|
data from a USB device (eg. requesting 3 bytes from a Pump pad and only
|
|
getting 2).
|
|
2. Errors that probably aren't our fault (that we don't want bug reports
|
|
about). These are predictable problems, that we expect to happen, but
|
|
also aren't fatal. MSD parse errors, missing song files, missing
|
|
announcer directories (except in Empty; that'd be our fault = #1);
|
|
DS failing due to a missing codec. Since we expect these to happen,
|
|
we can also include a "tip" section for the warnings; for example, if
|
|
an AVI is missing a codec we know about, we can point the user to the
|
|
codec's website.
|
|
|
|
Some users won't want to see one or both of these at all. ("Okay, it
|
|
can't load the doubles steps; I don't want to have to edit the song
|
|
to fix it, so stop bugging me about it." "Okay, I've reported that bug;
|
|
stop bugging me.")
|
|
|
|
We have important debug traces; these are normal (unlike Warn), but
|
|
should always be included in crash dumps. This includes things like
|
|
video card info and which input devices were found. All of these
|
|
should go to the debug log.
|
|
|
|
Right now, warnings are easily lost in the debug flood, and aren't seen by
|
|
non-developers running release builds. Put warnings in a grayed-out edit
|
|
box, so they can be easily copied.
|
|
|
|
I'll probably do this once I figure out a good place to display warnings.
|
|
|
|
*********
|
|
|
|
We have lots of big things that need to be portable; most of those
|
|
are obvious (renderer, joysticks, keyboard, sound, etc.) Less
|
|
obvious, minor ones here that nonetheless need to be done:
|
|
* use / as a filename separator, not \
|
|
Change this in song data at load time, too.
|
|
* no #pragma once
|
|
* MFC->STL is hard, because most STL implementations aren't very STL.
|
|
g++ 3.1 is much better, but VC6 isn't. (How is VC7?)
|
|
|
|
(This is long-term.)
|
|
|
|
*********
|
|
|
|
An override file. Some people put their data on CD; it'd be nice to
|
|
be able to tweak song data without actually rewriting the whole thing.
|
|
Also, some people may not want to modify the original data at all
|
|
("keep the source data prestine!"). I'm not sure if this should be
|
|
done with internal data (eg. specific to given song options) or
|
|
generic, applying to given .SM #OPTIONs. The latter is cleaner, but
|
|
we don't always load from .SM's. (Hmm, maybe a way to apply SM
|
|
options on top of a loaded song?)
|
|
|
|
This shouldn't allow changing steps at all (but it should allow changing
|
|
difficulty for existing steps).
|
|
|
|
UI is tricky. Perhaps just the EditMenu song selector, with an icon
|
|
or color showing songs that currently have overrides ...
|
|
|
|
(Useful but I don't need it right now, so "some day".)
|
|
|
|
********
|
|
|
|
A single options menu; toggle "graphics", "game options", "key
|
|
config", etc. as a separate option at the top to toggle which option
|
|
set is visible. Too much stuff on the main menu.
|
|
|
|
Don't put the game toggle here; it's used too much.
|
|
|
|
(Soon, but probably not for b6.)
|
|
|
|
********
|
|
|
|
Debug options. Options that most users don't need, but I don't want
|
|
to edit .INIs manually. I'll be adding a vsync toggle soon; most
|
|
users should never want to disable it (most people who think they
|
|
want to really don't :) so it's just clutter the main graphics menu.
|
|
Show FPS can go here, too.
|
|
|
|
********
|
|
|
|
I don't like needing to use the keyboard to configure my pad; it's
|
|
awkward. A mode to simply scan through inputs isn't good; it'll be
|
|
too easy to make false inputs. Delayed inputs suck (eg. bmdx).
|
|
|
|
Not sure how to deal with this, but it's minor. If we get BM support,
|
|
configuring two controllers one key at a time would be a pain. (KM
|
|
even more so.) In that case, we can just scan, though.
|
|
|
|
Low-pri; I'll do this if I figure out a good way.
|
|
|
|
********
|
|
|
|
Also, we have special cases for different hardware, and we'll only
|
|
be getting more of these (such as the converter that toggles on the
|
|
axis when opposite pad buttons are pressed); an autodetection mode
|
|
would be useful, so the user doesn't have to play with options.
|
|
"configure DDR pad via USB converter" -> "press up"; we know if we
|
|
need to ignore the axis; if not, "press up and down"; we know if we
|
|
need the toggle axis workaround.
|
|
|
|
This is probably difficult to implement reliably without having
|
|
access to all of the distinct adapter types, since this is very
|
|
special-cased.
|
|
|