aseprite で複数アニメをタグ付け管理

 asepriteを買ってグラフィッカに頼んでデータを作ってもらったが

使ってないレイヤーがあったり、無駄にフレームの溜めがあったり、

線画と塗りでレイヤー分けられていたり、タグ付けしないでアニメが別ファイルに分かれていたので、タグ付けしてひとまとめにして画像とJSONを出してみた

オプションはよくわからないけど、ここまで出来ればあとは如何様にもなる

ドット絵エディタのいいやつ見つけた

 https://www.aseprite.org/

ゆっくり動画やStableDifusionなどの動画例を見ていて思ったのだけど・・・
StableDifusionはちょっちやりすぎな感じがしてて、なんかマニアックすぎる
ゆっくりは素材サイトを見に行ったら、こちらも狂気的なノリで作られていて、、、

「え、これ昔流行った着せ替えソフト的なノリでつくられてんのね？ここまでカスタマイズするって必要？？」

とか思って、なんか乗り気になれない

元ゲームソフト屋としては、素材があれば動かせる
ゲームではドット絵、アニメーション、キャラの詰め合わせ（テクスチャアトラス）を作るところまでがグラフィッカーさんのお仕事

それをするためにグラフィッカは以下の様なツールセットを使っていた

１．ドット絵エディタ
　　限られたカラーでドット絵を作成する
２．アニメーションエディタ
　　ドット絵の組み合わせでアニメーションのタイミングを作る
３．パッキングアンパッキングツール
　　ドット絵をさらに細かく、
　　i8x8ドットや16x16ドット単位で切り出し
　　それをマッピングして
　　元のキャラを表現するマップファイルを作り出す
　　アンパッキングはその逆

今そういうツールが無いのかなぁと探してみたらあった！

しかも、これ、Gnome GTKで作られてんのか？
MacでもLinuxでもWinでも動く

こいつがあれば、昔の８ビット機時代のノリで
ファミコン版FFみたいに、
キャラクターに演技させることもできる

別に口パクしなくてもヒョコヒョコしてりゃいい
もちろん解像度上げて、もうちっと豪華にしてもいいだろう

JavaScriptを読み込んで、Canvasに絵を描く

ということで

JavaScriptを読み込んで

Canvasに絵を描く例

 

外部のJavaScriptを読み込んで実行する

ちとBootStrap5を勉強しながら

あれこれ試していたところなんだけど・・・

これは、それとは全然関係のない話

外部のJavaScriptを読んで、

そのJavaScriptを実行

読み込んだ側のHTML中にあるDIV領域に対して、

テキストを書き込むこともできた

やれるのは分かっていた

だって３０年くらい前にPerlで同じことやってたから

プログラマは10000％経験だ

つまり・・・

DIV領域ではなくCanvasに 画像貼り付ければ、

ノベルゲームくらいならJavaScriptで作れちゃうってことだ

つまり・・・

吉里吉里とかティラノとか要らんてことだ・・・

つまり・・・

ゆっくり動画くらい

簡単なJavaScriptで作れちゃうんじゃなかろうか？

困った・・・

まぢやればできそうだ

そんで、それを画面録画すれば動画になっちゃうじゃないか

ゲームエンジンを本体側に実装して

データファイルを読み込むようにすれば

ノベルゲームが動かせる

ゲームエンジン次第で

シューティングだろうがアクションだろうが作れる

わたしがSEGAの iPadゲームを作っていた時は、半日で作った自前のゲームエンジンで、カードゲームやクイズゲーム、すごろくなどを実装できていた

プログラマは理系でも文系でもない

要件定義から仕様書作成してコーディングまで持っていくまでには論理的思考が必要

ここまでは文系の文章問題ですが

残念ながら文系だからと言って論理的思考や文章の読解力がある訳ではありません

数学しか知らない数学者はまともなプログラムを作れません

微積や行列演算は理解していてもそれをどうプログラムするかは分からないからです

したがってプラグラマは文系でも理系でもありません

読解力があり、論理的思考ができる事

そして超大事なのは何にでも好奇心を持つ事

そう言う人材がプログラマに向いてます

追記

論理的思考をするにも

要件から実装を考えるにも

文章問題です

だからプログラマは文系の方が向いていると考えるのは合ってますが

残念ながら文系だから語学力があり、文章問題を解ける訳ではないということです

数学しか知らない数学者はまともなプログラムを作れません

数学で言うところの微分や積分、行列演算などは理解しているけれど、それをどうプログラムすれば良いのかは分からないと言うことです

