mieki256's diary

一応、2枚のBG画像を縮小描画しながらスクロールさせるテストプログラムを置いておく。

_bgscroll.hsp

; BGスクロールのテスト
;
; Left, Right, Up, Down key : 表示位置変更
; Z key : 仮想画面の解像度変更
;
; 2023/09/13 by mieki256

    ; 実画面解像度
    #define SCR_W       640
    #define SCR_H       360
    ; #define SCR_W       1280
    ; #define SCR_H       720
    ; #define SCR_W       1600
    ; #define SCR_H       900
    ; #define SCR_W       1200
    ; #define SCR_H       900
    ; #define SCR_W       1920
    ; #define SCR_H       1080

    #define set_array_n2(%1, %2, %3, %4) \
        %1(%2, 0) = %3 :\
        %1(%2, 1) = %4 :
    
    ; 仮想画面解像度
    dim vscr_size, 6, 2
    set_array_n2 vscr_size, 0,  640, 360
    set_array_n2 vscr_size, 1,  800, 450
    set_array_n2 vscr_size, 2, 1280, 720
    set_array_n2 vscr_size, 3,  320, 180
    set_array_n2 vscr_size, 4,  480, 270
    set_array_n2 vscr_size, 5,  512, 288
    ; set_array_n2 vscr_size, 6, 1920, 1080
    
    vscr_size_idx = 0

    VSCR_W_MAX = 1920
    VSCR_H_MAX = 1080

    ; 同梱ファイル / bundled files
    #define BG0_FILE    "bg_bg0.png"
    #define BG1_FILE    "bg_bg1.png"
    ; #define BG0_FILE    "bg_bg0_orig.png"
    ; #define BG1_FILE    "bg_bg1_orig.png"
    #pack   BG0_FILE
    #pack   BG1_FILE

    #packopt name "bgscroll"    ; exe filename
    #packopt type 0             ; generate ".exe"
    #packopt xsize SCR_W
    #packopt ysize SCR_H

    ; get windows size
    screen 0, SCR_W, SCR_H, 0
    gsel 0
    screen_w = ginfo_winx
    screen_h = ginfo_winy
    cls 4
    
    ; init virtual screen buffer
    vscrbufid = 1
    buffer vscrbufid, VSCR_W_MAX, VSCR_H_MAX
    dispw = vscr_size(vscr_size_idx, 0)
    disph = vscr_size(vscr_size_idx, 1)

    ; load bg image
    dim bgimgid, 2
    dim bgw, 2
    dim bgh, 2
    dim bgfilename, 2
    
    bgfilename(0) = BG0_FILE
    bgfilename(1) = BG1_FILE
    
    repeat 2
        bgimgid(cnt) = 4 + cnt
        buffer bgimgid(cnt), 4096, 2048
        picload bgfilename(cnt)
        bgw(cnt) = ginfo_winx
        bgh(cnt) = ginfo_winy
    loop
    
    ; init temporary image buffer
    tmpid = 7
    buffer tmpid, 4096, 4096

    ; bg scroll. 0.0 - 1.0
    bg_x = 0.0
    bg_y = 0.0
    
    vscr_change = 0
    nowframerate = 60.0

*mainloop
    #define KEY_ESC     128
    #define KEY_UP      2
    #define KEY_DOWN    8
    #define KEY_LEFT    1
    #define KEY_RIGHT   4
    #define KEY_Z       2048
    #define KEY_X       4096
    #define KEY_PRESS   (KEY_UP + KEY_DOWN + KEY_LEFT + KEY_RIGHT)
    
    stick k, KEY_PRESS

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

    ; 仮想画面サイズを変更
    if k & KEY_Z {
        if vscr_change == 0 {
            vscr_change = 1
            vscr_size_idx = (vscr_size_idx + 1) \ length(vscr_size)
            dispw = vscr_size(vscr_size_idx, 0)
            disph = vscr_size(vscr_size_idx, 1)
        }
    } else {
        vscr_change = 0
    }
    
    ; check cursor key
    spd = 1.0 / (nowframerate * 1.0)
    if k & KEY_UP : bg_y -= spd
    if k & KEY_DOWN : bg_y += spd
    if k & KEY_LEFT : bg_x -= spd
    if k & KEY_RIGHT : bg_x += spd
    
    if bg_y < -1.0 : bg_y = -1.0
    if bg_y > 1.0 : bg_y = 1.0
    
    base_y = int(double(disph) * 0.5)
    
    ; 描画開始 / draw start
    redraw 0
    gsel vscrbufid
    
    ; 背景(遠景)を描画 / draw BG
    draw_bg vscrbufid, bg_x, bg_y, bgimgid, bgw, bgh, dispw, disph, tmpid
    
    ; 仮想画面を実画面に転送
    gsel 0
    gmode gmode_gdi
    if screen_w == dispw and screen_h == disph {
        ; 等倍で転送
        pos 0, 0
        gcopy vscrbufid, 0, 0, dispw, disph
    } else {
        ; 拡大縮小して転送
        xscale = double(screen_w) / double(dispw)
        yscale = double(screen_h) / double(disph)
        
        ; if xscale < yscale : scale = xscale : else : scale = yscale
        if xscale < yscale : scale = yscale : else : scale = xscale
        
        dstw = int(double(dispw) * scale)
        dsth = int(double(disph) * scale)
        dstx = (SCR_W - dstw) / 2
        dsty = (SCR_H - dsth) / 2
        pos dstx, dsty
        gzoom dstw, dsth, vscrbufid, 0, 0, dispw, disph, 0
    }

    ; draw text
    if 1 {
        gsel 0
        font "Arial", 16, 1, 2
        objcolor 255, 255, 255
        color 1, 1, 1
        pos 4, 20
        mes "Press cursor key or Z", 4
        pos 4, 40
        mes "Res:" + dispw + "x" + disph, 4
        pos 4, 60
        mes "bg_x, bg_y = " + bg_x + ", " + bg_y, 4
    }

    redraw 1    ; 描画終了 / draw end
    
    await (1000 / int(nowframerate))
    goto *mainloop

