設定メモ: 2025

2025年9月29日月曜日

skyseaとfirefox

ここ最近会社のfirefoxで全くwebが見れなくなる現象が起こる。

原因は多分skyseaとか言う糞システムのfirefox用拡張機能だと思う。

firefoxの更新とか、何かのタイミングでskysea拡張機能の同意ボタンを押さないと何も表示出来ない作りになってるようだが、これにバグがある。

バグって同意ボタンが表示されない時はfirefoxが永久に使えなくなる。この拡張機能は勝手に入れられて尚且つ無効に出来ないので質が悪い。

拡張機能の設定(プライベートブラウジングで無効にするとか)を変えたり、他の拡張機能の有効無効を切り替えたり、デバッグモードにしたりしてると、何かのタイミングで再読み込みされるのか、同意ボタンが表示されて使えるようになる。

すぐに何とかしたい場合は新しいプロファイルを作るしかない。

これが発生すると他の拡張機能の設定を消し去ってくれる。

これ作った奴を殴り倒したい。

2025年8月4日月曜日

3Dモデリングをやってみる

ミャクミャクの3Dモデル

子供がずいぶん気に入っているので、ミャクミャクをVtuberみたいに動かせたらいいなと思って探してみたが、今一つ簡単に使えそうなのがなかった。

仕方ないのでちょっとyoutubeの初心者講座を見ながらblenderで作ってみた。我ながらなかなかいい感じの形になった。

使った機能はだいたい以下くらい。

gで移動
sで拡縮
iで面を入れる
eで押し出し
ctrl+rで分割
ctrl+dで複製
サブディビジョンサーフィス
ミラー

ミラーは分割したあたりに点が二重にあったりすると変な感じになって結構悩んだ。以下で解決。

点が重なってたら重なってる点を消して一つにする。
ミラーの境目に線が入ったりする場合は、ミラーで二重になってるので、マージで一つにする。

ボーンとやらも入れてみた。ちょっと胴長？

カメラでモーションキャプチャーして動かしたかったが、ここまで丸一日かかったのでまた今度。

単色でテクスチャもいらないし、丸いところはコピペでいいし、初心者向けにいい題材な気がする。

でも肘のしずくみたいなところとか、赤いところがめり込んだりとか、変なところは多い。ちゃんとやろうとすると無限に時間が溶けていきそうだ。3Dモデリングって大変なんだなあ。

参考にした動画

https://www.youtube.com/watch?v=uMeXuB82uZc&t=2026s

https://www.youtube.com/watch?v=Mp_8XHBUTpg

https://www.youtube.com/watch?v=mFJNdIKApPc&t=167s

参考にしたページ

https://styly.cc/ja/tips/blender-modeling-start5-2

2025年7月8日火曜日

年末調整ってどういう計算？

いまだに何が何やら分からない年末調整について、確認してみた。会社とか人によって違うと思うが、自分用のメモとして残す。

以下の順に計算する。

1. 支払金額 = 年収
2. 給与所得控除後の金額
3. 課税される所得金額
4. 所得税
4-1. 所得税(ローン控除)
4-2. 所得税(+復興特別所得税) = 源泉徴収税額
5. 所得税還付金

以下、仮に年収900万（あくまで仮に）だとした場合

1. 支払金額 = 年収

給与明細の「課税支給合計額」を1～12月まで足したもの。

これはさすがにメモする必要はないだろう。
と思ったが、通勤費は非課税で、食費補助手当は課税のようだということはメモしておく。

2. 給与所得控除後の金額

支払金額から控除を引く。税金を安くするためには所得が低ければ低いほどいいのだ。
表は左が入力、右が出力のイメージ。黄色と緑で示したところは源泉徴収票に載っていたので検算できる。

支払金額	9000000
給与所得控除額	1950000	給与所得控除後の給与等	7050000
		所得金額調整控除額	50000
		給与所得控除後の金額	7000000

給与所得控除額は年収により決まっていて、これを引くことができる。900万->705万。

