mieki256's diary

ソースは以下。

_road05.hsp
_road05_hsp (色分け表示)

使用画像は以下。.hsp と同じ場所に置く。

_bg_bg0.png
_bg_bg1.png
_trees.png

実行時、以下のキーを受け付ける。

• Up : アクセル
• Down : ブレーキ
• Left, Right : 左右移動
• Z : 仮想画面の解像度変更
• X : フレームレート変更

CPUで拡大縮小描画処理をしているせいか、それなりに処理が重いので、一旦、小さ目のサイズの仮想画面に描画してから、それを実ウインドウサイズに拡大描画している。

CPU : AMD Ryzen 5 5600X の環境で、実ウインドウサイズを 1600x900 にして動かしてみているけれど…。 *1

• 仮想画面: 512x288 なら 60FPS も出せた。
• 仮想画面: 800x450 なら 30FPS が出せた。60FPS は処理落ちする。
• 仮想画面: 1280x720 なら 20FPS まで。30FPSは処理落ちする。
• 仮想画面: 320x180 なら 60FPS も余裕だったけど、画面はめっちゃ粗くなる。でも、昔のゲーム画面っぽい粗さではあるなと…。

このクラスのCPUでも、この解像度・フレームレートになってしまうのか…。ちょっと残念。GPUを使って描画できればこのくらいの処理も楽勝なのだろうけど。

もしかして、元画像をあらかじめ拡大してイメージバッファに蓄えておいて、それをベタ転送したら多少は改善したり…。いや、それはメモリを滅茶苦茶食いそうか…。

今回、HSP の gzoom を使ってビルボード(スプライト)の拡大縮小描画をしているけれど、画面外にはみ出しているはずの部分も一旦拡大描画してから仮想画面に転送していたので無駄な処理時間がかかっていた。そのあたりを改良して、画面内に収まっている部分だけを拡大描画するようにしてみた。



サンプルソースは以下。

_gzoom_03.hsp

; 画面外にはみ出す分、幅や高さを減らして gzoom で拡大縮小描画

    #define SCR_W       640
    #define SCR_H       360
    ; #define SCR_W       1280
    ; #define SCR_H       720

    #define FRAMERATE   60

    ; 同梱ファイル / bundled files
    #define SPR_FILE    "trees.png"
    #pack   SPR_FILE

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

    ; onkey goto *jobend
    
    randomize 0
    
    ; 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 spite image
    sprimgid0 = 6
    buffer sprimgid0, 1024, 512
    picload SPR_FILE
    spr0w = ginfo_winx
    spr0h = ginfo_winy
    
    ; init temporary image buffer
    tmpid = 7
    buffer tmpid, 4096, 4096

    x = 16
    y = 16

*mainloop

    #define KEY_ESC     128
    #define KEY_UP      2
    #define KEY_DOWN    8
    #define KEY_LEFT    1
    #define KEY_RIGHT   4
    #define KEY_CTRL    64
    
    ; ESC key to exit
    stick k, 255
    if k & KEY_ESC : goto *jobend
    
    ; check cursor key
    spd = 8
    if k & KEY_CTRL : spd = 1
    if k & KEY_UP : y -= spd
    if k & KEY_DOWN : y += spd
    if k & KEY_LEFT : x -= spd
    if k & KEY_RIGHT : x += spd
    
    ; 描画開始 / draw start
    redraw 0
    gsel 0
    gmode gmode_gdi
    
    ; clear screen
    color 32, 64, 128
    boxf 0, 0, dispw, disph
    
    ; draw sprite
    imgid = sprimgid0
    imgw = spr0w
    imgh = spr0h
    dx = x
    dy = y
    
    scale = 1.5
    dw = int(256.0 * scale)
    dh = int(256.0 * scale)
    n = 5           ; sprite No.
    
    draw_sprite_gzoom dx, dy, dw, dh, imgid, imgw, imgh, n, tmpid, dispw, disph, 0

    ; draw text
    font "Arial", 18, 1
    color 255, 255, 255
    pos 6, 6
    mes "Push cursor key"

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

#module

