ぼちぼちまちま日誌2

カテゴリー「覚書・小ネタ」の検索結果……2件

【ウディタ】デバッグで詰んだ箇所メモ

ウディタ製ゲームのバグ取りの際に何十分も足止め食らった箇所として記憶にあるものの個人的まとめです。
起動条件・イベント移動系のバグがないのは作ってるゲームの仕様上ほとんど使うことがないからです。

【CDB読込み/書込み場所の指定を間違えてる】

20200419170539.PNG
割とやらかす。
下みたいに指定する変数を間違えた例について、単純に変数の指定を間違えた場合ならまだいいんですが、「Cself24で値を取ってCself25に入れて、Cself25を使って違うDBから値を取る……」みたいなことを何回もやって「あれ、これってCself24?Cself26?」ってことになるとバグ取りで大混乱が起こります(実際に起こりました)。DBにアクセスする可能性がある変数が複数存在する場合は名前の付け方に気をつけような……!

【数値代入の変数間違えてる】

20200419170540.PNG
これもまぁやらかす。明らかにおかしい値が出たら多分これ。
バグったらバグ起こった箇所前後を精査することになると思うので、前後のやつに比べるとある程度気づきやすいと思います。

【DB読込んだつもりだったけど読み込んでない】

つい最近こいつで30分詰みました。
条件分岐Aの時にa,bを、条件分岐Bの時にb,cを読み込むとき、条件分岐Bで実はbを読み込んでいなかった みたいな奴です。
前回呼び出した時のbの値が残っており、条件分岐Bで処理したいbの値と偶然一致したりすると上手く動いたりするのでまぁ気づかない。
ちなみにこれについては、「DBを読み込むタイミングを統一する」である程度対策取れます。というかスクリプトの視認性考えても読み込むタイミングを統一したほうが良いかと。
ただ、DB読み込む項目数が極端に多い・文字列を複数読み込む場合などで処理落ちが心配な場合は、とりあえず最初の処理でCself10~Cself99=0入れるのが良いと思います。それで処理おかしくなったらこれが疑わしいかなー。

【ウディタ】描画座標シフトメモ

20200326211151.PNG

ウディタの描画座標シフトとようやく和解できたのでメモも兼ねて。
正直合ってる自信あまりないのでここ違くね?とかあったらツッコミください。

前提の話

20200326211149.gif

上のGIFはX=200で表示している★マークを200pxスライドさせたものですが、これを実行する方法としては以下が挙げられます(他もあったら補足オナシャス)
(1) ピクチャ移動でX=400を指定
(2) ピクチャ移動で相対座標でX=200
(3) 描画座標シフトでX=200シフト
20200326211150.PNG
1の例はともかく2と3ってほぼ同じじゃね?ってところから今に至ります。ってことで2と3の違いをザックリまとめたあと、使い分けについてのメモりながらのまとめです。

てかどう違うんだよ

前提の話であげた例のX=200を2回実行してみます。
(a)ピクチャ移動で相対座標X=200を2回やる
(b)描画座標シフトX=200を2回やる
20200326211151.PNG
aの場合、今★マークがあるのは200(最初の表示場所)+200(相対移動1)+200(相対移動2)=600ですが、bの場合は200(最初の表示場所)+200(シフト分)=400です。まぁつまりそういうことです。

使い分け例

これは前提の話(1)の移動方法も含めてのメモです。多分実例上げたほうが早い。

ケースA : 右キー押すとピクチャを100px動かす
(1) 初期座標+100+100+100……
(2) 押される毎に相対座標100
(3) シフト量 = 100×右キー押された回数または押される毎に+10020200326211152.PNG

もしかしなくても一番簡単なのは(2)。(1)と(3)は手間としては同じですが、変数操作+のピクチャ情報取得で描画座標シフトの値を取ることはできないことを考えると、(1)のほうが管理的には楽なのかなぁと。後で詳しく触れますが、「描画座標シフトした結果描画されている位置≠ピクチャ座標」なのでここ注意。
ちなみに横スクロールゲームを作る際プレイヤーをピクチャとして描画する場合は移動量を相対でプラスしていくよりも下のやり方のほうが安定すると思います。

ケースB : ウィンドウ表示の際、後半がゆっくりになるように表示する
(1)1回目2回目共に同じ座標を設定し、1回目の移動はディレイ0で、2回目の移動は一定ディレイ置いてから実行
(2)何か上手いこと頑張る(スクショ参照)
(3)座標で指定する例と大体同じ。ただ描画座標シフトにはディレイはないのでウェイトで擬似的にディレイっぽくしています。20200326211153.PNG

(2)はちょっと面倒くさい……というか切り替わるタイミングで一瞬止まったりして上手く行かなかった記憶があります。ってことで、(1)と(3)の事例で絞ります。
移動ピクチャが1枚または複数枚で同じ座標の場合は(1)のほうが記述量が少ないので管理しやすそう。(3)が力発揮するのは座標がバラバラの塊を移動する時ですかね。

つまり描画座標シフトって何

ってことで再び本題。最初に「描画座標シフトと相対移動って大体同じだろ」って言いましたが、相対座標が「○○px動かす」を得意とするのに対し、描画座標シフトは「目的地の○○pxまで動かす」を得意としてるのかなーという感じです。言うまでもなく「目的地の○○pxまで」って動かし方を一番得意としているのは座標で指定する動かし方ですが、座標指定は座標指定ゆえに座標がバラバラの複数枚数の位置関係を維持しながら移動させるのは苦手、というか面倒臭いです。20200326213132.PNG

描画座標シフトが生きてくるのは、「それぞれの位置を維持しながら指定位置まで複数ピクチャをずらすとき」なのかなーと思います。例えばRPGゲーム戦闘画面のHPゲージとMPゲージを動かすときとか。座標をガッツリ指定するとなると「HPゲージはxxピクセルでMPゲージはxxピクセル……」と算出する必要がありますが描画座標シフトならピクチャ指定して○○px遷移でOKです。
もちろん相対座標でもできるんですが、使い分け例ケースBで示したように緩急つけるとなるといちいち「何フレームは何px動かして……」と算出しなきゃいけないので面倒臭い。

一方描画座標の欠点は間違いなく「描画座標シフトした結果描画されている位置≠ピクチャ座標」。例えば複数コモンで1枚のピクチャをアレコレしてる場合、コモンAで初めに座標(0,0)でピクチャ表示→コモンBでX200pxシフト→コモンAでピクチャ移動(200,0)みたいな時、予想したピクチャ位置とは当然ずれます。あとピクチャ情報取得で描画座標シフト量は取れないので「変数操作+」のピクチャ座標取得であれこれする場合も当然事故ります。

まぁつまり、ガッツリまとめると描画座標シフトって「複数枚のピクチャを対象に、それぞれの位置を維持したまま何かをスライドする時」に特に強いのかな!と思います。