Posts

ルール： マークダウン構造を保護する。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 阿珏Blog十周年活動が無事に終了しました。 今年の参加者は私の予想を超えていました。活動期間中、群グループで手がかりやヒントを交換し、多くの人々が無事に最終的な報酬を手に入れました。2年前から計画を立てていたものが本当に誰かが真剣に遊んで終わったことに、とても嬉しいです、AIのサポートがあったとはいえ。 もしまだ遊んだことがない場合は、まず活動原文を見てください。これはすべての答えを直接公開し、以下は完全なストーリーです。ゲーム中にはあなたの認識を覆すような多くの知識内容があります。 全体フロー 拆弾専門家 → エントリーポート → ブラックアウト画像の調整 → ログインとキャプチャー → 偽Cloudflareページ → PDFにZIPを隠す → GalGame対話で手がかりを見つける → 数字を推測 → 二次元コードをスキャン → 異なるものを見つける → 明暗モードのアルバム → パズル → 保险庫。 第0関：拆弾専門家 最初の関節は小さな前菜です。ページには4本の異なる色の線とカウントダウンがあり、どの一本を切るかを慎重に判断するように見えます。 しかし、正しい答えはありません。どの一本を切っても爆発します。爆発後、ページは貴重なアルバムが粉々になったことを示し、片付けるよう指示します。 次にやるべきことは明確です：支線タスクを引き出し、後のエンディングで散らばったパズルのピースを見つけることです。 したがって、4本の線に時間を割く必要はありません。爆発効果を見るために一本を切るだけで十分です。 第1関：活動ウェルカムエントリーページ 公式エントリーページに到着すると、画面中央の「今すぐ参加」ボタンは普通のジャンプボタンではなく、画像のホットスポットを通じて実現されています。手形の光標が見えたら、その位置を直接クリックすると次のエンディングに進みます。このエンディングは観察力を試し、HTML画像のホットスポット機能を少し使っています。 クリックすると、ページがまず黒くなり、次にロードが停止しているように見えるページにジャンプします。このブラックアウトはロード失敗ではなく、少し待つと問題が解決します。 第1.5関：ブラックアウト中のロード ページはほぼ完全に黒いです。複雑なソースコードを確認する必要はありません。ページのスクリーンショットを画像エディタに投入し、露出、影、コントラストを調整するだけで十分です。目的も明確で、画像の処理、露出の調整、低コントラスト情報の観察力を試すだけです。 明るくすると、2つの重要な情報が見えます： 開催コード：blog10years 次のエンディング：/level/googleLogin/login.html 第2関：ログインページ ログインページにはユーザー名、パスワード、招待コードが必要です。ユーザー名は自分で入力できますが、招待コードは前のエンディングで見つけた blog10years です。 本当に厄介なのはパスワードです。開発者ツールを開き、Consoleで buildLoginHash 処理が既に定義されていることを確認します。直接呼び出すだけでよいです： buildLoginHash("阿珏", "blog10years") ユーザー名が変更された場合は、処理内のユーザー名も変更してください。HMAC-SHA256文字列として返される処理をコピーし、パスワードとして使用します。パスワードを手動で計算する必要はありません。 ログイン前にキャプチャーを完了する必要があります。正しいを選択すると本当にログインできます。 このエンディングは、ソースコードを確認する習慣や開発者ツールの使用を試しています。パスワードは長い暗号化テキストのように見えますが、ページは生成方法を目の前で提供しています。 ps:阿珏酱が使ったアイコンはこの数年で何度も明かされてきました。 ...

8 月 8 日、またまんが展に行きました。 这次は第十届迷鹿まんが展です。 最近は自分がまんが展に参加するのがだんだんと慣れました。基本的にはまんが展を見つけたら、時間があれば行くだけです。 特に何か特別な目的もありません。 ただ、散策したいし、コスプレを撮ったり、知り合いがいないか探したりです。 要するに： 若い頃に好きなことをしてみる 写真 家に帰ると、もちろん慣れた手順に戻ります。 写真を導入します。 そして開いてみると： “どうしてこんなに多いんだ？” 少しずつフィルタリングし始めます。 この写真は残す。 あの写真も残す。 いくつかの写真は自分がうまく撮れたと思って、残しました。 いくつかは一般的な写真ですが、削除するのがもったいないと感じました。 最後には： “いいか、全部残すことにする。” 編集を終えると、徐々にソーシャルプラットフォームにアップロードします。 そして少し経ってからまた見ると、 “当時もっとよく撮っていれば良かったのに。” とても普通のことです。 次にやります。 ここまでの記録はこれで 第十届迷鹿まんが展。 また普通のまんが展でした。 特に特別な話もありません。 “ああ、2026 年 8 月 8 日、迷鹿に行った。” これで十分です。 次にまんが展があるなら…… また行くことにします。 📷 阿珏酱 / まんが展のちょっとした記録 第十届迷鹿まんが展、終了。

