mieki256's diary

GParted Live CD を使って、転送元HDDの各パーティションを縮小リサイズして、全体的にSSDの容量に ―― 256GB以下に収める。

_GParted -- A free application for graphically managing disk device partitions
_GParted -- Download

この手の作業に必要になるのは以下のツール。

• GParted
• ddrescue
• testdisk

この3つは GParted Live CD に入ってる。

ちなみに、KNOPPIX 9.1 DVD が起動するUSBメモリでも試してみたけれど、そちらに入ってる GParted はリサイズ処理すらエラーを出してしまって正常に動かなかった。GParted Live CD を使ったほうがハマらずに済むかも。ISOのサイズも小さくて済むし。

gparted-live-1.6.0-3-i686.iso (483MB) を入手。

USBメモリにISOを入れて起動させるために、UNetbootin (unetbootin-windows-702.exe) も入手。

_UNetbootin - Homepage and Downloads

Windows10 x64 22H2上で UNetbootin を起動して、Gparted の iso をUSBメモリに書き込んだ。USBメモリは16GBの品を使ったけれど、今回は 2GB 程度あれば足りたかもしれない。

何はともあれ、Gparted Live CD が入ったUSBメモリで起動。

• VGA云々と表示されてる3番目の項目を選ぶ。
• Keymap はそのまま。
• Laungauge は Japan を選択。15 を入力。
• 0を選んでX11を起動。

自動で Gparted が表示されるので、各パーティションを縮小リサイズ、かつ、移動して詰めていく。適用ボタンをクリックすると、指定した処理が実際に行われる。

GParted でリサイズや移動をして、SSDの容量、256GBより少ない感じにまとめたら、GParted を終了。Terminal を起動。ddrescue を使って、セクタ単位で、ディスクを丸々コピーする。

一般的には dd を使って作業することが多いらしいけど、ddは不良セクタがあった場合にそこで処理が止まってしまうらしい。ddrescue なら不良セクタはスキップして処理してくれるのだとか。

dd にしろ ddrescue にしろ、転送先SSDの容量が小さいので、「これ以上転送できない」「サイズがおかしい」的なエラーが最後に出てくるけれど、そこは無視して作業する。後で testdisk を使って不整合な部分を修正してしまうので…。

転送元HDDが /dev/sda、転送先SSDが /dev/sdc なら、以下のように打つ。

sudo ddrescue -f -v /dev/sda /dev/sdc logfile.log

-f は上書き指定。-v は詳細表示(進捗状態の表示)。logfile.log は、ログファイル名。

今回の、SATA接続で、HDD → SSD に256GBを転送する処理では、1時間ほどで終わってくれた。なんだか早過ぎる気もするけど…。

testdisk を使って、パーティションテーブルがおかしくなった状態のSSDを修復。

sudo testdisk

操作は以下を参考にした。

_パーティション情報を削除してしまったHDDの復旧を Ubuntu 上の TestDisk を用いて復旧する。 - KusoBoze is here.

HDDやSSDのパーティションには、UUIDというIDがついてる。このUUIDは重複しない値がついてるはず、ということになっている。

昔の Linux は /dev/sda1 とか /dev/sdb2 とか、そういう記述形式で各パーティションを指定していたけれど。この形式ではHDDやSSDを接続するポートを変えてしまったときに、各パーティションの判別名も変わってしまうので都合が悪い。そこで、各パーティションにUUIDをつけて管理しようということになったらしい。

以下で、パーティション一覧や、各パーティションのUUIDが確認できる。

lsblk
sudo blkid

ddrescue でコピーした直後は、HDDとSSDの各パーティションに同じUUIDがついてしまっている。このままだとUUIDを使ってパーティションを特定できなくなる…。どちらかのUUIDを変更したい。

しかし、これが上手く行かない。本来なら、GParted でパーティションを右クリックして「New UUID」を選べば変更できそうなのだけど…。「e2fsck -f を使え」云々のエラーしか出てこない…。どうしたもんか…。

Linuxは、/etc/fstab というファイルで、どのパーティションをどのディレクトリにマウントするか指定できるけど。その際、UUIDではなくて、ラベル(LABEL)を使うこともできるらしい。

今回、重複したUUIDが存在していてパーティションの特定ができない状態になっているし、どう考えてもラベルのほうが人間には分かりやすいので、そのような指定に修正することにした。

GParted で、各パーティションにラベルを設定する。右クリックして「Label File System」と書かれた項目を選べば、ラベル名を入力するダイアログが開く。

今回は以下のような指定にした。

• / にするパーティション : ROOT
• /home にするパーティション : HOME
• linux-swap にするパーティション : SWAP

SSD (/dev/sdc) 内の、/etc/fstab が入ってるパーティション(/dev/sdc1)を一時的にマウントして、/etc/fstab を修正できるようにする。

sudo mkdir /mnt/sdc1
sudo mount /dev/sdc1 /mnt/sdc1
cd /mnt/sdc1
cd etc
sudo nano fstab

/etc/fstab を編集。UUID=xxxxx と書かれている部分を、LABEL=ROOT といった感じで書き換えておく。

# /etc/fstab: static file system information.
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
LABEL=ROOT /               ext4    errors=remount-ro 0       1
LABEL=HOME /home           ext4    defaults        0       2
LABEL=SWAP none            swap    sw              0       0

SSDにgrubをインストール。以下を参考にして作業させてもらった。

_HDDからSSDへの換装作業ログ
_UbuntuのHDD 2TBからSSD 512GBへのLarger HDD to Smaller SSD換装を行う
_ubuntu BOOT Grub Restoring 起動 復旧 | 市野メモ

実機をシャットダウン後、電源を入れたら、何故かHDD側から Ubuntu Linux が起動してしまったのだけど。これ幸い(?)と、まだマウントされていないはずのSSDに対してgrubをインストール。

sudo mkdir /mnt/sdc1
sudo mount /dev/sdc1 /mnt/sdc1
sudo mount --bind /dev /mnt/sdc1/dev
sudo mount --bind /dev/pts /mnt/sdc1/dev/pts
sudo mount --bind /proc /mnt/sdc1/proc
sudo mount --bind /sys /mnt/sdc1/sys
  
sudo chroot /mnt/sdc1
sudo grub-install /dev/sdc
sudo grub-install --recheck /dev/sdc
sudo update-grub2
exit

umount /mnt/sdc1/sys
umount /mnt/sdc1/proc
umount /mnt/sdc1/dev/pts
umount /mnt/sdc1/dev
umount /mnt/sdc1

この状態で、シャットダウン。HDDを外してSSDだけにして電源を入れてみたところ、SSD側から起動してくれた。

色々ググってたら、e2fsck -f を何度も試すとUUIDが変更できる状態になるかも、という話を見かけた。

HDDとSSDの両方を繋いだ状態で作業するとどうも上手く行かないので、実機からHDDを取り外して、Windows10 x64 22H2 がインストールされてる別PCで作業してみることにした。USB3.0接続HDDスタンド Logitec LGB-1BSTU3 にHDDを差して、Windows + VMware 上で動かした Ubuntu Linux 22.04 LTS からHDDスタンドにアクセス。ちなみに、VMware利用時、USB機器を「ホストから切断」すれば、そのUSB機器は仮想PC側で利用できるようになる。

HDD (dev/sdb) に対して、e2fsck -f を3回ぐらい試してみた。

$ sudo e2fsck -f /dev/sdb1
e2fsck 1.45.5 (07-Jan-2020)
Pass 1: Checking iノードs, blocks, and sizes
Pass 2: Checking ディレクトリ structure
Pass 3: Checking ディレクトリ connectivity
Pass 4: Checking reference counts
Pass 5: Checking グループ summary information
ROOTOLD: 757242/3842048 files (0.5% non-contiguous), 10278914/15360107 blocks

$ sudo e2fsck -f /dev/sdb1

$ sudo e2fsck -f /dev/sdb1

この状態なら、UUIDの変更ができた。

sudo tune2fs /dev/sdb1 -U random

HDDに対してUUIDの変更をする場合、書き換えには数分ほどかかるっぽい…。

そういえば、本来この手のツールは、SATA接続されている状態を前提にして使うことを、うっかり失念したまま作業してしまった…。USB接続では上手く行かない時があったりするのかもしれない…。どうやら今回は上手く行ったっぽいけど…。

HDD側のUUIDを変更できたので、調子に乗ってSSD側のUUIDまで変更してしまったところ、SSDから Ubuntu Linux を起動できなくなった…。カーネルのロードすらできない。

おそらく、grub にカーネルがある場所をUUIDで指定していたのに、そのUUIDが変わってしまったので、カーネルがあるパーティションを見つけることができず、起動できなくなったのだろう…。

修復には、別途、OSが起動する何かを用意しないといけない。Ubuntu Linux 22.04 LTS が起動するUSBメモリを作成して、そちらで起動して、grub を再インストールした。

余談。USB2.0メモリを使ってこのあたりの作業したらとんでもなく時間がかかった。OSが起動するまで、USBメモリのアクセスLEDがずっとチカチカ。10分以上経過してから、ようやくデスクトップ画面が出てきた…。

SSDから起動するようにしてみたら、"Scanning for BTRFS file system" なるメッセージが表示されたタイミングで、そこから30秒ぐらい待たされる状態になってしまった。

Linux Mint 関係の掲示板で同種の不具合事例を目にした。解決策も書いてあった。

_SOLVED "Scanning for BTRFS file system" during boot - Linux Mint Forums

