数学の=(イコール)は、右辺と左辺が等しいことを意味していますが、SmileBASICでは左の変数に右の値を代入するという意味になります。 なのでスクショの場合、π／4という変数になんか値を代入することになりそうですが、変数の名前に／を使うことはできないので、エラーになったのでしょう。それを?(PRINT)しようとしたこと自体も間違いか。 まずはプログラム(SmileBASIC)の基本的な文法を調べるなり試すなりして知る必要がありそうですね。 ＃私が円周率を正確に表現しようとするなら ＃「円周÷直径」 ＃だって10進数で示そうとしたって無限に ＃続いちゃって無理なんでしょ?:-p

＃なんかプレイ日記久々。 一生懸命パラパラアニメ描いてたんだけど、お絵かきツールの謎のUNDOのせいで2度ほど振り出しに戻るを食らった^^; そしてPAINTは2度と使わないと誓いました。いいんだぁ～1ドットずつプチプチ打つんだから(T_T) お絵かきツール使ってると、直したくなって他が手に付かないという呪いにかかっちゃうんだよなぁ。それでしばらくイジんないようにしてたんだけど、イジっちゃったなぁ。 とりあえずUNDO何とかするか。あのソースコード見るのもうウンザリなんだけど。 う～ん、やっぱり嫌だなぁ^^;

いろんな可能性の考えられるプログラムですね(^o^) ピアノの調律とかギターのチューニングとかたけしの挑戦状とか。 口笛で試してみたけど私のドはソだった(何長調?^^;)

左側のボタンで「複写」→「消す」ってすれば一応ミラーリングになるけど、それじゃあタッチが無効ってことですよね。それに何だか処理も厳しそう(前にそれでゲームしてたらプチコン自体が処理落ちみたいになった)。 プログラムでやるにしても、いちいちDISPLAY命令で切り替えながら両画面に同じ絵描かないといけないし。そしてDISPLAY命令駆使したプログラムはデバッグとかも面倒だと思いました(今DISPLAYどっちだっけ?みたいな)。 BIG専用のXSCREEN 4みたいな、両画面高解像度でひと続きのモードがあっても良いのになぁとちょっと思いました。

ときどきキャラが呟くとか(シーマンみたいな)。 「マンガの映画化?あらすじの映画化だろ」的な 可愛いキャラが毒を吐く。キャラは可愛ければ可愛いほどいい。

USBキーボードだと当然INKEY$になるんだけど、BUTTON関数みたいに、押してる間、瞬間、離したとかの判定も面倒なんだよね。 で、トップメニューからのオプションでキーリピート値変えれるけど、それもちょっと面倒というか、怖いよね^^;すごく小さい値にしちゃっていいんだろうか?とか。 SilverBlueさんの言うように、タッチパネルの方で自前キーボード作ればTOUCH関数なので融通効くかと思います。

あー、携帯できるってメリット見落としてましたね。逆にそっちの方が身体的に縛られてなくて自由か。 DEFで1つ。 DEFはなるべくローカル変数だけで動かしたい(まだまだ自分プログラム資産少ないので、他のプログラムでも流用できたらと思って)けど、引数超長くなっちゃうとか、複数のDEFで使ってる情報(画面サイズとか)で、どうしてもグローバル変数のまま使っちゃう時は、そのDEFのところにその旨コメント残すようにしてます。DEFからDEF呼んでる時も。

昔は複数人で手分けして1つのプログラム(ソフト)作るよりも、1人のデキるやつが1人で作った方が良いものができあがる、って思ってたけど、今の時代大規模になっちゃってそうも言ってられないんだよねぇ。 3号は結局3DSって言うハードウェアの縛りがあるからプログラムの生産性(結局はこれだよね)もそれに伴っちゃう(画面ちっちゃい、ハードウェアキーボード使えない)感じかなぁ。 ゲームスロットに何か差してTVに出力できたりハードウェアキーボード使えるようにならないかなぁなんて妄想したもんです^^;