ルール： マークダウン構造を保護する。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 この旅行は、伝説の「中国最も美しい十大海島」の一つ、嵛山島に行くことになります。 出発する前に、とても楽しみでした。 こんな場所は、ネットでちょっと検索すると、さまざまなスライドショーが見つかります：青い海、重層の山、遠くの海島、そして山の頂から一望する壮大な海の景色。 しかし実際に到着した後、気づいたのです—— 旅行というものは、本当に天気次第です。 登島 最初は、天気は実際にはそれほど悪くなかった。 道を歩きながら風を感じ、体が少しずつリラックスしていきました。 島の風景は都市とは全く異なります。 高層ビルが多くなく、喧騒もなく、視界が一気に広がりました。 歩きながら、好きな場所を見つけると写真を撮ります。 上山 山の下では、天気は実際にはそれほど悪くなかったようでした。 しかし、標高が高くなるにつれて、周囲が次第に白くなり始めました。 遠くの山は見えなくなりました。 海も見えなくなりました。 さらに、ある場所にたどり着くと、前方の数十メートルがぼやけてしまいました。 最初は少し霧がかかっているだけで、その後「霧が山頂を覆う」ようになりました。 山頂に到達した後、遠くはほぼ見えなくなりました。そしてその日、風がとても強く、吹き続けていました 本来なら遠くの海面を見ることができたはずですが、白い霧がすべてを覆ってしまいました。 そこに立っていると、「私は本当に雲の中にいるのか？」と感じることがありました。 もちろん、完全な山海の景色を見ることができなかったのは、少し残念でした。 なぜなら、嵛山島に来るのは珍しく、ネットの写真で見たような壮大な海の景色を見たいと思っていたからです。 「山の頂から海を見下ろす」のようなネットの画像は、一つも見ることができませんでした。 ここは最も有名な大天湖と小天湖ですハハ 最も写真撮りやすい場所 海辺に行く 海辺に到着すると、全く違った感じになりました。 海風が吹き込むと、体がとても快適になりました。 山の頂にいたときよりも、海辺はゆっくりと過ごすのに適しています。 特定の観光スポットに急いで行く必要もなく、常にカメラを持って撮影する必要もありません。 代画小人、一円一枚、童叟無欺 日没を見る 夕方になると、また日没を待ち遠しさえしました。 この時点では、すでに期待していました。 日中に山の頂から完全な海の景色を見ることができなかったので、夜には少なくとも日没を見ることができると思っていました。 しかし…… 雲がまた来ました。 太陽が次第に低くなると、空は雲で覆われていました。 夕日の一息を感じることができましたが、想像していた「太陽が海面に沈む」の様子は、待つことができませんでした。 树の影下 島には、夜になると若者が歌い酒を飲む砲台バーがあります。 海風を感じながら、話し合い、隣の海を見つめています。 その瞬間はとてもリラックスしていました。 旅行は時々そうなります。 必ずしも多くの場所を訪れる必要もなく、必ずしも一つ一つの時間を満たす必要もありません。 時には木の影に座って、海風を感じるだけで、とてもリラックスできます。 青空、白雲、海風、木の影 回程 山頂の大霧で、嵛山島の完全な山海の景色を見ることができませんでした。 ...

