mieki256's diary

このプログラム、メインPC上では何度試してもすんなりヌルヌルと動くのだけど、サブPCでは動く時と動かない時があって、どうもまだちょっとどこかしら怪しい部分が…。ちなみにPCのスペックは以下。

• メインPC : AMD Ryzen 5 5600X + NVIDIA GeForce GTX 1060 6GB + RAM 16GB。Windows10 x64 22H2。画面解像度 1920x1080。
• サブPC : AMD Athlon 5350 + 内蔵GPU Radeon R3 + RAM 4GB。Windows10 x64 22H2。画面解像度 1920x1200。

どうしてサブPC上ではすんなり動かないのだろう…。

サブPC上では、メインPCからLAN経由で操作できるように、リモートデスクトップソフト Brynhildr をサーバモードで常駐させていた。もしかしたらそのせいでOpenGLを使ったプログラムが、ちと動かしづらい状態になっていたのかもしれない。

管理者権限で brynhildr.exe を実行して、Service で「Delete」を選ぶことでサーバモードのサービスを無効にしてから Windows10 を再起動したら、今回作成したスクリーンセーバが起動できる確率がグンと上がったような気がする。

ただ、完全に問題が解消されたわけでもなく。スクリーンセーバが呼び出された際、最初の1〜2回の呼び出し時は何故か起動に失敗する…。3回目ぐらいでスクリーンセーバが起動するようになって、一度起動してしまえば、そこから先は何度も起動が成功するし、ずっと動き続けてくれるのだけど…。

また、スクリーンセーバ版ではなく、GLFWを使った版は、Brynhildr がサーバモードで動いていても問題無く起動するし、描画もしてくれる…。

やはりスクリーンセーバとして動かそうとした時だけ、何か妙なことが起きてるとしか思えない。でも、メインPC上なら毎回必ず起動してくれるのだよな…。何故サブPC上ではダメなのか…。

今回、ビルボード用テクスチャが 4096 x 4096 x 1枚、BG用テクスチャが 2048 x 1024 x 4枚と、結構巨大なサイズのテクスチャになってるあたりも不安要素。png や jpg をベタデータに展開する際に時間がかかってしまっているだろうし…。何より、そんなサイズでVRAMを占有してしまって大丈夫なのかどうか…。そのせいで動作が怪しくなっている可能性は…。

いや、それは違う気もする。もしテクスチャのサイズが巨大過ぎて問題が起きてるなら、GLFW版の動作も同様に怪しくならないとおかしい。しかしGLFW版はすんなり何度も確実に動いてしまっているわけだから…。テクスチャサイズはこれでも問題無いということなんだろう…。

今回、各ビルボードを、四角ポリゴン(GL_QUADS)でドーンと表示してるけど。コレをちゃんと作るなら、複数のポリゴンを組み合わせて一つのビルボードにしたほうがいいのかもしれない。大昔の2Dゲームだって、スプライトを複数枚組み合わせて1つのキャラを作る場面があったわけだし…。

例えば…。

• 横方向にずらりと並ぶ花畑的なビルボードを描画したいなら、横方向に異様に長いテクスチャを用意するより、小さい正方形のスプライトを横にいくつも並べたほうがテクスチャ領域が節約できる。
• 木のビルボードも、葉っぱと幹を分けて組み合わせて作れば、幹の脇の透過部分を描画しなくて済む。
• 道路の上をまたぐ橋っぽいビルボードも、柱部分と横に長い部分で分けて作れば、真ん中の透過部分を描画しなくて済む。

しかし、そのあたりを考えていくと、いっそ3Dモデルを作って描画したほうがいいのでは…。どうせ今回OpenGLを使って描画しちゃってるわけだし。地面と道路は疑似3Dだけど、その上に載せる各オブジェクトが3Dモデルになっていても何ら問題は無いよな…。もしかすると、いかにもな3Dモデルじゃなく、Z軸方向に差がある状態で複数枚のスプライト相当を重ねてあるだけでも、視差効果/パララックスが得られるかもしれない。

もっとも、3Dモデルにしてしまうのはやり過ぎかも。元々、レトロな見た目が欲しくてわざわざ疑似3Dにしているのに、3Dに寄せ過ぎるのもどうなんだろう。だったら道路も含めて全部3Dにしてしまえばいいじゃん、という話にもなりそう。

まあ、OpenGLでモデルデータを描画するのも結構一苦労しそうなので、今回はこのままでいいかなと…。

スクリーンセーバを作る際の前提として、以下があるわけだけど…。

• C/C++ (MinGW gcc/g++ 6.3.0) でスクリーンセーバを作る際、scrnsaveライブラリを使うと作りやすくなる。scrnsave.h を include して、libscrnsave.a をリンクする。
• scrnsaveライブラリを使えば、たった3つの関数 ―― ScreenSaverProc()、ScreenSaverConfigureDialog(), RegisterDialogClasses() を自分で書くだけでスクリーンセーバが作れる。
• ScreenSaverProc() 内で、WM_CREATEメッセージが送られてきたら初期化処理を行い、SetTimer() で一定時間毎に処理が呼ばれるように ―― 指定時間毎に WM_TIMER が送られてくるように指定する。
• ScreenSaverProc() 内で、WM_TIMERメッセージが送られてきたら、毎フレームの処理を行う。

ふと、WM_CREATE が飛んできた際、そこで時間がかかる初期化処理をしてしまうとよろしくないのではないか…？ と思えてきた。昨日の段階では、WM_CREATE が来た時に画像の展開処理もしていて、そこで数秒待たされる状態になっていた。

試しに、WM_CREATE が来た時は最低限の初期化処理だけをして、画像の展開は各フレーム処理内で行うように変更してみた。更に、展開すべき画像5枚分を一気に展開せず、1フレームにつき画像を1枚ずつ展開して、5フレームかけて全画像を展開するようにした。

このように変更したところ、サブPC上でも、スクリーンセーバが起動してくれる確率がグンと上がった。

• リモートデスクトップソフト Brynhildr をサーバモードで常駐させていても、起動する確率は高い。
• 1920x1200の画面でも、全てが問題無く描画できるようになった。

今までは、Brynhildrを落としておくとか、デスクトップ解像度を下げるとか、BG画像の4枚分は展開しない/BG描画はしないようにしないと動いてくれなかったりしたので、状況はかなり改善された。

ただ、これでもまだ問題が残ってる。

