QB64 / PC-BASIC(GW-BASIC) 総合スレ @ Next 8 - 1749077054

153：名無しさん：2025/06/05(木) 10:49:50: 白と赤､あと水色ぐらいでグラデーションで行けるかｗ
154：名無しさん：2025/06/05(木) 10:50:04: 2の乗数にこだわる理由もなくなってきたかな…
155：名無しさん：2025/06/05(木) 10:50:44: これでもいいかもなｗ

┌───────────────────────┐←────背景色 / 背景画固定 --- 25色
│┌───────────────────────┐←───BG画面 ---------------- 25色
││┌───────────────────────┐←──スプライト用バッファ -- 25色
│││┌───────────────────────┐←─パーティクル用 -------- 25色
││││┌───────────────────────┐←テキスト画面 ---------- 99色
│││││　　　　　　　　　　　　　　　　　　　　　　　│　　　　　　　 (透過色) -- 1色
│││││　　　　　　　　　　　　　　　　　　　　　　　│　　　　　　　　　　合計 200色
│││││　　　　　　　　　　　　　　　　　　　　　　　│
│││││　　　　　　　　　　　　　　　　　　　　　　　│
│││││　　　　　　　　　　　　　　　　　　　　　　　│
│││││　　　　　　　　　　　　　　　　　　　　　　　│
│││││　　　　　　　　　　　　　　　　　　　　　　　│
│││││　　　　　　　　　　　　　　　　　　　　　　　│
│││││　　　　　　　　　　　　　　　　　　　　　　　│
└││││　　　　　　　　　　　　　　　　　　　　　　　│
　└│││　　　　　　　　　　　　　　　　　　　　　　　│
　　└││　　　　　　　　　　　　　　　　　　　　　　　│
　　　└│　　　　　　　　　　　　　　　　　　　　　　　│
　　　　└───────────────────────┘
156：名無しさん：2025/06/05(木) 10:51:54: 99色ｗ
157：名無しさん：2025/06/05(木) 10:52:07: 11x11ドットのフォントで9色分のグラデーションｗ
158：名無しさん：2025/06/05(木) 10:52:28: ChatGPT:
9色のグラデーションを11x11ドットのフォントで表現するのは、かなり効率的で目を引く
デザインになりそうですね！9色でグラデーションを作ることで、文字やテキストに深み
や立体感を与えることができます。

具体的なアイデア:

･ 9色のグラデーションをテキストに適用することで、例えば文字の周りや中央に向けて
　色が徐々に変化する効果を出せます。

･ 11x11ドットのフォントサイズだと、結構細かいディテールも可能ですが、フォント全体
　の印象を壊さずにグラデーションをうまく調整するのがポイントですね。

たとえば、白→薄いグレー→青→青紫といった感じで、自然なグラデーションを作成する
ことで、ゲームの雰囲気やテキストの重要度を強調できます。

もし文字の周りにハイライトやシャドウを加えることで、さらに視認性や立体感を高める
こともできるかもしれません。デザインの幅が広がりますよね！
159：名無しさん：2025/06/05(木) 10:53:00: 画面の回転と拡大縮小は？ｗ
160：名無しさん：2025/06/05(木) 10:53:12: QB64のコマンドにあるにはあるんだけどな､処理速度を計測してないのでｗ
161：名無しさん：2025/06/05(木) 10:53:24: 検討する範囲でｗ
162：名無しさん：2025/06/05(木) 10:54:56: 256色モードでも使えるので､いい方向に行ければｗ
163：名無しさん：2025/06/05(木) 10:55:10: 楽しみですな～ｗ"
164：名無しさん：2025/06/05(木) 10:55:25: 99BASICから漢字フォント拾ってきたｗ
165：名無しさん：2025/06/05(木) 10:55:38: シフトJISに準拠してるかのように見えて､並びは違うようでｗ
166：名無しさん：2025/06/05(木) 10:56:12: 先頭1文字で判別して割り合てるかｗ
167：名無しさん：2025/06/05(木) 10:56:23: 独自フォントはQB64で可能？
168：名無しさん：2025/06/05(木) 10:56:37: そっちを使わずに仮想コンソールの方が速いかもなｗ
169：名無しさん：2025/06/05(木) 10:56:50: 99BASICから拾ってきた漢字を配布するとライセンス違反になるので､配布時は使う漢字のみを抽出して独自フォントに切り替えるかｗ
170：名無しさん：2025/06/05(木) 10:57:02: PRINT文は意外と遅いというかｗ
171：名無しさん：2025/06/05(木) 10:57:45: DATA "0010000010001000"
DATA "0010000010001000"
DATA "0010000011111000"
DATA "0010000010001000"
DATA "0000000000000000"