規則： マークダウン構造を保護。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 計算すると、私は既に漫展に行ってある時間が経っています。 しかし、もし私の正確なアイデンティティを尋ねられたら…… フォトグラファー？それはもちろんです。 切手収集家？それはもちろんです。 二次元ファン？これがもっと正確です。 カメラをかけ、携帯電話をポケットに入れて、美しいコスプレを見ると歩けなくなります。 この回は福州・第15回潮柚次元アニメフェスティバルに行きました。 イベントは2026年7月24日から26日に開催され、場所は皆さんがよく知っている福州海峡国際会展中心です。 出発、目標：写真撮影 + 切手収集 撮影しながら、散策しながら、切手収集。 次の瞬間に誰が会場のどこにいるかはわかりません。 私の漫展の日常 「先生、写真を撮っていただけますか？」 「先生、切手を収集していただけますか！」 「ありがとうございます！」 「先生、見てください」 「先生、逆面も撮ってください、微信を追加してください」 この言葉は、フォトグラファーの固定台词のように感じています。 しかし、私は写真撮影だけではなく いつもカメラを背負っていて、フォトグラファーのように見えますが。 しかし、私は普通の漫展ファンの方が多いと思います。 なぜなら、私は切手収集も好きだからです。 知っている先生に会ったら写真を撮ります； 好きなコスプレを見たら写真を撮ります； 以前に会った先生に再び会ったら写真を撮ります。 時には、写真を撮る目的でもありません。 「また会えた」と感じるだけで： 「これまた会えた。」 それで、記念に写真を撮ります。 これは漫展の面白い点の一つだと思います。 数年後、これらの写真を振り返ると、その日の具体的な出来事を覚えていないかもしれません。 しかし、写真を見ると、思い出します： 「あ、この漫展に行った。」 「その日はここで一整天撮影していた。」 「その先生がここにいた。」 この感じはとても良いです。 漫展の中の様々な瞬間 漫展で一番好きなのは、舞台やゲストではなく、普通の小さな瞬間です。 道端でヘアースタイルを整えているコスプレイヤー。 痛包を持ってどこかを歩いている観客。 初めて勇気を出してコスプレイヤーに写真を撮ろうとする人。 そして、カメラを持って人混みの中で角度を見つけているフォトグラファー。 これらを合わせて、私の印象の中の漫展が作られます。 ゲスト、サイン会とステージ この潮柚漫展では、多くのゲストやイベントもあります。 普通の観客にとって、ゲストのサイン会も漫展の中で面白い一部です。 好きな先生に会いに来た人。 本や葉書、周辺商品を準備した人。 長い列に並んで、一言だけ言いたい人。 漫展は実はとても奇妙な場所です 普段の現実生活では、皆さんは普通の人かもしれません。 ...

ルール： マークダウン構造を保護する。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 # MoeKoe Music Mobile オープンソースでシンプルで高颜值のサードパーティーKuGou Musicのモバイル端末プレイヤー Expo / React Nativeに基づいて構築され、MoeKoeMusicデスクトップ版のモバイル版実装です 🌎 GitHubリポジトリ | 📦️ ダウンロードパッケージ | 💬 ブログアクセス | 🏠 プロジェクトホームページ オープンソースでシンプルで高颜值のサードパーティーKuGou Musicのモバイル端末プレイヤー Expo / React Nativeに基づいて構築され、MoeKoeMusicデスクトップ版のモバイル版実装です ✨ 特徴 🎵 サーバー自建不要 — KuGou APIのアダプテーションレイヤーが直接公式に直結し、すぐに使用可能で、外部APIアドレスに依存しません 🏠 ホームページの推薦 — 毎日の推薦、選定歌単、ランキング 🧭 発見ページ — カテゴリ別歌単、新曲速報などのコンテンツ探索 🔍 検索 — 歌曲や歌単、アルバムの迅速な検索 📀 歌単 / アルバム / ランキング — 完全な詳細ページと曲リスト 🎧 プレイヤー — ロールシャッター歌詞、プレイリスト、ミニプレイヤー（MiniPlayer）、バックグラウンドプレイ 🎚️ 音質検出 — 利用可能な音質を自動的に検出し、選択 📱 電話番号ログイン — KuGouアカウントの收藏と歌単の同期 🌗 ダークモード — システムに従って明暗テーマを自動的に切り替え 📝 Todoリスト [x] ホームページの毎日の推薦 / 選定歌単 / ランキング [x] 発見ページのカテゴリ別内容の閲覧 [x] 歌曲や歌単、アルバムの検索 [x] 歌単 / アルバム / ランキングの詳細ページ [x] プレイヤー：ロールシャッター歌詞、プレイリスト、ミニプレイヤー、バックグラウンドプレイ [x] 音質検出と自動選択 [x] 電話番号ログイン [x] 認証情報ログイン [x] スキャンログイン（他のデバイス） [x] いいね / 收藏の同期 [x] ユーザー歌単管理（作成 / 收藏 / 編集） [ ] 通知バー / ロックスクリーンプレイコントロール [ ] 歌曲詳細の閲覧 [ ] テキストから歌詞の検出 [ ] タブレットと横画面の対応 [ ] パフォーマンス最適化 📸 プレビュー 🚀 快速スタート 環境要件 Node.js ≥ 22 Git iOSシミュレータ / Androidシミュレータ、または開発版クライアントがインストールされた実際のデバイス 開発と実行 # リポジトリをクローン（api submoduleを含む） git clone --recurse-submodules https://github.com/MoeKoeMusic/MoeKoeMusic-Mobile.git cd MoeKoeMusic-Mobile # 依存関係をインストール npm install npm --prefix api install # モバイル端末APIエントリを生成（api/ 更新後は再実行が必要） npm run generate:mobile-api # 開発サーバーを起動 npx expo start クローン時にsubmoduleが欠けている場合は、git submodule update --initを実行して補完できます。 ...