文字透明抜きの例。 これだとループは文字数分の特殊効果タイルGLOADのだけでいいはず。 ARYOPは要らん。どうかのぉ?

お、ARYOPありでしたか。3号だと別売りなんだよね。自分だけで使うぶんにはいいけど、公開考えたとき高度サウンドユニット必要だよ制約付いちゃうのアレかなぁと思ってました。

＃文字のことしか考えてなかった^^; 全くその通りでございますm__m 背景潰れちゃうねぇ。 ポイントは縦、横用の2つのFORループを速くする、もしくは省略できないかになると思うんだけど。 更に背景とフォントデータでも同じようにして文字部分透明抜きの画像作って、更に重ね合わせるとか(遅いかなぁ)。 ほか思い付いたのは、IF 1なら代入、みたいなところを無条件にかけ算して代入とか(速くならないか)。 ＃ARYOPは...ダメだよねぇ^^; 最近仕入れた知識だと、FORじゃなくてREPEATにするとか、くらいかなぁ。

2コ乗っけるのは難しそう。座標を同時に複数認識させる工夫が。 ダイスなら、GamePadの振動機能で乗せたダイスを振らせるとか。厳しいか^^;

GamePadに乗っかれば何でもいいような気がしてきた。別に丸くなくても。タッチされてると認識されるくらいの重さがあれば。 問題はちゃんと乗っけられたもので操作されてるのか、タッチペンでズルしてるのかを判定できるのか。タッチが離れちゃダメ、タッチ座標の移動がちゃんと物理法則に従った加速度であるか、辺りをチェックすればいいか。 ＃って本当に本気か!?

フォントデータは文字列変数に入れとかなきゃいけない事情があるのかな? グラフィックの数値配列データとして持っておけるんだったら、例えばフォントデータの0/1を反転させて文字部分が透明になるようにしといて、特殊効果用のグラフィックをGLOADした上に、フォントデータをGLOADすれば、文字部分が透けて特殊効果が文字として浮かび上がるじゃないかなぁと。 それだとW,Hの2つのFORループ不要になって、GLOAD２発で済むから速くなると思う。

GamePadに乗っかればOKです。但しあんまりデカくて重いと腕が疲れるのと、GamePadが重さに耐えられない危険もあるので、そこは自己責任となります:-p

近日公開予定。 ※別途本物のビー玉が必要になります。 ＃本気か!?^^;

わ～い、おんつくがBIGにも対応してくれたよ～(^o^) 公開キー:EKE3YXCX でも作者のナツキさんはBIGお持ちじゃないから、もし何か動作おかしいことがあっても仕方がないんで注意してね(そういうときは多分BIG自体の動作の問題である場合がほとんどだと思うから)。

おぉ、早速の対応ありがとうございます(^o^) BIGのコミュの方でも宣伝しといて良いですか? BIG自体の問題でもし動作がおかしくても、ナツキさんに苦情挙げないように言い添えておきますので^^;

＃お、ここにも素敵なトピが。 私の場合(って書き出しになるよね^^;)、あんまりちっちゃいモジュール(3行4行くらいの)がたくさんになっちゃうと流れ追うのめんどくさくなっちゃうので、そこそこのサイズ(1画面くらいかなぁ)でモジュールになってる方が見やすいかな(まぁ処理の都合に依るんですけどね)。ちっちゃいんなら別にモジュールにしなくてそこにそのまま書いちゃえ、って。 あと、プチコンは1画面で把握できる情報少なめ(プログラムの2箇所分割表示とかそのままではできない)なので、スペースとか改行、なるべくぎゅっと縮めるようにしてます。著しく見辛くならない程度に。プチコンの文字全角っぽいからぎゅっとしても意外と見やすいんですよね。 ＃ユーザ関数びっしりで白い文字だらけの ＃EDITモードの画面見ると途方に暮れる^^; ＃でも細かいDEFたくさんあると、なんか ＃おしゃれにみえる(なんだそれ?)