#module

#deffunc draw_bg int dstid, double bg_x, double bg_y, array bgimgid, array bgw, array bgh, int dispw, int disph, int tmpid
    ; BGを描画 / draw BG
    ;
    ; dstid : 描画先バッファID
    ; bg_x, bg_y : bg position. 0.0 - 1.0
    ; bgimgid : bg images buffer ID. array.
    ; bgw, bgh : bg width, height. array.
    ; dispw, disph : screen width, height
    ; tmpid : 作業バッファID
    
    bx = bg_x
    by = bg_y
    if by < -1.0 : by = -1.0
    if by > 1.0 : by = 1.0
    
    repeat 2
        i = (2 - 1) - cnt
        bgid = bgimgid(i)
        bw = bgw(i)
        bh = bgh(i)
        
        shiftx = bx
        if i == 1 : shiftx *= 0.75
        
        sx = int(double(bh / 4) * shiftx) \ bw
        sy = int(double(bh / 4) * by) + (bh / 2) - (bh / 4)
        sw = (bh / 2) * dispw / disph
        sh = bh / 2
        
        dx = 0
        dy = 0
        dw = dispw
        dh = disph
        
        if sx >= 0 and (sx + sw) < bw {
            draw_by_gzoom dstid, dx, dy, dw, dh, bgid, sx, sy, sw, sh, tmpid, dispw, disph
        } else {
            if (sx + sw) > bw : sx = (sx - bw) \ bw
            w = -sx
            sw0 = w
            sx0 = bw - w
            dx0 = 0
            dw0 = w * dw / sw
            
            sw1 = sw - w
            sx1 = 0
            dx1 = dw0
            dw1 = dw - dw0
            
            draw_by_gzoom dstid, dx0, dy, dw0, dh, bgid, sx0, sy, sw0, sh, tmpid, dispw, disph
            draw_by_gzoom dstid, dx1, dy, dw1, dh, bgid, sx1, sy, sw1, sh, tmpid, dispw, disph
        }
    loop
    return
#global

#module
#deffunc draw_by_gzoom int dstid, int dstx, int dsty, int dstw, int dsth, int srcid, int srcx, int srcy, int srcw, int srch, int tmpid, int dispw, int disph
    ; 画面外にはみ出る分を考量して最小面積で画像を拡大縮小描画
    ;
    ; dstid : 描画先バッファID
    ; dstx, dsty, dstw, dsth : 描画先左上座標, 描画先サイズ
    ; srcid : 元画像バッファID
    ; srcx, srcy, srcw, scrh : 元画像左上座標, 元画像サイズ
    ; tmpid : 作業用イメージバッファID
    ; dispw, disph : 画面サイズ
    
    dx = dstx
    dy = dsty
    dw = dstw
    dh = dsth
    sx = srcx
    sy = srcy
    sw = srcw
    sh = srch
    
    if dx >= dispw or (dx + dw) < 0 : return
    if dy >= disph or (dy + dh) < 0 : return
    
    if dx < 0 {
        w = (-dx) * sw / dw
        sx += w
        sw -= w
        dw += dx
        dx = 0
    }
    if dy < 0 {
        h = (-dy) * sh / dh
        sy += h
        sh -= h
        dh += dy
        dy = 0
    }
    if (dx + dw) > dispw {
        dwd = (dx + dw) - dispw
        swd = dwd * sw / dw
        sw -= swd
        dw -= dwd
    }
    if (dy + dh) > disph {
        dhd = (dy + dh) - disph
        shd = dhd * sh / dh
        sh -= shd
        dh -= dhd
    }
    
    ; gzoom は透明色を扱えないので小技が必要
    ; 一旦、仮バッファに拡大縮小描画
    gsel tmpid
    pos 0, 0
    gzoom dw, dh, srcid, sx, sy, sw, sh, 0

    ; 仮バッファから実スクリーンに gcopy でコピー
    ; gcopy なら RGB=(0,0,0) を透明色として扱える
    gsel dstid
    gmode gmode_rgb0    ; RGB=(0,0,0)を透明色として扱う
    pos dx, dy
    gcopy tmpid, 0, 0, dw, dh

    ; draw text
    if 0 {
        gmode gmode_gdi
        font "Arial", 18, 1
        color 255, 255, 255
        pos 4, 80
        mes "x, y = " + dstx + ", " + dsty
        pos 4, 100
        mes "dst x, y, w, h = " + dx + ", " + dy + " ," + dw + " ," + dh
        pos 4, 120
        mes "src x, y, w, h = " + sx + ", " + sy + " ," + sw + " ," + sh
    }

    return
