mieki256's diary

_04_fullscreen_hgimg3.hsp

    ; hgimg3 fullscreen sample.
    
    #include "hgimg3.as"
    #include "d3m.hsp"
    
    #packopt name   "04_fullscreen_hgimg3"  ; file name
    #packopt type   0   ; generate ".exe"
    
    #define TEXFILE     "tex.png"
    #define FONTFILE    "font.png"
    
    #pack   TEXFILE
    #pack   FONTFILE
    
    #define KB_ESC      $00080
    #define FRAMERATE   60
    
    ; get desktop size
    dispx = ginfo_dispx
    dispy = ginfo_dispy
    
    ; initialize window without frame
    bgscr 0, dispx, dispy, 0, 0, 0
    
    hgini                       ; initialize hgimg3
    
    ; init bimap font, load font texture
    setfont 20, 20, 18, 1   ; 20x20 font
    texload FONTFILE
    
    ; load texture
    texload2 TEXFILE
    texid = stat            ; get texture ID
    texw = 512
    texh = 512
    
    ; Set the buffer to draw from. Windows ID 0
    gsel 0, 1
    
    clscolor $4080c0        ; set clear color
    
    angle = 0.0
    
    time_start = d3timer()
    
*mainloop
    ; get FPS
    tm = d3timer() - time_start
    fps = d3getfps()
    
    ; ESC key to exit
    stick k, 0
    if k & KB_ESC : goto *job_end
    
    angle += 0.5
    
    ; ----------------------------------------
    ; draw start
    hgdraw
    
    objmax = 64
    repeat objmax
        r = double(dispy) * 0.5
        a = angle + (270.0 / double(objmax)) * double(cnt)
        x = int(r * cos(deg2rad(a))) + (dispx / 2)
        y = int(r * sin(deg2rad(a))) + (dispy / 2)
        d = double(cnt) / double(objmax)
        
        ; draw image by crlput
        gmode gmode_rgb0, texw, texh
        pos x, y
        
        src_x = (idx \ 2) * texw
        src_y = ((idx / 2) \2) * texh
        idx = (cnt \ 4)
        rot = deg2rad(angle * 2.0 + 360.0 * d)
        scale = 8.0 - (7.5 * d)
        dst_w = int(double(texw) * scale)
        dst_h = int(double(texh) * scale)
        
        ; draw texture
        hgrotate texid, src_x, src_y, rot, dst_w, dst_h
    loop

    ; draw text
    gmode gmode_rgb0
    fprt strf("[%dx%d] %d/%dFPS", dispx, dispy, fps, FRAMERATE), 10, 10
    
    hgsync (1000 / FRAMERATE) - 1   ; draw end and wait
    
    goto *mainloop

*job_end
    hgbye       ; release HGIMG3 plugin
    end

使用画像は以下。

_font.png
_tex.png

表示結果は、hsp3dish のソレと大体同じなので省略。

以下の環境で動作確認。

• メインPC : CPU AMD Ryzen 5 5600X + GPU NVIDIA GeForce GTX 1060 6GB + RAM 16GB, 画面解像度 1920x1080
• サブPC : CPU AMD Athlon 5350 + オンボードGPU Radeon R3 + RAM 4GB, 画面解像度 1920x1080

メインPC上では60FPS前後のFPSが出た。これは予想通り。hgsync に与えているwait値が正確な1/60秒になってないので誤差が大きく出ていた気もするけれど、大体似たようなFPSになってれば、まあいいかと。

問題はサブPC。12 - 17FPS しか出ない。hsp3dish を使った時と似たようなFPSになった。

サブPCの Radeon R3 で OpenGL を使うと遅いのではないか、DircetX を使えばもう少し速く処理してくれるのではないかと、淡い期待を持ちつつ実験してみたのだけど、そんなことはなかった。おそらく、OpenGL も DirectX も、どちらも遅い。単にスペックがショボいGPUでした、というオチだなと…。

でもまあ、どうにかして DircetX を使わないと描画が速くならないという状態ではなさそうなので、今後は安心して(?) hsp3dish を選択できそう。OpenGL と DircetX のどちらが使われているかなんて一切気にしなくていい。どうせサブPC上で動かしたらどちらも遅いから…。トホホ。

しかし、困った。この状態で高速化するにはどうすればいいのだろう。

描画面積を減らしていけば目に見えてFPSが改善するのだろうか。だとしたら、やはり小さな仮想画面を作っておいて、そこに全部描画してから最後にデスクトップサイズに拡大描画、というやり方が有効だろうけど…。hsp3dish でそんなことはできるのだろうか。必ず、最初に生成したウインドウに描画しないといけない、仮想画面に描画なんて無理、みたいな制限があったりしないか…？

その前に、hsp3dish でスクリーンセーバが作れるのかどうか実験してみないと…。

スクリーンセーバにできるかどうかは、今回重要。最終的にスクリーンセーバにしてみたいから、あえてわざわざ HSP というアレなソレを選んでいるわけで…。

スクリーンセーバにしなくていいなら、言語仕様が至極真っ当な、Love2D (Lua)、DXRuby (Ruby)、PyGame (Python)、Processing 等を使ってデモプログラムを書いたほうが、はるかに楽だし分かりやすいよなと…。

AMD Radeon R3 ってどの程度の性能のGPUなんだろう。ベンチマークの類を調べてみた。

何か比較対象があったほうが分かりやすいだろう…。今も売ってる増設ビデオカードの中で比較的低価格なものとなると…。NVIDIA GT 710、GT 1030 あたりと比べてみればいいのかな。

_UserBenchmark: AMD Radeon R3 Graphics vs Nvidia GeForce GT 710
_Radeon R3 Graphics IGP (APU A6-6200) vs GeForce GT 710

_UserBenchmark: AMD Radeon R3 Graphics vs Nvidia GT 1030
_GeForce GT 1030 vs Radeon R3 Graphics IGP (APU A6-6200)

絶句。Radeon R3 ってこんなに性能低いのか…。GT 710 の 1/2 - 1/3、GT 1030 の 1/6 の性能だろうか。増設ビデオカードって、このランクでも結構凄いんだな…。

でも、Intel の内蔵GPUと比べたらどうだろう。例えば Core i5-2500 に入ってる Intel HD 2000 あたりと比べたら…。

_UserBenchmark: AMD Radeon R3 Graphics vs Intel HD 2000 (Desktop 1.1 GHz)
_HD Graphics 2000 (Sandy Bridge GT1) vs Radeon R3 Graphics IGP (APU A6-6200)

さらに絶句。昔の Intel製オンボードビデオと比べたら、まだ Radeon R3 のほうがマシだったとは…。と言っても 1.5 - 2.0倍ぐらいだけど。

ちなみに、Intel Skylake世代(6xxx番台) に内蔵されてる Intel HD 510 あたりと比べたら、さすがに Intel HD 510 のほうが Radeon R3 より 1.5倍ぐらい性能が良かった。Intel製の内蔵GPUは、世代が変わるたびにグングン性能を上げていたんだなと。

_UserBenchmark: AMD Radeon R3 Graphics vs Intel HD 510 (Desktop Skylake)
_HD Graphics 510 (Skylake GT1) vs Radeon R3 Graphics IGP (APU A6-6200)

何にせよ、オンボードビデオのPC上でも動かすことを考えたら、描画に関して贅沢な作りは一切できない気がする。1920x1080なら10FPS前後で動くだけでも「スゴイね！」という話なのかも…。

