mieki256's diary



2024/04/03(水) [n年前の日記]

#1 [prog][windows] Windows用の自作スクリーンセーバが動かない問題の回避策が分かった

_昨日、 C++ (MinGW g++ 6.3.0)とOpenGLで自作したWindows用スクリーンセーバが、サブPC上で起動したりしなかったりする問題で悩んでいた。症状は以下。
サブPCのスペックは以下。
原因が分かった。デスクトップ解像度だった。

サブPC上で選択できる最大解像度、1920x1200にしていると、この問題が起きてしまう。しかし、Windowsのデスクトップ解像度設定画面で「(推奨)」と表示されている1920x1080にすると、何の問題もなく一発でスクリーンセーバが起動するようになった。

そこかよ…。スクリーンセーバの作り方がまずかったわけではないのだな…。

このあたり、サブPCの内蔵GPU (Radeon R3, GCN世代)のスペックに絡む問題なのか、それとも、HDMI接続している液晶ディスプレイ MITSUBISHI MDT243WG-SB の問題なのか、一体どのへんが絡んでるのか分からないけれど、どうもこのサブPCは、デスクトップ解像度を1920x1200にして利用しようとすると、こういったところで妙な問題が発生するようだなと…。それともまさか、使っているHDMIケーブルのスペックの問題なのだろうか…?

何にせよ、なんだか動作が変だなと思ったら、「(推奨)」と表示されてるデスクトップ解像度に変えてみるのもアリ。なのかもしれない。

なんだかこの件はそのうち忘れそう。覚えていられる自信がない…。

OpenGLを使わなければ問題無い :

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

まず、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上で「(推奨)」と表示されてるデスクトップ解像度で動かしてる分には、この問題には遭遇しないだろうけど…。たぶん。

#2 [pc] サブPCを操作するのが面倒臭い

サブPCを操作して各種実験をする際、なんだかちょっと面倒臭い。サブPCには無線接続のキーボードを繋いであるので、目の前にはメインPC用のキーボード(USB有線接続)とサブPC用のキーボード(無線接続、タッチパッド付)の2つがある状態で…。サブPC用のキーボードを膝の上に置きながら作業してるけど、フラフラして打ちづらい。タッチパッドの操作もしづらい。

このへんどうにかならんかなあ…。とりあえず思いついた案をメモして考えをまとめてみよう…。。

キーボードを宙に浮かせられないか :

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

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

サイドテーブルはどうか :

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

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

キーボードとマウスを1つずつにできないか :

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

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

Bluetoothはどうか :

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

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

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

LAN接続してリモート操作でいいのでは :

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

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

日常的に使うわけでもないからいいか :

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

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

以上、1 日分です。

過去ログ表示

Prev - 2024/04 -
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30

カテゴリで表示

検索機能は Namazu for hns で提供されています。(詳細指定/ヘルプ


注意: 現在使用の日記自動生成システムは Version 2.19.6 です。
公開されている日記自動生成システムは Version 2.19.5 です。

Powered by hns-2.19.6, HyperNikkiSystem Project