#global

*jobend
    end

使用画像は以下。

_bg_bg0.png
_bg_bg1.png

動作結果は以下。


今気づいたけど、奥側のBGレイヤーについては、RGB=(0,0,0) を透明色として扱う gmode gmode_rgb0 を使わずに、ベタ転送する gmode gmode_gdi を使ったほうが良かったのでは…？ そうすれば、少しは処理時間が短くなったのでは…。いや、焼け石に水か…。

これまた今気づいたけど、手前側のBGレイヤーの下半分で、奥側のBGレイヤーは完全に隠されてしまうのだから、そこは奥側を描画しなくても良かったのでは…？ そうすれば、少しは処理時間が短くなったのでは…。まあ、それも焼け石に水かな…。

考えてみたら、BGが1枚しかなくても、ラスタースクロール相当をすれば多重スクロールに見えるよな…。縦方向に多重スクロールさせないなら、それで十分かも。まあ、そういう画像を作らないといかんのだけど。

一応写真も置いておこう…。数日後には、在りし日の上池、ということになるのだろうな…。

GIMP 2.6 + Python-Fu は、Python 2.5 もしくは Python 2.6 を要求するので、インストールしておく。Python 2.6.6 は C:\Python\Python26\ にインストールした。

また、Python-Fu は PyGTK関係のモジュールも必要とするので、pygtk-all-in-one-2.24.2.win32-py2.6.msi もインストールした。

セットアップファイルの入手先は以下。

_Python Release Python 2.6.6 | Python.org
_Index of /binaries/win32/pygtk/2.24/

GIMP-painter- は、GIMP 2.6 にペンタブレット描画時の調整機能を追加した版、という説明でいいのだろうか。あるいは混色ブラシが使えるようになった版とでもいうか…。まあ、現行版の GIMP 2.10 ではそれらの機能が取り込まれていた気がするけど…。

GIMP-painter- 2.6.11 の入手は以下。

_ダウンロードファイル一覧 - [旧]GIMP-painter - OSDN

以下の2つを入手。

• gimp-painter--2.6.11_100627-4_win32_starter.exe
• gimp-painter--2.6.11_100627-4_win32_update.exe

実行して任意のフォルダに展開する。今回は、D:\Prog\GIMP-2.6.11-painter-\ に展開してみた。

中に入ってる run_gimp.wsf を実行すれば GIMP-painter- 2.6.11 が起動する。ただ、このままでは Python-Fu が利用できなかった。

自分の手元の環境では、C:\Python\Python26\ に Python 2.6.6 がインストールしてあるので…。この Python をGIMPから呼び出せるように、環境変数 PATH を若干変更するbatファイルを作成した。環境変数 GIMPPATH と PPATH だけ、各自の環境に合わせれば利用できるはず。

_gimppainetr.bat

@echo off
set GIMPPATH=D:\Prog\GIMP-2.6.11-painter-\gimp-painter-
set PPATH=C:\Python\Python26

set PATH=%PPATH%;%PPATH%\Scripts;%PATH%
set PYTHONPATH=%PPATH%\Lib\site-packages
set PYTHON_ROOT=%PPATH%

echo.
echo Add path [%PPATH%]
echo Add path [%PPATH%\Scripts]
echo PYTHONPATH=%PYTHONPATH%
echo PYTHON_ROOT=%PYTHON_ROOT%
echo.

cd /d %GIMPPATH%
run_gimp.wsf

加えて、 (GIMP-painter-インストールフォルダ)\home\.gimp-2.6\interpreters\ 以下に、pygimp.interp というテキストファイルを作成する。おそらく、GIMPから利用するインタプリタ言語の設定を記述するファイルだと思うけど…。内容は以下。pythonw.exe が置いてある場所を指定している。

_pygimp.interp

python=C:\Python\Python26\pythonw.exe
/usr/bin/python=C:\Python\Python26\pythonw.exe
:Python:E::py::python:

注意点。pygimp.interp は、改行コードを*NIXのソレに合わせてLFにしておくこと。Windowsの改行コード、CRLF になっていると、GIMPはこのファイルの解析に失敗する。