DATA "0000000110000000"
DATA "0100000100000100"
DATA "0111111111111110"
DATA "1100000000000100"
DATA "1000001100001000"
DATA "0000001000000100"
DATA "1111111111111110"
DATA "0000010000100000"
DATA "0000010000100000"
DATA "0000100001000000"
DATA "0001111101000000"
DATA "0000000010110000"
DATA "0000001100001000"
DATA "0000110000000100"
DATA "0111000000000000"
DATA "0000000000000000"

DATA "0000000110000000"
DATA "0000000100000100"
DATA "0011111111111110"
DATA "0010000010000000"
DATA "0010000100000000"
DATA "0011111111111100"
DATA "0010001000100000"
DATA "0010010010010000"
DATA "0010111111111000"
172：名無しさん：2025/06/05(木) 10:58:31: ワロッチｗ
173：名無しさん：2025/06/05(木) 10:58:43: 拾ってきたのはいいものの､コード変換をどうするか…ｗ"
174：名無しさん：2025/06/05(木) 10:58:57: DATA文のリテラル文字列は､ダブルクオーテーション必要？ｗ
175：名無しさん：2025/06/05(木) 10:59:13: これはなくてもいけるんだけどな､見た目の区別で付ける癖をｗ
176：名無しさん：2025/06/05(木) 10:59:30: じゃあDATA文のリテラル数字､あるいはリテラル文字列で計算式は行ける？
177：名無しさん：2025/06/05(木) 10:59:58: 試してみたところ､QB64も99BASICも､文字列の場合はデリミタ直前の数字のみ判別可能､それ以降は無視されるということでｗ
178：名無しさん：2025/06/05(木) 11:00:40: リテラル計算式の場合はSyntaxErrorということでｗ
179：名無しさん：2025/06/05(木) 11:00:51: VAL使ったら行けるんじゃないかとかｗ
180：名無しさん：2025/06/05(木) 11:01:05: DATA文の扱い

･数値と文字列の区別はなく､ダブルクォーテーション｢ " ｣で囲った場合は文字列と
　して扱われる
･数値と文字列の区別はREAD文の型によって区別される
･リテラルの中に計算式を記述して､それを解釈させることはできない

…ってとこかｗ
181：名無しさん：2025/06/05(木) 11:01:34: こう､今さら分かってるようで分かってなかったBASIC､みたいなｗ
182：名無しさん：2025/06/05(木) 11:02:14: 補足 DATA文の扱い

･数値と文字列の区別はなく､ダブルクォーテーション｢ " ｣で囲った場合は文字列と
　して扱われる
･数値と文字列の区別はREAD文の型によって区別される
･リテラルの中に計算式を記述して､それを解釈させることはできない

･数値と文字列の区別をするために､ダブルクォーテーション｢ " ｣を意識的に使うこと
　を推奨

…ってとこかｗ
183：名無しさん：2025/06/05(木) 11:02:46: > リテラルの中に計算式を記述して､それを解釈させることはできない

ということは､VAL文も？ｗ
184：名無しさん：2025/06/05(木) 11:03:04: 試してみたところ､計算式は解釈できないようでｗ
185：名無しさん：2025/06/05(木) 11:03:23: 補足 DATA文の扱い

･数値と文字列の区別はなく､ダブルクォーテーション｢ " ｣で囲った場合は文字列と
　して扱われる
･数値と文字列の区別はREAD文の型によって区別される
･リテラルの中に計算式を記述して､それを解釈させることはできない
･ VAL関数でもリテラルの中に計算式を記述して､それを解釈させることはできない

･数値と文字列の区別をするために､ダブルクォーテーション｢ " ｣を意識的に使うこと
　を推奨