扶養親族が居たりすると、所得金額調整控除額を引くことができる。

所得金額調整控除額 = (支払金額-850万)x10% = 50000円

差し引き700万が所得税がかかる金額のベースになる。
ここからさらに控除を引くことができる。

3. 課税される所得金額

給与所得控除後の金額から、さらに各種控除を引く。

給与所得控除後の金額	7000000
基礎控除額	480000
社会保険料等の金額	1273500
生命保険料の控除額	120000
地震保険料の控除額	5000	所得控除の額の合計額	1878500
		課税される所得金額	5121000

基礎控除は年収によって決まるが、よっぽど高給取りでなければ48万だろう。

社会保険料「等」の金額とあるが、自分の場合は以下だった。

社会保険料等の金額 = 健康保険料＋厚生年金保険料＋介護保険料＋雇用保険料

厚生年金保険料が年収の18.3%、その他健康保険料等は合わせて10%くらい（自治体による？）。計28.3%が社会保険料等として奪われる。が、半分は会社が持つので、年収の14.15%くらいが社会保険料等の金額になるだろう。

仮に900万だと上記127万くらいになる。
実際には会社が（自分が働いたことによる利益から）払っているので、本来の年収は1027万くらいで、254万くらい国に取られているとも考えられる。一見して払っている額が少ないように見せるトリックが使われているようだ。

生命保険料、地震保険料の控除額は、毎年年末調整で提出するアレ。

これらの控除の合計が「所得控除の額の合計額」となる。
給与所得控除後の金額から差し引くと、儲けとなる「課税される所得金額」が512万くらいとなった。(1000円未満切り捨て)

4. 所得税

「課税される所得金額」によって決まる税率/控除額から所得税額を出す。

課税される所得金額	5121000
所得税率	0.2
控除額	427500
		所得税	596700

税率/控除額は以下の表で決まる。

所得金額が500万くらいなら20%で控除額427500円。これで所得税が決まる。

所得税 = 課税される所得金額 x 20% - 427500円

これで所得税596700円と出る。

4-1. 所得税(住宅ローン控除)

ローンがあると所得税から控除できる。

所得税	596700
住宅取得等特別控除額	150000
源泉徴収時所得税減税控除済額	90000
		所得税-ローン控除	356700

所得から引くのではなく、直接税金が減るのでなかなか大きい。

4-2. 所得税(+復興特別所得税) = 源泉徴収税額

ここまで計算してなかなか数字が合わなかったが、復興特別所得税2.1%を追加することで源泉徴収票の「源泉徴収税額」と一致した。(100円未満切り捨て)

所得税-ローン控除	356700
復興特別所得税率	0.021
源泉徴収税額	364100	所得税(＋復興特別)	364100

（人によってはほかにも何かあるかもしれないが）これが国に取られる所得税になる。

5. 所得税還付金

と見せかけて、実際には1～12月にかけて、だいたいの雰囲気で所得税は取られていて、給与明細にも載っている。

毎月取られているが、当然年末にちゃんと計算した結果と合うわけがないので、払い過ぎた分が12月か1月に帰ってくる。

所得税還付金 = 1～12月に払った所得税の合計 - 源泉徴収税額

これが給与明細に載っている額と一致した。
なんか源泉徴収票の計算が間違っているような気がして計算してみたが、合っていたようだ。

2025年6月24日火曜日

トリドールの株主優待の残高

トリドール（丸亀製麺）の優待が金券じゃなくて優待カードになって久しい。

残高はwebで確認できるが、こんな感じでログインが必要。

ブラウザは最後の4桁しか自動入力してくれなくてめちゃくちゃめんどくさい。

「これで」とか言ってカードを出して残高がなかったら恥ずかしいので残高は確認したいが、めんどくさいのは嫌だ。

ワンクリックで確認したいので何とかしてみる。

GETでやってみる

開発者ツールで見てみる。

POSTしているようだが、たぶんGETでもいけるんじゃないのか？