ルール： Markdownの構造を保護する。 URLやコードは翻訳しない。 翻訳された内容のみを返す。 MoeKoe Music エクステンション MoeKoe Music ブラウザエクステンション版は、MoeKoeMusic Webをベースに構築され、ブラウザエクステンション内でAPIルートの互換性を完了しています。 🌎 GitHubリポジトリ 特徴 ブラウザエクステンションのアイコンをクリックして、独立したウィンドウでMoeKoeMusicを起動します。 ユーザーがAPIアドレスを設定する必要はなく、ローカルのAPIサービスを追加で起動する必要もありません。 MoeKoeMusicのオリジナルWebページとインタラクションを保持し、ブラウザエクステンションの運行環境に互換性があります。 快速スタート 環境要求 Node.js 20以降 Git Chrome / EdgeなどのChromiumコアブラウザ 依存関係のインストール git submodule update --init --recursive npm install npm run install:app npm run install:appは、MoeKoeMusicとMoeKoeMusic/apiの依存関係をそれぞれインストールします。インストール後は、子モジュールのワークスペースを確認し、アップストリームのlockfileの非期待の変更をコミットしないようにしてください。 エクステンションの構築 npm run build 構築物は以下に输出されます： dist/extension ブラウザにインストール chrome://extensionsまたはedge://extensionsを開きます。 「開発者モード」を有効にします。 「既に解凍されたエクステンションをロード」をクリックします。 プロジェクトのdist/extensionディレクトリを選択します。 extensionソースディレクトリをロードしないでください。そうすると、ブラウザはマニフェストやバックグラウンドスクリプトの読み込みに失敗を通知します。 APIの実行方法 MoeKoe Music Webバージョンに比べて、このプラグイン版はユーザーにAPIアドレスを入力させることはありません。MoeKoeMusicのフロントエンドは、HTTPルートに基づいてリクエストを送信し、ビルド時にAxiosリクエストをエクステンション内部のメッセージチャネルに適用します。 リクエストフローは以下の通りです： MoeKoeMusic Web -> extension/app/api-adapter.js -> extension/api/service-worker.cjs -> extension/api/generated/modules.cjs -> extension/api/generated/modules.cjs -> MoeKoeMusic/api/module/*.js -> 酷狗関連インターフェース extension/api/generated/modules.cjsは生成ファイルで、scripts/generate-extension-api-entry.mjsがMoeKoeMusic/api/moduleをスキャンして生成します。APIモジュールを追加または更新した場合、以下のいずれかの命令を再実行します： ...

