mieki256's diary

xyzzy の basic-mode 関係の設定を、一応バックアップ的にメモ。

;; ----------------------------------------
;; VBScript (basic-mode)
(pushnew '("\\.vbs$" . basic-mode) *auto-mode-alist*)

;; ----------------------------------------
;; basicモードの設定
;; C-. でキーワード補完
;; タブをスペースに

(require "basic-mode")

(add-hook 'ed::*basic-mode-hook*
          #'(lambda ()
              (set-tab-columns 4 (selected-buffer))
              (setq ed::*basic-indent-level* 4)
              (make-local-variable 'indent-tabs-mode)
              (setq indent-tabs-mode nil)
              ))

(define-key *basic-mode-map* #\C-. 'ed::basic-completion)

(pushnew '("\\.bi$" . basic-mode) *auto-mode-alist*)

FreeBASICのソース内に Unicode(utf8n)で日本語文字列を書くと、エディタによっては正常に表示されない。

Editor	Unicode	SJIS	日本語入力	note
IUP_FB_EDITOR	GOOD	GOOD	GOOD	文字コード判別はOS機能に任せてるのでどうしようもないらしい
FbEdit 1.0.7.4	BAD	BAD	BAD	表示も入力も一切できない
WinFBE 3.1.0 x86	BAD	GOOD	BAD	日本語入力できない
FBIde 0.4.6r4	BAD	GOOD	BAD	インライン日本語入力できない
Geany 2.0	GOOD	GOOD	?	インライン入力できるけど変換中の文字が小さくて見辛い
Notepad++ 8.6 32bit	GOOD	GOOD	GOOD	表示も入力も問題無し
Microsoft Visual Studio Code 1.86.0	GOOD	BAD	?	Unicodeなら入力できる

FreeBASIC用を謳っているエディタの中で、Unicodeも表示できるのは IUP_FB_EDITOR ぐらいのようだなと…。

それぞれの入手先は以下。

_Main - IUP_FB_EDITOR
_FbEdit
_PaulSquires/WinFBE: FreeBASIC Editor for Windows
_FBIde - #1 editor for FreeBASIC
_Home | Geany
_Geany Portable (text editor and basic IDE) | PortableApps.com
_Notepad++

FBIde は、コマンドラインオプションでファイル名を渡しても、「language file missing」と警告が表示される。一応ファイルを開いてはいるけど…。

_fb024 Patcher Warning - freebasic.net

FBIde 0.4.6r2 を入手して、FbIdeFix.dll を 0.4.6r2版で置き換えれば、警告が出なくなるらしい。試してみたら、たしかに警告は出なくなった。

実処理部分。オリジナル版と混ざるとアレなので、サブルーチン名は imgput() から imgputt() にしておいた。

_imgputt.bi


imgputt()の使用サンプル。

_imgputt_test.bas

' imgput() sample. RGB = (255, 0, 255) is transparent

#include "imgputt.bi"

#define BPP  32
'#define BPP  16
'#define BPP  8

screenres 512, 288, BPP
Dim As Any Ptr p = ImageCreate(101, 101)
Select Case BPP
Case 8 : Bload "sprite_8bit.bmp", p : color 16, 16 : cls
Case 16 : Bload "sprite_16bit.bmp", p
Case 32 : Bload "sprite_24bit.bmp", p
End Select

Dim As Integer mode = 0  ' 0 Trans, 1 Pset

' Draw
imgputt( p, , 10 + 120 * 0, 10, 0,   mode)
imgputt( p, , 10 + 120 * 1, 10, 90,  mode)
imgputt( p, , 10 + 120 * 2, 10, 180, mode)
imgputt( p, , 10 + 120 * 3, 10, 270, mode)

imgputt( p, , 10 + 120 * 0, 130, TRANSFORM_HFLIP,  mode )
imgputt( p, , 10 + 120 * 1, 130, TRANSFORM_VFLIP,  mode )
imgputt( p, , 10 + 120 * 2, 130, TRANSFORM_D1FLIP, mode )
imgputt( p, , 10 + 120 * 3, 130, TRANSFORM_D2FLIP, mode )

imagedestroy p
sleep

使用画像。

_sprite_24bit.bmp
_sprite_16bit.bmp
_sprite_8bit.bmp

fbc imgputt_test.bas でコンパイル。imgputt_test.exe を実行。


RGB = (255, 0, 255) の部分が透明になっている。

せっかくだから、Put() と比べてどのくらい遅いのか調べてみた。

また、ついでなので、昨日自分が書いた、縦1ライン、もしくは横1ライン毎に Put() を使って逆方向に描画する版( PutEx() )も測ってみた。

_putex.bi

_imgputt_test2.bas

#include "imgputt.bi"
#include "putex.bi"

#define BPP  32
'#define BPP  16
'#define BPP  8

screenres 512, 288, BPP
Dim As Any Ptr p = ImageCreate(101, 101)
Select Case BPP
Case 32 : Bload "sprite_24bit.bmp", p
Case 16 : Bload "sprite_16bit.bmp", p
Case 8 : Bload "sprite_8bit.bmp", p : color 16, 16 : cls
End Select

Dim As Double starttime, t0, t1, t2
Dim As Integer max_count = 3000

Sub sub1(ByVal max_count As Integer, ByVal p As Any Ptr)
    For i As Integer = 0 To max_count
        Put (10, 10), p, Trans
        ' Put (10, 10), p, Pset
    Next i
End Sub

Sub sub2(ByVal max_count As Integer, ByVal p As Any Ptr)
    For i As Integer = 0 To max_count
        'imgputt( p, , 130, 10, TRANSFORM_HFLIP, 0 )
        'imgputt( p, , 130, 10, TRANSFORM_VFLIP, 0 )
        imgputt( p, , 130, 10, TRANSFORM_HFLIP Or TRANSFORM_VFLIP, 0 )
    Next i
End Sub

Sub sub3(ByVal max_count As Integer, ByVal p As Any Ptr)
    For i As Integer = 0 To max_count
        'PutEx(10, 130, p, 0, 0, 101, 101, 1)
        'PutEx(10, 130, p, 0, 0, 101, 101, 2)
        PutEx(10, 130, p, 0, 0, 101, 101, 3)
    Next i
End Sub

starttime = Timer
ScreenLock
sub1(max_count, p)
ScreenUnlock
t0 = Timer - starttime

sleep 1000

starttime = Timer
ScreenLock
sub2(max_count, p)
ScreenUnlock
t1 = Timer - starttime

sleep 1000

starttime = Timer
ScreenLock
sub3(max_count, p)
ScreenUnlock
t2 = Timer - starttime

sleep 1000

Print "Put     : " & t0 & " sec (100%)"
Print "imgputt : " & t1 & " sec (" & int((t1 / t0) * 100) & "%)"
Print "PutEx   : " & t2 & " sec (" & int((t2 / t0) * 100) & "%)"

imagedestroy p
sleep

fbc imgputt_test2.bas でコンパイル。imgputt_test2.exe を実行。

• imgputt() は、メモリからメモリに値をコピーするものとして処理をしている。
• PutEx() は、横1ライン、もしくは縦1ライン毎に、Put() を使って逆方向に描画していく。水平垂直反転の時だけ、1ドット単位で Put() を呼んで描画する。

水平反転のみ、垂直反転のみ、水平垂直反転、の3つを測定。





フォントが小さくて読めないかもしれないけれど、大体以下のような結果になった。

• 水平反転のみ、かつ、透明色有効の場合、Put() と比べて、imgputt() は5倍遅い。PutEx() は6倍遅い。
• 垂直反転のみ、かつ、透明色有効の場合、Put() と比べて、imgputt() は5倍遅い。PutEx() は2倍遅い。
• 水平垂直反転、かつ、透明色有効の場合、Put() と比べて、imgputt() は5倍遅い。PutEX() は135倍遅い。

imgputt() は、大体5倍ぐらい遅い。どの反転描画も似たような処理をするので、処理速度は安定している。

ライン単位で Put() を呼んでいく PutEx() はかなり遅いのではないかと思ってたけど、意外とそうでもなかった。imgputt() は5倍遅いけど、PutEx() の水平反転は6倍ちょっと程度。そんなに悪くない。垂直反転に至っては Put() の2倍程度で処理できてるので、5倍遅い imgputt() よりも処理が速かった。これは意外だった。

ただ、PutEx() で水平垂直反転をすると、最悪な結果になる。135倍遅いのは、さすがに…。おそらく、Put() を1回呼ぶたびに、画面をオーバーしてないか等を調べていくのだろうけど、それを1ドットずつやってたら話にならないよなと…。

それにしても、標準描画機能の Put() は異様に速い。どういう処理をしているのだろう。github にC言語で書かれたソースがあったので眺めてみた。

_fbc/src/gfxlib2/gfx_put_trans.c at master - freebasic/fbc

fb_hPutTrans1C()、fb_hPutTrans2C()、fb_hPutTrans4C() があるけれど、それぞれ、色深度8bitモード(パレットモード)、16bitモード(RRRRRGGGGGGBBBB bit)、32bitモード(AARRGGBB byte)なのだろう。

やってることは、imgputt() とさほど変わらない印象。y と x でループを回して、1ドットずつ見ていって、値をコピーするかしないかを決めて、ポインタをしかるべき値で進める。まあ、そうなるよなあ…。

もしかして、+= ではなくて、++ をループ内で使ってるあたりが効いてるのだろうか？

.tcl のexe化を試してみた。手順は、以前メモしたやり方を踏襲。

_mieki256's diary - Tcl/Tkのスクリプトをexe化
_Google Code Archive - Long-term storage for Google Code Project Hosting.

以下のファイルを入手してリネーム。

• sdx-20110317.kit -> sdx.kit
• tclkit-8.5.9-win32.upx.exe -> tclkit.exe
• tclkitsh-8.5.9-win32.upx.exe -> tclkitsh.exe

sdx.bat も作成。

_SDX under Windows

sdx.bat

@tclkitsh sdx.kit %1 %2 %3 %4 %5 %6 %7 %8 %9

hoge.tcl というスクリプトがあると仮定する。exe化の流れは以下。

hoge.tcl を hoge.kit (VFS,仮想ファイルシステム) にラッピング。

sdx.bat qwrap hoge.tcl

hoge.kit を逆ラッピングして hoge.vfs/ に展開。

sdx.bat unwrap hoge.kit

hoge.vfs/ 以下を hoge.exe にパッケージング。つまりexe化する。

sdx.bat wrap hoge.exe -runtime tclkit.exe

MSYS2上でも、Tcl/Tk が動作するか確認してみた。関連パッケージは既にインストールされていた。pacman -Ss tcl と打てば、おそらく関連パッケージがリストアップされるのではないか、と。間違ってるかもしれんけど。

*NIX上ではどうやって動かすのかなと思ったけれど、各スクリプトの先頭に以下の1行を書いておけばいいらしい。

#!/usr/bin/env wish

wish が Tcl/Tk を動かすためのプログラムなのだろう…。/usr/bin/env wish で、PATHの中から wish を探し出してくれる。

もしかすると、スクリプトの改行コードを LF にしておかないといけないのかもしれない。面倒な時は、dos2unix *.tcl を動かせば改行コードをLFに変換してくれる。pacman -S dos2unix でインストールできる。

まずは、実行プログラムである自分自身のファイルパスを取得できそうか試してみる。それができれば、(自身のファイル名).ini のファイルパスを得ることもできるだろう…。

以下のページが参考になった。ありがたや。

_HSP3 あれこれ 【ファイル関連サンプルソース】 - Let's HSP!

_getexeloc.hsp

; 実行プログラムの名前やパスを取得してみる

;; 実行ファイル名を指定
#packopt name "getexeloc"

;; exe生成を指定
#packopt type 0

#uselib "kernel32"
#func GetModuleFileName "GetModuleFileNameA" int, int, int

sdim filepath, 256
GetModuleFileName, varptr(filepath), 256

cls
mes "dir_cur : " + dir_cur
mes "dir_exe : " + dir_exe
mes "filepath : " + filepath

;; ファイル名のみ取得
mes "filename : " + getpath(filepath, 8)

;; 拡張子を除外してiniファイル名にする
mes "ini file : " + getpath(filepath, 1) + ".ini"

HSPスクリプトエディタで開いて、Ctrl + F9 を叩いて exeファイルを作成。実行してみる。


取得できたっぽい。

iniファイルを読み込んでみる。

_read_ini.hsp

; iniファイルを読み込んでみる

;; 実行ファイル名とexe生成を指定
#packopt name "read_ini"
#packopt type 0

fullscreen_bin = ""
config_bin = ""
preview_img = ""

#uselib "kernel32"
#func GetModuleFileName "GetModuleFileNameA" int, int, int

;; 自分自身のファイル名を取得
sdim filepath, 256
GetModuleFileName, varptr(filepath), 256

;; iniファイルのファイルパスを生成
ini_filepath = getpath(filepath, 1) + ".ini"

;; iniファイル読み込み
ini_data = ""
notesel ini_data

; iniファイル存在チェック
exist ini_filepath
if strsize = -1 {
    mes "Not found " + ini_filepath
} else {
    ; iniファイルを読み込む
    noteload ini_filepath

    ; 1行ずつ内容を解析して記録
    sdim ld, 512
    repeat notemax
        noteget ld, cnt     ; 1行分を取得
        
        if instr(ld, 0, "fullscreen_bin=") >= 0 {
            split ld, "=", kind, cmd
            gosub *checkfileexist
            fullscreen_bin = cmd
        }
        if instr(ld, 0, "config_bin=") >= 0 {
            split ld, "=", kind, cmd
            gosub *checkfileexist
            config_bin = cmd
        }
        if instr(ld, 0, "preview_img=") >= 0 {
            split ld, "=", kind, cmd
            gosub *checkfileexist
            preview_img = cmd
        }
    loop
}

cls
mes "fullscreen : " + fullscreen_bin
mes "config     : " + config_bin
mes "preview    : " + preview_img

; main loop
repeat
    ; ESC key to exit
    stick key, 128
    if key & 128 : end

    await (1000 / 60)
loop
end

; ファイルの存在チェック。
; cmd にファイルパスを入れて呼ぶ。
; ファイルが存在しなかったら cmd が空文字列になって返る。
*checkfileexist
    if cmd = "" : return
    
    exist cmd
    if strsize = -1 {
        cmd = ""
    }
    return

iniファイルは以下。

_read_ini.ini

fullscreen_bin=D:\home\prg\hsp\fullscreen\boundball.exe
config_bin=D:\home\prg\hsp\fullscreen\boundball_cfg.exe
preview_img=D:\home\prg\hsp\fullscreen\sample.bmp

HSPスクリプトエディタで Ctrl + F9 を叩いて exeファイルを生成。実行してみる。


iniファイルの内容を取得できた。

一応少しだけ解説。

• テキストファイルを読み込むには、notesel, noteload, noteget, notemax 等を使える。
• ファイルの存在確認は、exist ファイルパス、が使える。その直後に strsize を調べてみて -1 だったらファイルは存在していない。
• instr() で、指定文字列が入ってるかどうかを調べられる。
• split を使って、任意の区切り文字で文字列を分割できる。

これで、"自分自身のファイル名".ini を読み込んで、中に書かれた文字列を取り出すことができた。

HSPから外部プログラムを実行してみる。以下が参考になった。

_exec命令 （外部プログラムの起動） HSP3入門講座 - Let's HSP!

_exec_tes.hsp

; 外部プログラムを実行

#packopt name "exec_tes"
#packopt type 0

exe_path = "C:/Windows/System32/calc.exe"

exist exe_path
if strsize = -1 {
    mes "Not found " + exe_path
    wait 5 * 100
    end
}
    
exec exe_path
end

実行すると、Windowsの電卓が起動する。

とりあえず、iniファイルの読み込みと、外部プログラムの実行はできたので、これをスクリーンセーバのサンプルに組み込んでいけば…。どうかな…。

帰宅後少し使ってみたけれど。予想通り、クリック音が…。初代を横に置いて比較すると、初代は「カチ」「カチ」で、二代目は「パキャッ！」「パキャッ！」。思わず変な笑いが出てしまうぐらいに違う。いや、分かってたけど。既に1個持ってるから知ってたけど。 *1 まあ、当時から何か変更されたりしてないようだなと。そして、個体差というわけでもなかったのだなと…。

さておき。ホイールはちゃんと反応してくれた。良かった…。最初から壊れてる個体ではなさそう。でもまあ、数日〜数週間でダメになる展開もありそうな…。

拡張ボタンは、初代ほどではないにせよ、間に合わせで使っていた _ ELECOM M-BL21DBSSV の拡張ボタンと比べたら全然マシな押しやすさ。まあ、二代目形状は既に持っていたから、そのあたりは予想通りで。

M-BL21DBSSV の拡張ボタンは、お情け程度の面積なので、ちとツラくて。1回押したつもりが2回クリックになったりもするし。M-XGM10UBXBK の拡張ボタンは面積がそれなりにあるので、まだ全然押しやすい。

もっとも、以前、初代から二代目に変更した際は、1日で右肩がバキバキになったので、ちょっと様子見しないといかんけど…。拡張ボタンに何かを貼り付けて、高さ調整できないものかな。プラモデルを趣味にしてる人ならパテだのなんだので加工できるのかもしれんけど…。

でもまあ、「握りの極み」を謳うだけあって、マウスを動かしてる時の腕は随分楽になった気が。もちろん、人それぞれ持ち方が違うので、万人にオススメできるわけでもなく。購入を検討する人は必ず店頭で実際に触ってみてね、としか言えないですけど。

何にせよ、コレでしばらく様子見…。当たりの個体ならいいのだけどな…。保証期間は6ヶ月なので、7月一杯まで壊れずに済むかどうか、みたいな。

店頭で物色した際、 _BUFFALO BSMBU510MBK にするかどうかで悩んだり。本体の形状自体はヨサゲだったけど…。

ただ、店頭の展示品は、ホイールの回転が妙に硬いのが気になって…。以前、BUFFALO製マウスを買った際、左クリックが異様に硬くて使い物にならないと判断した記憶もあって、それ以来あのメーカの品は信用できなくて…。個体差が大きいのかもしれんけど、マウスとして最低限の品質すら満たせているのか、ちょっと怪しいなと…。

拡張ボタンも小さ目で、これはおそらく押しにくいかもな、と…。例えば、BUFFALOの _Premium Fitシリーズ は、拡張ボタンが下についているけれど。そこから察するに、どうも「拡張ボタン要らない」派の声をまともに聞いてしまって、いかにして拡張ボタンを押しにくくするか、てな方向で設計しちゃってる気配があるなと。個人的に、それは困るわけで…。

以下、長文。

自分は、マウスの拡張ボタンを日に100回以上はクリックしている人種で。 *1 だから、押しやすく、しかも確実に押したことが反映される、そんな拡張ボタンを持った多ボタンマウスが必須でして。

そんな条件を満たすマウスが無いか、各製品のレビューを眺めていたら、ちょっと首を傾げるレビューを見かけてしまったのです。

その人は、とあるメーカの多ボタンマウスを買ったのだけど。「誤操作で拡張ボタンを押してしまう。そもそも拡張ボタンを無くしたほうがいい」てなレビューを書いていて。

それを読んで、自分は目が点に。オイコラちょっと待て。なんで「拡張ボタンなんて要らない」と言い切れちゃう人間が、わざわざ多ボタンマウスを選んで買って文句を言ってんだよ。おかしいだろ意味わかんねえ。お前のようなヤツが居るせいでマウスメーカがどんどん拡張ボタンを押しにくい設計にしちゃってんだよ。おかげで俺の右肩は痛みでバキバキだよ。大迷惑だよ。お前いいかげんにしろよ。ふざけたこと言ってんじゃねえぞ。責任取れよ。

などと怒りすら感じ始めた直後に、ふと疑問が湧いたのです。待てよ？ その人が欲しいと思う3ボタンマウスって、今の市場にあるのかな？ と。

そこでようやく「あっ」と気付いたのです。無いのですよ。そんな3ボタンマウスは今の市場に無い。多ボタンマウスと同じ形状、同じ機能で、しかし、3ボタンマウス。そんな製品はまず存在しない。

考えてみたら、マウスってそういう品揃えだよなと…。「形状に拘りました」「質感に拘りました」「機能を色々つけました」「お値段も高くなりました」…そんな製品群はえてしてもれなくほぼ確実に、拡張ボタンまでついてくる。3ボタンマウスで、「(形状|質感|機能)に拘りました」てな製品ってありますか？ ほとんど見かけないですよ。

こんな状況では、「拡張ボタン要らない」派は…。

「お。このマウスいいな。でも多ボタンマウスかー。これの3ボタン版は無いのかな？ …無いのか。仕方ない。この多ボタンマウスを試しに買ってみるか」

そして。

「うわ！ やっぱり拡張ボタンを押しちゃうじゃないか。この糞マウスが！ ええい、ムカつく…。こうなったらレビューを書いて叩いてやる！」

みたいな。

更に、それらのレビューを真に受けちゃったマウスメーカが、「あの製品、『拡張ボタンを誤操作で押してしまう』と散々叩かれてしまったな…。もっと押しにくい位置や形にしないとダメなんだろう…」と次製品で改悪を加えて。

そして自分のような人間がソレを買ってしまって、「えっ。前の代はめっちゃ押しやすい拡張ボタンだったのに、なんでこんな押しにくい位置・形にしちゃったの？ コイツラ一体何のために多ボタンマウス作って売ってるんだ？」てな感想を…。

ということで、「拡張ボタンを誤操作で押してしまう」的レビューを書いている方の中には、そもそも「拡張ボタン要らない」派が絶対に混ざってるよなと。そうとしか思えない。だって、「そもそも拡張ボタンは要らない」なんて意見を、わざわざ多ボタンマウスのレビューで書いちゃう人が居るわけで。月見うどんを注文しておいて、何だコレ卵が入ってるぞけしからん！と怒り始める客のようなもので。そこだけ見たら全く意味がわからない。

しかし、それも仕方ない。なぜなら、そういう人達が欲しいと思う3ボタンマウスは市場に無いですから。マウスメーカが、マウスに付加価値つけて売ろうとすると、猫も杓子も多ボタンマウスにしちゃう…。「拡張ボタンは要らない」けれど「マウスにはちょっと拘りたい」派は、多ボタンマウスの中から選ぶしかない。そして文句を言う。「なんだこれ。拡張ボタンを押しちゃう(＝押しやすい)じゃないか！ ふざけんな！ クソが！」と。

「多ボタンマウスをわざわざ買ったのだから、その人は拡張ボタンも欲しがってるはず」 ―― 自分は今までそう思い込んでいたけれど、その認識は間違ってた。現状、多ボタンマウスなんて要らない人が、多ボタンマウスを仕方なく買っている。

そのことを意識しながら各製品への意見・感想を読まないといけない。「コイツは『拡張ボタン無いと死んじゃう』派か、それとも『拡張ボタン要らない』派か」、まずはそこから見極めないと…。「誤操作で拡張ボタンを」系の感想は、本当の感想じゃないのです。そこは気をつけて読まないと…。

じゃあ、どうすればいいのか。

多ボタンマウスを発売する時に、同じ形状、同じ機能で、3ボタンマウス版もラインナップに加えれば…それが理想的ですわな。でも、そんなの無理だと言われそう。製品ラインナップを1つ増やすだけでどれだけコストがかかると思ってるんだ、金型作るのも基板設計するのもラインを確保するのも大変なんだぞ、みたいなことを言われそうな気が。

でも…。素人考えですが、他にも方法はあるよなと。

• 拡張ボタン(のプラスチック部分)をズボッと引っこ抜ける設計にしちゃう。
• 拡張ボタンに蓋をして隠してしまうパーツも付属させる。
• 物理的 or 電気的なスイッチをつけて拡張ボタンの有効無効を切り替え可能にする。
• 拡張ボタンを強制無効にするソフトウェアを配布する。

どうしても多ボタンマウスとして売らなきゃいけない、という場合でも、工夫次第で3ボタンマウスにできる余地がまだ残ってる。頭の固さには自信がある自分ですらスラスラと案が出てくるのだから、アイデアマンならもっとナイスな名案を思いつくはずで。

もっとも、実は現状でも、多ボタンマウスを3ボタンマウスにできるのですけど。

例えば Windows機なら、マウス関連ユーティリティをインストールして、拡張ボタンの割り当てで「無効」を設定してしまえば、それで済んじゃう。

各マウスメーカは ―― 例えば、ロジクールも、ELECOMも、BUFFALOも、拡張ボタン割り当て変更ソフトを公開してるわけで。…BUFFALO のは設定項目が少なかったから無効化できるかちょっと分からんけれど。

_Logicool Optionsをダウンロードし、作業生産性を高めましょう
_SetPointソフトウェア
_エレコム マウスアシスタント - ELECOM
_Buffalo Mouse Utility ソフトウェアマニュアル

ちなみに自分は、 _X-Mouse Button Control (XMBC) というユーティリティを使って拡張ボタン割り当てを変更してますけど。確認してみたら、拡張ボタンを無効にする設定も、ちゃんとしっかりありました。

なので、マウスを買い替えるまでもなく、「拡張ボタンを殺す」という目的は今でもすぐに果たせるのです。殺してしまえば誤操作もへったくれもないわけで…。

だから、本来、マウスメーカは、「誤操作でー」なんて文句を全てガン無視していいはずなのです。「は？ ユーティリティ入れろや」と言い放って切って捨てればいい。本来であれば。

ただ…。文句を言う人達って、どうもそのあたり、全般的に無知っぽくて…。

何せ、あのへんの方々は、「マウスを買い替えたらマウスカーソルの動きが速過ぎた！ この製品は糞！」てな文句を言ってる場面もチラホラ…。そんなの _OSのマウス設定弄れば 好きなだけ変更できますわな。遅いのを速くはできないけれど、速いのは遅くできる。

そんなこと(?)すら知らない人達が、その手のユーティリティを導入できるかと言うと…。これはちょっと望み薄で…。

なので、マウスメーカは、マウス自体にスペックの切り替え機能を設けることがちょくちょくあって。例えば、DPI切り換えボタンがついてる製品がありますけど。アレって、「マウス自体を買い替えないとマウスカーソルの速度は変えられない」とすっかり思い込んでる人達を相手にしてる面もあるのだろうと…。

であれば、多ボタンマウスの拡張ボタンを無効にする機能を、マウス自体につけてしまう策だってアリかもしれないよなと。 *2

まあ、何にせよ、「誤操作で拡張ボタンを」系の感想に騙されてはいけないよなと。ソレ、嘘だから。本当の感想じゃないから。真の問題は別にあるから。もちろん前述のとおり、そのユーザのせいではなく、市場の品揃えの問題で、そういう嘘の感想が出てくるわけですけど…。

"""
Pyxel Hello world.

Windows10 x64 + Python 3.7.1 32bit
"""

import pyxel


class App:
    def __init__(self):
        w, h = 160, 120
        pyxel.init(w, h, caption="Hello World", fps=60)

        pyxel.load("assets/helloworld.pyxel")

        self.x = pyxel.width / 2
        self.y = pyxel.width / 2
        self.counter = 0

        pyxel.run(self.update, self.draw)

    def update(self):
        if pyxel.btnp(pyxel.KEY_Q):
            pyxel.quit()

        if pyxel.btn(pyxel.KEY_LEFT):
            self.x -= 1
        if pyxel.btn(pyxel.KEY_RIGHT):
            self.x += 1
        if pyxel.btn(pyxel.KEY_UP):
            self.y -= 1
        if pyxel.btn(pyxel.KEY_DOWN):
            self.y += 1

        self.counter += 1

    def draw(self):
        # clear screen
        pyxel.cls(0)

        # draw image
        x, y = self.x - 8, self.y - 8
        u, v, w, h = 0, 0, 16, 16
        img = 0
        colkey = 10
        pyxel.blt(x, y, img, u, v, w, h, colkey)

        # draw text
        col = self.counter % 16
        pyxel.text(56, 16, "Hello World!", col)


App()

.
|-- assets
|   `-- helloworld.pyxel
|
`-- helloworld.py

python helloworld.py

簡単に解説。

Pyxel を使う時は、import pyxel と最初のあたりに書いておく。

pyxel.init(w, h, caption="Caption", fps=60) で、Pyxelの初期化をする。fps= を指定しないと、30FPSになる模様。

pyxel.load(".pyxelへのパス") で、Pyxelのリソースファイル(.pyxel)を読み込む。

• .pyxel には、画像、タイルマップデータ、サウンドデータ、ミュージックデータが一つにまとまっている。
• .pyxel は、Pyxel に同梱されている pyxeleditor で作ることができる。

pyxel.run(更新処理関数, 描画処理関数) で、更新処理、描画処理をする関数を渡して、メインループを回し始める。

キー入力は、pyxel.btn(pyxel.KEY_LEFT) のような感じで調べられる。押されっぱなしなら True。押されていなければ False。キー定義の一覧は、 _pyxel/constants.py at master - kitao/pyxel を参考に。

pyxel.btnp(pyxel.KEY_xxx) で、キーを押した瞬間を調べられる。

画像の描画は、pyxel.blt(x, y, img, u, v, w, h, colkey) を使う。

• x, y が描画位置。
• img が画像バンク番号。
• u, v, w, h が、画像のどの位置から、どのサイズで画像を取得するか。
• colkey が、透明色扱いにする色番号。

画像を反転描画したいときは、w や h にマイナス値を与える。x, y, u, v はそのままでいい。

文字列の描画は、pyxel.text(x, y, "文字列", 色番号) を使う。フォントサイズは…1文字が4x6ドットだろうか…。3x5ドット＋余白が縦横1ドット、みたいな感じ。

これだけ分かっていれば、2Dゲームっぽい画面表示ができるのではないかと。

Pyxelのドキュメントには、

* Alt(Option)+3
画面キャプチャ動画 (gif) をデスクトップに保存する (最大30秒)

pyxel/README.ja.md at master - kitao/pyxel より

と書いてあるのだけど。どうも動作してくれない気配が。

Windows10 x64 + Python 3.7.1 x86 + pyxel 1.0.1 で試したところ、Pyxel のウインドウが応答無しになってしまって…。放置しておけばキャプチャできたりするようだけど、キー入力をしてスプライト相当を動かしながらキャプチャしようとすると、全然撮れていない状態に。そのうちスプライト相当もウインドウ内から消えてしまったりして…。何故。

ググってみた感じでは、もしかすると Mac上ならキャプチャできるのかなと…。Windows上では不具合があるのかもしれない。不便。

仕方ないので、今回は、 _GifCam というツールを使ってキャプチャした。

ちなみに、この GifCam というツールは、ググると、作者さんとは全然関係ない悪質なサイトがトップに出てきて、アドウェア入りのソレをダウンロードする羽目になるので、作者さんのサイトからDLすること。現在の最新バージョンは 5.5 なので、「GifCam 2.0 - ダウンロード」なんてリンクは絶対にクリックしないように。

pyxeleditor を使ってドットを打った後で気がついたけど。もしかすると、現状では、pyxeleditor はリソースの墓場かもしれないなと。ドットを打っても、別途、他のツールで利用できる画像として取り出せないなと…。他のツールで作った画像を、D&D(ドラッグアンドドロップ)して、インポートすることはできたのだけど、エクスポートをする手段が用意されてない雰囲気。

TIC-80 のように、画像だけでもエクスポートできれば助かる場面もありそうな予感。

でもまあ、Pyxel から画像データへのアクセスはできるようだし、必要ならば自前でツールを作ることも可能ではあるのかな…。

でも、コマンドラインオプションを指定すると画像をエクスポートできます、みたいな仕様が入ってたら、助かりそうだなと…。

妄想を書き留めた後でググってみたら、薄型掃除機は既にフツーにゴロゴロ存在してた。考えてみたら、ロボットタイプのウロウロする掃除機って、ほとんどが薄型掃除機だったのだな…。ていうか「薄型掃除機」でググるとロボット掃除機しか出てこない。ロボット以外の薄型掃除機は無いのかな…。

でも、静音なのかというと、どうやらそうでもないらしい。

_うるさいと言う不満を持たせない音の静かなロボット掃除機6選 | ロボット掃除機でみんな幸せ

「昼間は使えるけど夜は無理」なのか…。どんな構造になってるのだろう。

ググってみたけど、家庭用の掃除機って羽を大きくしてどうこうという発想がまず無いみたいだなと。家庭で使うものだからできるだけ小型にせよ → 羽が小さくなる → モータを高速回転させて風量を稼ぐ → 騒音増加、という製品しか無いような。

どうも、「大きくなったら邪魔になるだろう。そんなの決まってるだろ」という思い込みがありそうな…。大きくなるけど薄くなるとか、大きくなるけど細くなるとか、色々ありそうな気もするのだけど。x,y,zの全方向に大きくしなきゃいけないわけでもあるまいに。

などと思ったりもしたけど、紙パック式云々の問題もあったりするから、形状を大きく変えることは許されない、みたいなところがありそうな気もしてきたわけで。

小説や漫画は持ってない、映像作品の特長として、時間の制御ができる・時間を提示できるという点があるわけで。そのあたり、音楽と似てるのですが、それはちょっと横に置いといて。

「時間を提示」と言っても、大別すると2種類あって。実時間を見せてる場面と、体感時間(心理描写)を見せてる場面がある、と思うわけですよ。

実時間ってのは、1秒の動作を撮影したら、1秒かけて再生するソレ。現実の風景を等速撮影して等速再生する。これは映像作品の基本。例えば、御家庭でお父さんが撮影した子供のビデオは、えてして実時間しか入ってない。そのくらい、誰でもカメラを回せば作れてしまう。それが、実時間の映像。

対して、体感時間ってのは、そこに居るキャラがその風景をどのように感じているか、その瞬間何を考えているか、そういった部分を説明する映像。1秒の動作でも、3秒、3分、30分、いくらでも長い時間をかけて見せられる。

• (自分は未見ですが)「巨人の星」で、一球投げるのに丸々一話使った回があるそうで。それはどう考えても、体感時間の映像だよなと。
• 1stガンダムで、アムロがララァを殺してしまったシーンは、体感時間の映像。本来は一瞬の出来事だけど、アムロとララァの意識の交錯が描かれる。これは実時間を見せてるわけじゃない。
• 聖闘士星矢で、敵が星矢に殴り飛ばされる直前に、「何ィ…！ このコスモは…まさか…」とか色々ブツブツ言ってたりするけど、アレも体感時間。実時間では、音速だか光速だかで殴り飛ばされてるはずですから、ブツブツ言ってる余裕なんてない。
• 出崎演出の3回PANは、体感時間。正確には、1回目は実時間、2回目3回目は体感時間なのかなと思いますが。…アレって、文法を知らない人が見ると、「この人は3回殴られてるんだな」「この人どうして一瞬のうちに3回もボールを打ち返してるんだろう」と勘違いするのかしらん。

実写作品の場合、実時間を忠実に再現してる場合がほとんど。せいぜいスローモーションが時々入るかどうか、ぐらいなもんで。もっとも最近は、視聴者側の、映像に対する文法の理解が進んだので、早回し映像や、連続した動きを分断して繋ぎ直す映像もOKになっていますが。

アニメの場合、実写と同様、実時間の映像を見せることもできますが。実写以上に、体感時間の映像を見せやすいという性質があって。

• 日本のTVアニメは、漫画原作の映像化で発展してきたので、漫画で多用される体感時間の表現を多く取り込んできた。
• そもそも人が描いた絵が動いてるから、現実の風景をそのまま見ているわけではなく、実時間から体感時間に切り替わる際の拒否反応が少ない。
• ずっとそういう作りを続けてきたので、作る側も、見る側も、文法として慣れてしまっている。

他にも理由はあると思いますが…。

例えば、宮崎駿監督は、作家性としては実時間系だろうと。明らかな体感時間映像を見せてるシーンは、かなり少ない印象で。まあ、宮崎駿監督は、体感時間を実時間のように見せてしまう魔術師、てなところもあるのですけど。

勝手な印象だけど、昔の東映動画出身者は、実時間系の作家性を持つ人が多いような気もしますな。東映動画は、映画会社が作ったスタジオ、だからなのかな…。あまり関係ないかな…。

体感時間系の監督と言うと…たくさん居るだろうけど、例えば、故・出崎監督などはそうだったのかなあ。

これもまた、虫プロやタツノコプロ出身者は、体感時間を見せることに躊躇しない印象が。元々、虫プロも、タツノコプロも、漫画をアニメにするために作ったスタジオだったので、漫画の各種表現を再現することも課題として与えられてた…てな点も関係してるのかなと。

さらに、虫プロから分かれて作られた、マッドハウスやサンライズも、その傾向があるような。そしてそれらのスタジオ作品を見て育った今の作り手も、同じ傾向が…と想像しますが。

てなわけで、アニメというジャンルは、やたらと実時間ではない映像が挿入される傾向がある、と、自分は思っているのですけど。

しかし、無頓着に、体感時間を実時間の中に入れてしまって構わないというわけでもなくて。「今まで実時間映像を見せてたけど、このカットは体感時間を見せてますよ」と、映像のモードを切り替えてることを伝えるための、スイッチ・記号的表現が必要で。

• 1stガンダムで、ガンダムハンマー(?)をゴッグが受け止めちゃうシーンがあるけれど。受け止めた直後、ガンダムとゴッグが静止しますが、背景が謎模様になったり、色指定が通常時と変わったりしてた…ような記憶が。謎模様の背景、あるいは、いつもと違う色指定が、「体感時間を見せてますよ」のスイッチ、だろうなと。そういう見せ方は、ダンバイン、エルガイム、Zガンダムでも見かけた記憶もあり。
• 「風の谷のナウシカ」で、ナウシカがユパ様の腕に剣を刺しちゃった直後、ナウシカの周囲がどんどん暗くなって、ユパ様のテレパシー音声が聞こえてくるシーンがあるけれど。真昼間なのに背景が急激に暗くなっていくあたりが、スイッチ。
• 出崎演出のハーモニー効果は、セル画タッチから、手塗りタッチにオーバーラップしていく見せ方だけど。塗りの質感が変化するあたりが、スイッチ。

てな感じで、「このカットは実時間じゃないよ。体感時間だよ」と伝えるための手管を、過去の名作は駆使していて。それらスイッチが用意されてるから、見ている側は、無意識下で、実時間と体感時間をパチパチ頻繁に切り替えつつ、それでいて混乱することなく、各作品を楽しめてる。キャラが長々と心の声で喋っていても、「これは一瞬のうちに起きてることなのだ」「のんびり戦ってるわけじゃないのだ」と脳内補完・理解してくれるわけですな。

てなわけで。「東京レイヴンズ」の件のコンテって、もしかするとそこが欠けてたんじゃないのかなと疑問を持ったのでした。コンテ・演出は、それぞれのカットで体感時間を描いてるつもりでいたけれど。画としてのスイッチが足りてなくて、結果、こっちは実時間と勘違いしたまま見てしまったカットがいくつかあり、「緊迫してるように見えないなあ」と思ってしまったのかしら、と。 *1 まあ、分かんないですけど。

とりあえず、件の回をキッカケにして、映像作品中で実時間と体感時間の切り替えが上手く行ってないと緊迫感が出なかったりするのかもしれん、てな仮説を、こんな感じで捻り出してしまった…てなだけの話でした。この仮説、当たってるのか、外してるのか、分かんないですけど。

スイッチ云々は、誰でも知ってれば使えるだろうけど、知らないままだと使えないし、使ってないことをマズイとも思わない、てな話だろうなと。こういうのって、センス云々で片づけちゃいかん気もしてきたり。「技を知ってるけどあえて使わない」「(予算やスケジュールが足りなくて)状況的に使えない」のと、「知らないから使えない」のは、違うよなと。

件の回のコンテは、平池芳正氏だったようで。気になってググってみたら、「WORKING!!」「AKB0048」の監督さんだったり、「ポスト佐藤順一」と一部で呼ばれてたりする方だそうで。…変だな。監督さんクラスなのに。何か実験でもしてたのかな。あるいは単に、話の内容と作家性の相性なのかも、と思えてきたり。日常シーンが多めの回や、ギャグ回なら、イイ感じになったのかも。

企画・脚本と、コンテ・演出の相性って、絶対にあるよなと思うわけで。例えば、佐藤順一監督に「ブラックマジックM-66みたいなコンテ描いて」とお願いしても絶対無理だし。山田洋次監督に「トランスフォーマー実写版の監督して」とお願いしても絶対無理だし。相性って重要だよなと。

でも、何度か試しにやってみないと、向いてるか向いてないかも分からんですわな。

そう考えると…。なんだか、山田洋次監督のトランスフォーマーを見てみたい気もしてきたり。意外と面白かったり…いや…どうだろ…。

なんで前述の記事に辿り着いたかというと。

_Unicodeに不愉快な絵文字が - Mac OS Xの文字コード問題に関するメモ
_アレはどこから来たの？ - Mac OS Xの文字コード問題に関するメモ
_最も危険な絵文字 - Mac OS Xの文字コード問題に関するメモ
_バルカン星人のUnicode侵攻 - Mac OS Xの文字コード問題に関するメモ

t-tanaka
しつこいようだが，何度でも主張する。絵文字を取り入れたのはUnicode最大最悪の失敗だった。 2013/01/29

はてなブックマーク - Unicodeに不愉快な絵文字が - Mac OS Xの文字コード問題に関するメモ より

自分もそう思えてきたり。日本のガラケー文化はUnicodeに酷い事をしたよね(´･ω･｀) みたいな？ いや、ガラケー文化のせいだけじゃないのかもしれないけど。

Unfold Tool の作者が、「Unfold Tool よりゴイスなプラグインもあるぜ」と紹介しているソレ。らしい。

試しに使ってみた。たしかに、簡単にサクサクと展開してくれる。が、使い方がよく分からん…。

自分の場合も、なんだか思い当たることがある。例えばアプリを切り替える際、Alt+Tabを連打して、目的のアプリを通り過ぎて2〜3周してしまう場面が結構ある。Shift+Alt+Tabを押せば逆に進むことは知ってるし、カーソルキーで選べることも知ってるけれど、どうしても瞬間的に、Alt+Tabを連打して数周回るほうを選んでしまう。どう考えても無駄な操作。だが、そのほうがやりやすいと感じてしまう何かがある。 *1

ウインドウ管理を、もう少し改善できないものだろうか。Windowsも、各ウインドウのサムネイルを表示してみたり、3次元的に並べてみたり、色々模索をしているのは分かっているのだが。

ウインドウ管理・アプリ管理も、タブになれば解決するのだろうか。いや、だから、それは正解じゃないだろう…。

世の中には、「どうやって紙だけでこんな形状を作り上げたんだ」と驚愕するゴイスな作品がたくさん存在していて。見ている分には感嘆の溜息しか出てこない。

しかし、自分自身でそれらを作ってみたくなるのかというと、全然まったくそんな気持ちにならないことに気が付いた。だって、面倒臭い。やってられない。

自分は、小学生の頃、「紙工作ペーパークラフト入門 (小学館入門百科シリーズ)という本を読んで、ペーパークラフトに興味を持ち始めた。そして、掲載されていた機関車を作ろうとしたものの、作業の大変さに挫折した。それ以来、ペーパークラフトに若干興味がある状態が続いているのだけど。小学生の頃からずっと、作ろうとしては面倒臭くて挫折してばかりで。

ここにきてようやく、どうやら自分が好むペーパークラフトは、世間一般のソレとは違うような気がしてきたわけで。自分は、世間の皆様ほどの根性はない。

では、どういうペーパークラフトならいいのだろう。…関連しそうな事例を3つほど思い浮かべた。

NHK教育のとある番組で、紙コップにマジックで顔を描いてアニメをさせているコーナーがある。紙コップというシンプルな形状。しかし豊かな表情。…アレは素晴らしい。

昔NHKで「テラホークス」というSF人形劇が放送されていて、その中で、ボール型ロボットとサイコロ型ロボットがバトルをしていた。ボールとサイコロと言うシンプルな形状。しかし表面はメカ。…アレは素晴らしい。

ネットで時々見かける有名な写真。ダンボールをかぶり、表面に「GUNDAM」とだけ書いて、ビシッとポーズを決めているコスプレ写真。極限までシンプルな形状。そこに描かれた重要な意味を持つテクスチャ。…アレは素晴らしい。

この3つに共通するのは、「形はシンプル」「テクスチャが肝」。

ペーパークラフトも同様なのではないか。自分が好む、というか、作ってみようかなと思えるペーパークラフトは、そういう方向性のような気がする。

つまり、こんなシンプルな形でも、

テクスチャを頑張れば、 印象が随分変わる。自分の場合はこれでいいんじゃないかと。

そのあたりを考えると、PC上で動作するペーパークラフト作成支援ソフトも、微妙に問題があるような気がする。ソフト自体に問題があるのではなく、ソフトの利用のされ方、あるいは、特定の方向のみを意識したソフトしか存在していない状況に問題があるというか。

それらソフトは、えてして複雑な形状を如何にして展開するかということに重点を置いているように見える。方針として、まず形状ありき。テクスチャは二の次。ではあるまいか。

支援ソフトに渡すデータを作る際には、3DCGモデリングソフトを使うが。そういったソフトを使って作業していると形状作成に力が入ってしまう。ポリゴンだけでどれだけ滑らかな曲面を表現するか。どれほど入り組んだ形状を構成してみせるか。便利なソフトだから、ついつい凝り始める。そして、プリンタで印刷してから、途方に暮れる。切り出しも、のり付けも、面倒臭いデータが出来上がる。ソフトが便利過ぎて、いつの間にか、簡単に作れるようにしようという意識がどこかに飛んで行ってしまう。…いや、元々、そんな意識は持たないのがペーパークラフトの世界かも知れないのだけど。

個人的には、そっちじゃないよなと思えてきた。形状なんて、展開しやすくて、組み立てもしやすい、あらかじめ事前に準備した、数種類の基本形だけでもいいのではないか。その分、テクスチャを描きやすくしたほうが、楽しい気分で心も折れずに作れるのではないか。

テクスチャが描きにくくなるぐらいなら。作る際にゲンナリするぐらいなら。形をどんどんシンプルにしたほうがいい。ラクガキする子供さんの側に寄った、あるいは、絵描きさんの側に寄った、そんなペーパークラフトを模索できないものか。

でもそうなると、ソフトを作る必要はないような気もしてくる。テンプレートだけ用意して、お絵かきソフトで上から描いていくだけでも良いのかもしれない。あるいは、ソフトで支援するとしても、あくまで部分的に、テクスチャ画像を変形させて1パーツ分程度を出力するツールとか。その程度でもどうにかなりそうな。

最近のガンプラは、接着剤を使わなくても組み立てられると聞く。

ペーパークラフトも、接着を省けないものか。接着は面倒臭い。手にボンドがベタベタつくし、紙のあちこちにもボンド跡が残るし、一度くっつけたらバラすこともできない。

例えば、日本の折り紙は、基本的にはのりを使わずとも立体になる。何かそのあたりの手法を取り込むことはできないか。と夢想中。

TVマガジン等、幼児向けの雑誌の付録は凄いなと思えてきた。アレは、どんな人達が設計してるんだろう。紙工作に関してノウハウの塊ではあるまいか。師匠や先輩から学んだのか、それとも各人が自力で発明してきたのか。一般には知られていない歴史がそこにありそうな予感。

_折り紙の科学で知的な形を作りたい！（前篇） 立体図形、折り紙研究者・三谷 純　WEDGE Infinity(ウェッジ)
_折り紙の科学で知的な形を作りたい！（後篇） 立体図形、折り紙研究者・三谷 純　WEDGE Infinity(ウェッジ)

ペパクラデザイナーを作った方って、大学の先生だったのか…。いや、今は、の話だけど。

RAGE128については動作しないとの報告を見つけました

Ubuntu日本語フォーラム / Berylを使いたい より

_Installing Beryl On An Ubuntu Feisty Fawn Desktop With An ATI Radeon Graphic Card
_A “what is” guide to 3D desktops - put in a bowl, mix, add chips for topping

なるほど、ATIビデオカードの場合、3Dデスクトップとやらは Radeon 7000 以降じゃないと使えなかったのか。

P902iS のSDオーディオを聞きながら自転車を走らせた。携帯1つ持ち歩けば音楽も聴けるというのは、便利だなと。

でもまあ、その分、電池が切れるのが早くなるだろうから、いざというときに電話としてすら使えなくなって酷い目に会いそうではあるのだけど。

音楽聴きながら自転車で走るなんて、かなり危ない気もしたけど。実際は、ヘッドフォンがアレだから、国道4号線を走る車の走行音しか聴こえない場面がほとんどだった感も。音量上げると電池が切れるし。まあ、自分、そもそも音楽聴かない人だから、今後使う場面もなさげ。

knoppix DVD版 に入ってる豊富なアプリは非常に魅力的ではあったのだけど。HDDにインストールしたらそれっきり、なのではいくらなんでもちょっとよろしくないだろうと思えるわけで。何か別のディストリビューションを探さないといけない。

インターネットに接続できない状態でも、子供たちが面白がって使ってくれそうなぐらい、たくさんアプリが入ってる・比較的簡単に入れることができるディストリビューションというと、何があるだろう…。

面倒くさいから WinXP Home を買ってきちゃうか。…いや。子供の玩具になってくれるならまだいいほうで、単に部屋の置物になるかもしれない運命のPCに、お金を出していられないしなぁ。…まあ、それを言ったら、古い版の knoppix でもいいじゃん、DVDからの起動で充分じゃん、ということにもなりそうだけど。…そもそも Windows はアプリを揃えるのが大変か。却下。

knoppix の元になった Debian は、以前試したときに、日本語化で大変な思いをさせられたから避けたいところ。もうあんな苦労は嫌だ。アレは、一切日本語を使わないことが前提のディストリだ。ということにしたい。

日本語化といえば Vine だけど、いかんせんパッケージが古かったり、他のディストリと比べてパッケージ数も少ないほうだったりするし。

Ubuntu あたりはどうなんだろう。knoppix でタブレット関係の設定が判らなかったとき、参考になったのは Ubuntu のドキュメントだったりもしたので、かなり好印象。なのだけど、knoppix DVD版に相当するようなものがあるという話は見かけてなくて。インストールするアプリを自分でリストアップして、apt-get 等でインストールしていく必要があるのだろうか。ネットに繋がる場所に置かれるわけじゃないから、アレがない、コレがない、となったときに苦労しそうな予感もあるし。そもそも Linux 文化圏にどんなアプリがあるのか詳しくない自分なので、リストアップ作業も時間がかかりそう。

BSD 界隈はどうなんだろう。ってアレはサーバ向けだろうしなぁ。

現時点では拡大画像が別の画像に差し替えられているみたいではある。が、相変わらずサムネイル画像が以前のままであるあたりは謎。さておき、やはり漢字を読めないことが歴史研究に関しても正確さを著しく欠く状況になってるであろうことは容易に想像できたりもする。…単純に考えて、その当時に利用されていた言葉が判らない知識状態で、当時の状況について研究することはかなり難しいのではなかろうか。

まあ、自分も昔の文書なんかは読めないし。旧仮名使いすらよくわからんしなぁ。専門家と呼ばれる人達によって現代文に訳したと称される文章が、どの程度正しいのか検証する術もなく。となれば、「どこからどこまでが捏造なんだろうなぁ」と絶えず疑いの目で見ることぐらいしかできないわけで。判らないなら判らないで、せめてそのくらいは意識しないとマズイよな、とも思うのだけど。

本当だとしたら、ややこしいというか、状況が複雑と言うか。

他所の国に進出すると面倒くさいことになるから、そういうことはしちゃいかんということだな。たぶん…。勝っても負けても後からグダグダ言われるし。とはいえこの国のことだから、何十年・何百年もすれば、また忘れちゃいそうな予感。

この強風を、発電か何かに使えないのかしら。エネルギー、もったいないなぁ。と言っても、常時吹いてるわけでもないし。たまにしか発電できないのでは、設置コストやメンテナンスのコストも回収できないのだろうしなぁ。

福島県中通りの、須賀川だの郡山だのは、会津のほうから風がビュンビュン吹いてくるらしいのだけど。ウチの建ってる場所は、以前は山で遮られていて穏やかだった。…日本人は自然を上手に利用する術を忘れてしまった気がする。＜話を大きくし過ぎ。

削ってしまった山は、二度と元には戻らないのだな。うーん。

防風林を植えることができればいいんだけど。そんな場所もないし。…ウチは、昭和44年頃に家を建てて引っ越してきたのだけど。須賀川に昔から住んでいた農家の人達は、えてして防風林を植えてるわけで。…目の前に堂々と公開されていた先人達の知恵。それを活かせなかった昭和・平成の日本人。かしら。

ウチの両親はどちらも農家生まれで、防風林に守られた家で育ってるのだけど。それがあるのが当たり前になりすぎて、知恵の存在に気づかなかったところがあるのかもしれない。…もっとも、そのへん、自分の世代にも言えるところがあるはずで。おそらく下の世代から、「なんで上の世代はこのことを意識・認識できなかったんだろう」と疑問を持たれる時代が来るのだろうな。

設定に関しても、今までにないヒーロー像を作ろうと奮起してるのが手に取るように判る。開拓精神豊かな石ノ森先生に負けじと、若い(?)世代が物怖じせずに冒険してるこの姿。先生も、雲の上から、 きっと見守ってるはず ―― と、そんな気がしたり。…微笑みながら見てるか、眉間に皺よせて見てるか、それは判らんけど。＜オイ。つーかあっちでも〆切に追われてて、下界の様子なんか見てる暇なかったりして。

自分も、シャンゼリオンが辛くて、ガイファードを見てた時期があったりするので。なんとなく、判る。 *4

各人、幼少時に鑑賞した特撮番組の数々によって、ガチガチに固まってしまったヒーロー像が、脳内にできてしまってる。それとかけ離れたものが出てくると、拒否反応を示してしまいがち。更に、冒険＝各所の熟成具合が足りないわけで。映像や演出にはアラが目立つ場合も多い。故に、評価が低いのも仕方ないところもあるよな、と想像するわけで。

…まあ、痛いのは最初だけだから。そのうち彼の太くて荒々しいスティックさばきが病みつきになりますよ。しかも彼ってば2本も使って同時に攻め＜何を口走ってますかコイツは。

真面目な話、その固定してしまったヒーロー像がどのような過程を得て生まれてきたのか、想像を巡らせてほしい気もしたり。最初からそれらヒーロー像はこの世に存在していただろうか。…なわけない。先人達も、当時、様々な模索を繰り返した結果、それらヒーローを生み出してきたはずで。

そして今、若い世代が、今までにない新ヒーローを生み出そうと、必死にもがいてる。…それを考えれば、せめてその姿勢には声援を送りたいと思うのでした。出来はさておき。＜オイ。 *5 *6

でもまあ、自分は「変なモノ」が出てくるだけで絶賛しちゃう人なので。何せEVAの最終回も大喜びで見てたぐらいだし。こういう人間が褒めてる時点で、商業作品としてはヤバイことを証明してるのかもしれん… (;´Д｀)

ま、1,2話は特別だから。そのうち“フツー”な作品になっちゃうかも。＜オイ。

海外では忍者や侍が人気あるみたいだし。それを考えると、和風ヒーローって意外にイケるのかしら。…でも、あくまで人気があるのって、忍者と侍だけのような気も。鬼はどうなんだろう。…アジア圏なら、比較的似通った鬼のイメージを持ってる地域が多かったりするのかな。であれば、そちらには売れるのかもなぁ…。

前代未聞。イイヨイイヨー。つーか、そこからどうやって『ライダー』に仕立てあげるのか興味津々お手並み拝見。

誰かが言ってたけど、バイクの代わりに馬に乗ってほしいなぁ。オシャレな都会の○○通りの雑踏の中を、あの姿で馬に乗ってパカラパカラパカラ。周囲は大パニック。…ウヒョー！ カッコイイ！ (ﾟ∀ﾟ)！ で、戦いが終わると、ロングショットの画で、腰を落とし背中を丸めながらアスファルトの上に粗相した馬の糞をゴミ袋に片付けるライダーの後姿。ちょっぴり異質な哀愁漂うその背中。特撮史上、最もクサイ新ヒーロー誕生。「少年。ペットの落し物はちゃんと片付けないとダメだぞー (´ー｀)」「ヒビキさん…その馬…ペットなんですか…？ (;´Д｀)」とか。礼儀正しくて子供達の模範になりそうなヒーローだ。うむ。＜「うむ」じゃねえだろ。

かなり気に入ってしまったみたいです。＞自分。