#deffunc draw_sprite_gzoom int dst_x, int dst_y, int dst_w, int dst_h, int imgid, int imgw, int imgh, int n, int tmpid, int dispw, int disph, int dstid
    ; スプライト相当を拡大縮小して描画
    ;
    ; dst_x, dst_y : 描画先の左上座標
    ; dst_w, dst_h : 描画先のサイズ
    ; imgid : 元画像バッファID
    ; imgw, imgh : 元画像サイズ
    ; n : スプライトNo.
    ; tmpid : 作業用イメージバッファID
    ; dispw, disph : 画面サイズ
    ; dstid : 描画先イメージバッファID
    
    ; テクスチャのソース座標を算出
    src_w = (imgw / 4)
    src_h = (imgh / 2)
    src_x = (n & 3) * src_w
    src_y = ((n >> 2) & 1) * src_h
    
    if dst_x >= dispw or (dst_x + dst_w) < 0 : return
    if dst_y >= disph or (dst_y + dst_h) < 0 : return
    
    dx = dst_x
    dy = dst_y
    dw = dst_w
    dh = dst_h
    sx = src_x
    sy = src_y
    sw = src_w
    sh = src_h
    
    ; 画面外になっている分、幅や高さを減らす
    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, imgid, 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
    gmode gmode_gdi
    
    if 1 {
        ; draw text
        gmode gmode_gdi
        font "Arial", 18, 1
        color 255, 255, 255
        pos 6, 28
        mes "x, y = " + dst_x + ", " + dst_y + "  dest w,h = " + dw + ", " + dh
    }

    return
#global

*jobend
    end

使用画像は以下。

_trees.png

実行すると、カーソルキーでスプライトを上下左右に動かせる。スプライトが画面外に出始めると、画面上で表示している dest w,h の値が増減するので、適切な描画面積に変更してから描画してることが分かる。

遠景の縦方向スクロールがどうもイマイチ。試しでテキトーに書いてみたけれど、仕組みについてもうちょっとしっかり考えないとダメだなと…。

また、遠景については、HSP の gcopy を使ってベタ転送・等倍で描画してるので、仮想画面サイズを変更すると見た目が変わってしまう。遠景も拡大縮小描画しないとダメかなと…。そもそも遠景の画像サイズが小さ過ぎる気もする。

各ビルボードの見た目が粗い気がする。1つにつき、テクスチャサイズを256x256で用意しているけれど、512x512ぐらいにしてみたほうがいいだろうか。遠景も画像サイズを変えたいし、画像関係は全部作り直ししたほうがいいかな…。

GLUT を使っていた頃は glutMainLoop() を終了させる方法が無かったらしいけど、freeglut では glutLeaveMainLoop() が追加されて、glutLeaveMainLoop() を呼ぶと glutMainLoop() を終了させられるようになった模様。

def _keyfunc(key, x, y):

    ESCAPE = "\x1b"
    # ESCAPE = b'\x1b'

    key = key.decode("ascii", "ignore")
    print("Push key,", key, x, y)

    if key == ESCAPE or key == "q":
        print("Exit")
        if glutLeaveMainLoop:
            glutLeaveMainLoop()
        else:
            sys.exit()

# ...

def main():

    # ...

    glutKeyboardFunc(_keyfunc)
    
    glutMainLoop()

PyOpenGL-Demo 3.1.1 の中の、NeHe/ の中を眺めていて、そういう記述ができることが分かった。

_PyOpenGL-Demo - PyPI

ちなみに、PyOpenGL-Demo のインストールの仕方は以下。

pip install PyOpenGL-Demo

(Python3インストールフォルダ)\Lib\site-packages\OpenGL_Demo\ の中に展開される。

PyOpenGL は、glutKeyboardFunc() や glutSpecialFunc() を使うことで、キーが押された時に呼ばれる関数を登録できるのだけど、どのキーが押されたか比較する記述で悩んだ。昔は key == 'q' といった感じで書けたようだけど…。

Python 3.x では、b'q' とか b'\x1b' といった感じで、最初に「b」をつける必要があるらしい。

def keyboard(key, x, y):
    """ キーボードが押された時に呼ばれるコールバック関数. """
    global xspeed, yspeed

    # ESC key
    ESCAPE = b'\x1b'

    # ESCAPE = 27
    # ESCAPE = chr(27)
    # ESCAPE = '\033'
    # ESCAPE = "\x1b"
    
    if key == ESCAPE or key == b'q':
        if glutLeaveMainLoop:
            glutLeaveMainLoop()
        else:
            sys.exit()
    elif key == GLUT_KEY_UP:
        xspeed -= 0.1
    elif key == GLUT_KEY_DOWN:
        xspeed += 0.1
    elif key == GLUT_KEY_LEFT:
        yspeed -= 0.1
    elif key == GLUT_KEY_RIGHT:
        yspeed += 0.1
    elif key == b'l':  # 照明のオンオフ
        if glIsEnabled(GL_LIGHTING):
            glDisable(GL_LIGHTING)
        else:
            glEnable(GL_LIGHTING)

# ...

def main():

    # ...

    glutKeyboardFunc(keyboard)
    glutSpecialFunc(keyboard)

ESCキーをどう記述すればいいのかで結構悩んだ…。Python 2.x 時代は、27、chr(27)、'\033'、'\x1b' 等を指定してたけど…。Python 3.x では b'\x1b' と書けばいいらしい。

