2005年1月の日記

相も変わらずギリギリにならないと始められない性分はどうにかならぬものか。

パネルγ4107点。
消している最中はプレス機のスピードが上がらないからやる人は10000点いくぞ。
スコアランキングが楽しみです。
やる人、いてくれるのかな…

更新したけど・・・・ほとんど解説無し。
まだまだ準備段階だから仕方ないか。

課題のレポート作成中。

横の繋がりなんて弱いものさ。ちょっとしたことですぐ崩れてしまう。
だけどいざというときに頼りになるのは縦じゃなく横の繋がりだぜ。

灰色の高のぼり。
いやむしろ、灰色よ高のぼれ！

悪あがきしないとみっともないぜ。
変えられる運命をそっくり受け入れるなんて、気が早くないか？

で、ゲームオーバーになるまで一度やってみました。
3987点。
4000点に後一歩及ばず。惜しいっ！
最初にHUGEを２個作って後はLARGE狙いで。
隙間が残り２マス分を切ってもまだ悪あがき。
さすがに逆転ができないことはもうわかってたけど１点でも多くとりたいので。
隙間が残り２ドットになってもまだ色はわかります。
最後の最後の最後の最後まで粘りましょう。

個人的リンク集に暗号機能を搭載してみました。
まあ暗号とはいってもとても実用には耐えない代物なんですけどね。
まあ家族の好奇から逃れるためならばこの程度で充分ということで。
暗号化と同じ秘密鍵で復号化します。

MIDIを作るアプレットMIDIAを作成中です。
とりあえずEclipseインストールしてアプレットクラスを継承するところまで。

プレス機をちょっと改良しました。
グラフィックの変化と、ピンチ時遅くなる処理(ただし、ピンチになるスイッチが働かないのでノンストップ)。
たくさん同時消ししてもプレス機を押し返せるようにはしたけどあまり当てにはならない。

まだゲームオーバーは作っていないんですが、物は試しということで、プレス機が動く状態でプレイしてみました。
プレス機が迫ってくるという緊張感があるとやっぱり違いますね、HUGEなんて冷静に作ってる余裕なんてない。
それどころかsmallを作るのに必死で、作ったとしても連鎖できなければプレス機はその場で止まるだけ。
やはり経過時間に比例してプレス機の動作速度が上がるというのは安直過ぎたか。
動作スピードが速くなってくると、もう本当に容赦なくぐんぐん迫ってくるのですから、気付いたときにはもうおしまい。バイバイ。
プレス機ということで、物を挟んだら反発力で勢いが落ちる、というのが当初の考えにあったので、これから実装していくつもりなのですが、この勢いが落ちるという仕様にはもうひとつの理由がありまして、それは、「最後の悪あがきで何とかなる」。
そうそう、パネルγの厄介なシステム。
パネルがね、逃げるんですよ。プレス機から。逃げ場があったらの話ですけどね。

適当にガチャガチャやっててもそれなりに遊べるゲーム性と、狙ってやりこむゲーム性、両立させたいのですが、連鎖に関しては、狙って消すよりでたらめに出しまくって消しまくっていたほうが効率がいいんですよね。
適当にガチャガチャ、は、ピンチのときにこそ陥りがち。
狙ってやりこむ、は、比較的余裕のあるときに。
だからして、適当にガチャガチャ、はピンチ回避に役立ち、狙ってやりこむ、は高得点につながる、という風にすればちょうど良いバランスとなる(はず)。
だから、連鎖をするとプレス機を押し戻し、同時消しや大きなパターンで消すと得点が高い、ということにして、パターン固有の押し戻し係数は廃して連鎖の得点を下げる、いや、連鎖については充分得点が低いからいいけど。
HUGEの得点が高すぎる気がしたけどあれでいいや。
smallも、無視できる得点にしてもなんら支障はない。
プレス機の動きの部分も作ってみたり。

とりあえず現状でどの程度動くかどうかの確認のために他の人に少しプレイしてもらったのですけれども、ものすごく重いとの報告をいただいてしまいました。
で、状況を見る限りはどうやらDirectDrawの描画処理で遅くなっている模様。
GDIで描画しているプロトタイプを試してもらったところそこそこの速度が出てくれたそうなので、描画エンジンとして、DirectDrawのほかにもGDIによるものを用意しようかと思っています。