高水準とか低水準と言う言い回しに起因した誤解が本当にあるようだ

アセンブラは超低水準言語と言われるが

何が低いかと言うと人の言葉と違うかららしい

これを聞くと普通の人は、あぁ、ロクでも無い言語なんだねと思うらしい

だけど、プログラマからすると

簡単な言語だからこそ、何をどうすれば開発できるのかわからない言語なわけで、習得するのはかなり難解なものなのだ

つまり、アセンブラは高難易度言語である

これに付随して、上流工程、下流工程と言う言い方があり、さらにV字開発という図がある

わたしは常々、これを考えた奴は、IT業界に入って何も出来ないけど自らの地位を高位に保ちたがった文系野郎だと思っている

そもそもわたしの周りのプログラマは誰も自分たちのやっていることが低級だとは考えていない

なのに、それが下流工程と言われるのだ

ウォーターフォールと言う

以前にも書いたがただの虚構開発工程で言うと、

要件定義から基本設計、詳細設計、コーディングと下流工程に移っていくわけだが、

たかだか要件定義如きしかまとめられない連中が、あたかも上流貴族のような扱いになってるのは何故だ？

絵に描いた餅しか作れない脳足りんどもが、

コーディングと言う超高級レベルの仕事をあたかも下級職のように扱いやがって

V字の図を見ろ

コーディングが一番下なのはなんでだ？

山の頂点にコーディングをかけ！

そしてΛ modelとでも呼べ！

この世で最強なのは話せるプログラマである

文系の要件定義しかやらない人種はITに入ってくるな！

お前らにはIT業界で人権なんざねぇ！

さて、吠えた後で論理的に否定してやろう

V字の横軸は時間だろう

縦軸はなんだ？

山に登る前から上流工程が左上に居るのは何故だ？

生まれながらに上流貴族って事ですか？

ちゃんと麓から山登れよ？

したがって、わたしが提唱する縦軸は難易度だ

一番難易度が低い要件定義から

一番難易度の高いコーディングに行き

テスト工程、実働管理へと難易度が下がっていく

だからわたしはΛ字開発と呼べと提唱する！

V字開発の提唱者に告ぐ！

図を書くなら縦軸と横軸の単位くらい考えろ？

マルチツールが嫌い

ナイフやハサミやノコギリなどがセットになった類のマルチツールというものが嫌いだ

十特ナイフも嫌い

スイスアーミーも嫌い

専用の工具の方が良いし

数種類専用の道具を持っていても

そこまでかさばるものではない

オブジェクト指向が業務に必要ないのか？みたいな記事について

書いてる人も意見してる人もJavaの人だった

この時点でオブジェクト指向にどっぷり浸かってるように感じる

わたしがJavaな人によく言うのはJava以外やってみな？と言うこと

だが、わたしは知っている

一生懸命覚えてプロフェッショナルになった人はそれ以外の言語をなかなか習得せず

他の言語を批判する

だからJavaの人はJava最高で終わってしまう

もちろんVB.netの人もそうだし

C#の人もそうだ

下手したら、Strutsの人はSpring覚えないかもしれない

それだけ業務が忙しく、新しく勉強する時間も無く、教えてくれる人もいないのだろう

さて、ここから本題

オブジェクト思考が要るか要らないかだが

わたし的にはどっちでも良い

それよりもフレームワークの方が大事

メンテしやすいかどうかでフレームワークを選ぶべきだ

個人的見解としてJavaSpringは使いやすいと思う

フレームワークのポリシーを理解していないと

余計な実装しまくることになる

まぁ、原因は何も理解していないプロジェクトリーダーやご意見版を気取る自称スーパープログラマの横槍なのだけど

例えばフロントでシームレスにバリデーションチェックとか

せっかくバックエンドでバリデーターがあるのにそれでは遅いからフロントでやれ！とお達しが来る

理由はお客様からのお達しだ！

上から下に直通な訳だ

バックに渡す前にフロントでシームレスにバリデーションチェックやるなら、バックエンドでも同じことやるので二重チェックになる

JavaScriptからAjax呼び出ししてDBにも負担かけてやることになるわけだ

これが最悪なのはメンテ重ねるとフロントとバックの整合性が合わなくなっていったりする

Javaだけではないのだけど

フレームワークの方針というものがあるのでそれに逆らう実装は本来望ましくはない

そもそもシームレスにバリデーションチェックするという事は結構大変な事だ

ウェブアプリでなくともやるべきではないと思っている

