mieki256's diary

ユーザエクステンションが入る場所は、以下で確認できる。

Inkscape を起動して、編集 → 環境設定、を選ぶ。



システム、を選択。ユーザーエクステンションという項目に、場所が表示されてる。右のほうの「開く」ボタンをクリック。



エクスプローラが起動して、ユーザーエクステンションの保存場所が開かれる。



手作業でユーザエクステンションをインストールしていく時は、このフォルダの中に各ファイルをコピーしていけばいい。

順番がちょっと逆になるけど、手作業でインストールする手順をメモしておく。後述の「エクステンション管理」機能を経由してインストールができるなら、そちらを使ってインストールしたほうがはるかに楽。

今回は、「Mirror」というエクステンションをインストールしてみる。これは、任意の直線を基準にして、図形を対称になるように移動/変形してくれる拡張機能。

_Mirror - Inkspace（Inkscapeのギャラリー） | Inkscape


ページを開くと下向きの矢印ボタンがあるのでクリックすると、zipファイルをダウンロードして入手できる。2023/11/30 の時点では、mirror_It7es4K.zip が得られる。



mirror_It7es4K.zip が入手できた。これをエクスプローラで開く。ちなみに、Windows10 x64 22H2 のエクスプローラは、zipファイルの中を覗ける機能を持っている。



zipファイル内には、Inkscape のバージョンに合わせたフォルダ群が入っていた。今回は Inkscape 1.3 で使いたいので、比較的バージョンが近い v1.2 をダブルクリック。



mirror.inx, mirror.py の2つのファイルが入ってる。両方選択して右クリック。メニューの中から「コピー」を選ぶ。



ユーザエクステンション保存フォルダの中で、右クリック。メニューの中から「貼り付け」を選ぶ。



mirror.inx と mirror.py が、ユーザエクステンション保存フォルダの中にコピーされた。ちなみに、何かフォルダを作っておいて(この場合は「Mirror」とか)、その中に入れたほうが管理は楽かもしれない。フォルダの中に入れてあっても Inkscape 上で反映される。



この状態で Inkscape を再起動すれば、追加したユーザエクステンションが、エクステンションメニュー内で項目として追加される。


一応、Mirror エクステンションの使い方もメモしておく。

1. 図形と、対称線になる線分を作っておく。
2. 図形をクリックして選択してから、対称線を Shift + クリックして、複数選択。
3. エクステンション → パスの変形 → Mirror、を選択。

対称線を基準にして、図形が移動した。

上記では手作業でインストールしたけれど、「エクステンション管理」を使ってインストールできるなら、そちらを使ったほうが簡単。

今回は、「Guide Creation Tools」という拡張をインストールしてみる。コレを使うと、色々な種類を選んでガイドを作成できる。

_Guide Creation Tools - Inkspace the Inkscape Gallery | Inkscape


エクステンション → エクステンション管理、を選択。エクステンション管理のウインドウが表示される。

1. Install Packages を選択。
2. 検索入力欄に単語を入力。「guide」と打ち込んで Enterキー。
3. 「Guide Creation Tools」がリストアップされたので、クリックして選択。
4. 「Install Package」ボタンをクリック。

もし、拡張の詳細を知りたい時は、拡張名を選択した状態で、左下の「Details and Comments」をクリックすれば、Inkscape公式サイトの該当ページがWebブラウザで表示される。


「Guide Creation Tools」がインストールされた。


ちなみに、この画面で該当項目をクリックして選択して、右下の「Uninstall Package」をクリックすれば、アンインストールすることもできる。


Guide Creation Tools の使い方もメモしておく。何か図形を選択した状態で、エクステンション → ガイド → Guide Creation Tools、を選択。



設定ダイアログが表示される。ここでは「プリセット」の中から「Centered」を選んで、「適用」をクリックしてみた。



選んでいた図形の中心線になるようなガイドが作成された。

以前、hsp3dish を使ってスクリーンセーバが作れるのか実験してみたけれど、その時の実験は失敗に終わった。

HSPの標準機能を使ってスクリーンセーバを作成する場合、フルスクリーン表示モードにおいては、以下のような状態で作ることになっている。

• HSP起動時に作られるウインドウID0には一切手を触れない。
• 表示ウインドウID2を新規作成して、そのウインドウID2に描画していく。

そういう仕組みにしておくことで、Windows用のスクリーンセーバに求められる細かい仕様は、HSP側でイイ感じに処理してくれるのだろう。たぶん。

しかし、hsp3dish は、表示ウインドウが必ず1つであることを強制する上に、必ずウインドウID0に描画するという制限がある。ウインドウID2が作れないし、ウインドウID2に描画していくこともできない…。

hsp3dishを使って、ウインドウID0をデスクトップサイズに変更して描画してみたが、一見それらしく表示されたものの、通常のスクリーンセーバのようには動作してくれなかった。マウスを動かしても、キーボードを叩いても、終了してくれない。これではスクリーンセーバにならない。

と、ここまでが前回の実験結果だった。

そこでふと、自前でキー押しやマウスカーソル移動を判定して、自分で勝手に終了してしまえばいいのではないかと思いついた。

また、多重起動禁止も盛り込んでおいた。と言うのも、Windowsのスクリーンセーバは多重起動されてしまう時があるらしいので…。このあたりも、HSP側がイイ感じに処理してくれないだろうから、自前で処理しなければならない可能性がある。

そんなわけで、それで上手くいくのか、実験をしてみたのだけど…。

実験に使ったソースは以下。

_ssstarh3d.hsp

使用画像は以下。

_star.png
_preview.png

動作させると以下のような画面になる。昔のWindowsに標準で入ってた「宇宙飛行」みたいなソレ。

この実験も失敗に終わった。

フルスクリーン表示モードは、一見それらしくなってるし、何かのキーを押すか、マウスを動かせば終了するようになったのだけど。