連鎖に対応しました。
コンボは、消え方にかかわらずコンボ継続時間中に次のパターンがそろったら発生して、コンボ数に応じて点数が入ります。
連鎖は、消えたパネルの上にあるパネルでコンボが続いた場合に発生して、連鎖の数だけ基本得点が倍増します。
連鎖数を画面上に表示する演出ができれば連鎖に関する基本的な処理は終了。バランスとか調整しなきゃならないけど。
コンボ終了後にBGMが止まるバグは、コンボ精算の音を出すタイミングを調整すると発生しなくなりました。それでも消えたら御免。
消しBGM＆コンボ精算が、今までは常にフルパワーでうるさく鳴っていましたが、たいしたことのない消し方のときはグレードダウンするようにしました。
DirectXのヘルプを見るとものすごく難しそうなことが書かれてあって尻込みしていたのですが、DirectMusicがメッセージベースであることから、MIDIを再生してリセットせずに曲を切り替えたら前のMIDIの設定を受け継いだまま次のMIDIが鳴り始めるのではないかと思って試してみたところ、本当にそうなってくれました。
だから、特定のチャンネルの音を消すだけのMIDIとか、必要なとき以外は音量が0のMIDIとかができてきちゃいました。
ゲームバランスはまだまだ模索中…
適当にやっていればそれなりに消えてくれるけど、でたらめにやっていたら対して消えてくれない、そして頑張って連鎖を組んだりたくさん消したりしたらどかんと点数をあげたい、そんなバランスにしたいのですが、今の状況だと狙いすぎるとかえって不利な状況になってしまうような気がしています。

パネルγのページを更新しました。
大体消しパターンと消し方が自分でつかめてきたので消しパターンのページを作ってみました。
他にもあったりしますがまああれはまともには作れないし、フリーウェアによくある、作りたいので作ってみたというやつだったりするので基本的には非公開です。
あとは、妙な消し方をしてみたスクリーンショットとか。
なにしろ消している間にも、消えている途中のパネルも、お構い無しに入れ替えられちゃうんですから、できちゃうんですね、あんなのが。
連鎖のアルゴリズムも考えようかと思ったのですが、ちょっとややこしかったので今日のところは断念しました。

ちょっと学校のレポートの途中経過でも。
2000字以上書かなければならないのでパソコンで書くと4KB分必要なのですが、適当に口語で書いてみたらあっさり超えちゃいました。
もちろんこのまま出すはずはありませんが、これだと真面目な文体にして少し補足説明を加えれば充分かなと思ったり思わなかったり。

