itgmania212121/stepmania/TODO.glenn

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 big 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.  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.

Hmm.  The two times we want to scale textures (to fill the texture)
are 1: when we're going to wrap the texture and 2: when the image is
larger than our maximum texture (eg. due to the max texture size option).
In case #1, we want the resize filter to wrap.  In case #2, we don't.
We should only wrap filtering if the texture is going to be wrapped.
Is it actually noticable?  Might reduce seams in tiled BGAs.

********

Make RageTextureManager handle refcounting, not RageTexture.

********

D 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 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.
2: 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 ...

********

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.)

********

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.

*********

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".)

********

Debug options.  Options that most users don't need, but I don't want
to edit .INIs manually.  Show FPS can go here.

********

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.

********

BPM sync for menus; this would allow full BGAs, synced menu effects,
and so on.  Novelty; low-pri.

********

Option to turn off menu music (except for song previews).

********

Don't export *.old in SMZIPs.

********

Make autogen go through combinations of arrows.

That is, right now we just walk through consecutive arrows.  DDR
to Pump results in DL, DR, C and UR being used or UL, C, UR, DR.
Instead, walk through all combinations of 4; 11110, 11101, 11011,
10111, 01111, so more patterns are possible.

********

Note that a 16bpp framebuffer bit depth can give extremely high quality
output; it's usually only worse than 32bpp if you're looking for it.  (It
becomes more important with heavy filtering; for example, Q3's transparent
layered smoke puffs.)  Using 32bpp textures and a 16bpp framebuffer will
dither in hardware, which is much higher quality than dithering the
texture itself and is free.

Jumping to a 32bpp framebuffer is *much* more expensive than jumping
to 32bpp textures, and doesn't improve quality nearly as much.

ex. in the graphics menu, 1024x768, vsync off, I get 170 fps in 16 bpp
textures, 16 bpp framebuffer.  Jumping to 32bpp textures costs 20 fps.
32 bpp framebuffer costs 62.  Both costs 74.

We're more fillbound than most apps: we don't draw very many polys,
but backgrounds can result in multiple fullscreen passes.
(Okay, this isn't a TODO ...)

********

debug option to show console in release

********

Overload theme metrics on the commandline.

--metric "Common::InitialScreen=ScreenDemonstration"
--metric "ScreenDemonstration::NextScreen=Exit"

could be used to run a demo and exit, for benchmarking and profiling.

********

Defaulting to the default refresh rate sucks; it gives 60Hz on
most systems.

The reason we do this instead of using the max is that Windows often
doesn't really know the max refresh rate, but it always thinks it
does, so on some systems the max refresh rate will just desync the
monitor.

We can find out the active refresh rate:

	DEVMODE dm;
	memset(&dm, 0, sizeof(dm));
	dm.dmSize = sizeof(dm);

	EnumDisplaySettings(NULL, ENUM_REGISTRY_SETTINGS, &dm);
	LOG->Info("%ix%i, %i %i %i", ydm.dmPelsWidth, dm.dmPelsHeight,
		dm.dmBitsPerPel, dm.dmDisplayFlags, dm.dmDisplayFrequency);

If the resolution and bit depth we're setting is <= the current,
we should be able to use the same refresh rate, too.  Many people
probably don't play games in higher resolutions than they normally
run their desktop at, so this is often going to be true.

If this gives anything above 60 at all, it's a big win for sensible
defaults.  70 is infinitely better than 60.

I don't want to change the default refresh right now, until things
settle down a bit more--don't want to introduce new problems.