sudo apt-get purge btrfs-tools
sudo update-initramfs -ukall
sudo apt purge btrfs-progs
sudo update-initramfs -ukall

おそらく、btrfs関連パッケージを削除しつつ、initramfs なるものを作り直しているのだろう…。

HDDからSSDに換装してみたところ、OSのデスクトップ画面が出てくるまで2分かかっていたのが、40秒で出てくるようになった。

たしかに速くはなった。でも、期待していたほど速くもない印象。と言うのも、もしこれが Debian Linux なら、HDDにインストールしてある環境でも1分ぐらいで起動してくれるので…。

Ubuntu Linux は、何故か起動が遅い…。いやまあ、こちらが把握してない色々なサービスが山ほど立ち上がってるとか、サポートしてるハードウェアの種類が多くてハードウェアのチェックで時間がかかってたりするのかなと想像するのだけど。

とは言え、Webブラウザの起動等、明らかにHDD利用時より速くなった気もする。これなら、Webブラウザを起動させようかな、という気分にもなれそう。今までは起動時間が長過ぎて、起動させなきゃならんのか、やだなあ…みたいな気分になっていた…。

以下のページを参考にしながら作業してるのだけど、英文ページなので何が何やら…。

_Lou's Pseudo 3d Page
_How to build a racing game - straight roads | Code inComplete

とりあえず、一直線の道路だけなら処理を書けた。


_road02a.hsp

    ; 疑似3D道路を描画する / Drawing pseudo 3D roads

    #define BGROAD_FILE "bg_road.png"
    #define BG_FILE     "bg_16col.png"
    #define SCR_W       640
    #define SCR_H       360

    ; 同梱ファイル / bundled files
    #pack   BGROAD_FILE
    #pack   BG_FILE
    
    #packopt name "road02a"     ; 生成exeファイル名 / generated exe file name
    #packopt type 0             ; exeファイルの生成を指定 / exe file generate
    #packopt xsize SCR_W
    #packopt ysize SCR_H
    
    onkey goto *jobend
    
    ; ウインドウサイズを取得 / get windows size
    screen 0, SCR_W, SCR_H, 0
    gsel 0
    ; width SCR_W, SCR_H
    dispw = ginfo_winx
    disph = ginfo_winy
    cls 4

    ; 道路画像を読み込み / load road image
    roadimgid = 6
    buffer roadimgid, 1280, 1440
    picload BGROAD_FILE
    roadimgw = ginfo_winx
    roadimgh = ginfo_winy

    ; 背景画像を読み込み / load bg image
    bgimgid = 4
    buffer bgimgid, 1280, 720
    picload BG_FILE
    bgw = ginfo_winx
    bgh = ginfo_winy

    dist = 150.0    ; 画面までの距離 / distance to screen
    
    angle = 0.0
    scroll_z = 0
    camera_x = 0

*mainloop

    ; ESC key to exit
    stick k
    if k & 128 : goto *jobend

    base_y = int(double(disph) * 0.5)
    road_y = 100
    road_x = 300
    h = disph - base_y
    
    camera_x = 0
    ; camera_x = 600.0 * sin(deg2rad(angle * 0.75))

    redraw 0    ; 描画開始 / draw start
    gsel 0
    
    ; 背景(遠景)を描画 / draw BG
    gmode 0
    
    ax = sin(deg2rad(double(angle) * 0.25)) * ((bgw - dispw) / 2)
    
    bg_x = (bgw / 2 - (dispw / 2)) + ax
    bg_y = bgh / 2 - base_y
    pos 0,0
    gcopy bgimgid, bg_x, bg_y, dispw, disph
    ; gradf 0, (disph / 2), dispw, (disph / 2), 1, $449044, $080808

    ; 道路を描画 / draw road
    repeat h
        scrn_y = h - cnt - 1
        if scrn_y = 0 : continue
        
        road_z = road_y * dist / scrn_y
        scrn_x = road_x * dist / road_z
        
        center_x = (camera_x * dist / road_z)
        
        u = center_x + (roadimgw / 2) - (dispw / 2)
        addv = ((roadimgh / 2) * (((road_z + scroll_z) / 32) & $1))
        v = scrn_x + addv
        
        ; 1ラスター分を描画 / drawing 1 raster
        pos 0, scrn_y + base_y
        gcopy roadimgid, u, v, dispw, 1
    loop

    redraw 1    ; 描画終了 / draw end
    
    angle += 1
    scroll_z += 10
    
    await (1000 / 30)
    goto *mainloop

*jobend
    end

使用画像は以下。道路用画像。

_bg_road.png

背景用画像。

_bg_16col.png

画像は、.hsp と同じフォルダ階層に置いておく。

実装する際の考え方を一応メモ。

以下は、横から見た図。


画面上の特定のy座標 = sy に道路が表示されているとして、その位置の道路のz値 = rz を知りたい。

• 画面までの距離 sz は決めておく。
• 画面上のy座標 sy も決めておく。
• 道路の高さ(低さ) ry も決めておく。
• 道路のz値 rz だけが分からない。

sz,sy で作られる三角形と、rz,ry で作られる三角形は、大きさが違うだけで形は同じ(相似)なので、以下の式が成り立つ。

sz : sy = rz : ry
sy * rz = sz * ry
rz = ry * sz / sy

これで、画面上のy座標 sy に表示されている道路のz値、rz を求めることができた。

更に、その位置に表示されている道路の見た目の幅(片方の幅)を知りたい。上から見た図で考える。

• 画面までの距離 sz は決めておく。
• 道路の実際の幅 rx も決めておく。
• 道路のz値 rz は先ほど求めることができた。
• 画面上の道路の見た目の幅 sx だけが分からない。

sz,sx で作られる三角形と、rz,rx で作られる三角形は、大きさが違うだけで形は同じ(相似)なので、以下の式が成り立つ。

sz : sx = rz : rx
sx * rz = sz * rx
sx = rx * sz / rz

これで、画面上のy座標 sy に表示されている、道路の見た目の幅、sx を求めることができた。

道路の見た目の幅が分かったので、事前に用意した道路用の画像内から、合致する1ラインを持ってきて画面に描画する。


上記の画像は45度の角度で道路の幅が広がっていくように描いたので…。例えば道路の見た目上の幅が 120 なら、y = 120 のあたりの1ラインを使って画面に描画してやればいい。

更に、奥から手前に向かって、白線が点線になってるように、かつ、道路や地面の色が縞々になるように描画したい。

道路のz値が得られているので、そのz値を元にして 0 か 1 かを決めて…。

• 0 なら白線のある画像側を ―― 上記の画像であれば上半分側を使って描画。
• 1 なら白線のない画像側を ―― 上記の画像であれば下半分側を使って描画。

これで、白線は点線になるし、道路や地面の色も縞々になる。

その際、道路のz値に、別途スクロール値を加算して 0 or 1 を決めてやれば、道路が奥から手前に向かってスクロールしてるように見えるはず。

ここまでの処理を、画面の下半分程度、ループ処理で描画してやれば、疑似3D道路が描画できるはず。

余談。昔のゲーム機ならパレット書き換えができただろうから、水平帰線割り込みを使って、水平帰線期間内に道路用パレットの一部の値(白線、道路、地面の3色)を書き換えてやれば、わざわざ似たような画像を用意しなくても、点線状の白線や、縞々模様を実現できたのではないかなと想像するのだけど、実際はどうだったんだろう。

昔のゲーム機は、基本的には事前に用意した画像を画面に表示することしかできなかったので、前述のように道路用画像を別途用意しておかなければいけなかったと思うのだけど。

今時のハードウェアは、というかPCは、えてしてフレームバッファを持っているので、点だの、線だの、矩形だのをその都度描画することができるなと。だったら、この程度のシンプルな形状であれば毎回プログラムで計算して描いちゃってもいいんじゃないかと思えてきた。

そんなわけで、道路用の画像を使わない版も書いてみた。


_road02b.hsp

    ; 疑似3D道路を描画する / Drawing pseudo 3D roads
    ; 道路画像を使わずにプログラムで描画する版

    #define BG_FILE     "bg_16col.png"
    #define SCR_W       640
    #define SCR_H       360

    ; 同梱ファイル / bundled files
    #pack   BG_FILE
    
    #packopt name "road02b"     ; exe filename
    #packopt type 0             ; generate ".exe"
    #packopt xsize SCR_W
    #packopt ysize SCR_H
    
    onkey goto *jobend
    
    ; get windows size
    screen 0, SCR_W, SCR_H, 0
    gsel 0
    ; width SCR_W, SCR_H
    dispw = ginfo_winx
    disph = ginfo_winy
    cls 4

    ; load bg image
    bgimgid = 4
    buffer bgimgid, 1280, 720
    picload BG_FILE
    bgw = ginfo_winx
    bgh = ginfo_winy

    dist = 150.0    ; 画面までの距離 / distance to screen
    
    angle = 0.0
    scroll_z = 0
    camera_x = 0

