カラーサークルを描かせようと思ってたらこうなった。

あともう一つ作ろう……

ちゃんとレベリングしないと簡単にやられてしまいそうですねこれは……

あれ、考案当時はフヨシの髪色って栗色だった気がするんだけど、ここの絵だと白銀だわ。 短編集作るならプチコンよりうごメモかなぁ… 実はまだサンムーン買ってない。

実行例 Jで曲線の方向を変えたり、Cで細かさ曲線の細かさを変えたりできます。

【QSP】黄金長方形と、その辺に等しい長さの半径の円弧を描写するプログラム フラグ管理や手法がごちゃごちゃしてます。

それによって起きる弊害は既に述べました。

対策として、SPSETで管理番号を取得するのではなく、SPUSEDで使われていない管理番号を探しだし、スプライトを作成する前にパーツの情報を保管する方法。あるいは、パーツに対してSPOFSやSPLINKで結合する際に、SPCHRで再度SPDEFの情報を読み込む方法ですね。今回は後者で解決しました。

今までデータ構造が「SPDEFによる情報→パーツの情報」だったので、SPDEF→SPSETで良かったんですよ。 でも、SPDEFで横反転のパーツを作るにあたって、データそのままでSPDEFしたあと、アトリビュートに横反転を足したものをすぐにSPDEFした場合、通常の画像と反転の差分がひとまとまりになって、定義番号に対するアニメーションが少し面倒になるんですよね。 なので、データ構造を「パーツの情報→SPDEFによる情報」にして、パーツの情報から差分(反転などではなく、表情や模様の違い)の個数を用いることで、通常と横反転を独立させた構造にしたんです。 パーツの情報は各管理番号に対していくつかのパラメタを持つ二次元配列に保管するんですけど、管理番号はSPSET()で手に入れるまで解らないので、SPSETで管理番号取得→SPDEFで定義→ごにょごにょ…という流れになってしまったのです。

SPSETしてからSPDEFで同じ定義番号に対して情報を書きかえると、SPCHR等で更新しない限り、表示していたスプライトに変化が無い仕様に少し手こずった。

関数を定義するときに、引数と戻り値それぞれの名前がかぶっちゃダメなんじゃないかな。 OUTの後にあるXを別の名前にしてみては。 OUT使ってるからRETURNは要らないはずです。

テクスチャは後でちゃんと描きます(´･_･`)

四方向と二方向、それぞれ別の命令で2Dモデルを作るようにした。方向自体がフラグで管理してるから同じアニメデータを使い回せる……はず。

コード。 何かが不足してる気がするけど何か解らない。 どうしましょ。

左から、向きが0,1,2,3,4のモデル。 優先度撤廃。代わりにどの方向を向くかでZ座標を反転するか否かを決めるマスクを用意することでそれっぽいのが出来た。 b2が正のとき、必ずX座標を反転するようにしたため、定義できる方向は4が限界。うーんこの

z座標もうひとつ欲しいな

!の数が逆だった。

2Dモデルにy軸の角度を与えると使いづらそうなので、妥協してX,Zの反転で方向を設定することに。 この!!○-!○って形なんだかおもろい

全額デレステに突っ込んでちっひに貢げ。 うそ() プログラミングの学習本とか良いのでは

良いですぞ