甲骨文字、これは文字通り亀の甲羅や牛の肩甲骨などに刻まれる文字であります。
亀の甲羅とはいっても、踏んで猛スピードで飛ばすような甲羅じゃありません。
しかしなぜよりにもよって字を書きにくそうな骨なんかに字を書いたのか。
それは、祭政一致の政治で、儀式の際に神からの預言を残すためなのです！
はい、骨というと、宗教的なにおいがぷんぷんしますし、保存も利きます。
まあ要するに神聖文字ですな。
そして、甲骨文字とほぼ同時かやや遅れて登場するのが「金文」であります。
これは、神々と祖先に生贄と供え物を捧げるための神聖な器具、青銅器に掘り込まれたものでありまして、大体十文字未満で書かれ、文章というよりは、その青銅器で祭られる祖先神の名前やそれを作らせた人物の属する氏族のエンブレムなどが記されているのです（授業の配布プリント）
その意味で言うならば、この時代の文字はどちらかというと記号的な意味が強いものでした。
そうです、これから漢字が文字としての体裁を持ってくるのです。
それが、秦の時代から使われだした「篆書」です。
実はこの篆書、秦の皇帝の偉大さを称える文字なのです。
だから、これまでのいかにも時代遅れな象形文字みたいなものでなく、皇帝らしくかっこいい字体なのです。
さて、それと時期を同じくしまして、中央集権体制としまして、郡県制が敷かれました。
そうすると、郡やら県やらがたくさんできてきて、情報伝達が大変！
だから、口頭による情報伝達でなく、確実に情報を伝えて、証拠を残せる文書での行政になるわけです。
しっかあーし！
いちいち亀やら牛やらを殺して骨を得なければいけない甲骨文字やら青銅器の壷やら皿やらに書かなければいけない金文だとか、皇帝様専用のかっこいい篆書などは問題外なのであります。
そして時代は、骨や壷や石版から、竹簡・木簡をメディアとして使う時代と変わってゆきました。
(とはいえ竹簡・木簡自体は甲骨文字の時代からあったそうですが)
そのころは王様やら貴族並みの大金持ちではない貧乏小役人、言ってみれば地方公務員も普通に字をかけなければいけない時代。
軽くて安くて石や骨ほどにはかさばらない、そして何より文字を書きやすい木や竹が当たり前となったのです。
そしてもちろん字そのものも彫ったり鋳込んだりするよりも、筆で書くのに適した字となるわけです。
その字は、それを書く地方の小役人が「隷」と呼ばれたことから、「隷書」と呼ばれています。
大篆というのは、始皇帝様のかっこいい篆書と貧乏小役人のお手軽隷書の共通の祖先であります。
（プリントには詳しくかかれてなかったから後で本を読んで補足しておこう）
この隷書では、大篆を改良し、象形文字っぽく書きたいように書いていた部分を整理し、わかりやすく体系化しました。
だからこそ馬鹿小役人どもにも普及させることができたわけですね。
結構完成体に近かった隷書ですが、それで終わりなら現在の楷書が登場できないというものです。
ついに出ました！今でも通用する草書と楷書！
さて、隷書は漢の時代まで愛用されていたわけですが。
隷書の地位を揺るがす大事件！
匈奴とかから異民族が攻め込んできたんです。
馬を乗り回す強敵の騎馬民族、漢民族は勝てなかったので逃げた。
北から攻め込まれたので南に逃げた。
南には川があるので馬には渡れない。
隷書を脅かすもうひとつの存在、それは紙の発明でした。（それまでは木や竹）
かさばらないとはいっても厚さが1cm近くもある竹簡に比べて、1mm未満の脅威の薄さの紙はあらゆる方面の人々から喜ばれました。
しかも、竹簡のよさであった、軽さ・安さも紙のほうが一枚上手。
保存性は竹簡にはかないませんが、それらを補って余りある長所が紙にはあったのです。
しかし、そんな紙にも決定的な弱点がありました。
そう、そうなんです！破れやすいんです！弱くてデリケートなんです！
だから、強くてバリケードな竹簡に書く感覚で紙に字を書くとビリっといっちゃいます。
紙の普及のためには、竹にガリガリ書く方法から、紙にサラサラ書く方法に移り変わる必要があったのです。
それこそが「草書」。
サラサラサラサラサ～ラサラ書けるミミズのような字体です。
紙にも優しいミミズの字体「草書」により、問題は解決されました。
強いて問題があるとすれば、漢がそのころ北方民族に負けていたことでしょうか。
それで開き直ったのか何なのか、貴族たちは戦いなんてくだらんとか考えるようになりました。
それで貴族たちは明けても暮れても文化やら芸術のことやらを話し合うようになりました。
戦争やら行政やらは二の次三の次です。
で、その矛先は草書や隷書に向けられました。
「草書や隷書はイナカくさい。もっとナウい字体はないのか」と。
そしてまた、貴族趣味以外にもナウい字が必要とされた背景があったのです。
それが「科挙」制度。
まあたぶん、楷書みたいにきっちりした文字でないと公正さは保てなかったんでしょうな。
こうして現在の漢字の完成体「楷書」ができ、千年以上もたった今でも使われ続けているのです。

基本得点とBGM実装。
ただし基本得点には連鎖による倍率掛けはなし。基本得点は基本得点のままです。
DirectMusicを使ってみたのですけれども、ゲームとの同期が取れなくていろいろ手間取りました。
消しBGMがコンボ終了後も鳴り終わらなかったり、コンボが終わった後に無音になったり…
先日言っていたチャンネルの問題は、実際起こり、消しBGMの楽器で次のBGMが鳴らされたりもしたので、チャンネルを完全に分けました。
コンボ精算のときの音をどうやって分けるかというのと、消しBGMの同時消しに反応する部分をどうやって実現するかということを現在研究中です。
ところで、適当にプレイしながら思ったのですが、これ、何も考えずにパネルを出しまくって消しまくっていたら勝手にどんどん最小単位の4つパネルの四角形ができて得点がたまっていくんですよね。しかもかなりのスピードで。
これでは、運を天に任せてひたすらパネルを流していくゲームになりかねません。
そんなゲームバランスのないゲームなんか、自分で作って自分で遊べばいいのです。人様に見せるような代物ではありません！(そういうことで、私のパソコンにはバランスも糞もないくだらないゲームがたくさん埋もれています)
だから、まだ途中ですが、ゲームバランスを考えるためテストしてみました。
4つ消しのみを狙い、ひたすら出して消し、まぐれ当たりを狙ったら10000フレームで1020点。
9つ消しを狙い、適当に出しつつ入れ替えで消していったら、まぐれ当たりも含めて1270点。
かろうじて9つ消しのほうが高得点ですが、あまり割に合いません。
だからといって4つ消しの得点を下げすぎると4つ消しが「ハズレ」になってしまいます。
4つ消しの価値はそれなりに残しつつ、狙うならまぐれ当たりよりももっと大きく、という方向に持っていけるゲームバランス(例えば、4つ消しを連鎖数稼ぎに使い、数がたまったところで大きな塊を作れるようにして更なる高得点を目指すとか)にしたいものです。
ちなみに、灰色パネルというのがたまに出てきまして、これは普通の方法では消えてくれません。
で、特殊なパターンに揃えて消すわけですが、これがまた、完全に消せるパターンだと難易度の割りにやけくそに得点が低く、それなりの得点が入るものは8個消えて1個発生という、実にプレイヤー泣かせの消え方をしてくれます。