ルール： マークダウン構造を保護。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 ルール： マークダウン構造を保護。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 ルール： マークダウン構造を保護。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 在做插件市场之前，先有的是 MoeKoe 的普通插件系统。 当時我想解决的问题不是某一个具体功能，而是一个更通用的问题：播放器里总会冒出很多小需求，有些人想改界面，有些人想加一个工具弹窗，有些人想接自己的服务。如果每个想法都往主程序里塞，主程序会越来越重，也越来越难维护。 所以我一开始给插件系统定的方向很明确：主程序只提供插件运行环境和管理入口，具体功能交给插件自己做。插件能独立安装、独立卸载，坏了也尽量不要影响播放器本体。 上一篇我写的是 MoeKoeMusic-Plugins 这个插件登记仓库。那边解决的是“插件市场的数据怎么产生”：用户用 Issue 提交，Action 校验，维护者审核，通过后写进 plugins.json。 但光有登记仓库还不够。真正对用户来说，插件市场不是 GitHub 上的一份 JSON，而是客户端里一个能看、能搜、能安装、能更新的入口。 所以这篇就换到 MoeKoe Music 主项目里，专门聊客户端的插件市场部分。 为什么选 Chrome Extension 这一套 MoeKoe は Electron アプリであり、Electron 自身に拡張の読み込み能力があります。既に Chrome Extension が動作する底層があるので、新しいプラグインフォーマットをゼロから設計する必要はありません。 この方法はいくつかの利点があります： 第一，プラグイン作者は完全に新しいフォーマットを学ぶ必要がありません。manifest.json、popup.html、background.js はすべてブラウザ拡張でよく使われる概念です。 第二，プラグインには天然のリストファイルがあります。主プログラムはまず manifest.json を読み取り、プラグイン名、バージョン、説明、権限、ポップアップエントリ、最低サポートバージョンなどの情報を判断します。 第三，Electron はプラグインディレクトリを直接読み込むことができます。私がサンドボックススクリプトを書く必要はありません。 展示、検索、分页と状態 プラグイン市場はインストールできるだけでなく、迅速に判断する必要があります： このプラグインは何をしていますか 私はこれをインストールしていますか 私がインストールしているのは旧バージョンですか このプラグインにはより高いバージョン要求がありますか それがネットワーク、ファイルアクセス、ローカルバイナリなどのリスクポイントを持っていますか 分页、検索、更新、状態 したがって、市場カードには「インストール」ボタンだけでなく表示されます。 プラグインディレクトリが存在することを確認 Electron を呼び出してダウンロード、インストール、旧バージョンをアンインストール、新しいバージョンをインストール プラグイン関連の IPC を登録 Chrome 拡張をロード Native Host インデックスと認証システムをロード 已安装插件 プラグイン管理ページの「已安装插件」は、現在読み込まれている Electron 拡張だけでなく、二つの情報を統合します： ...

ルール： マークダウン構造を保護する。 URLやコードを翻訳しない。 翻訳された内容のみを返す。 MoeKoe Music 插件エコシステムを最初に作成した時、オンラインプラグイン市場という機能はまだありませんでした 後にコミュニティの提案により、このプラグイン市場が誕生しました 公式/コミュニティプラグインリポジトリを追加して製品機能を拡張 プラグインはコミュニティで開発されるので、プラグイン市場はどう管理すべきか？ 最も直接的な方法は、すべてのプラグインソースコードを一つの大リポジトリにまとめることです。しかし、この案は考えれば考えるほど不自然に感じられました。それぞれのプラグインには、それぞれの作者、それぞれのリリースリズム、それぞれのビルド方法があります。これらをすべて公式リポジトリにまとめると、メンテナンスコストが高くなるだけでなく、責任範囲も曖昧になります。 したがって、このリポジトリは最終的には「プラグインソースコードリポジトリ」として設計されず、代わりに「プラグイン登録とインデックスリポジトリ」となりました。それは以下の数点を行います： プラグインの上架、更新、下架、および報告の申請を受け取る 基本的な検証と静的認識を自動的に行う 人工的に承認されたプラグインのスナップショットを記録する クライアントが読み込める plugins.json を維持する READMEにプラグインリストを更新する、人々が読みやすくする 追跡可能な登記簿：誰が提出したか、どのバージョンが承認されたか、ダウンロード先はどこか、ネットワークやファイルの権限はどうか、すべて明確なデータにまとめられます。 市場インデックス、ソースコードリポジトリではなく リポジトリのルートディレクトリで最も重要なファイルは plugins.json です。これがプラグイン市場が実際に消費するデータソースです。 { "id": "custom-app-background", "name": "カスタム背景画像", "description": "MoeKoe Musicにカスタム背景画像機能を提供し、透明度調節をサポート。", "iconUrl": "...", "version": "1.0.0", "minversion": "1.6.1", "...":"....", "buildRequired": false, "networkAccess": false, "fileAccess": false, "binaryContent": false, "snapshot": { "iconUrl": "...", "repository": "MoeKoeMusic/custom-app-background-plugin", "commitSha": "dbf72d38c8cf6b1d1cefdf8ce15798d565678995", "downloadUrl": "hxx.zip", "release": null } } 私は市場が「プラグインリポジトリの「現在の最新コード」を常に記録するようにしないことを望んでいます。なぜなら、作者が今日提出したコードと、承認当日に見たコードが同じものではなかったかもしれないからです。プラグイン市場が本当に認めるべきは、承認されたバージョンです。 したがって、このプロジェクトには以下の核心原則があります： 上架されるのは、動き回るリポジトリのアドレスではなく、既にロックされたスナップショットです。 コンパイル不要のプラグインの場合、スナップショットはデフォルトブランチの当時のcommitにロックされます。コンパイルが必要なプラグインの場合、スナップショットは対応するReleaseタグと发行附件にロックされます。これにより、実際に問題が発生した場合でも、当時どのバージョンが承認されたかを振り返ることができます。 アクションが先に動く、人間が最後に決定する ユーザーがIssueを提出する際には、以下の選択を行う必要があります： 「新規上架」または「プラグインの更新」 GitHubリポジトリのアドレス インストール前にコンパイルが必要かどうか Actionが自動検証を行い、結果をIssueのコメントに書き込むと同時に、check-passedまたはcheck-failedタグをIssueに付ける。 ...