カーソルキーが押されたかどうかは、GLUT_KEY_UP、GLUT_KEY_DOWN、GLUT_KEY_LEFT、GLUT_KEY_RIGHT と比較すれば判別できる。ただ、glutSpecialFunc() を使わないと、それらの特殊キーは読み取れない。

前述の記述は、引数に何の処理もしないで読み取る際の記述だけど、.decode() を通してから比較する方法もある模様。

def _keyfunc(key, x, y):

    ESCAPE = "\x1b"
    # ESCAPE = b'\x1b'

    key = key.decode("ascii", "ignore")
    print("Push key,", key, x, y)

    if key == ESCAPE or key == "q":
        print("Exit")
        if glutLeaveMainLoop:
            glutLeaveMainLoop()
        else:
            sys.exit()

# ...

    glutKeyboardFunc(_keyfunc)

「b'\x1b'」という記述が、「"\x1b"」になってる。また、「b'q'」が「"q"」になってる。

今までとは違うWebページを取得しようとしたら文字コードの変換でエラーが出て悩んでしまった。どうやら euc-jp で書かれたhtmlを読み込むとutf-8に変換できない場面が発生するようで。今まではutf-8のページを読み込んでいたから不具合に遭遇しなかったのだな…。

    r = requests.get(uri)
    s = r.content.decode("euc_jp")

問題が発生しているのは丸数字(丸付き数字)らしい。本来、euc-jp に丸数字は存在しないらしいのだけど、読み込んだWebページに何故か丸数字が入ってる時があって、そこでエラーが出る模様。

解決策をググったら以下のページに遭遇。

_[python3] EUC-JPなのにShift-JISの機種依存文字が入っててUTF-8にできなかったときの対策 - Qiita
_pythonで丁寧な文字コード変換 - シコウサクゴ（）

euc_jp 以外に、euc_jis_2004 や euc_jisx0213 もあるのか…。euc_jis_2004 を指定してみたらエラーが出なくなった。助かった。

html内のリンクを辿って、その先のリンク先を取得しようとしたら403になった。原因をググってみたら、User Agent を見て一般的なブラウザ以外は弾くサイトや、referer を指定しないとファイルを取得できないサイトもあるとのことで。

requests.get() に headers を渡してやれば、そのあたりの情報を渡せる模様。Firefox の User-Agent を調べておいて、その文字列を渡すようにしてみたり、元ページのURLを referer として渡すようにしてみたり。

uagent = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0'

...

        headers = {
            'User-Agent': uagent,
            'referer': ref_uri
            }
        r = requests.get(uri, headers = headers)

この状態ならリンク先も取得できるようになった。

ヒートシンクでもつければ改善しないだろうか、どうにかしてつける方法はないかな、と思ってググってみたけれど。

_USB無線ラン・アダプター　Buffalo WLI-UC-GNM：ubuntu & LibreOffice：So-netブログ
_Buffalo WLI-UC-GNM を買ってみた - talkwithdevices.com

うわ…。そこまでしないと安定動作しない製品なのか…。参った。

一応、ヒートシンクのサイズや値段等もググってみたけれど、それらを追加購入するだけで、通販では1,000円程度をすぐに超えちゃうので悩んでしまったり。元が1,000円前後の製品なのに、そこまでするのもどうなんだろう、みたいな。

他の無線LAN子機も不安定になるPCだったりしないか、と気になり始めて、試しに、手持ちの無線LAN子機、ELECOM WDC-150SU2MBK を代わりに差してみたけれど。ドライバのインストール作業は必要なものの、特に設置等を工夫しなくても、2時間ぐらいは接続が切れなかった。

まあ、WDC-150SU2MBK も、「すぐ壊れた」等のレビューが多いので…。もしかすると自分が入手した個体は当たりだったのかもしれないし、あるいは何日か使ってると壊れちゃうのかもしれないしで、WDC-150SU2M のほうが良い製品とまでは言い切れないけれど。それでも、BUFFALO WLI-UC-GNM2S よりは、マシな動作だよなと…。

もっとも、この価格帯の製品は、当たりの個体を引くか、ハズレの個体を引くかで、結果が違うのかもしれず。例えば、以前の製品、BUFFALO WLI-UC-GNM、WLI-UC-GNM2 も悪評が多いけれど、自分の手元の個体は比較的まだ安定動作しているわけで…。

今回の WLI-UC-GNM2S は、ハズレの個体だった可能性が高いのだろうな…。しかもコレ、一度店頭で、初期不良扱いで交換してもらった個体なわけで…。まあ、店頭に並んでるそれらはおそらく似たようなロットだろうから、別個体に交換してもらってもやっぱりダメだったりする可能性が高いのではと想像したりもするけれど。

コレを買っておけば間違いない、的な無線LAN子機って無いのかな…。ググってみた感じでは、どの製品も怪しい話が目に付くし。設計に無理がある製品が多いのでは…。

