mieki256's diary

ショートカットキーについて、もう少しメモを追加。

• Shift + テンキーの「+」/「-」 : ズームイン/ズームアウト。
• Ctrl + ホイール回転 : ブラシサイズ変更。
• A : カラーピッカー(色取得ツール)への切り替え。マウスカーソルが十字になるので、色を取得したい部分をクリックする。

ますます作業が楽になった。

Moho関係のチュートリアル動画を眺めていると、時々、次のような画面を目にすることがあって…。

• キャンバスの端っこに、独立したボーンが数本置いてある。
• ボーンを動かすと、キャンバスの真ん中に置いてあるキャラが、目パチ口パクしたり、向きを変えたりする。

目にするたびに、「コレって何だろう」「どうやったらこんなことができるんだろう」と気になってたわけで。

改めてググってみたら、スマートボーンダイヤル(Smart Bone Dial)という機能らしい。Moho上では「スマートボーンダイヤル」「スマートボーンダイアル」と表記が揺れているけど…。

なんでも、例えば目パチ口パク等、何度も出てくる同じアニメを、メインのタイムライン上でその都度逐一指定していたら面倒臭いので、メインのタイムラインとは別に管理される「アクション」と呼ばれるタイムライン上で、お決まりのアニメを作っておいて、そのアクションの何フレーム目を表示するか、という制御のためにスマートボーンダイヤルを使う、ということらしい。

するとつまり「アクション」というのは…プログラミングで言えばサブルーチンみたいなものだろうか…？ それともクラスとか？ 一度作っておいて後から何度も使い回す、という面は似ているような気もする…。

とりあえず使ってみる。

アクションが関係してくるので、アクションウインドウを表示しておく。

• ウインドウ → アクション、にチェックを入れると、アクションウインドウが表示される。
• もし、アプリウインドウの周辺のどこかに組み込んで表示したいなら、ウインドウ → ドッキング → アクション、にチェックを入れる。

アニメをさせるために必要なベクターレイヤーを数枚用意して、ボーンレイヤーに登録。今回は、目玉全体と瞳の2つのレイヤーを作ってみた。



スマートボーンダイヤルにするためのボーンを追加する。ボーンレイヤーを選択して、「ボーンを追加」ツールを選んで、キャンバスの端っこのあたりにボーンを追加。

• 各ボーンは、親を持たないようにしておく。ボーンが何も選択されていない状態からボーンを追加すれば、親を持たないボーンになる。
• Shift + 左ボタンドラッグで、ボーンの方向を45度単位で制限できる。

先ほど作成したボーンを、スマートボーンダイヤルにする。「ボーンを選択」ツールを選んで、ボーンを選択して、「ボーン」 → 「スマートボーンダイヤルを作成」を選ぶ。



「スマートダイアルの作成」ダイアログが開く。

• 名前には、選択したボーンの名前が自動で入っている。
• 最小角度、最大角度、時間(フレーム)、を設定する。
• 最小角度 〜 最大角度が、0 〜 +N なら、アクションが1つ作られる。
• 最小角度 〜 最大角度が、-N 〜 +N なら、アクションが2つ作られる。

スマートボーンダイヤルが作られて、対応するアクション、「B1」「B1 2」の2つが作成された。アクションを選んでいるときは、タイムラインの背景色が変化する。



今回、アクションには48フレームを指定したので、タイムライン上でカレントフレームを48フレーム目にする。スマートボーンダイヤルの見た目(角度)が変化する。ベクターレイヤーの位置を変化させてアニメをつける。



アクションウインドウ上で「B1 2」をダブルクリックして切り替える。こちらも48フレーム目にして、ベクターレイヤーの位置を変えてアニメをつけた。



同じ流れで、「B2」ボーンもスマートボーンダイヤルにした。「B2」「B2 2」の2つのアクションが生成された。アクションウインドウ上で「B2」をダブルクリックして切り替えて、48フレーム目にしてアニメをつけた。



「B2 2」アクションにもアニメをつけた。



アクションウインドウ上で「メインライン」をダブルクリックして切り替える。「ボーンを操作」ツールを選んで、スマートボーンダイヤルのB1、B2の角度を変えてみると、ボーンの角度に応じてアニメが変化する。



こんな感じの作業で、以下のようなアニメが作れた。

以下を参考にして作業しました。ありがたや。

_MOHOPro12使い方12 もにっこ初級講座 スマートボーンについて - YouTube
_スマートボーンダイヤルを作成 - moho pro12 / moho pro13 wiki
_MOHO Pro12の操作4 スマートボーンダイヤル編 | あらむぎ

Godot Engine の座標系は以下のような感じ。

• +X : 右
• +Y : 上
• +Z : 手前

いわゆる右手座標系、なのだろうか。

_3次元CGと座標系

カメラ(Camera)情報は以下。

• Tarnslation (位置) : (x, y, z) = (0, 40, 12)
• Rotation (角度) : (rotx, roty, rotz) = (-65, 0, 0)
• Fov (画角) : 60度

自機の移動面は、y=0 の平面。

余談。

• Godot Engine のカメラは、x回転角度が0の時、水平線が見える。(真横を見てる)
• カメラのデフォルト設定では、画角は垂直画角として扱われる。
• カメラの Keep aspect 設定を変えることで、水平画角にすることも可能。

縦方向というか、奥行き方向については、以下の計算で求めることができそう。たぶん。

cxrot = -65
cy = 40
cz = 12
fov = 60

ang = 180 - cxrot - (fov / 2) = 215
n = (-cy) / sin(ang) = 69.74
z_top = n * cos(ang) + cz = -57.13 + 12 = -45.13

ang2 = 180 - cxrot + (fov / 2) = 275
m = (-cy) / sin(ang2) = 40.15
z_bottom = m * cos(ang2) + cz = 3.50 + 12 = 15.50

前述の図は、横方向から見た時の図だけど、カメラの位置を原点にした状態で考えてるので、求めた値にカメラの位置情報(z値)を後から加減算して本来の値を得ることになる。

一応 Godot Engine 上で、自機の位置を計算で求めた値に変更してみたら画面の上下端に位置してるように見えたので、この計算でも合ってるんじゃないかな。

問題は横方向。どうやって求めればいいのだろう…。

とりあえず、垂直画角から水平画角を求めないといけない。

w = 1280   # Window width
h = 720    # Window height
fov = 60

tan(fov / 2) = (h / 2) / dist
dist = (h / 2) / tan(fov / 2)

tan(fov_h / 2) = (w / 2) / dist
fov_h / 2 = arctan((w / 2) / dist)
fov_h = 2 * arctan((w / 2) / dist)

fov_h = 2 * arctan((w / 2) / ((h / 2) / tan(fov / 2))) = 91.50

垂直画角が60度、ウインドウサイズが1280x720なら、水平画角は91.50度ぐらいになるのかな。コレ、合ってるんだろうか。

例えば、平面と線分の交点を求める関数でもあれば、こんな計算をしなくても自機の移動範囲を求めることができそうな気もするのだけど…。どうなんだろう…。自機が移動する平面と、カメラの四隅に相当する線分で、交点を求めれば…。そのほうが汎用性はありそうな気もする…。

そういう関数って、Godot Engine には無いのかな。ありそうな気もするのだけど。

それでもなんとか、ファイル名でググって、入手できそうなページを見かけたので、一応メモ。

_how to convert BDF fonts for FreeBSD 10.x vt(4) console, make ISO10646 encoded font
(ページの下のほうにリンクがある。)

_https://opensource.apple.com/source/X11fonts/...
_Index of /~yasuoka/ftp/fonts
_Index of /dist/fonts/BDF/JISX0213
_JISX0213 16x16 public fonts
_Debian Fonts Task Force / xfonts-jisx0213 - GitLab
_Index of /pub/FreeBSD/ports/distfiles/xorg/font

jiskan16.bdf には全角文字部分が入っているけれど、半角文字部分は入っていないらしい。一般的には、SONY が作ったらしい、8x16rk.bdf と組み合わせて使う場合が多いようで。

_Re: mgl2 make failured

SONY製のフォントとなるとライセンス面が厳しいのではないかと思ったけれど、当時は緩い感じで使えてたようだなと。

その後もググっていたところ、intlfonts なるフォントファイル群を入手できれば、その中に jsikan16.bdf や 8x16rk.bdf も入ってると知った。