• 最初の呼び出し時は、一瞬画面がチラついて、すぐにスクリーンセーバが終了してしまう。
• そのまま放置して2度目の呼び出しが来ると、今度はちゃんとスクリーンセーバが起動してくれる。

何度試しても、こういう状態になる…。何が原因なのか。解決策/回避策は無いのだろうか。

メインPC上ではこんな問題は起きてない。サブPC上でだけ起きてるのだよな…。AMD製GPU(Radeon R3)のせい…？

原因が分かった。デスクトップ解像度が1920x1200になっているとこの不具合が発生する。1920x1080にすれば一発でスクリーンセーバが起動する。そんなオチかよ…。トホホ。

試行錯誤した際に一応分かった点をメモしておく。

まず、OpenGLを使ってないスクリーンセーバなら、解像度が1920x1200でも、こういった問題は起きない。

例えば、以下で、OpenGLを使っていないスクリーンセーバのサンプルコードが紹介されているけれど、これをビルドして、スクリーンセーバ(*.scr)にして試した際は、解像度が1920x1200でも、何の問題もなく一発ですんなりと起動することが分かった。

_Screen Saver 入門 (WebArchive)


また、以下で紹介されてるサンプルコード、もしくは自分が書いたコードは、OpenGLを使っているスクリーンセーバだけど。1920x1200では、例の不具合が ―― 1回目の呼び出しですぐ終了して、2回目の呼び出しで起動成功する不具合が発生した。そして1920x1080なら、そういった問題は発生しない。どのスクリーンセーバも一発でちゃんと起動した。

_Windows - OpenGLスクリーンセーバーサンプル: インディーズゲームデベロッパー「OMEGA POINT」
_How to Scr: Writing an OpenGL Screensaver for Windows
_mieki256/glboundballscr: Bound ball animation screensaver win32 by using OpenGL.


更に、以下はソースコードは公開されてなくて実行バイナリしかないスクリーンセーバだけど、これもOpenGLを使っているので、1920x1200では件の不具合が発生して、1920x1080なら一発で起動した。

_TeapotGLスクリーンセーバーの詳細情報 : Vector ソフトを探す！


そんなわけで、「OpenGLを使っていて」、かつ、「(推奨)」と表示されていないデスクトップ解像度にしている場合、件の不具合が発生する可能性が出てくるらしい。

念のために一応書いておくけれど、スクリーンセーバではなく、GLFWで新規にウインドウを作成してOpenGLで描画する分には、デスクトップ解像度が1920x1200でも問題無く動作した。

つまり、OpenGLの勉強をするだけなら、この問題には遭遇しない予感。フツーは GLUT や GLFW を使って実験するだろうから。

「せっかくここまで作ったんだから、試しにスクリーンセーバにでもしてみようかな」
「選択できる最大解像度で動作確認しておかないとマズイだろう」

などと欲を出して(?)作業をし始めると、こうしてハマる。でもまあ、Windows上で「(推奨)」と表示されてるデスクトップ解像度で動かしてる分には、この問題には遭遇しないだろうけど…。たぶん。

膝の上にあるキーボードが鬱陶しい。このキーボードを宙に浮かせられないか。ディスプレイアーム/モニターアームにノートPCを乗せられるようにする製品があった気がする。ソレをPCデスクに固定して使えば、キーボードを宙に浮かせられるよな…。

でも、ディスプレイと違って、キーボードは常に打鍵して力を加えるものだから、その手のアームで浮かせたらフラフラして使えたもんじゃないかもしれない。うっかり力を入れ過ぎてアームが外れたら危険だよな…。

キーボードが置ける程度の小さいサイズのサイドテーブルのようなものはないか。と思ってググってみたけど…。そこまで小さいサイズのサイドテーブルは見当たらなかった。

そこそこ大きいサイズなら、いくらでも見かけるけれど、それは自分も持ってるのだよな…。ずっと畳んだ状態で部屋の隅で埃を被っているけれど。引っ張り出すのが面倒臭い。ここまで大きくなくてもいいんだよな…。

そもそもキーボードとマウスが２つあるのがおかしい。人間の手の本数は限られているのだから、瞬間的には1つのキーボード、1つのマウスしか操作できない。だったら、2つは要らない。本来は1つで十分なはず。

となると、CPU切替器かな…。1つのキーボード、1つのマウスの先にCPU切替器があって、そのCPU切替器から2台のPCにUSBケーブルが伸びていて…。どう考えてもケーブルが邪魔になりそう。サブPCはメインPCから結構離れたところに置いてあるし。

キーボードとマウスを1つずつにするなら別の方法もあるなと。Bluetooth接続のキーボードとマウスを使えば、接続先を切り替えて複数のPCに対応できるのではないか。その手のキーボードは、3台ぐらいまで登録できそうでもあるし。Bluetoothだからケーブルも無いし。

各PC用にBluetooth受信機を用意しないといけない…。そもそも新規にBluetoothキーボードとマウスを購入しないと…。自分が気に入りそうなキーボードって無さそうな気もする…。

Bluetooth接続キーボードは、BIOS設定の操作ができないのもアレだな…。もっとも、BIOS設定ってそう頻繁に変更するものでもないから、そういう作業をする時だけ有線接続のキーボードを繋いでやれば済む話だろうか。

どのサブPCもLAN接続しているのだから、LAN経由でリモート操作すればいいのではないか。実際、Linux機に対してはメインPCから ssh でアクセスして操作することが多いのだし。VNCを使ってデスクトップ画面を操作することもあるし。LAN経由で操作する分にはキーボードもマウスも1つで済む。新規に何か買わなくてもいい。

ただ、リモート操作は反応が遅くて…。CUIで操作する分には問題無いけど、VNCで操作すると画面がベロンベロンと書き換えられる様子が見えてしまって…。各サブPCは無線LANでLANに接続しているから速度が出なくてベロンベロン状態になるんだろうけど。いっそ有線で接続してしまおうか…。

「BIOS設定は頻繁に変更するものではない」と書いたところで気が付いた。そもそも、サブPCで各種実験をする機会自体がそんなにないのだよな…。サブPCは常に電源を入れてるわけでもない。日常的に、頻繁に使ってるわけではなく、たまにしか使わない…。

だったら別に、このままでもいいんじゃないのか…。年に何回あるのか分からない場面のために、何かしらを新規購入するのもコスパが悪過ぎるだろう…。今の状態で我慢しよう…。

Windows用とLinux用の両方でビルドが通るように、定義済みマクロでソースの中身が変わるようにした。