Windows10の、「スクリーンセーバーの変更」ウインドウで、hsp3dish を使って作ったスクリーンセーバを選んだところ、ウインドウ内の小さな窓に収まるようにプレビュー画像を表示することができなかった。別ウインドウが表示されてしまって、その中にプレビューが表示されてしまう。


HSPの標準機能を使ってスクリーンセーバを作る場合は、「スクリーンセーバーの変更」から与えられたウインドウハンドルに従って、ウインドウID0が小さな窓に収まるようにサイズその他が調整されるのだけど…。

hsp3dish を使った場合は、与えられたウインドウハンドルも、ウインドウハンドルから得られる情報もガン無視して、いつものように通常ウインドウを表示してしまうのだろう…。

そんなわけで、HSp 3.7 beta 7 の時点では、hsp3dish を使ってWindows用のスクリーンセーバは作れない ―― そう断言してもいいのかもしれない。無念。

多重起動禁止処理については、以下のページが参考になった。

_二重起動の防止(1) - Advanced HSP
_HSP講座 - プログラ広場 (mutex.as)

Windows の kernel32.dll が持っている、CreateMutex関数を利用することで、多重起動しているかどうかを判別できるので、ソレを使って多重起動禁止処理が作れるらしい。

紹介されているソースをコピペさせてもらって、手元でも動作確認してみた。

_test_createmutex_b.hsp

; 多重起動禁止テストその2
;
; 二重起動の防止（１） - Advanced HSP
; http://chokuto.ifdef.jp/advanced/singleton1.html    
;
; 2023/11/30, Windows10 x64 22H2 + HSP 3.7 beta 7

#packopt name "test_createmutex_b"  ; filename
#packopt type 0     ; generate ".exe"

; 多重起動をチェックするためのミューテックスオブジェクト名を定義。
; アプリ固有の名前であること。
#define MUTEX_NAME  "HSP_WinAPI_Test_Mutex"

; ----------------------------------------
; アプリケーションの起動チェックを行うモジュール
#module

#uselib "kernel32.dll"
#cfunc CreateMutex  "CreateMutexA" int, int, sptr
#cfunc GetLastError "GetLastError"
#func  CloseHandle  "CloseHandle"  int

#define ERROR_ALREADY_EXISTS    183

; アプリがすでに起動されているか取得する関数
#defcfunc AlreadyAppRunning str name
    if (hMutex == 0) {
        ; 名前付きミューテックスオブジェクトの作成
        hMutex = CreateMutex(0, 0, name)

        ; オブジェクトがすでに作成されていたかどうかの判別
        if (GetLastError() == ERROR_ALREADY_EXISTS) {
            ; すでに同じ名前のオブジェクトが存在する
            alreadyRunning = 1
        } else {
            ; オブジェクトが新しく作成された
            alreadyRunning = 0
        }
    }
    return alreadyRunning

; クリーンアップ処理（終了時に自動実行）
#deffunc CleanupAppRunChecker onexit
    if (hMutex != 0) {
        ; ミューテックスオブジェクトハンドルのクローズ
        CloseHandle hMutex
        hMutex = 0
    }
    return

; ----------------------------------------
#global

*start
    if (AlreadyAppRunning(MUTEX_NAME)) {
        dialog "すでに起動されています。"
        end
    }

    mes "二重起動してしません。"
    stop

生成された .exe を最初に実行すると以下のような表示になる。



その状態で、同じ .exe をまた実行すると、以下のような表示になる。OKボタンをクリックすれば終了する。



たしかに、多重起動禁止が実現できた。

デスクトップ上のマウスカーソル座標の取得でちょっとハマったのでメモ。

HSP の場合、ginfo_mx, ginfo_my で、デスクトップ上のマウスカーソル座標が得られる。

当初、mousex, mousey でマウスカーソル座標を取得しようとしたのだけど。これはアプリウインドウ内にマウスカーソルがある場合に、アプリウインドウ内のマウスカーソル座標を取得できる変数だった。アプリウインドウの外でマウスカーソルを動かして、反応しないな、おかしいなと悩んでしまった…。

コントロールパネルの電源オプション(電源プラン変更画面)へのショートカットもスタートメニューに登録しておいた。

1. コントロールパネルを表示。
2. 「システムとセキュリティ」をクリック。
3. 「電源オプション」の上で右クリック。
4. 「スタートメニューにピン留めする」を選べば登録できる。

電源プラン切替ソフトをわざわざ導入しなくても、これだけで良さそうな気もする…。

各電源プランへのショートカットファイルを作成する方法もあるらしいけど、今回はそこまでやらなかった。

Windows10 x64 22H2 + Ryzen 5 5600X で、電力プランを「省電力」にしたところ、タスクマネージャー/パフォーマンスの表示では、CPUクロックが1.7GHz固定になったように見えた。「バランス」にすると4.38〜4.43GHzをウロウロするので、省電力にすればたしかにクロックは落ちる模様。ネットサーフィンぐらいなら体感では問題無い印象。

ノード構成は以下のようにした。

• プレイヤーキャラは KinematicBody2D が担当。
• BGアタリを担当する TileMap は、背景の多重スクロールを担当する ParallaxBackground, ParallaxLayer の中に入れてしまうと正常動作しない。プレイヤーキャラと同階層に置いたら期待通りの動作をしてくれた。
• 単に表示するだけでアタリ判定をしないBGについては、ParallaxBackground, ParallaxLayer の中に入れてしまって問題無い。

重力については、プロジェクト設定の中で値を指定することができる。




プロジェクト設定のインプットマップで、move_left, move_right, move_up も追加。



プレイヤーキャラを動かしてるスクリプトは以下。KinematicBody2D にスクリプトをアタッチした。

_KinematicBody2D.gd

extends KinematicBody2D

export var walk_force = 2000.0
export var walk_max_speed = 400.0
export var stop_force = 1600.0
export var jump_speed = 960.0

var velocity = Vector2()
var gravity
var jumping = false

