メインPCが故障して少しの間開発できないのと、直ってもまりおふに向けたRTAの練習があって開発ペース落ちるので、その間に構想というか思っていることをメモしておきます。
いろんな人に「それは違うんじゃないの」みたいなツッコミをもらえたら改善につながるので、コメントやTwitterでガンガンツッコんでくれると嬉しいです。
なんでそんなの作ってるの？
私がRTAをはじめたころ、RTA放送を行うのに必要なPCはCPUがCore2DUO、メモリが1GBあれば十分でした。
これは現在ではドン・キホーテで2万円で買えるようなPCのスペックに相当します。
あとは5000円の外付けHDDを購入すれば録画しながら配信も可能でしょう。
しかし現状はどうでしょう。
2万円や3万円のPCのスペックでは単にRTA配信をすることすらままならず、快適にRTA配信をしようと思うと15万円以上のPCが必要になります。
最近ではPCを持っていない若者も多い状況で、スマホ視聴でRTAに興味を持たれた方がRTAに参入するにはあまりに高い出費です。
これは配信やRTAに必要なソフトウェアが加速度的に重くなっていることに起因します。
当時マリオ64RTAの国内での標準タイマーとして使われていたSWfTAは、今主流のLiveSplitよりも遥かに軽いです。
RTA大会の連絡に使われていたSkypeは、定期的にログをクリーンすれば、Web技術をベースとしたDISCORDの4分の1のメモリ消費量で動作しました。（※今はSkypeもDiscord並に重くなりました。）
更にいうとOSもそうです。Windows 10のコルタナは頼んでもいないのにCPUを消費し、不定期なタイルの更新はネットワーク帯域を圧迫します。メモリもOSを起動しただけで1GBも消費するという体たらくです。
※Windows 10は普段からやや重いことに加え、突発的に大量の計算リソースを持っていく立ち回りをするので、突然録画がコマ飛びするなどの録画ミスにも繋がります。
※OBSは高負荷ですが、配信と録画をまとめられるので、おそらくRTAで一般的な録画しながらの配信というスタイルだと当時と負荷は大きく変わらないと思います。（要検証）
そんな状況に疑問を感じていると、LiveSplitのプロジェクトにLiveSplit Oneというプロジェクトを見つけました。
これは開発中のクロスプラットフォーム版LiveSplitだそうです。
試しに起動してみて驚きました。
あくまでタイムを測るツールであり、RTA放送の裏方に徹するべきタイマーが、SWfTAの軽く5倍以上の負荷をCPUとメモリに与えます。
こんなものが普及したら、それこそRTA放送に必要な予算は膨れ上がり、この世にRTAプレイヤーはビル・ゲイツとジェフ・ベゾスしかいなくなることでしょう。
これを見て私は新しい軽量なクロスプラットフォームなタイマーを開発することに決めました。
当然タイマーだけが軽くなっただけでは、この状況を大きく変えることはできません。
タイマーが軽くなってもDISCORDやWindowsは容赦なくマシンリソースを奪っていくでしょう。
少しRTA放送への参入のハードルを下げることができるかもしれない程度です。
それでも、このプロジェクトでRTAやゲーム配信に関わる方々の意識を変えることができれば、流れは変わるかもしれません。
クロスプラットフォームな軽量タイマーがあれば、PCにかけるお金がない人はWindows以外のOSを試すこともできます。
PCに詳しい人が先陣を切ってWindows以外のOSを使い始めれば、詳しくない方が放送する上で詰まったことを尋ねやすい空気もできるでしょう。
もちろん私もそれらの解説記事などを執筆するつもりです。
DISCORDの代わりを作ることは難しくても、大会に特化した情報交換ツールなどは作れるはずです。
目指すのは、スマホ視聴でRTAに興味を持った方が、3万円でRTA大会に参加できる世界です。
どんなものになるの？
基本的にはLiveSplit Oneと同等の機能を、SWfTAと同等の軽さで実現することを目指します。
また、LiveSplitのファイルをインポートしたり、逆にエクスポートしたりする機能も実現します。
ただし、初回リリースでは外部サイト（SRCなど）との連携はサポートされません。（うっかりバグって対象サービスに過負荷をかけたら申し訳が立たないため。）
また、先述の通りクロスプラットフォームです。
Windows以外のOSであれば、Windows XPのように軽く、セキュリティ上も問題のないOSは今も存在しています。
それらのOSでRTAを行うことができる環境を目指します。
（将来的には他のOSでのRTA配信の解説記事とかも書くかもしれません。）
進捗どうですか？
進捗ダメです。
現状最低限RTAのタイムを測るのに使えるかなという感じです。
現時点では驚くことにSWfTAより軽いようです。（完成版は機能が増えるのでもう少し重くなります。）
使用技術
GUI Widget toolkitはFLTKを採用
目指すのは軽量・マルチプラットフォームということで、Qt、GTK+、WxWidgets、FLTK、ネイティブで頑張って実装するが候補に上がりました。
これらを比較した結果、
・Qtはガーベジコレクションを採用している
現代においてGCが与えるパフォーマンスへの軽量は一般に軽微ですが、GCは走るタイミングでCPUリソースの消費が大きくなります。
RTA配信では一般的なPCの用途とは異なり、録画や配信、プレビューなどリアルタイム性を要求されるタスクが複数同時に走ることになります。
この特殊な状況下ではGCのようなメモリ管理は不適合と判断しました。
・GTK+は日本語Windows環境の動作が怪しい
GTK+を使ったソフトウェアは、Geanyのような有名プロジェクトですら、日本語Windows環境での動作が怪しくなっています。
また、MSYS2/MinGW環境でのGTK+は安定しているように見えますが、流石に開発者でもない人が導入するにはハードルが高すぎます。
・WxWidgetsはよくわからない
私がよくわかりませんでした（諦め）
・ネイティブでがんばって実装するのはつらい
ネイティブで頑張るなら開発メンバーが5000兆人ほしい！！！
ということでFLTKを選びました。
あとベンチマークみたらFLTKは描画が滅茶苦茶速いらしいのも嬉しい点です。
記録フォーマットはyamlの独自拡張
今回フォーマットに求めた要件は以下のとおりです。
1.省メモリ、高速に読み書きできること
2.外部アプリケーション開発者が容易に扱えること
2については、Splits.ioなどの優秀な外部ツールとの連携を見越したものです。
他に、当アプリが開発終了となったときに、他のタイマーアプリへのデータの移行を容易にする狙いもあります。
本来yamlにはファイル中に登場するデータの並び順を保証する仕様はありませんが、拡張によってこれを実現します。
常に最新の記録が末尾になるように調整し、保存のタイミングでファイルを丸読みすることを避けます。
この拡張により、外部のソフトウェアが書き出したyamlは読み込めなくなりますが、こちらが出力したyamlは一般的なライブラリで読み込めるようにします。
（また、変換は比較的容易なので、将来的には標準的なyamlも読めるようにするつもりです。）
LiveSplitのXMLフォーマットには平均タイムやプレイ回数が記録されていますが、これらはファイル内容から導出できるはずなので書き込み時の丸読みを避けるために省略します。
ファイル内容からこれらの値を計算するのに時間がかかってしまいますが、キャッシュファイルを持つことでこれを解決します。
個人のRTAプレイヤーが走るRTAのカテゴリはせいぜい20程度とすれば、キャッシュヒット率は極めて高くなることが予想できます。
時間測定
時間測定はstd::chrono::steady_clockを使うつもりです。
ナノ秒オーダーの精度は、人手でのタイマーストップどころかAutosplit Helperのようなツールですら担保できないと考えられるため、それよりも途中のPC設定変更に左右されないことを優先します。
ただし、とりあえず完成した後ですが、PCの内蔵タイマーが不正確な場合などはNTPを使うことなども考えるべきかもしれません。
おわりに
RTAをもっと広く楽しんでもらうために、オラに元気を分けてくれ！！！