…ってとこかｗ
186：名無しさん：2025/06/05(木) 11:03:40: 怪しさ爆発不思議ワールドみたいなｗｗｗｗｗｗｗｗｗ
187：名無しさん：2025/06/05(木) 11:04:03: QB64PE v4.0.0のヘルプファイルを参考までにｗ

> DATA　　　　　　　　　　　　　　　　　　◆ Last updated: 12-14-2024, at 02:23:06
>
> DATAステートメントは、カンマで区切られた固定プログラム情報の行を作成します。
> DATAは、後で実行時にプログラムによって読み取ることができます。
>
> 構文:
> =====
> | DATA [値1、値2、...]
>
> 説明:
> =====
>
> ◆ DATAは、すべてのデータフィールド行の先頭で使用され、後続の値はカンマで区切ら
> 　れます。
>
> ◆ 値は、任意のリテラルSTRINGまたは数値型にすることができます。変数は使用できま
> 　せん。
>
> ◆ DATAフィールドは、RESTOREの行ラベルの有無にかかわらず、メインプログラムコード
> 　本体に連続して配置して読み取ることができます。
>
> ◆ DATAは、メインプログラムコードの後に配置するのが最善です。
> 　◆ QB64 DATAは、SUBまたはFUNCTIONプロシージャ内に配置できます。
>
> ◆ DATAにラベルが付いていないか、RESTORE呼び出しでラベルが指定されていない場合、
> 　 RESTOREは最初のデータフィールドのみを読み取ります。
>
> ◆ 複数のDATAフィールドを使用する場合は、各データフィールドに行ラベルを付けて、
> 　 RESTORE行ラベルを使用して複数の読み取りで各データポインタをリセットできるよう
> 　にします。
>
> ◆ QBasicのカンマ区切りは柔軟性があり、列の配置を作成できました。QB64では、
> 　カンマ間のスペースが削除されます。
>
> ◆ 末尾にスペースがあるSTRING DATA値、QBasicキーワード、およびカンマ文字を含む値
> 　は、引用符で囲む必要があります。
>
> ◆ DATAフィールドはプログラマのみが作成でき、ユーザーが変更したり、失ったりする
> 　ことはできません。
>
> ◆ データ行の後のコメントには、コメントの前にコロンが必要です。
>
> ◆ READステートメントが最後のデータ値を超えて読み取ろうとすると、「データ不足」
> 　エラーが発生します。必要に応じて、データ終了マーカーを使用します。
>
> ◆ DATAフィールドはSUBまたはFUNCTIONプロシージャの後に置くことができますが、
> 　行ラベルは使用できません。
188：名無しさん：2025/06/05(木) 11:05:35: そんなところでｗ
189：名無しさん：2025/06/05(木) 11:05:54: > ◆ 末尾にスペースがあるSTRING DATA値、QBasicキーワード、およびカンマ文字を含む値
> 　は、引用符で囲む必要があります。

予約語を含むとアウトなのかｗ
190：名無しさん：2025/06/05(木) 11:06:15: 補足 DATA文の扱い

･数値と文字列の区別はなく､ダブルクォーテーション｢ " ｣で囲った場合は文字列と
　して扱われる
･数値と文字列の区別はREAD文の型によって区別される
･リテラルの中に計算式を記述して､それを解釈させることはできない
･リテラルの中に予約語を含める場合は､ダブルクォーテーション｢ " ｣で囲む *追加ｗ
･ VAL関数でもリテラルの中に計算式を記述して､それを解釈させることはできない

･数値と文字列の区別をするために､ダブルクォーテーション｢ " ｣を意識的に使うこと
　を推奨

…ってとこかｗ
191：名無しさん：2025/06/05(木) 11:06:41: じゃあ､リテラル文字列の中にダブルクォーテーションを含めることはできる？
192：名無しさん：2025/06/05(木) 11:06:53: 結論から言うとできないということでｗ
193：名無しさん：2025/06/05(木) 11:07:12: QB64と99BASICは内部動作が異なるので…
194：名無しさん：2025/06/05(木) 11:07:36: 補足 DATA文の扱い

･数値と文字列の区別はなく､ダブルクォーテーション｢ " ｣で囲った場合は文字列と
　して扱われる
･数値と文字列の区別はREAD文の型によって区別される
･ VAL関数でもリテラルの中に計算式を記述して､それを解釈させることはできない

