339 lines
13 KiB
Plaintext
339 lines
13 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.
|
|
********
|
|
|
|
Resizing tiled textures is a pain: if we scale down a tiled 1024x1024
|
|
texture to 256x256, then we need *four pixels* of buffer between each
|
|
tile to ensure they don't bleed into each other. Splitting all tiled
|
|
bitmaps into lots of smaller textures sounds good (for other reasons,
|
|
too). But for fonts, this would create hundreds of tiny textures; that
|
|
would be a performance hit (four fonts could mean over 1000 textures,
|
|
and we'd have to flush the render queue *every character*--ack.) Maybe
|
|
BitmapTexts could pre-render their text; then they'd be nearly free,
|
|
but changing text would be more expensive. Maybe too expensive; eg.
|
|
the Oni timer changes every frame. But we might have to do that anyway
|
|
with fallback fonts; how is Jared implementing that?
|
|
|
|
If we split tiled sprites apart, we can also tile BGAs with only one
|
|
render, by using the texture matrix (I think--maybe we'd just have to
|
|
stretch.) Then we might be able to use multitexturing (if available)
|
|
for BGAs, to render multiple BGALayers in one pass; they get slow. Tricky
|
|
to interface, though.
|
|
|
|
Even with texture wrapping off, I'm still seeing borders. With my new
|
|
texture loader, the bottom gameplay frame has a black border instead of
|
|
a gray one. Is that the border color or is it still wrapping? Either
|
|
is a problem; even if it *is* the border color, it shouldn't render anything
|
|
there. (Can the border be set transparent? But that would cause transparent
|
|
borders, which might cause seaming ...)
|
|
|
|
********
|
|
|
|
Abstract NoteData completely, and then make the arrays vectors, so they
|
|
don't have arbitrary limits and don't take lots of extra memory.
|
|
|
|
1: add real accessors: GetTapNote(row, track), SetTapNote(row, track, char),
|
|
GetHoldNote(num), SetHoldNote(num, Hold), etc. Inline them.
|
|
2: Make everything use them. (Including derived classes.)
|
|
3: Make m_TapNotes and m_HoldNotes private. (Not protected! A base
|
|
class implementation should almost always be hidden even from its
|
|
derived classes; they can use the same above accessors as everyone
|
|
else.)
|
|
4: Change them to vector<>s. Make sure GetTapNote returns a '0' when
|
|
the parameters are out of range (since we generally assume we can
|
|
do that).
|
|
Step 2 is straightforward but will take time and a lot of changes, so
|
|
I don't want to do that before the release.
|
|
|
|
Then, make class Notes store a NoteData instead of SMNoteData, so we'd
|
|
only have to convert on initial load and when saving; faster and simpler.
|
|
|
|
|
|
Even better: do away with m_HoldNotes completely, and change the default
|
|
storage scheme to 4s. Make every place that accesses holds either use
|
|
them in 4s, or specifically request a hold list, when needed (such as
|
|
when rendering). If we can do this, we can do away with most of the
|
|
2sand3s and 4s conversions, which will aid const-correctness a *lot*
|
|
(which has been bothering me), and simplify the code further.
|
|
|
|
One problem: The renderer (NoteField::DrawPrimitives) wants HoldNotes.
|
|
That's not a problem (we can still create an array of HoldNotes when
|
|
requested, and it can be cached); the problem is that it'd need to be
|
|
recreated whenever the data changed, which would make editor recording
|
|
slow, at least.
|
|
|
|
Maybe even the NoteField::DrawPrimitives could deal with 4s, generating
|
|
HoldNotes as needed. I'm not sure if that'd be too slow, I'll have to
|
|
try it and see.
|
|
|
|
********
|
|
|
|
Thinking ahead: BM support in .SM's and internally.
|
|
|
|
Background: allow an arbitrary number of keyed notes; any tap can
|
|
be keyed to any effect. BM doesn't have hold notes, but I'd like to
|
|
support them anyway.
|
|
|
|
Right now, a '0' indicates nothing, a '1' indicates a tap note, a '2'
|
|
indicates the beginning of a hold note (which is duplicated in the hold
|
|
note list). We want more than 255 keyed sounds, so make this a short,
|
|
with -1 indicating nothing and 1+ indicating a tap note for a given key.
|
|
Put autoplay sounds on 0 (keyed sounds to always play).
|
|
|
|
DDR can be stored the same way; just put every key on 1 and don't attach
|
|
a sound to it.
|
|
|
|
Hold notes are tricky. Any note should be able to be held, even keyed
|
|
ones, and we need some equivalent to "4s mode". We could make TapNote a
|
|
struct { short key; bool hold; }.
|
|
|
|
How to handle playing keyed hold notes with regular sound effects? (We
|
|
aren't using MIDI ...)
|
|
|
|
Make sure hold notes work together with autoplay sounds. (Lots of songs
|
|
have hard versions with a lot of sounds being played by the player, and
|
|
easier ones with many of those sounds on autoplay; it should sound the
|
|
same.)
|
|
|
|
Hmm. So, tentative steps:
|
|
1: Make TapNote a short, and change '0' '1' and '2' to integers, leaving
|
|
the meanings alone. Change hardcoded '0', '1', '2' to constants
|
|
TAPNOTE_NOTHING, TAPNOTE_TAP, TAPNOTE_HOLD_HEAD, so we can search for
|
|
them more easily. This step should be straightforward.
|
|
2: Make TapNote a struct, adding 'enum type', with values "TN_NONE",
|
|
indicating nothing (the short should always be 0 here), TN_TAP, indicating
|
|
a tap note, TN_HOLD, indicating a hold note head, TN_AUTOPLAY, indicating
|
|
an autoplay note.
|
|
3: Remove TAPNOTE_HOLD_HEAD, using TN_HOLD instead. At first, only the tap
|
|
head of the hold note will have a TapNote entry (like it is now).
|
|
|
|
This will make NoteData larger. It's already too large, so this should
|
|
all be done after abstracting it (so we don't have to overallocate
|
|
everything).
|
|
|
|
|
|
|
|
---
|
|
|
|
And the other part: how to store this in .SMs? We need to be backwards-
|
|
compatible, of course, so perhaps we should add an #SMVERSION tag; this
|
|
would be #SMVERSION:2.
|
|
|
|
Currently, we do
|
|
|
|
10000
|
|
|
|
to indicate one tap. We can't use single digits, since we might have any
|
|
number of keyed notes, so
|
|
|
|
1 0 0 0 0
|
|
|
|
which would allow higher numbers; but how to represent holds? Perhaps
|
|
|
|
+1 0 0 0 0
|
|
0 0 0 0 0
|
|
0 0 0 0 0
|
|
-1 0 0 0 0
|
|
|
|
which would be the equivalent of
|
|
|
|
20000
|
|
00000
|
|
00000
|
|
30000
|
|
|
|
except indicating that the hold is keyed to key 1.
|
|
|
|
This would make .sm's more than twice as large. I don't think that
|
|
should be a consideration; if it becomes a problem, we can add gzip
|
|
support. Better to do it cleanly and have readable data files than
|
|
to go to lengths to "compress" manually, like DWI's do, and have data
|
|
that's impossible to read and almost impossible to parse.
|
|
|
|
Where to put autoplay notes? They can't go in their own tag, since
|
|
they're specific to notes, not songs. They also need all of the
|
|
data that regular notes need (hold length, if any, and what they're
|
|
keyed to), so it'd be cumbersome and ugly to put them out-of-line;
|
|
having them inline with the rest of the notes would be nice. Hmm ...
|
|
|
|
********
|
|
|
|
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?)
|
|
Hmm. Things aren't as bad as they seemed a while back; we should be
|
|
careful, but maybe it's not hopeless.
|
|
|
|
(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.
|
|
|
|
********
|
|
|
|
Option to skip the music select screen and always pick all music.
|
|
|