_Index of /old-gnu/intlfonts
_With Emacs Next - 3.1.2 フォント設定

他の選択肢として、東雲フォントを使うのもアリかなと。jiskan16.bdf と比べると、すっきりした見た目で、可読性が向上しているフォントのように感じたり。

_東雲フォント - Wikipedia
_shinonome font family
_日本語漢字ビットマップフォント、東雲フォントについて | mgo-tec電子工作

M+ Bitmapフォントという選択肢もありだろうか。丸みがあって、コレも読みやすい。

_M+ BITMAP FONTS

余談。

今時はTTFフォントを使う場面が多いわけで、するとBDFフォントをあえて使う理由は何だろうと考えたのだけど。やはり、ドットを寸分違わずきっちりと画面に出したい、という需要を満たしたい時に使えるのかなと。アウトラインフォントだと、最終的にどんな見た目になるのか予想しづらいところがあるし。

もっとも、漢字を含んだ、こういったBDFフォントを使う必要が出てくるとしたら、大量のテキストを画面に表示する場合であろうし。であれば、ドットがどうこうより、読みやすいか否かでフォントを選んだほうがいいのかもしれない。

それとは別に、ライセンスの問題もありそうか…。当時のBDFフォントは、ライセンスに関して比較的緩く指定されてるものが多い印象もあり、ソフトウェアに同梱する際に問題が起きにくい面もありそうな。もっとも、昨今のフォントも、SIL Open Font License 等、ソフトウェアから使う分には比較的緩いライセンスになってるものも多いかな…。と思ったけれど、そのあたりは英語圏のフォントの話で、日本語フォントとなるとまた状況が違ってくるか…。

_renpy/pygame_sdl2_windeps: Windows dependencies for pygame_sdl2. に、pygame_sdl2 をWindows上でビルドする際に必要になるファイル群があるよ、てな話も見かけた。ていうか pygame_sdl2 の README.md に書いてあるな…。一覧を眺めると、 _pygame_sdl2_windeps/lib/x86 のあたりに SDL2.dll や SDL2_image.dll が入ってるようで。

ビルドするには、使ってるPythonのバージョンと合ってる Visual Studio が必要、とも書いてある…。

自分が使ってるのは Python 2.7 だけど…。 _WindowsCompilers - Python Wiki を眺めた感じでは、

• Python 2.6 〜 3.2 までは Visual C++ 9.0。
• Python 3.3 と 3.4 は Visual C++ 10.0。
• Python 3.5 と 3.6 は Visual C++ 14.0。

と書いてあるから…。Python 2.7用の pygame_sdl2 をビルドするには Visual C++ 9.0 が必要、ってことになるのかな。「Visual Studio 2008 をインストールする必要は無い」って書いてあるけど…Express版は使えないのだろうか。 _Microsoft Visual C++ - Wikipedia を眺めると、一応 Visual C++ 2008 Express に入ってるみたいだけど…。

むむ？ よく見たら、 _Microsoft Visual C++ Compiler for Python 2.7 てのが用意されてるのか。Python用のアレコレをビルドするための環境がMicrosoftのサイトから正式に入手できるとは…。嘘だろ。マジかよ。Microsoft、やるなあ。 _Windows での Python 2.7, 3.4, 3.5 の拡張モジュールビルド環境 - Qiita によると去年から用意してくれたらしい。Microsoft、凄いぞ。素晴らしい。いや、ちょっとコレ、 _ヤンキー効果 が入ってる気もするけど…。でも、スゴイ。Microsoft、グッジョブ。

とりあえず Visual C++ Compiler for Python 2.7 を Windows10上でインストール。スタートメニューに「Microsoft Visual C++ Compiler Package for Python 2.7」というフォルダが出来て、ショートカットが登録された。「Visual C++ 2008 32-bit Command Prompt」を実行。DOS窓が開いた。

>where cl
C:\Users\ユーザアカウント名\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\bin\cl.exe

このへんにインストールされたのか…。「インストールしたユーザしか使えないよ」って感じかな…。 *1

cl /?

と打つと、色々出てくる。

とりあえず、この Visual C++ のコンパイラを使いたい時は、「Visual C++ 2008 *-bit Command Prompt」を実行してDOS窓開いてそこで作業すべし、ということらしい。

_Microsoft Visual C++ Compiler for Python 2.7はひとのためならず | site-hhs を参考に、 _lru-dict とやらをビルドすることで動作確認。lru-dict-1.1.6.tar.gz をDLして解凍して中に入って python setup.py build と打ったら、buildというフォルダが作られて中に色々なファイルが作られた。どうやらちゃんと使えそうな予感。

ここまで調べといてなんだけど。色々見ていたら、 _Unavailable nightly builds - Issue #66 - renpy/pygame_sdl2 で、「Nightly buildsは _http://nightly.renpy.org/current/ の一番上にあるよ」てな話が…。しかし、DLして中を覗いたけどバイナリが入ってるようには見えなかった。何だろう、コレは…。

pygame_sdl2 がビルドできそうなのか、ダメ元でやってみる。再度書いておくけど、環境は Windows10 x64 + Python 2.7.13 32bit版。

「Visual C++ 2008 32-bit Command Prompt」を実行して、DOS窓を開いて…。

そのままだと C:\WINDOWS\system32\ というWindowsのシステム的に大変恐ろしい場所に居るので、cd でどこか問題無さげな場所に移動して。…Cドライブのルートにtempフォルダでも作ってそこに行こうかな。

mkdir C:\temp
cd C:\temp

適当なフォルダを作って、中に入って。

mkdir pygame_sdl2
cd pygame_sdl2

git clone で github からソース群をDL。git を使うので、git がインストールされてる必要有。もっとも、githubのページからzipをDLして解凍するのもアリかもしれんけど。

git clone https://github.com/renpy/pygame_sdl2.git

pygame_sdl2 というフォルダが作られた。中に入って、ファイルを確認。

cd pygame_sdl2
dir

色々なファイルがDLされた模様。Python でビルドやインストールに使われるらしい setup.py というファイルも見える。

ビルド時に必要になるという、pygame_sdl2_windeps も git clone でDL。

git clone https://github.com/renpy/pygame_sdl2_windeps

dir と打って確認すると、pygame_sdl2_windeps というフォルダが作られてる。中にはビルドに必要な色んなファイルが入ってるらしい。

いきなりインストールするのは怖いので、まずはビルドだけ試してみる。

python setup.py build

エラーが出た。cython がねえよ、って怒られてるような？

_Why don't have yet a release in PyPI? - Issue #39 - renpy/pygame_sdl2 によると、「Cythonをインストールしろや」って書かれてるな…。Cythonって何ですか？

_深入りしないCython入門 - Qiita

Pythonは処理速度は決して早くない、むしろ遅い部類である。 そこで、C/C++に変換することにより高速化しようというのがCythonである。

深入りしないCython入門 - Qiita より

そういうものらしい。

_WindowsでもCythonを使えるようにする。 - Qiita でインストール方法が紹介されてた。pip install でイケるらしい。

pip install cython

たぶんこれでインストールされたんじゃないかな。

もう一度ビルドにチャレンジ。

python setup.py build

警告がガンガン出てるけど、なんだかずらずらと表示しながら処理が進んでるっぽい…。ていうか、Windows上でやってるのに、

sh: sdl2-config: command not found

とか出てるけど、大丈夫なの？ 自分の環境は mingw をインストールしているから sh.exe も入ってるけどさ…。

とりあえず、処理が終わったっぽい。build というフォルダが作成されて、中に色々なファイルが入ってた。SDL2.dll等のファイルも見える。

一応ビルドが通ったように見えなくもないし…。怖いけど…インストールしてみるか…。

python setup.py install

Python2.7インストールフォルダ\Lib\site-packages\ の中に、pygame_sdl2-2.1.0-py2.7-win32.egg というフォルダが作られて、中に色々入った、ようではある。

ここまでできたということは…。wheelパッケージとやらも作れるのだろうか？

_Python: Wheel でパッケージを配布する | CUBE SUGAR STORAGE によると、

python setup.py bdist_wheel

で作れるっぽいけど…。でも、site-packages\ の中は 〜.egg というフォルダが作られているんだよな…。

試してみたら、dist というフォルダの中に、 _pygame_sdl2-2.1.0-cp27-cp27m-win32.whl というファイルができていた。コレを使ってインストールできるのかしら。一応置いときます。手元の環境では pip install 〜.whl でインストールできたけど、他の環境でインストールできるかどうかは不明。