*mainloop

    ; ESC key to exit
    stick k
    if k & 128 : goto *jobend

    base_y = int(double(disph) * 0.5)
    road_y = 100
    road_x = 300
    h = disph - base_y

    camera_x = 0
    ; camera_x = 600.0 * sin(deg2rad(angle * 0.75))
    
    redraw 0    ; 描画開始 / draw start
    gsel 0
    
    ; 背景(遠景)を描画 / draw BG
    gmode 0
    
    ax = sin(deg2rad(double(angle) * 0.25)) * ((bgw - dispw) / 2)
    
    bg_x = (bgw / 2 - (dispw / 2)) + ax
    bg_y = bgh / 2 - base_y
    pos 0,0
    gcopy bgimgid, bg_x, bg_y, dispw, disph
    ; gradf 0, (disph / 2), dispw, (disph / 2), 1, $449044, $080808

    ; 道路を描画 / draw road
    repeat h
        scrn_y = h - cnt - 1
        if scrn_y = 0 : continue
        
        road_z = road_y * dist / scrn_y
        scrn_x = road_x * dist / road_z
        
        center_x = camera_x * dist / road_z
        
        addv = (((road_z + scroll_z) / 32) & $1)
        
        ; 1ラスター分を描画 / draw 1 raster
        road_w = scrn_x * 2
        draw_x = -scrn_x + (dispw / 2) + center_x
        draw_y = scrn_y + base_y
        kind = addv
        gosub *draw_raster_road
    loop

    redraw 1    ; 描画終了 / draw end
    
    angle += 1
    scroll_z += 10
    
    await (1000 / 30)
    goto *mainloop

*draw_raster_road
    ; 道路を1ラスター分描画
    ;
    ; draw_x, draw_y : draw x, y
    ; road_w : road width
    ; kind : 0 or 1
    ; dispw : screen width

    ; draw ground
    if kind = 0 {
        ; color R, G, B
        color 114, 185, 66
    } else {
        color 22, 174, 63
    }
    ; boxf x0, y0, x1, y1
    boxf 0, draw_y, dispw, draw_y

    ; draw road base
    if kind = 0 {
        color 133, 149, 158
    } else {
        color 149, 168, 179
    }
    boxf draw_x, draw_y, draw_x + road_w, draw_y

    ; draw white line
    lw = double(road_w) * 48.0 / 2048.0     ; white line width
    
    if kind = 0 {
        color 255, 255, 255
        
        lx = double(draw_x)
        boxf lx, draw_y, lx + lw, draw_y
        
        lx = lx + road_w - lw
        boxf lx, draw_y, lx + lw, draw_y
        
        lx = double(draw_x) + (double(road_w) * 0.5) - (lw * 0.5)
        boxf lx, draw_y, lx + lw, draw_y
        
        lx = double(draw_x) + double(road_w) * 0.25 - (lw * 0.5)
        boxf lx, draw_y, lx + lw, draw_y
        
        lx = double(draw_x) + double(road_w) * 0.75 - (lw * 0.5)
        boxf lx, draw_y, lx + lw, draw_y
    } else {
        color 228, 236, 252
        
        lx = double(draw_x) + lw
        boxf lx, draw_y, lx + lw, draw_y
        
        lx = double(draw_x) + road_w - (lw * 2)
        boxf lx, draw_y, lx + lw, draw_y
    }
    return

*jobend
    end

見た目では違いが分からないな…。

HSP は、line で線を描画、boxf で矩形塗り潰しができるけど、1ラインだけ描画するならどちらが速いのか気になったので少し試してみた。環境は Windows10 x64 22H2 + HSP 3.6。

_bench.hsp

    ; line と boxf のベンチマーク

    #include "d3m.hsp"
    
    #define SCR_W       640
    #define SCR_H       360

    #packopt name "bench"       ; 生成ファイル名
    #packopt type 0             ; .exe生成を指定
    #packopt xsize SCR_W
    #packopt ysize SCR_H
    
    onkey goto *jobend
    
    ; get windows size
    screen 0, SCR_W, SCR_H, 0
    gsel 0
    ; width SCR_W, SCR_H
    dispw = ginfo_winx
    disph = ginfo_winy
    cls 4

*mainloop
    ; ESC key to exit
    stick k
    if k & 128 : goto *jobend
    
    redraw 0    ; 描画開始
    gsel 0
    gmode 0

    lp = 1000
    
    starttime = d3timer()
    repeat lp
        repeat (disph - 1)
            color 16, 32, 64
            ; line x1, y1, x0, y0
            line dispw, cnt, 0, cnt
            
            ; pos 0, cnt
            ; line dispw, cnt
        loop
    loop
    tm1 = d3timer() - starttime

    starttime = d3timer()
    repeat lp
        repeat (disph - 1)
            color 16, 32, 64
            ; boxf x0, y0, x1, y1
            boxf 0, cnt, dispw, cnt
        loop
    loop
    tm2 = d3timer() - starttime

    color 255, 255, 255
    pos 8, 8
    mes "line : " + tm1
    pos 8, 32
    mes "boxf : " + tm2
    
    redraw 1    ; 描画終了
    
    await (1000 / 60)
    goto *mainloop

*jobend
    end

微妙に boxf のほうが速いようだなと…。まあ、劇的に違いが出るわけでもないので、今回はどっちを使っても良さそうだけど。

ただ、ループ内の color 命令をコメントアウトすると、line のほうが速くなったりもした。なんでだろ。

たしかに、「風立ちぬ」の主人公のキャラ属性を考えると、庵野監督の起用は、ほぼ本物を起用した状態に近いだろうなと。モノづくりのことを優先しちゃって、それ以外はおろそかになりがちな、どこか求道者のような人種。めちゃくちゃリアル。もし、ひたすらリアルを追求することで価値が産まれるのであれば、庵野監督の起用は大正解だし、これ以上の理想的な起用は無い ―― と自分も思ってしまうのですが。

でも、アニメにおいて、本物を連れてくればそれでいいのか？ とにかくリアルにしちゃえばそれで良いのでしょうか？ という疑問も湧くわけで…。

一体何のためにリアルにするのか？ それについては、人によって様々な理由があるのだろうけど…。これは想像だけど、観客にすんなりと作品世界に没入してもらうための一手段、としてのリアルの追及があるんじゃないかと。

ところが、本物を連れてきたことによって、観客が真っ先にそこで引っ掛かりを感じてしまって、作品世界にするりと没入する際の大きな障害になってしまったとしたら…。その場合、果たしてその起用は正しいと言えるのだろうか。

一体何のためにリアルを追求していたのか。目的を忘れてないか。リアルにすることは、おそらく一手段にしか過ぎなかったはず。だけど、リアルにすることがいつのまにやら目的になってないか。

それとも、元々、リアルにすることの意味なんて考えたことがなかったのだろうか…。実は、宮崎駿という映像作家は、高畑勲監督からとにかくリアルにリアルにと要求され続けて、リアルならそれでいいのだと思考停止してしまったのではないか…。

まあ、そんなわけないだろうとは思うのだけど。きっと1回ぐらいは、「パクさんってすぐに『リアルに』って言い出すけど、なんでリアルにしなきゃいけないの？」と素朴な疑問をぶつけたことがあるのでは。そして高畑監督のことだから、ぐうの音も出ない理由を返してきたのではないか。だから、リアルを追求する意味を毎回ちゃんと考えながらアニメを作ってきたはず…。

でも、だとすると、庵野監督を起用した理由が分からない。たしかにリアルだし本物相当だけど。本物を連れてくることより優先されること、実現しなきゃいけないことがあったような気がするわけで…。

アニメに詳しくないお婆ちゃんに、「声が酷いね」という感想を持ってもらいたくて、そのアニメを作ったわけじゃないだろうと…。

本来、アニメというものは、人の手で描かれた絵の世界なのだから、実写と比べてしまったら、最初から終わりまで偽物の映像と捉えることもできるよなと…。なのに、その偽物に魅了されてしまう人達が出てくるのは何故だろう。

一つは、偽物なのに、本物より本物らしく感じる瞬間が多々出現するから、ではないかと想像するわけで。所謂デフォルメってヤツだけど…。本物の特徴を抽出して、より強調して見せることで、本物以上のそれらしさを感じてしまうことができる。それがアニメの持つ魅力の一つ、ではなかったかと。

それを考えると、「風立ちぬ」の主人公の声も、本来ならデフォルメが必要だったのかなー、と。本物よりも本物らしく演技してくれる役者さんをどうにかして探し出すのが正解だったのでは…。庵野監督のような本物を連れてきてハイ終わり、てのは日和った結果に思えるわけで。そこにはデフォルメが一切無いわけだから…。

まあ、「映像が偽物なんだからせめて声は本物を」という考え方もありそうだけど、「映像が偽物なんだから声も偽物で統一しないとチグハグになるでしょ。だけどその代わり、本物より本物らしい偽物を揃えてみせますぞ」という考え方もアリかも、という気もする。偽物には偽物の矜持があるんじゃい、ポンと本物持ってきて悦に入るとは偽物作りの名折れじゃ、みたいな。

もっとも…。宮崎駿監督はアニメーター出身の監督だから、自身のリソースを注ぐとしたらそれは自ずと作画面に集中してしまうだろうし、声優さんや役者さんを選ぶ時期になるともうヘロヘロになっていてなんでもいいや状態に、てな可能性も高そうだけど…。鈴木Pもおじさん達の相手をしまくって一緒にヘロヘロになってそうだし…。

本当は、監督を名乗るからには、声優・役者を、根気強く、辛抱強く、最後まで選び抜くためのパワーをずっと温存しておかないといかんのだろうな…。コンテや作画で全部消耗するんじゃなくて…。もしくは、自分の代わりにコイツに選ばせておけば間違いない、そっち方面は全部任せた、俺はこっちに集中する、と思えるスタッフを用意しておくとか…。