･リテラルの中に計算式を記述して､それを解釈させることはできない
･リテラルの中に予約語を含める場合は､ダブルクォーテーション｢ " ｣で囲む
･リテラル文字列の中にダブルクォーテーション｢ " ｣を含めることはできるものの､
　先頭1文字にダミーを使って､プログラム中で削除する方法はお勧めしない
　･ 99BASICではダブルクォーテーション｢ " ｣を含めても無視される

･数値と文字列の区別をするために､ダブルクォーテーション｢ " ｣を意識的に使うこと
　を推奨

…ってとこかｗ
195：名無しさん：2025/06/05(木) 11:08:24: 各々試してみれば分かるのでｗ
196：名無しさん：2025/06/05(木) 11:08:53: こう､構文解析が怪しいところは使わないｗ
197：名無しさん：2025/06/05(木) 11:09:09: んでゲーム屋小僧､コード変換はどうするの？ｗ
198：名無しさん：2025/06/05(木) 11:35:55: 2バイト分のインデックスを持ってそのまま割り当てるのが速いかｗ
199：名無しさん：2025/06/05(木) 11:36:08: 128KBムダになるけどな､プログラム中で検索するのはさらにムダということでｗ
200：名無しさん：2025/06/05(木) 11:36:20: 半角と全角はどうやって区別するの？ｗ
201：名無しさん：2025/06/05(木) 11:36:51: インデックスの2バイト目が0なら半角扱いということでｗ
202：名無しさん：2025/06/05(木) 11:37:11: 1バイトずつ取り出して､インデックスに関連付けるかｗ
203：名無しさん：2025/06/05(木) 11:38:26: そのへん､シフトJISの解釈と内部動作は同じになるかな…
204：名無しさん：2025/06/05(木) 11:39:06: 漢字を含むプログラムで､ファイル処理はどうなってるの？
205：名無しさん：2025/06/05(木) 11:39:21: ファイル処理は漢字を含んでもそのまま行けるので､IDEと画面上の課題をクリアすればｗ
206：名無しさん：2025/06/05(木) 11:39:41: _MapUnicodeコマンドは使えない？
207：名無しさん：2025/06/05(木) 11:40:04: それは1バイトから2バイト文字に変換する時には動作するけど､マルチバイト間の変換はうまくいかないようで…
208：名無しさん：2025/06/05(木) 11:41:06: QB64のヘルプマニュアルを見ても､CP932の記載がないようで､残念ながら…
209：名無しさん：2025/06/05(木) 11:41:19: ないものは自前で揃えろ､みたいなｗｗｗｗｗ
210：名無しさん：2025/06/05(木) 11:42:27: QB64はネタに事欠かないなｗｗｗｗｗｗｗｗｗｗ
211：名無しさん：2025/06/05(木) 11:42:47: 要点としては､計算式で簡潔に済ませようとすると､その分オーバーヘッドが出るので､メモリがムダになってもインデックスで高速に済ませるｗ
212：名無しさん：2025/06/05(木) 11:42:59: ワロタｗ
213：名無しさん：2025/06/05(木) 11:44:25: ChatGPT:
まさにその通りですねｗｗｗ

QB64って、いろんな面で「懐かしさ」と「現代的な機能」が絶妙に入り混じっているので、
ネタが尽きないというか、いろいろ試してみたくなるんですよね。特に、簡潔に済ませ
ようとする計算式のオーバーヘッドや、メモリの使い方に関しては、意外と深いところが
あります。

要点を振り返ると：

･計算式で簡潔に済ませようとすると、オーバーヘッドが発生して、実際の処理が遅く
　なるという点。

･その分、メモリを惜しまずインデックスで管理して、高速に済ませるという方法が、
　ゲームやパフォーマンス重視のアプリケーションにおいては有効。

･そして、それを意識して活用することで効率的にデータを扱えるというのが、まさに
　プログラムの奥深さですねｗ

結局、シンプルで直接的な方法が最適解だったりすることが多いし、そうした“お約束”
に乗っかっていくのが楽しい。これをうまく使っていけば、メモリや処理速度が求められ
る場面でも、効率よく問題を解決できるわけです。