MIDIどうすべきか考えていたりするのであります。
リアルタイム性が必須の消しBGMは通常BGMとチャンネル分けるべきかもしれないと思っていたりするのであります。
なぜなら、パラメータ変更に手間取っていたらピアノ化したり前に使っていたりした楽器が勝手に使われたりして困るかもしれないと思っていたりしたからなのであります。
ともかくMIDIを再生できないことにはどうにもならないのでリソースからMIDIを読む処理を作ることにしていた次第であります。
ヘルプのチュートリアルには記述が見当たらなかったのでプラットフォームSDKのヘルプと照らし合わせながら作っていたりするのであります！

パネルγでやったことと同じことをPRG±0でも。
ウィンドウをクリップしてウィンドウモードでウィンドウを動かしてもウィンドウの位置に合わせた位置に正しくウィンドウ内に収まるようにウィンドウにウィンドウの内容を表示できるようになりました。
さらに保存してあるデータのタイトル画面を表示できるようにもしてみたかったんだけど面倒だったんで後回し。

パネルγの動作チェックも。
空中で素早くパネルを揃えることにより脅威の空中消しが！
例によって得点は変わりませんが。

「パネルγ」のノーマルゲームのコアの部分を作りました。
まず、パネルの生成。
イレカエモードで(といってもまだこれだけなんですが)、何もないところをマウスでごしごしするとパネルがだーっと降ってきます。
で、逆にパネルがあるところを右クリックでがしがしやるとパネルがざーっと消えます。
正直言うとパネルを直接消す機能はいらないと思ったのですが、実際に操作した感覚ではパネル入れ替えは想像以上に神経を使う細かい作業なので、通常時はともかくピンチのときはとっさにパネルを退避できそうにないので、一時しのぎに使えるようにパネルを直接消す方法を用意しました。
で、次がパネル消し。
アルゴリズムは作り始める前から考えていたので一日で作った割にはまあまあ。
得点加算のところの演出までできたので結構満足。
現状のゲーム画面をアップしておきました。

学校のActiveBasicで、行単位でデータが格納されたファイルを整理する「LineConstructor」を作っていたのですが、メニューを作成すると謎のエラーが出てコンパイルが通らなくなるという事態が発生。
もちろんエラーの原因を究明しようと思ったのですが、ヘルプにも公式サイトにもエラーの解説はなく、該当するエラーをクリックしても存在しないFドライブのファイルを参照してデバッグも糞もない状態。
一応それらしきファイルを探してきて覗いては見たのですが、エラーの原因となっている部分と関係のありそうなところは確認できず。
VS.NETがだめ、JBuilderもだめ、ActiveBasicもだめとなればもう残りはさっぱりわからないDelphiのみ。
こりゃ学校じゃプログラミングはできそうもありません。

「パネルγ」のマウスクリック感知の部分を作って、タイトルを動かせるようにできました。
まずは終了処理を作成。
ウィンドウを直接閉じると強制終了がかかってデータが破損する可能性があったので正規の終了方法を用意ということで。
これでゲームメインへのシーン移動もできるようになったのでこれからはメインのほうを集中的に作っていこうと思います。

さて、HPMでも更新しようかと思ったのですが、やる気が起きないので「ふにゃふにゃ」のほうで。