まあ、そんなアレコレをぼんやりとなんとなく考えてしまったのでメモ。思考メモです。

「風立ちぬ」を最後まで見たお袋さんに改めて感想を聞いてみたら、「話は大体分かった。飛行機を設計する人の話でしょ」「最後まで見てたら、声もまあ慣れた」とは言ってました。良かった。「声が気になって話が分からなかった」と言い出したらどうしようとヒヤヒヤしてました。そこまでアレではなかったようで。良かった良かった。ただ、「ずっと盛り上がらないままだったのが、ちょっと」とも…。

しかし直後に、「『風立ちぬ』を見る前に『ローマの休日』を見てたから、それと比べちゃうと全然盛り上がらなくて」と言い出して。

うわあ。それはダメだぁ。たぶん、宮崎駿監督も、「『ローマの休日』見てから『風立ちぬ』を見るのはやめろ！」と叫ぶんじゃないかな…。その流れはあかんわ…。「ローマの休日」には、そりゃ勝てませんわ…。どっとはらい。

aptでインストール。

sudo apt install gerbera

/etc/gerbera/config.xml が設定ファイル。バックアップを取ってから修正する。

sudo cp /etc/gerbera/config.xml /etc/gerbera/config.xml.bak
sudo vi /etc/gerbera/config.xml

以下のような感じで修正。

$ diff -U 1 /etc/gerbera/config.xml.bak /etc/gerbera/config.xml

@@ -7,5 +7,5 @@
   <server>
-    <ui enabled="no" show-tooltips="yes">
+    <ui enabled="yes" show-tooltips="yes">
       <accounts enabled="no" session-timeout="30">
-        <account user="gerbera" password="gerbera"/>
+        <account user="gerbera" password="gerberahogefugapswd"/>
       </accounts>
@@ -36,3 +36,3 @@
     </storage>
-    <protocolInfo extend="no"/><!-- For PS3 support change to "yes" -->
+    <protocolInfo extend="yes"/><!-- For PS3 support change to "yes" -->
     <!--
@@ -54,3 +54,3 @@
     <extended-runtime-options>
-      <ffmpegthumbnailer enabled="no">
+      <ffmpegthumbnailer enabled="yes">
         <thumbnail-size>128</thumbnail-size>
@@ -69,2 +69,4 @@
   <import hidden-files="no">
+    <filesystem-charset>UTF-8</filesystem-charset>
+    <metadata-charset>CP932</metadata-charset>
     <scripting script-charset="UTF-8">
@@ -78,2 +80,10 @@
       <extension-mimetype ignore-unknown="no">
+        <map from="jpg" to="image/jpeg"/>
+        <map from="jpeg" to="image/jpeg"/>
+        <map from="gif" to="image/gif"/>
+        <map from="png" to="image/png"/>
+        <map from="m4v" to="video/mp4"/>
+        <map from="mp4" to="video/mp4"/>
+        <map from="mpg" to="video/mpeg"/>
+        <map from="mpeg" to="video/mpeg"/>
         <map from="mp3" to="audio/mpeg"/>
@@ -98,3 +108,3 @@
         <!-- Uncomment the line below for PS3 divx support -->
-        <!-- <map from="avi" to="video/divx"/> -->
+        <map from="avi" to="video/divx"/>
         <!-- Uncomment the line below for D-Link DSM / ZyXEL DMA-1000 -->
@@ -137,3 +147,3 @@
   </import>
-  <transcoding enabled="no">
+  <transcoding enabled="yes">
     <mimetype-profile-mappings>
@@ -143,2 +153,6 @@
       <transcode mimetype="audio/x-flac" using="oggflac2raw"/>
+      <transcode mimetype="video/avi" using="video-thumbnail"/>
+      <transcode mimetype="video/divx" using="video-thumbnail"/>
+      <transcode mimetype="video/mpeg" using="video-thumbnail"/>
+      <transcode mimetype="video/x-ms-wmv" using="video-thumbnail"/>
     </mimetype-profile-mappings>
@@ -161,2 +175,10 @@
       </profile>
+      <profile name="video-thumbnail" enabled="yes" type="external">
+        <mimetype>image/jpeg</mimetype>
+        <accept-url>yes</accept-url>
+        <thumbnail>yes</thumbnail>
+        <resolution>128x128</resolution>
+        <agent command="/usr/bin/ffmpegthumbnailer" arguments="-i %in -o %out -s 128 -t 2"/>
+        <buffer size="524288" chunk-size="512" fill-size="1024"/>
+      </profile>
     </profiles>

gerbera を再起動。

sudo service gerbera restart

状態を確認。

sudo service gerbera status

Webブラウザで管理画面にアクセスして、どのメディアファイルを配信するかを指定できるらしい。

Windows10 + 適当なブラウザで、以下のURLにアクセス。

http://ホスト名:49152/

管理画面が表示された。

左上の Filesystem をクリックして、配信したいファイルの右側のプラスマークをクリックすれば登録される。Databse をクリックすれば、先ほど選んだファイルが登録されていることが分かる。

動作確認。Windows10上で PowerDVD 12 を起動した。「ホームメディア(DLNA)」を選ぶと、gerbera が追加されていて、登録した jpeg や mpg を表示・再生することができた。

Drawgraphic 2 と Drawgraphic 3 Pro の両方をインストールして、出力結果の違いを調べてみようとしたのだけれど。どうやら共存はできないようで…。

Drawgraphic 3 Pro をアンインストール後、Drawgraphic 2 をインストールして、その後、Drawgraphic 3 Pro をインストールしようとしたら、「既に Drawgraphic がインストールされてるぞ。アンインストールしてから作業しろ」と言ってきたわけで。

Drawgraphic 3 Pro が旧版と同様の出力もできるなら、共存させようなんて思わないわけですが…。ちゃんとした製品を作ってないのに、こういうところはちゃんとしちゃうあたり、なんだかちょっとイラッとしたり。

Drawgraphic 2 のインストールフォルダを別の場所にコピーしたら動かないかと試してみたけど、実行したら「正常にインストールされていません」と表示されてしまう。おそらくアンインストールする際に、動作に必要なレジストリ情報も削除しているのだろう…。

もっとも、もはや Drawgraphic 2 は販売されてないので、仮に Drawgraphic 2 のほうがまともな処理をしていると分かったとしても、「Drawgraphic 3 よりも Drawgraphic 2 を使おう」と言うわけにもいかないわけで…。

Drawgraphic 3 Pro から出力した emf を、Inkscape で開いて眺めていたのだけど、どうも妙な気配がする…。

Drawgraphic 2 で出力した emf は、D&Dしてもそれっぽく表示されたけど。Drawgraphic 3 で出力したemfをD&Dすると、各図形が、本来表示される範囲の左上のあたりに小さく表示されてしまう。何故。

更に、本来表示される範囲の右下のあたりに、線幅0、サイズが極小の塗りが存在していて。その塗りがあることで、本来の表示範囲がかろうじて分かる状態になってるのだけど。コレ、一体何だろう…。何のために、こんな図形がこんなところに…。いや、そもそもどうして、現行版の出力emfは、旧版と違うサイズになってしまうのだろう。

各図形の線や塗りも、なんだか奇妙。

通常、線が閉じた図形があって、その中が塗られているなら…。面の色、線の色、線幅を持つ図形がそこにある、と想像するのだけど。

Drawgraphic が出力した図形は、太い線があったら、それは線幅0の、線の形のように見える面だったりして。そこ、線じゃないのかよ、面を線のように見せてるのかよ、てな驚きが。また、線の端も、そういう形の端に見えるような面が置いてあったりして。

また、Drawgraphic 3 の出力 emf は、面の輪郭と重なるように、面と同じ色が指定されてる細い線もうっすらと存在していて…。Drawgraphic 2 の出力結果には、そんな線は無いのだけど。


例えば上の画像では…。左側の1つの四角は、面の色、線の色、線幅を持った1つの四角で表現できそうなものだけど。Drawgraphic 3 の出力emf は、赤い面が1つ、黒い面が8つ、非常に細い黒い線が8つ、非常に細い赤い線が1つで構成されてるようで…。どうしてそんなに必要になるのか…。

このあたり、wmf や emf の制限だったりするのかな…。それとも Inkscape が、こういう状態に分解してるだけだろうか…。でも Drawgraphic 2 の出力emfには、こんな細い線は無いわけで。

これは外してるかもしれないけど…。もしかして Drawgraphic 3 は、アンチエイリアスに対応する際、レンダリング処理には手を入れずに…。図形の生成時、アンチエイリアスがかかってるように見える、細くて薄い色の線を各線に別途追加して、対応したように見せかけているのではないか、てな不安が。

ただ、そういうやり方だとすると、環境設定のアンチエイリアス有効無効という項目の存在が謎で。図形を生成する際、既にアンチエイリアスっぽくなってるなら、後から表示設定でアンチエイリアスの有効無効を切り替えることなんてできないだろうと…。

となると、ちゃんとレンダリング処理に手を入れてアンチエイリアスに対応したのかなと。でも、そうだとしたら、このうっすらとした謎の線は、一体何に使っているのか…。謎。

LibreOffice より Apache OpenOffice のほうが wmf や emf への対応状況はマシ、という話を見かけたので、Apache OpenOffice 4.1.5 をインストールして、Drawgraphic 3 の出力emfをD&Dしてみた。

たしかに…。LibreOffice では表示すらされなかった emf も、OpenOffice なら一応表示してくれた。