https://www.vcsys.com/s/toridoll/p/login?cardId1=xxxx&cardId2=xxxx&cardId3=xxxx&cardId4=xxxx&cardPin=xxxxxx&kind=%83%8D%83O%83C%83%93

cardId1～4のxxxxを4桁ずつのカード番号、cardPinのxxxxxxのところをpin番号に置き換えてブックマークしておく。%83%8D%83O%83C%83%93はcopilotに聞いたところsjisで「ログイン」らしい。

firefoxで開いたら残高表示された。多分ほかのブラウザでも行けると思う。

知らんうちに6000円くらい溜まっていたようだ。

POSTでやってみる

GETだとさすがにセキュリティ的によくなさそう。（別に残高知られても困ることはないが）

javascriptでPOSTするコードをブックマークレットにしておけばいいかもしれない。

javascript:(function(){
    var form = document.createElement('form');
    form.action = 'https://www.vcsys.com/s/toridoll/p/login';
    form.method = 'post';

    var ids=['cardId1','cardId2','cardId3','cardId4','cardPin','kind'];
    var vals=['xxxx','xxxx','xxxx','xxxx','xxxxxx','%83%8D%83O%83C%83%93'];

    for(var i=0;i<ids.length;i++){
        var q = document.createElement('input');
        q.name = ids[i];
        q.value = vals[i];
        form.appendChild(q);
    }

    document.body.appendChild(form);

    form.submit();
})();

valsのxxxx,xxxx,xxxx,xxxxにカード番号、xxxxxxにpinを入れてブックマークのURLにセットする。

androidのfirefoxでも行けた。他のブラウザは未確認。

ただしfirefoxのブックマークにpin等が記録される事は気にしないものとする。

2025年4月30日水曜日

C言語のforとマクロで簡単な時間計測

前回、処理時間計測の必要に駆られた。いちいち時間計測のコードを入れて回るのが面倒なので、forとマクロで簡単に計測した。

enum{
        SW_SH2,
        SW_HBIN,
        SW_HBOUT,
        SW_VBIN,
        SW_VBOUT,
        SW_SCSP,
        SW_SCU,
        SW_68K,
        SW_SMPC,
        SW_CDB,
        SW_SYNC,
        SW_MAX
};
static const char* swname[]={
        "SW_SH2",
        "SW_HBIN",
        "SW_HBOUT",
        "SW_VBIN",
        "SW_VBOUT",
        "SW_SCSP",
        "SW_SCU",
        "SW_68K",
        "SW_SMPC",
        "SW_CDB",
        "SW_SYNC",
        "SW_MAX"
};
static u64 swbuff_[SW_MAX];
static u64 start_time_ = 0;
static int sw_flag = 0;

#define SW(n) for(tick_start();sw_flag;tick_end(n))

static void tick_start()
{
        sw_flag=1;
        start_time_ = YabauseGetTicks();
}
static void tick_end(int n)
{
        u64 diff = YabauseGetTicks() - start_time_;
        swbuff_[n] += diff;
        sw_flag=0;
}
static void tick_clear()
{
        for(int i=0;i<SW_MAX;i++){
                swbuff_[i] = 0;
        }
}
static void tick_show()
{
        for(int i=0;i<SW_MAX;i++){
                printf("%d:%s: %llu\n", i, swname[i], swbuff_[i]);
        }
}

for文は最初と最後で文を実行できるので、これを利用して、tick_start()とtick_end()を呼び、sw_buff_に時間を足していく。tick_startでループ条件ON、tick_endでループ条件OFFとすれば、ループにならない。

こうしておけば以下のようにSW(番号){}で囲むと時間を計って加算してくれる。

SW(SW_SH2){ 
  計測したい処理(SH2)
} 
SW(SW_SCU){
  計測したい処理(SCU)
}

新しいCならforの中で変数宣言できるので、工夫すれば入れ子で計測できたりしそうだが、そこまではやってない。