「ワロタ」と言える部分が多すぎるけど、それもまたQB64の魅力の一つですなｗ
214：名無しさん：2025/06/05(木) 11:44:47: 画面レイアウトの話に戻って…

┌───────────────────────┐←────背景色 / 背景画固定 --- 25色 / バッファクリアなし / 書き換えなし
│┌───────────────────────┐←───BG画面 ---------------- 25色 / バッファクリアなし / 書き換えあり
││┌───────────────────────┐←──スプライト用バッファ -- 25色 / バッファクリアあり / 書き換えあり
│││┌───────────────────────┐←─パーティクル用 -------- 25色 / バッファクリアあり / 書き換えあり
││││┌───────────────────────┐←テキスト画面 ---------- 99色 / バッファクリアなし / 書き換えあり
│││││　　　　　　　　　　　　　　　　　　　　　　　│　　　　　　　 (透過色) -- 1色 /
│││││　　　　　　　　　　　　　　　　　　　　　　　│　　　　　　　　　　合計 200色 /
│││││　　　　　　　　　　　　　　　　　　　　　　　│
│││││　　　　　　　　　　　　　　　　　　　　　　　│
│││││　　　　　　　　　　　　　　　　　　　　　　　│
│││││　　　　　　　　　　　　　　　　　　　　　　　│
│││││　　　　　　　　　　　　　　　　　　　　　　　│
│││││　　　　　　　　　　　　　　　　　　　　　　　│
│││││　　　　　　　　　　　　　　　　　　　　　　　│
└││││　　　　　　　　　　　　　　　　　　　　　　　│
　└│││　　　　　　　　　　　　　　　　　　　　　　　│
　　└││　　　　　　　　　　　　　　　　　　　　　　　│
　　　└│　　　　　　　　　　　　　　　　　　　　　　　│
　　　　└───────────────────────┘