動作確認。gimppainetr.bat を実行して、フィルタ → Python-Fu → コンソール、を選んでコンソールが表示されれば Python-Fu が動いてる状態になっている。

もう少し色々試していたら、通常インストール版 GIMP 2.6.12 32bit でも、Python-Fu が利用できる状態になった。

GIMP 2.6 で Python-Fu を利用するための条件としては、おそらく以下を満たしておく必要があるのだろう…。これを踏まえつつ、GIMP 2.6 のインストール作業をしていけばよいのではないか。たぶん。

• GIMP 2.6インストール時に、Python 2.6.x が利用できる状態であること (Python 2.6にPATHが通っていること)。
• GIMP 2.6インストール時に、Python-Fu関係(GIMP-Python)のファイルもインストールすること。(「GIMP Python extension」にチェックを入れてインストール作業を進める。)
• GIMP 2.6起動時に、Python 2.6 が利用できる状態であること。
• GIMP 2.6インストールフォルダ\lib\gimp\2.0\interpreters\pygimp.interp で、Python 2.6への正しいパスが指定されていること。
• GIMP 2.6インストールフォルダ\lib\gimp\2.0\plug-ins\ 内の *.py で /usr/bin/env が記述されていないこと。

ひとまず、GIMP 2.6 や GIMP 2.8 は、インストーラを実行すると、今までSSD/HDD内に存在していたユーザーデータ用フォルダを平気で削除してくれちゃうので…。~/.gimp-2.6 や ~/.gimp-2.8 等を、一旦別の場所に移動してから作業を始めた。

Pythn 2.6.6 にPATHが通っている状態にしてから、GIMP 2.6.12 のインストーラ、gimp-2.6.12-i686-setup-2.exe を実行した。

GIMPのインストーラが Python 2.6 を見つけたので、インストールの途中で Python-Fu関係のファイルもインストール項目(「GIMP Python extension」) として表示された。もし、Python 2.6 が利用できない状態でインストーラを実行すると、該当項目はグレーアウトして選べない状態になるはず。さておき、チェックを入れてインストールを続行。

GIMP 2.6.12 インストール後、GIMPを実行。ユーザーデータ用のフォルダ、~/.gimp-2.6/ が作られた。GIMP を終了。

GIMP 2.6インストールフォルダ\lib\gimp\2.0\interpreters\pygimp.interp の内容を確認。利用したい Python (pythonw.exe) の場所が正しく指定されているか、また、改行コードが CRLF ではなくて LF になっているか確認する。

python=C:\Python\Python26\pythonw.exe
/usr/bin/python=C:\Python\Python26\pythonw.exe
:Python:E::py::python:

GIMP 2.6インストールフォルダ\lib\gimp\2.0\plug-ins\*.py を確認。もし、1行目に 「#!/usr/bin/env python」と書いてあったら、「#!/usr/bin/python」に書き換える。Windowsに /usr/bin/env というプログラムは無いので…。

GIMP起動用のbatファイルを作成。GIMPインストールフォルダ\bin\ あたりに入れておく。

_gimp-2.6.bat

@echo off
set GIMPPATH=D:\Prog\GIMP-2.6.12\GIMP-2.0
set PYPATH=C:\Python\Python26

set GTKPATH=%PYPATH%\Lib\site-packages\gtk-2.0\runtime\bin
set GIMPFUPATH=%GIMPPATH%\lib\gimp\2.0\python

set PATH=%PYPATH%;%PYPATH%\Scripts;%GTKPATH%;%GIMPPATH%\bin;%PATH%
@rem set PATH=%PYPATH%;%PYPATH%\Scripts;%GIMPPATH%\bin;%PATH%

@rem set PYTHONPATH=%PYPATH%\Lib\site-packages
set PYTHONPATH=%GIMPFUPATH%
set PYTHON_ROOT=%PYPATH%

echo.
echo add path %PYPATH%
echo add path %PYPATH%\Scripts
echo add path %GTKPATH%
echo add path %GIMPPATH%\bin
echo.
echo PYTHONPATH=%PYTHONPATH%
echo PYTHON_ROOT=%PYTHON_ROOT%

@rem cd /d %GIMPPATH%
@rem cd /d %GIMPPATH%\bin
cd /d %USERPROFILE%
%GIMPPATH%\bin\gimp-2.6.exe %1 %2 %3 %4 %5 %6 %7 %8 %9

このbatファイルを実行すると、Python 2.6.6 をPATHに追加してから、GIMP 2.6.12 を起動する。

余談。カレントディレクトリを %USERPROFILE% にしてから GIMP 2.6.12 を起動しないと、何故か Python-Fu が動いてくれなかった…。なんでだろ…。

さておき。GIMPが起動したら、フィルタ → Python-Fu → コンソール、を選択。コンソールウインドウが表示されたら、Python-Fu は利用できる。