Radeon R3 の遅さにガックリきているけれど、Windows10のサポートが終了して、Windows11だけになったら、動かせるCPUの最低ランクが Intel の第8世代以上になるはずで、内蔵GPUもそのランクが最低ランクになるだろうから、状況がガラリと変わるのではないかと思えてきた。

Windows11が動かせる最低ランクのCPU、最低ランクのGPUって、どのあたりになるんだろうか…？ そこが分かれば、どの程度の描画をしてもいいのか大体把握できるのでは。

ググっても分らなかったので、試しにAIさん(Bing Chat)に尋ねてみたら「Celeron J4005はどうでしょう」と言ってきた。調べたところ、たしかに Windows11 の対応CPUに入ってる。内蔵GPUは Intel UHD 600。ベンチマーク結果を確認したところ…。

_UserBenchmark: AMD Radeon R3 Graphics vs Intel UHD 600

どんぐりの背比べではあるけれど、Radeon R3 のほうが、まだマシだった…。Windows11 になったからと言ってGPUの最低スペックまで劇的に上がるわけではない、ということだな…。やっぱり贅沢な描画は無理っぽい。

スマホを使っていると、しみじみ思ってしまうのだけど。スマホと呼ばれるパーソナルコンピュータに、「カメラ」と「マイク」という「目」と「耳」がついたことで、やれることが一気に増えたよなと…。

自分はスマホよりPCが好きな人種なのだけど。なんだかちょっと悔しさを感じる。もし、PCにも、最初からカメラとマイクがついていたら、スマホでやれるアレコレは、まず最初にPC上で実現できていたはずなのに、と…。本当ならできていたはずのことが、特定の入力デバイスが標準ではついてなかったことで、なかなかできないと思われていたのが、なんだか悔しい。スマホという別種のコンピュータに全部持っていかれてしまった。 *1

キーボードとマウスと言う入力デバイス“しか”ついてなかったことが、何十年もPCの足枷になっていたのだろうなと。パーソナルコンピュータって、本当はもっと色んな事ができる子だった。でも、自分達はそれが分からなかった。カメラとマイクがオプション扱いだったという、ただそれだけのことで…。その製品ジャンルに、標準状態で何の入力デバイスをつけておくのか。そのことが、ここまで重要だったとは。製品ジャンルの命運を分けてしまうとは。

そう考えると、今後、また違った何かしらの入力デバイスが、スマホに、あるいはPCにつくのが当たり前になった時、更にもう一段、やれることが増えるのかもしれない。その入力デバイスが一体何なのかは、自分は未来人じゃないからイメージが湧かないのだけど。

数十年後、「なんであの頃のコンピュータにコレをつけてなかったのかねえ。こんなに便利になるのに。誰も気づいてなかったの？ コレってあの頃にはもうあったよね？」と、その時代の人達は首を捻っているのかもしれないよなと…。

「薬屋〜」を見ていて、ヒロインが少女キャラな点がちょっと気になったりもした。と言うのも、チャングムアニメ版は幼女がヒロインだったので…。幼女ヒロインよりは少女ヒロインのほうがまだ見れる感じがするな、みたいなことを考え始めてしまって…。

コレ、お姉さんキャラではウケが悪いんだろうか…？ いっそおばさんキャラ、お婆さんキャラではどうか…。お婆さんが名探偵として活躍する作品も世の中にはあった気もするし、ヒロインをそういう年齢設定にするだけでも、右も左も美少女キャラだらけの日本国内に限定すれば、他作品との差別化ができたりしないか。

などと書いたところで「ハウルの動く城」がソレじゃん、と今頃思い出したりもして。

そう考えると、御歳を召した宮崎駿監督のほうが、頭が柔らかいはずの若い作り手達よりも、アニメにおける新規性をはるかに多く提示してきた面がありそうだなと…。いや、ジブリというブランドが確立したからこそ冒険できる面もあるのかな。若い頃の宮崎駿監督が似たような企画を出しても十中八九通らなかっただろうし…。

「薬屋〜」を見ていたら「スカート」という単語が出てきて、そこがなんだか気になった。

中国/韓国っぽい世界観からして外来語(?)が使われるのは不自然な感じもしたのだけど、おそらく件の台詞は、読者視聴者の理解のしやすさを考慮して、あえてわざわざ使った可能性が高そうだよなと…。ツッコミを入れるヤツは絶対に居るだろうけど、どう考えてもこのほうが瞬時に話が分かるやろ、ココは分かりやすさを優先じゃい、みたいな。

このあたり、聞いた瞬間に視聴者が「？」になってしまう、考証面で正しい単語/用語を披露するのは、娯楽コンテンツとして本当に正しいことなのでしょうか、という問題があるよなと…。

そこで生活している登場人物達にとっては常識であっても、見ているこちら側には異界の文化や用語なわけで。何の説明もなくポンと出てきても見ている側は「？」としかならない。そんなところで引っ掛かりを作ってみたところで意味はあるのか。とは言え、こちらとは違う世界と感じさせる「香りづけ」は大なり小なり必要でもあろうし。結局はバランス感覚の話になるのかもしれないけれど。

「フォース」は「フォース」で本当にいいのか？ 「理力」のほうがまだ通じませんか？ いっそ「超能力」と言っちゃったらダメ？ さすがにそこまでやっちゃったら色々と台無しですか？ 「ジェダイ忍法」は…もちろんダメですよね。そりゃそうだ。みたいな。

昨今、中国で作られた、仙人っぽいキャラが出てくるアニメが放送されていたりするけれど。あちらの人達、あの手のジャンルでは常識であろう専門用語(?)がポンポン出てきて、自分などは設定すら把握できずに困ってるわけで…。「もう中国のアニメは見なくていい。どうせ基本設定すら分からんし、アイツラが一体何の話をしているのかさっぱり分らん」と切って捨ててもいいかもな、とすら思い始めているぐらいで…。アレはなんとかしたほうがいいのでは。あんなに豪勢な映像を作っておいて、実にもったいない…。

でも、このあたり、おそらくガンダムシリーズを初めて見た人も同じ感覚になるのかもしれんと不安になったりもする。そりゃおじさんしか見ないコンテンツになっていくわな、と…。

ガンダムに限った話でもない。日本の学園を舞台にしたアニメは、海外の人達は理解できるのだろうか。「生徒会長」って通じるのか？ 「部活動」は分かるのか？ どこまで通じるものなんだろう。

もっとも、ある程度はテクニックで解決できるのではないか、とも思うのだよな…。「スカート」と意訳して言わせてもいいし、何か分からない単語を口にした直後にヒロインがスカートを隠す動作を見せて「ああ、スカートのことか」と察してもらってもいい。件のアニメでは両方やってて至れり尽くせりだったけど…。伝わりさえすれば、なんでもOk。どれも正解。花丸二重丸。

ただ、「これ、お客さん分かるかな？」「これ、海外の人は理解できるんだろうか？」と疑問を持ちながら作らないと、テクニックが駆使されることもないわけで。

昔何かの番組で見たけれど。ピクサーに在籍していた頃のジョン・ラセター監督が、若いスタッフに「これ、お客さんは分かるかな？」と“笑顔”で質問していた光景を思い出したりもする。世界中で通用するヒット作を生み出す人達は、常に、その問いを、あらゆるカットにぶつけながら作ってるのだなー、大変だなー、でも、まるでなんでもないことのように笑って優しく後進達に尋ねる風を装って諭していくのだなー、テクニシャンだなー、と感心したわけで…。 *1

