lifthrasiir / angolmois Goto Github PK

Effects:

• NOTE_type will have the fifth type BOMB = 4
• Sanitization will strip NOTE and LN{START,DONE} if BOMB is present, INVNOTE is still kept as it can be used as a custom bomb sound (somehow)
• Its grading occurs at the same time as pcur adjustment, but may have to be independent due to lag resilience
• update_grade requires the third argument for the amount of gauge decrease
• tkeykinds will have dummy sprites only used to render bombs (different color but same width)

Actually not quite hard as it sounds (it is similar to INVNOTE in terms of processing) but can be annoying to implement.

This isn't really an issue, but not being able to change keys easily is big let down for me. It'd be easier if this have something like a configuration file so that we can easily change the keys.

How do I use the environment variables to change the keys? Do I really have to edit every single BMS files that I want to play with my own keys? That sounds ridiculous to me.

This warning message appears when I compile.
I don't know what string arg does but the warning sign worries me.
not a blocker so far.

E.g. alternately pressing left shift and ctrl should key-up each other

Needs something like XV(struct rndst { int sw, rnd, els; }) rndbuf;.

At least the minimal width of panels should be enforced.

Mostly trivial.

Inspired from Hitkey's diary entry:

• It is possible to reuse #xxx[1-2][A-Z] which is normally unused by BMS files as a spacer for layout.
  • Separator between 1P and 2P, scratch on the right hand side, 10KEYS:
    angolmois -w -K '11a 12b 13a 14b 15a 16s 1Zs' '21a 22b 23a 24b 25a 26s'
  • Separator between 1P and 2P, 14KEYS:
    angolmois -w -K '16s 11a 12b 13a 14b 15a 18b 19a 1Zs' '21a 22b 23a 24b 25a 28b 29a 26s'
  • Simulated Couple Play rendering for Double Play charts using #PLAYER 3:
    angolmois -w -B -K '11a 12b 13a 14b 15a 16s 1Aa 1Bs 1Cs 1Ds 1Es 1Fs 1Gs 1Hs 1Is 1Js 1Ks' '21a 22b 23a 24b 25a 26s'
• I also wish these options:
  • --no-combo: No combo display
  • --half: Half-line display (* each lane overlaps with previous/next lanes by half the lane width)

It would be good to have an explicit "gap" specification in --key-spec:

Example 1: angolmois -w -K '11a 12b 13a 14b 15a 16s' '(40) 21a 22b 23a 24b 25a 26s'
Example 2: angolmois -w -K '16s 11a 12b 13a 14b 15a 18b 19a' '(40) 21a 22b 23a 24b 25a 28b 29a 26s'
Example 3: angolmois -w -B -K '11a 12b 13a 14b 15a 16s' '(450) 21a 22b 23a 24b 25a 26s'

If we are careful enough, --half can be simulated as follows:

--key-spec '11a (-12) 12b (-12) 13a (-12) 14b (-12) 15a 16s'

adjust_object_position (converts virtual measure not affected by #xxx02 to actual measure) is stupid, we should precalculate or at least cache actual measures. The problem is that we can't really resolve them until parse_bms ends.

Refer http://hitkey.nekokan.dyndns.info/diary1301.php#D130118. Under investigation.

It may be hard to simulate with the absolute accuracy, e.g. if same lane has lots of notes with overlapping grading areas, then the automatic player should press and unpress the key in much higher rates. If our goal is only to get reasonably plausible result then it can be much easier.

At least make them unable to crash the program.

• Zero BPM
• Negative BPM during a long note
• Zero or negative STOP time
• #RANK 6 or higher

The current build system does not work in Windows (MinGW) at all. Also, there was a report of smpeg.h residing in the different directory from SDL (so sdl-config won't work). Extending a plain Makefile may work or may not; other systems (CMake etc.) may be the better choice.

Consecutive LNs had been a source of problems:

• 2.0 branch had consecutive LN parsing wrong (first introduced by git rev cb72f2f, fixed by git rev d242076). It accidentally removed LNSTART when LNDONE is present.
• #LNTYPE 2 parsing is much more complex due to consecutive LNs.
• As BMS command memo describes, Angolmois' handling of consecutive LNs lead to the possible incompatibility. If we disallow consecutive LNs we can just let AAAABBBB parse like AAAAAAAA.
• In 2.0 branch (and also possibly 1.0) consecutive LNs are mostly unplayable due to strange grading: the start of second LN cannot be graded (and eventually graded MISS) if the key is pressed up and down earlier than the shared endpoint. This is because an imaginary "grading area" of the start of second LN is contracted due to the end of first LN (in spite of the grading area of the end of first LN is not contracted as LNDONE is checked separately). This can also occur if two LNs have very small gap, but consecutive LNs result in the most severe instance.
• The current display of LNs cannot distinguish two consecutive LNs apart.

So let's get rid of consecutive LNs. That should make things much more clearer, and also saves a few lines (estimated). Checklists:

• Check if there are BMSes with intentional consecutive LNs
• Remove special casing of consecutive LNs in #LNTYPE 2 parsing; that should make #LNTYPE 2 parsing routine not to use prev in the current sense (last observed non-zero key in channels 5x/6x), and possibly to unify iprev, prev and lprev to have same meanings (the start of LN).
• Simplify sanitization routine. I think there also exists some complex bug with BOMB/INVNOTE inside LN...
• Update documents.

Workflows:

• Add a flag that signals PMS handling (eventually results in nkeys = 9); triggered by the file name extension or -P option (maybe)
• Add an envvar ANGOLMOIS_PMS_KEYS that is a reordered synonym to ANGOLMOIS_{1P,2P}_KEYS
• Merge alternative rhs channels before get_bms_info
• Add tkeykind 5---9 so that play_prepare works

How about 18-key PMS?

Yep, this is a bug since this should not happen if we didn't call SDL_DisplayFormat (instead of SDL_DisplayFormatAlpha or similar).

There are three primitive operations to the channel array:

• Maintaining a sliding note window which size is fixed to the virtual measure (for drawing notes to the screen);
• Maintaining a pointer sliding through the notes (for playing BGMs and applying BMSes etc.); and
• Finding the closest note of given kind from the given point (for grading things).

None require multiple arrays for each channel. Merging them may simplify things a lot. It is also future-proof as more than 18 keys are in use in some BMS-derived formats.

Related to LN rendering process.

While not quite useful (non-ASCII characters will be broken), #TEXT is good for writing test cases.

Current grading rule: abs(time) < {0.6, 2.0, 3.5, 6.0} / (1.5 - #RANK * 0.25) * 0.024ms (thus ±19.2ms for #RANK 3 and ±14.4ms for #RANK 2)

This rule is too unusual to adapt #EXRANK or related commands. Maybe we should rethink about it.

From Hitkey's diary entry:

• Measures #404-523 have a BPM of 900,000,000 (#BPM2D 900000000).
• There are several portions that BMSE is unable to edit (e.g. a scaling factor of 32 in measures #584-587).
• Several BMS implementations are unable to play this chart:
  • nazo, Angolmois: Skips the remaining portion of the chart.
  • PMSee-V: Issues an error as it limits a BPM to 100,000.
  • IIDXv: No objects displayed, no sound played.
• In addition to be unable to play it, BPM counter of nanasi and ruvit does not work correctly on this chart.
• Maybe uBMplay and BMX2WAV are the only implementations that can play it correctly?

I think it is a bug to skip the remaining portion of the chart (it is okay to behave wrongly in the problematic portions but that effect should not last forever). Not sure how to work around the problem without introducing an exact arithmetic though.