• Windows上でビルドする際は _WIN32 が定義される。
• MSYS2上でビルドする際は __MINGW64__ が定義される。
• Linux上でビルドする際は __linux__ が定義される。

#if defined(__MINGW64__) || defined(__linux__)

// MSYS2 (Windows, g++ 13.2.0) or Linux

#else

// MinGW (Windows, g++ 6.3.0)

#endif


#ifdef _WIN32

// Windows only

#include <tchar.h>
#include <windows.h>
#include <scrnsave.h>
#include <mmsystem.h>

#endif

VMware Player + Ubuntu Linux 20.04 LTS x64 ならビルドが通るのだけど。実機 + Ubuntu Linux 22.04 LTS x64 ではビルドが通らない…。

Ubuntu Linux 20.04 LTS x64 の場合。ビルドは通る。

$ g++ --version
 g++ (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
 ...

$ ld --version
 GNU ld (GNU Binutils for Ubuntu) 2.34
 ...

$ make -f Makefile.glfw
g++ -o ssp3droadglfw.o -c ssp3droadglfw.cpp
g++ -o render.o -c render.cpp
ld -r -b binary -o sprites.o sprites.png
ld -r -b binary -o bg_summer.o bg_summer.jpg
ld -r -b binary -o bg_autumn.o bg_autumn.jpg
ld -r -b binary -o bg_winter.o bg_winter.jpg
ld -r -b binary -o bg_night.o bg_night.jpg
g++ -o ssp3droadglfw ssp3droadglfw.o render.o sprites.o bg_summer.o bg_autumn.o bg_winter.o bg_night.o -lGL -lGLU -lglfw -lm

Ubuntu Linux 22.04 LTS x64 の場合。エラーが出てしまう…。

$ g++ --version
 g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
 ...

$ ld --version
 GNU ld (GNU Binutils for Ubuntu) 2.38
 ...

$ make -f Makefile.glfw
g++ -o ssp3droadglfw.o -c ssp3droadglfw.cpp
g++ -o render.o -c render.cpp
ld -r -b binary -o sprites.o sprites.png
ld -r -b binary -o bg_summer.o bg_summer.jpg
ld -r -b binary -o bg_autumn.o bg_autumn.jpg
ld -r -b binary -o bg_winter.o bg_winter.jpg
ld -r -b binary -o bg_night.o bg_night.jpg
g++ -o ssp3droadglfw ssp3droadglfw.o render.o sprites.o bg_summer.o bg_autumn.o bg_winter.o bg_night.o -lGL -lGLU -lglfw -lm
/usr/bin/ld: render.o: relocation R_X86_64_PC32 against absolute symbol `_binary_sprites_png_size' in section `.text' is disallowed
collect2: error: ld returned 1 exit status
make: *** [Makefile.glfw:26: ssp3droadglfw] エラー 1

このエラーはどういう意味なんだろう…。

ビルドが通る、VMware Player + Ubuntu Linux 20.04 LTS x64上でも、動作に問題がある。出来上がった実行バイナリを動かしてみると、テクスチャ画像を展開できる時と、展開できない時がある…。必ず展開できるわけでもなく、必ず展開できないわけでもない。こういうバグが一番困る…。

実機上なら動作が変わるのだろうか。しかし、そちらは Ubuntu Linux 22.04 LTS だから、ビルド自体が通らない…。

自作したWindows用スクリーンセーバを ―― 疑似3D道路を描画するスクリーンセーバを、親父さんのPC上で動かして動作確認してみたところ、スクリーンセーバ設定ダイアログ上のプレビュー表示がおかしくなってることに気づいた。本来表示されるべき位置からかなり左上のほうに表示されてしまって、描画内容の右下だけが、プレビュー画面の左上のほうにちょっとだけ表示されてしまっている。何故だ。どうしてこうなった。

そこでふと気が付いた。親父さんは視力が衰えてしまっているので、Windowsのディスプレイ設定で、「テキスト、アプリ、その他の項目のサイズを変更する」を150%にしていた…。たぶんそのせいじゃないだろうか。

自分のメインPC上でも、そのあたりを変更してみたところ、親父さん用PCと全く同じ不具合が再現できた。

今までビルドしてきた各スクリーンセーバについても一通り試してみたところ、OpenGLを使っている/使ってないに係わらず、どのスクリーンセーバも、プレビュー表示は表示位置がおかしくなった。

この結果は、当然な気もする。自分がググって今まで参考にしてきた、スクリーンセーバの作成方法を解説しているページは、「高DPI？ ナニソレ？」「WindowsのDPIと言えば96DPIに固定されてるもんだろJK」という時代に書かれているので、こういった不具合が起きることも、もちろん解決策についても、一切言及していない。故に、どのサンプルを動かしてもこういう不具合が発生するのは必然、ということなのだろう…。

ただ、試しているうちに、FreeBASICで作成したスクリーンセーバだけが、高DPIにしても正常なプレビュー表示になっていることに気づいた。

_freeBASIC Screensaver Kit Updated - freebasic.net
_FreeBASIC Screensaver Kit - freebasic.net

一体何が違うのか調べてみたところ、FreeBASICのスクリーンセーバ作成用kitには、マニフェストファイル(manifest)が添付されていることに気づいた。

そのマニフェストファイルに書かれていた内容は以下。

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >
  <asmv3:application>
    <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
      <dpiAware>true</dpiAware>
    </asmv3:windowsSettings>
  </asmv3:application>
</assembly>

内容についてググった感じでは…。この記述は、Windows Vistaの時点で追加されたDPI変更機能に対応させるための記述、ということらしい。

ちなみに今現在は、Windows10 Version 1607で追加された機能もあるらしくて、完全に対応させるならそのあたりもアプリ側で行わないといかんらしい…。

更に、このマニフェストファイルは、リソースファイルの中で取り込むように指定されていた。リソースファイルの内容は以下。

 FB_SCRNSAVER_ABOUT DIALOGEX 6, 18, 160, 62
 STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU | DS_NOFAILCREATE
 FONT 10,"Arial"
 CAPTION "Mambazo Doodle"
 BEGIN
     CTEXT "Mambazo Doodle" -1, 0, 5, 160, 8
     CTEXT "Version 1.0" -1, 0, 15, 160, 8
     CTEXT "http://langfordtavern.com/" -1, 0, 25, 160, 8
     DEFPUSHBUTTON "OK" IDOK, 55, 40, 50, 14
 END 
 
 1 24 "MambazoDoodle.xml"

一番最後に、「1 24 "MambazoDoodle.xml"」 という記述がある。

• ここで指定されているxmlファイルがマニフェストファイル。
• 最初のほうにある「1 24」は、マニフェストファイルをリソースファイル内で指定する際のお約束らしい。

試しに、自作のスクリーンセーバでも同じことをやってみた。

• マニフェストファイル名を、「スクリーンセーバファイル名.manifest」にする。
• リソースファイル(resource.rc)の最後に、該当行を追加。

1 24 "ssp3droadgl.scr.manifest"

この状態でビルドし直したところ、WindowsのデスクトップのDPIを変更しても、スクリーンセーバ設定ダイアログ上で正常な位置にプレビューが表示される状態になった。

_mieki256/ssp3droadgl

とりあえず今回は、この対応だけでいいんじゃないかな…。

今まで作った、OpenGLを使った他のスクリーンセーバも対応させておいたとメモ。

_mieki256/ssstars_opengl
_mieki256/glboundballscr

_CLI で Linux ファイルマネージャ ranger を使うことのメモ | Jenemal Notes

sudo apt install ranger

MobaXterm にはXサーバも同梱されているので、アクセス先の Ubuntu Linux にインストールされているGUIアプリも起動することができる。ターミナルエミュレータ(ターミナルソフト)も起動できるので、それらを起動して、その上で ranger を使えば画像のプレビュー表示もできるのではないかと思いついた。

ただ、それぞれを起動して試してみたところ、urxvt 以外は全滅だった。

sudo apt install rxvt-unicode
urxvt &

sakura terminal も、roxtem も、rangerの画像表示はできなかった。自分の環境の場合、rangerで画像を表示したい時は urxvt を起動するしかないようだなと…。

一応、 _~/.Xdefaults で urxvt 用の設定はしておいた。設定内容については以下が参考になった。ありがたや。

_urxvt こと rxvt-unicode を使うことのメモ | Jenemal Notes
_Ubuntuにurxvt（軽量ターミナル）を導入 - mfumiの日記

ちなみに、昔の Ubuntu Linux では、この rxvt-unicode は256色に非対応だったらしいけど。説明文を見る限り、Ubuntu Linux 22.04 LTS でインストールできる rxvt-unicode は、256色をサポートしてる、と表示されている。本当に対応してるのかどうかは分からんけど…。

$ sudo aptitude search rxvt
i   rxvt-unicode   - RXVT-like terminal emulator with Unicode and 256-color support

_Ubuntu - jammy の rxvt-unicode パッケージに関する詳細

画像のプレビュー表示をしたいだけなら、GUIのファイラーを起動すればサムネイル表示ができるので、そちらを使ってしまうのもアリかもしれないと思いついた。

自分は普段、Ubuntu Linuxのデスクトップ環境として Xfce を利用しているので、Xfce の標準ファイラー thunar 以外なら ―― pcmanfm, nautilus, nemo, rox-filer, doublecmd 等なら、MobaXterm経由で起動してWindows10のデスクトップ上に表示できる。

pcmanfm &
nautilus &
nemo &
rox-filer &
doublecmd &

ちなみに、thunar だけは、MobaXterm から起動すると、Windows10 のデスクトップではなく、アクセス先の実機側のデスクトップ画面に表示されてしまって利用できなかった。これはデスクトップ環境として Xfce を使っているからで…。他のデスクトップ環境を使った場合は、そのデスクトップ環境の標準ファイラーが同じ状態になる。

• Xfce : 標準ファイラー Thunar
• Gnome : 標準ファイラー Nautilus
• LXDE : 標準ファイラー PCManFM

そもそも画像ビューアを使ってしまえばいいのでは、と気が付いた。MobaXterm上で ranger を起動して、画像ファイルの上で Enter を叩いて、例えば画像ビューア sxiv あたりを起動してやれば画像表示ができなくもない。


ranger から sxiv を起動した場合、sxiv のウインドウ内で右クリックすると、そのフォルダ内に入っている他の画像もサムネイルで一覧表示してくれるので、これでも問題無さそうな気がする…。

そもそも、東日本大震災の記憶を、こういった作品にして後世に残せないかとチャレンジしてみたこと自体が評価に値するのではないかと感じた。たしか以前、監督さんへのインタビュー記事で、「映像作家の自分はあの震災に対してこういう形でしかアプローチできない」といった感じの発言を目にした記憶があるのだけど、映像を見ていて、なるほどたしかにと納得できたというか。

自分達は、過去の大災害の記録を後世に残したいと思った際、一般的にはついついハードウェアで残すことをまず考えてしまう。例えば石碑を残すとか…。しかし、石碑の類は、あっという間に人々の記憶から忘れ去られてしまう。

何せ、大阪の街のど真ん中に、「江戸時代にここまで津波が来たよ…」と記してある碑が残ってるわけで…。どうして街のど真ん中にあるのかと考えたら、まあ、そういうことだよなと…。

あるいは、以下のような話もある…。

_寺田寅彦 津浪と人間

三陸災害地を視察して帰った人の話を聞いた。ある地方では明治二十九年の災害記念碑を建てたが、それが今では二つに折れて倒れたままになってころがっており、碑文などは全く読めないそうである。またある地方では同様な碑を、山腹道路の傍で通行人の最もよく眼につく処に建てておいたが、その後新道が別に出来たために記念碑のある旧道は淋れてしまっているそうである。

寺田寅彦 津浪と人間 より

しかし、それらの記録はハードウェアでしか残せないというわけではない。ソフトウェアで残すという方法もある。

例えば、自分が住んでいる福島県須賀川市には、松明あかしという祭りがある。めっちゃデカイ松明を作ってガンガン燃やすという祭りなのだけど、伊達政宗に滅ぼされた二階堂勢を弔うため、というのが由来。

_松明あかしの由来 / 須賀川市公式ホームページ

災害の記録というわけではないけれど、こういった事例は、ソフトウェアで記録を残そうとした事例と言える。この場合、少なくとも四百年は残せてる。

そして、新海監督が「すずめの戸締り」で試そうとしたのも、こういうことだろうなと…。娯楽性/エンターテイメント性を持った映像作品として提示しつつも、その中で過去に大災害があったことをしっかり示しておくことで、見た人の脳内に情報をインストールする…。「お話」にしてみせることで「覚えておいてね」と語りかける。ソフトウェアで記憶を伝えていこうという、立派な試みの一つと言える。「映像作家には所詮こんなことしかできない」と捉えることもできるだろうけど、「映像作家だからこそ、こんなことだってできる」と捉えることもできる。

何にせよ、後の時代に少しでも伝えていきたいと考えて、実際に作品の形にしてみせただけでも、それは賞賛されてしかるべき行為なのではないかと思えた。こんなこと、作家さんじゃなきゃできない。でも、大半の作家さんはここまでやらない。だけど新海監督は、こうしてやってみせた。それだけでも、自分は監督に拍手を送りたいなと思えたわけで。

ただ、ソフトウェアで残すのは、結構難しい…。それが面白かったら残っていくけど、つまらなかったら残らないから…。このアニメは一体どちらの扱いを受けるのか…。でもまあ、そこは時間が判断してくれることだから…。

~/config/gtk-3.0/settings.ini を修正すれば対応できそう。

$XDG_CONFIG_HOME/gtk-3.0/settings.ini

vi ~/config/gtk-3.0/settings.ini

[Settings]?
gtk-application-prefer-dark-theme=0?
gtk-icon-theme-name = Numix?
gtk-theme-name = GreyBird?
gtk-font-name = DejaVu Sans 11?

ちなみに、PCManFM-qt なら、PCManFM-qt 自身の設定ウインドウ内にアイコンテーマの選択項目があるので面倒臭くない。

sudo apt install xfe

xfe と一緒に、xfimage という画像ビューアもインストールされた。

xfe上で画像ファイルを右クリックして「開く」を選べば、xfimage が起動する。もしくは端末から xfimage と打っても起動する。

右側にファイル一覧が表示されて、左側に画像が表示される。ファイルをダブルクリックしないと表示されないのがちょっとアレな気もするけど…。画像表示するだけならこれでもいいかも。ちなみに画像に含まれているアルファチャンネルは表示に反映されない。透明部分は真っ黒になった。

ネット上の感想を眺めると、キャラデザが変更されたことに不満を持ってる方がチラホラ居るようなのだけど…。メインスタッフがごっそり変わって、1期2期のキャラデザ総作監さんが抜けてしまった/続編にはノータッチになった以上、原作寄りのキャラデザに修正したことは正解だろうと個人的には思えた。

今後、仮に、4期や5期が作られることになったとして。そしてその時も、制作スタジオやメインスタッフがごっそり変わるとしたら、どこかの時点で1期2期のキャラデザとは決別しておかないとマズイ。そして、その時原典として頼るべき絵柄はどれなのかと考えたら、それはどう考えてもアニメ版1期2期ではなく、原作の絵柄が基準になるべきで…。迷ったら原作漫画を開け。そこに答えがあるはずだ。企画を引き継いだスタッフがそう考えるのは、そんなにおかしいことだろうか？

ルパン三世パート1のキャラデザやカリ城の作画監督を担当した大塚康生さんだって、「最近のルパンはカリ城のキャラデザを参考にしたものばかりですよね？」という問いかけに、「そんなことはないですよ。今のルパンのキャラデザをしてる人達も必ず原作を参考にしてキャラデザしてるはずですよ」と答えていたし。まず参考にするのは原作。その上で、過去作の絵柄も参考にして、という形にならないと…。

まあ、ルパン三世アニメ版のキャラデザの違いと比べたら、ゆるキャンのソレなんて「全部同じじゃないですか！？」レベルじゃないかなあ、とも…。「ちがいますよーっ」「これだからしろうとはダメだ！ もっとよく見ろ！」と言われそうだけど、両さん達は全バージョンを肯定した上でソレを言ってる点を忘れちゃいけないよなと…。 *1

gltfの読み込み用ライブラリを探したら、以下に遭遇。

_syoyo/tinygltf: Header only C++11 tiny glTF 2.0 library

まだ試用してないけど、なんだか良さそう。色々なプロジェクトで使われているようでもあるし、Windows + MinGW でも利用できると書いてあるのもありがたい。

wavefront(obj)形式の読み込みライブラリを探したら、結構な数が見つかった。テキストファイルだし、フォーマットとしてシンプルなので、対応しやすいのだろう…。

_syoyo/tinyobjloader-c: Header only tiny wavefront .obj loader in pure C99
_tinyobjloader/tinyobjloader: Tiny but powerful single file wavefront obj loader
_Bly7/OBJ-Loader: A C++ OBJ Model Loader that will parse .obj & .mtl Files into Indices, Vertices, Materials, and Mesh Structures.
_tek-nishi/OBJ-loader: Wavefront OBJ loader with OpenGL 1.1, C++
_mojobojo/OBJLoader: stb-style obj loader for obj files output by blender

C/C++で書いたプログラムから、.objを直接読み込んで、解析して利用するようだなと…。

ググっているうちに、blenderから、C言語用の記述でモデルデータを直接エクスポートできるアドオンが存在しているという記事を見かけた。

_Blender OpenGL / C header exporter - ゲームが作れるようになるまでがんばる日記
_でらうま倶楽部 : Blenderのアドオン C header exporter がありがたい
_export - Get indices of vertices of triangulated faces in python - Blender Stack Exchange

しかし配布サイトは404。WebArchiveにページだけは残っていたけど…。

_Blender OpenGL / C header exporter... (WebArchive)

肝心のアドオンファイルは残ってなかった。ファイル名は、io_mesh_ogl-2.63.tar.gz、もしくは io_mesh_ogl_2.58.tar.gz だったようだけど…。

まあ、blender 2.63 時代のアドオンらしいので、今現在の blender では利用できない可能性が高いけど、どういう作りだったのかちょっと気になる。入手できないのは残念。

wavefront(obj)形式を読み込んで、C/C++ の形に変換できるツールがあれば済むのではないかと思いついた。ググってみたら、やはりそういうツールを作った事例がある模様。

_glampert/obj2c: Simple command line tool to convert Wavefront OBJ models to C/C++ data arrays.
_Moon64/obj2c.py at main ・ UnderVolt/Moon64

C++で書かれた前者を試用してみることにした。環境は Windows10 x64 22H2 + MSYS2 (h++ 13.2.0)。

任意のフォルダを作成して、中に入って、githubからクローン。

mkdir obj2c
cd obj2c
git clone https://github.com/glampert/obj2c.git
cd obj2c

MSYS2 の g++ 13.2.0 を使ってビルドする。以下で、obj2c.cpp から obj2c.exe が作れる。

g++ -o obj2c.exe obj2c.cpp -static

注意点。MinGW g++ 6.3.0 でビルドしようとしたらエラーが出た。MSYS2 の g++ 13.2.0 ならエラーが出なかったし、exe も生成された。

使い方は以下。最後につけてる -c は、配列の個数も出力させるオプション。

obj2c.exe INPUT.obj OUTPUT.c -c

ちなみに、-h か --help をつければヘルプが表示される。

> obj2c.exe --help
Convert Wavefront OBJ mesh file to C/C++ data arrays.

Usage:
  $ obj2c.exe <source-file> <target-file> [options]
Options:
  -h, --help            Shows this help text.
  -v, --verbose         Be verbose; output a lot of info and timings.
  -s, --static_arrays   If present, add the 'static' qualifier to array declarations.
  -c, --write_counts    Write lengths of data arrays as constants.
      --inc_file[=name] If flag present, generate an include file externing the array variables.
                        Incompatible with 'static_arrays'. If no filename provided, uses the target file name.
  -n, --smooth_normals  If set, gen smooth per-vertex normals. Default are shared per-face 'flat' normals.
  -f, --vb_friendly     Make the output 'Vertex Buffer friendly'. That is, single index per-vertex.
      --ib_type=<type>  Index buffer data type for when using 'vb_friendly'.
                        Possible values are 16, 16std, 32 and 32std.
                        The 'std' suffix causes the use of the standard C data types found in <stdint.h>
      --no_uvs          Don't output mesh UVs, even if they are present in the OBJ file.

Created by Guilherme R. Lampert, Apr 10 2024.

それはさておき。blender 3.6.9 x64 LTS からエクスポートした .obj を変換してみたところ、たしかに頂点座標の配列等は得られたのだけど…。面毎に異なるマテリアルを指定しているのに無視されて、面情報は全部一つにまとめられてしまうようだなと…。

blender 3.6.9 から wavefront (obj)形式でエクスポートしたものの、マテリアルファイル (.mtl) の中にカラー情報が出てこなくて結構悩んでしまった。しかし、これは単に自分の勘違いだった。RGB を 1.0 or 0.0 にして実験していたから一見分かりづらかっただけで、.mtl の Kd (diffuse, ディフューズ色)に、blender のマテリアルのベースカラーが反映されていることが確認できた。

Ks (Specular, スペキュラ色)は、blender のスペキュラーが対応してるようだなと…。ただ、blender上ではRGB別で指定できないように見える。また、Ns (スペキュラー指数)もどこで指定すればいいのやら…。

Ka (Ambient, アンビエント色)は、blender のどこで指定すればいいのか分からない…。

今回のような状況になった場合、それなりのスペックの電動ポンプが必要だなと…。今まで使ってた小さい電動ポンプでは全く歯が立たない。しかし、どのくらいの値段の製品を購入すればいいのだろうか…。

今回最終的に使った TERADA SL-52 の価格を調べてみたけど、既に生産終了品になっていて値段は分からなかった。ただ、現行品の SL-40 が12,000 - 18,000円ぐらいで販売されているようなので、SL-52 も同じくらいか、もしくはもっと高い値段だったのではないかと…。

中国メーカの製品なら 1,980円ぐらいから売られているけれど、価格差からして罠があるとしか思えない…。表記スペックを満たしてないとか、すぐに壊れるとかありそうだよな…。

Wings3D 2.3 x64 で wavefront (.obj) をエクスポートしてみたら、中に「s 1」という行があって悩んだ。blender でエクスポートした .obj には、そんな行は無いのに…。

_Wavefront .objファイル - Wikipedia

「s 1」はスムージングを有効にする指定らしい。たしかに、Wings3D でエクスポートした .obj を blender 3.6.9 x64 LTS にインポートすると、なんだかスムージングがかかっているような見た目になる。「s 1」が入っていたから ―― スムージングを有効にする行が入っていたから、そんな状態になっていたのか…。

Wings3D上でスムージングを無効にする方法はないのだろうか…。TABキーを叩くとウインドウ上でスムージングの有効無効が切り替わるけれど、これはあくまで作業ウインドウ上の見た目を変えるためだけの機能のようで、エクスポートした .obj には反映されなかった。

線を全選択して、右クリック → エッジ属性の切替 → ハードエッジにする、を選んだら、スムージングがかかってない見た目になった。しかし、コレを .obj としてエクスポートすると、「s 2」「s 3」という行が盛り込まれてしまう…。「s off」になるわけではないのか…。

マスターサーフェイスを用意する際にオブジェクトを選択して材質を削除して、とかやるのが面倒臭かった。マスターサーフェイスって複製できないのかな…。

できるらしい。

_マスターサーフェスを複製したい - Shade3D Knowledge Base

マスターサーフェイスを選択した状態で、表面材質パネルの「複製」をクリックすれば複製できた…。それだけで良かったのか…。

OpenGL 1.1 の glDrawElements() について調べてる。

OpenGL 1.1 で頂点配列を使ってポリゴンを描画する場合、glDrawArrays() か glDrawElements() を使えるらしいのだけど。

• glDrawArrays() ... 頂点配列を渡して描画する。
• glDrawElements() ... 頂点配列のインデックス値の配列を渡して描画する。

頂点配列のインデックス値を渡して描画するほうが、頂点配列内の座標値が重複したりしないので、データ量は少なくて済む。実際、wavefront形式も、頂点座標群とは別に、面を構成する情報としてインデックス値群を持っているので、このメリットを意識したフォーマットになっている。

しかし各頂点には、頂点座標の他にも、法線情報(Normal情報)、テクスチャのUV座標、頂点カラー情報も持たせないといけないはずで…。

wavefront形式の場合、頂点配列、法線情報、テクスチャのUV座標のインデックス値が、別々の値になってる場面がほとんど。しかし、OpenGL の glDrawElements() のサンプルコードを見る限り、どうやら頂点、法線、UVで、別々のインデックス値を指定することはできないようで…。となると、wavefront形式が持っている面情報 = インデックス値列をそのまま OpenGL に流用することはできないようだなと…。

仕方ないので、Pythonスクリプト側で、頂点座標、法線情報、UV座標、頂点カラーを、全部配列にずらずらと展開してから出力してしまうことにした。それらの配列を使って、glDrawElements() ではなく、glDrawArrays() で描画する。

こういうデータの持ち方では、座標値が重複するのでデータ量はかなり増えてしまうけど、これはもうどうしようもないかなと…。いやまあ、glBegin() と glEnd() を使って、ポリゴンを1枚1枚ループを回して描画するようにすれば、wavefront形式が持ってる面情報をそのまま使うこともできるだろうけど、その代わり処理が遅くなってしまうはず。データは増えるけど処理が速いか、データは減るけど処理が遅いか、どっちを取るか、という話になるのだろうか。

本当に頂点配列を使うと処理は速くなるのかな。ベンチマークを取ったわけじゃないから確実なことは言えない気もする…。

blender 3.6.9 x64 LTS で簡単なモデルデータを作成して、wavefront形式(.obj)でエクスポートした。ファイル → エクスポート → Wavefront (.obj) を選択。

• .objファイルは、頂点座標、テクスチャのUV座標、法線情報、面情報が保存されているファイル。
• .mtlファイルは、マテリアル情報が保存されているファイル。

blender から .obj をエクスポートする際、四角形を三角形にするオプション(メッシュの三角面化)にチェックを入れる。後で出てくる Pythonスクリプトも、C言語のソースも、三角形ポリゴンにのみ対応させてある状態なので…。

作成したモデルデータは以下。一つは、只の四角い箱。各面が別の色になっている。

_cube01.obj
_cube01.mtl



以下のモデルデータは、blenderでお馴染みのスザンヌ。目や口のあたりを別の色にしている。

_suzanne01.obj
_suzanne01.mtl

この wavefront形式(.obj) と .mtl を、Pythonスクリプトを使って、C言語の配列の形に変換して出力する。今回書いたPythonスクリプトは以下。ライセンスは CC0 / Public Domain ということで…。

_pyobj2c.py

使用方法は以下。

python pyobj2c.py INPUT.obj > OUTPUT.h

例えば hoge.obj というファイルを読み込ませた場合は、以下の名前の配列を作成する。

• const float hoge_obj_vtx[] ... 頂点配列。1つにつき、{x, y, z} を持つ。
• const float hoge_obj_nml[] ... 法線情報配列。１つにつき、{x, y, z} を持つ。
• const float hoge_obj_uv[] ... テクスチャ座標配列。１つにつき、{x, y} を持つ。
• const float hoge_obj_col[] ... 頂点カラー配列。1つにつき、{r, g, b, a} を持つ。
• const unsigned int hoge_obj_vtx_size ... 頂点配列の個数
• const unsigned int hoge_obj_nml_size ... 法線情報配列の個数
• const unsigned int hoge_obj_uv_size ... テクスチャ座標配列の個数
• const unsigned int hoge_obj_col_size ... 頂点カラー配列の個数

OpenGL 1.1 の glDrawArrays() を使って描画することを前提にした配列になっている。ちなみに、頂点カラーについては、マテリアル情報の Kd (Diffuse色)だけを取り出して頂点カラーにしている。


前述の2つの .obj を変換。以下の結果が得られた。

_cube01.h
_suzanne01.h

これらの配列を、C言語のソースで #include して利用する。

C言語のソースは以下。ライセンスは CC0 / Public Domain ってことで。ちなみに、ウインドウの作成等はGLFW3を利用している。

_01_drawobj.c

#include <stdlib.h>
#include <stdio.h>
#include <GL/gl.h>
#include <GL/glu.h>
#include <GLFW/glfw3.h>
// #include <SOIL/SOIL.h>

#include "cube01.h"
#include "suzanne01.h"

#define WDW_TITLE "Draw wavefront obj"

// Window size
#define SCRW 1280
#define SCRH 720

#define FOV 50.0

#define ENABLE_LIGHT 1

#if ENABLE_LIGHT
const float light_pos[4] = {1.0, 1.0, 1.0, 0.0};
const float light_ambient[4] = {0.2, 0.2, 0.2, 1.0};
const float light_diffuse[4] = {0.8, 0.8, 0.8, 1.0};
const float light_specular[4] = {0.7, 0.7, 0.7, 1.0};
#endif

typedef struct
{
  int scrw;
  int scrh;
  float fovy;
  float znear;
  float zfar;

  double angle;
} GWK;

static GWK gw;

// ----------------------------------------
// Render
void render(void)
{
  gw.angle += (45.0 / 60.0);

  // init OpenGL
  glViewport(0, 0, gw.scrw, gw.scrh);
  glMatrixMode(GL_PROJECTION);
  glLoadIdentity();
  gluPerspective(gw.fovy, (double)gw.scrw / (double)gw.scrh, gw.znear, gw.zfar);
  glMatrixMode(GL_MODELVIEW);

  // clear screen
  glClearColor(0, 0, 0, 1);
  glClearDepth(1.0);
  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

  glDepthFunc(GL_LESS);
  glEnable(GL_DEPTH_TEST);
  glEnable(GL_BLEND);
  glEnable(GL_NORMALIZE);

  glLoadIdentity();

#if ENABLE_LIGHT
  glColorMaterial(GL_FRONT, GL_AMBIENT_AND_DIFFUSE);
  glEnable(GL_COLOR_MATERIAL);

  glLightfv(GL_LIGHT0, GL_POSITION, light_pos);
  glLightfv(GL_LIGHT0, GL_AMBIENT, light_ambient);
  glLightfv(GL_LIGHT0, GL_DIFFUSE, light_diffuse);
  glLightfv(GL_LIGHT0, GL_SPECULAR, light_specular);
  glEnable(GL_LIGHTING);
  glEnable(GL_LIGHT0);
#endif

  // obj move and rotate
  glTranslatef(0.0, 0.0, -10.0);
  float scale = 3.0;
  glScalef(scale, scale, scale);
  glRotatef(-20.0, 1, 0, 0);
  // glRotatef(gw.angle * 0.5, 1, 0, 0);
  glRotatef(gw.angle, 0, 1, 0);

  glEnable(GL_CULL_FACE);
  glCullFace(GL_BACK);

  // draw vertex array

  glEnableClientState(GL_VERTEX_ARRAY);
  // glEnableClientState(GL_TEXTURE_COORD_ARRAY);
  glEnableClientState(GL_NORMAL_ARRAY);
  glEnableClientState(GL_COLOR_ARRAY);

#if 1
  glVertexPointer(3, GL_FLOAT, 0, suzanne01_obj_vtx);
  // glTexCoordPointer(2, GL_FLOAT, 0, suzanne01_obj_uv);
  glNormalPointer(GL_FLOAT, 0, suzanne01_obj_nml);
  glColorPointer(4, GL_FLOAT, 0, suzanne01_obj_col);
  glDrawArrays(GL_TRIANGLES, 0, suzanne01_obj_vtx_size);
#else
  glVertexPointer(3, GL_FLOAT, 0, cube01_obj_vtx);
  glNormalPointer(GL_FLOAT, 0, cube01_obj_nml);
  glColorPointer(4, GL_FLOAT, 0, cube01_obj_col);
  glDrawArrays(GL_TRIANGLES, 0, cube01_obj_vtx_size);
#endif

  glDisableClientState(GL_COLOR_ARRAY);
  glDisableClientState(GL_NORMAL_ARRAY);
  // glDisableClientState(GL_TEXTURE_COORD_ARRAY);
  glDisableClientState(GL_VERTEX_ARRAY);
}

// ----------------------------------------
// init animation
void init_animation(int w, int h)
{
  gw.scrw = w;
  gw.scrh = h;
  gw.angle = 0.0;

  gw.fovy = FOV;
  gw.znear = 1.0;
  gw.zfar = 1000.0;

  glViewport(0, 0, (int)gw.scrw, (int)gw.scrh);
}

// ----------------------------------------
// Error callback
void error_callback(int error, const char *description)
{
  fprintf(stderr, "Error: %s\n", description);
}

// ----------------------------------------
// Key callback
static void key_callback(GLFWwindow *window, int key, int scancode, int action, int mods)
{
  if (action == GLFW_PRESS)
  {
    if (key == GLFW_KEY_ESCAPE || key == GLFW_KEY_Q)
    {
      glfwSetWindowShouldClose(window, GLFW_TRUE);
    }
  }
}

// ----------------------------------------
// window resize callback
static void resize(GLFWwindow *window, int w, int h)
{
  if (h == 0)
    return;

  gw.scrw = w;
  gw.scrh = h;
  glfwSetWindowSize(window, w, h);
  glViewport(0, 0, w, h);
}

// ----------------------------------------
// Main
int main(void)
{
  GLFWwindow *window;

  glfwSetErrorCallback(error_callback);

  if (!glfwInit())
  {
    // Initialization failed
    exit(EXIT_FAILURE);
  }

  glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 1); // set OpenGL 1.1
  glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 1);

  // create window
  window = glfwCreateWindow(SCRW, SCRH, WDW_TITLE, NULL, NULL);
  if (!window)
  {
    // Window or OpenGL context creation failed
    glfwTerminate();
    exit(EXIT_FAILURE);
  }

  glfwSetKeyCallback(window, key_callback);
  glfwSetWindowSizeCallback(window, resize);

  glfwMakeContextCurrent(window);
  glfwSwapInterval(1);

  // Init OpenGL
  int scrw, scrh;
  glfwGetFramebufferSize(window, &scrw, &scrh);
  init_animation(scrw, scrh);

  // main loop
  while (!glfwWindowShouldClose(window))
  {
    render();
    glfwSwapBuffers(window);
    glfwPollEvents();
  }

  glfwDestroyWindow(window);
  glfwTerminate();
  exit(EXIT_SUCCESS);
}