これで一応、Python-Fu が動作する GIMP 2.6 環境は得られたわけだけど。不具合に遭遇した。

通常インストール版 GIMP 2.6.12、GIMP-papinter- 2.6.11、どちらでも不具合が発生してるのだけど…。Pythonコンソールウインドウや、Python-Fu で書いたフィルタのダイアログの入力欄で、何故かキー入力ができなかった。Enterキー、Deleteキー、Backspaceキーは反応するし、Ctrl + V で貼付けはできるのだけど…。

メモ帳でも開いておいて、そこに入力値を打ち込んでからコピーして、Python-Fu関係のダイアログに貼り付ける、といった感じで使っていくしかなさそう。

でもまあ、今時 GIMP 2.6 を使うことはまず無いと思うので…。GIMP 2.10 か 2.8 を使えばいいわけで…。

ちょっと記憶が怪しいけれど、たしか GIMP 2.8 からは Python-Fu が使える状態で配布されていた気がする。だから、Python-Fu を使いたいなら、最初から GIMP 2.8、2.10 を利用したほうがいい。GIMP 2.6 で Python-Fu を使おうとしたから、こんな面倒臭い作業をすることになってるわけで…。

気になった点、1つ目。ゲーム本編では主人公キャラが動物キャラだったのに、エンディングでは人間のおじさんが主人公キャラとして出てきて…。エンディングのデモ映像で、「あれから数十年経って、私は映画監督になった。あの時の体験が今も仕事で活きている」みたいな台詞が出てきて、いやお前ずっと動物だったやん、なんでしれっと人間になってんの、などと夢の中でツッコんでしまったのだけど…。目が覚めてから、そういう繋がりが可能になる設定・シチュエーションってあるのかなと悩んでしまって。

つまり、お題としては、「主人公は動物キャラとして本編内で活躍するが、ラスト近辺で人間キャラになる。その流れが不自然ではないと思える設定を考えなさい」みたいな感じかなと。さて、どんな設定を思いつくだろうか…。

こんな感じかなあ…。

• 主人公は子供の頃に、悪い魔法使いから動物になる呪いをかけられた。冒険の末、ラスボスの魔法使いを倒したので人間に戻れた。
• 主人公は狸か狐。後に人間に化けて、人間社会に溶け込むことになる。
• 異世界で動物キャラとして数々の冒険をしていた主人公が、異世界転生してこっちの世界に来てしまった。
• 主人公が子供時代に空想して作っていたお話の主人公が動物キャラ。

1番目はちょっと「紅の豚」「美女と野獣」っぽい。2番目は「平成ぽんぽこ」だよな…。3番目は意外と使えそうかもしれない。いや、既にそういう作品がありそうだけど。4番目は…これは元ネタが分からないけど、ノスタルジーを感じさせる設定に持っていけそうな気もする。

動物じゃなくてロボットにすれば、結構印象が変わるかもしれない。本編ではずっとロボットとして活躍するけど最後は人間になるお話、みたいな。「ピノキオ」「キカイダー」系っぽいな…。

「『○○○○がラスト近辺で人間になるお話』 ―― ○○○○に入る言葉を考えなさい」というお題もアリかもしれない。プログラムとか。宇宙戦艦とか。惑星とか。他に何があるだろうか。

気になった点、2つ目。夢の中に出来てたゲーム機がメガドラだったのだけど、背景スクロールが妙に立体的な見せ方で、拡大縮小もポリゴンも使えないのにコレってどうやって実現してるんだろうと夢の中で悩んでしまって、目が覚めてからも、あんな処理は実現できるのかなと悩んでしまった。

頭が少し冴えてきてから、とあるゲームの映像が夢の中で再生されただけっぽいと気づいたけれど。

_Mega Drive Longplay [259] The Adventures of Batman & Robin (a) - YouTube

改めて映像を眺めてみたら、ますます悩んでしまった。コレってどうやったら実現できるんだろう…？

ラスタースクロールを使ってるのであろうことは分かるのだけど、実際にどんな背景画/BGを事前に描いておけばいいのか、そして、各ラインのスクロール値をどう変化させていけばいいのか、そのあたりで悩んでしまう…。

32ドットとか64ドットとかその程度のドット数の幅でループしてる背景画なら、スクロール値を適度にリセットすればいいよなと思いつくけど。ていうか自分も以前、 _DXRuby を使ってそういう処理を試して上手くいった 記憶があるので…。しかし、件のゲームの背景は、ほぼ画面幅相当でループしてるわけで…。スクロールに合わせてBGを書き換えているシーンもあるし…。メガドラはBG1枚につき、横2画面、縦2画面分を持ってるので、その面積でやり繰りしないといけないはず。さて、どういう作りにすればいいのやら…。実現できることは分かってるけど、実際やろうとすると細かいところでちょっとした工夫が必要になるはず…。