func _ready():
    gravity = ProjectSettings.get_setting("physics/2d/default_gravity")

#func _process(delta):
#   pass

func _physics_process(delta):
    var right = Input.get_action_strength("move_right")
    var left = Input.get_action_strength("move_left")
    var input = right - left
    var walk = walk_force * input
    if abs(walk) < walk_force * 0.2:
        velocity.x = move_toward(velocity.x, 0, stop_force * delta)
        # velocity.x = 0
    else:
        velocity.x += walk * delta
        # velocity.x = walk_max_speed * input
    velocity.x = clamp(velocity.x, -walk_max_speed, walk_max_speed)
    velocity.y += gravity * delta

    var snap = Vector2(0, 32)
    if is_on_floor():
        jumping = false
        if Input.is_action_pressed("move_up"):
            velocity.y = -jump_speed
            jumping = true
            snap = Vector2.ZERO
    else:
        snap = Vector2.ZERO
        
    velocity = move_and_slide_with_snap(velocity, snap, Vector2.UP, true, 4, deg2rad(60))
    # velocity = move_and_slide(velocity, Vector2.UP)
    
    _set_label_text("velo: (%.2f, %.2f)" % [velocity.x, velocity.y])
    
    if right > 0.5:
        $Sprite.flip_h = false
    if left > 0.5:
        $Sprite.flip_h = true
    
    if jumping:
        $Sprite.frame = 2
    elif is_on_floor():
        $Sprite.frame = 0
    else:
        $Sprite.frame = 1

func _set_label_text(t):
    $Label.text = t

• gravity = ProjectSettings.get_setting("physics/2d/default_gravity") で、プロジェクト設定の default_gravity を読み取ってる。
• KinematicBody2D は一定の時間間隔で _physics_process(delta) を呼び出すので、その中に移動処理を書く。
• _process(delta) も一定の時間間隔で呼ばれるけれど、状況によっては物理計算・衝突判定が正しく行われないのだとか。アタリを持ってるオブジェクトは _physics_process(delta) 内で処理をせよ、ということになっているらしい。
• Input.get_action_strength("xxx") で、xxxキーやxxxボタンを押したかどうかが 0 〜 1 の値で得られる。アナログジョイスティックを割り当てた時には、おそらく 0.n の値が返ってくるのではないか。たぶん。
• velocity = move_and_slide_with_snap() でBGアタリとの衝突判定＋補正処理をする。内部で delta を使って計算しているらしいので、与えるベクトルに対して事前に delta を掛けておかなくてもいい。
• move_and_slide*() を呼んでおけば、is_on_floor() で床の上に立っているかどうかを調べられる。立っていたら true。立ってなかったら false。
• move_and_slide() と move_and_slide_with_snap() の違いは、前者が斜め床に非対応で、後者が斜め床に対応 ―― 床に吸着して移動ができるらしい。
• move_and_slide_with_snap() は斜め床にも対応しているけれど、ジャンプしようとした時も床に吸着されてジャンプできなくなるので、ジャンプ時は吸着用(?)ベクトルを 0 にする。(Vector2.ZERO = Vector2(0, 0))

move_and_slide_with_snap() に渡すパラメータは色々あってややこしいけど、おそらく以下のような内容かなと…。

Vector2 move_and_slide_with_snap ( Vector2 velocity,
                                   Vector2 snap,
                                   Vector2 up_direction,
                                   bool stop_on_slope,
                                   int max_slides,
                                   float floor_max_angle,
                                   bool infinite_inertia )

• velocity ... 移動ベクトル。単位はピクセル/秒。1秒で何ピクセル移動するか。
• snap ... 床への吸着用ベクトル。このベクトルの範囲内に床があった場合は床に吸着されるので、斜め床に張り付いたまま動ける。
• up_direction ... 上方向を指定する。Vector2.UP (= Vector2(0, -1)) を指定。省略時はデフォルト値 Vector2(0, 0) が入る。
• stop_on_slope ... true なら、Body(?)が静止してる場合に斜面の上で滑らなくなる。デフォルトは false。
• max_slides ... 衝突してから静止するまで何回スライドするか、らしい。デフォルト値は4。
• floor_max_angle ... 床として扱う角度を指定。デフォルトは 0.785398ラジアン(45度)。BGアタリに45度の床が混ざってると床として扱われなくなるので、その場合は 45度以上を指定してやると良いらしい。ちなみに、deg2rad(度) で度をラジアンに変換できる。
• infinite_inertia ... RigidBody2D への反映を変化させるらしいが…よくわからない。

_2D移動の概要 - Godot Engine (stable)の日本語のドキュメント
_キネマティックキャラクター(2D) - Godot Engine (stable)の日本語のドキュメント
_KinematicBody2Dの使用 - Godot Engine (stable)の日本語のドキュメント
_KinematicBody2D - Godot Engine (stable)の日本語のドキュメント
_KinematicBody2D の基本 - Qiita
_Godot Engine - Godot 3.1 will get many improvements to KinematicBody
_godot-demo-projects/player.gd at master - godotengine/godot-demo-projects
_【Godot】TileMapのコリジョンからタイル情報を検出する - 非常口blog
_Difference between move_toward() and lerp() - Godot Engine - Q&A
_Move_and_Slide_With_Snap Failing When Jump From Slope - Godot Engine - Q&A
_Move_and_slide_with_snap() is consistently inconsistent : godot
_Help with Move_and_Slide_with_snap. Wont stay on slope. : godot
_Problem with move and slide with snap function : godot
_move_and_slide_with_snap issue : godot
_KinematicBody2D: move_and_slide_with_snap won't snap to slopes - Issue #26274 - godotengine/godot
_Kinematic body slides off slopes that is supposed to snap to when landing - Issue #30777 - godotengine/godot
_move_and_slide_with_snap 3D KinematicBody not snapping on slopes - Issue #38564 - godotengine/godot
_KinematicBody player with RayShape does not respect snap argument in move_and_slide_with_snap() - Issue #34098 - godotengine/godot
_The player (kinematic body) continues to slide down the slope after I have stopped moving it - Godot Forum

