プレイ日記
すう SU-KUN
『UI関数を作ろうと企画中…』 UI(GUI)ってゲームでもツールでも必要になるけど、プチコンで作るのって、リソース準備したり、配置をこまごま調整したり、意外と大変じゃないですか?それに、作品毎に毎回作り直すのも無駄に感じます。 そこで、DEFを使ったUI関数を作ろうと企てたのはいいのですが…。(ちょうどいい画面がなかったのでスクショは適当…)
22そうだね
プレイ済み
返信[1]
親投稿
すう SU-KUN
最初に、いくつかの市販ゲームのUIを研究しました。結果として、WiiUのゲームはボタンなども複雑に動いたりする物が多かったですが、3DSの方は、意外と色反転するだけとか、思ったよりも動いてなかったです。このあたりはハードウェア制限によるものでしょうか。3DS程度の物ならプチコンでも十分に再現可能と思いました。 次に実装を考えました。プチコンのBG面を1つ犠牲にして画面全体をおおい、仮のGRP面として使い、全てのオブジェクト類を自前で描画しようと考えました(グラフィック(GRP)面はスプライトに隠れてしまうため使えません)。 でも、市販ソフトを見ると、多くのボタン類は、アニメーションで色が変わったり、拡大縮小したりする事が多かったので、プチコンで実装するならスプライトを使わないと、速度面などで難しそうです。
2そうだね
プレイ済み
返信[2]
親投稿
すう SU-KUN
ただ、スプライト面のGRPは、ゲーム本編などで割とギリギリまで使っている事も多く、それと同時にUIの方で、大きめのボタンやウインドウなどの領域を確保するのは難しそうです…。かといって、BGだと、半透明も使えなかったり… 結局は、ボタン類はあまり動かない仕様にしてBGに描画、カーソルなどの動くもの、半透明の背景などはメインプログラム側でスプライトを用意して、関数に渡すと言う形で実装しようと考えています。 でも、BGも表示できる面は4面あっても、参照されるGRPページは1つしかないですし…、うーん…、UI専用のGRP面が欲しいですね(;´∀`)
2そうだね
プレイ済み
返信[3]
親投稿
ナルミンチョ naru_starfy28
GRP面はGPRIOで表示順位を変更できるので、スプライトに隠れて使えないとは思わないのですが…… 見た目がしょぼいけど、四角のスプライトの拡大縮小を使えば、アニメーションを含んだUIを、GRP4の消費が比較的少なくて済むと思います。UIの凝った未完成のゲーム(関数で統合的には処理をしていない) 7KK8EERM
1そうだね
未プレイ
返信[4]
親投稿
ナルミンチョ naru_starfy28
全面に表示するタイプのウィンドウは角の模様のみGRP4で書いておき、背景は(模様なしになりますが)四角い画像を拡大縮小させて、位置とサイズを合わせるという感じです。また、SPCOLとSPHITRCで、タッチ操作の当たり判定を直感的に扱えると思う。SPCOLのマスクを0にすれば、disabledなボタンを定義できます。
1そうだね
未プレイ
返信[5]
親投稿
いいねぇ (RPG用の基本システムなら作れる人)
0そうだね
未プレイ
返信[6]
親投稿
とはいえ、他人にとっての使いやすさを追求するのは難易度が上がるなぁ
0そうだね
未プレイ
返信[7]
親投稿
画像領域を汚さないのが1番の課題かぁ… BG/SP各512四方はきついようぅ
0そうだね
未プレイ
返信[8]
親投稿
すう SU-KUN
>ナルミンチョさん おお、すごい!ナルミンチョさんの作品のUI凝ってますね^^これだけを組むのは結構大変そうです。リソースも拝見させてもらいましたけど、512x512ぎゅうぎゅう詰めって感じですね。 GPRIO命令は昔触ったまま、すっかり忘れてました><;一方のGOFS命令にZ指定がないのって、プチコンのアップデートで後からできたからですよね。 ウインドウなどはやはり少々面倒でも四つ角を別に用意して合成する方がよさそうですね。それから、タッチ判定もスプライト使うと楽ではあるんですよね…(スプライト万能説;;;) >あまさとさん 今回ライブラリ作るのも自分向けが目的なので、他の人にも使いやすくできるかは未知数です^^;でも、WiiUスレに投稿してますが、3DS対応予定です。そうそう、GRPページ、余ってる分をSPやBGの2枚目に使いたいですよね…><;
1そうだね
プレイ済み
返信[9]
親投稿
みなつ tksm372
タッチ判定は、色を使うとラクチンな気がしますヽ(´▽`)ノ 余ってるGRPを使って、ボタンと同じ位置(と形)にボタン毎に違う色を塗っておいて、タッチされた座標と同じ場所をGSPOITして、その色でどのボタンが押されたかを判定する感じです。 (この判定用のGRPは表示には使わず、実際に見せるUIは別GRPに表示しておきます。) 鍵盤を押すと音が出るプログラムを作ったときに、この方法を使いました(≧∇≦)b ただ、GSPOITで採れる色はRGBそれぞれ上位5bitなので、下位3bitは使わないようにしておく必要がありました。 あと、判定用GRPに色マップを一旦描画したあとGSAVEで配列にしまっておき、GSPOIT()の代わりに配列を参照する(例えばimg[Y][X])ようにすれば、GRPを消費せずに済むのでお得かもーヽ(´▽`)ノ
1そうだね
プレイ済み
返信[10]
親投稿
すう SU-KUN
>みなつさん おお、ドット単位で判定できる上に、プログラムも楽ちんですねー^^(そのメリットは大きい…) このUIライブラリ、将来的にはPICSなんかにも使用しようと思っていて、GRP面はいっぱいいっぱいになりそうなので、実装するとしたら配列変数にオブジェクト番号で保存かなぁ… すうも、シンセサイザーを随分昔から作りかけているのですが(なぜかBIGで動かないので3号用…)、黒鍵の当たり判定めんどくさい!と思ってたので、この方法を使うといいかもしれませんね^^情報ありがとうございます。
2そうだね
プレイ済み