閑話休題。まあ、こういうのって、細かいところだけど結構難しい問題だよなと…。そんなことを、「スカート」という単語一つから思ってしまいました。とメモ。思考メモです。

TIC-80 0.90 以降には、BDR() という関数が用意されてる。

_BDR - nesbox/TIC-80 Wiki

この関数は、ウインドウの横1ライン分を描画する直前に呼ばれる関数。描画しようとしているy座標 + 4 の値が入った状態で呼ばれる。

要するに、昔のゲーム機で言えば、水平帰線期間(HBlank)割込みに相当する。この BDR() の中で、Screen Offset値を書き換えてやれば、1ライン毎に表示位置を変えられるから、ラスタースクロールもできる。

ちなみに、TIC-80 0.90 より前の版(0.70.6 や 0.80.1344)では、BDR() ではなくて SCN() という関数名だった。

_SCN - nesbox/TIC-80 Wiki

また、SCN() に渡される値と、BDR() に渡される値も、若干違っている。

• SCN(n) : n = 描画するラインのy座標。0 - 135 の値が入る。
• BDR(m) : m = 描画するラインのy座標 + 4。0 - 143 の値が入る。0 - 3 は TOP BORDER。140 - 143 は BOTTOM BORDER になっている。

まずは、BDR() の中で、Screen Offset にsin値やcos値を書き込んでみる。


_raster1.zip (raster1.tic, tiles3.png, map3.map)

ローカル環境で動かしたい場合は、以下で実行できる。

tic80.exe raster1.tic

画像(tiles3.png)やマップデータ(map3.map)を利用したい時は、TIC-80 のコンソール上からインポートできる。

tic80.exe --fs=.

import tiles tiles3.png
import map map3.map

ソースは以下。

_raster1.lua

t=0
x=96
y=24

