昼にテレビを見ていたら「投票済証」と言うのがあって、実は言うと貰えるとのこと。 実際に言ってみたら、「一枚でいいですか？」と聞き返されました^^; 使い道はよくわかりません。 テレビでは、期間限定でこの「投票済証」を見せると割引になったり、おまけがついたりするお店もあるのでお得だよ、と。 「投票済証」は数に限りがあるので早めに行って貰った方が良いよ、と。 投票を促す為の小ネタ情報だったと思いますが。

起動に必要なSmileBasicのプログラムとその他必要なファイル付きで具体的な手順が公開されてますね。 でも、まだ配信停止となっていないようなので現行バージョンは対策済みということでしょうか？ ならば安泰な気が。

投票行ってきました。 今回はちゃんと「投票済証」をもらってきました。 今まで「投票済証」が貰えるとは知りませんでした。 それ以前にその存在も orz

プチコン3号の場合、色の物理コードは16bitなので、いくら32bitで頑張っても結局内部的には16bitに丸められ発色は16bitにしかならないので細かい表現はできない仕様だったと。 なので、割りきって色は16bitとしてしまうのは？ そうすれば、16bit用の配列ですむのでかなり節約になるのでは？ ここら辺もスーさんの方が詳しいと思うので素人考えかも知れませんが^^;

内部構造がよくわからないので適当ですが 座標が0～239でX,Yを別にいれているとして「DIM X%[100],Y%[100]」としていたなら、 1byteは0～255だし、変数%は4byteだし、で。 DIM XY%[50] XY%[0]=&HAABBCCDD AA : X%[0] BB : Y%[0] CC : X%[1] DD : Y%[1] と詰め込めそうですが、そんなことは既に対応済ですね、きっと^^;

以前は、問題なくて改造中になら付け加えた部分に問題があるような。 そこで動的にメモリを確保する処理とか、新たに大きな領域を確保する処理があるのでは？という感じも。 スーさんの事なのでそんなことは確認済みかと思いますが… 。 この際動的確保は止めて、全て想定の最大値で先に静的に確保する様に変えて見るのはどうでしょう？ 適当なことしか言っていませんが何かの参考になれば。

既にコメントされているかもしれませんが…。 自分の認識では以下の通り。 まず、配列は領域の場所への参照値(ポインタ？)である。 その領域が何処からも参照されなくなったら自動的に消える。 なので別の変数に代入したりで領域の参照元の変数を増やしていなければ新たにサイズ0で確保した領域をその変数に代入すれば、前に参照していた領域は解放される。 また、関数内で宣言した配列は関数をぬけると領域開放されるので、その配列を確保したしたままにしたい場合は、関数外の変数(グローバル変数、引数で渡された変数)に代入しておけば確保されたままになる。 仕様がちゃんと確認できている訳ではないので間違っていたらすみません。 ダイレクトモードが在るのはクローバル変数の領域が確保されたままになっているから？ よくわかりません^^;

最初の質問に答えられてなかったので改めて。 3DSへの侵入と言うよりシステムの乗っとりのきっかけかな？ 手順は、既にだいたい確立されていて、まずはHBL起動から始まり、FWのダウングレード、そこからのCFW(改造版FW)導入となっている様です。 ここまでできれば後は自由に自作プログラムでもコピーソフトでも動くように。 問題は、これに無料でゲームをしたいだけの輩が群がって来て…。 今回は、このソフトがそのきっかけとなるHBL起動に使えるという話。 本当にそうであれば対策されて前回CFW化のタイミングを逃して次の穴を待っていた新規の不正ユーザに利用される事に。 不正ユーザを増やさない為には、まずきっかけをつぶすという対策がとられ、だいたいは、対象ソフトの流通をとめて、本体のFW改修。 よってこのソフトが配信停止となってしまうのではないかと言うお話。

穴を塞いで再版とされた場合でも、このソフトは自由度が高すぎるので別の穴を探される可能性はあります。 しかし、穴が見つかればよいので別にSmilebasicである必要もなく、ダメなら別のソフトを探します。こだわりはないかと。実際に別のソフトも見つけているようですし。 この手の話は昔からイタチゴッコでずっと続いて来ています。 ちなみにこれ、後で塞がれようが、そんなことはどうでも良く、タイミング良く対策前に入手して実行できれば後は用なしです。 前回タイミングを逃した方々が対策前に入手しようと今慌てている最中かと。 上から見るとリスクを伴うソフトなので本当に停止になった場合、再版を許してくれるのかが気になるところです。

あ、printf() は大丈夫かも^^; 他に何があったかなと検索してみたら、バッフア指定のある物が強化されています。 sprintf_s fprintf_s fopen_s sscanf_s strcpy_s ここら辺を _s なしで使っていると _s 使えと。

多分、だいぶ前からだと思うけど 実は printf() は非推奨になっているようです。 最近はC言語を使う機会がほとんどないのですが、たまにちょっとしたプログラムを作って、printf()等使うとコンパイラさんに 「お前 printf() 使うのかよ。printf_s() 使えよ。」と怒られますw printf() に限らず、 fprintf → fprintf_s sprintf → sprintf_s と、ことごとく _s 付きになっているようで、一々バッフアの最大値を指定する必要があるようです。 最近の人は色々面倒くさくて大変だなぁと。 他にも色々セキュリティ対策はあるのかも知れませんが、追求していないのでよくわかりません^^;

前のは、ちょっとひねくれて、 初期値を「i=0;」に変更して 表示を「++i」に変更した迄は良かったのですが、ループの条件を「i<10」に変更するのを忘れていました^^; そうなんですよ。 C言語の好きなところは、自己責任なところです。

ホントだバグってる^^;

これでも良いかも。 main()の定義はコンパイラ依存する所なので使用するコンパイラに合わせる必要が。 voidで良いとか、intじゃないとだめとか。引数も省略出来るとかできないとか。

ついでに。 画像の左側上から3つめに「I」、右側上から2つめシフトを押しながらで「i」が入力できるのですが。 ここら辺の文字は普段使わないからと言って調子にのってFONTDEFで文字パターンを変えまくっていると大変なことにw ここの「I」と「i」の文字パターンをを変更すると、英字(全角半角とも)の「I」と「i」も同じに変更されてしまいますw どうやら英字と同じ文字パターンが参照されているようです。 でもこれはバグでは？と疑っています。 試しにFONTDEFで変更できる文字を全て何もなしのパターンにしてみてください。 そのときのGRPFを保存して後で確認してみると一度もアクセスされなかったのでそのまま潰されずに残っている文字が数文字見つかります。その中に「I」と「i」らしき文字パターンがあります。 本来ここの「I」「i」はそれらの文字パターンを参照すべきだったのでは？と。

確かに for で良い気も。 でもそこら辺は人の趣味なので。 for は使わない修業中かも。

下画面 下の全角に置き換えられた部分は幅が違うので、みわけられる。

上画面 した側には全角文字が混ざっているが見分けがつかず。

面白ろそうなのでまねてみた^^ &H20～&H7E の範囲の文字コードの文字を全角文字に置き換えて返す関数H2Z$() 与えられた文字列の中で半角→全角変換(H2Z$()関数使用)できる文字は全角変換して返す関数H2Z_STR$()を作成。

前のコメントのダイアログでの " の表示のひかくですが以下のように " の左右に半角空白をいれればあのようにも見せられます。 ["] [ " ] なので実際に動かして試せるようにソースを貼って置きます。