ついでに、「Bomber丸World」のページも更新しておきました。
ふにゃの仲間の歴史がわかっちゃいます。

Lunascape2入れてみました。
使ってみた印象は、Luna2でできていたことができなくなっていたり、よくわからない機能が説明もなしにたくさん付いていたりで、かなり使いにくいという印象でした。
大部分は慣れで解決するのでしょうけれども、慣れではどうしようもない不具合などはできればつぶしていってほしいものです。
そのいくつかは既に報告があったようで。
まだまだ安定版には程遠いようですなぁ。

「パネルγ」のタイトル画面を作りました。
ゲーム名はまだ表示されませんが、ゲームメニューがずらっと表示されます。
背景とメニューの文字の明度が近いので見づらかったのですが、マウスカーソルを合わせると背景色を明るくして見やすくなるように調整しました。
今回アップしたスクリーンショットではプレス機が表示されていなかったりしますが、実際の今の状況だとプレス機が表示されていますし、パネルの並び方も若干異なり、メニューの位置も変わっています。
まだマウスボタンの押下を検出することができないのでメニューを押すことはできません。

「Bomber丸World」のページを更新しました。
主人公の社会での扱われ方がわかっちゃいます。

あっ、そろそろ更新する時期だなぁ。

３Ｄの新しい表現を考えてみたり。
トゥーンレンダリングは影を極端に強調したシェーディングと輪郭表示に関する技術を使うわけですが、たとえば、ドラクエ３のレムオルのように輪郭だけを表示して本体を表示しないとか。
しかし、それは意外に難しいことなのです。
なぜなら、トゥーンレンダリングの輪郭抽出は、本体があることが前提であるため本体を除くと輪郭が輪郭でなくなってしまうのです。
したがって、普通にトゥーンレンダリングで本体つきの輪郭を描き、あとから本体を抜くのです。
真っ先に思い浮かぶのは、本体に向こう側の景色を写して見えなくする方法。
もうひとつは真っ黒な背景に真っ黒な本体と白い輪郭を描き、白い部分だけを背景と合成する方法。
最初のは「TWINTAIL LOVERS.」の「真・ステルス」と「トゥーンシェーディング」を組み合わせて使えばそれなりにできそうです。
もうひとつのほうは、輪郭用テクスチャを用意してそこに輪郭を描画して、ビルボードで表示すればOK。
前者のほうが前後関係は正確に表現されますが、後者のほうが輪郭以外にゆがみが出ません。
いずれにしても実際に作って確かめてみないことには確かなことはいえませんが。

「Bomber丸World」のBGMアップしました。
研究所ダンジョンボスですよ。
かっこつけたつもりがぷぴーとかぴっぴこぴーとか入ってて台無しな曲ですよ。
トゥッティとはどんなものかなんとなくわかってきた予感。

「Bomber丸World」のBGMを一つ作ってみました。
最初のボスの音楽ということで、ボスらしい印象を、そして、「Bomber丸World」のボスということで、単なる強いだけのボスじゃないということで、アレンジ用のパートも。
アレンジというよりは余計な音が混じっているというほうが正しいのですけれども。
ほぼイメージどおりにはできたけど後半のStringsが今一気に入らない。

「ふにゃふにゃ」のステージ作成講座を書いてたりもします。
当たり判定の原理を書いてたりします。

考えてもみればパネルγはマウス操作だったんですよ！
というわけでマウスカーソルのソフト表示に対応。
画像転送の部分も改良。
一部がはみ出すような場所にも表示できるようになりました。
さて、気になるのがBGMに使うDirectMusic。
IDirectMusicPerformance8::PlaySegmentExでi64StartTimeを0にして実行するとできるだけ早く演奏が開始されるらしいけど、この遅延時間が60msを超えると使っている音楽の性質上異常演奏になってしまうのです。
できるだけ早く、だから結果が不定になるのなら、あえて開始時間を設定して開始時間のほうに遅延時間を吸収してしまうとか…