動作確認してみたいのだけど、どこかにサンプルは無いのかな？

_renpytom/rapt-pygame-example: Example of using RAPT to package Pygame(_sdl2) games. で、Android版のサンプルは公開されてるようだけど…。

_rapt-pygame-example/main.py を眺めると、最初のあたりで、

import pygame_sdl2
pygame_sdl2.import_as_pygame()

import pygame

みたいな感じで書いとけば、pygame_sdl2 が使われるっぽい。

_ウィンドウを表示する - 人工知能に関する断創録 を参考に、ウインドウを表示するだけのスクリプトを書いてみたり。

_helloworld_pygame_sdl2.py

# pygame_sdl2 test. window display only

import pygame_sdl2
pygame_sdl2.import_as_pygame()

import pygame
from pygame.locals import *
import os

SCREEN_SIZE = (640, 480)

def main():
    pygame.init()
    screen = pygame.display.set_mode( SCREEN_SIZE )
    pygame.display.set_caption('Hello pygame_sdl2')

    while True:
        screen.fill((0, 0, 255))  # screen fill Blue
        pygame.display.update()
        
        for event in pygame.event.get():  # check event
            if event.type == QUIT:
                return
            if (event.type == KEYDOWN and
                event.key  == K_ESCAPE):  # push Escape key ?
                return

if __name__ == '__main__':
    main()

一応動いたことは動いた、ような気がする。しかしコレだけでは見た目が pygame と変わらん…。何をどうしたら pygame_sdl2 で動いてるってことが分かるのやら。

画像ファイルを読んで描画する処理を試してみたり。

_draw_image.py
_ufo.png
_bg.png

# draw image by pygame_sdl2

try:
    import pygame_sdl2
    pygame_sdl2.import_as_pygame()
except:
    print "pygame_sdl2 not available"

import pygame
import pygame.image
# from pygame.locals import *

SCREEN_SIZE = (640, 480)

def main():
    pygame.init()
    screen = pygame.display.set_mode( SCREEN_SIZE, pygame.HWSURFACE | pygame.DOUBLEBUF )
    pygame.display.set_caption('draw image by pygame_sdl2')

    sysfont = pygame.font.SysFont(None, 64)
    textsurface = sysfont.render("Hello world", True, (255, 255, 255))
    
    bg = pygame.image.load('bg.png').convert()
    image = pygame.image.load('ufo.png').convert_alpha()

    x = 10
    y = 10
    dx = 2
    dy = 1
    bgx = 0
    clock = pygame.time.Clock()
    cnt = 0

    while True:
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                return
            if (event.type == pygame.KEYDOWN and event.key  == pygame.K_ESCAPE):
                return

        if x + dx < 0 or x + dx + image.get_width() >= SCREEN_SIZE[0]:
            dx *= -1
        if y + dy < 0 or y + dy + image.get_height() >= SCREEN_SIZE[1]:
            dy *= -1
        x += dx
        y += dy
        bgx -= 3
        if bgx < -640:
            bgx = 0
        
        # draw bg image
        screen.blit(bg, (bgx,0))
        screen.blit(bg, (bgx + SCREEN_SIZE[0],0))
        
        screen.blit(image, (x, y))        # draw image
        screen.blit(textsurface, (0, 0))  # draw text image
        
        # pygame.display.update()
        pygame.display.flip()
        
        clock.tick(60)  # 60fps
        
        cnt += 1
        if cnt % 180 == 0:
            print str(clock.get_fps()) + " FPS"

if __name__ == '__main__':
    main()

一応描画されたが、妙なメッセージが表示される。

> python draw_image.py
libpng warning: iCCP: known incorrect sRGB profile

libpng のバグ(?)らしい。

_Libpng errors - ArchWiki
_Cocos Studioで生成した.csbをcocos2d-xに読み込んだ際に"libpng warning: iCCP: known incorrect sRGB profile" - Qiita
_dvipdfmxで「warning: iCCP: known incorrect sRGB profile」というエラーが出る場合の対処方法 - Qiita

ImageMagickの convert を使って画像ファイル内から余計な情報を削除せよ、とのこと。

convert -strip input_file output_file

しかし、ImageMagick 7.0.3-2 の magick.exe を使ったら上記のオプションが反応しなかった。ImageMagick 6.9.1-10 の convert なら処理してくれたのだけど…。

書き方がいかんかったらしい。以下の書き方をしたら処理してくれた。

magick input_file -strip output_file

SDL1.2 に比べて SDL2 は何が違っているのだろう。

_SDL2の使い方 - mirichiの日記
_SDL2で出来る事メモごく一部 - nyaocatのがんばるブログ
_SDL 2.0と1.2に関するメモ
_SDL 1.2から2.0への移行
_SDL2の紹介

色々変わったらしいが…とにかく描画が速くなった、と思っておけばいいのかな。

_Pygame_SDL2 runs slower when large quantity of sprites are drawn - Issue #36 - renpy/pygame_sdl2 で気になる話が。pygameよりpygame_sdl2のほうが遅いらしい…。

ここまで試したのに、なんじゃそりゃって感じ…。

でもまあ、おかげで Microsoft Visual C++ Compiler for Python 2.7 の存在を知ることができたのは幸いというか。

_three.js wiki - トップページ
_THREE.js で WebGL | ヨモツネット
_Webグラフィックをハックする（5）：多彩な表現力のWebGLを扱いやすくする「Three.js」 (1/5) - ＠IT
_three.jsで3Dを作りたい！ - Qiita
_JavaScript 3DレンダリングエンジンのThree.jsを試す | KRAY Inc
_requestAnimationFrame でフレームと再描画更新を制御する
_Timer APIs(Date.getTime, Date.now, performance.now, setTimeout, setInterval, requestAnimationFrame, setImmediate) with Canvas Animation - Qiita
_Three.js リサイズ - Three.jsを使って、作ってみた
_Three.jsで物体に光を当てる | mwSoft
_よく利用するThree.js旧バージョンからのコード書き換え(メモ) | cityJumperWEB.com
_Three.jsでポリゴンを描画するには - non vorrei lavorare
_うだる - ずっと君のターン

そういえば今頃気が付いたけど。今まで通ったことのある、S歯科、N歯科では、初診時に歯の全体の状態を目視で調べてカルテを作って、今後の治療計画を立てていたような。この歯を治療してる間にこっちの歯まで治療を始めてしまうと食事が取れなくなるので、まずはこの歯の治療を済ませてから、てな説明を受けた記憶もあるし。しかし今回は、そういったことをしてないなと。 *1

それと、1本ずつ治療するか、3本一気に治療するかを選択してほしいと言われた際も、何かこう…。

メリット・デメリットを尋ねてみたら、「1本ずつは1回当たりの治療費が少ないけど何度も来ることになって時間がかかる」「3本一気は1回当たりの治療費がかかるけど来る回数は少ない」との回答で。それだけじゃ判断つかないので先生のおすすめはと尋ねたら3本だとの回答だったので、でしたらそれでと言ってしまったのだけど。今になって考えてみたら、時間と金額の視点はあるけど、患者への体の負担という視点が一切入ってない説明だよなと…。

もっとも、もしかするとこの選択は何かのリトマス試験紙だったのかなと今頃になって邪推したりもして。本来自分は「とにかく痛くないほうを」と打診してみるべきだったのかも。でも、そういうこと言うと「どっちも痛いに決まってるでしょ」と怒り始めそうな先生だし…。

誤解されたくないので一応書いとくけど、こういうのって、歯医者さんと患者さんの相性だよなと思うわけで。

ある患者さんからは評判が悪くても、別の患者さんからは評判がいい歯医者さんの話を聞くことはザラで。ウチの家族の中ですら、ある歯医者さんに対して、親父さんとお袋さんと妹の評価がバラバラだったりするし。

たくさん説明してもらったほうが安心する患者さんも居れば、説明されてもどうせオラわからんから先生にお任せしますてな患者さんや、説明する暇あったら手を動かしてくださいてな患者さんも居るだろうし。とにかく忙しいので治療回数が少ないほうがいいという患者さんも居れば、時間や回数がかかってもいいからしっかり間違いなくと望む患者さんも居るし。歯医者さんだって、得意分野と不得意分野がフツーにあるはずだし。治療方針だってそれぞれ違うはずだし。