YabauseGetTicks()は現在時刻を取得するようなyabauseの関数で以下のようになっている。

u64 YabauseGetTicks(void) {
#ifdef WIN32
   u64 ticks;
   QueryPerformanceCounter((LARGE_INTEGER *)&ticks);
   return ticks;
#elif defined(_arch_dreamcast)
   return (u64) timer_ms_gettime64();
#elif defined(GEKKO)
   return gettime();
#elif defined(PSP)
   return sceKernelGetSystemTimeWide();
#elif defined(ANDROID)
        struct timespec clock_time;
        clock_gettime(CLOCK_REALTIME , &clock_time);
        return (u64)clock_time.tv_sec * 1000000 + clock_time.tv_nsec/1000;
#elif defined(HAVE_GETTIMEOFDAY)
   struct timeval tv;
   gettimeofday(&tv, NULL);
   return (u64)tv.tv_sec * 1000000 + tv.tv_usec;
#elif defined(HAVE_LIBSDL)
   return (u64)SDL_GetTicks();
#endif
}

という事でやってみた結果、遅い処理はどうやらSH2とSCUのエミュレーション部分のようだった。

SH2部分はダイナミックリコンパイル(JITコンパイル？)されていて、もうこれ以上は早くならなそう。

SCUも同じような感じでコンパイルしなおせば早くなるのかもしれないが、かなり特殊な命令形態っぽいので、簡単にアセンブラに変換はできないような気がする。これ以上はもう無理か。。あと2倍くらい早いか倍のコア数がある端末ならば、何とかなりそうな気がするが。。

2025年4月19日土曜日

続5：中華linuxゲーム端末Anbernic 353PSでセガサターン

今度こそyabasanshiro-saでGRANDIAのムービーが遅い原因を調査する

とりあえず忘れないうちに覚書をメモ

ここまでの調査でFBCRへの書き込みで画面をマニュアル更新していることは分かっている。要はこの画面更新のタイミングがなぜ遅いのかが問題となる。単にタイマーのエミュレーションにバグがあるとかだったら直せそうなので調べてみる。（そうであってくれ）

FBCR(25D00002)への書き込みを行っているのがどこなのか探してみる。いろいろやったがよくわからず、SSFのデバッグ機能で、25D00002を検索した。（ような気がする。うろ覚え）

そしてprintf結果と突き合わせて、どうやら060129baでFBCRに書いているようだとわかった（と思う）

そしてその近辺でpcをprintfした。普通こういうタイミングが重要な処理は割り込みのタイミングでやるはず。急にアドレスが飛んで戻っているので、おそらく割り込みだろうと決めつけて調べる。

pc 06039f94
pc 06037b10
pc 06013a1c <= なんとなくここで割り込みっぽい気がする
pc 06012952
pc 06012988
pc 0601298e
pc 06012996
pc 060129a8
pc 060129ba
mw 25D00002 @060129ba
pc 06013a34
pc 06015144
pc 06015160
pc 060151c8
pc 060151f4
pc 06015210
pc 06015222
pc 06039ae4

再びSSFで06013a1cを検索、06000a04が見つかる。なんか割り込みベクタっぽいアドレスだ。ただ、SSFの画面を見る限りはVBRは06000000と060000400で、微妙に遠い。ただ、限りなく割り込みっぽいので、Interruptで検索してprintfを入れまくる。そしてここで06013a1cを登録しているっぽいことが分かる。