もしや、GIMP側のフィルタメニューの該当部分が、何かしらでブロックされているような状態になってたりしないかと不安になってきた。

試しに、vignetting.c のメニュー登録部分を、<Image>/Filters/Map/Texturize... に変更してビルド。これで登録できなかったら、ブロックされてる可能性も考えないといけない。

ちゃんとメニューに出てきた。ということは、GIMP側で該当メニュー部分をブロックしているとか、そういうことはないようだなと…。

ひょっとして、.cpp(C++ソースファイル)が含まれていることが原因だったりしないか。試しに、C++で書かれたソースは除外して、Cで書かれたソースのみでビルドするよう修正して動作確認。

この状態なら、フィルタメニューに項目が出てきた…。

ということは、Cだけでソースが書かれてる場合はフィルタメニューに登録することができるけど、C++で書かれたソースが混ざってるとフィルタメニューに表示されない状態になる、ということかなと…。

.c だけなら、リンク時に gcc.exe を使うし、.cpp があるなら、リンク時に g++.exe を使うようにしているけれど。リンカ用のオプション指定で回避できるのだろうか。それとも GIMP側に何か追加しないといかんのだろうか。

一応操作方法をメモ。

基本的にはマウスクリックで動作する。

• WAVE ID <n> : 現在アクセスしてる波形メモリのID。0〜15まで選べるが、0〜3はデフォルトで波形が入っているので変更できないようにしてある。
• READ : 波形メモリの読み出し再生モード。
• MAKE : 波形生成モード。
• PLAY : 1秒間隔で音が鳴り続ける。
• STOP : 音を停止。
• Sync : 現在の波形メモリ状態を、cart に記録。
• MAXI : SFXエディタと同じサイズで波形を表示。
• OCT : オクターブの指定。
• AJST : 音量自動調整。
• RSET : 周波数設定のリセット。
• スライダー : 音量や位相の指定値。
• 波形アイコン : sin波(正弦波)、矩形波、ノコギリ波、三角波の切り替え。

下のほうに2つのスライダー群があるけれど、左が周波数の音量指定。基準となる周波数(440Hz)の1倍、2倍、3倍…10倍、と並んでいる。

右のスライダー群は、位相(角度)の指定。-180度 〜 +180度を指定できる。

一番左のスライダーは、全体の音量。

スライダーの上で左ボタンクリック or ドラッグすると値を変更できる。中ボタンクリック(ホイールクリック)で、値をリセット。

この wavetest2.tic で作成したSFX(効果音)の波形メモリを、自分が作成中の cart に流用したい場合は、load コマンドが使える模様。

load wavetest2.tic sfx

最後に「sfx」を指定して load しているので、wavetest2.tic のSFX領域データだけが、現在開いてる cart の SFX領域データに読み込まれる。ソースコードやスプライト画像の領域は上書きされない。はず。たぶん。

設定は、Edit → Preferences → Setting: User を選ぶと開かれる、user.lua に追加していけばいいらしい。たぶん。

今回は以下のような設定を追加してみた。

-- font setting
editor.fontname = "Consolas"
-- editor.fontname = "MigMix 1M"
editor.fontsize = 13

-- indent setting
-- editor.tabwidth = 2  -- default
editor.tabwidth = 1

上記の例では、フォント種類、フォントサイズ、及び、インデント幅を設定している。記述してから ZeroBrane Studio を再起動したら設定が反映された。

設定内容については、以下が参考になる。

_Editor Preferences - ZeroBrane Studio

ショートカットキーも追加してみた。