パネルγ、ハイスコア記録をどうするか思案中。
文字列の表示は結構遅いようなので(おそらくフォントから画像を計算で作成しているため)、また、画像主体のところへWindowsのテキストボックスを表示するのはあまりよくなさそうな気がするので、使える文字を英数字に限定してフォントをビットマップの形で使おうかと思っています。
そういうことなので善は急げということでＭＳゴシックのフォントで画像を作成。
プログラム的なところでは、シーン管理クラスを作って、タイトルシーン(ただし真っ白な画面が表示されるだけ)を作りました。
このシーン管理クラスの特長は、シーンが増えても管理しやすく、次のシーンへの切り替えのときにパラメータなどを詳細に指定することができることなどですが、短所として、ウィンドウを閉じて終了するとシーンでの処理がその瞬間に強制終了されるため何が起こるかわからないということなどがあります。
タイトルメニューの仕様も考えてみたり。
「ふにゃふにゃ」と同じく、項目を上下に並べ、左右キーでその子項目を動かせるようにしようかと思っています。

アクセス解析に表示件数制限の機能をつけてみました。
何万件もあるログを一度に表示して全部見ようなんて人はいないでしょうから、無駄に表示時間やメモリを費やす必要もないわけです。
あと、必要ない情報をカットする機能が必要か。
今回の利用目的と明らかに関係ない項目は最初からないほうが絶対に都合がいいのです。

行ごとにデータの並んだテキストファイルの内容を整理する「LineSort」を学校のActiveBasicで作り始めました。
各行を五十音順に並べ替えたり、逆にシャッフルしたりできます。

QuickTimeをAppleのサイトでダウンロード。
で、そのときのメッセージが
おめでとうございます！
いや、便利だとは思うけどおめでたくありませんよ、どっちかというとこういうときの定番メッセージは「ありがとうございます！」だと思いますよ。

随分と久しぶりですがRPG±0、やりましたよ。
ええ、弟から不満が出ていたマップのスクロールをスクロールバーでより直感的に、よりWindowsらしく操作できるようになりましたよ。
ついでに起動時の標準で出るウィンドウをマップウィンドウだけにしました。
で、敵キャラのこともそろそろ考えようかとも思ったのですが、キャラグラフィックを作るのが面倒だったのでフリー素材を探してみたのですが、どうもこの辺は作者の個性が出るところらしく、使いまわしの利くフリー素材として提供されているものはごく少数でした。

う～ん、もともと色のあるメッシュでトゥーンレンダリングをすると元々の材質(色)が無効になってしまいます。
材質にはライティングの設定なんかも入っているためライティングをオフにすると材質もろとも無効になっちゃうようです。
例えば材質ではなく頂点カラーを使うとか？
例えばテクスチャに色をつけるとか？

あう～、レポートやらねば…
明日中に終わらせて月曜日は休みたい。

パネルγのページ更新しましたよ。
ルールにパネル発生メカニズムとプレス機の恐怖を。

今日レポート書き始めないと今までの経験からすると間に合わない。
やるでえ。

賞味期限切れ直前のウニがまずかったか…
最近の不規則な生活も影響したかも。

いろいろできそうに見えて案外面倒な設定が必要だったり結果が結構地味だったりして、画像ほど際立った効果は実感できませんでした。
さりげなく使って陰で雰囲気を盛り上げるような使い方なのかなと思ったりします。

パネルγのタイトルBGMを作りました。
パネルを消したときの音とゲームのメイン音楽との組み合わせです。

DirectMusicですよDirectMusic！
VB用でもC/C++用ほどではないけどいろいろできるんですよ。
今夜はメッセージ送りまくって遊ぼう。

画像表示ができるようになりましたよ。
画像読み込みがDirectDrawに入ってないのって納得いかない！
でもないもんはないから自前で。というかサンプルからコピー。
VBのDirectDrawにはあるんですけどね。
ウィンドウモードはメインにするつもりはないけどデバッグやウィンドウで使いたい人のために一応対応。
そのためにいろいろ面倒なことがあって。
ウィンドウモードで正しく表示するためにはクリッパーを仕掛ければよいということで、使ってみたら、使ってないときよりはマシだけど、描画位置そのものはディスプレイ画面の左上だからウィンドウ内に正しく表示されない。
他のサンプルではどうしているのかと思えばただ単に正しい位置に描画されるように位置を補正しているだけ。
それに倣ってこっちも補正を加えるようにしました。
これからはもっと開発スピードが上がりそうです。

履いていた靴があまりにもボロだったので新しい靴を買いました。
試し履きせずに買ってしまったのですがピッタリだったようで安心しました。

「パネルγ」のプレス機の絵を描きました。
金属光沢がよくわからなかったのですが…まあまあ妥協しておくことにします。
しかし256色パレットを使っているのにまだ16色パレットにある色しか使ってない…色を使うために絵があるわけじゃないけど、気になるところではあります。