static void FASTCALL BiosSetScuInterrupt(SH2_struct * sh)
{
SH2GetRegisters(sh, &sh->regs);

LOG("BiosSetScuInterrupt. vector = %02X, func = %08X\n", sh->regs.R[4], sh->regs.R[5]);

これで、どうやらベクタ番号41番と分かり、先日見つけたサターンの仕様を見ると

SCU Interrupt
bit 1 V-blank-OUT VDP2 vector 41 Level E

となっている。1画面書き終わったら発生するV-blank-OUTの割り込みのようだ。という事は単に1画面60フレームごとに割り込みでマニュアル更新しているということになる。

単に画面の描画が60fpsに間に合ってなくて遅くなっているという事だろう。エミュレーションバグとかではなかった。簡単に治せそうにない。当てが外れたようだ。

フレームスキップが有効になっているが、無効にしても同じ速度で動いている。自動フレームスキップが何の役にも立ってなさそうだ。何か違うところが遅いのかもしれない。

実機でしか動かせないからどこが遅いのかしらべるの大変そう。。

2025年4月13日日曜日

MOONLIGHT & SUNSHINE

ROCKNIXでMoonlightとやらの設定があった。どうやらNvidiaのGameStreamとやらでPC上のゲームをlinuxゲーム端末で遊べるというものらしい。

ただ、いくら探してもnvidiaのアプリ上にgamestreamらしきものはなかった。どうやら非対応になった模様。

それに代わるものとしてMoonlightの開発チームがsunshineというものを作っているようだ。PC上にsunshineをインストールし、PCのIPをlinuxゲーム端末に設定すると、遠隔でPC上のゲームを遊べる。

PCは電源を入れてsunshineを動かしておかなければならない。wakeonlanとか設定して自動ログインとかにしておけばいつでも遊べる感じになりそうだが、めんどくさいのでそこまではしない。

steamのbig pictureが多分最初から設定されていて（インストールされてあったら自動的に登録されてたりする？）、まあまあそれなりに遊べそう。

マウス入力はできなそうなので、ゲームパッドで遊べるやつ専用かな。とりあえず428は遊べそうだが、画面サイズが640x480でなんか縦長に圧縮されたような画面になってちょっと気になる。

終わらせ方はSELECT+RUN+L1+R2同時押しで終わる。

2025年4月10日木曜日

自民党がまた金配るみたいだな

現役世代から金をとって老人に配りたいんだろう。それで票を買いたいわけだ。そもそも配るくらいなら最初から取るなと言いたいところだが、一度作った仕組みは変えたくない、一度取り始めた税金は意地でも減税したくないという事だろう。

プログラム的に言うと継ぎ足し継ぎ足しで無駄コードがわんさか入っているスパゲッティコードだけど、動かなくなるから削るなみたいな感じだろうか？

放送法とか。当初は電波塔とかの整備で予算が必要だったのかもしれないが、もう要らんはずだし。ガソリン税も二重課税になって、一般財源にされて何に使ってるかよくわからなくなってる。流用流用で何に使ってるか分からないまま税金だけどんどん増えている。

プログラムだったら、コードを見直して、何がどうなっているか把握できる状態を保っておかないと管理できなくなるんだが。都度見直しして根本原因を直す。コードは常にきれいに無駄なく保つってことができない奴は優秀とはいえない。

口先だけの文系に任せてるからこうなってるんじゃないのか？もっと理論立てて仕組みを考えられるやつにやらせたほうがマシになるんじゃないのか？

と思ったりしていたが、アメリカではイーロンマスクが容赦なくリファクタリングしまくっているようだ。将来的には無駄を排除したすっきりしたシステムになるのかもしれないが、どうなるんだろう。結構な痛みは伴っているようだが。

しかしアメリカはすごいな。日本だと一人二人変わったところで、何も変わらずスパゲッティを肥大化させていくだけだろう。

2025年4月5日土曜日

続4：中華linuxゲーム端末Anbernic 353PSでセガサターン（更新）

yabasanshiro-saでGRANDIAのムービーの音がおかしい原因の調査の覚書のメモ（更新）

GRANDIAを動かすとムービーが遅い気がする。そして雑音だらけで何を言っているか分からない。遅いせいで雑音だらけなのか？音だけでも何とかしたい。と思って調べた。

ソースコードvdp2.cpp:882くらい

swap_frame_bufferがmanual changeされていて、VDP1 offset 0x02にval=3が書かれたとき更新される。

FBCR	Frame buffer switching mode

どうやら遅いわけではなく、もともとそういうスピードにしてそう？？

音が雑音だらけで遅くなっているのかと勘違いしていた。どうやら雑音だけの問題の模様。

セガサターンの音を再生する機能（SCSP）にはSLOTというものがあり、オープニングムービーでは、SLOT04とSLOT08を使っている模様（SSFのデバッグモードを使うとわかる）

08だけ生かすとほぼ無音（あっているのか？）
04だけ生かすとノイズまみれ。ただ、ノイズにまみれた中で、ところどころ正常な音が鳴る。部分的に問題なさそう。

とりあえずSLOT04が悪いようだ。

データを見てみると、サウンドバッファにあるデータをM68kに投げて、データを戻してから再生するようだ。おそらく、M68kとやらを使って圧縮された音を展開しているんじゃないだろうか。

原因を調べようとprintfを入れると音がマシになる。

またタイミング問題かよ。。。

タイミングの問題を調べようとする

なんかyabause.cのあたりで、CPUシミュレーションとSCSPシミュレーションの同期が取れてないような気がしてきた。

とりあえずyabause.cの中を見てみる

deciline = 1/10ライン
SCSP 44100 * 512 clock？
M68k 44100 * 256 clock？

decilineの9と10でHBlankINとHBlankOUTになり、ScspExecされる

PAL 50フレーム x 313ライン
NTSC? 60フレーム x 263ライン

1/10ライン当たり 143.0874... clockということ
この端数が良くないとか？

scsp_cycles_per_deciline =

VLBlankで
    setM68kCounter((u64)(44100*256/60)<<SCSP_FRACTIONAL_BITS)
    SmpcINTBACKEnd()
    Vdp2VBlankIN()
    SyncCPUtoSCSP()

と見ていった中で、SyncCPUtoSCSPが実質何もやっていないように見える。

CPUから書いたデータをSCSPで受けて、M68kに渡して展開、戻ってきたデータを(ここで壊れている感じ？)SCSPで鳴らす。 CPUとSCSPでタイミングを合わせないとうまくデータがやり取りできないのでは？

とりあえずの解決策

よく見ると、SCSPのコードには2通り実行コードがあった。

void ScspExec(){
if (thread_running == 0){
    thread_running = 1;
    if (g_scsp_main_mode == 0) {
      YabThreadStart(YAB_THREAD_SCSP, (void * (*)(void *))ScspAsynMainCpuTime, NULL);
    }
    else {
      YabThreadStart(YAB_THREAD_SCSP, (void * (*)(void *))ScspAsynMainRealtime, NULL);
    }
    YabThreadUSleep(100000);
}
}

何も変えない場合、ScspAsynMainRealtimeで動く。試しにg_scsp_main_modeを0にして、ScspAsynMainCpuTimeに変えてみると、雑音がなくなった。ただ、やっぱりスロー再生みたいになっているようだ。なんか遅い気がした感覚は気のせいではなかったようだ。

見たところRealtimeの方は時計の時間に同期して動くように見える。それに対してCpuTimeはおそらくシミュレーション時間に同期して動くものだと思われる。ここで雑音になった原因を考えてみると、端末のCPUが貧弱なためにCPUエミュレートが遅くなり、ムービーがスロー再生気味になるのに対し、SCSPだけ現実時間で動いて同期が取れなくなり、音声データがおかしくなり雑音だらけになったという事だろう。当初推測した原因（遅いせいで雑音になる）は一応当たっていたという事になる。

なんにせよグランディアの音が正常に鳴るようになった。やったー。と言いたいところだが、今度はスロー再生になるのが気になってしまう。CPUの処理能力が足りないんだろうが、うーん。。

FBCRで毎回書いてるみたいだから、なぜそれが遅くなっているかだなあ。

2025年3月25日火曜日

続3：中華linuxゲーム端末Anbernic 353PSでセガサターン

前回に引き続き、yabasanshiroがメモリを消費しまくる原因を探している。

_ZNSt10_HashtableIjSt4pairIKjiESaIS2_ENSt8__detail10_Select1stESt8equal_toIjESt4hashIjENS4_18_Mod_range_hashingENS4_20_Default_ranged_hashENS4_20_Prime_rehash_policyENS4_17_Hashtable_traitsILb0ELb0ELb1EEEEC4Ev
toolchain/aarch64-rocknix-linux-gnueabi/include/c++/14.2.0/bits/hashtable.h:539 (discriminator 2)
_ZN10DynarecSh210SetContextEP10SH2_struct
yabause/src/sh2_dynarec_devmiyax/DynarecSh2.h:320
SH2Reset
yabause/src/sh2core.c:180 (discriminator 1)
YabauseStopSlave
yabause/src/yabause.c:966
_Z11yabauseinitv
yabause/src/retro_arena/main.cpp:272
main
yabause/src/retro_arena/main.cpp:440 (discriminator 1)

このあたりでメモリ消費が大きいという事で、ファイル名からしてダイナミックリコンパイルの処理の模様。

試しにインタプリタ方式で実行してみると嘘のようにメモリ消費量が下がった。変更するところは以下。src/retro_arena/main.cppのyabause_init()内、

yinit.sh2coretype = 0;

とすると、上の方で定義しているSH2Interpreterが選ばれる模様。ただ、これだとインタプリタなので遅い。早く動かしたくてstandalone版を何とかしようとしているので、本末転倒になる。

次はこのダイナミックリコンパイルの処理を何とかしないといけないという事だ。

メモリリークの場所

探すのにだいぶ苦労したが、 DynarecSH2.cppのInit部分

void CompileBlocks::Init()
{
dCode = (Block*)ALLOCATE(sizeof(Block)*NUMOFBLOCKS);
memset((void*)dCode, 0, sizeof(Block)*NUMOFBLOCKS);

この関数は最初だけじゃなく、結構何回でも呼ばれる。そのたびにdCodeが新しく確保されていく。とりあえずNULLじゃなかったら確保しないようにすればメモリリークはなくなる。

最初はdCodeのサイズ自体が大きすぎるのかと思って削減用のコードを書いてしまった。半分くらいに減らしたところで、よく見たら16MB程度であり、何かのきっかけで20MB程度増えるという現象に合致する数字であることに気づくという失態。

本家のソースを見るとすでに対処済みのようだった。見当がついた時点でそっちを見ればよかった。

root        2897 227 26.1 1060784 262320 pts/0 Rl+ 01:46 22:07 |           \_ /tmp/yabasanshiro -r 2 -i /storage/roms/saturn/AdvancedWorldWar.chd
root        2897 227 26.1 1060784 262360 pts/0 Rl+ 01:46 22:09 |           \_ /tmp/yabasanshiro -r 2 -i /storage/roms/saturn/AdvancedWorldWar.chd
root        2897 227 27.1 1060784 271604 pts/0 Sl+ 01:46 22:11 |           \_ /tmp/yabasanshiro -r 2 -i /storage/roms/saturn/AdvancedWorldWar.chd
root        2897 226 25.2 1050692 252664 pts/0 Sl+ 01:46 22:12 |           \_ /tmp/yabasanshiro -r 2 -i /storage/roms/saturn/AdvancedWorldWar.chd
root        2897 226 25.0 1049160 251088 pts/0 Sl+ 01:46 22:12 |           \_ /tmp/yabasanshiro -r 2 -i /storage/roms/saturn/AdvancedWorldWar.chd

何回か戦闘してもメモリ250MBくらいに収まっている。仮想メモリは1GBくらい行っているので最悪それくらいまでは消費し得るのかもしれないが、今のところ大丈夫そう。おそらくは前回確認したcurrentQuadの部分だと思われるが、際限なく増えるわけではないのでとりあえず良し。

あとはGRANDIAのムービーが激重でコマ送りになっているのが何とかなればいいんだけど、これはちょっと見当つかないな。

登録: 投稿 (Atom)

設定メモ