まあ、ポリゴンをバンバン描画できる今のハードウェア上で、ラスタースクロールを駆使して云々なんて考えること自体が無意味だけど。どうせラスタースクロールそのものが疑似的な再現になってしまうし…。もっとも、頭の体操、遊びの類としては、方法を考えてみたり、HSP等々で再現してみるのもアリな気がする。

「寝床で思いついたネタは使えない」と任天堂の宮本茂さんが何かのインタビュー記事で発言していて、たしかにその通りなんだよなあ、と自分も思っているのだけど。

何故使えないかと言うと…。夢の中って、名案が思い付いた時の高揚感すら、その時見ている夢の内容と全く関係無く突然再生されちゃうので、何かのネタが出てきて「これは使えるのでは？」と夢の中でワクワクしても、目が覚めてからよく考えてみると「どこが使えるねん…」となっちゃう。

ただ、お題を思いつく分には使えなくもないかな、という気もしていて。「動物が人間になるシチュを考えよ」なんて出題は、日頃生活していてそうそう出てくるものでもないし。目が覚めてる状態では「なんでそんな馬鹿げたこと考えないとあかんねん」で終わってしまってお題すら出てこない。

夢の中って、頭の中で勝手にサイコロが振られてランダムなお題が出続ける、そういう状態ではあるよなと…。まともな答えは一切期待できないけど、馬鹿げた質問ならポンポン出てくる時間というか…。ゴールは無いけどスタート地点はありそうというか…。

以下の静止画像を使用。今回は、ちゃんと腕と体を別レイヤーにした。




Moho を使って、こうなった。



「ドヤァ」感が出ているだろうか…。アニメ絵の場合は、これでも十分な気がする…。

手描きアニメは、計算で映像を作る3DCGアニメと違って、形状が絶えず不正確に歪む映像なのだから…。正確なパースで動くより、その場のノリでイイ感じに歪ませてしまうほうが手描きアニメっぽく見える、のではないかと想像してみたりもして。

手前に存在してるはずの腕部分を、スマートワープ機能で、偽パースっぽく変形させて歪ませているだけ。



他には、体部分のレイヤーを微妙にY軸で回転させて、後はカメラ位置を変更して、トラックアップだかドリーインだかT.Uをしてるだけ。

ImageMagick を使っても同様の処理ができたような気がする…と思ってググったら、なかなか難しい場面があるらしい。

_どうでもいいと思うよ: ImageMagickのPSDの扱い方
_どうでもいいと思うよ: ImageMagick PSD続き、PNGをインデックスカラーで透過

というか、自分も以前実験してたっぽい。

_mieki256's diary - psdをレイヤー別にpngで保存する方法

とりあえず、一番簡単に使えそうな ImageSprite を使って描画してみる。


_imagesprite.py
_cutegirl.png
_cutegirl2.png

u"""
pi3d ImageSprite sample.

スプライトを描画するサンプル。
平行投影で描画。
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)

# シェーダーを生成。uv_flatは照明関係の計算をしない。
shader = pi3d.Shader("uv_flat")

# カメラを平行投影に
camera = pi3d.Camera(is_3d=False)

# テクスチャを読み込み
tex = pi3d.Texture("cutegirl.png", blend=False, filter=pi3d.GL_NEAREST)
# tex = pi3d.Texture("cutegirl2.png", blend=False, filter=pi3d.GL_NEAREST)

# スプライトを生成
sprite0 = pi3d.ImageSprite(tex, shader,
                           w=256.0, h=256.0, x=0.0, y=0.0)
sprite1 = pi3d.ImageSprite(tex, shader,
                           w=256.0, h=256.0, x=128.0, y=128.0)

print("sprite0.z() = %d" % sprite0.z())  # z=20.0
print("sprite1.z() = %d" % sprite1.z())

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

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

    # スプライトを描画
    sprite0.draw()
    sprite1.draw()

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

画像は、 _OpenGameArt.org の、 _Cute Girl - Free Sprites を使わせてもらいました。ありがたや。この画像、可愛いな…。しかもライセンスが CC0 だし…。

ソースにコメントを書きまくったから、眺めれば分かりそうではあるけど、一応。

画像の色をそのまま出したいときは、uv_flat という種類のシェーダーを使うといいらしい。shader = pi3d.Shader("uv_flat") で用意してる。

_pi3d.Shader - pi3d 2.21 documentation によると、テクスチャ画像を使いたいときはシェーダー種類を示す文字列の頭に「uv_」と付くらしい。「flat」は、照明関係の計算をしないでフラットな状態で描画、ということかなと。

2D描画をしたいので、透視投影ではなく平行投影にする。そのために、カメラを用意して設定する。camera = pi3d.Camera(is_3d=False) で、「このカメラは、3Dっぽく描画しないでくれ＝平行投影にしてくれ」と指定してるのだろう…。

画像を描画したいので、テクスチャ画像として読み込む。tex = pi3d.Texture("テクスチャ画像のパス") でテクスチャとして読み込める。

テクスチャ読み込み時の、blend指定の意味は、ちょっとよく分からなかった。filter指定は、拡大縮小時にどんなフィルタをかけるか、だろうけど。 _pi3d.Texture - pi3d 2.21 documentation によれば、フィルタ種類として pi3d.GL_NEAREST や pi3d.GL_LINEAR が指定できるらしい。GL_NEAREST はクッキリだけどジャギジャギ。GL_LINEAR は滑らかだけどぼやける。てな認識でいいんじゃないかな…。 _Textures で紹介されてる画像を眺めれば分かるかなと。

ちなみにドキュメントには、「テクスチャ画像のサイズは、4, 8, 16, 32, 48, 64, 72, 96, 128, 144, 192, 256, 288, 384, 512, 576, 640, 720, 768, 800, 960, 1024, 1080, 1920 てな感じのキリのいい値にしておいてね」と書いてある。

画像を使うスプライトは、以下で生成できる。

sprite0 = pi3d.ImageSprite(テクスチャ, シェーダー,
                           w=幅, h=高さ, x=x座標, y=y座標)

そして、この場合は平行投影だから、幅、高さ、座標はドット単位で指定すればいいのだろう…。たぶん。

pi3d.ImageSprite() のテクスチャのところに、直接、画像のパスを書いても、画像をテクスチャとして読み込んで使ってくれる模様。ただ、同じ画像を他のスプライトでも使いたい場合は、別途テクスチャとして読み込んでソレを指定したほうが確実かもしれず。

と思ったけど、 _pi3d/Sprite.py at master - tipam/pi3d を眺めたら、既にテクスチャが読み込まれているならそっちを流用する、てな実装になってる、ように見えなくもないな…。

前述のソースは平行投影で描画してるけど、透視投影でも描画してみる。


_imagesprite2.py

u"""
pi3d ImageSprite sample.