思ったようなカメラ角度が出ない時があるのだけど、グリースペンシルによる線の描き順によって結果が変わるのではないかと思えてきたので、そのあたりを試したり。

描き順を変えても、計算結果は変わらなかった。ちなみに、その手の解説動画を見ると、「奥から手前に」「下から上に」の順で線を描いてる場合がほとんどだけど、そうしなければいけないというわけでもないっぽい。

グリースペンシルで直線を引く際に、マウス左ボタン、もしくは右ボタンを使うのだけど。以下のような違いがあるらしい、とメモ。

• Ctrl + D + マウス左ボタンドラッグ → Ctrl + D を離してドラッグを続ける → 左ボタンを離す : 線の見た目を確認しつつ線を引ける。
• Ctrl + D + マウス右ボタンクリック → 左ボタンクリック : 線の開始点を指定して、2回目の左クリックで線が引ける。続けて左クリックすると、繋がった2本目、3本目を引ける。終了は Enter。

開始点と終了点をクリックで決めるやり方なら、線の開始位置と終了位置が結構離れていても、画面を拡大しながら作業できるメリットがあるなと…。

グリースペンシルで直線を引く際、Z軸(縦方向の線)を引いて計算させると、カメラの天地が逆になるような気がする…。解決策が分からない…。

蓋を閉めると内部の温度が上がり過ぎないかと不安だったけど。以下のコマンドで温度を取得したところ、アイドル状態なら蓋無しの場合より数度上昇するぐらいで済んでる感じ。

$ vcgencmd measure_temp

temp=45.5'C

_[Raspbian] Raspberry Pi 3の動作状況とハードウェア設定を取得する(vcgencmd) - Life with IT
_RaspberryPi(Raspbian)のCPUの温度をcatを使わないで取得してみた - Qiita

ただ、CPUやGPUを回し始めると、どの程度温度が上昇するのかちょっと予想できないなと。給気口？っぽいスリットでもあったほうがいいのだろうけど…。いや、その場合はヒートシンクもつけたほうがいいのかな。でも、サイズが分からんな…。ググってみても情報が無いし。測ってみるしかないのかな…。

まあ、熱が怖ければ、蓋を開ければいいか…。しばらくはそんなノリで…。

少し前に、中国でウルトラマンの新作が、という話が出て、円谷プロが「聞いてねえよ！」「訴えてやる！」と反応してた話があるけれど。

中国企業にアドバイスしてやりたいなと…。円谷プロ、買っちゃえよ…。買収しちゃえよ…。買収すれば、中国国内向けどころか、アジア向け、世界向けの新作ウルトラマンを作り放題やで…。数十年後に、「ウルトラマンは日本生まれだが、育ての親は中国だ」と言っちゃえよ…。

昔、日本企業がアメリカの映画会社を買収しちゃったりして、アメリカ人から「ジャップ許すまじ」的にかなり恨まれた時期があったけど。今の中国なら似たようなことができるだろと。買っちゃえ買っちゃえ。爆買いしちゃえ。

で、中国国内に、昔のILMもビックリな巨大特撮スタジオを作ったりして、今頃になって何故か特撮の復権をですね…。大昔、日本の東映動画が「我々は東洋のディズニーを目指す」とぶち上げてたけど、今度は中国が「東洋の○○を目指す」などとぶち上げてみたらどうかと。庵野監督に「我が国のスタジオを使ってマイティジャック作りませんか？ ただし船体色は真っ赤でお願いします」と声かけちゃうとか。ダメか。

いやまあ、怪獣と戦ってるうちに万里の長城をうっかり蹴り飛ばしちゃうウルトラマンの図とか、それはそれで見てみたいかもと思っただけなんですけど。日本のウルトラマンがソレをやると大問題だけど、中国のウルトラマンがやる分には意外と許されそうだなと…。ダメか。当局とやらに怒られるか。社長や監督が投獄されちゃうかな。中国の観客にウケそうだけどなあ…。「アイヤー…ウルトラマン…アイヤー…」みたいな。

中国のあらゆる観光名所を阿鼻叫喚な戦場に変えていくウルトラマン…。面白そうだけどなあ。とは言ったものの、自分、恥ずかしながら、中国の名所ってほとんど知らないんですよね…。「サザエでございまーす」なノリで、中国版ウルトラマンがOPで「シュワッ」「ヘアッ」「ンッガッググ」と中国の観光名所を紹介してくれないものかってソレどんな番組やねん。

もはやウルトラマンと関係ないけど、観光名所を巡って紹介するだけの特撮ヒーローってどうだろう。いや、ソレってもはや特撮もヒーローも関係なくて只のヒーローコスプレしてる人になるんだろうけど。