しかし、曲線を使った emf などは、真っ黒な矩形になってしまった。

つまり LibreOffice のwmf/emf対応は一際よろしくないが、かといって OpenOffice も、Microsoft Office と高い互換性を持ってるわけではない、ということかも。

それはともかく、OpenOffice 上にD&Dしたemfに対して、右クリック → 切り離す、をしてみたところ、Inkscape 上で確認した構成と、ほぼ似た感じの構成になっていた。やはり Drawgraphic 3 の出力emfには、謎の細い線が多々含まれているらしいなと。それが理由で、Drawgraphic 2 の出力emfよりファイルサイズが大きくなるのかもしれない。

ちなみに、角丸矩形を読み込んだら、角丸が、多数の短い直線で構成されていて、なんだかゾッとした…。もしや、wmf や emf は、本来は曲線が存在しないのだろうか…。

Drawgraphic 3 だけを使って印刷物データを作る、といった作業であれば、そこそこ使えるソフトなのかもしれないけど。このソフトで作った何かしらを他のソフトに持っていって、とか考え始めると、なんだか面倒臭いことになってくるなと…。

ベクターデータを出力して、とか考えちゃうからいかんのかな。ソリッドな図形が描かれたビットマップデータを、グリッドを利用してキッチリ作って、そのビットマップデータを他のソフトで、みたいな連携ならまだどうにか…。いや、ソレ、ドローソフトなのかな。

Drawgraphic で作成したベクターデータは、Drawgraphic でしか開けない、というのも痛い…。G.CREW の二の舞になりそう。汎用性のあるベクターデータとして出力できないと、そのソフトが開発終了・販売停止になった時にダメージを受けるわけで…。

そうか。最終結果をビットマップデータとして別途保存しておけばいいのか。いや、ソレ、ドローソフトなのかな。

印刷物の作成目的なら、と思っていたけど、巷のレビューで「ロゴ画像の品質が…」と言われているのを見かけて、自分も確認してみたら、ちょっとビミョーな感じになってきた。

印刷物となれば、ロゴの生成機能が重要になりそうだけど、Drawgraphic のソレは輪郭が汚くて…。以下で、Drawgraphic 3 と LibreOffice Draw のpng出力を比較して見たけれど…。


「i」の丸の部分や、「C」の輪郭、「3」の左上のあたりを眺めると、うーん。同じフォントを使っているのに、どうしてこんなにガタガタしているのか…。

もっとも、「このくらいなら印刷しちゃえばわかんねえよ」「等倍で見れば違いなんてわからん」という意見もありそうだけど。

一応、Drawgraphic 3 Pro と LibreOffice Draw のpng出力結果も置いておくので参考になればと。

_texttest01_drawgraphic3pro.png (986KB)
_texttest02_libreoffice.png (431KB)

ちなみに、Drawgraphic 3 Pro は、環境設定 → 一般 → 曲線、で、精度(DPI)を300に、スムージングを6にしてある状態。曲線で図形を描いた際に、そのあたりが絡んでくるようだけど、ロゴ生成には関係がないのかもしれず。ロゴ生成時のダイアログ内に、別途スムージング設定が用意されてるようだし…。

G.CREW がお亡くなりになってから、低価格なドローソフトは市場にほとんど存在していないので、個人的には、このソフトを、できれば色々褒めたいし、応援もしたいのだけど…。

時々、ソースネクストのキャンペーンで、安く販売されてたりするようだし。先日見た時は 2,480円で売られてた記憶が。定価の4,980円はちょっとどうかと思うけど、キャンペーン時の価格ならお手頃価格と言えるので、そういうソフトは応援したいのですけど…。したいけど…。なかなか厳しい…。

ソースネクスト製品を購入してインストールすると、ソースネクストアップデートというソフトも一緒にインストールされて常駐するのだけど。ウザい…。

「新しい○○が発売されてますよ！」…うん。知ってるから。知ってるけどあえて購入してないんだよ。君、ちょっと黙っててくれないか。

まあ、コントールパネル経由でアンインストールできるから、まだマシだけど。

そういや以前、年配の方から、「ソースネクストの広告がひっきりなしに出てくるのが鬱陶しい。どうにかならないか」と相談された記憶も。もしかして、ソースネクストアップデートは、かつての Microsoft Office のイルカ並みになってないか…。

_pi3dの公式ドキュメント に従って、ウインドウを生成して球を出してみたり。こんな感じに。


一応、ESCキーを押したら終了するようにしてある。じゃないとスクリプトを簡単に終了させられないので。

ソースは以下。

_helloworld.py

u"""
pi3d Hello World.

球を生成して描画するサンプル。
ESCキーで終了する。

Windows10 x64 + Python 2.7.12 32bit + pi3d 2.20
"""
from __future__ import absolute_import
from __future__ import division
from __future__ import print_function
from __future__ import unicode_literals
import pi3d

# ウインドウ生成
display = pi3d.Display.create(w=640, h=480,
                              frames_per_second=60)

# 球を生成
ball = pi3d.Sphere(z=5.0)

# キーボード取得用クラスを生成
keys = pi3d.Keyboard()

# メインループ
while display.loop_running():

    # 球を描画
    ball.draw()

    if keys.read() == 27:
        # ESCキーが押されたらループを抜けて終了
        keys.close()
        display.destroy()
        break

python helloworld.py で実行できる。

Windows10 x64上だけではなく、以下の環境でも同じように表示された。

• Ubuntu 16.04 + Python 2.7.12
• Raspberry Pi3 + raspbian stretch + Python 2.7.13

pi3d を使うときは、import pi3d を最初のあたりに書いて、「このスクリプトはpi3dを使うよ」とPythonに教えてやる。

上記スクリプトの最初のほうに、from __future__ import なんたら、みたいな行が列挙されてるけど。これは、Python 2.7を使いつつも Python 3.x っぽく動かすための指定らしい。コレを入れとけば Python 2.7 と Python 3.x の両方で動くスクリプトが書けるのだろう。たぶん。Pythonってよく知らないから自信ないけど。

display = pi3d.Display.create(w=640, h=480, frames_per_second=60) で、ウインドウを生成。w,h が、ウインドウ横幅と縦幅の指定。frames_per_second で最大フレームレートを指定。この場合、640x480ドット、60FPSのウインドウを作れ、と指定してる。

フレームレートを指定しないと、CPUが全力でループを回す状態になって、その分、他の処理がおろそかになるのだとか。バックグラウンドで音楽を鳴らしつつ、みたいなことをしたいときはフレームレートを指定したほうがいいよ、とドキュメントには書いてあった。

ball = pi3d.Sphere(z=5.0) で、球を生成。pi3d.Sphere(x=0.0, y=0.0, z=0.0) といった感じの指定で、位置を設定できるらしい。

if keys.read() == 27: は、ESCキーが押されたかチェックしてる。…いきなり直接数値を書いて比較してるあたりがなんだか引っ掛かるなあ。

そのままいきなりスクリプトを終了させると、キー入力関係の不具合が発生する時があるらしいので、keys.close() を呼んでから終了したほうがいいかも、みたいなことが公式ドキュメントに書いてあった。pi3d_demos のサンプルスクリプト群も大体そんな感じの記述になってるっぽい。

display.destroy() でウインドウを破棄、してるのかな。たぶん。

静止画ではつまらないので、球を動かしてみたい。sinカーブで位置を変えてみる。


これも、Windows10 x64、Ubuntu 16.04、Raspberry Pi3上で同じように動いた。

ソースは以下。

_helloworld2.py

u"""
pi3d Hello World.

球を生成して描画するサンプル。位置を動かしてみる。
ESCキーで終了する。

Windows10 x64 + Python 2.7.12 32bit + pi3d 2.20
"""

from __future__ import absolute_import
from __future__ import division
from __future__ import print_function
from __future__ import unicode_literals
import math
import pi3d

# ウインドウ生成
display = pi3d.Display.create(w=640, h=480,
                              frames_per_second=60)

x, y, z = 0.0, 0.0, 15.0
x_ang, y_ang, z_ang = 0.0, 0.0, 0.0

# 球を生成
ball = pi3d.Sphere(x=x, y=y, z=z)

# キーボード取得用クラスを生成
keys = pi3d.Keyboard()

# メインループ
while display.loop_running():

    # sinカーブで位置を動かす
    x_ang += 3.0
    y_ang += 4.5
    z_ang += 0.8
    x = 5.0 * math.sin(math.radians(x_ang))
    y = 3.0 * math.sin(math.radians(y_ang))
    z = 7.0 * math.sin(math.radians(z_ang)) + 15.0

    # 球の位置を設定
    ball.position(x, y, z)

    # 球を描画
    ball.draw()

    if keys.read() == 27:
        # ESCキーが押されたらループを抜けて終了
        keys.close()
        display.destroy()
        break

python helloworld2.py で実行できる。

どうも時々 VNC viewer が落ちてしまう。もしかして、Ubuntu側で TigerVNC を使ってるのがよろしくないのかな。公式リポジトリに入ってないパッケージだし、ちょっと不安定だったりする可能性がありそうな。や、どこが原因で落ちてるのか分からないので、濡れ衣かもしれんけど。

とりあえず TigerVNC をアンインストールして、代わりに vnc4server をインストールしてみたり。後者で安定動作してくれたらいいのだけど、さて。

sudo aptitude purge tigervncserver
sudo aptitude install vnc4server