スプライトを描画するサンプル。
透視投影で描画。
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)

# シェーダーを生成。uv_flatは照明関係の計算をしない。
shader = pi3d.Shader("uv_flat")

# カメラを透視投影に
camera = pi3d.Camera(is_3d=True)

# テクスチャを読み込み
tex = pi3d.Texture("cutegirl.png", blend=False, filter=pi3d.GL_NEAREST)
# tex = pi3d.Texture("cutegirl2.png", blend=False, filter=pi3d.GL_NEAREST)

# スプライトを生成
sprite0 = pi3d.ImageSprite(tex, shader,
                           w=10.0, h=10.0, x=0.0, y=0.0)
sprite1 = pi3d.ImageSprite(tex, shader,
                           w=10.0, h=10.0, x=5.0, y=5.0)

print("sprite0.z() = %f" % sprite0.z())  # z=20.0
print("sprite1.z() = %f" % sprite1.z())

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

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

    # スプライトを描画
    sprite0.draw()
    sprite1.draw()

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

pi3d.Camera(is_3d=True) を指定してるので、平行投影ではなく、透視投影になってる。それと同時に、ImageSprite() 生成時の、幅、高さ、座標値に対して、謎単位な数値を指定している。

また、透視投影の場合、 ImageSprite() 生成時に、z=20.0とか z=30.0 とか指定してやると、描画される大きさが違ってくる。

以下の描画結果は、2つ目のスプライトのz値を、1つ目より大きくした＝遠くにしてみた事例。透視投影は、近くにあるものは大きく、遠くにあるものは小さく描画するので、遠くにあるスプライトのほうが小さく描画されてる。

アルファチャンネルを持った画像を描画した場合、境界部分がちょっと妙な描画になることに気づいた。


お判りいただけるだろうか。

どうやら pi3d は、テクスチャ画像のアルファチャンネルが 0 or 255 の時は問題ないけど、1〜254の時は妙な描画になるっぽいなと…。これはもしかすると、pi3d の問題ではなくて、Open GL ES の問題なのかもしれない。あるいは、使おうとしてるシェーダーの問題だろうか。

_cutegirl.png は境界部分のアルファチャンネルが0〜255になってるけど、 _cutegirl2.png は 0 or 255 の二値にしてあるので、読み込む画像を変えてみると違いが分かるかも。平行投影の場合は _cutegirl2.png を使うと変な境界が出ないけど、透視投影の場合はどちらを使っても変な境界が出ちゃう。みたいな。このあたり、解決策はあるのだろうか…。

ふと気がついたら、メインPCのシステムタイマーがとんでもなくずれていた。どうやら Ubuntu 系ディストリはシステムタイマーをUTCとして扱うらしくて、起動するたびに UTC の時間が再設定されていたらしい。

• linuxBean の場合は、スタートメニュー → 設定 → linuxBean 日付と時刻、を起動して、UTCのチェックを外してから時間合わせをすれば直る。
• Zorin OS の場合は、/etc/default/rcS 内の UTC=yes を UTC=no に修正すれば直る。

_UbuntuTips/Others/DateAndTimeSettings - Ubuntu Japanese Wiki の一番下の方を参考にして作業すればいい。