昔、美人のお姉さんが温泉に入りながら「効能は」とか言ってた番組があったような気がするけど。その美人のお姉さんを特撮ヒーローに置き換えてみたらどうなるか、みたいな。

ヒーロー 「皆さん、こんにちわ。○○戦隊○○の○○レッドです。今日は東京タワーに来てみました。実は俺、東京タワーにくるの初めてなんだよね」
怪人 「実は俺も」
ヒーロー 「あ。そうなん？ 意外とさ、地元の観光名所ってこないよね」
怪人 「いやいやいや。俺達、東京が地元じゃないやん」
ヒーロー 「アレッ？ そうだっけ？ 俺達、都民じゃなかったの？」
怪人 「設定では埼玉県民になってます」
ヒーロー 「いやー、似たようなもんだろ」
怪人 「正義のヒーローが嘘ついちゃダメだよー。怪人の俺にこんなツッコミさせないでよ」

みたいな。

てな妄想を書いてるうちに思い出してしまったけど、ウルトラマンに登場する宇宙人がこんな感じのアレコレをする番組が既にあったような…気がする…。スキー場で滑ってる回を見たような記憶が…。自分如きが思いつくようなことは、既に誰かがやってるのだよなあ…。

PCの動作が急に重くなって云々と言う話だったので、さてはスパイウェア・アドウェア・マルウェア等に感染したのかなと推測。昨晩のうちに、検出するためのツールをいくつかUSBメモリに入れて持っていった。ところが、USBメモリを差した途端、USBメモリ上に autorun.inf、system.exe というファイルが作られてしまった。コレは何かに感染してるなと。

_Microsoft Safety Scanner でスキャンしてみたけど、何も検出されなくて、ちょっと途方に暮れる。 _Spybot Portable でスキャンしたら、いくつかマルウェアが見つかった。更に、 _Emsisoft Emergency Kit Free でスキャンしたら、おそらくクリティカルっぽい何かが見つかったようで。C:\Program Files\ 以下に、Microsoft Common というフォルダだかファイルだかが作られていると、えてしてUSBメモリに autorun.inf、system.exe を作成する何かに感染してる状態らしい。Emsisoft 〜は、そのあたりを見事にリストアップしてくれた。

さらに _ClamWin Portable でスキャンしたかったけど、始めてみたら一日かかりそうな進み具合だったので、今回は諦めた。

もう一つの相談内容は、サーバ？を起動させる際にF1キーを押さないとOSが起動しないとの話で。幸い、BIOS起動時の画面をスマホで撮影しておいてくれたそうで。画像を眺めてみたら、「Alert! system battery voltage is low」云々のメッセージが表示されていた。たぶんM/B上のボタン型電池が切れてるのかなと。

見た目フツーのPCケースには見えなかったけど、DELL製PCだったので、引っ張りだしてみたら意外と簡単にケースを開くことができた。向かって左側の丸いパーツを上にずらすだけでガルウィング？状態で開く。近くのコンビニで、CR2032を買ってきてもらって、M/B上のCR2032と交換したところ、すんなりOSが起動するようになってくれた。

もう一つの相談内容は、先日購入した borother製複合機 PRIVIO MFC-J6970CDW を使って、スキャナを使いたい、PCからFAXを送りたい、という要望。

スキャナ使用は、PCにインストールした brother Control Center4 を開けば、タブの中に「スキャナ」があるし、画像取り込み・ファイル保存のアイコンボタンもあるので楽だった。

ただ、PCからFAXを送るのがなかなか…。PDFマニュアルを眺めると、一般的なアプリ上で「印刷」を選び、プリンタ一覧内にある Brother PC-FAX 〜 宛てに印刷すればFAX送信できる…はずだけど、そもそも PC-FAX なるプリンタが存在していない。仕方ないので、プリンタドライバやソフトウェアをアンインストール後、再インストール。今度は PC-FAX 〜 という名前のプリンタが一覧に表示された。

しかし今度は、FAX送信先の電話番号を入力しても、なんだか変な電話番号に送ろうとしてしまう。

色々調べたら、PC-FAX送信設定の「外線番号」に、謎の電話番号が入ってた。その外線番号が、送ろうとしている電話番号の前にくっつけられてしまうので、存在しない電話番号にかける状態になってたという。外線番号を空欄に設定し直したら、ようやくFAX送信できるようになった。

