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 ... ******** 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?) ******** 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. ********* * use / as a filename separator, not \ Change this in song data at load time, too. ********* 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. 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. ******** Don't derive subtitles via GetMainAndSubTitlesFromFullTitle in SMs if there's a #SUBTITLE tag at all, even an empty one. This way, you can get full control over what goes in which field, and it's derived automatically only if no subtitle is specified at all (or we're importing from another format). Files with subtitles in the #TITLE field should be discouraged. ******** Find a replacement for the CRC code. It doesn't explicitly give permission to distribute or modify; only "use", which means we really can't even distribute it, much less link it against a GPL program. (No doubt it was probably *intended* to allow modification and distribution, of course, but it doesn't say that.) ******** 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. Fix the hold note strangeness first, though. ******** Texture cache. Decompressing, resizing and occasionally dithering images takes a good amount of time (most of the load time). Do all this and write the postprocessed data to disk; read it and load it in a simple block load later on. This is tricky; it's possible that reading uncompressed textures will be slower than reading compressed ones and porcessing them. I was hoping to use hardware compressed textures for this, but they're way too low quality. Also, some mechanism to cache song images during the song scan, so we don't spend time doing it in the music wheel or gameplay. ******** 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