元々 TigerVNC をインストールしたのは、x0vncserver を試してみたかったから、だけど。vnc4server にも、x0vnc4server が入っていて、インストールすると x0vncserver として割り当ててくれるので、x0vncserver を使いたくなった時も困ったりはしないだろう…。

sudo aptitude install winbind libnss-winbind

sudo vi /etc/nsswitch.conf

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
↓
hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname mdns4 wins

sudo service winbind restart

Ubuntu 16.04側から、Windows10 x64上の共有フォルダにアクセスしたい。cifs-utils なるパッケージをインストールすればマウントできるらしい。試してみたり。

sudo aptitude install cifs-utils
sudo mkdir /mnt/windows

以下でマウント。パスワード指定は省略可能で、その場合コマンドを実行した段階で尋ねてくるのだとか。

sudo mount -t cifs -o username=Windowsユーザ名,password=Windowsパスワード //Windowsホスト名/共有フォルダ名 /mnt/windows
or
sudo mount.cifs -o username=Windowsユーザー名 //Windowsホスト名/共有フォルダ名 /mnt/windows

これで実際にマウントできた。

上記の場合、所有者が root:root になる。変更した状態でマウントしたいなら、uidとgidを指定すればいいらしい。

sudo mount.cifs -o username=Windowsユーザー名,uid=ubuntu,gid=ubuntu //Windowsホスト名/共有フォルダ名 /mnt/windows

以下、参考ページ。

_Ubuntu から Windows の共有フォルダをマウントして利用する - Qiita
_【cifs-1】UbuntuからWindowsの共有フォルダを手動マウントする | インフラエンジニアのメモ

今までの日記ページ(*.hnf)に対してgrepをかけて、Dropboxへリンクを張ってる行を抽出。htmlへのリンクについては、htmlその他を自宅サーバにも置き直して、そちらへのリンクを追記しておいた。

zip や jpg や mp3 や ogg については、そのままでもいいのだろうか…。

.
│  Sample2.hxproj
│  Sample2.xml
│  
└─source
    │  Gbl.hx
    │  Main.hx
    │  MenuState.hx
    │  Player.hx
    │  ProjectClass.hx
    │  Reg.hx
    │  Stage1.hx
    │  
    └─org              <---- ココ
        └─flixel
            └─tmx
                    TmxLayer.hx
                    TmxMap.hx
                    TmxObject.hx
                    TmxObjectGroup.hx
                    TmxPropertySet.hx
                    TmxTileSet.hx

source/org/flixel/tmx/TmxTileSet.hx:87: lines 87-95 : Please use set_image to name your property access method
source/org/flixel/tmx/TmxTileSet.hx:83: lines 83-86 : Please use get_image to name your property access method

Tiled Map Editor は、json でエクスポートもできるので、それでどうにかすることにした。.tmx を直接読むのは諦める。

以下、Haxe 3 L OpenFL 用のソース。

application.xml に、以下の指定を追加。

    <assets path="assets/maps" rename="maps" />
    <assets path="assets/maps" include="*.tmx" type="text" />
    <assets path="assets/maps" include="*.csv" type="text" />
    <assets path="assets/maps" include="*.json" type="text" />

• assets/maps/ フォルダを、プログラム中からは "maps/" として扱えるようにリネーム扱いにしてる。
• .tmx、.csv、.json ファイルは、テキストファイルとして扱え、と指定をしている。

Tiled が出力した json の文字列の中から、必要なところだけ取り出すためのクラスを作成。 src/ フォルダの中に、TmxJson.hx というファイル名で作成した。

TmxJson.hx

package ;

import haxe.Json;

/**
 * Tiled Map Editor で export した json を解析
 * @author mieki256
 */
class TmxJson {

    public var width:Int;
    public var height:Int;
    public var bgcolor:Int;
    public var layerTileData:Map<String,String>;
    public var layerWidth:Map<String,Int>;
    public var layerHeight:Map<String,Int>;
    
    public function new(jsondata:String) {
        // jsonを解析
        var d = Json.parse(jsondata);
        
        // タイルの縦横個数を取得
        width = Std.parseInt(d.width);
        height = Std.parseInt(d.height);
        
        // 背景色を取得
        var s:String = untyped d.backgroundcolor;
        s = "0x" + StringTools.replace(s, "#", "");
        bgcolor = Std.parseInt(s);
        
        layerTileData = new Map();
        layerWidth = new Map();
        layerHeight = new Map();

        // 各レイヤーのタイル並び情報を取得
        var layernum:Int = Std.parseInt(d.layers.length);
        for (i in 0...layernum) {
            var name:String = untyped d.layers[i].name;
            
            // レイヤーの縦横タイル個数を取得
            var w:Int = Std.parseInt(untyped d.layers[i].width);
            var h:Int = Std.parseInt(untyped d.layers[i].height);
            layerWidth.set(name, w);
            layerHeight.set(name, w);
            
            // タイル並びを整形
            var tiledata:Array<Int> = untyped d.layers[i].data;
            var count = 0;
            var layer:String = "";
            for (y in 0...h) {
                var row = new Array();
                for (x in 0...w) {
                    var c:Int = Std.parseInt(untyped tiledata[count]);
                    
                    // Tiledのデータは、
                    // 0番が透明、1番からチップ番号が始まるので、
                    // 若干番号を調整する。
                    if ( c > 0 ) c -= 1;
                    
                    row.push(c);
                    count++;
                }
                layer += row.join(",") + "\n";
            }
            layerTileData.set(name, layer);
        }
    }

    // 与えられたレイヤー名のタイル並びを返す
    public function getLayer(layerName:String):String {
        return layerTileData.get(layerName);
    }
    
}

使いたいファイルの中に、記述を追加。

import org.flixel.FlxTilemap;
import flash.display.BitmapData;
import flash.Lib;
import openfl.Assets;
import TmxJson;

        // BGを生成
        var mapimg:BitmapData = Assets.getBitmapData("maps/area01_level_tiles.png");
        var mapdata:String = Assets.getText("maps/level1.json");
        var mapcsv:TmxJson = new TmxJson(mapdata);

        bg_a = new FlxTilemap();
        bg_a.loadMap(mapcsv.getLayer("layer1"), mapimg, 16, 16, FlxTilemap.OFF);
        bg_a.solid = false; // アタリなしを指定
        add(bg_a);

• Assets.getText("maps/level1.json"); で、jsonファイルの中身を文字列として取得している。
• new TmxJson(mapdata); で、json文字列の中から、マップレイヤーのタイルの並びデータ等を解析・記録。
• mapcsv.getLayer("layer1") で、"layer1" という名前をつけたレイヤーの、タイルの並びデータを csv的な文字列の形で得られる。

ハマるかと思ったけど、そうでもなかった。結構あっさりBGが表示された。

コレ、DXRuby あたりも、同じやり方でできそうだなと思えてきたり。Ruby にも、json を扱うための何かがあったような気もするし。とりあえず、マップデータを json で出力できれば、後はどうにでもなりそうな。

上の TmxJson.hx はバグってることが分かった。

• Tiled上で背景色を指定していないデータを作った場合、TmxJson.hx を通すと止まってしまう。bgcolor 関係の部分は全部削除しといたほうが良さそう。どうせ背景色なんか使わないだろうし…。
• Std.parseInt() を使って、文字列を数値化しようとしている部分は、html5 で出力した場合におかしな動作になる。

修正版は、 _2013/09/10の日記 に書いときます。

MMDで作った動画を、アルファチャンネルつき連番pngにしたい。以下、その手順。

まず、MMDでAVI出力する際に、RGBA が使えるコーデックを選択する。Ut Video (RGBA) とか。

そして、出力したAVIを、AviUtl + _PNGエクスポータープラグイン ver.001 で開いて、ファイル → エクスポート → RGBA(32bit) → 連番PNG、を選択。これで、アルファチャンネルつき連番pngが得られた。

ちなみに、AviUtl に標準(?)でついている連番BMP出力も、アルファチャンネルつきのbmpを出力できるらしいのだけど。アルファチャンネルつきのbmpは、扱えるCGソフトがあまり多くないので、まだ png で出力したほうがいいかなと個人的には思っていたり。…まあ、アルファチャンネルつきbmpも、GIMPなら開けるらしいけど。

ただ、この、PNGエクスポータープラグインは、フィルタ等が一切かけられず。もっとも、フィルタをかけると、内部でアルファチャンネルが消滅してしまいそうな予感もあるので、仕方ないのかも。ただ、AviUtlに放り込む前に、サイズや色調やトリミング等を詰めておかないといかんのがちょっと面倒だなと。

世代交代する漫画は、ほとんどソレなのかもしれないけど。

• キン肉マン。そのまま二世が登場している。
• 聖闘士星矢。あくまでTV版だけかもしれないけど。紫龍以外は子供が居ないらしいのが、なんだか寂しい。
• 北斗の拳。子供と言うか、世代交代かしら。…いや、一応子供も出ていたっけ？
• ドラゴンボール。または、Drスランプ。
• JoJoシリーズ。もう何世代目になってるのか知らないけど。

最初の世代が活躍し続けている長期連載漫画も、子供を出したら、更に長期化できるのだろうか。

例えば、こち亀で世代交代をしたらどうなるんだろう…？ いや、漫画の内容からして、あまり変化は無いよな。たぶん。

昨今、ウルトラセブンの息子が頑張ってるぐらいだから、仮面ライダーにおいても子供が登場するのは商売上おかしくなさそうだなと。