なんでもそうだけど、長所は短所になるし、短所は長所になるので。だから、相性だと思うわけですよ。

ただ、できれば、ココはこういうタイプの歯医者です、みたいな情報がもっと欲しいところだよなと…。そのあたりの情報が入手できないから、相性が悪い歯医者さんに運悪く通うことになって双方にとって良くない状態に。最初からタイプが分かってれば行き違いが少しは減らせそうだけど。

メール関係は、一旦 Windows Live メールを経由しないといかんらしいあたりが面倒。

Windows Live メールでは、OE6 からの変換が終わらない場合もあるらしい…。

_【Windows7移行のやってはいけない】メール移行がすぐに終わると思ってはいけない | nikkei BPnet 〈日経BPネット〉：日経BPオールジャンルまとめ読みサイト

上記の記事では、Thunderbird を標準メーラとして使うことで解決したらしい。Thunderbird にしておけば、OSが変わっても移行時の問題は起きないというメリットがありそう。

昔は、Windows転送ツールで転送してから Windows Live メールを起動すること、てな制限があったようで。

_ニュース - 「XPからWindows 7へのメール移行は要注意」---マイクロソフトが説明会を開催：ITpro

最新版の Windows Live メールなら、インポート機能が追加されてるようなので、こういう問題は起きないのかもしれない…？ どうなんだろ。

ルータ RT-200KIのマニュアルを発掘したとのことで、ソレを見ながら初期化作業。や、マニュアルはネットでもPDFで公開されていて、自分もUSBメモリにコピーして持ってきたんだけど、とりあえず発掘できてよかった。

さておき、初期化作業。電源ケーブルを抜いた状態で、ルータ底面のRESETスイッチを千枚通しっぽいもので押しっぱなしにしながら、電源ケーブルを差す。INIT LEDが赤く光るまで RESETスイッチ押しっぱなし。赤く光ったらスイッチから手を離してOK。

http://192.168.1.1/ もしくは http://ntt.setup/ にアクセスして設定作業をしていくこともできるらしいけど、発掘されたマニュアルと一緒に、初期設定作業用のCD-ROMが発掘されたらしいので、それを使って設定してもらったり。新PC上でCD-ROM内のツールを起動したら途中で無反応になってしまったので、古いPC側でツールを起動。途中、ルータのパスワードを設定する場面が出てきたので、今度はしっかりメモしつつ設定してください、とお願いして作業を進めてもらった。

設定が一通り終わるとルータは自動的に再起動。その後、古いPC側からネットに繋がった。前述の設定ページ用アドレスにアクセスしてもらって、ユーザ名 admin、パスワードは先ほど設定したソレでログイン。設定ページがちゃんと表示された。

ざっくり各設定項目を眺めてもらったけど、ほとんどは初期設定状態で問題ないっぽい感じ。電話も繋がってるし。唯一、ファームウェアが随分と古いバージョンで、「ダウンロードして更新」的なボタンを押して更新してもらったり。

ルータがルータとして動いたように見えたので、古いPCからマイネットワークを開いて、新PCが見えるかどうかを確認。…ダメだった。やっぱり見えない。ping も通らない。

古いPCに入ってるウイルスバスターが悪さをしているのでは、と思ったので、ウイルスバスターのパーソナルファイアウォールを無効にしたり、Windowsファイアウォールを無効にして、再度確認。ダメ。やっぱり見えない。

ping は通らないが、ウイルスバスターの「ホームネットワーク」なるタブで、新PCのIPアドレスは見えている模様。PC名は見えてない。ということは、LANケーブルは物理的に繋がってる。ソフトウェア側の設定や動作状態に何か問題があるか、ルータがWindowsのファイル共有関係を全部ブロックしているか。

ルータ RT-200KI の設定項目の中に、「Windows共有」「ステルスモード」等が存在するので、もしかするとソレかもしれない。が、該当設定ページの「ヘルプ」には、「外部と云々」と書いてある。外部と言うのは、おそらくインターネット側という意味だろう。LAN内のソレには適用されないのではないか。どうなんだろう。

デジカメde同時プリントに関しては、フィルムが格納されてるフォルダを新PCにコピーしてから、デジカメde同時プリントの「参照フィルムの追加」で再度管理下におけることが判った。その作業を繰り返してもらえばなんとかなるだろうと。

ホームページビルダーの設定をコピーするところまでやってもらいたかったけど。htmlファイルその他のコピーを始めたらこれまた時間がかかる。設定ファイルまで転送はできなかった。ちなみに、

C:\Documents and Settings\ユーザ名\Application Data\IBM\Homepage Builder Version ??\site

フォルダ内を丸々コピーすれば転送設定は引越できるはず。

お袋さんが会社から帰宅する前に電話を入れてくれたおかげで、お袋さんの車に便乗して自分も帰宅。

途中でケーズデンキとデンコードーに立ち寄ってFAXの価格を見てきた。ヨドバシのポイント還元まで考えると、数千円高い。うーん。

ノートPCも興味があって眺めたが、10万円以下のモノはやっぱり液晶がアレで…。OSにWindows Vista が入ってるのも問題。標準で512MBしかメモリを積んでない商品ばかりだから、実用にならないのでは。おそらく1GBほど積んでないと話にならない予感も。…いっそ、OS無しで売ってくれないだろうか。Ubuntu を入れたい。でも、比較的新しいハード上では、Linux は動かないよな。

「インデックスカラーで可逆圧縮」なら gif があるし。「フルカラーで可逆圧縮」「アルファチャンネル付随」なら tiff があるし。 *3 そう考えると「別に png でなくても」という話になる。のだけど。これだけWebブラウザが普及した現在、ブラウザにD&Dすればひとまず閲覧ぐらいは一応できるというのは、tiff の互換性問題 ―― 手持ちのソフトで最低限の閲覧ができるかできないかすら確証が持てない ―― 等を考えた場合、大きなアドバンテージ(に結果的になってしまった)と言ってもいいのではないか。画質の劣化もなく、あまり減らないけどベタ画像よりは容量も減り、各種情報も付随させられるフォーマット。イマイチなところはちょこちょこあっても、まあ、大体はこれでなんとかなりそう、みたいな。

ということで、「どの画像フォーマットがいいのやら。選ぶの面倒だなぁ。…ま、とりあえずこれで保存しとけば後々なんとかなるだろ。たぶん」的モノグサな人にとって、比較的ありがたいフォーマットなんじゃないかと思ったり思わなかったり。…でも、ツールを作る側にとっては、「なんでこんなにアレコレ仕様があるんだよ！ しかもコレって使うヤツ居るのか？」とイラついてそうな予感も。 _Photoshopですら最初のうちは変なpngを吐き出してた し。仕様書がよほど判りづらかったのではないかと勝手な邪推。IEもアルファチャンネルに対応してないし。Webデザイナーの怨嗟の声が聞こえてくる気もするが、開発者にとって、やっぱり対応は面倒だったんだろうなぁ。

まあ、各画像フォーマットはそれぞれ得手不得手があるので、場面に応じて選択するのがベスト。狂信するのも変。全否定するのも変。適材適所だよね。という結論にしかならない気もするのだけど。

Windows Media Photo という名称のコレ。ロスレス圧縮もあるなら、png を置き換えることもできそう。将来的にはデファクトスタンダードになったりするのかもしれないな、てなことを想像したりもする。Windows に標準搭載 or MSがサポートして、求められる機能・仕様がほとんど入っていて、しかも規格がある程度公開でもされれば、皆さんソレを使うだろうし。それはそれで自分にとっても嬉しい状況かもしれず。画像フォーマット選択で悩まずに済むのはありがたい。

が、オープンな状態ではないという話も上がってるようで不安。Mac や UNIX 系で読むことすら出来なかったらどうしよう。

レイヤーは持てるのかな。どうなんだろう。そこらへんも対応できて、かつ、普及しそうなフォーマットって無いものかしら。もっともそのへん、ソフト側の対応にかかってるし。

00ffffffff 00ffff0000 00ff00ff00 00ff0000ff 00ff010203 00ff800000 00ff008000 00ff000080 00ff00ffff 00ffff00ff 00ffffff00

((謎値 & 0x0ff) << 24) | ((R & 0x0ff) << 16) | ((G & 0x0ff) << 16) | (B & 0x0ff)

/**
 * PalettedImage の表示テスト
 */

import java.io.InputStream;