VMware Player 上では、USBメモリやUSB-HDDから起動できないのかなと思い込んでいて、Plop Boot Manager とやらを使ってどうにかしようとしてたけど。HDDを追加する際に、物理ディスクを追加するという選択肢を選べば、USBメモリやUSB-HDDから起動することができるらしいと知った。

_ぼーびろくとかんそうぶん: VMwarePlayerでUSBブートさせる

実際試してみたらすんなり起動してくれた。ありがたや。

Plop Boot Manager では、USBメモリならともかく、USB-HDDから起動しようとすると必ずエラーが出てしまって困っていたのでした。助かりました。

実機で動かしたら、指でタップした位置と、実際に取得された座標にずれがあって悩んでしまった。例えば、左手の親指でバーチャルパッドの中心を押さえたつもりが、少し左下の位置が押されたものと判別されているようで。まあ、実際に触れているのは、親指の先・中心ではなくて、少し根元に近いほう、ということだろうけど。触ってる人間が期待しているソレと、端末が取得してる情報の間にはずれがある、ということなのかな。

何かこのあたり、細かい一工夫が必要になりそう。本来は、こういうのもキャリブレーション？する機能を入れるべきなんだろうけど。

知らない間にキャリブレーションすることもできなくはない、かもしれない。アプリ開始時から何度か各ボタンをタップさせるうちに、ボタンの中心位置からのずれを平均値にして持っておいて後で使うとか？ ユーザは、ボタンをタップする際に、えてして真ん中を叩いているつもりのはず、と仮定したり。しかし、右手の人差指でタップするのと、左手の親指で押すのでは、触れる部分が違うはずで…。

SkyDriveなら合計25GB・1ファイル50MBまで保存できるらしいし。

SDExplorer をインストールしたり等して実験してたのだけど。どうやら Windows Live のアカウントを持っていないと共有はできない感じ。アップロードする側はアカウント必須で問題無いけど。受け取る側もアカウントが必要というのはよろしくない。パスワードを入力さえすれば、DLだけはできる、みたいな感じで使えたら良かったのに。まあ、それだとファイル置き場にされちゃうか。いや、本来ファイル置き場としてのサービスのはずだけど。

ひとまずバイナリを送ったので、セーブロード機能の追加作業に取り掛かることに。結構大幅な修正が必要になりそうだけど、さてはてどのくらいの時間で対応できることやら。

_FONT BMP MAKER を使わせてもらったり。等幅で並べてはくれないので、そこは _EDGE で編集。

ロゴ画像については、GIMPで作成・減色までやったほうが、透過(透明)部分を手作業で編集しなくて済む分、楽だったりするかもしれない。どうしても境界がガクガクするけど。…それと、GIMPの減色機能は、あまり優秀ではないあたりがちとアレだけど。

Photoshop Elements でもgifの透過部分を処理できるのか。って当たり前だわな。

こういったソフトで、透過部分作成についても対応してくれていれば楽なのだけど。もっとも、アンチエイリアスの関係で、機能を盛り込むのが難しい予感も。どうしてもガクガクしちゃうしなぁ。

_EDGE2 。かなり機能が増えている。そのせいかシェアウェアにもなった模様。

_GraphicsGale と比べてどうなんだろう。gif関係の扱いが気になる。

_Inkscape で元画像を作成して、pngでエクスポートしても、アンチエイリアスはかかってくれないわけで。大きめに出力して縮小する等、手を加えないといけないのが面倒。

むむ？

かなり危険な行為である事を一応は自覚しつつ実験的に行ってたはずが、あまりにスムーズに実現できたので何時の間にかその危険性を失念した状態になっていたようにも思う。紐の長さ、固定位置、バランス状態、走行コース等々、本来課題が山積だったはずで。犬が歳を取って体力が無くなってくれば歩行による散歩に切り替える事も可能だけど現状では全力で走らないと散歩した気にならないみたいだし＞バカ犬。であればとにかく改善を図らないと。…犬ぞりとか作れないかなぁ ＜ますます危険。犬もバカなら飼い主達もバカだ… (；´Д｀)

事件当時のTVニュースで、行方不明になった時の服装を言葉で説明していて呆れた。ああいった情報は必ずイラストも付随させないと。文字情報の羅列からビジュアルを脳裏に浮かべる事が可能な人間は比較的少ないであろうと想像するわけですが、しかしコレが絵であれば、どんなバカでも「ああ、こういう服装か」と瞬時に理解・認識できるでしょうに。特に福島県は、頭がアレになりつつある爺婆や、文字が読めない爺婆や、カタカナ言葉が判らない爺婆 *1 が多いのだから、如何にして情報を判りやすい形で提供するか真剣に考えていかないと。で、そのへんに全く気を使わない情報提示を、警察もマスコミ連中も呑気に続けてたので、「こいつら、実は本気で探す気ねえだろ…」とガックリですわ。 *2