括弧英数字キーとティックオブジェクトに理論的根拠を追加。...10月22日(火)Postscriptsこんにちは、lifthrasiirです。effect("キーを押した時の効果")であるため、formatがノートにkeysoundがなく効果を割り当てることを考慮して設計されなければなりません。"拡張が容易ではない"という言葉はこのような意味で使われました。barを任意の位置に入れることができるが、BMSではないですから。formatに変換して解決しなければならない問題です。(ななしのBMS拡張がどの程度受け入れられたのもななしがどの程度使われるソフトウェアだったからです。CSSのようなsyntaxは流用できるが、XMLではなく、また他の言語を解釈する負担があります。<judges>を分離するのが解釈は簡単です。identifier問題は、idという名前を避けて異なるnamespaceごとに異なるattributeを使用することにすればいいと思います。内部的にsoundref/imagerefという用語を使用しています。“Angolmois”こんにちは、lifthrasiirです。Sonorousは依然として作業中です。基本的に"安定したゲームシステム"を目標するので判定、主要インタフェース、互換性などがどの程度改善される前までは0.1.0は発表しないつもりですが時々snapshotは出そうです。Sonorous実装の過程でcmds.htmを改めて詳しく読んでいます。#SKINBMPzz、#SKINWAVzz、#SKINTEXTzzなどで次第に変わってこそ、しないと思っています。rewindingは...そうですね、できれば直したほうがいいようですね。editionの速度の問題は同一の原因です。具体的に、特にWindowsでRustの特定の関数(std::os::path_is_dir)が非常にゆっくりなせいです。問題を報告したため未来には改善されるが、一旦はSonorousでは問題を避けるように構造を変更し、Angolmoisの方も近いうちに直そうとします。TokenizedTypeはDTDでそんなに宣言されている時だけ適用されます。typeを持つattributeの名前が必ずidである必要はありません(HTMLでは保障されますが)。identifierが必要なら、xml:id(https://www.w3.org/TR/xml-id/)みたいなのがもっといいようです。XBMSについては・・・続いて書きます。(1/2)lifthrasiirです。-個人的には新しいformatを作ることは反対する立場です。ここには私が約7年(!)前に似たようなものを作ろうとした経験もあって、同様の試みをとてもたくさん見たせいもあります。具体的に、私が考えているBMSの当面の問題はこうです。1.音楽からBMSデータを作るのが簡単ではないです。soundがない"商用音ゲームが登場する現象もここにいると思います。effectorを使用する某ゲームがこの問題をうまく解決したと思いますが、いつも可能な方法ではないでしょう。これはBMSの特性上やむを得ない問題だけに、BMSの改善よりはBMSを作るソフトウェアの改善で解決しなければならないと思います。BMSが使用できるresourceに制限が多いです。これはBMSの根本的な問題というよりは拡張が容易しないために生じた問題です。XMLやJSON基盤なら拡張がたくさん容易になるように見えるが、formatがそれほど柔軟しなければ意味がありません。LRXも結局、LRの内部表現をそのまま持ってきたものに過ぎなかったんです。新しいゲーム要素の追加が極度に難しいです。BMSのゲームシステムがとても曖昧に規定されていて新たな機能が現れても他のソフトウェアがこれを具現化するには危険が大きいです。結局、機能が追加されなかったり、過度に緩やかに追加されたりします。これこそBMSじゃなく他のformatが必要な理由になることができます。BMSを使っていないという話は既存のBMSを放棄しなければならないという話もします。BMSと新しいformatをともに支援しながら絶対的な優位を占めるソフトウェアがないかぎり難しいです。(2/2)lifthrasiirです。このような理由で、BMSに新しい機能が追加されるには二つの可能性があります。使うソフトウェアが新機能を主導したり、新しい機能を大幅に制約して他のソフトウェアが簡単に適用できるようにしたり。XBMSをはじめとする多くの提案の共通的な問題は、既に実装するソフトウェアはないのに他のソフトウェアが追いつくのにはあまりにも巨大ということです。私はLRがもし今すぐLRXを使用し始めたら、BMSが消えるかもしれないと思います。ほとんどの提案にはLRはおろかnanasigrooveのようなソフトウェアさえありません。Sonorousはたくさん使うソフトウェアがないので漸進的な機能追加を目標としています。#LANESは多分もうちょっと修正をしなければならないが...他のことは経験を基にほかのソフトウェアが実装しやすいように作っています。内部的にJSONなどでserializeするformatの標準化なら可能かもしれません。hash計算などに使われることができるようです。BMSで#IF...#ENDIFなどを全て除去したBMSデータを作って各パターンを別のランキングで集計したり。title/artistのpriorityはsubtitle/subartistでも十分だと思います。value=""/>で統一してもいいです。したらkey部分だけ簡単に標準化して拡張できます。ノートを押した時の効果は音がないこともできます。sound/imageとeffectを交わすのがいいと思います。keysとjudgesは良い方向だと思うけどどうやって作ったのがいいのかは分かりません。(http://www.geocities.jp/kokolaworks/carmvtr/)が、個人的に興味深いました。Objectと同じタイミングで再生されなければならないためにひょっとしたらこれで十分だっかもしれません。Objectに吸収されるかもしれません。ambiguous.そして私見ではあるが、一貫したゲームバランスは重要だと思います。同じBMSがロングノートコンボや空POORの有無によってクリア難易度までもが大きく変わったらいくつかのプログラムがいても、人々は気に入る限り、プログラムを使うようになることであり、すでにある程度その現象があります。それで実装の特色とは別にゲームバランスが大きく変わらなければ、様々なBMS実装が共存するのに役立つようです。(1)こんにちは、lifthrasiirです。SDLがついに2.0が発表された関係で久しぶりにAngolmoisに修正を加えました。思ったより変換が難しくはありませんね。この過程でそのままにしにくい#BGAの動作が変わってhttps://nekokan.dyndns.info/~hitkey/diary1307.php#D130715で指摘された非互換性が改善されました。(Extra-Mix)"で1文字keyを2文字に変えたことがよく動くのが確認しました。遅くなったできるけど、一応は微々たる差で報告はあります。lens.Sonorousは...https://github.com/lifthrasiir/rust-encoding/こんなものを作るために少し休んでいました。ESを使用するために無視した低い仕様のパソコンをまた支援できるかもしれません。rust-sdl2のようなものはないけど。この日記では翻訳しませんが、非常に興味深いです。これ以上よい方法を私は思いつくことができません。今後の拡張性について言及しています。ような形式を表現しやすくするでしょう。予想外の落とし穴があるかもしれませんが、私はそれを思いつくことができません。いまのところ、私はこの提案を強く支持します。Objects長さを持つノートについて、従来よりも詳細に記述できるようにする提案。区別できるようになります。数え方を規定する効果については、私以外の誰かが考察してくださることを期待します。