function TIC()
 cls(13)
 map(0,0)
 local col=0
 local scale=3
 spr(1+t%60//30*2,x,y,col,scale,0,0,2,2)
 col=12
 print("HELLO WORLD!",84,84,col)
 t=t+1
end

--function SCN(row)
function BDR(row)
 local rx,ry
 rx=8*math.cos(math.rad(3*t+4*row))
 ry=6*math.sin(math.rad(2*t+4*row))
 poke(0x3FF9,rx)
 poke(0x3FF9+1,ry)
end

• function BDR(row) - end の中が、ラスタースクロール処理。
• poke(0x3FF9,rx) で、Screen Offset の x値を書き換え。
• poke(0x3FF9+1,ry) で、Screen Offset の y値を書き換え。今気づいたけど、poke(0x3FFA,ry) と書いたほうが良かったかも…。
• Lua で sin,cos を使う時は、math.sin(), math.cos() を使う。
• sin, cos関数に渡される値はラジアン単位。math.rad() を使って、度からラジアンに変換できる。

前述のラスタースクロール処理を行うと、ウインドウ内の全体の見た目が変わってしまう。背景はラスタースクロールさせるけど、手前のスプライト相当はラスタースクロールをかけないようにしたい。

そんな時は OVR() 関数を使う。OVR()関数は、BDR() が描画処理を終えた後、一番最後に呼ばれるので、その中で描画処理をすれば、BDR() の処理が影響しない状態の描画ができる。

_OVR - nesbox/TIC-80 Wiki


_raster2.zip (raster2.tic)

_raster2.lua

t=0
x=96
y=24

function TIC()
 local spd=2
 if btn(0) then y=y-spd end
 if btn(1) then y=y+spd end
 if btn(2) then x=x-spd end
 if btn(3) then x=x+spd end

 cls(13)
 map(0,0)
 t=t+1
end

--function SCN(row)
function BDR(row)
 local rx,ry
 local sx,sy=x/10,y/5
 rx=sx*math.cos(math.rad(3*t+4*row))
 ry=sy*math.sin(math.rad(2*t+4*row))
 poke(0x3FF9,rx) -- Screen Offset x
 poke(0x3FFA,ry) -- Screen Offset y
end

function OVR()
 local col=0
 local scale=2
 spr(257+t%60//30*2,
     x,y,col,scale,0,0,2,2)
 col=12
 print("HELLO WORLD!",84,84,col)
end

OVR() の中で、スプライト(コンピュータみたいなキャラクタ)の描画と、文字描画("HELLO WORLD!")をしているので、背景はラスタースクロールしているけれど、スプライトと文字はラスタースクロールしていない状態になっている。

注意点。TIC-80 1.0以降では、OVR() の中で描画指定をすると、パレットの0番色が必ず透明色として扱われてしまう。

上記の例では、0番色を透明色、それ以外を不透明色扱いにしてドット絵を描いてあるので、問題無さそうに見えてるけれど。TIC-80 のデフォルトのパレットデータでは、0番色 = 黒色なので、黒色を使ったドット絵を描いて OVR() の中で描画してしまうと、黒い部分が透明になってしまう。

以下のやり取りによると、任意の色番号を透明色として扱うように指定することも可能らしいけど、やり方がよく分からなかった…。何にせよ、その場合もどこか1色は透明になってしまうので、OVR() の中で描画する何かしらは15色しか使えないと思っておいたほうが良さそう。

_everything drawn in OVR with color 0 is transparent - Issue #1897 - nesbox/TIC-80

そこに水面があるような見た目を、ラスタースクロールを使って実現してみる。


_raster3.zip (raster3.tic)

_raster3.lua

t=0
x=64
y=32
sy=0

function TIC()
 local spd=2
 if btn(0) then y=y-spd end
 if btn(1) then y=y+spd end
 if btn(2) then x=x-spd end
 if btn(3) then x=x+spd end

 cls(0)
 map(0,0)
 local col=0
 local scale=2
 spr(1+t%60//30*2,x,y,col,scale,0,0,2,2)
 col=12
 print("HELLO WORLD!",84,28,col)
 t=t+1
 sy=math.floor((136*0.7)+16*math.sin(math.rad(t)))

 -- reset palette
 sync(1<<5)
end

--function SCN(row)
function BDR(row)
 local rx,ry=0,0
 
 if row==sy then
  -- palette change
  local PAL_ADDR=0x3FC0
  for i=PAL_ADDR,PAL_ADDR+16*3-1 do
   poke(i,peek(i)*0.5)
  end
 end
 
 if row<sy then
  rx=0
  ry=0
 else
  local dy=row-sy
  rx=1.5*math.cos(math.rad(4*t+55*dy))
  -- ry=-dy*2 -- TIC-80 0.70.6
  ry=dy*2 -- TIC-80 1.0.2164
 end
 
 local SCROFSX=0x3FF9
 local SCROFSY=0x3FFA
 poke(SCROFSX,rx)
 poke(SCROFSY,ry)
end

まず、BDR() に渡された値(y座標 + 4)と、値が上下に揺れるグローバル変数 sy を比較して、もし同じ値なら、そのタイミングでパレットデータを少し暗めな値に書き換えている。これで、水面相当がちょっと暗い感じの色になってくれる。

ただ、このままだと次のフレームを描画する時に、暗くなったパレットデータを使って描画してしまうので、TIC() の中の最後のあたりで sync(1<<5) を呼ぶことでパレットデータを初期化してる。

BDR() の中では、グローバル変数 sy より下を描画するときだけ、ラスタースクロールをかけている。 Screen Offset のy値を書き換えて、縦方向の表示位置を変化することで、上下反転した見た目にしている。

ただ…。TIC-80 0.70.6 / 0.80.1344 / 0.90.1723 と、TIC-80 1.0.2164 では、Screen Offset値の正負が逆なようで…。以前の版で書き込んでいた値の正負を反転して利用しないと、期待していた見た目にはならなかった。このあたりは別記事でまとめておく。

t=0
x,y=96,24

function TIC()
 cls(13)
 map(0,0)
 spr(1+t%60//30*2,x,y,0,3,0,0,2,2)
 print("HELLO WORLD!",84,84,12)
 t=t+1
end

function BDR(v)
 -- TIC-80 0.90 later
 local y=v-4
 if y<0 or y>135 then return end
 my_bdr(y)
end

function SCN(v)
 -- TIC-80 0.70.6
 my_bdr(v)
end

function my_bdr(y)
 poke(0x3FF9,y) -- Screen offset x
 poke(0x3FFA,0) -- Screen offset y
end

縦方向も試してみた。

_raster5.zip (raster5.tic)

_raster5.lua

t=0
x,y=96,24

function TIC()
 cls(13)
 map(0,0)
 spr(1+t%60//30*2,x,y,0,3,0,0,2,2)
 print("HELLO WORLD!",84,84,12)
 t=t+1
end

function BDR(v)
 -- TIC-80 0.90 later
 local y=v-4
 if y<0 or y>135 then return end
 my_bdr(y)
end

function SCN(v)
 -- TIC-80 0.70.6
 my_bdr(v)
end

function my_bdr(y)
 poke(0x3FF9,0)     -- screen offset x
 poke(0x3FFA,y*0.5) -- screen offset y
end

以下は、TIC-80 1.0.2164。



以下は、TIC-80 0.70.6、0.90.1723。



これも、ずれる方向が逆になっている。

Godot Enigneのエディタ画面にエクスプローラ等から pngファイルをドラッグアンドドロップしてインポートする。



res://resources/ 以下に画像を置いた。



bg02a.pngを選択した状態でインポートタブをクリック。Filter のチェックを外して無効にして「再インポート」。2Dゲームを作る時は、Filter のチェックを外しておいたほうが良い。


あ。しまった。このスクリーンショット、「再インポート」に丸をつけるのを忘れてるなあ…。「再インポート」をクリックしないと反映されないので注意。

Mainノードの下に Spriteノードを追加。このSpriteノードにBG画像の表示を担当してもらう。



分かりやすくするために、「Bg」にリネーム。



Playerノードの上にドラッグアンドドロップして移動する。これでプレイヤーの後ろに表示される状態になる。

Bgノード(Sprite)のテクスチャを指定。Textureプロパティの「空」の部分をクリック。「読込み」を選択。



res://resources/ の中にある bg02a.png を選択して「開く」。



BG画像が表示された。

BG画像の表示位置がずれてるので調整する。「Offset」の「Centered」のチェックを外すと、基準点が左上になってBG画像がゲーム画面を覆うような位置に表示される。


Centered にチェックを入れると基準点が画像の中央になる模様。チェックを外すと左上になる。基準点の位置をずらしたい時は Offset x,y の値を調整する。

F6キーを押して動作確認。


背景画像(BG画像)が表示された。

これはこれでいいのだけど、せっかくの2Dゲームだから、タイルマップを使ってBG表示してみたい。次回は TileMap を使って同じことをしてみる。

Godot Enigneのエディタ画面に、エクスプローラ等から bgchip.png をドラッグアンドドロップしてインポート。



res://resources/ 以下に bgchip.png を移動した。



bgchip.pngを選択した状態でインポートタブをクリック。Filterのチェックを外して「再インポート」。

シーンを新規作成。シーン → 新規シーン。



「その他のノード」を選択。



「tile」と打ち込んで絞り込み検索。TileMapノードを選択して「作成」。



TileMapノードが追加された。

タイルマップ(TileMap)を使うには、タイルセット(TileSet)が必要になる。Tile Setプロパティの横の「空」をクリック。「新規 TileSet」を選択。



更に、TileSet と表示されている部分をクリック。



タイルセットを設定していくためのウインドウが、Godot Engine エディタ画面の下のほうに表示された。

タイルセットの設定をしていく。bgchip.png をドラッグアンドドロップして、タイルセットの画像リスト(?)の中に入れる。



タイルセットが使う画像として、bgchip.png を登録できた。今回使う画像は各タイルがビッシリと詰まっているので、右上のほうにある「新しいアトラス」をクリック。



どのタイルからどのタイルまでを使うのかを指定するけれど、グリッドにスナップさせながら作業したほうが楽なので、「スナップとグリッドの表示を有効にする」ボタンをクリック。有効になると青色で表示される。



左上から右下までドラッグして、使う範囲を指定する。



もし、タイルサイズが合わない時は、インスペクタウインドウ内の Step x,y を設定するといいかもしれない。今回は最初から (32, 32) が入ってた。

TileMapノードをクリックして選択すると、キャンバス上でタイルを並べていくモードになる。右のほうに使えるタイルの一覧が表示されているので、使いたいタイルをクリックしてからキャンバス上で並べていく。もしかすると、Cell → Size x,y を調整しないといけないかもしれない。今回は1タイルが 32 x 32ドットなので、Size x,y も (32, 32) にした。



上のほうに、鉛筆、バケツツール(塗り潰し)、セルを取得、選択範囲作成、のツールが並んでいるので、その都度切り替えつつタイルを並べていく。


ちなみに、鉛筆ツールは左クリックでタイル配置、右クリックでタイル消去になっている。また、Shift+左クリックで線を引いたり、Ctrl + Shift + 左クリックで長方形塗り潰しもできる。

それらしく配置した。

TileMapノードを BgTileMap にリネーム。



シーン → 名前を付けてシーンを保存。res://assets/ 以下に BgTileMap.tscn として保存する。

メインシーンに組み込む。Main.tscn を開いて、BgTileMap.tscn を子ノードにして Playerノードの上に位置するように配置。

F6キーを押して動作確認。


それらしい表示になった。

次回は…。スタートボタンをキーボード操作で押せるようにしたり、ゲームウインドウを最大化した際に表示も追随するように設定する予定。

ゲームを実行するとスタートボタンが表示されるけど、一々マウスクリックして先に進むのが面倒臭い。キーボード操作で押せるようにしたい。

HUDシーン(Hud.tscn)を開いて、StartButtonノードを選択。



Shortcutプロパティの右の「空」をクリック。「新規ShortCut」を選択。



「ShortCut」をクリックして、その下の「Shortcut」の「空」をクリック。「新規InputEventAction」を選択。



「InputEventAction」をクリックして、その下の「Action」に「ui_accept」と入力。


「ui_accept」には、プロジェクト設定でいくつかのキーが ―― デフォルトではEnterキーやSpaceキーが割り当てられてる。

これで、ゲーム実行直後、スタートボタンが表示されている状態で、EnterキーやSpaceキーを叩けば先に進むことができるようになった。

現状では、ゲームウインドウの最大化ボタンをクリックすると以下のような妙な表示になってしまう。


最大化した時はそれらしく表示してほしい。プロジェクト設定の Stretch設定を変更すれば対応できる。

プロジェクト設定を開く。上のほうのメニューから、プロジェクト → プロジェクト設定。Dispaly → Window → Stretch と辿り、Mode に viewport、Aspect に keep を指定して「閉じる」。



これで、最大化時に表示が追随してくれる状態になった。



次回は、林檎を取った時に「+10」みたいなエフェクト？を表示させてみたい。

/etc/apt/sources.list
/etc/apt/sources.list.d/raspi.list

sudo apt update
sudo apt dist-upgrade -y

sudo apt purge ca-certificates-java

bluej (4.2.1)
greenfoot (3.6.0)
greenfoot-unbundled (3.6.0)
openjdk-11-jdk:armhf (11.0.5+10-1~deb10u1)
openjdk-11-jre:armhf (11.0.5+10-1~deb10u1)
openjdk-11-jdk-headless:armhf (11.0.5+10-1~deb10u1)
openjdk-11-jre-headless:armhf (11.0.5+10-1~deb10u1)
ca-certificates-java (20190405)

sudo apt update
sudo apt autoremove
sudo apt autoclean
sudo apt purge timidity lxmusic gnome-disk-utility deluge-gtk evince wicd wicd-gtk clipit usermode gucharmap gnome-system-tools pavucontrol

sudo apt install neofetch
neofetch

メインメニュー > Appearance Settings > Defaults タブ

bluejって何だろうとググってみたら、Java開発用の何からしい。一応入れておいたほうがいいのだろうか。

しかし、インストールしようとしてもやはりエラーが出る…。

sudo apt install bluej

ググってみても解決策が見つからない…。

OSをクリーンインストールしないとダメかな…。

TIC-80 はブラウザ上でも動作するので試してみたけど…。

一応動くことは動いたものの、かなり重い。画面の更新がガクガク状態で、60FPSには程遠い。

まあ、昔の Intel Atom だから、コレは仕方ないだろう…。

何にせよ、「TIC-80は非力なPCでもそれなりに動くよ」とは言えない作りっぽいなと。

以下の記事が参考になった。ありがたや。

_Love2D:ゲームエンジンその4 - Qiita

こんな感じの結果に。

使用画像は以下。License : CC0 ってことで。

_bg_1280x720.png
_spaceship_001_64x64.png

ソースは以下。

_main.lua

-- sprite move example

function love.load()
  -- init
  
  -- get window width and height
  scrw = love.graphics.getWidth()
  scrh = love.graphics.getHeight()
  
  -- load image
  bgimg = love.graphics.newImage("bg_1280x720.png")
  playerimg = love.graphics.newImage("spaceship_001_64x64.png")
  
  -- player work
  player = {}
  player.x = scrw / 2
  player.y = scrh / 2
  player.speed = 300
end

function love.update(dt)
  -- update
  
  -- key check
  if love.keyboard.isDown("left") then
    player.x = player.x - player.speed * dt
  elseif love.keyboard.isDown("right") then
    player.x = player.x + player.speed * dt
  end
  if love.keyboard.isDown("up") then
    player.y = player.y - player.speed * dt
  elseif love.keyboard.isDown("down") then
    player.y = player.y + player.speed * dt
  end
end

function love.draw()
  -- draw BG
  love.graphics.setColor(255, 255, 255, 255)
  love.graphics.draw(bgimg, 0, 0)
  -- love.graphics.rectangle("fill", 0, 465, scrw, 150)
  love.graphics.setColor(255, 255, 255, 255)
  
  -- draw player
  ofsx = playerimg:getWidth() / 2
  ofsy = playerimg:getHeight() / 2
  love.graphics.draw(playerimg, player.x - ofsx, player.y - ofsy)
  
  love.graphics.print("FPS: "..tostring(love.timer.getFPS()), 10, 10)
end

function love.keypressed(key, isrepeat)
  -- ESC to exit
  if key == "escape" then
    love.event.quit()
  end
end

_conf.lua

function love.conf(t)
  t.window.width = 1280
  t.window.height = 720
  t.window.title = "Move Sprite Example"
  t.window.fullscreen = false
  -- t.window.fullscreentype = "exclusive"
  t.window.vsync = true
end

実行方法は、何か適当な名前でフォルダを作成して、上記の画像やソースを全部入れて…。以下で実行。

love フォルダ名

conf.lua というファイルを作って中に色々書いておくと、ウインドウサイズ、ウインドウタイトル、フルスクリーン表示等が指定できる。love.conf(t) という関数を作って…。

• t.window.width で、ウインドウ横幅を、t.window.height で、ウインドウ縦幅を指定。
• t.window.title で、ウインドウタイトルを指定。
• t.window.fullscreen で、フルスクリーン表示にするかしないか。
• t.window.fullscreentype で、フルスクリーン表示時の種類を指定。
• t.window.vsync で、vsync を見る、のかな。

main.lua に、処理を書く。

• 関数 love.load() に、初期化処理を書く。
• 関数 love.update(dt) に、更新処理を書く。dt には、前回の更新処理からの時間が秒単位で入っている、らしい。
• 関数 love.draw() に、描画処理を書く。
• 関数 love.keypressed(key, isrepeat) を書くと、キーが押されるたびにその関数が呼ばれる。

• 画像の読み込み : love.graphics.newImage("画像ファイル名")
• キーの押し下げ判定 : love.keyboard.isDown("キー種類")
• 画像の描画 : love.graphics.draw(画像が入ってる変数, 描画位置x, 描画位置y)
• 文字列の描画 : love.graphics.print("文字列", 描画位置x, 描画位置y)
• ウインドウサイズの取得 : love.graphics.getWidth()、love.graphics.getHeight()
• 画像サイズの取得 : 画像の入った変数:getWitdh()、:getHeight()
• FPSの取得 : love.timer.getFPS()

love.graphics.setColor(R, G, B, A) は…。それ以後に描画するアレコレの色を変化させることができるらしい。

love.timer.getFPS() でFPSが取得できるらしいのだけど、なんだかスゴイ値になってる…。何故。

逆の方向ではどうだろう。

例えば、ウルトラマン。彼等は人間以上の科学技術を持ってるだろうし、人間以上の知能だって持ってるだろうと自分達は思い込んでるけど。あれだけ個体が居るのだから、中にはとんでもない落ちこぼれが居てもおかしくはないだろう…。

銀色の巨人が現れた！ さあ、怪獣を倒してくれるはず…と思ったら怪獣そっちのけで高層ビルに登り出して実に楽し気に「ウッホウッホ！」と騒ぎ始めるウルトラマン。ってソレ見た目が違うだけのキングコングじゃん。新規性が無いな…。

光の国ってそのへんどうなってるんだろう。生まれてきた個体が「あっ。これは…」てな状態だった場合、何が行われるのだろう…。それはそれでなんだか怖い。

考えてみたら、ウルトラマンって妙なヤツだな…。「シュワ！」「ヘアッ！」「ダアッ！」しか喋らないし。頭めちゃくちゃ良さそうなのに。怪しい…。

アイツら何故か、人間サイズの時はフツーに喋るイメージが。「私は命を2つ持ってきた」とかフツーに言いそう。そもそも人間に化けてるときは人語を話すし。でも、巨大化すると「ダアッ！」。なんだか怪しい…。

と思ったけど、最近のウルトラマンはそうでもないな…。ゼロとか結構ベラベラ喋ってる印象。あの目つきの悪い黒いヤツも、空にでっかい自撮り画像をプロジェクションしながら人類に向かってベラベラ喋りそうだし。

しかし、「何故ウルトラマンは巨大化すると喋らないのか」てなあたりは、妄想すると妙な設定が出てきそうではある…。

• テレパシーで意思伝達することが当たり前になったほどに進化した存在だから、音声伝達なんてそもそも不慣れ。人間が尾骨を自らの意思で動かすぐらいに面倒臭い。
• 巨大化すると自分のエネルギーの配分が色々と大変なので、真っ先に声の発生部位はリソースが節約されちゃう。「シュワ！」も、当人的には「お疲れ様でした！」と喋ってるつもりだったり。
• 人類に対するイメージ戦略。プロデュースは大事。
• 発展途上の惑星住民に過剰な科学技術を与えてはならない。そのためには極力接触を避けねばならない。会話するなんてとんでもない。と法律で決まってるから喋りたくても喋れない。

そのあたりを真面目に妄想していくと…。

• 声を出す文化がないなら、ウルトラ一族は歌という概念を失ってる可能性が。「歌はいいねえ。リリンの生み出した文化の極みだよ」とか言い出しそう。
• 巨大化するとオツムまで弱くなってる可能性が。ヤバイ。体のどこらへんにエネルギーを割り振ってるのか不安が残る。
• 光の国には名の知られた名プロデューサーが居るのかも。たぶん太ってる。イメージ的には。
• 科学技術をポンポン人類に与えちゃう妙な思想を持った個体が登場して面倒臭い事態に。人類は波動エンジンを手に入れた！ 的展開も。

まあ、色々妄想できそうな。

QPushButton に画像を割り当てて表示したい。

    btn_pixmap = QPixmap(24, 24)
    btn_pixmap.fill(QColor(r, g, b))

    btn.setIcon(QIcon(btn_pixmap))
    btn.setIconSize(btn_pixmap.rect().size())

    btn.update()

setIcon() で QIcon(QPixmap) を渡してやれば画像を設定できるようで。一応その次に setIconSize() を呼んでアイコンサイズも設定してるけど、必要なのかどうか…。

_user interface - Python QPushButton setIcon: put icon on button - Stack Overflow
_QPushButtonクラス - yu00’s blog

色を選択したい。

    color = QColorDialog.getColor(Qt.green, self)
    if color.isValid():
        r = color.red()
        g = color.green()
        b = color.blue()
        self.set_rgb((r, g, b))

QColorDialog.getColor(初期色, 親) を呼べば、色選択だかカラーピッカーだか、そういう感じの例のダイアログが表示されるらしい。返り値は QColor。QColor.isValid() を呼んで False だったらキャンセルされたと分かる。

_QColorDialog - PySide v1.0.7 documentation
_QColor - PySide v1.0.7 documentation
_Pyside を使ったカラーピッカー（色選択ツール）のサンプル - Qiita
_Dialogs in PySide

思考メモ。

サイコパスの1期は、本広克行総監督＋塩谷監督＋虚淵シリーズ構成＋深見脚本。

2期は、塩谷監督＋冲方丁シリーズ構成＋熊谷脚本。

布陣が変わったことで、作品の方向も変わったのかなと感じているのだけど、どうなんだろう。

アニメで管理社会モノ？ ディストピアモノ？ と言うと、自分などは「銀河鉄道999」「地球へ…」あたりを思い出しちゃうのだけど。その手の管理社会は、主人公が反逆して倒すべき対象でしかなく。そして、倒すべき対象に見せるためには、強大な悪として描く必要があり、故に、管理社会に対して、非合理性、凶暴性、残虐性、幼稚性、異常性、その他を内包させて「コレは倒さないといかんよな」と観客・視聴者に思わせるのが常で。

しかし、その社会の有り様を見て、観客・視聴者は疑問を持つわけで。「どうしてこんなアホ社会が存在してるの？ ありえねえだろ」。ソレが存在することに説得力が無くてシラケちゃう。

で。管理社会云々に限らず、その強大な悪が存在する理由を説明して観客の疑問を補完するために、ラスボスキャラあたりがどうしてこういう状況を作ったのか言い訳を始めたりするのだけど。これがまた、中学生ですらもっとマシなこと考えるだろと思えるほどに、穴だらけ、ツッコミどころだらけの酷いロジックばかりで。いや、ロジックになってないのがほとんどですが。

てなわけで。その手のアニメを見ていると、十中八九、「アニメの脚本書く人って、頭悪い人ばかりなんだなあ…」「建前すら上手に構築できないのか…」と思ってしまうことが多かったのですよ。

ところが、サイコパスの1期は、そこらへんがちょっと違ってた印象で。

現実の日本社会でも、犯罪を未然に防ぐシステムの登場が望まれているわけですが。たとえば、

• ストーカー被害にあった人が警察に駆け込んだら、警察はちゃんと動くべきだ。犯罪を未然に防がないと。
• ネットに犯罪予告が書き込まれたら、たとえそれが冗談の書き込みだとしても、書き込んだヤツを逮捕すべきだ。犯罪を未然に防がないと。
• 大人になってもアニメを見てるヤツは犯罪者予備軍だ。そのうち幼女を殺し始める。近所にそういうヤツが居たら注意深く監視しないといけない。犯罪を未然に防がないと。

等々。この社会は誰しもが、犯罪を未然に防ぎたいと願ってるよなと容易に想像できる。

1期は、そういう希望を叶えるシステムとしてシビュラシステムができました、という世界設定で。しかもオマケで、職業の適性診断までかなり高い精度でやってくれる。便利。快適。安心。一般市民様にとっては、間違いなく夢のようなシステム。まあ、娯楽作品だから当然のごとく、夢と一緒に悪夢もついてきますけど。

そのあたりの作りが、“既存アニメと比べたら”ちゃんとしてたほうなので *1 、常守監視官と言うキャラが ―― システムのカラクリを把握しつつも、その存在の是非の判断で葛藤してしまうキャラとして存在することもできたし、そのことで作品が(多少は)深みを持てた、とも言えるわけで。

しかし、2期はちょっと違うかもなと。シビュラシステムが、只の強大な悪として描写されるだけ。ソレが存在することに対してフォローがされてない感じがして。 *2

個人的には、そういうのはもういいよと。またかよと。頭悪い系の脚本は子供の頃から見せられてるからウンザリ。一工夫欲しいなと。これじゃ常守が只の馬鹿になっちゃう。や、わざと馬鹿に見せるためにやってんのかなとも思いますが。

1期がイクラの軍艦巻なら、2期はイクラの代わりに納豆が乗ってた印象。どっちも丸いツブツブだから同じだろと言われても…。納豆は二日に一度は食べてるからもういいよ。しかも臭うし。ってどんな喩えなんだ。

それにこのままだと、シビュラ倒して万歳三唱して…

• で、続きどうするの？
• 商品としてのシリーズ展開どうすんの？
• 現代風のパトレイバー作るって話じゃなかったの？
• それってつまり、その気になれば延々と続きを作れるタイトルを新規作成することを目的としてたんじゃないの？
• このスタッフ、劇場版パト2でシリーズの息の根止めるつもりだった押井監督にでもなったつもりなの？

ってことになっちゃうし。倒さなければ倒さないで、強大な悪は残り続けるのです、てな結末で視聴者にはストレスしか残らないし。どうすんだコレ、と。

要は、シビュラは存在してないと困るし、存在していても困る。どうしよう困ったなあ、てな絶妙のバランスで描写せんとシリーズにならんだろと思うのですけど。2期はそのあたり、片方に寄せ過ぎてる感じがして。これで大丈夫なのかなー、と。

でも、まだ始まったばかりなので、後になってから「この展開を見せるためにアレをやったのか。構成上手いなあ」「これなら続きも作れますな。やりますなあ」と感心する場面が出てくるかもしれない、などとうっすら期待していたりもするのでした。さて、どういう展開になるのかな。

まあ、2期を作るのって色々大変なんだろうなー、スタッフ違うとノリも違うなー、と思ったという、ただそれだけの話でした。とっぴんぱらりのぷう。

握りやすさを前面に出してアピールしているだけあって、たしかに握り心地はかなりグッド。マウスに手を載せた瞬間、「ふわあ…。な、なにコレ…」てな気分に。手の平に吸い付くようにピッタリフィット、って、なんか女性向け商品のアレのような言い方だけど、そんな新感覚。コレは凄い。素晴らしい。

もちろん、Mサイズがたまたま自分の手のサイズと合ってたから、だと思うけど。サイズが合わない人・変なマウスの持ち方をしてる人は、真逆の印象になりそうな。「ココに指を置け。絶対に置け。それ以外の持ち方は認めん」と強く主張している形状なので、合う人は絶賛するけど、合わない人は酷評しそう。

とりあえず、店頭で触れるなら、触ってみてから買ったほうがいいのかもしれず。自分は博打感覚で買っちゃったけど。

左右ボタンのクリック感は、比較的軽いのではないかと思えたり。A4tech XL-755BK-JP、Logicool VX Nano と押し比べてみたけれど、重さ・硬さの違いが分からなかった。少なくとも、クリックが硬くて嫌気が差した BUFFALO BSMLU06 と比べたら雲泥の差。これなら使えそう。

マウスの親指側にある、2個の拡張ボタンの大きさや位置も、自分にとっては問題無しだった。

_【特集】写真で見る、握り心地を“極めた?”エレコム製マウス 〜「L」と「M」の2サイズ展開 - PC Watch という記事中では、「うっかり押してしまうことがあった」と否定的なレビューがされてるけれど。「…これでどうやってうっかり押せるんだ？ 一体どんな持ち方・動かし方をしてるんだろう？」と疑問を持ってしまったぐらいに、自分の場合はそのへん大丈夫そうな感じ。

もっとも、もしかすると自分の持ち方がおかしい可能性もあるのでアレなのだけど。かぶせ持ち/つまみ持ちのどちらかで、誤操作が増えたりもするのだろうか…？ 自分の持ち方はどっちなのかわからんのだよな…。

各人、マウスの使い方には癖があるのだろうけど。幸いにして自分の場合は、誤操作に繋がる変な癖がついてない or 誤操作を無意識に回避しちゃう変な癖がついてる、ということかも。

カーソルの動きも問題無し。キビキビしてるというか、満足できる速度で動いてるというか。

今まで、スペック値1600dpiのマウスばかり使ってたけど、たぶんそれらに近い分解能なのかなと。パッケージには1600カウントと書いてあるけど…。もしかして自分、dpi と cpi を勘違いしてるのかな。でも、A4tech や BUFFALO は dpi で表記してるな…。表記の単位がよくわからんです…。

もっとも自分、フルHDのディスプレイで作業をしてるから、このぐらいの速度でちょうどいいのかなと。解像度が低いディスプレイで作業してる人は、「動きが速過ぎる！」と文句を言うかもしれず。…そういう時はポインター速度の調整でどうにかならんのですかね？ 反応が遅いものをキビキビ動かすのは難しいけど、反応が速いものをわざとゆっくり動かすのは容易なのでは、と想像するのですけど実際はどうなんだろうか。

ホイール部分は、回しやすいように若干幅広になってるらしくて。たしかに、回すのがツラいという状態ではナサゲ。でも、別に幅広には感じないのだけど…。自分、Logicool VX Nano や M705 を触ったから、特に感じないだけなのかな。

買ってから気付いたけど。これ、チルトホイールじゃなかったのですね…。まあ、チルト機能をつけると複雑な構造になって、ホイールクリックの感触が犠牲になることが多そうだから、無理して実装されるよりは、無理しないでつけないほうが、という気もしたり。

自分にとってはかなり重要な、ホイールクリック(中ボタンクリック)の感触だけど。これは…うーん。予想通り、やっぱり残念な感じ。

まあ、随分昔にホイールクリックの軽いマウスを探してアレコレ手を出してみたマウス群に比べたら、はるかに軽い・まだそこそこマシなほうかなとは思うのだけど。しかしやっぱり、「押し込んでクリック」な印象。「押すとクリック」が欲しいのだけど…。「グニカチッ」じゃなくて「カチッ」が欲しいんだけど…。

これは勝手な想像だけど。たぶんこのあたり、生まれて此の方ホイールクリックなんてしたことない人達・下手するとホイールがボタンになってることすら知らない人達が、「ホイールを回してたらなんか変な動作になった！ なんだこの糞マウス！」等の文句をやたら叫んで、結果、どのメーカも誤クリックしないように深めに作ってしまっているのかな、てな邪推をしたり。どれもこれも「押し込んでクリック」になってるのは、やっぱりおかしいし。意図的にこうしてるとしか思えない。

CGツールその他を使う時は、「押し込んでクリック」だと、かなり不便なんだけどなあ…。まあ、世の中、中ボタン押しで視点を変えたりPANしたりするツールを使ってる人は少数派だろうから、仕方ないのかもしれんけど。

いっそのこと、分解して改造できないものかと思ったけど。ホイールクリックって、ホイール軸でマイクロスイッチを押してたりするから、他のボタンほど、間に何かを挟んで〜等の改造はできない予感も。

細かい不満点では、拡張ボタンの押し分け、というか判断が、指先だけではちょっと難しいかな、と思ったり。

どうして巷のマウスは、ボタンの表面にポッチをつけないんだろう…？

例えばA4techのゲーム向けマウスなどは、表面をツブツブにしたりポッチをつけたり等、似たような大きさのボタンが並んでいても、指先で触れただけでボタン種類がちゃんと分かる工夫をしてあるのだけど。ELECOM、BUFFALO、SANWASUPPLY は…。いや、Logicool や Microsoftもだけど。そのあたり全く気が利かないというか。

これがキーボードなら、どのメーカも「F」「J」「テンキーの5」にポッチをつけるのに、マウスになると途端にそういう工夫が見られなくなるのが不思議。まさかこのあたり、特許でも絡んでるの…？

手元を見ないで使うことが当たり前の入力機器なのだから、触れただけでそれが何のボタンなのか分かったほうがいいだろう、と思うんだけど。デザイナーさんや、デザインにOK出してる偉い人達は、そのあたり気付いてるのだろうか…。今まで一度もそういう工夫をしているマウスを使ったことが無いから気付いてない？ そもそも拡張ボタン付きマウスなんて日常的に使ってないからボタン種類が分かる利便性を知らない？ 何にしても不思議です。

他に気になる問題点というか、不安としては…。耐久性、かなあ…。ELECOMの製品だし…。ELECOMだもんなあ…。

でも、オムロン製スイッチを使ってると謳ってるから、もしかすると意外とそこそこ持って…くれるといいのだけれど。でも、ELECOMだからなあ…。

とりあえず、耐久性については覚悟しつつ、しばらく使ってみようかなと。

エレコムマウスアシスタントをインストールすれば、ボタンへの機能割り当て、マウスジェスチャ等が使えるようになるらしく。

インストールしてみたけど、ArtTipsで実現してる、カーソル下のウインドウをスクロールさせる機能が使えなくなってしまったり。これでは少々不便なので、エレコムマウスアシスタントはアンインストール。

拡張ボタンの割り当ては、 _X-Mouse Button Control でどうにか。

自分の環境は、SetPoint、X-Mouse Button Control、ArtTips と、マウス関係のアレコレが結構常駐してる上に、マウス以外にトラックボールも接続してるので、不具合が起きやすい特殊な環境のかもしれず。なんとなくだけど、SetPoint が一番怪しい気がする…。例えば、フォント管理ソフトの「フォントインストーラーSAKURA」は、SetPoint が常駐してるとフリーズするし。

• LEDクリップライト。D-011 LEDライトA No.2。
• 単3電池4本。電池-55。
• 単3電池4本。電池-113。
• いろいろ収納BOX CD。A-001 ボックス No.01。

LEDクリップライトの蓋を開けてみたら、相変わらずの、ボタン型電池をLED端子で直に挟んでるだけのタイプだった。長時間使うとたぶんLEDが切れる予感。

電池-55と電池-113は、 _ASCII.jp：12時間電池耐久レースはコンビニ＆100円ショップ対決 の記事で評価が高かったようなので試しに購入。

オンライン版。

WinXP には codec が入ってないはず。

ということで iv5setup.exe を探してインストールするために実行したのだけど。途中でHDDにアクセスしっぱなしになる。なんだか Netscape関係のファイルを探してるみたいだ。余計なことを。custom でインストールすれば良かった。

あ。途中で気がついた。昔の日記で書いてたわ。 _DLLは入ってるけど登録されてないだけっぽい。 ヤバイ。新しいDLLを、上書きしてしまったか…？

一応再生はできてるみたいだから、いいか。

海外に居る日本人は海外に居るというだけで外国人にしか見えてないのかも。という電波を受信。

それはさておき。早々に交渉の余地を自ら消滅させる発言をしておきながら、そのことについて自覚してるかどうかも怪しいこの国のトップに交渉能力の完全な欠落を感じたり。いや、最初から交渉するつもりはなく、見殺しにするシナリオは決まっていたと見るべきだろうけど。が、交渉するつもりがないのと、交渉する素振りを見せないのは、全然違う。それすら判ってないのだろう。救出に全力を尽くす？ その言葉と同時に、『条件は飲まない』＝『殺したければ殺せ』と発言してる馬鹿がどこに居る。…居たんだな、コレが。しかも国のトップ。肝心なところで、特に国外に向けてポーズ取らなきゃいけないところで、ポーズの取り方を間違えるんだよ、あの人は。そういう人だよ。 *1 *2

ネットでもなんでもいいから殺害時の映像を流してほしいものだけど＞犯行グループ。そういう映像を直接目にしないと、この国は自分たちが何を選択したか・しているのか自覚できないと思うので。自覚したうえで「それでもこれでいくしかない」と判断するのと、自覚できてないのに「これでいく」と判断するのは、違うわけで。映像、流してくれないかなぁ。 *3

まあ、犠牲になった彼はこの国の人柱？人身御供？になったようなもので。靖国神社とやらで英霊扱いでもしたらどうかと。 *4 「アメリカ様のお望みどおり、私たちは軍を派遣しております。ご覧のとおり、自国民の生命よりも、アメリカ様の意向を最優先で尊重しております。どうかよしなに」と、国としてのポーズを取るために死んでもらったようなもんで。もっとも米にしてみれば、米国民が既に比べようもないぐらい犠牲になってるわけだから、今更アジアの隅っこの島国の人間が1人犠牲になっても「あ、そうなんだ？ へぇ」てなもんだろう。NYっ子のどれだけが日本にも犠牲者が出たと知っているのだろうか。意味ねえ。これでは無駄死にじゃないか。…コレ、隣の将軍様が同じ状況になったら、コレを利用して米に揺さぶりぐらいはかけてたんじゃないか。撤退するつもりは毛頭無くても早々に撤退する素振りだけは見せて、自国民の生命を尊重するお優しい将軍様像を国内に向けて宣伝しつつ、人質奪還の交渉も進めつつ、 *5 米が絶対文句言ってくる＝こちらにしっかり注目するから、そのタイミングを見計らって「やっぱり撤退しないことにしました」「私たちはアメリカの意向を尊重します」と。運良く人質が助かったら、国内に「崇高なる将軍様」をアピールできるし、殺害されたとしても米に対して今以上に自国を印象づけることができる。どっちに転んでも何かしらの利がある。…そういう選択肢だってあったことを考えると、誰もこっち向いてないのに言いつけを馬鹿正直に守って自国民の人命を失って、この国は何か得るもんがあったのかと。 *6 *7

などと偉そうに書いてるけど。こりゃ中二病ですな。

この人、自分の発言が、犯行グループに対して殺害GOサインを出したことを、未だに理解してないのね。すっかり他人事で喋ってる…。たった二言喋らなければ、別の未来があったかもしれないのに。

つーか何度読んでも他人事のコメントだよなぁ。大丈夫か、この人…

_震度1 か。情報が出てくるまで結構時間がかかるのね＞気象庁の地震情報ページ。

あのような混雑状態・デンジャラスな場所で、転落しないよう意識・実行できてしまう人間が大半という状況が、対策を打たずに放置しててもそれほど文句を言われないそもそもの原因なのだろうか。工業製品の製造過程などでも見られるらしいけど、日本人は全般的にDQNシステムを人間各個体の優秀さでもってどうにか運用してしまう（らしい）ので、結果、システムが抱えている問題点を意識することもなく、致命的被害・具体的損害が発生するまで問題はいつまでも放置され続けるのです。嘘。

オイラの住んでるところは田舎なので、ホームが人で埋め尽くされることはほとんどなく、転落事故なんて意識してやらない限りあり得ない感じなのだけど。 *1 おそらく駅のホームってその程度の利用者数を前提に設計されてたのだろうな。それが都市圏ではかなり混雑する状況へと変化して問題が…などと思ったらそのあたりは _既に述べられていた わけで、なるほどたしかに、みたいな。ていうか「コンサルがよく口にする『ゼロベース』」とはなんぞや。… _ふむふむ。 _なるほど。

_「前例を踏襲することに余分なコストがかかるようにしないと、たいていのものは環境が変わってもDQNのまま継続してしまう」 …事を考えると、転落事故が起きる度に鉄道会社が遺族にかなりの金額を払うような法律でも作ればDQNが解消されたりしないかなと。現在どれだけの人が転落事故の被害にあってるかを調査すれば法律施行後も何ら対策を打たない事で鉄道会社が被る経済的損失が算出できるし、具体的な数字さえ出てきてしまえば、対策を打つ事でどれだけ「コスト減」が見込めるか、○年で対策費用の元が取れるか、という話にもなっていきそうな。なんちてぽっくん。