_Tiled Map Editor でエクスポートした json を読んで、BG描画用の csv に変換するソース、の修正版をメモ。

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 layerTileData:Map<String,String>;
    public var layerWidth:Map<String,Int>;
    public var layerHeight:Map<String,Int>;
    
    public var tileWidth:Int;
    public var tileHeight:Int;
    
    public function new(jsondata:String) {
        // jsonを解析
        var d = Json.parse(jsondata);
        
        // タイルの縦横個数を取得
        width = d.width;
        height = d.height;
        
        // タイルのサイズを取得
        tileWidth = d.tilewidth;
        tileHeight = d.tileheight;
        
        layerTileData = new Map();
        layerWidth = new Map();
        layerHeight = new Map();

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

    // 与えられたレイヤー名のタイル並びを返す
    public function getLayer(layerName:String):String {
        if (layerTileData.exists(layerName)) {
            return layerTileData.get(layerName);
        }
        else {
            trace('$layerName layer is None');
            return "0";
        }
    }
    
}

利用してる箇所をメモ。

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

        // BGを生成
        
        // BG用画像ファイル読み込み
        var mapimg:BitmapData = Assets.getBitmapData("assets/maps/mylevel1_tiles.png");

        // json読み込み
        var mapdata:String = Assets.getText("assets/maps/mylevel1.json.txt");

        // json解析・BG用データを記録
        var dt:TmxJson = new TmxJson(mapdata);

        // 奥のBG
        bg_c = new FlxTilemap();
        bg_c.loadMap(dt.getLayer("layer4"), mapimg, dt.tileWidth, dt.tileHeight, FlxTilemap.OFF);
        bg_c.solid = false; // アタリなし
        bg_c.scrollFactor.x = 0.25; // スクロール速度の割合
        bg_c.scrollFactor.y = 0.25;
        add(bg_c);

ただ、Hxae + OpenFL には、そもそも tmx というライブラリがあって、ソレを使えば直接 tmx から ―― Tiled の保存ファイルから読み込みができそうなのだけど。使い方がどこにも載ってなかったので今回はアレだけど、そのあたりのドキュメント・サンプルが出てくるならそっちを使ったほうが良さそうだなと。

昨日、夕食後に熱いお茶を飲んだら奥歯が痛み始めた。参ったな…。

科学文明の発達した宇宙人にしてみれば、地球はとんでもない田舎だろうなと。

宇宙人という都会人が、地球という片田舎にやってくるとしたら、そこにはどんな理由があるんだろう。都会人が田舎にわざわざ赴く理由と言えば…。せいぜい観光、もしくは何かネガティブな理由があるとしか思えないのだけど。たとえば、東京暮らしで便利な生活を享受してる人が、襟裳岬に行きたいと思うとしたら、それは一体どんな理由で？

などと考えると、正月になると大挙して宇宙人が押し寄せる地球とか、一家心中するために地球にやってきた宇宙人、なんて設定があってもいいのかなとか。＜オイ。

そもそも、ウルトラ一族と地球人のサイズには差がありすぎるし。ウルトラ一族から見た地球人のサイズは、地球人に置き換えればゴキブリやネズミを見てるようなものだろうと。仮に、ゴキブリやネズミが人語を話したとしても、人間はゴキブリやネズミを身を張って守ってやろうなどという殊勝(?)な気持ちになるのだろうか。望み薄。

地球という惑星の上にびっしりと張り付いた人類 = どこぞの岩の表面にびっしり張り付いたゴキブリの群れ、みたいなものじゃないのだろうか。いや、ウルトラ一族の中に居る生物学者が、「この地球人ってのはずいぶん奇妙な種なんだから、保護しないとあかんやろ」とか言って守ってるならまだ判るのだけど。

アリの群れが巨大なアリ塚を作って、人間はソレを見て「よくまあこんなもん作るよなぁ」と感心したりするけれど。宇宙人から見た人間の街も、たぶんそんな感じなんじゃないのかな、とか。「こんなチンケな科学力で、よくまあこれだけ作ったなぁ」とか思われてたり。…そのうち子供の宇宙人がやってきて、興味本位で アリ塚 人間の街を壊しちゃったりして。棒で突っついたり、お湯をかけたり、足で踏み付けたり等々。

宇宙人にとっては、人間は昆虫みたいなものとして見えている、と仮定すれば。たとえば、『「昆虫の標本を作ろうとしてる人間」を捕まえて人間の標本を作ろうとしてる昆虫型巨大宇宙人』てな設定はどうか。…最初の頃のウルトラシリーズで既にありそうだけど。

昆虫型宇宙人「夏休みの自由研究で、標本を作るんだー」
ウルトラマン「そんなことはやめろ！」
昆虫型宇宙人「なんで？ 宿題出さなかったら僕先生に怒られちゃうよ…。おじさんだって子供のころ標本作ってたじゃないか！」
ウルトラマン「うっ…。たしかにおじさんも、子供のころ人間の標本作ったけど…。」＜オイ。
ウルトラセブン「俺は、アステロイドベルトを集めて工作してたけどな。人間なんて気持ち悪くて触れなかった。標本作るのに注射も使うだろ。アレも妙に怖くて」
ウルトラマン「そういやエースのやつ、あの注射をタロウに刺して大変なことになったっけ」

