GitHubとアンパンマンDB
GitHub
昔C#で作ってたちょっとしたツールをGitHubでソース公開しました。
ちゃんと作り込んだツールじゃないからバイナリの配布はしないけど、需要があるなら…JavaScriptでWebアプリ化したほうが使い勝手いいか?
アンパンマンDB(システム)
検索用データ更新処理競合対策中。
変化がないときにまで更新しないというシンプルな対策です。
ただ、動作確認してみたら、うまく動いてるんだか動いてないんだかよくわからない状況…。
動作確認方法も工夫必要かも。
昔C#で作ってたちょっとしたツールをGitHubでソース公開しました。
ちゃんと作り込んだツールじゃないからバイナリの配布はしないけど、需要があるなら…JavaScriptでWebアプリ化したほうが使い勝手いいか?
検索用データ更新処理競合対策中。
変化がないときにまで更新しないというシンプルな対策です。
ただ、動作確認してみたら、うまく動いてるんだか動いてないんだかよくわからない状況…。
動作確認方法も工夫必要かも。
来週の放送情報。
ナポレオンパイくん登場多いな。
やっぱり大変なので、ちょっと自動テストのほうを拡充中。
関連箇所全部一度に修正しないとエラーになっちゃうんですよね。
で、一箇所だけどうしてもテストできない場所があって…。
まあ、実際に使ってないからなんですが、一応その部分も対応しておきます。
あと…そうだ。
検索用データ更新まではすでにリリースしたんですが、本番投入してみたら、検索用データ更新処理中に別の書き込み作業をやると結構な確率で競合起こしますね。
このあたりはもうちょっと工夫が必要になりそう。
昨日実装したリンク情報、やりたかったリンク検索には役に立たないものでした。
いえ、本当はリンク検索自体は一応できる仕組みだったのですが、リストの何行目という情報が抜けていて、行情報を差し込めるような形式でもないので、ストリクトクエリによる同一行内複数条件に対応できなかったのです。
「それをわざわざやりたいケースがあるのか?」と言われると、複雑な検索を使い倒している自分でさえも、「ないな…」となってしまうので、こだわる必然性はないかもとは思うのですが、ここまで頑張ったからには、やり切ってしまいたいです。
それはそうとして、今のリンク情報も、あれはあれで使い道はありそうなので、そっちも含めて考えてみたいところです。
新たに公開された公式情報を追記しました。
リンク情報の件、保存の高速化と安定化を図って、ひとまずリリースしました。
今のところうまくリンク情報を保存できているようです。
これを使ってリンク検索を実装するのはこれから。

テンの日!!
は、そこそこにしておいて…
装備枠拡張クエストこなしました。
シャイニーメロンがなくて困ってる様子。
他の写真は以下から。
写真置き場「2025/03/10」
ふにゃ1リメイクのほうもやり残しはまだあるわけですが、こっちも考えてることが。
フレームレートのことです。
ふにゃ1は20FPS、ふにゃふにゃは同じく20FPS、ふにゃさんは40FPS、ふわふわふにゃは30FPS、ふわふわふにゃ on web browserは30FPS(内部90FPS)でした。
funyakは、60FPS(描画は60FPSを上限とした可変で、内部は60FPSを維持)です。
一方、きょうび、結構ハイスペックを要求する3Dゲームでも、240FPSとか平気で叩き出したりします。
もちろん、それはハイスペックPCと、最高峰の最適化が両立したらの話ですが、シンプルな2Dゲームなら低スペック+雑実装でも60FPSを当たり前に超えられるんじゃないかと。
まあ、普通のPC用モニタは60FPSが上限なので、映像の滑らかさという点では60FPS超えは意義が薄いと思われます。
しかし、内部処理は、時間を細かく刻めば刻むほど精度が上がり、変な挙動が抑えられます。
わかりやすいところでいうと、小さい物体を高速で移動させた場合、当たり判定を工夫しないと壁をすり抜けてしまうのですが、細かく刻むと、1フレーム当たりの移動量が抑えられるので、シンプルな当たり判定ですり抜けを防止できます。
ふにゃ特有の角抜け(するり)は細かく刻むことでは解決しませんが、これは工夫は工夫でも簡単な工夫で済むのでまあいいかと。
まだ思い付きレベルだし、まずはふにゃ1リメイクのほうを優先して、FPSの件は後回しにしようと思います。