render() の中で OpenGL の描画をしている。glDrawArrays() の前後を見れば、今回のモデルデータの利用の仕方が分かるだろうか…。

  glEnable(GL_CULL_FACE);
  glCullFace(GL_BACK);

  glEnableClientState(GL_VERTEX_ARRAY);
  // glEnableClientState(GL_TEXTURE_COORD_ARRAY);
  glEnableClientState(GL_NORMAL_ARRAY);
  glEnableClientState(GL_COLOR_ARRAY);

  glVertexPointer(3, GL_FLOAT, 0, suzanne01_obj_vtx);
  // glTexCoordPointer(2, GL_FLOAT, 0, suzanne01_obj_uv);
  glNormalPointer(GL_FLOAT, 0, suzanne01_obj_nml);
  glColorPointer(4, GL_FLOAT, 0, suzanne01_obj_col);

  glDrawArrays(GL_TRIANGLES, 0, suzanne01_obj_vtx_size);

  glDisableClientState(GL_COLOR_ARRAY);
  glDisableClientState(GL_NORMAL_ARRAY);
  // glDisableClientState(GL_TEXTURE_COORD_ARRAY);
  glDisableClientState(GL_VERTEX_ARRAY);

• glEnableClientState() で、利用したい情報を有効にする。
• GL_VERTEX_ARRAY, GL_TEXTURE_COORD_ARRAY, GL_NORMAL_ARRAY, GL_COLOR_ARRAY 等を指定することで、頂点座標配列、テクスチャ座標配列、法線情報配列、頂点カラー配列を有効にできる。
• glVertexPointer()、glTexCoordPointer()、glNormalPointer()、glColorPointer() で、利用したい頂点配列等を指定できる。
• glDrawArrays() で、頂点配列を使って描画。
• glDisableClientState() で、利用したい情報を無効化。