バリデーションは要素の妥当性だけでなく、他の要素との関連チェックもある

フロントでチェックしててもバックで処理してる最中に誰かの操作した事などが起因で現在の状況が変わっててエラーでら返すことになることもある

だからJavaではコントローラで頑張るわけだ

こういうプログラムの手の入れどころを制限する事で新米プログラマの妙な実装も抑止できる

最初に書いた通り

フレームワークは必須

オブジェクト指向ついては、正直どうでも良い

オブジェクト指向と言うのは

新米プログラマでもプログラミングの考え方を定着させる点ではいい考え方だと思う

しかし、Javaはやりすぎじゃね？とも思う

asp.netくらいがちょうど良い気がする

しかし、制約が薄い分

とんでもない実装し出す奴もいる

Javaから来た人はマヂで無駄にクラス作りまくる

要らんからそれと言いたくなる

多分、オブジェクト指向が要らないと言い出す人は

この匙加減のことを言ってるのではなかろうか

DDDに毒された人と言っても良いかもしれない

Javaの人はDDD信者だからなぁ

それと、Goのマイクロサービスで実態作ってしまうとオブジェクト指向要らん！となるかも知れない

Javaの人も一度そう言う現場を見てみるべきだ

わたしはかつてGoのマイクロサービスで

データベースはXMLDBを使い

全体はMVCになっているものを作った

めちゃくちゃ開発効率が高いものが出来た

しかしXML DBも自前で作る必要があることに気がつき、脆弱性にも気がつき、言語もGoからSwiftに変更している最中だ

C、C++、Perlとの付き合いは長いが

わたしは最近の言語を一通り使った上で

Swiftでよくね？と思ったのでやりなおしている

C系はCPU依存がありすぎて

今後ARMのサーバが主流になったらヤバいことになる

あとで苦労したく無いのでRaspberryPiにSwift入れて作り始めているのだ

Web系の技術は脆弱性に関連してどんどん変わってきた

攻撃との追いかけっこでスタンダードの代替わりが激しかった

これからも変わるだろう

SpringSecurityでも2段階認証をもっと簡単に実装する方法を提供できないかと言う議論は見たことがあるし

ゼロトラストについても考えていかないとだし

アンテナ貼りまくって新しいものを学び続けるのはなかなか大変だと思うが

それがプログラマなのだと思う

RaspberryPi4 LibreElec KodiでBD

RaspberryPi4のLibreElec KodiにIOデータのBDレコーダを繋げてみた

DVDは問題なく再生できたのに

BDは再生できなかった

なんだろうと思って調べたら結構グレーゾーンな事をやらないといけないらしい？

(具体的には こちらの情報の通り)

必要なファイルはここに置いておいた

• convtabは全部Update版を上書きしてる
• KEYDBはJPN版でヘッダ部をmkv8のミニマムセットで書き換えている
• vm0はそのまま

いちいち説明するまでもないと思うが

ダウンロードしたマシンから

sshでRaspberryPiに繋いで

scpでkodiに送って

unzipで解凍してから以下の手順に従えば良い

mvで解凍したフォルダやファイルを配置するだけだ

1. JREのアドオン入れる（Blu-rayのメニューがJavaらしい）

    LibreElecのアドオンを検索して追加（ただしJava8）

2. VM0を配置（仮想マシン）

    /storage/.configure/bfplus/vm0

3. KEYDBを配置(BDPlusデコード用)

   /storage/.configure/aacs/KEYBF.cfg

4. convtabを配置(BDPlusデコード用)

  /storage/.cache/bdplus/convtab

超ドマイナーなこの北米版？のBlu-rayは再生出来た

極黒のブリュンヒルデ

外国人の声優さんも頑張ってて

実は英語の勉強になったりする

しかしながら、うる星やつらのBlu-rayは再生出来なかった

多分KEYDBが有志で更新されないとダメな感じ？

または日本版みたいなのが置いてあるから

そっち使えば良いのだろうか？

どこがグレーゾーンなのかと言うと

KEYDBはそもそもDVDFabから取得するものらしいと言うところ

よくわからないのだけどこれは

covtabとセットなんではなかろうか？

マヂこのあたりよくわからないので

もう少し調べてみるつもり

PocketCHIP

http://chip.jfpossibilities.com/docs/chip.html#using-the-chip-operating-system

やばい

本家のサイトよりもかなり詳しく使い方？

と言うか、こう言うワンチップなLinux環境の使い方について書かれている

真空管アンプ