とか。この場合、昆虫型宇宙人に対して「人間の標本を作るべきではない」と説得するにはどういう理屈を持ち出せばいいのか。

人間を高等生物として見ていない宇宙人、というと、藤子F氏のSF短編にあった宇宙人の侵略モノを思い出す。アレは、 人間の丸焼は毛はえ薬になるという迷信(「サンショウウオの丸焼」を「人間の丸焼」に置き換えてある)を信じてる宇宙人が人類を絶滅寸前まで追い込むが、人間が天然記念物に指定されて人類は助かったというオチだったか。あるいは、 _園田健一著「砲神エグザクソン」 とか。 宇宙人が、人間の食料として人間を使うあたり、人間を牛や豚と置き換えてる・肉骨粉あたりからの連想による設定ではないかと想像したりもするわけで。そういう作品を見てしまうと、ウルトラマンの各種発言 ―― 「ウルトラ一族と地球人は、対等 or 友人」 ―― は、かえって胡散臭く思えてくる。そこに、人間の傲慢さというか、何の根拠もなく自分たちはとにかく価値ある存在なのだと思いたがる嫌な性質を感じてしまうのは私だけでしょうか。

つーか子供向け作品におけるそのへんの設定は、ドンパチやるための舞台を整えるために理由をでっちあげてるに過ぎないわけで、合理性その他は何ら求められていないのでアレなんだけど。しかし、そういう事情を一旦横に置いて、まずは自分が宇宙人になったつもりで真面目に妄想していくと、妙な設定ができたりしないか。てなことを妄想したりもする。

_「文系学生」が初挑戦したプログラム(前編)
_「文系学生」が初挑戦したプログラム(後編)

Java Applet 利用により、ブラウザ上で動作できるものがあるらしい。素晴らしい。

動いていく過程をアニメーションで見れるわけではないのだな。いきなり最終画像が現れるあたり、想像とは違った。

てのがあったら、どうなるんだろうな…。掲示板の各記事を閲覧すると、プログラムによって何か画像が描かれたり、音楽がなったりする。…いや、ソースプログラム部分を選択→右クリックで実行できる拡張、とかそんな感じでもいいのか。もちろん、ファイル操作等は一切できない仕様で。描画や演奏しかできないようにしておく必要があるだろうけど。

言語として、Processing あたりを使えば、そういう見せ方もできるのかしら。

どういう仕組みで音声が出てるのかによるだろうけど。

音に変換する部分が本体とは独立して動いてたら…。制御データを送信 → エラー → リトライを繰り返したりするのだろうか。であれば途切れた直後に再度同じ音声が出力されたりするのかな。

それらしい器官に空気を送ることで人間と同様の発音をしてるなら…。空気を送る・声を変化させるための駆動部分が思ったように動かないことで、音声に変な音が混ざったり、モゴモゴした音声に。

メモリのビットが不定に変化してしまう状態なら…。意図しない波形データがDA変換されてしまう・インパルスノイズ(?)が入ってしまったりして。でも、人間が聞き取れるような音じゃなさそうな。

単にスピーカから音が出ている仕組みで、接触が悪いだけだったら…。のび太の母の右斜め45度チョップが効果を発揮。しないわな。外れかかってた接続部分が衝撃で完全に外れて沈黙する可能性が高そう。

今回のウルトラマンマックスでは、磁気による影響で不具合が起きてるという設定だから…。本体側でリセットがかかる → 再起動を繰り返したり、とか。それじゃ説明のための台詞を出せないから話が進まないか。

そんなどうでもいいことを妄想させてくれる適度な表現が多々あったので今回はなかなかグッド。

マジレンジャーの玩具と響鬼の玩具って、使ってるチップや波形データのROM等、同じだったりするのだろうか。や、先生役の変身アイテム玩具が、本編と関係ない音を出すみたいだし。たしか響鬼の太鼓玩具も関係ない音を出すとどこかで聞いたので…。

極力同じ部品を使ったほうがいいだろうけど。そこまで考えて設計してるのかな。

前にも書いたかもしれないけど。ビデオで見てるうちになんとなく思ったので再度まとめてみたり。

もしかすると各種「下準備」をちゃんと書くあたり、特徴の一つだったのかなと。考えてみれば、1〜2話からして変わってる。「武器となる材料を探すため」に屋久島までやってきたライダーの図。そんなライダー、今まで存在しなかった。新しい戦闘フォームも、鍛錬の結果。不思議な光が突然現れて2段変身できたわけじゃない。

白倉Pの平成ライダーに欠落してるのはそのへんで。龍騎や555を見ていて釈然としないのは、新アイテムを難なく使いこなしてしまう主人公の図。わずか数カットでも、主人公がそれらアイテムについて調べる・マニュアルを読んでるカットが挟んであれば、それら不自然さは容易に回避できるわけだけど。