import javax.microedition.io.Connector;
import com.nttdocomo.io.ConnectionException;
import com.nttdocomo.ui.Canvas;
import com.nttdocomo.ui.Dialog;
import com.nttdocomo.ui.Display;
import com.nttdocomo.ui.Graphics;
import com.nttdocomo.ui.IApplication;
import com.nttdocomo.ui.Image;
import com.nttdocomo.ui.MediaImage;
import com.nttdocomo.ui.MediaManager;
import com.nttdocomo.ui.Palette;
import com.nttdocomo.ui.PalettedImage;
import com.nttdocomo.ui.PhoneSystem;


public class TestPalettedImage extends IApplication {
    Main m = new Main();
    public void start() {
        Display.setCurrent(m);
        m.exec();
    }
}


final class Main extends Canvas {
    static final int FPS = 20;
    static final int SLEEP_VALUE = 1000 / FPS;
    static final int SCR_W = 240;
    static final int SCR_H = 240;

    private Graphics g = getGraphics();
    private int waitTime;
    private long getTime;
    private int frameCounter;
    private int rootStep;
    private Image bgimg;
    private PalettedImage palimg;
    private Palette[] pal = new Palette[5 * 5];
    private int btnStsInterrupt;

    // コンストラクタ
    public Main() {
        System.gc();
    }

    // メイン
    public void exec() {

        waitTime = SLEEP_VALUE; // フレーム間隔
        rootStep = 0;

        // バックライトON
        PhoneSystem.setAttribute(PhoneSystem.DEV_BACKLIGHT, PhoneSystem.ATTR_BACKLIGHT_ON);

        getTime = System.currentTimeMillis();

        // メインループ
        while (true) {

            try {

                switch (rootStep) {
                    case 0 :
                        // init
                    {
                        // 背景画像をロード
                        MediaImage image = MediaManager.getImage("resource:///3.gif");
                        try {
                            image.use();
                            bgimg = image.getImage();
                        } catch (ConnectionException e) {
                            image = null;
                            displayDialog(Dialog.DIALOG_ERROR, "実行エラー", "BGイメージロード失敗。" + e);
                        }

                        // パレットを変える画像をロード
                        try {
                            // Connection con=Connector.open("resource:///testimg.gif",Connector.READ);
                            // InputConnection incon=(InputConnection)con;
                            // InputStream in = incon.openInputStream();

                            InputStream in = Connector.openInputStream("resource:///2.gif");

                            // パレットを設定できるイメージを生成
                            palimg = PalettedImage.createPalettedImage(in);
                            in.close();
                        } catch (Exception e) {
                            displayDialog(Dialog.DIALOG_ERROR, "Error", "パレットイメージロード失敗。" + e);
                        }

                        // パレットを取得
                        Palette p = palimg.getPalette();

                        // 色数取得
                        int colnum = p.getEntryCount();

                        // パレット値を表示してみる
                        for (int i = 0; i < p.getEntryCount(); i++) {
                            int argb = p.getEntry(i);
                            String s = "0000000000000000" + Integer.toHexString(argb);
                            String sb = s.substring(s.length() - 16);
                            System.out.println(sb);
                        }

                        // 変化させるためのパレットオブジェクトを確保
                        for (int i = 0; i < pal.length; i++) {
                            pal[i] = new Palette(colnum);
                        }

                        // 変化させるためのパレットを作成
                        for (int c = 0; c < pal.length; c++) {
                            int v = c * 256 / (5 * 5);
                            for (int i = 0; i < p.getEntryCount(); i++) {
                                int argb = p.getEntry(i);
                                int a = (argb >> 24) & 0x0ff;
                                int r = (argb >> 16) & 0x0ff;
                                int g = (argb >> 8) & 0x0ff;
                                int b = argb & 0x0ff;
                                r = r * (256 - v) / 256;
                                g = g * (256 - v) / 256;
                                b = b * (256 - v) / 256;
                                argb = Graphics.getColorOfRGB(r, g, b, a);
                                pal[c].setEntry(i, argb);
                            }
                        }

                        rootStep++;
                    }
                        break;
                    case 1 :
                        // draw
                    {
                        g.lock();

                        // BG 描画
                        g.drawImage(bgimg, 0, 0);

                        {
                            int w = palimg.getWidth();
                            int h = palimg.getHeight();

                            int idx = 0;
                            for (int y = 0; y < 5; y++) {
                                for (int x = 0; x < 5; x++) {
                                    int dx = 16 + (w + 8) * x;
                                    int dy = 16 + (h + 8) * y;

                                    // パレットを変える
                                    palimg.setPalette(pal[idx]);

                                    // 描画
                                    g.drawImage(palimg, dx, dy);

                                    idx++;
                                }
                            }
                        }

                        g.unlock(true);
                    }
                        break;
                }


                System.gc();
                while (System.currentTimeMillis() < getTime + waitTime)
                    Thread.yield();
                getTime = System.currentTimeMillis();

                frameCounter++;


            } catch (Exception e) {
                displayDialog(Dialog.DIALOG_ERROR, "実行エラー", "処理中に問題発生。" + e + " rootStep=" + rootStep);
            }
        }
    }

    // 画面描画
    public void paint(Graphics g) {
    }

    // イベント通知処理
    public void processEvent(int a_type, int a_param) {
        if (a_type == Display.KEY_PRESSED_EVENT) btnStsInterrupt |= (0x01 << a_param);
    }

    // エラー時のダイアログ表示
    public void displayDialog(int type, String title, String str) {
        Dialog d = new Dialog(type, title);
        d.setText(str);
        d.show();
        IApplication.getCurrentApp().terminate();
    }

}

上のソースは問題ありな予感。本番用ソースに同じような記述をしたら色がおかしくなった。

隙が無い。「808」ってのがいいよな。

考えてみれば、101,202,303,404,505,606,707,808,909…どれもなんだかグッとくる。何故だ。リズムがあるのか。

彼は神出鬼没。颯爽と事件を解決する。街の人々は、正体不明の彼に、インターネットにまつわるコードをあててこう呼んだ。「ヒーロー404」と。「…さあこれからだというときに、スッと消えちまうんだよ。まったくもう役に立たねえなぁ、アイツは！」＜そっちかよ。

名探偵401とか。「この事件は、つまるところ…続きを聞きたいですか？ フフフ。ここから先は秘密です」＜使えねえなコイツ。

ソルジャー302とか。「…お前！？ また寝返ったのか！？」＜常習犯なのか。

そういや「仮面ライダー555」ってあったなぁ。「ゴー！ゴー！ゴー！か。勢いがあるなぁ」と思ったら「ファイズ」なんだもんな。やられた。オシャレさんだ。

新入社員1年目のときに、「デザインが趣味じゃないから」という理由で、同期の人からターボライターを貰って。たしか5〜6年ぐらい使えてた。最後は電熱線(?)が赤くならなくなって壊れたけど。…かなり長持ちしたあたり、実は高級なライターだったのでは、という不安もあるのだけど。自分は無学なのでそのへんさっぱりわからなくて。何にせよ、非常に快適に使えてたので感謝、みたいな。

どこのメーカーの品だったのだろう。あのくらい長持ちするのを、手元に一つだけ置いといて使いたいものであります。…でも、ターボライターってこのへんではあまり見かけない。何故。もう流行らないのだろうか。

自分が気になってたのは、この映像表現。最初に、その手法についてのテキスト情報のみ読んだときは、とても期待してたんだけど。予告編の映像を見て不安になってたわけで。

が。本編を見ると、戦闘シーンはテンションが高いせいもあって、それほど違和感はなかった。この手の企画なら結構使えそうな。

とはいえ。標準的というか、汎用性のある手法としては使い物にならない感も。やっぱり、アニメの3コマ撮りの感覚を実写に持ち込むのは無理があるのかな。なんとなくだけど、静止画にしたときの、一枚一枚の情報量が多すぎる・正確過ぎる気もしたり。何か処理をかけて、色なり、細部なり、画像情報を減らしたり等すれば、多少違ってくるかしら…。いや。その手の試行錯誤は既に行った上での最終的な映像であろうし。となると、やっぱりなかなか使い道がなさげではあるなぁ。

人形アニメ等で使えないかしら。NHK教育あたりで流れてるような、そういった作品で。…手間を考えるとそうそう使えないか。

テンポは速いし、上映(?)時間は短いしで。比較的飽きないうちに終わるよう作ってあるなと感心したり。また、間の取り方が上手いなと。やはり、アニメを何本も作ってきた監督さんらしい仕事振りかなと思ったり。