-- add shortcut key
editor.keymap[#editor.keymap+1] = {('E'):byte(), wxstc.wxSTC_SCMOD_CTRL, wxstc.wxSTC_CMD_LINEEND}
editor.keymap[#editor.keymap+1] = {('K'):byte(), wxstc.wxSTC_SCMOD_ALT, wxstc.wxSTC_CMD_DELLINERIGHT}
editor.keymap[#editor.keymap+1] = {wxstc.wxSTC_KEY_UP, wxstc.wxSTC_SCMOD_ALT, wxstc.wxSTC_CMD_MOVESELECTEDLINESUP}
editor.keymap[#editor.keymap+1] = {wxstc.wxSTC_KEY_DOWN, wxstc.wxSTC_SCMOD_ALT, wxstc.wxSTC_CMD_MOVESELECTEDLINESDOWN}

この例では、以下のショートカットキーを追加している。

• Ctrl + E : 行末まで移動
• ALt + K : 行末まで削除
• Alt + Up : 行を上に移動
• Alt + Down : 行を下に移動

このIDEは、 _Scintilla を利用しているようで、ショートカットキーの設定などは、Scintilla の設定その他が参考になる模様。

_Editor Preferences - ZeroBrane Studio
_KeyBindings - Scintilla Documentation
_KeyboardCommands - Scintilla Documentation
_[ZeroBrane Studio] Copy/move line keyboard shortcuts - zerobrane - FreeLists
_[ZeroBrane Studio] Re: Copy/move line keyboard shortcuts - zerobrane - FreeLists

「editor.keymap[#editor.keymap+1] = { 〜 }」と書くことで、editor.keymap というテーブルの最後に設定を追加しているのだろう…。

ショートカットキーの設定は、

{ キー種類, 修飾キー, コマンド }

という形で並べていくのかなと。修飾キーの種類には、以下があるらしい。

• wxstc.wxSTC_SCMOD_CTRL
• wxstc.wxSTC_SCMOD_SHIFT
• wxstc.wxSTC_SCMOD_META
• wxstc.wxSTC_SCMOD_ALT

2つ以上の修飾キーを指定したい場合は、

wxstc.wxSTC_SCMOD_CTRL + wxstc.wxSTC_SCMOD_ALT

といった形で書くのかな。たぶん。試してないけど。

コマンドの種類については、 _Scintillaのソレ を眺めて処理内容を想像しつつ試しに書いて動かしてみるしかないかな…。wxstc.wxSTC_CMD_コマンド名、と書くっぽい。

カラーテーマというか配色を変更したいなと思ってググってみたら、以下が参考になった。

_Changing color theme in ZeroBrane Studio

ZeroBrane Studio のインストール場所に、cfg/scheme-picker.lua というファイルがあるので、ZeroBrane Studio で開いてみる。コメント部分に、色々なテーマ名が並んでいるので、それぞれをマウスでクリックしてみると色が変わるので…。これだな、と思ったテーマ名で、user.lua に以下のような感じで記述。

styles = loadfile('cfg/tomorrow.lua')('Monokai')
stylesoutshell = styles -- apply the same scheme to Output/Console windows
styles.auxwindow = styles.text -- apply text colors to auxiliary windows
styles.calltip = styles.text -- apply text colors to tooltips

この場合は、Monokai を選んでる。

Notepad++ 風にしたい場合は、

styles = loadfile('cfg/tomorrow.lua')('NotepadPlusPlus')

と書く模様。

以下から入手できるらしい。

_pkulchenko/ZeroBranePackage: Packages for ZeroBrane Studio (https://studio.zerobrane.com)

インストールの仕方は以下。

• ZeroBrane Studio インストール場所の下にある packages フォルダの中に .lua を入れる。
• もしくは、~/.zbstudio/packages/ フォルダを作ってその中に .lua を入れる。

_「バトルガレッガ Rev.2016」，秋葉原Heyにて期間限定でアーケード版の稼働を実施。敵弾カラー変更の紹介ムービーの公開も - 4Gamer.net

敵弾の表現として、以下を用意してるらしい。

• 1パターンを表示するだけ。
• 弾の色を赤と青で構成。点滅無し。
• 弾の色を赤と青で構成＋白も挿入して点滅有り。
• 弾の色を赤と青で構成＋グレー？も挿入して点滅有り。
• 弾の色をピンク＋白を挿入して点滅有り。

「刺激性の強い色使いにする」「点滅させる」てなあたりが策だろうか。しかし、アーケード版は何もしてなかったというのが気になる。何もしないほうが、パッと見ではリアルな画面に感じる、てなことだろうか。まあ、現実世界では、点滅する存在のほうが珍しいわけで。

しかし、点滅させればいいというモノでもなさそうな。例えば以下のタイトル。

_Hyper Duel (Arcade/Technosoft/1993 Keith) [HD] - YouTube
_Sega Saturn Longplay [006] Hyper Duel - YouTube

アーケード版に比べると後者のコンシューマ版のほうが敵弾が描き込まれていてリッチさが増してるけど、かえって見づらくなってないか、という気もするわけで。

_四色カラーで視認性を上げるために: ドット絵とアイデアと

4色しか使えない環境では、黒で縁取ることで視認性が上がる、という話が出ている。アタリが存在するものは輪郭をハッキリさせる、という方針というか。

_回転と点滅、どっちが目立つ？表示灯の点灯方式の違いについて - LED回転灯.com

ゲームのグラフィックの話ではないけれど、警告灯は、回転と点滅のどちらが目立つか、という話らしい。回転するほうがより目立つ、ということかな…。

回転する敵弾と言えば、このあたりだろうか。

_レイディアントシルバーガン - YouTube
_1988 [60fps] Gradius II Type4 Nomiss Loop1 - YouTube

_【東方】最近光る弾多くないかな…以前の境目がある弾の方が見やすいと思う｜2ch東方スレ観測所

加算描画を多用して光らせる事例が多くなってきてるけど、避けづらくなったという苦情が出てる。考えてみれば、4色で画像作成する話で出ていた、「アタリが存在するものは輪郭をハッキリさせる」という方針と真逆なわけだから、そりゃプレイしづらくなって当然かもしれないなと。ただ、加算描画って見た目が奇麗だから、ウケがよさそうではある…。

「拡張ボタンが押しやすくなった」というのが今回の製品の売りらしいけど。どちらかというと「今までより随分と押しにくくなったから、誤操作せずに済みますよ」てな言い方のほうが正しい気がしたり。

拡張ボタンは、以前の形状に比べると自己主張が弱くなったというか、ボタンの高さが抑えられているのだけど。そのせいか、しっかり奥まで、グイッとかなり力を入れて押し込まないと、反応してくれないようで。…あくまで、今までの製品と比べたら、だけど。

自分の場合は、以前の形状・反応のほうが全然良かったなと。これでは中ボタン代わりに使えない。横から結構な力を入れて押さないといかんから、当然ポインタがずれるわけで、つまりポインタを動かさずにボタンが押されることを前提とした操作を拡張ボタンに割り当てることができない。まあ、フツーの人はブラウザの戻る・進むぐらいしか割り当てないのかもしれないけど…。自分は中ボタン代わりに使ってたから、コレでは困るわけで。 *1

おそらくこのあたり、以前の製品・形状に対して、「こんなに軽々と反応するようでは拡張ボタンをうっかり押してしまうではないか」と文句を言った人達が結構居て。その意見を反映させて、あえてこういう設計に変更したのだろうけど。

しかし、そもそもアレは、「拡張ボタンは要らない派」の発言だから、まともに聞いちゃダメだったのではないか、という疑念が。例えば「拡張ボタンは絶対に必要派」が、「2つの拡張ボタンが邪魔」なんて発言をするものだろうか。否。するわけがない。故に、文句言ってた人達は滅多に拡張ボタンを押さない人達であろうと推測できるわけで。

つまり、拡張ボタンがついてない3ボタンマウスを新規に発売すれば良かったのであって、拡張ボタンを押しにくくするのは方針を間違ったのではないかなあ、と自分は思ったのでした。

さておき。一応、前回同様、拡張ボタンに100円ショップで買ったポッチっぽいシールを貼り付けたり。

拡張ボタンにポッチをつければ、「あ、ここが拡張ボタンだ」とすぐに分かるし、誤操作だって減ると思うのだけど、どうしてどのメーカもポッチをつけないんだろう…。指の腹で触っただけでボタン種類が分かるのは、とても便利・快適なのだけどなあ。

写真を何枚か撮ってたので一応アップロード。

それまでの会話とは脈絡なく(?)、いきなり、無表情な相手キャラの顔にめがけて、数秒かけてじわじわとズームインするカットがあって。「ズズズ」だか「ゴゴゴ」だかのSEつき。その後、主人公が、「…アレ？ もしかして…怒ってる？」と尋ねるのですが。

自分、見ていて、まずは「え？ 何？ どういうこと？ 何が始まったの？ 何を伝えようとしているの？」と思ってしまって。

そのうち、そのカットの長さに次第に笑えてきて。「意味分からんけど面白いなコレ」と。おそらく、突然の意味不明なカットの出現で緊張した後、その見せ方が延々と続くことで緊張の緩和へと繋がり、故に笑えたと思うのですが。緊張と緩和。コレ、笑いを生み出す基礎テクニック、ですよね…？

そしてその後、主人公の台詞を聞いて、「ああ！ そういうこと！ これは考えたなあ…」と感心してしまったのです。

そのシーンは、主人公が相手の表情を読み取れず、困惑してるシーンなわけです。そして視聴者も、カットの意図が分からずに、困惑させられた。つまり、「困惑」という点で、主人公と同じ気持ちへと、視聴者の気持ちを誘導してみせた ―― 主人公と視聴者の気持ちをシンクロさせることを試みたシーン、だったのだろうと。なので、「コレ、上手いなー。こんな場所でそんなテクニックを使ってくるかー。しかも笑えたし」と感心しちゃったのでした。もっとも、もしかするとそこまでの演出意図は無くて、結果的にそうなったという話かもしれませんけど。

たぶん、脚本はこんな感じだったのかなと勝手に想像するのですけど。

○○、無表情なまま怒っている。
主人公 「…アレ？ もしかして…怒ってる？」

コレ、フツーの演出家さんなら、「無表情で怒る…？ そんなのどうやって見せろと…。ああ、もう、ここは主人公の台詞で説明したことにしよう」で済ませるよなと。そして、一瞬だけ相手の顔を見せて、すぐさま主人公に台詞を吐かせてハイ終わり。これっぽっちも面白くないコンテになりそうな。そのうえ下手すると、脚本家さんに向かって、「君、脚本家向いてないよ。小説家になったほうがいいんじゃない？」と余計なことまで言い出しかねない。…それがフツーかなと。

でも、この演出家さんは、「待てよ？ ホントにソレ、表現できないの？」と、チラッと思ってみたんじゃないかと。そして、「ハーイ、TVの前の皆、この娘の表情に注目！ よーく見て。何かを思ってるんだよ。読み取ってー。でも、無表情だから全然読み取れないよね？ では、主人公さん、説明をどうぞ」てなカットを試してみたのかなと。結果、笑える見せ方が誕生したわけで。

こういう姿勢、自分は好きでして。フツーはスルーしてぞんざいに表現しちゃう個所だって、拘ってみれば、こうして技が一つ生み出せる。こういうの、大事だと思うんですよ。

以前、とある演出家さんが、爆発シーンで爆発音が遅れて聞こえてくる表現に拘ってみたら音響の人から褒められた、とblogで書いてたのですが。そういうの、とても大事だよなと。今後、その演出家さんは、似たようなシーンが出てきたときに、その技が使えることに気づくはずで。拘ったことで、手持ちの技が一つ増えた。漫然とコンテ切ったり、漫然と演出してたら、その技はゲットできなかったよなと。

一話につき、たった一ヶ所でもいいし、どんな些細な部分でもいいから、何かしら拘ってみる…。拘れば、その時に、えてして何かしら技が生まれる。そうしてどんどん技が溜まっていけば、どんな脚本が届いても立派な見世物に仕立て上げる職人へと成長できるんじゃないか、と、自分は思いたいのです。一話につき一つでも、コンテを千本切れば、達成した暁には千の技を持つ男、ですよ。たとえ凡人でもそれなら到達できるんじゃないか、みたいな。…や、なんか途中でネタ切れしそうではありますが。

ていうか、宮崎駿監督も富野監督もそうですわな。あの年齢でも未だに、「今回はここに拘ってみた」等を仰ってる。やっぱり、拘らないと、技が身に着かんところがあったりするのかなと。

もちろん、全カットでそんなことしてたら疲弊して潰れちゃって引退会見開くところまで行っちゃうし、悩んだ分だけ手は遅くなるのでスケジュールが遅れていって次から仕事こなくなったりしそうですし。だから、「ほどほどに」「その時できる範囲で」も、大事だろうなと思うんですけど。

てなわけで、そのシーンを見て笑った後、演出家さんの「一工夫」を惜しまなかった姿勢に、TVの前から拍手を送りたくなったのでした。まあ、以前の作品で悩んで見つけた技だったのかもしれないのでアレですけど。何にせよ、件のシーン、自分は面白いと思いました。

風呂場のシーンで、ボケ→ツッコミ→ボケ→ツッコミ→ボケ→ツッコミ、と3回繰り返すシーンがあって。…3回だったかな。たぶん。その3回とも、同じレイアウトでツッコミをしていて。しかも、ツッコミする際、「ズドーン」だか「ドゴーン」だかド派手なSEを追加していて。ツッコミ台詞自体は、フツーのよくある台詞なんですけど。何故そんな台詞に、こんなSEを、と。

同じレイアウト、ド派手なSE、そしてそれを3回繰り返す。その一連の流れを見て、笑いながら感心を。繰り返しで生まれる笑いを意識して盛り込んでるコンテだなと。

3回繰り返すってのは…。子供向け番組を作る際の定石としてあるらしいですな。

_「テレタビーズ」の魅力と昔話 - 子どもにとっての面白さ(pdf)

子供が笑うってことは、たぶん本能的な部分で笑えるということだろうから、大人向けコンテンツでも結構有効なのかなと思えてきたり。

また、同じレイアウトで見せる点は、なんとなく細田演出を連想したりもして。自分、同ポジ演出の効能については詳しく考えたことがないんですけど、分析した人なら、「その見せ方、イケるよね」と説明できたりするんでしょうな。

主人公が、「何…この状況…？」と混乱してるシーンで、よく分からない人の声が入ったBGMが流れてきまして。見ていて、「なんなんだ、このシーンは」と笑ってしまいました。理解不能な状況を、意味不明なBGMでブーストしてる。音楽の力は偉大ですな…。

そういや、「アウトブレイクカンパニー」で、少し前に放送された回でも、「ダ、ダダダ」てな人の声入りのBGMが使われてて。「このBGM、実にいいなあ。おかげで、なんともいえない奇妙な場面になってるよなあ」と感心したことを思い出したり。

考えてみたら、人の声が入ったBGMって、パワーあるよなと。

• ヤマトの「アー、↑アー」も。
• ルパン三世の「ルパンルパーン、ワーオ！」も。
• ゲームだけど、ダライアス外伝のBGMも。
• AKIRAの「ラッセラ、ラッセラ」も。

それぞれ思い返してみると、パワーありますよね…。

もっとも、パワーがあり過ぎて、使いどころは難しいだろうと思うのですけど。故に、頑として楽器音だけでBGMを鳴らす作品がほとんどでしょうけど。しかし、人の声が入ったBGMは、ハマるとスゴイ。効果絶大。だよなと。

「○○様、○○です」「ブー(飲み物を勢いよく吹き出す)」というカットがありまして。その、「ブー」に繋げるタイミングが絶妙やなと感心を。間髪入れず、みたいな。フレーム単位で調整したんじゃないのと思えるぐらいに絶妙。また、「ブー」で吹き出される飲み物の量も尋常じゃなくて、そこも笑ってしまったり。

漫画やアニメでは、よくあるシーンですよね。ネット上ではAAにもなってるぐらいで。だから、珍しいシーンというわけではない。だけど、タイミングだけで笑えてしまって、直後に、「今回の演出家さん、上手いわ…」と唸ってしまいました。

「ブー」をどう表現するか、どんな演出で仕上げるかは、演出家の試金石、リトマス紙じゃなかろうかと、時々思うのです。

今回見たソレは、「ブー」が出てくるタイミングを詰めていく派。仮で、「詰めブー派」と呼びますけど。

当人にとって衝撃的な言葉を聞いた瞬間、思わず、口に含んでた飲み物を吹き出してしまうソレについて、吹き出すまでの時間が短ければ短いほど、衝撃が大きかったと伝わってくれるだろう、視聴者にとっても飛躍が感じられて笑いに繋がるだろう、だから、大げさにしたほうがいい、間髪入れずに見せたほうがいい、てな理論武装があるんじゃないかと自分は想像してるのですが。

「詰めブー派」は、おそらくちゃんと考えて演出してる人達でしょう。どんな光景を見た時に人は笑ってくれるのか、そこを考えてみたことがある人じゃないと、そもそも「詰める」ことができないはずだと。…映像制作は、何も考えずにやっていくと間延びしますから。意識しないと「詰める」ことはできなくて。 *1 もちろん、あまり考えずに手癖でそういう見せ方をしてる演出家さんも多いでしょうけど。しかし、そういった演出家さんも、どこかの時点で、「ブー」のベストタイミングについて自分なりに一度は悩んでるはずで。考えてみた時期がちゃんとあるから、詰めることができてる、と想像するのです。

そして、「詰めブー派」と別に、もう一つの派閥があって。相手の台詞を聞いてから、確実に一呼吸おいて、そこから「ブー」をさせる派。とりあえず「待ちブー派」と呼びましょうか。

この「待ちブー派」。時々見かけるんですけど、正体というか、意図がよく分からない。というのも、「待ちブー派」にも二種類あると思うのですね。

一つは、「この作品はリアルに見せるべき」と思ってるから、あえて「待ちブー」で見せてる人達。

現実世界の人間も、飲み物を「ブー」とやっちゃう瞬間はある。だけど、その場合、間髪入れずに「ブー」はしないよねと。相手の言葉を脳で反芻して理解してから「ブー」をする。だから、一呼吸が必ず入るはずなんだ、と。

それに加えて、現実には「ブー」なんて勢いよくやらないよと。フツーは「ブピュッ」とか「ゴフッ」ぐらいのものだろうと。いつまでも勢いよく液体が飛び出し続けるなんてありえない。だから、そんな画にはしない。それじゃ漫画だよ。

てな考えなのかなと想像するのですよ。おそらく、こういう方向の演出は、笑わせることは重要視してない。「飲み物を吹き出しちゃうぐらいに、このキャラはビックリしました」と、それだけ伝われば充分だと。これはこれで、納得できる見せ方で。ちゃんと考えてるなあ、と思うのです。

で、もう一つは…。おそらく、たぶん、もしかすると、何も考えてない人達。

例えば、一呼吸入れておきながら、勢いよく液体が吹き出す画を入れたりすると、自分は首を傾げてしまうのです。一呼吸入れるということは、リアルに見せたいんだろうと。漫画っぽくしたくないんだろうと。なのに、その後に出てくる画は漫画。君は、笑わせたいのか、笑わせる云々はどうでもいいのか、リアルにしたいのか、したくないのか、一体どっちなんだと。

コレ、たぶん何も考えてなくて、「お約束」でコンテ切ったり演出してるんじゃないかと、自分は邪推してしまうのです。

しかも、そういう人達は、映像作品を作るにあたっては、時間制御が大変重要なのだと、どうやら全然気づいてない節もあって。あちこちがとにかくダラダラしてたりもして。

ということで、「ブー」を見ただけでも、「この演出家さん、ちゃんと考えてるなあ。真摯に仕事に取り組んでるなあ。できれば応援してあげたいなあ」と思う時もあれば、「この演出家さん、何も考えてねえや…」と疑ってしまう時もあるのでした。 *2

そんなわけで。今回の「詰めブー派」の鮮やかなソレを見て、「さすがや…こういうところをちゃんと抑えてくる演出家さんは、こりゃ間違いなく職人さんやで…まるでお手本のような『ブー』だった…眼福眼福」と自分は感心しちゃったのでした。

いくら感心したとはいえ、この記事、長すぎますわ…。

自分、素人なので、「詰める」ことを意識できてないんですよねえ…。

HDDから消す前にもう一度眺めてみたら、「詰めブー派」のあたりはちょっと怪しかったかも…。リアルタイムに見た時は、絶妙だと思ったんだけどなあ…。深夜だったから、自分の時間感覚がおかしくなってたんだろうか…。

棒グラフを伸ばすタイプの Now Loading 画面は作れたけど。欲を出して、円グラフが動くものを作ろうかと思ったところでハマる。円グラフの元になる画像は Inkscape で作ったけれど。肝心の円グラフをAS3で描こうとしたところ、円描画メソッドはあるけれど、扇型の描画メソッドは存在しなかったわけで。自前で書かないとダメか…。

カスタマイズ性が高い上に機能も豊富。機能使用中の場合にマウスカーソル周辺に画像をつけられるのは誤操作を防げそうでヨサゲ。いや、画像を追加表示するより、マウスカーソル自体を変化させる方向でも良かったような気もするけど。そうなると、技術的に難しいのかしら。

マウスカーソルの移動に関して加減速がなく、定速で動くのがちょっと気になった。デフォルト設定では Shiftキー同時押しにより低速移動にも切り替わるので実用上の問題はないし、むしろマウスカーソルが定速で動いたほうが、マウスカーソルがどこまで動くか予測しやすいので便利かもしれない、とも思うのだけど。…まあ、マウスカーソルに限らず、エディタなどでも、カーソル移動時の加減速はあったほうがいいのかどうかというのは色々な考えがあって、ちと判断が難しい気もする。

自分の Windows XP Home SP3 環境では、設定ウインドウ（今ふぃぐウインドウ）中の「×」ボタンの端が欠けて表示されてしまっていて、ちょっと気持ち悪い。なんでだろ。

CapsLock でモードを切り替えるのだけど、自分の環境では CapsLockにCtrlキーを割り当ててしまっているので、Ctrl + Shift + M を指定してみたり。

海外製ツール。テンキーをマウスカーソル移動用として使う。キー割り当て変更はできない。

テンキー部分に全ての機能を割り振ってあることで、操作に関してはかえって判りやすくなっている感もあり。とにかくテンキーに手を伸ばせばマウスカーソルを動かせるはず、みたいな。ただ、ノートPCでは使えないに等しい状態になりそうな予感も。

マウスカーソル移動は加減速がついているタイプ。速度変更は、.reg を書き換えて、レジストリ変更しないといけないらしい。設定ウインドウの類が何もないのは厳しい。

カスタマイズ性が高い。インターバルまで設定できるのはヨサゲ。ただ、キーの割り当て時・確認時に、仮想キーコードを要求されるのがちょっと厳しい。添付ファイルに一覧がついてきてるので、それを見ながらどうにか設定。デフォルト設定では、Mouse Emulator と真逆の思想(?)で、できるだけ英字キー部分のみで操作できるよう、ホームポジションから指が離れず操作できるよう割り当てがされている。

マウスカーソル移動は加減速がついているタイプ。インターバルを細かく(?)すると、サクサク操作できている感覚が増すような気がした。

開発は停止してる状態のようで、今後の発展は期待できず。

一休「ふむ…。橋を渡らねば対岸に行けぬ。しかし橋は渡れないという。…渡れないなら、飛べばよいか」
一休、懐から紙片を取り出し、印を結んで呪文を唱える。紙片、たちまち巨大な鷲に。一休が鷲に颯爽と飛び乗ると、鷲は舞い上がり、川も橋もやすやすと越え対岸へ。桔梗屋の上をぐるりと一回りして門前に降りる。一部始終を店内から目撃していた桔梗屋。その場にへたりこみ足をがたがたと震わせるのみ。
一休「こんにちは。桔梗屋さん」
桔梗屋「ぎゃーーっ」

こういうのって絶対に誰かが既にやってそうな。つーか、橋の上をJoJo風・座ったままの姿勢で跳んでいく一休さんの画を見たような記憶もある。

後になって気がついた。おかしい動作をしていたのは、

if ( u_win > c_win ) {

と書くべきところを、

if ( u_win > cwin ) {

と書いてしまってたから。トホー。となると、やっぱり数値で比較されていたのだろうか。まあ、ミスを軽減できるから、parseInt() を使ってもいいよな。

にしても、宣言してない変数を使うとエラーが出る、ぐらいの予防策が欲しいところではあるなぁ。何の宣言もなく、ポンポンと変数を作成できてしまうのもちとどうかと。

NHKのニュースで、導火線とやらが上部→下部→上部の順にグルリと回り込んでる図を見て首を捻った。何故に、温度が高くなる＝事故の確率が上がるであろう噴射口近辺を経由させるのだろう。下で問題が起きたら上もダメになりそうな。何かのタイミングでも絡んでるのかな。

閲覧者が色んなサイトをアクセスしていく様を情報として得る事で、その人の感想を知る、みたいな。例えばそのサイトでの滞空時間とか、スクロールバー操作回数とか。や、言ってみただけ。なんだか難しそう。でも、 _NC等のクリック回数 ってそんなアプローチに近い感も。ある種の感想表明になってる。