しかし、改造人間である本郷猛には、生殖機能が残っているのかどうか。仮に失われているとすれば、どうやって子供を作ればいいのやら。

• 改造人間にされる前に、とある女性と深い関係になっていたことにする。しかし、本郷猛は結婚してなかったはずだから、相手の女性はシングルマザーとして子供を育てたことになるはずで…。
• 本郷猛の遺伝子を元に、クローンを作る。でも、改造人間の体の中には、遺伝子を取り出せるほどの生体部分が残っているのかどうか。ショッカーが改造前にそのあたりの記録を残していればどうにかなりそう。場合によっては精子を冷凍保存していたり、とか。…仮に残してたとしたら、ショッカーはソレを何に使うつもりだったんだろう。

よく考えたら、仮面ライダーのヒーローとしての能力は、怪人バッタ男として人工的に作られた、その体のほうにあるわけで。本郷猛の遺伝子を受け継いだ子供には、さほどの価値も無いような気もしてきた。ショッカーは、あれだけやたらと怪人○○を作っているのだから、本郷猛レベルの肉体が無いと、改造人間を作れないというわけでもないだろうし。

怪人バッタ男の体のほうに価値があるならば。生体部品である脳が衰えて、代わりに誰かの脳を移植・交換した、という設定になれば、そこに仮面ライダーの子供が誕生した、という話になるのだろうか。しかし、1号ライダーより、V3以降のほうが、スペックは上なんだろうし。スペックの低い旧型の体を使い続ける意味は無いよな…。そもそも2号ライダーやV3が居るわけだから、別人を改造人間にしたほうがコスト面では安上がりなのだろう。

ということで、本郷猛の子供を登場させるには、よほど上手い理由を考え出さないといけない予感。まあ、仮面ライダーの場合は、ライダーとしての魂を継承してればそれはもう子供みたいなもんだ、という扱いにするしかないような気もしてきたり。

ウルトラシリーズと仮面ライダーを比較すると、先天的な能力でヒーローになるか、後天的な能力でヒーローになるか、ヒーローは2種類に分類できるなと思えてきたり。

ウルトラ戦士は血筋でなれる。仮面ライダーは血筋ではなれない。

いや、仮面ライダー牙という特例もあるのか…。今になって考えると、ベルトが意志を持って喋る設定もそうだけど、血筋でライダーになったという設定も異質。ライダー牙は、ライダーシリーズの中では異端者、だったのだな…。まあ、毎回必ず既存作とは異質な設定が盛り込まれるシリーズだけど。

何にせよ、キャラクターが先天的な能力で活躍している場合は、子供を出すという展開もできそうだけど。そうではないなら、子供を出しても全然盛り上がらないのかもしれないなと。

ELECOMからは、アンプ付きの _MS-STM88SV という製品も販売されているらしい。この手の製品にしては珍しく、コンデンサマイクではなくダイナミックマイクを使用した製品。ダイナミックマイクだから、PC側のプラグインパワー云々ではまず使い物にならない。それをどうにか、コンデンサマイクと同程度の使い勝手にするための、アンプ内蔵・アンプを駆動するための電池内蔵だろうと思われる。別に、音質を良くするためにアンプを内蔵したというわけではないのだろう。PCでどうしてもダイナミックマイクを使いたいが大掛かりな機器導入は嫌だ、という人向けの製品として企画したのかなーと邪推する。

だが、Amazonやconeco.netのレビューを見ると、「どうして電池を入れなければならないのか」等、使われているマイクの種類を何ら気にすることなく不満を述べている事例が散見される。

一般的なPCユーザは、あまりにもマイクについて無知過ぎることを、なんだか再認識。種類すら知らずに平気で不満を述べるぐらいに無知なのだ。もちろん自分も無知過ぎる人間の一人。数日前にダイナミックマイクをノートPCにそのまま繋いじゃった自分には、他人様にどうこう言える資格など無いのであった。

マイクに限らずスピーカもそうだけど、音の入出力に関わる部分はどうしてもアナログ的なソレになるから、規格統一とか、ランクをつけるとか、そういうのは難しいのかもしれないと想像したりもする。にしても、PC側のソレをもうちょっときっちり統一しておくことはできなかったのだろうか。一応MSがWindows絡みで提唱してたらしいけど、それでコレかよという気もする。

真空断熱は、発泡スチロール等で周囲を囲んだだけのなんちゃって保冷ボトルやアルミで囲んでいるだけのなんちゃって保冷水筒とはレベルが違う保冷性。そこに、冷蔵庫で冷やしたコーラを入れて、ちびちびやりたい。

でも、その手の魔法瓶には「炭酸飲料を入れてはいけない」と注意書きがある。たぶん材質的にヤバイんだろう。しかし既にペットボトルには炭酸飲料が入っているわけで。だったらベットボトルごと入れてしまえばいいじゃないか。これで、魔法瓶に炭酸飲料を入れてるも同然。それでいて直接入れているわけではないから、問題は起きないはず。

オフィス等でも使えるのではと思うんだけど。机の下に置いといて、喉が渇いたなと思ったら、さっとベットボトルを取り出して冷たいジュースを。わざわざ保冷剤を確保・冷却しておく必要もない。電気を使って無理矢理個別にそこだけ冷蔵する必要もない。

でも、そういう製品を、どこも作ってないっぽい。ありそうなんだけど、意外と無い。ペットボトルをそのまま入れられると謳っている商品はあるけれど、よくよく見てみると真空断熱じゃなくて、発泡○○で囲んであるタイプだったり。そういうタイプは以前買って、保冷効果がさほど得られずガッカリしたわけで。

ひょっとすると、真空断熱のクーラーボックスがあれば済むのかな。検索してみたら、釣り具メーカだけが本気で真空断熱のクーラーボックスを作ってくれているらしい。が、値段が高い。そのへんのホームセンターで売っている発泡スチロールのソレとは本当に一桁違う。その分保冷能力は凄いらしいが。ペットボトルを1つだけ入れるために、この値段は厳しい。

アホみたいに保冷剤をガンガン突っ込んで無理矢理持たせるのが貧乏人にはお似合い、ということなんだろうなあ。

つまるところ、「ネットが発展していく過程」を見たことがない・今まで意識したことがなくて、物心ついた時にはそういう空間が存在するのが当たり前、という状態でネットを使ってる人間が多数派になってしまったから、「公開」という行為を否定することに何ら危機感すら感じていない、ということなんだろうか。と思っちゃったりしたけどよく判らない。

「どうしてNHKは受信料取るの？」等を口にしてる人達と似たようなもの、かもしれない。生まれたときから「TVはタダで見れるモノ」という認識しか持ってないから、そういう発言が出てくる。みたいな。 *1

どんなくだらない情報も、公開して共有知にすることで、別の価値がそこに生まれる可能性がある、ということを見事に示してみせたのがネットなのだから、情報を公開することを否定してはいけないのではないか、それはネットの否定に繋がりかねないのではないか、ネットの土台を壊してしまうものではないのか、と思うのだが。なんとなくこのへん、フリーライダー論に繋がりそうな気もするけど。

「チラシの裏に書いてろ」という発言も「情報」ではないか、という意見もありそうだけど、それには賛同しかねる。少なくとも、新たな情報が公開されることを阻害する文に関しては、情報として扱うべきではないような気がする。や、このへんなんだか矛盾があるような気もするのだけど。

要するに、「書くな」じゃなくて「その調子でどんどん書いてくれ。そしてどんどん調子に乗って何かの拍子についうっかりとお前のおっぱい画像コレクションももzipで俺にくれ」という方向でツッコミを入れるべきではないのかと。共有知、いや、共有乳(チチ)を増やすのだ。 ＜何を口走ってるんだ俺は。

• タグ情報入力が面倒。キーボードだけでサクサク入力したいのだが、各項目選択時にマウス操作を強要される。おそらく、開発者は、市販CDの音楽を取り込むことしか考えてない・どうせCDDBで情報取得するから手入力する場面はないだろうと思い込んでるのだろう。
• そもそもどうしてノーマライズやマキシマイズ機能がないのか。それがあれば、今回のように一旦wavを経由しなくてもいいし、タグ情報を手入力せずとも済んだのに。…市販CDから取り込んだデータを改変してはならない等の制約でもあるのかしら。であれば再生側で音量を自動調整する等、何かしら機能をつけておかないと。…再生側のバッテリーの問題を考えると、元々のデータを調整済みにしてしまうほうがいいのだろうけどなぁ。
• mp3を携帯に転送・aacに変換した際に、無音になって変換されたのが謎。mp3が、CBR 320kbpsなのがマズイのか。それとも MP3Gain で弄ったのがマズイのか。であれば変換前にチェックして、規定外のデータならエラー表示を出してくれないものか。…でも、最初の1曲だけ正常に変換されるのが不思議。
• 携帯に転送中、メインPCにリセットがかかったのは何故。miniSDに原因があるのか。それともソフトの問題か。…や、これは自分の環境に原因がある可能性も否定できないからアレか。

特に、音量が調整できないのは、かなりマズイと思う。たとえば。

1. 車の運転中に、SD-Audioを再生。
2. 昔のCDから取り込んだ曲データ再生中、音量が急に小さくなる。
3. ボリュームを変えるために機器に手を伸ばして余所見をする。
4. 歩行中の保育園児の列に突っ込む。
5. 大惨事。

…かなりマズイ。Panasonicが各種機器に添付したSD-Jukeboxの仕様がアレなために、未来ある子供達の尊い生命が無駄に失われてしまうという。