もっとも、それら描写を入れないのは、意図があるのだろうとも。あえて、やらない。わざと、入れない。おそらくはそれが白倉P版ライダー。子供にとってそれら「下準備」はさほど魅力的な画じゃないから。せいぜいオタクぐらいしか評価をしないから。アイテムのマニュアルを読んでる主人公の図を2秒入れるより、必殺技を決めてポーズをとってるライダーの図を2秒長くしたほうがいい。

ウルトラマンが新必殺技を繰り出すために練習してる風景なんてありはしない。ライダーがライダーキックを繰り出すために練習してる風景なんてありはしない。車田正美の漫画の登場人物が必殺技を繰り出すために悩んでる風景なんてありはしない。…「ライブ感」を優先する旨の発言がある白倉Pだけど。音楽バンドは、練習してる風景をライブ中に客に見せたりはしない。

ヒーローは、この世に生まれたときから必殺技を持ってるし、アイテムの使い方を知っている。人間が呼吸するのと同じくらいに、必殺技や新アイテムをどう使ったらいいのか、その体にインプットされている。それが特撮ヒーローという存在。

なのだけど。視聴者は人間で、ヒーローじゃない。人間は、勉強したり調べたりしないと、新しいアイテムを使えない。今までのライダー響鬼が「それらしかった」のは、視聴者と同レベルで、それらアイテムや技に接してたから、だろうかと。

まあ、「らしさを積み重ねた上に一つ二つの大嘘を置くか」「最初から終わりまで嘘で塗り固めるか」、単に方法論の違いであってどっちが正解というわけでもないんだけど。

小型で口先の短い犬種（チンやシーズーなど）の場合、ちょっと耳を引っ張っただけでも眼球が飛び出してしまうことがあります。

小型犬だから、というわけでもなくて犬の種類によるのだな。＜当たり前か。

どこかで、興奮すると飛び出すという話も見かけたのだけど、どこだったか…。ミポだのメポだの喋る二匹のUMAがいちゃついて性的興奮を感じるたびに、あるいは「邪悪な気配を感じるメポ！」「どんどん近づいてくるミポ！」などと興奮するたびに眼球が飛び出してそれをガーゼ片手に戻してやらなきゃいけない主人公二人の図とか。…イヤ過ぎる。

ていうかプリキュアと関係ない話か。

ていうか「ミポ」「メポ」の使い方が逆かしら。まあ、個人的にはUMAの喋りの正確さなんてどうでもいいというか。

_ruby-mode(改) for xyzzy
こっちも気になる。自分、普段は xyzzy を使ってるので。

Emacs で断片的なメモをどんどんとるための環境です. 分類機能はあえてつけません. かわりに, 全文検索とメモ間リンクが手軽にできるようにしました.

分類機能がないというあたりが少し気になるけど。とりあえず触ってみないと判らない。

_Migemo: ローマ字のまま日本語をインクリメンタル検索

Migemo はローマ字のまま日本語をインクリメンタル検索するためのツールです。かな漢字変換をすることなく日本語のインクリメンタル検索を快適に行うことができます。

最初、howm-wrap が動かなくて。migemo.l を入れてないから動かないのか、と思って入れた。…全然関係なかったんだけど。いい機会だから少し使ってみようかしらん。…おお。漢字にまで反応する。スゴイ。

howm-init.l を修正。

[[hogehoge]] の使い方がよく判らない。書けば、自動で、対応ファイルを作成してくれるとチュートリアル等には書いてあるのだけど。Enter を押してもそれらしい動作にならない。何故。

ロボット犬のみならず、HANDMAIDメイみたいな商品の開発にも着手してほしいところ。一人勝ちするなら今だ！＜また妄想が。

でも難しいよね。今の技術では、ジャイ子みたいなHANDMAIDメイになりそうな予感。(;´Д｀)

「~」を「にょろ」ってのはよく聞くなぁ。でもないか。

「ぐるぐる」は多いのだろうか。

前述の記事を書いた方がまとめてくれた対策方法。メリットとデメリットが明記されてて判り易い。なるほどなぁ。

*3 _誤って掲載されたと言われてるコメント を読んだら、担当者が弱気になってる感じがして気になった。…IR自体は、おそらく、イベントとしては美味しい。旨味のある案を捨てる必要はないようにも思う。 *4 発案者の着眼点は間違ってない。その点は堂々と胸を張って(?)いいんじゃないかと思ったり。…ゲームだって何度もデバックしながら完成にこぎつけるのだもの。イベントだってデバックしながら完成(?)にこぎつければいい。次回のイベントに今回得たノウハウを反映できたらそれでOK、ぐらいの話ではないのかしらん。 *5 と思いますた。 *6