真空管アンプはシングルかプッシュプルで

信号用の出力トランスでスピーカーへの出力をしている

ところで最近の中華な真空管アンプは

トランスが載ってないように見える

つまりは普通に半導体のアンプが入ってると思われる

そのわりに、YouTubeとか見てると重いらしい

え？トランス中に入ってんの？

ちょっとわからないんで分解してくれないか？

KORGのnutubeは一時めちゃくちゃ流行って（と言うほどでもない？）

その回路の中にはあえてトランジスタで増幅してるのもある

nutubeは一種のフィルターのような役割で入ってる感じだ

museでも使えばもっと安定するだろうが

あえてトランジスタを使ってるのが

わたし的には響いた

わたしの友達の父君は結構有名な方で

真空管アンプを作る会社をやっていた

あちこちのオーディオ雑誌からレビュー依頼が来て

コメントを書きまくっていた

その父君の形見分けで、アナログオシロを頂いた

以前偶然電車で会った時に

これから秋葉にオシロを買いに行くんだと話していた

おそらくその時に購入されたものだろう

まさか

それが自分の手元に転がり込んでくるとは思わなかったが

今も大事に使わせてもらっている

家を訪問した時にはいつもワーグナーをかけていて

セレッションのSL-7で鳴っていた

スピーカーもいただいた事があって

お下がりのSL60がうちにある

当然ちゃんと音が鳴る状態にしている

思い出話に脱線したが

真空管アンプの音は

やはりトランスも無いとなぁと感じる

真空管アンプの設計の本は読んでいて

計算方法も分かるが

わたしは知識しかなくて自分で作ってはいない

あるハードウェアエンジニアと話した時に

いい音とは？と言う話になって

楽器をやる人の言ういい音は

結局でかい音なんだそうだ

いやいや、そんな事はないだろう人によるよな？

と思ったが黙って聞いていた

だからオーディオマニアの言ういい音もでかい音で鳴らせる事を重視しているとのことだ

まぁ、わからなくもないが、、、

今の人は音の粒と言う表現をするし

解像度もあるだろう

とは言えわたしはもう高音が聞き取れない

細かい音を聞くと疲れてくるし

音の粒度が下がった程度の音の方が聞きやすい

あまり下がりすぎると気がつくけど

いい塩梅がありそうだ

PocketCHIPにluaをインストール

Luaのインストールは、普通にソースからmake installした方が良い

luaの公式サイト行って、wgetして、解凍してmake installでイケる

てか、luaのコンパイル早！

型のないプログラミング言語で最速と言われるが

コンパイルまで早いんか

PocketCHIPをbusterまでアップデート

jessie→stretch→busterまでアプデしてみた

ウインドウマネージャーはi3にした

ショートカット感覚でターミナル起動したり画面切り替えたり出来るので、こっちのが便利

docker、build-essential、emacsなどを入れ始めてる

バックスペースも効かなくなって来てるので、

そのうちスイッチ取り替えるかも

やり方はそのうちまとめるかも知れないけど

需要あるんだろうか？

ラズパイより遅いけど、熱暴走しないし

わりとこいつ気に入ってる

mako server入れて、

命令タンク（そんな用語ないけど）にしてしまうのもありだな

カセット

うちには録音機能がなくラジオの付いてるウォークマンがある

しばらく使ってなかったが、ゴムが切れていた

ゴム部品を交換して動くようにしてみた

音を聞いてみた

おいおい、いい音で鳴るじゃないか

なんなんだ、この大きさにこのギミックを入れ込んだ技術は

マヂでロストテクノロジーじゃないか

CDやMDが廃れて、カセットがまた流行り始めてるようだが

このガチャっと音が鳴るのが、アナログで楽しいのかも知れない

昔はインディーズバンドがカセットに録音してて

喫茶店などに置いてあって

いくつか貰って聞いていた事がある

今はなんでもWEBに情報があるが

才能があっても埋もれてしまう

ゲームも同じだ

面白くても埋もれてる事が多い

宣伝には物理が良い

目で見て触れる事が出来る

本も同じだなと思う

リチウム電池燃えた

燃えたと言うか

刃物がちょびっと刺さって燃え出した

だから燃えたと言うより燃やした

かなりの高温で、刃物の先端が溶けた

みるみる火が強くなったので

近くにあったコーヒーカスに突っ込んで消した

コーヒーカス取っておいて良かった

まぢリチウム電池はやばい

もっと激しく爆発することもあるだろう

扱うことのある方は要注意だ