運転中にカーオーディオ等の操作などすべきではない、という意見もあるかもしれないのだけど。しかしそもそも SD-Jukebox に音量調整変換機能がついてたら、運転中にその手の機器を操作する場面を、間違いなく確実に、たった1つとはいえこの世界から無くすことができるわけで。Panasonic がちゃんと仕事をするかしないかが、日本全国のドライバーが安全運転できるか否かに実は繋がっている。SD-Jukeboxの開発に関わってる技術者は、自身が、人間の生命に関わる(可能性が高い)、重大な仕事に従事してるという自覚と誇りを持って職務にあたっていただきたい。

って話が大袈裟過ぎるか。でもないか。 実際、 _事件・事故が起きて たりするわけだし。…まあ、件のソレは、テープ入れ替えという、SD-Audio以前の話だけど。ここは一つ、「安全運転のためにSD-Audioを使いましょう」「SD-Audio = Safe Driving Audio」と宣伝できるぐらいまで作り込んでいただきたい。現状ではそんな宣伝はできない。ボリュームに手を伸ばさないといけないから。…まあ、シャッフル機能もアレなんだけど。

つーか世間ではiPod全盛なんだろうし。SD-Audio関連ソフトの仕様についてアレコレ考えること自体、無駄か。

ttaというのは、True Audio 形式の拡張子。mp3のような非可逆圧縮じゃなくて、可逆圧縮ができるフォーマット。CDからリッピングしたwavをそのままHDDに置いておくよりは、ほんの少しファイルサイズが小さくなるので、たまに使ってたり。＞自分。

STEPにプラグインを追加すれば、ttaのタグも編集できるらしいのだけど、配布サイトである STEP の wiki にそもそもアクセスできない。うーん。

ググってたら、プラグイン名が判った。 _STEP_tta というらしい。で、不思議なことに、 _Googleのキャッシュページ にアクセスしてから、「ダウンロード」等のリンクをクリックしたら、該当プラグインの配布ページに飛べた。何故なんだろう…。

とりあえず、STEP_tta100.zip を入手。STEPの、オプション→プラグイン→インストール、で該当プラグインを登録することで、ttaのタグが編集できるようになった。ありがたや。

CDDBとは音楽CDのタイトル、アーティスト名、曲名などの情報をインターネットから受信できる機能です。対応ソフトとインターネットの接続環境があれば誰でも自由に利用できます。

CDDB対応の吸い出しソフトを利用するとCD→WAVEやCD→MP3変換時にアーティスト名や曲名をファイル名に適用したり、mp3ファイルのID3タグに自動で入力させることが出来ます。

CDDBについて より

便利な時代になったなぁ…。ありがたや…。

ありがたや…。CDex、CD2WAV32 に、設定させてもらったり。

LAME 3.97 の beta 版がリリースされたことによって、このページの記述はそろそろ時代遅れになるつつある。LAME 3.97 以降を使う場合には --alt-preset や --preset の存在は忘れてしまった方が良い。

LAMEの設定の仕方 より

LAME 3.97 以降では --preset ではなく、次のどれかを使うようにした方が良いだろいう。
* VBR-NEW → -V n --vbr-new
* VBR → -V n
* ABR → --abr xxx
* CBR → -b yyy
n は 0, 1, ..., 9 のどれかで数字が小さいほど高音質になる。 xxx は目標とする平均ビットレートである。 yyy は 32, 40, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256, 320 のどれかである。

LAMEの設定の仕方 より

wav から変換した tta (=タグ情報がない) に対して使ってみたところ、一発で正解の情報を取得できた。これは素晴らしい…。

なるほどたしかに、特定用途に関しては恐るべき生産性を発揮するように見える。

なんとなく、TVゲームの中で動いてるインタプリタを思い出した。

_TiddlyWiki Style - Tips, Macros and FAQ
_JapaneseTranslation - メニューその他を日本語化
_MemoWiki - メモ用Wiki by TiddlyWiki
_TiddlyWiki関連リンク集
_[観] TiddlyWiki で遊んでみる
_TiddlyWikiのススメ
_Onlinesoft Lab Wiki
_unisonDiary - TiddlyWiki 2.0 の2ペイン化
_TiddlyWikiの「SelectThemePlugin」導入手順 : PamGau

『ナディア』しかり、『SEED2』しかり、『ボイスラッガー』しかり、やはり腕だよなと。

頭では…『イデオン劇場版』『Vガンダム』『デビルマン』があるけれど、直接的過ぎてアレだし。いや、『Vガンダム』のアレは上手かったけど。ヘルメットしか見せてないのに、なんともゾッとする光景で。

足ではなぁ。形状からしてよくわからないんだよな。関係ないけど足といえば、EVAにおけるそこだけシーツが凹んでるの図に感心したことが。そこにあるはずのものを書かないことで何が起きていたかが伝わるという。

『ナディア』で上手かったのは、シルエット中心で見せて、かつ、見せる時間を極力短くしたところ。…ただ、近年のアニメ作品になると、『SEED2』しかり、『エウレカ』しかり、直接じっくり見せてしまうのがちょっとどうかとも思ったり。所詮、絵でしかないから。絵で見せる・解説するより、絵をトリガーにして、視聴者の脳内に存在するイメージをそこに導き出したほうが効果が高いと思ったり。それとも、今の視聴者はそこまでの想像力を持ってないバカばかり、という予測があってのそういう流れなんだろうか。あるいは絵の力を信じすぎてるスタッフ・演出家が多いのだろうか。まあ、見せないより見せたほうが刺激性は増すから商品の訴求力は高まるのかもしれんのだけど。

「そこで一言説明しておけば問題は起きないのに」「そこでそんなことを言わなければ波風立たないのに」と思わせるキャラの言動なわけだけど。人として理想的と思われる行動・言動ではなく、あえて愚行を描くことで、話というものはどんどん進んでいくのかもしれないなとぼんやり思ったり。つまりはそれが脚本を書くときのテクニックなのかなと。まあ、後で書くけど、ライダーヒビキにも共通する感想で。

2chの特撮板を眺めてたら、色々な予測が。

• 視聴率が取れなかった。
• 玩具が売れなかった。
• 山や川でロケばかりしてスケジュールが厳しくなった。
• CG等を使いすぎて予算が厳しくなった。

なんでも高寺Pは、『仮面ライダークウガ』の時に、「たった2話でシリーズの予算を使い果たした」という伝説があるらしく。それを考えると、視聴率や玩具の売り上げより、スケジュールや予算の面で交代させられたという予測が主流みたい。なるほど、毎回スゴイなと思ってたけど、そういう面とのトレードオフだったのか…。

ということで、白倉Pに変わってから、おそらく画面はケチケチ路線(?)になりそうな。どうやって予算を抑えていくのか、そのへんも興味津々。おそらく…

• 屋外ロケは都心の近くだけになる。
• ライダーにしろ怪人にしろ、変身前の人が屋外ロケには極力出てこない展開に。
• CGの巨大生物も出てこない。出てくるとしても1クールに1回とか。

などと想像を。さて、どんな工夫を見せてくれるだろう。楽しみ。

今までの「響鬼」は、ヒビキおじさんにしろ、イブキくんにしろ、ザンキさんにしろ、おやっさんにしろ、誰も彼もが「理想的な人物」として書かれてた感が。少年が悩んでるときには、そのことを察知する能力はあったし、理想的な助言も与えていたし。おそらくは視聴者が憧れる「ヒーロー」を描こうと意識していたが故にそうなったのだろうと。でも、その代わり、ミスはなかなか見せないから、話がまったりというか、奇麗事ばかりにも感じるというか…。まあ、そこを気に入った人達が多かったのだろうと思うのだけど。ていうか自分はそこが好きだったのだけど。

その点、井上脚本は、おそらく理想ばかりを描いたりはしない。理想を描く前には、たぶん、一度は落とす。愚行を描いたその中で、理想的な言動が見え隠れするからこそ、理想が本当に光って見える…といった書き方をするような印象が。 *2

どちらのやり方が良い悪いという話ではなく。客を楽しませるという目的は同じなれど、その目的を果たすための方法論が違うだけだろうなと思ったり。「現実は愚行ばかりなのだから、せめて画面の中は理想だけを」というのもアリだし。「現実は愚行ばかりなのだから、画面の中でも愚行を見せなきゃ絵空事になる。でも、その上で理想を」というのもアリ。どちらも正しいやり方。

というわけで、旧路線も好きだけど、新路線も応援したいと、個人的には思うのでした。

まあ、作品内容より、まずはスケジュールや予算配分の建て直しのほうが、優先順位は高いよな…。

「2〜3日で書き上げた」「書き上げてからタイトルを知った」とか。スゲエ。やっぱり井上氏はスゲエ。なんだか次元が違う。思わず惚れてしまいそうなエピソードだ…。

.bash_profile には環境変数を、 .bashrc にはエイリアスを書くのが通らしい。しかし PS1 とかあたりは .bashrc に書くのが通らしい。というか何でもかんでも .bashrc に書くのがトレンド(?)になりつつあるらしい？ よくわからないけど。とにかく自由ってことですか。

昔は .Xdefaults を弄るのが当たり前だったみたいだけど、昨今は .Xresourecs を弄るのが _トレンド(?) らしい。 .Xresources は、.Xdefaults と違って自動で読みこまれないけど、.xinitrc や .xsession 中から xrdb -merge $HOME/.Xresources として呼ぶのだそうで。