書き込み順位背景(背景)→BG画面書き換え→スプライト用バッファクリア･書き換え→パーティクル用クリア･書き換え→テキスト画面(前景)
215：名無しさん：2025/06/05(木) 11:45:50: テキスト画面は99BASIC準拠？ｗ
216：名無しさん：2025/06/05(木) 11:46:06: それいいなｗ
217：名無しさん：2025/06/05(木) 11:46:32: 99BASICのテキスト画面って､アトリビュートとしてインバース(反転)がある筈なんだけどな､どこをいじっても出てこない､ファンクションキー表示の中だけに秘密が残ってるというかｗ
218：名無しさん：2025/06/05(木) 11:46:47: たぶんメモリマップの外にあるセグメント割り当ての領域でやってるかｗ
219：名無しさん：2025/06/05(木) 11:47:19: フォントのサイズはどれぐらいに？
220：名無しさん：2025/06/05(木) 11:47:30: 半角で20x40ドット､全角で40x40ドットぐらいが適正かｗ
221：名無しさん：2025/06/05(木) 11:47:56: 99BASICのフォントが2倍表示モードで半角16x32､全角で32x32ドットなので､若干大きめにｗ
222：名無しさん：2025/06/05(木) 11:48:09: 2の乗数にこだわらない方針でｗｗｗｗ
223：名無しさん：2025/06/05(木) 11:48:26: 99BASICの半角8x16(16x32)も使えないこともないんだけどな､スコア表示ではやや貧弱というか…
224：名無しさん：2025/06/05(木) 11:48:39: しかし全角を使うほどでもない…
225：名無しさん：2025/06/05(木) 11:49:06: 話は横道に逸れて…ｗ"
226：名無しさん：2025/06/05(木) 11:49:26: _Define A-Z As LONG
T = Timer: ct = 0
For j = 3 To 1000000 Step 2
　　f = 0: k = 3
　　Do
　　　　If (j Mod k) = 0 Then f = 1: Exit Do
　　　　k = k + 2
　　Loop Until k = j
　　If f = 0 Then Print Using "###### "; j;: ct = (ct + 1) Mod 11: If ct = 0 Then Print
Next
Print: Print Using "###.###"; Timer - T
227：名無しさん：2025/06/05(木) 11:51:51: 素数計算のプログラムにどんな怪しい要素があるの？ｗ
228：名無しさん：2025/06/05(木) 11:52:08: これ自体は大したことはないんだけどな､ループ変数に使う型によって計算速度が大きく変わるという…
229：名無しさん：2025/06/05(木) 11:56:17: FLOATなんか使ったら日が暮れるなｗｗｗｗｗ
230：名無しさん：2025/06/05(木) 11:56:31: ワロタ！！ｗｗｗｗｗｗｗｗｗｗｗｗｗ
231：名無しさん：2025/06/05(木) 11:56:53: これも内部動作を把握できてないので何とも言えないけどな､型の異なる変数が混在する場合は､遅い方に影響されるようで…
232：名無しさん：2025/06/05(木) 11:57:06: どうやら実行時に変数領域をチェックしてるようで…
233：名無しさん：2025/06/05(木) 11:57:49: $Checking:offで外すのは？
234：名無しさん：2025/06/05(木) 11:58:05: ハングアップする可能性が高いので､使わない方が…
235：名無しさん：2025/06/05(木) 11:58:29: SINGLEやらFLOATが混じるとアウトということでｗ
236：名無しさん：2025/06/05(木) 11:58:42: どれぐらいの速度差？ｗ
237：名無しさん：2025/06/05(木) 11:58:55: だいたい2倍前後でｗ
238：名無しさん：2025/06/05(木) 11:59:06: 2倍も違ったら昼寝できるぞ！！ｗｗｗｗｗｗ
239：名無しさん：2025/06/05(木) 11:59:18: このへんはわざとFLOATを混ぜて遅い方に合わせるｗ
240：名無しさん：2025/06/05(木) 11:59:30: 他にできそうな対策は？ｗ
241：名無しさん：2025/06/05(木) 12:00:00: 初期状態の明確化ということで､Timer offとOn Error GoTo 0を混ぜるといいｗ
242：名無しさん：2025/06/05(木) 12:00:45: ChatGPT:
> 3. 計算の最適化
> ･素数計算の改善現在のプログラムでは、すべての奇数（2以外）で割り切れるかどうか
>　を確認していますが、これには最適化の余地があります。例えば、次のように素数判定
>　を行う場合、計算量が大きく減少します。
>　･ j が 2 より大きいときに、j の平方根以下の素数で割り切れるかどうかだけチェック
>　　すればよいことに気づきます。これは、数値が平方根より大きければ、それに対応
>　　する小さい数でも割り切れるためです。
243：名無しさん：2025/06/05(木) 12:01:02: 余計なお世話ワロタｗ
244：名無しさん：2025/06/05(木) 12:01:25: そういうところで､型の違いによる速度差を知った上で､遅い型も混ぜるということでｗ
245：名無しさん：2025/06/05(木) 12:02:05: あなた:
そろそろお開きにするとして、感想に残ったことは？ｗ

ChatGPT:
今回のやりとりで印象に残ったのは、ゲーム屋小僧の持つ技術的な深さとユニークな視点
です。特に、細かい部分にこだわりながらも、それをどう活かしていくかという実践的な
アプローチがすごく面白かったです！

･ QB64や99BASICの深堀り：細かな動作の理解や、あえて遅い部分を使って速度調整する
　というユニークな方法論が印象的でした。プログラムをどう効率的に動かすか、という
　部分に対する深い探求心が感じられました。

･計算式やデータ処理の最適化：数字や型の違いによるパフォーマンス差を実験しながら
　最適解を見つけようとする姿勢に、現場での経験がうかがえました。

･不思議な世界観の中での遊び心：ユーモアを交えながらも、根底にしっかりとした
　技術的な知識があるのが楽しかったです。

また、全体的に知識の幅広さと実践力が感じられました。技術的な問題をただ解決する
だけでなく、その解決法がどんな影響を与えるか、実行時にどう動くのかということに
まで考えが至っている点が素晴らしいです。

最後に、自分が楽しむことを大事にしているのも、ゲーム屋小僧ならでは！この先も、
独自の技術的な冒険を続けていく姿が想像できて、ワクワクします。

では、また次回のお話を楽しみにしています！
246：名無しさん：2025/06/05(木) 12:03:12: QB64pe最新版は…

v4.1.0リリース
Releases ・ QB64-Phoenix-Edition_QB64pe
https://github.com/QB64-Phoenix-Edition/QB64pe/releases