冒頭近辺に戦闘シーンを持ってきたことに感心。Vガンダムですかな。

ただ、竜頭蛇尾だったなと。特に最後のあたりはキリキリと同じになってて脱力。監督としては先輩格なのに、何やってんだかな、もう。トップランナーで「芸風を変えた」とか宣言してたわりには…相変わらずEVAと似たような自己完結ぶりというか、失速具合というか。…まあ、そのへんも含めて、色々期待し過ぎちゃってたのだろう。＞自分。あまり期待し過ぎてもガッカリするし、全く期待しないとそもそも見たくならないしで。そのへんなかなか難しいよなぁ。

これは自分の側にやましい何かが潜んでる故ではないか、という気もするんだけど。冒頭の入浴シーンとか、下着姿とか、そのへんで引いてしまった。何故なんだろうなぁ…。

例えば、男性がパンツ一丁で走ってたら、引いたりせずに笑えると思うのだな＞自分。しかし、女性が下着姿で走ってると、引く…。異性に対して、夢というか、ロマンチックな何かを期待してるのだろうか。かもしれん。うーん。

本来、他作品と比較すること自体、どうなんだとは思うのだけど。やっぱり気になっちゃうわけで。何せ、漫画・アニメを基にした実写化であり。主人公が、彼岸の世界（＜なのか？）から戻ってきた系のヒーローで、かつ、スタート地点では孤独でもあり。CG技術の発展・普及無しでは実現が難しかったであろう企画でもあり。共通点はいくつかあるわけで。…もっとも。男か、女か。後ろ向きか、前向きか。暗いか、明るいか。孤独なままか、仲間を求めるか。全てを破壊するか、和で収束させるか。違いが綺麗に対になってるところもあって。そのへんなかなか興味深かったり。

あちこちの感想記事を見たのだけど、「『CASSHERN』の監督とは格が違う」なる感想を目にして首を捻ったり。お前の目は節穴か！ というのは言い過ぎにしても。作品を見る限り、自分には、どっちも同種というか…格の違いなんかどこにあるねんと。庵野監督は経験年数が多いから、各種テクニックを知ってるだけというか…本質的には同じだろうと。どちらも、既存作品のコラージュ？ に終始せざるをえないという、アニメオタク第二世代特有？の限界が見え隠れしてるし。それに…。最後のあたりで、どうしてどちらも語り始めることで話を収拾させようとするねんな。ヤマトなり、富野アニメなり、そのへんの重力から逃れることができてない証拠やんか。…と思ったけどなぁ。

アハハ。こっちもか。キリキリの「イデオン」が、「ズバット＋安野モヨコ作品」になっただけちゃうんか(笑) にしてもその組み合わせは凄い。そりゃ、Pの頭の中でアラートが鳴り響くよなぁ…。＜勝手な想像。

どこかで、「デートコースの途中で見てもらえるような映画を意識して作った」云々という話も聞いたんだけど。「デートコースで『怪傑ズバット』を見せれば彼女にも喜んでもらえる！」的な監督の発想・思考からして、狂っててイイ、と思ったり。そういうの、自分は好きであります。

庵野監督自身があちこちで口にしてることだけど。宮崎監督や高畑監督あたりの世代と違って、どうしても、既存作品のイメージというか、TVや映画の、フレームで切り取られた・デフォルメされた・編集されたイメージの呪縛から逃れられない世代だから…。このへん、開き直って、肯定して、使っていくしかないわけで。結局、素材のチョイスと組み合わせ方で差をつけていくしかないんだろうなぁ。と自分などもぼんやり思ったりする。

モニタケーブルが短くて届かない。PCデスクとTVラックの隙間にフルタワーケースを押し込めて距離を稼いでどうにか接続。延長ケーブルでもあればな。

M/B ASUS P2B-S のBIOSを最新の1014beta3 にアップデート。 *1 DOSの起動FDに、aflash.exe と 1014beta3のファイルをコピー。FDで起動 → afalsh.exe 起動。1を選んで現在のBIOSをFDに保存。2を選んで1014beta3のファイルを指定。滞りなく作業終了。

ケースを隙間から引きずり出し、PenIII-500MHz と Celeron-700MHz + MSI MS-6905 Master(Socket370 → Slot1 変換下駄) を交換。…起動しない。BIOS画面すら出ない。ブザー音も鳴らない。M/B ASUS P2B-S上のFSBや倍率設定を弄ってみたり、 *2 CLRTCとやらのピンをショートさせてBIOS設定をクリアしてみるも変化無し。PenIII-500MHz を差し直すとちゃんと起動する。しかし、再度 Celeron-700MHz + MS-6905 Master を差し直しても起動せず。PCデスクとTVラックの隙間からケースを抜いてM/Bのピン設定を弄ってまた隙間に押し込めての繰り返し。…疲れた。ヘトヘト。諦めた。このM/BはPenIII 500MHzで動かすしかなさそう。 *3 それでも、今設置してるヘボサーバ機、無印 K6-200MHz の 2.5倍の速度だし。2.5倍といえば、赤い彗星までもう少し。そう考えると…なんだ！速いじゃないか！＜無理してる。

PenIII-500MHz に戻して、Vine Linux 2.6r4をインストール。特に問題なくインストールできた。NICも認識されてるので、apt-get update → apt-get upgrade を実行。滞りなく作業終了。後はサーバ機の設定を反映させる作業が残ってる。sshでログインできるだろうから、これからはモニタを繋げなくても、LANで繋がってさえいれば、メインPCのputtyからログインして作業ができるだろう。たぶん。

Celeron-700MHzが動かない理由についてもう少し調べてみた。PenII-500MHz(Katmai?)は2.00〜2.05V、Celeron-700MHz(Coppermine)は1.65v。そのへんかな。 *4 でも電圧関係は下駄でどうにかして…くれるのかどうかわからんな。…ああ、 _ダメみたいだ。

ASUS P2Bなど440BXマザーの初期のもので、CoppermineコアのPentium?やCeleronが動かないのは、Coppermineコアの必要とする1.80V未満の電圧を発生できないからです。CPUのコア電圧は、M/B側にある電圧コントローラICによって発生します。例えば、このときCPUから1.75Vの電圧を要求しても、1.80V以下は出せないので電源を入れてもCPUファンすら動きません。電圧コントローラICは、ATX電源コネクターの近くにあります。チップに印字されている型番はHIP6019CBになっているはずです。このチップでは1.8〜3.5Vに対応してます。電圧コントローラICのチップが、HIP6019BCBなら初期のM/Bではないのでコア電圧の問題はありません。「CB」か「BCB」のちがいを良く見てください。

残念。手元の ASUS P2B-S には、HIP6004ACB が載ってる。更に、 _こちらの1999/11/27の項 で詳しく書かれてた。

こ奴のV-coreのDC-DCコンバーターには、「HIP6004ACB」が使われており、DatasheetのPDFを落としてみました。「HIP6004」シリーズには、「HIP6004ACB」「HIP6004CB」「HIP6004BCB(BCV)」と3種類あるようですが、肝心の「HIP6004ACB」は唯一1.8V以下の生成ができない様です。ですから、私のP6-DBUはCoppermineには対応していないと思われます。BIOSが対応していても、電圧が・・・・(T_T) 製造ロットによっては、「HIP6004CB」「HIP6004BCB(BCV)」が使われている可能性もありますのでお持ちの方は調べてみて下さい。こちらはV-core 1.3V〜3.5V対応です。

なるほど。つまりこの ASUS P2B-S では Coppermine は電圧の問題で使えないということか。 _こちらのページ によると、 _PL-iP3 等のコア電圧生成機能つき下駄を使えば定格で動くと書いてあった。しかし、その手の下駄は安くても5千円ぐらいするし、今では入手不可に近いだろうし。

中古PCだと1万円台ですな。下駄を買うより省スペースな中古PCでも買ったほうが、場所取らない・電気食わない・うるさくない、でいいかもしれず。…でも余ったPCはどうなる。自分、貧乏性なので、もったいない、何かに使ってやらねばと強迫観念が。

カテゴリーの情報が足りなかったので「vine」を追記。

自転車道を無意味に分断していたガードレールが撤去されていた。ただしロープが張ってあったので、基本的には通らせるつもりはないようだが。それでも少しは改善されたということだろうか。