Makefileは以下。MinGW gcc 6.3.0、MSYS2 gcc 13.2.0、Ubuntu Linux 22.04 LTS + gcc 11.4.0 でビルドできることを確認した。

_Makefile

MODELS = cube01.h suzanne01.h
SRCS = 01_drawobj.c $(MODELS)

ifeq ($(OS),Windows_NT)
# Windows
TARGET = 01_drawobj.exe
GCC_VERSION=$(shell gcc -dumpversion)

ifeq ($(GCC_VERSION),6.3.0)
# MinGW gcc 6.3.0
LIBS = -static -lopengl32 -lglu32 -lwinmm -lgdi32 -lglfw3dll -mwindows
else
# MinGW gcc 9.2.0, MSYS2
LIBS = -static -lopengl32 -lglu32 -lwinmm -lgdi32 -lglfw3 -mwindows
endif

else
# Linux (Ubuntu Linux 22.04 LTS, gcc 11.4.0)
TARGET = 01_drawobj
LIBS = -lGL -lGLU -lglfw -lm
endif

$(TARGET): $(SRCS) Makefile
    gcc -o $@ $(SRCS) $(LIBS)

%.h: %.obj
    python pyobj2c.py $< > $@

.PHONY: clean
clean:
    rm -f *.o $(TARGET) $(MODELS)

ちなみに、MinGW gcc 6.3.0 でビルドすると、別途 glfw3.dll が必要になるけれど、MSYS2 gcc 13.2.0 でビルドすれば GLFW3 をスタティックリンクできるので、MSYS2 を使って実験したほうがいいと思う。

以下を打ってビルド。

make clean
make

01_drawobj.exe が生成される。