続き：《同じアニメーション、3つの技術スタックで実装したらどう違うの？》 WebGL による二次元じゃんけんゲーム。 ルールは普通： グー > チョキ チョキ > パー パー > グー でも面白いのはここ： 負けると服を脱ぐ。 ええ、それだけです。単純かつストレート。 きっかけは「スプライトシートを研究したかった」 最初はゲームを作るつもりなんてなかった。 ただ研究したかっただけ： atlas sprite レイヤー合成 アニメーションカット こんな技術要素。 それで考えたんです：「実際に使える場面がないと？」 そして思い付き： じゃあ、二次元脱衣じゃんけんにすればいいと。 そしたらプロジェクトが暴走し始めた。 このプロジェクトで一番大変だったのはゲームロジックじゃない じゃんけんのルールはシンプルすぎる。 本当に大変だったのは：服のレイヤー管理 キャラクターは「1枚の完成した画像」ではなく： ベース画像 (全裸バレ防止のため、わざと暗号化済み) 服 A 服 B 服 C アクセサリー 遮蔽レイヤー 重ね続ける。 「脱衣」の正体はレイヤー管理 プレイヤーが勝った： 設定された順番で服を1枚除去 コンピュータが勝った： 逆順で服を着せる 聞こえるのは簡単。 実際は山のような問題にぶつかる： 例えば「ベース画像が一瞬見えてはいけない」 これは特に重要。 もしこうすると： 古い服を先に消す 新しい服を後で追加する その一瞬ベース画像がチラ見えする。 見た目がすごく変になる。 なので後で：reveal カバーロジックを使うことにした。 新しいレイヤーが即座に上に被さる。 極力避けたい： 「裸が1フレーム映り込む」 プロジェクト自体は不真面目に見えるけど 少なくとも技術的には美しくありたい。 WebGL はここで本当に心地いい このプロジェクトは最終的に WebGL で実装した。 理由はシンプル：レイヤーが多すぎる。 ...

最近、なかなか面白い小実験をやってみました。 二次元キャラクターのちょっとしたアニメーション効果を、それぞれ： WebGL Canvas 2D 純 DOM + CSS の3つの方法で実装し直しました。 効果自体は複雑ではありません： まばたき 眉毛/下まぶたの連動 汗のゆらゆらした揺れ アホ毛の振り動き でも本当に面白いのは、「作れた」こと自体ではなく： 同じものを、3つの技術スタックで実装したとき、どれくらい差が出るのか？ というところです。 本質的には「フロントエンドグラフィクス色の濃い」再現実験でした。 最初はただアホ毛アニメーションを再現したかった インスピレーション元：https://tamanidamani.itch.io/nijikas-ahoge 当時のシンプルな思い：「自分だったらどう実装する？」 そしてやるほどに熱中してしまい、最終的にこうなりました： じゃあ、WebGL、Canvas2D、DOM の3パターン全部作ってみよう。 そうしてリポジトリは今の形になりました： canvas/ canvas2D/ dom/ 同じ効果を3つのバージョンで実装しています。 まず結論 一言でまとめるなら： WebGL が最強だけど、Canvas2D が一番書きやすくて、DOM がビジネス向け 1. WebGL バージョン：「本当のゲーム開発」に一番近い このバージョンが一番手間がかかります。 なぜなら本質的には「フロントエンドアニメーション」ではなく：GPU グラフィクスプログラミング だからです。 どう実装しているのか？ コアとなる考え方は： 背景レイヤー1枚 スプライトを重ねていく shader で描画制御 JS でアニメーションパラメータを動かす 例えば： アホ毛の回転 まばたきの切り抜き alpha ブレンド これらはすべて GPU 側で処理されます。 だんだんとこういうものに触れるようになります： uniform texture shader UV 頂点座標 テクスチャ座標 そして笑顔が消えていきます。 でも WebGL は本当に強い 要素が増えてくると、WebGL の「全然平気」という感覚が際立ちます。 特に： ...