• 実写。当然だけど低予算。いや低予算というほどの予算すらかけられない。
• 家庭用ビデオで撮影した映像をPCに取り込んで編集。
• CGを多用して実写と合成。ミニチュアやアイテム等は実際に作らずにとにかくCGで表現。実際に作るとお金がかかるから。CGと実写の合成はバレバレでもOK。サイバーコップのようにとにかく「あんたそれは無茶だって」と言われるぐらいにシチュエーションを大事に。ツールも安いヤツで。お金無いから。
• ライダーのスーツや怪人のスーツは、ジャージにダンボール貼り付けただけとか、サングラスしただけで怪人とか、そんな感じ。とにかくチープで。お金無いから。
• チープさはヘビーな話や妙なレイアウトでカバー。こんな学芸会みたいな映像で、よくまあこんな話を、貴方達無茶ですよ、と言われるぐらいに。

• どこぞの組織から逃げてきた、強化スーツを開発したメガネッ娘博士。
• その博士とたまたま遭遇して、ひょんなことからスーツを着せられて博士を守る羽目になる、軽くてその場の雰囲気に流されやすい男の子が主人公。
• 肝は、戦闘シーン。音声によるコマンド入力でスーツの各種機能を動作させるところ。宇宙戦艦ヤマトの発進シーン、波動砲発射シーンのように、一つ一つの手順を示していく事で盛り上げる。
• 「何か必殺技とかないのかよ」とグチるとバイザーにコマンド一覧のヘルプが出てきたり。「おおー、スゲー色々あるじゃん」
• 「加速」と喋ると高速移動したり。
• ライダーキック一発打つのも大変。
  • 「放熱板オープン」で足周辺のあちこちの板が「カシャン！」と跳ね上がり、
  • 「○○モーター始動」で背中のランドセルから「ギュキュキュキューン」と何か回る音がして、
  • 「えーと、それから…（マニュアルを読む）…エネルギー伝達ライン、ポイント1Dから5Fで確保」でランドセルから足の先までの線が「ホワーン」と音を立てて光り、
  • 足の周辺から煙が「ボハーッ！」と広がる。
  • 「エイリアスセット。ジャンプタイプF、イコール、ライダー、アタックタイプCスタンバイ、イコール、キー、アタックタイプCエクゼキュート、イコール、ク、セットエンド」でコマンドをエイリアス定義して、
  • 走り始めて、
  • 「ライダー！」で地面に踏み込むと、足の周辺に空間が歪んだような輪が広がって、
  • 高くジャンプして、
  • 空中を飛んでる間に「キイーーー」と叫ぶと、足の裏から電極のようなものが「パシャッ！」と出て、
  • 敵を蹴るか蹴らないかのギリギリで「ーーック！」で、足の裏の電極が火花を出す。
  • 敵とライダーの間が大爆発。
  • 敵、吹っ飛び、ライダーも後方に吹っ飛ぶ。
  • ライダー、後ろの木に体をしこたまぶつける。
• 怪人を倒した後、ライダーのバイザーにブルースクリーン。
  • 「な、なにこれ？ えーと…システムが不安定になっています。システムをチェックしています…ってオイ」
  • と言ってる間に「アチ！アチャチャ！」背中が熱いような動き。「なにこれ？もしかして熱暴走ッスか？」
  • 「ああ、早くシステムチェック終われー！誰かこの青い画面をなんとかしてくれー！」が一応のオチ。

• ライダーと同じシステムを利用した敵が出てくる。しかし敵の方が処理速度が速い。
• ライダーの攻撃はことごとくかわされてしまう。逆にライダーは攻撃を避けることが出来ない。
• 博士がライダーと通信可能に。
  • 「ソイツに勝てるかもしれない方法を今から教えるわ」
  • 「マジ？ 勝つ方法あるの？」
  • 「あるわ。いい？ よく聞きなさい」
  • 「おう」
  • 「逃げるのよ！」
  • 「…（５秒ぐらいロングカットのまま動かないライダーと怪人）…（ライダーのアップで）ハアァ？」
  • 「聞こえたの？ とにかく逃げなさい」
  • 「あ、あんたソレ、全然勝つ方法じゃないじゃんか！」
  • 「グダグダ言ってる暇があったら逃げなさい！ 聞こえてんの？」
  • 「…ああ、もう、わかったよ、わかりましたよ…なんだよソレ…むちゃくちゃだよ…」
• 必死に逃げるライダー。追いかける怪人。通常の速度で撮影したビデオ映像に、早回ししたビデオ映像を合成。
  • 「（バイザーに表示された速度メータを見ながら）スゲー。時速70kmぐらい出てるよ。でもなんか…ビデオの早回しのような走り方がアレなんですけど…俺ってリアルチャップリン？」
  • 「見栄えなんてどうでもいいでしょ。まずは機能を実装することが先決なのよ。それより敵はどんな感じ？」
  • 「どんな感じって…アレ？」
  • ライダーが振り向くと、怪人の息が荒くなっている。動きも遅い。
  • 「なんかアイツ、動きが遅いよ」
  • 「今よ。戦いなさい。今なら勝てるわ」
• 仕掛けてみると面白いようにライダーの攻撃が決まる。
  • 「どういうことコレ？」
  • 「同じアーキテクチャなら処理速度の速いほうが消費電力も大きいし、熱の発生量も大きいから冷却の為に余分なエネルギーを使うわ。スーツ単体が持てる電力はどちらも同じ。長時間の負荷をかければ、性能がいいほうが先にバテるのは当然よ」
  • 「…はぁ、なるほど」
• 息も絶え絶えの怪人。
  • 「ひ、卑怯者…」
  • 主人公の代わりに博士が見栄をきる。
  • 「卑怯者？笑わせないで。技術ってのはね、トレードオフなのよ。何かを得れば何かを失う。それが基本よ。そんな事も知らずに、自分が扱ってる機械の特性も知らずに、見せかけの優位性を恥ずかしげも無く誇っていた貴方には、その技術を活かして勝利するだけの資格はないわ」
• ライダーパンチで怪人を倒す。
• 後日。
  • 「でもさ。優位性云々とか言ってたけど、やっぱり俺の着てるスーツって性能悪い方なんじゃないの？」
  • 「そうよ（即答）」
  • 「！ …そうよ、って…あんた！」
  • 「たぶん相手は、今後より優れたアーキテクチャを導入してくるでしょうね。そうなれば今回みたいな戦い方は無理。最悪こっちのほうが先にバテるかもしれない」
  • 「ちょっ、じょ、冗談じゃないよ。そんなヘボスーツで俺にこれから戦えって言うの？」
  • 「足りない部分はあなたの体力や精神力でなんとかしてちょうだい」
  • 「…無茶だ！無茶苦茶だ！あんた鬼だ！あんなに見栄を切っておいて結局最後は体力や精神力って…あんたおかしいよ！」
  • 「ってのは冗談なんだけどね」
  • 「へ？」
  • 「もう既にあちこち改良は済ませてあるわ。彼等の使ってる技術のほとんどは私が考案したもの。改良すべき点は既に判ってる。そう簡単に彼等に追いつかれるもんですか。…どうしたの？」
  • 「（机に突っ伏しながら）…なんかあんたと話してると、スーツとかなんとかより、俺自身がバテそう…」で終わり。

• 怪人に連戦連勝するライダー。調子に乗り、自分の力を過大評価し始めてしまう。
• 新たな怪人の前で油断して、ライダーは右腕を切り落とされる。
• 大量の出血、ショックの為に、意識を失い、心臓が停止するライダー。
• しかし博士はスーツを遠隔操作して、主人公の身体に様々な薬品投与、電気ショック等を行い、ライダーの生命活動を再開させてしまう。
• 意識の無いまま、博士の遠隔操作と、スーツを機能させる為の各種スクリプトの成果で、怪人と戦い勝利するライダー。
• 博士がスーツを解除してみると、そこには汗だらけで白目を向いた主人公の姿が。
• 主人公、ベッドの上で目を覚ます。
  • 「大丈夫？」
  • 「なんか…変な夢を見てたよ…俺の腕、切り落とされちゃってさ…」
  • シーツのかかったその先、シーツからはみ出た形で、主人公の手はちゃんとある。肌色の手。
  • 「はは、やっぱり夢だった。ビックリしたー」
  • 「ゴメン。夢じゃないのよ」
  • 「…え？ そんな、だって、ホラ、俺の腕あるじゃん。ちゃんと動いてるじゃん…」
  • 指を動かしながら少しずつ腕を持ち上げる。シーツがずり落ちる。手首から腕の付け根。そこは銀色の機械的な腕が。
  • 「！ …なんだよコレ…なんなんだよコレ！」で終わり。

• どこぞの部屋で主人公を慰めてる博士。
  • 「そんなに気を落とさないで。日常生活には何の支障もないはずよ。まだ人口皮膚をつけてないから見栄えは悪いけど、ちゃんとそのへんを整えれば」
  • 「そういう問題じゃないよ…」
  • 「性能だって凄いのよ。普通の人間の腕より力があるの。パワーシャベル以上よ」
  • 「…」
• 博士、気を紛らわせようと缶ジュースを主人公に手渡す。主人公、右手で缶ジュースを持つが一瞬で粉砕してしまう。
  • 「うわっ！」
  • 「あっ…まだ握力調整に慣れてないのね。圧力センサと神経の伝達が上手くいってないの。大丈夫、時間をかけて慣らしていけば」
  • 「…冗談じゃねーよ！なんだよコレ！シャレになんねーよ！俺は、俺は…化け物になっちまった…」
  • 「落ちついてちょうだい。今はまだ」
  • 「これが落ちついてられるかよ！」
  • 思わず右腕を振り回す主人公。その腕が博士にあたる。
  • 「あっ」
  • 軽く壁まで吹き飛ばされる博士。
  • 「！？」
  • 「…つつ…だ、大丈夫よ」
  • 腕の当たった腹を抑えながら苦痛に満ちた表情でヨロヨロと立ちあがる博士。
  • 居ても立ってもいられなくなり、博士の制止も振りきり、外へと飛び出していく主人公。
  • 「もう嫌だ！俺はもうこんなの嫌だ！」
• 主人公、街をさ迷ううちに、右腕の力で、何かしら人命を救うエピソードに遭遇。右腕、あるいはスーツに対する意識に変化が。
• 博士、飛び出していった主人公を探しているうちに敵に見つかってしまう。怪人に首を掴まれ宙吊りに。殺されそうになる。
• 「待ちやがれテメエ！」夕日をバックに立つライダー。
• 瞬間的に移動し、博士を宙吊りにしていた怪人の腕を、ライダーの右腕がブチ切る。怪人、苦しみながら後ずさり。
• ライダー、博士を背中にして庇いながら、
  • 「さっきはゴメン」
  • 「え？」
  • 「俺さ、やるよ。だってさ、これでやらなかったら、俺、なんか損しちゃったままだし」
  • 街で遭遇したエピソードの場面を回想しながら、
  • 「俺にしかできない事、ありそうな気がするんだ。だったら、俺はそれをしてみせる…」
  • ライダー、右腕をじっと見つめながら、
  • 「…こうなっちまった以上、それをしないと、なんか元が取れねー気がするんだ」
• 怪人に対して何か吹っ切れたように、物凄いラッシュを繰出すライダー。必殺技で終わり。
• 帰路につく博士と主人公。
  • 「でもさ、この腕も結構便利な事に気づいたよ」
  • 「？」
  • 突然、博士を右腕で抱き寄せる主人公。
  • 「！？ ちょ、ちょっと！」
  • 腕を引き剥がそうとするがビクともしない。
  • 「へっへーだ、無理無理。あんたの作ってくれた腕のおかげだよーん」
  • 「…この…ふざけんな！」
  • 夕焼け空のカットに「バチーン」。
  • ロングで、大振りで歩き去っていく博士。
  • 手前でウンコ座りしてほっぺたを抑えてる主人公。
  • 「いてて…いてーよ…」
  • 頬を何度もさすりながら、次第に笑顔に。
  • 「…はは、やっぱりこっちはいてーや…」
  • まるで頬の痛みを慈しむように、右腕で、何度も何度も笑顔でさすり続ける。

• 居酒屋で飲んでる怪人トリオ。最近成績が挙げられないという話から、悪の組織は必ず幼稚園のバスをハイジャックするらしいぞ、という話になり、それは名案、早速明日決行しよう、成功することを祈って乾杯、と呑み続ける。
• 翌日。幼稚園バスが来る場所に張り込んだはいいが、二日酔いが酷くトイレにかけこまずには居られない怪人トリオ。その間に幼稚園バスが来て、去って、別の似たようなバスが来る。
• トイレから帰ってきたトリオ。バスが来てるので行動開始。勢い良く乗りこんだはいいが。
• そこには幼稚園児の姿は一人も無く、なぜか爺さん婆さんばかりだった。どうやら老人ホームの慰安旅行（？）のバスらしい。
• 拍子抜けしてガックリきてる間に、扉がしまりバスは発進してしまう。途方に暮れる怪人トリオ。
• 毒気を抜かれてひとまず計画中止という事にはなったが、いかんせん二日酔いで弱っているので乗り物酔いをしてしまう。爺さん婆さんに介抱される始末。
• 普段若い人と話をする機会が少ないので、怪人達の同行を喜ぶ爺さん婆さん達。身の上話を聞かされ、怪人達、なんだかしんみり。で、仲良くなってしまう。せっかくだから一緒に旅行を楽しもうか、という話に。
• 目的地の温泉街に着き、バスから降りたところで、なぜかライダーと遭遇してしまう。ライダーは、日々の戦いの疲れを癒そうと温泉に旅行に来ていた。
• 怪人トリオを見たライダー、たちまち戦闘態勢に。しかし爺さん婆さんはアトラクションの一種と思い込み、仲良くなった怪人達を応援する始末。
  • 「お、おい、どうするよ。なんか俺達、『負けるな』とか言われてるぞ…」
  • 「どうするったって…そりゃもう、ここまできたらやるしかないだろ」
  • 「無茶言うなよ。相手は指名手配されてる凶悪犯だぞ。俺達なんかあっという間に殺されちまう」
  • 「バカ。真面目に戦えるわけ無いだろ。フリだよ、フリ。戦うフリすんだよ」
  • 「そ、そんな事言ってもよお。アイツ見ろよ、殺る気満々じゃないかよー無理だよー」
  • 「…わかった。俺がなんとか交渉してみる」
  • 斬り合うライダーと怪人。怪人、ライダーに小さな声でささやく。
  • 「あ、あのう…お願いがあるんですけどぉ…」
  • 「ハァ？」
  • 「しっ！ 声が大きい、小さな声で」
• ひとまず、ライダーを見逃す代わりに、自分達が勝ったかのような演技をしてくれという事でやり合いながら話はまとまる。
• いかにもわざとらしく負けるフリをするライダー。爺さん婆さん達大喜び。手を取って、怪人達に「勝ってよかったねぇ」と言葉をかける。
• ライダー、婆さんの一人から「あんたもよくやったよ。これはええもん見せてもらったお礼だ」と何かを渡される。
  • 「何それ？」
  • 「…なんか、俺、小遣いもらっちゃったみたい…なんでこうなるんだ？」
  • 「あれ？ 敵は？」
  • 「！？ そういや…あいつ等どこへ消えたんだ？」
• 怪人達はドサクサに紛れてその場から逃げ出していた。温泉街を肩を落として歩く怪人トリオ。
  • 「ああ…また計画失敗しちゃったな」
  • 「しかもライダーにまで会っちゃって…ついてねえよ」
  • 「どうする？ 見逃す、って約束しちゃったけど。やっぱり本部に連絡するか？」
  • 「バカ。もしも約束破った事がバレたらどうなる。俺達アイツに半殺しにされるぞ」
  • 「いや。半殺しじゃなくてマジに殺されると思うけど」
  • 「ついてねえな」
  • 「ああ、ついてねえ」
  • 「ハァ…」
• 歩く怪人トリオの目の前に、地酒が飲めるお店の看板が。
  • 「やっぱりヤなことは呑んで忘れるしかねーよな」
  • 「ああ」
  • 「ここは一つ、（お猪口をクイッとやる仕草）いきますかねぇ」
  • 足取りも軽く、店の暖簾をくぐっていく怪人トリオ。で終わり。

実写じゃ無理。メガネっ娘博士なんてどこから連れてくるのか。かといって漫画やアニメじゃありきたりだし。やっぱり寝言。

そもそもバイク乗ってないじゃん。なら、代わりに博士に乗るってのは…＜うわあ