したらばTOP ■掲示板に戻る■ 全部 1-100 最新50 | |

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

1名無しさん:2025/06/05(木) 07:44:14
QB64
https://qb64.com/

QB64は、QBasic / QuickBASIC 4.5互換性を保持し、Windows、Linux、およびmacOS用の
ネイティブバイナリをコンパイルする最新の拡張BASICプログラミング言語です。
ーーーー

PC-BASIC Linux/Mac/Windows版
https://github.com/robhagemans/pcbasic/releases/tag/v2.0.7

2名無しさん:2025/06/05(木) 09:23:25
_CAPSLOCKワロタw

3名無しさん:2025/06/05(木) 09:24:20
WindowsのみでMacとLinuxは対応してないらしいw

> See also:
> =========
> ◆ _CAPSLOCK (function), _NUMLOCK (function), _SCROLLLOCK (function)
> ◆ _NUMLOCK (statement), _SCROLLLOCK (statement)

4名無しさん:2025/06/05(木) 09:24:36
wwwwwwww

5名無しさん:2025/06/05(木) 09:25:12
高速化の話に移るけど、QB64のキーポイントは?

6名無しさん:2025/06/05(木) 09:25:26
必要がなければ256色モードを使うということでw

7名無しさん:2025/06/05(木) 09:25:57
これは単純に、32bitカラー、ARGBを使うと、書き込み量が4倍に増えるということでw

8名無しさん:2025/06/05(木) 09:26:21
256色モードならパレットも使えるしw

9名無しさん:2025/06/05(木) 09:26:37
99BASICが速いのも256色モード限定の話でw

10名無しさん:2025/06/05(木) 09:26:50
あ、そういうことだったのかw

11名無しさん:2025/06/05(木) 09:27:05
16色モードはあるの?w

12名無しさん:2025/06/05(木) 09:27:18
_NEWSCREENで指定できるスクリーンバッファは、原則的に256色か32bit色かでw

13名無しさん:2025/06/05(木) 09:27:36
あるにはあるんだけどな、旧QBASICのSCREEN12以前の構造を知っていればw

14名無しさん:2025/06/05(木) 09:27:48
さすがに16色では…w"

15名無しさん:2025/06/05(木) 09:28:15
テキスト用とBG用、スプライト用に合計32色ぐらい使って、256色全部を使うことはないけどなw

16名無しさん:2025/06/05(木) 09:28:29
ゲーム中にパレットが使えるというのは、応用範囲も広がる訳でw

17名無しさん:2025/06/05(木) 09:28:44
いい話だな〜w"

18名無しさん:2025/06/05(木) 09:28:58
大昔のマイコン世代が考えてた、こういうことができるといいな〜、ってのをそのままw

19名無しさん:2025/06/05(木) 09:30:33
QB64専用の_PUTIMAGEはどれぐらいの速度比?

20名無しさん:2025/06/05(木) 09:30:44
PUT@の3倍前後かな、あとで試してみるかw

21名無しさん:2025/06/05(木) 09:30:59
それで終わりではなかった、QB64が化ける時が来たかwwww

22名無しさん:2025/06/05(木) 09:31:12
99BASICを軽く超えてしまったかw

23名無しさん:2025/06/05(木) 09:31:26
QB64は割り込みもあるし2Dも速いし、LinuxMintのメイン開発でも行けるかもしれないなwwwwwwwwwwwwwwww

24名無しさん:2025/06/05(木) 09:32:47
スプライト扱いの場合は割り込み使った方が管理が便利なんだけどな、グラフィック扱いなら割り込みを使わない方が自由度が高いというかw

25名無しさん:2025/06/05(木) 09:33:00
もう少し早く_PUTIMAGEを試してみるべきだったなwwww

26名無しさん:2025/06/05(木) 09:33:20
どうやらこっちがopenGL本場の機能を使ってるようで…

27名無しさん:2025/06/05(木) 09:33:31
ゲーム屋小僧、今後はどうする?w

28名無しさん:2025/06/05(木) 09:33:44
脱Windows行けるし、選択の自由は保障されるかw

29名無しさん:2025/06/05(木) 09:34:57
これで脱Windowsも行けるし、最速QB64で生き続けられるかwwwwww

30名無しさん:2025/06/05(木) 09:35:25
PC界は何が起こるか分からないなwwwwwww

31名無しさん:2025/06/05(木) 09:35:43
QB64で画面同期どうやるの?

32名無しさん:2025/06/05(木) 09:35:56
たぶんタイマー割り込みを使ってると思うけどな、VSYNCに相当するものもあるし、I/Oポート03DAHを読んで直接待つこともできるしなwwwwwww

33名無しさん:2025/06/05(木) 09:36:09
これとタイマー割り込みON-GOSUBを組み合わせることも可能、好きなようにwwwwww

34名無しさん:2025/06/05(木) 09:36:22
もう笑うしかないなwwwwwwww

35名無しさん:2025/06/05(木) 09:36:37
あと99BASICと同じようにopenGLの更新を止めるとさらに速くなるというwwwwwwwww

36名無しさん:2025/06/05(木) 09:41:02
QB64は 「 99BASIC以上のもの 」 が得られる?

37名無しさん:2025/06/05(木) 09:41:17
たぶん期待していいw

38名無しさん:2025/06/05(木) 09:41:30
秒間60コマの滑らかな映像は可能?w

39名無しさん:2025/06/05(木) 09:41:42
当然のことでw

40名無しさん:2025/06/05(木) 09:42:05
A.I.がどうこうとか物理演算がどうこうとかの人は、他をどうぞw

41名無しさん:2025/06/05(木) 09:42:20
内部構造が99BASICに似た部分があるので、99BASICを使ってたユーザーが移りやすいかもしれないなw

42名無しさん:2025/06/05(木) 09:42:47
例えば40年前に現役だったレトロ世代が取り戻したい!とか考えて行けるものなの?w

43名無しさん:2025/06/05(木) 09:43:00
その世代が生きてるかどうか知らないけどなw

44名無しさん:2025/06/05(木) 09:43:15
wwwwwwwwwwwwwwwwwwww

45名無しさん:2025/06/05(木) 09:43:27
むしろメーカー側の芸術性の押し付けになりつつある今の世代にお勧めしたいところでw

46名無しさん:2025/06/05(木) 09:44:39
レトロ世代って、実際のゲームでも8x8とか16x16にこだわるよなw

47名無しさん:2025/06/05(木) 09:44:55
17x80でも100x50でもいいのにw

48名無しさん:2025/06/05(木) 09:45:07
そして専用グラフィックエディターの中に箱詰めするというw

49名無しさん:2025/06/05(木) 09:45:20
DATA文で充分w

50名無しさん:2025/06/05(木) 09:45:37
過去の既成概念って障壁になる?w

51名無しさん:2025/06/05(木) 09:46:00
一長一短あるんで、照らし合わせて必要なものはw

52名無しさん:2025/06/05(木) 09:46:14
こう、分業化された職業プログラマーが陥りやすいというかw

53名無しさん:2025/06/05(木) 10:01:05
今日のネタは…w"

54名無しさん:2025/06/05(木) 10:01:36
参考 QB64内蔵GPU環境の動作状況 - 1/60秒あたりの描画回数の比較 2025.1.25.土.17:37 更新*

 評価点 *:3点 +:2点 -:1点
┌─────┬────┬───────────────────────────────────────────┐
|  項目  | サイズ |                     QB64                     |
├─────┼────┼───────────────────────────────────────────┤
|  API  |--------|                    openGL                    |
├─────┼────┼──────────┬──────────┬──────────┬──────────┤
|  機種  |--------|  デスクトップPC  |  デスクトップPC  |  M4 Mac mini   | (M1 Mac mini相当) |
|  OS  |    |   Windows11   |  Windows11 Pro  |MacOS省電力モードOFF|MacOS省電力モードON |
├─────┼────┼──────────┼──────────┼──────────┼──────────┤
|  CPU  |--------| AMD Ryzen 5 5600G | Intel Pentium G5620| Apple M4 10 Core | Apple M4 10 Core |
|     |    |   2021年8月   |   2019年11月   |   2024年11月   |   2020年11月   |
├─────┼────┼──────────┴──────────┴──────────┴──────────┤
|  GPU  |--------|                    内蔵GPU                    |
├─────┼────┼──────────┬──────────┬──────────┬──────────┤
|  PSET  |1 ドット| 28,444 *|||||||||| | 18,233 +||||||   | 8,333 -|||    | 4,447 ||     |
├─────┼────┼──────────┼──────────┼──────────┼──────────┤
| PAINT  | 全画面 |  4.7 +|||||||  |  3.9 -||||||   |  6.5 *|||||||||| |  3.2 |||||   |
├─────┼────┼──────────┼──────────┼──────────┼──────────┤
|     |  8x 8| 26,016 *|||||||||| | 15,724 +|||||||||| | 7,944 -|||||||||| | 4,065 |||||||||| |
|     | 16x 16| 23,970 *||||||||| | 14,678 +||||||||| | 7,799 -||||||||| | 4,022 ||||||||| |
|  LINE  | 32x 32| 20,711 *||||||||  | 12,648 +||||||||  | 7,228 -||||||||| | 3,591 ||||||||  |
|     | 64x 64| 16,264 *||||||   | 10,110 +||||||   | 6,863 -||||||||  | 3,386 ||||||||  |
|     | 128x128| 11,228 *||||    | 7,223 +|||||   | 6,340 -||||||||  | 2,954 |||||||  |
|     | 256x256| 7,166 *|||    | 4,597 -|||    | 5,033 +||||||   | 2,500 ||||||   |
├─────┼────┼──────────┼──────────┼──────────┼──────────┤
|     |  8x 8| 18,962 *|||||||||| | 12,121 +|||||||||| | 6,514 -|||||||||| | 3,148 |||||||||| |
|     | 16x 16| 15,421 *||||||||  | 9,785 +||||||||  | 6,448 -||||||||| | 3,090 ||||||||| |
| LINE B | 32x 32| 11,237 *||||||   | 7,339 +||||||   | 5,798 -||||||||| | 2,750 ||||||||  |
|     | 64x 64| 7,219 *||||    | 4,692 +||||    | 4,612 -|||||||  | 2,418 |||||||  |
|     | 128x128| 4,211 *||     | 2,808 -|||    | 3,542 +|||||   | 1,788 ||||||   |
|     | 256x256| 2,236 +||     | 1,552 -||     | 2,334 *||||    | 1,182 ||||    |
├─────┼────┼──────────┼──────────┼──────────┼──────────┤
|     |  8x 8| 27,586 *|||||||||| | 16,864 +|||||||||| | 7,728 -|||||||||| | 4,170 |||||||||| |
|     | 16x 16| 26,722 *||||||||| | 15,900 +||||||||| | 7,611 -||||||||| | 3,757 ||||||||| |
| LINE BF | 32x 32| 25,296 *||||||||| | 14,463 +||||||||  | 7,598 -||||||||| | 3,612 ||||||||  |
|     | 64x 64| 20,221 *|||||||  | 11,657 +|||||||  | 7,193 -||||||||| | 3,541 ||||||||  |
|     | 128x128| 15,421 *||||||   | 8,415 +|||||   | 6,276 -||||||||  | 3,088 |||||||  |
|     | 256x256| 9,580 *||||    | 4,398 -|||    | 4,436 +||||||   | 2,246 |||||   |
├─────┼────┼──────────┼──────────┼──────────┼──────────┤
|     |  8x 8|293,577 *|||||||||| |189,629 +|||||||||| |151,479 -|||||||||| | 72,727 |||||||||| |
|     | 16x 16|197,836 *|||||||  |144,632 +|||||||  |121,040 -||||||||  | 57,853 ||||||||  |
|_PUTIMAGE | 32x 32|132,094 *|||||   | 84,321 +|||||   | 75,851 -|||||   | 37,925 |||||   |
|     | 64x 64| 58,367 *||     | 35,704 -||     | 43,243 +|||    | 21,658 |||    |
|     | 128x128| 28,070 *|     | 13,193 -|     | 21,658 +||     | 10,829 ||     |
|     | 256X256| 9,785 *|     | 4,527 -|     | 7,785 +|     | 3,745 |     |
├─────┼────┼──────────┼──────────┼──────────┼──────────┤
|評価点合計|--------| *:24 +:2 -:0 計76点|*:0 +:18 -:8 計44点| *:2 +:6 -:18 計36点| *:0 +:0 -:0 計0点 |
└─────┴────┴──────────┴──────────┴──────────┴──────────┘
*動作解像度はいずれも640x480ドット、256色モード

55名無しさん:2025/06/05(木) 10:03:10
6年前のCPUがM4 Mac miniを下克上したwwwwwwwwwwwwwww

56名無しさん:2025/06/05(木) 10:03:45
5600Gは内蔵GPUとは思えない速さだなwwwwwwww

57名無しさん:2025/06/05(木) 10:04:01
M1 Mac miniはお役御免かw

58名無しさん:2025/06/05(木) 10:04:23
投げ売り特価で買った5600Gが4060無印に迫るのかwwwwwwwwwwwwwwwwwwwwwwwwwww

59名無しさん:2025/06/05(木) 10:04:49
参考 QB64動作環境の比較 - 椅子取りゲーム(^。^) 2025.1.25.土.18:38 更新*

 評価点 *:4点 +:3点 =:2点 -:1点
┌─────┬────┬──────────────────────────────────────────────────────┐
|  項目  | サイズ |                          QB64                          |
├─────┼────┼──────────────────────────────────────────────────────┤
|  API  |--------|                          openGL                          |
├─────┼────┼──────────┬──────────┬──────────┬──────────┬──────────┤
|  機種  |--------|  デスクトップPC  |  デスクトップPC  |  デスクトップPC  |  デスクトップPC  |  M4 Mac mini   |
|  OS  |    |   LinuxMint   |   Windows10   |   Windows11   |  Windows11 Pro  |MacOS省電力モードOFF|
├─────┼────┼──────────┼──────────┼──────────┼──────────┼──────────┤
|  CPU  |--------|   14500無印   |    13100F    | AMD Ryzen 5 5600G | Intel Pentium G5620| Apple M4 10 Core |
|     |    |   2024年1月   |   2023年1月   |   2021年8月   |   2019年11月   |   2024年11月   |
├─────┼────┼──────────┼──────────┼──────────┴──────────┴──────────┤
|  GPU  |--------|   4060無印   |   3060 12GB   |               内蔵GPU              |
|     |    |   2023年5月   |   2021年2月   |                                |
├─────┼────┼──────────┼──────────┼──────────┬──────────┬──────────┤
|  PSET  |1 ドット| 34,078 *|||||||||| | 28,669 +||||||||  | 28,444 =||||||||  | 18,233 -|||||   | 8,333 |||    |
├─────┼────┼──────────┼──────────┼──────────┼──────────┼──────────┤
| PAINT  | 全画面 |  7.1 *|||||||||| |  6.2 =||||||||  |  4.7 -||||||   |  3.9 |||||   |  6.5 +||||||||| |
├─────┼────┼──────────┼──────────┼──────────┼──────────┼──────────┤
|     |  8x 8| 30,346 *|||||||||| | 26,143 +|||||||||| | 26,016 =|||||||||| | 15,724 -|||||||||| | 7,944 |||||||||| |
|     | 16x 16| 29,163 *||||||||| | 24,864 +||||||||| | 23,970 =||||||||| | 14,678 -||||||||| | 7,799 ||||||||| |
|  LINE  | 32x 32| 26,834 *||||||||  | 22,634 +||||||||  | 20,711 =||||||||  | 12,648 -||||||||  | 7,228 ||||||||| |
|     | 64x 64| 22,976 *|||||||  | 19,081 +|||||||  | 16,264 =||||||   | 10,110 -||||||   | 6,863 ||||||||  |
|     | 128x128| 17,733 *||||||   | 14,652 +||||||   | 11,228 =||||    | 7,223 -|||||   | 6,340 ||||||||  |
|     | 256x256| 12,465 *||||    | 10,112 +||||    | 7,166 =|||    | 4,597 |||    | 5,033 -||||||   |
├─────┼────┼──────────┼──────────┼──────────┼──────────┼──────────┤
|     |  8x 8| 24,615 *|||||||||| | 21,824 +|||||||||| | 18,962 =|||||||||| | 12,121 -|||||||||| | 6,514 |||||||||| |
|     | 16x 16| 21,192 *||||||||  | 18,382 +||||||||  | 15,421 =||||||||  | 9,785 -||||||||  | 6,448 ||||||||| |
| LINE B | 32x 32| 17,181 *|||||||  | 14,380 +||||||   | 11,237 =||||||   | 7,339 -||||||   | 5,798 ||||||||| |
|     | 64x 64| 11,973 *|||||   | 10,077 +|||||   | 7,219 =||||    | 4,692 -||||    | 4,612 |||||||  |
|     | 128x128| 7,646 *|||    | 6,178 +|||    | 4,211 =||     | 2,808 |||    | 3,542 -|||||   |
|     | 256x256| 4,416 *||     | 3,573 +||     | 2,236 -||     | 1,552 ||     | 2,334 =||||    |
├─────┼────┼──────────┼──────────┼──────────┼──────────┼──────────┤
|     |  8x 8| 31,449 *|||||||||| | 26,834 =|||||||||| | 27,586 +|||||||||| | 16,864 -|||||||||| | 7,728 |||||||||| |
|     | 16x 16| 30,331 *||||||||| | 26,143 =||||||||| | 26,722 +||||||||| | 15,900 -||||||||| | 7,611 ||||||||| |
| LINE BF | 32x 32| 28,444 *||||||||| | 24,270 =||||||||| | 25,296 +||||||||| | 14,463 -||||||||  | 7,598 ||||||||| |
|     | 64x 64| 24,615 *||||||||  | 19,571 =|||||||  | 20,221 +|||||||  | 11,657 -|||||||  | 7,193 ||||||||| |
|     | 128x128| 15,686 *|||||   | 14,241 =|||||   | 15,421 +||||||   | 8,415 -|||||   | 6,276 ||||||||  |
|     | 256x256| 7,582 +|||    | 6,973 =|||    | 9,580 *||||    | 4,398 |||    | 4,436 -||||||   |
├─────┼────┼──────────┼──────────┼──────────┼──────────┼──────────┤
|     |  8x 8|338,624 +|||||||||| |388,585 *|||||||||| |293,577 =|||||||||| |189,629 -|||||||||| |151,479 |||||||||| |
|     | 16x 16|277,056 *||||||||  |248,640 +||||||   |197,836 =|||||||  |144,632 -|||||||  |121,040 ||||||||  |
|_PUTIMAGE | 32x 32|151,838 *|||||   |138,483 +||||    |132,094 =|||||   | 84,321 -|||||   | 75,851 |||||   |
|     | 64x 64| 74,074 *||     | 59,590 +||     | 58,367 =||     | 35,704 ||     | 43,243 -|||    |
|     | 128x128| 26,384 +|     | 23,327 =|     | 28,070 *|     | 13,193 |     | 21,658 -||     |
|     | 256X256| 8,154 +|     | 7,640 -|     | 9,785 *|     | 4,527 |     | 7,785 =|     |
├─────┼────┼──────────┼──────────┼──────────┼──────────┼──────────┤
|評価点合計|--------| *:22 +:3 =:0 -:0 | *:1 +:16 =:8 -:1 | *:3 +:5 =:15 -:2 | *:0 +:0 =:0 -:18 | *:0 +:1 =:2 -:5 |
|     |    |       計97点 |       計69点 |       計59点 |       計18点 |       計12点 |
└─────┴────┴──────────┴──────────┴──────────┴──────────┴──────────┘
*動作解像度はいずれも640x480ドット、256色モード

60名無しさん:2025/06/05(木) 10:06:48
さて、M4 Mac miniの思わぬ苦戦、この原因は?w

61名無しさん:2025/06/05(木) 10:07:16
おそらくRosetta2のオーバーヘッドが足かせになってるという…

62名無しさん:2025/06/05(木) 10:07:34
テスト環境はv2.0.7で確認したもので、v4.0.0では結果が違うかもしれないということでw

63名無しさん:2025/06/05(木) 10:07:58
単純転送は5600G内蔵GPUの方が速いかもしれないな…

64名無しさん:2025/06/05(木) 10:08:14
G5620でWin11動くの?w

65名無しさん:2025/06/05(木) 10:08:26
クリーンインストールから入ると昼寝ができるぐらいにwwww

66名無しさん:2025/06/05(木) 10:08:55
見た目はそうでもないけど、けっこう待たされる感じでw

67名無しさん:2025/06/05(木) 10:09:17
Windows11のサポート範囲なんだけどな、一言でいうと 「 やめた方がいい 」 というw

68名無しさん:2025/06/05(木) 10:09:31
この中で1つ削除するとしたら、どれにする?w

69名無しさん:2025/06/05(木) 10:09:51
3060 12GBはさすがにw

70名無しさん:2025/06/05(木) 10:10:45
QB64で想定されたユーザーではないというw

71名無しさん:2025/06/05(木) 10:11:03
ゲーム屋小僧、G5620みたいなものを一般層が使ってるとも思えないけど、これは?w

72名無しさん:2025/06/05(木) 10:11:19
内蔵GPUの性能をこれほどまでに引き出す開発ツールが他にあればな…

73名無しさん:2025/06/05(木) 10:11:38
ビデオカードを載せなくても256色モードを使えばなんとかなるというw

74名無しさん:2025/06/05(木) 10:11:54
物価高騰の背景で買い控えがある、しかしパフォーマンスは引き出したい…

75名無しさん:2025/06/05(木) 10:13:30
ChatGPT:
ほんと、5600Gの内蔵GPUがすごいね!まさか6年前のCPUがM4 Mac miniを超えるとは驚き
だわ。内蔵GPUの性能でここまで差がつくのか、と。M1やM2のようなAppleのチップも
すごいけど、Ryzen 5600Gの内蔵GPUは、GPUなしのエントリーレベルでもかなり強力な
性能を発揮してるんだな。

「4060無印に迫る」っていうのもかなりすごい表現だね。内蔵GPUでもここまで来るって
ことは、特に軽いグラフィック描画やゲームの処理では、十分なパフォーマンスが出せる
ってことかも。しかも、投げ売り特価で買えたなら、コストパフォーマンスもかなりいい!

M1 Mac miniが「お役御免」になるかは難しいところだけど、やっぱり内蔵GPU性能だけで
言うと、5600Gの方が今は上回ってるって感じがあるね。それでも、Appleのエコシステム
やソフトウェア最適化がしっかりしているから、そっちの利点は捨てきれない部分も多い
けど。

とはいえ、価格と性能のバランスで言ったら、これから5600Gを選ぶ人が増えるかもしれ
ないね!

76名無しさん:2025/06/05(木) 10:14:01
ChatGPT:
面白い比較だね!まさに「椅子取りゲーム」みたいな感じで、性能の差が顕著になってる。
特に、最新のGPUを搭載したデスクトップPCが圧倒的な速さを見せてるけど、それでも
内蔵GPUの性能が驚くほど高いのが印象的だね。

例えば、内蔵GPU(Ryzen 5600GやM4 Mac mini)でも、PSETやLINE、PUTIMAGEなどで
かなりのスピードが出てる。特に、内蔵GPUにしてはかなりのパフォーマンスを見せている
M4 Mac miniも、比較的低い点数(12点)にはなってるけど、実際に使ってみると快適さが
伝わってきそう。

また、GPUの処理能力がダイレクトに現れるPUTIMAGEの項目では、4060無印が圧倒的に
速くて、次点の3060 12GBがそれに続く感じ。内蔵GPUがいかに低いスコアでも、
グラフィック系の処理をハードウェアに任せることで、これだけの差が出ているんだなぁ
って思う。

こういった比較を見てると、予算や用途に合わせてどの環境を選ぶか迷ってしまうけど、
やっぱり「パフォーマンス重視」なら外付けGPUのPCが一歩リードしている感じかな。

77名無しさん:2025/06/05(木) 10:15:05
ChatGPT:
なるほど、M4 Mac miniが苦戦している理由はRosetta 2のオーバーヘッドが大きな要因と
して考えられますね。Rosetta 2はApple Silicon用に設計されていないアプリケーション
を動かすためのエミュレーション環境ですが、どうしてもネイティブのARMアーキテクチャ
と比べると処理が遅くなりますよね。

v2.0.7とv4.0.0のバージョン差によっても、パフォーマンスに変動が出る可能性があるの
で、テスト環境における結果が異なるのも十分にあり得ます。特に、CPUやGPUの性能を
フルに引き出せるような最適化がされていないと、内蔵GPUのほうが速く感じられるの
かもしれません。

「G5620でWin11動くの?」という問いに関しては、確かに動くけど、パフォーマンス的に
は厳しいですね。クリーンインストールで「昼寝できるくらい待たされる」というのは、
かなりのストレスかも(笑)。ただ、Windows 11は比較的重めのOSなので、低スペックの
マシンではやっぱり応答速度が遅くなることが多いですね。

「やめた方がいい」と言われてる中で、削除するべき項目を選ぶなら、3060 12GBは間違い
なく外れそうですね。やはりQB64のような環境では、そこまでのグラフィック性能は必要
ないし、むしろオーバースペック。ゲーム開発や重い3D処理をするわけでもないので、
内蔵GPUや中級クラスのGPUがあれば十分ですもんね。

最適化を考えると、やっぱり「適材適所」で、必要なパフォーマンスを引き出せる環境を
選ぶのが一番です!

78名無しさん:2025/06/05(木) 10:19:01
ChatGPT:
確かに、G5620のようなCPUを一般層が使っているとはあまり考えられませんね(笑)。
一般的には、もっと手軽に性能が高くてコストパフォーマンスも良いものを選ぶ人が多い
と思います。ですが、こうした「古めの低価格帯のCPU」であっても、QB64のような軽量な
開発ツールやゲームエンジンを使うことで、性能を引き出す方法はあるのかもしれません。

内蔵GPUをうまく引き出す開発ツールがあれば、ビデオカードを使わずに「ゲーム屋小僧」
のような環境で十分に性能を発揮できるというのはまさにその通り。256色モードを使う
ことで、特にグラフィックの描画負荷を大幅に減らすことができるので、安価なPCでも
それなりのパフォーマンスが得られるわけです。

物価高騰が続いている中で、パフォーマンスは求めつつも、ビデオカードや高性能な
パーツへの投資を控える傾向が強くなっているのも納得です。そんな時に、予算内で
最大限に性能を引き出せる開発環境があれば、非常にありがたいですね。

QB64のような軽量かつシンプルなツールが役立つのも、そういう背景があるからでしょう。
開発者にとっても、物理的な制約を越えて「どうにかして性能を引き出す」という
チャレンジが面白いところでもありますね!

79名無しさん:2025/06/05(木) 10:19:35
売る側としては、最適化は買い控えに繋がる考えということで嫌われるというかw

80名無しさん:2025/06/05(木) 10:19:57
しかしゲーム屋小僧、プログラムにしても売る側の芸術性の押し付けもあれば、画面周りにしても必要のないオーバーヘッドを取り除けばまだまだ使えるという、これがいけないことなのか?

81名無しさん:2025/06/05(木) 10:20:52
ChatGPT:
確かに、売る側としては最適化によって「これ以上買わなくても大丈夫」という状況が
作られてしまうのは困りますよね(笑)。その結果として、性能を引き出す手段が制限さ
れてしまうのは、販売側にとってはちょっと困るところかもしれません。

でも、ゲーム屋小僧の言う通り、プログラムにおいても売る側の「芸術性の押し付け」や、
画面周りに必要のないオーバーヘッドを削減すれば、性能はまだまだ使えるという点には
同感です。過剰なグラフィックや演出に注力しすぎて、本当に必要な部分が見えなくなっ
ていることが多いですからね。

最適化が悪いことだとは思いません。むしろ、最適化によって限られたリソースを最大限
に活用する方法を見つけることが、開発者としては価値のあることだと思います。ただ、
売る側がその「最適化」をあまり進めすぎると、買い控えが進んでしまうのも事実です。
結果的に、バランスをどう取るかが重要になってくるのでしょうね。

ただ、消費者側としては、無駄なオーバーヘッドを省き、性能を引き出せるような開発や
利用方法は大いに歓迎されるはずです。最終的にそのパフォーマンスがゲームや
アプリケーションの体験にどう影響するかが大事ですから。

82名無しさん:2025/06/05(木) 10:22:37
他人の商売の邪魔はしちゃいけないからなw

83名無しさん:2025/06/05(木) 10:22:52
こう、レトロ世代に毛が生えたぐらいの範囲でw

84名無しさん:2025/06/05(木) 10:23:04
どんな表現なんだよwwwwwww

85名無しさん:2025/06/05(木) 10:23:20
16色モードと256色モードの違いはどう?

86名無しさん:2025/06/05(木) 10:24:05
ちょっと試してみた範囲では、速度差がないということでw

87名無しさん:2025/06/05(木) 10:24:22
32bit色になると半分以下に落ちるというw

88名無しさん:2025/06/05(木) 10:24:37
16色では不足でw

89名無しさん:2025/06/05(木) 10:25:11
こう、MSX時代みたいなw

90名無しさん:2025/06/05(木) 10:25:29
怪しさ爆発wwwwwwwww

91名無しさん:2025/06/05(木) 10:25:44
この当時に見られたPCG機能やら、スプライトやら、処理速度を克服するための仕組みは、今となっては利用価値がないというか…

92名無しさん:2025/06/05(木) 10:26:10
MSX2+以降の19,268色表示については?

93名無しさん:2025/06/05(木) 10:26:26
いわゆるYJK表示、画像フォーマットを考える上では興味深いものの、それ以上のものはないというw

94名無しさん:2025/06/05(木) 10:28:54
圧縮フォーマットかw

95名無しさん:2025/06/05(木) 10:29:06
QB64の変数の扱いのうち、グローバル変数、あるいはローカル変数の扱いは?

96名無しさん:2025/06/05(木) 10:29:21
SUB-END SUBのプロシージャの中で使う変数がローカル変数扱いで、その外にあるのがグローバル変数扱い?

97名無しさん:2025/06/05(木) 10:29:38
SUB-END SUB外にある変数も参照不能のようでw

98名無しさん:2025/06/05(木) 10:29:53
DIM SHARED 変数名 [定義列]を使ってグローバル変数扱いできるみたいだけどな、使い方の不明な部分もあるようでw

99名無しさん:2025/06/05(木) 10:30:08
パラメータを返す必要がある場合はSUB-END SUBではなく、FUNCTION-END FUNCTIONを使った方がいいかなw

100名無しさん:2025/06/05(木) 10:30:31
SUB-END SUBが拡張コマンドのように使えて、FUNCTION-END FUNCTIONが拡張関数のように使えるところかw

101名無しさん:2025/06/05(木) 10:30:45
IDEでは色分けされるので見た目の問題はないかw

102名無しさん:2025/06/05(木) 10:31:00
99BASICから移る場合は、素直にラベルとGOSUB使った方がいいかもしれないなw

103名無しさん:2025/06/05(木) 10:31:15
その中で、すぐに捨てるような雑用の変数が増えてきた場合、SUB-END SUB、あるいはFUNCTION-END FUNCITONを使うなりw

104名無しさん:2025/06/05(木) 10:31:27
この中の注意事項は、ハンドル変数はプロシージャを抜けても保持されるところかw

105名無しさん:2025/06/05(木) 10:31:40
_NEWIMAGEとか?

106名無しさん:2025/06/05(木) 10:31:51
そっそw

107名無しさん:2025/06/05(木) 10:32:34
> 画像は、それが作成されたSUBまたはFUNCTIONが終了しても割り当て解除されません。
> _FREEIMAGEを使用して解放してください。

…ということらしいw

108名無しさん:2025/06/05(木) 10:32:49
明確なローカル変数指定、あるいはグローバル変数指定がないので混乱しないようにw

109名無しさん:2025/06/05(木) 10:33:01
ラベルとGOSUBを使う範囲では、すべてがグローバル変数扱いということでw

110名無しさん:2025/06/05(木) 10:33:14
サブルーチンの中でループ変数が重複して壊れるとか、そのへんは自分で解決するようにw

111名無しさん:2025/06/05(木) 10:33:30
リカーシブに陥った場合、QB64は途中で自動停止する?

112名無しさん:2025/06/05(木) 10:33:44
しないw

113名無しさん:2025/06/05(木) 10:33:55
そのへん気を付けてw

114名無しさん:2025/06/05(木) 10:36:14
ChatGPT:
MSX2+以降の19,268色表示(YJK表示)の話は、確かに当時としては非常に画期的でした
よね。MSX2+は、色数や解像度において、当時の他の家庭用機やPCよりも優れた性能を
持っていたため、ゲームやアプリケーションでかなりインパクトがありました。しかし、
今となっては、その技術自体が特に「これを使いたい!」という場面は少ないかもしれま
せんね。

YJK表示自体は、主に色空間の変換に関わる技術で、映像やグラフィックスの圧縮や
保存方法を工夫する上で使われていました。YJK(Y=輝度、J=色差、K=色差)という
分離の仕組みは、特に色の圧縮と視覚的な違和感を抑えるために活用されていました。
しかし、現代の圧縮技術やカラー表示の進化により、その独特なフォーマットが使われる
機会は減ったと思います。

実際、圧縮フォーマットという観点で見ると、YJKのような方式が主流だった時代に比べ、
今では例えばPNGやJPEG、WebPなどが圧縮と画質のバランスを取る形で広く使用されて
います。これらの形式は、色空間の扱いにおいても遥かに効率的で、現代のハードウェア
ではより高精度で高速な処理が可能になっています。

当時のMSX2+やその後の技術が「今では利用価値がない」というよりは、時代のニーズに
応じた最適化が進んだ結果、それに代わるもっと効率的で高品質な技術が登場したという
感じでしょうか。レトロな技術や方法論には、その時代の制約の中で創意工夫があったり
しますが、現代の標準に合わせた処理速度や圧縮方法、色表現の精度にはやはり敵わない
部分が多いですね。

ただ、レトロな技術や古いフォーマットが持つ「味わい」は、今でもどこか魅力的です。
例えば、レトロゲームや懐かしい映像表現を再現したい時には、昔の技術を意図的に
使ってみるのも面白いかもしれません。

115名無しさん:2025/06/05(木) 10:36:35
SUB-END SUB、 FUNCTION-END FUNCTIONを使う上での留意点

・ SUB-END SUBではブラケットを使わない表記が認められる 例: proc P1,P2など

・ プロシージャ内では外で定義された変数は無効
・ プロシージャ内で定義された変数はローカル変数扱い
・ DIM SHAREDで定義された変数はグローバル変数扱い

・ ハンドル変数とそのワークエリアはプロシージャを出入りしてもその内容は保持される

・ QB64内部でリカーシブ(再帰)の判定はしないので、原則的には使わない

・ 99BASIC、あるいは古い世代のBASICから移る場合は、始めはラベルとGOSUBを使って、
 ループ変数の重複が増えてきた場合にSUB-END SUB、 FUNCTION-END FUNCTIONを使う

…ってとこかw

116名無しさん:2025/06/05(木) 10:37:13
DIM SHAREDが落とし穴になりそうでw

117名無しさん:2025/06/05(木) 10:37:25
他で慣れてると、そっちの先入観が支配してしまうからなwwwww

118名無しさん:2025/06/05(木) 10:37:49
サンプルプログラムと実行結果w

Dim Shared A As Integer
A = 12: B = 34: C = 56: D = 78: ret = 0
sample1 A
Print Using "mainloop: A=### / B=### / C=### / D=### / ret=###"; A; B; C; D; ret
ret = sample2(A)
Print Using "mainloop: A=### / B=### / C=### / D=### / ret=###"; A; B; C; D; ret
End

Sub sample1 (C)
  D = A
  C = B
  D = D + 1
  A = 99
  Print Using "sub proc: A=### / B=### / C=### / D=### / ret=###"; A; B; C; D; ret
End Sub

Function sample2 (C)
  D = A
  C = B
  D = D + 1
  A = 33
  Print Using "func prc: A=### / B=### / C=### / D=### / ret=###"; A; B; C; D; ret
  sample2 = D
End Function

結果:
sub proc: A= 99 / B= 0 / C= 0 / D= 13 / ret = 0
mainloop: A= 99 / B= 34 / C= 56 / D= 78 / ret = 0
sub proc: A= 33 / B= 0 / C= 0 / D=100 / ret = 0
mainloop: A= 33 / B= 34 / C= 56 / D= 78 / ret =100

119名無しさん:2025/06/05(木) 10:38:28
ワロタw

120名無しさん:2025/06/05(木) 10:39:07
他で覚えた知識のある人は捨てる、99BASIC、あるいは古い世代から移ってきた人は新たに覚えればいいw

121名無しさん:2025/06/05(木) 10:39:20
この中で、QB64はグローバル変数の扱いが低いかw

122名無しさん:2025/06/05(木) 10:39:38
それをDIM SHAREDで定義しなければ存在を認めてもらえないというw

123名無しさん:2025/06/05(木) 10:39:53
ChatGPTはこの内容を理解していないので、解説はオミットw

124名無しさん:2025/06/05(木) 10:40:13
ゲーム屋小僧、要するにプロシージャ内はサンドボックス化されてるということ?

125名無しさん:2025/06/05(木) 10:40:27
サンドボックス化という表現が適当かどうかは置いといて、まあ、そういうことだなwwww

126名無しさん:2025/06/05(木) 10:40:41
外と内が分離されてるということでw

127名無しさん:2025/06/05(木) 10:41:19
補足 SUB-END SUB、 FUNCTION-END FUNCTIONを使う上での留意点

・ SUB-END SUBではブラケットを使わない表記が認められる 例: proc P1,P2など

・ プロシージャ内では外で定義された変数は無効
・ プロシージャ内で定義された変数はローカル変数扱い
・ DIM SHAREDで定義された変数はグローバル変数扱い
・ プロシージャ内で定義された変数と外で定義された変数は、DIM SHAREDで定義しない
 限りは別々の扱い

・ ハンドル変数とそのワークエリアはプロシージャを出入りしてもその内容は保持される

・ QB64内部でリカーシブ(再帰)の判定はしないので、原則的には使わない

・ 99BASIC、あるいは古い世代のBASICから移る場合は、始めはラベルとGOSUBを使って、
 ループ変数の重複が増えてきた場合にSUB-END SUB、 FUNCTION-END FUNCTIONを使う

…ってとこかw

128名無しさん:2025/06/05(木) 10:41:59
ここで躓いたら大きいプログラムは作れないからなwwwww

129名無しさん:2025/06/05(木) 10:42:09
ワロッチw

130名無しさん:2025/06/05(木) 10:42:20
ゲーム屋小僧、続・漢字表示はどうする?w

131名無しさん:2025/06/05(木) 10:42:33
今のところ予定はないけどな、99BASICからフォントを引っ張ってきてry

132名無しさん:2025/06/05(木) 10:42:48
仮想コンソール?w

133名無しさん:2025/06/05(木) 10:43:00
仮に仮想コンソールをやったとしても、充分な余裕ありということでw

134名無しさん:2025/06/05(木) 10:43:10
画面のレイアウトは?w

135名無しさん:2025/06/05(木) 10:43:37
一例を挙げると、こういう感じでw

┌───────────────────────┐←────背景色 / 背景画固定
│┌───────────────────────┐←───BG画面
││┌───────────────────────┐←──スプライト用バッファ
│││┌───────────────────────┐←─パーティクル用
││││┌───────────────────────┐←テキスト画面
│││││                       │
│││││                       │
│││││                       │
│││││                       │
│││││                       │
│││││                       │
│││││                       │
│││││                       │
│││││                       │
└││││                       │
 └│││                       │
  └││                       │
   └│                       │
    └───────────────────────┘

136名無しさん:2025/06/05(木) 10:43:50
それだけの余裕あるの?wwww

137名無しさん:2025/06/05(木) 10:44:10
参考 QB64動作環境の比較 - 椅子取りゲーム(^。^) 2025.1.25.土.18:38 更新*

 評価点 *:4点 +:3点 =:2点 -:1点
┌─────┬────┬──────────────────────────────────────────────────────┐
|  項目  | サイズ |                          QB64                          |
├─────┼────┼──────────────────────────────────────────────────────┤
|  API  |--------|                          openGL                          |
├─────┼────┼──────────┬──────────┬──────────┬──────────┬──────────┤
|  機種  |--------|  デスクトップPC  |  デスクトップPC  |  デスクトップPC  |  デスクトップPC  |  M4 Mac mini   |
|  OS  |    |   LinuxMint   |   Windows10   |   Windows11   |  Windows11 Pro  |MacOS省電力モードOFF|
├─────┼────┼──────────┼──────────┼──────────┼──────────┼──────────┤
|  CPU  |--------|   14500無印   |    13100F    | AMD Ryzen 5 5600G | Intel Pentium G5620| Apple M4 10 Core |
|     |    |   2024年1月   |   2023年1月   |   2021年8月   |   2019年11月   |   2024年11月   |
├─────┼────┼──────────┼──────────┼──────────┴──────────┴──────────┤
|  GPU  |--------|   4060無印   |   3060 12GB   |               内蔵GPU              |
|     |    |   2023年5月   |   2021年2月   |                                |
├─────┼────┼──────────┼──────────┼──────────┬──────────┬──────────┤
|  PSET  |1 ドット| 34,078 *|||||||||| | 28,669 +||||||||  | 28,444 =||||||||  | 18,233 -|||||   | 8,333 |||    |
├─────┼────┼──────────┼──────────┼──────────┼──────────┼──────────┤
| PAINT  | 全画面 |  7.1 *|||||||||| |  6.2 =||||||||  |  4.7 -||||||   |  3.9 |||||   |  6.5 +||||||||| |
├─────┼────┼──────────┼──────────┼──────────┼──────────┼──────────┤
|     |  8x 8| 30,346 *|||||||||| | 26,143 +|||||||||| | 26,016 =|||||||||| | 15,724 -|||||||||| | 7,944 |||||||||| |
|     | 16x 16| 29,163 *||||||||| | 24,864 +||||||||| | 23,970 =||||||||| | 14,678 -||||||||| | 7,799 ||||||||| |
|  LINE  | 32x 32| 26,834 *||||||||  | 22,634 +||||||||  | 20,711 =||||||||  | 12,648 -||||||||  | 7,228 ||||||||| |
|     | 64x 64| 22,976 *|||||||  | 19,081 +|||||||  | 16,264 =||||||   | 10,110 -||||||   | 6,863 ||||||||  |
|     | 128x128| 17,733 *||||||   | 14,652 +||||||   | 11,228 =||||    | 7,223 -|||||   | 6,340 ||||||||  |
|     | 256x256| 12,465 *||||    | 10,112 +||||    | 7,166 =|||    | 4,597 |||    | 5,033 -||||||   |
├─────┼────┼──────────┼──────────┼──────────┼──────────┼──────────┤
|     |  8x 8| 24,615 *|||||||||| | 21,824 +|||||||||| | 18,962 =|||||||||| | 12,121 -|||||||||| | 6,514 |||||||||| |
|     | 16x 16| 21,192 *||||||||  | 18,382 +||||||||  | 15,421 =||||||||  | 9,785 -||||||||  | 6,448 ||||||||| |
| LINE B | 32x 32| 17,181 *|||||||  | 14,380 +||||||   | 11,237 =||||||   | 7,339 -||||||   | 5,798 ||||||||| |
|     | 64x 64| 11,973 *|||||   | 10,077 +|||||   | 7,219 =||||    | 4,692 -||||    | 4,612 |||||||  |
|     | 128x128| 7,646 *|||    | 6,178 +|||    | 4,211 =||     | 2,808 |||    | 3,542 -|||||   |
|     | 256x256| 4,416 *||     | 3,573 +||     | 2,236 -||     | 1,552 ||     | 2,334 =||||    |
├─────┼────┼──────────┼──────────┼──────────┼──────────┼──────────┤
|     |  8x 8| 31,449 *|||||||||| | 26,834 =|||||||||| | 27,586 +|||||||||| | 16,864 -|||||||||| | 7,728 |||||||||| |
|     | 16x 16| 30,331 *||||||||| | 26,143 =||||||||| | 26,722 +||||||||| | 15,900 -||||||||| | 7,611 ||||||||| |
| LINE BF | 32x 32| 28,444 *||||||||| | 24,270 =||||||||| | 25,296 +||||||||| | 14,463 -||||||||  | 7,598 ||||||||| |
|     | 64x 64| 24,615 *||||||||  | 19,571 =|||||||  | 20,221 +|||||||  | 11,657 -|||||||  | 7,193 ||||||||| |
|     | 128x128| 15,686 *|||||   | 14,241 =|||||   | 15,421 +||||||   | 8,415 -|||||   | 6,276 ||||||||  |
|     | 256x256| 7,582 +|||    | 6,973 =|||    | 9,580 *||||    | 4,398 |||    | 4,436 -||||||   |
├─────┼────┼──────────┼──────────┼──────────┼──────────┼──────────┤
|     |  8x 8|338,624 +|||||||||| |388,585 *|||||||||| |293,577 =|||||||||| |189,629 -|||||||||| |151,479 |||||||||| |
|     | 16x 16|277,056 *||||||||  |248,640 +||||||   |197,836 =|||||||  |144,632 -|||||||  |121,040 ||||||||  |
|_PUTIMAGE | 32x 32|151,838 *|||||   |138,483 +||||    |132,094 =|||||   | 84,321 -|||||   | 75,851 |||||   |
|     | 64x 64| 74,074 *||     | 59,590 +||     | 58,367 =||     | 35,704 ||     | 43,243 -|||    |
|     | 128x128| 26,384 +|     | 23,327 =|     | 28,070 *|     | 13,193 |     | 21,658 -||     |
|     | 256X256| 8,154 +|     | 7,640 -|     | 9,785 *|     | 4,527 |     | 7,785 =|     |
├─────┼────┼──────────┼──────────┼──────────┼──────────┼──────────┤
|評価点合計|--------| *:22 +:3 =:0 -:0 | *:1 +:16 =:8 -:1 | *:3 +:5 =:15 -:2 | *:0 +:0 =:0 -:18 | *:0 +:1 =:2 -:5 |
|     |    |       計97点 |       計69点 |       計59点 |       計18点 |       計12点 |
└─────┴────┴──────────┴──────────┴──────────┴──────────┴──────────┘
*動作解像度はいずれも640x480ドット、256色モード

138名無しさん:2025/06/05(木) 10:45:06
例えばHD解像度(1280x720)で5600Gを使ったとすれば、1/60秒で9,785回書き換えができるので、計算式は…

139名無しさん:2025/06/05(木) 10:45:16
9785*(256*256)/(1280*720*5)=139.164

140名無しさん:2025/06/05(木) 10:45:27
1/60秒で5画面取っても139回書き換える速度はあるようでw

141名無しさん:2025/06/05(木) 10:45:37
139回ワロタw

142名無しさん:2025/06/05(木) 10:45:49
特に考える必要なしということでw

143名無しさん:2025/06/05(木) 10:46:00
考える必要なしwwwwwww

144名無しさん:2025/06/05(木) 10:46:11
こう、好きなように考えて、自分で管理できるかどうかでw

145名無しさん:2025/06/05(木) 10:46:22
参考までに、99BASICが6.4回でギリギリということでw

146名無しさん:2025/06/05(木) 10:46:35
別々の世界みたいなw

147名無しさん:2025/06/05(木) 10:46:46
スプライト用とパーティクル用のバッファを分ける理由は?

148名無しさん:2025/06/05(木) 10:46:58
256色モードは半透明が使えないので、パーティクルは1ドット毎に間を空けて描画して、背景が見えるようにしようかな〜、って感じでw

149名無しさん:2025/06/05(木) 10:47:10
んで、描画の優先度が混じると何を表示してるか分からないので分離するというw

150名無しさん:2025/06/05(木) 10:47:43
パレットの割り当てを考えると…

┌───────────────────────┐←────背景色 / 背景画固定 --- 32色
│┌───────────────────────┐←───BG画面 ---------------- 32色
││┌───────────────────────┐←──スプライト用バッファ -- 32色
│││┌───────────────────────┐←─パーティクル用 -------- 32色
││││┌───────────────────────┐←テキスト画面 ---------- 32色
│││││                       │          合計 160色
│││││                       │
│││││                       │
│││││                       │
│││││                       │
│││││                       │
│││││                       │
│││││                       │
│││││                       │
└││││                       │
 └│││                       │
  └││                       │
   └│                       │
    └───────────────────────┘

151名無しさん:2025/06/05(木) 10:49:27
なんとか足りるかなw

152名無しさん:2025/06/05(木) 10:49:39
テキスト画面は32色で足りるの?

153名無しさん:2025/06/05(木) 10:49:50
白と赤、あと水色ぐらいでグラデーションで行けるかw

154名無しさん:2025/06/05(木) 10:50:04
2の乗数にこだわる理由もなくなってきたかな…

155名無しさん:2025/06/05(木) 10:50:44
これでもいいかもなw

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

156名無しさん:2025/06/05(木) 10:51:54
99色w

157名無しさん:2025/06/05(木) 10:52:07
11x11ドットのフォントで9色分のグラデーションw

158名無しさん:2025/06/05(木) 10:52:28
ChatGPT:
9色のグラデーションを11x11ドットのフォントで表現するのは、かなり効率的で目を引く
デザインになりそうですね!9色でグラデーションを作ることで、文字やテキストに深み
や立体感を与えることができます。

具体的なアイデア:

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

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

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

もし文字の周りにハイライトやシャドウを加えることで、さらに視認性や立体感を高める
こともできるかもしれません。デザインの幅が広がりますよね!

159名無しさん:2025/06/05(木) 10:53:00
画面の回転と拡大縮小は?w

160名無しさん:2025/06/05(木) 10:53:12
QB64のコマンドにあるにはあるんだけどな、処理速度を計測してないのでw

161名無しさん:2025/06/05(木) 10:53:24
検討する範囲でw

162名無しさん:2025/06/05(木) 10:54:56
256色モードでも使えるので、いい方向に行ければw

163名無しさん:2025/06/05(木) 10:55:10
楽しみですな〜w"

164名無しさん:2025/06/05(木) 10:55:25
99BASICから漢字フォント拾ってきたw

165名無しさん:2025/06/05(木) 10:55:38
シフトJISに準拠してるかのように見えて、並びは違うようでw

166名無しさん:2025/06/05(木) 10:56:12
先頭1文字で判別して割り合てるかw

167名無しさん:2025/06/05(木) 10:56:23
独自フォントはQB64で可能?

168名無しさん:2025/06/05(木) 10:56:37
そっちを使わずに仮想コンソールの方が速いかもなw

169名無しさん:2025/06/05(木) 10:56:50
99BASICから拾ってきた漢字を配布するとライセンス違反になるので、配布時は使う漢字のみを抽出して独自フォントに切り替えるかw

170名無しさん:2025/06/05(木) 10:57:02
PRINT文は意外と遅いというかw

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
ワロッチw

173名無しさん:2025/06/05(木) 10:58:43
拾ってきたのはいいものの、コード変換をどうするか…w"

174名無しさん:2025/06/05(木) 10:58:57
DATA文のリテラル文字列は、ダブルクオーテーション必要?w

175名無しさん:2025/06/05(木) 10:59:13
これはなくてもいけるんだけどな、見た目の区別で付ける癖をw

176名無しさん:2025/06/05(木) 10:59:30
じゃあDATA文のリテラル数字、あるいはリテラル文字列で計算式は行ける?

177名無しさん:2025/06/05(木) 10:59:58
試してみたところ、QB64も99BASICも、文字列の場合はデリミタ直前の数字のみ判別可能、それ以降は無視されるということでw

178名無しさん:2025/06/05(木) 11:00:40
リテラル計算式の場合はSyntaxErrorということでw

179名無しさん:2025/06/05(木) 11:00:51
VAL使ったら行けるんじゃないかとかw

180名無しさん:2025/06/05(木) 11:01:05
DATA文の扱い

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

…ってとこかw

181名無しさん:2025/06/05(木) 11:01:34
こう、今さら分かってるようで分かってなかったBASIC、みたいなw

182名無しさん:2025/06/05(木) 11:02:14
補足 DATA文の扱い

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

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

…ってとこかw

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

ということは、VAL文も?w

184名無しさん:2025/06/05(木) 11:03:04
試してみたところ、計算式は解釈できないようでw

185名無しさん:2025/06/05(木) 11:03:23
補足 DATA文の扱い

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

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

…ってとこかw

186名無しさん:2025/06/05(木) 11:03:40
怪しさ爆発不思議ワールドみたいなwwwwwwwww

187名無しさん:2025/06/05(木) 11:04:03
QB64PE v4.0.0のヘルプファイルを参考までにw

> 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
そんなところでw

189名無しさん:2025/06/05(木) 11:05:54
> ◆ 末尾にスペースがあるSTRING DATA値、QBasicキーワード、およびカンマ文字を含む値
>   は、引用符で囲む必要があります。

予約語を含むとアウトなのかw

190名無しさん:2025/06/05(木) 11:06:15
補足 DATA文の扱い

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

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

…ってとこかw

191名無しさん:2025/06/05(木) 11:06:41
じゃあ、リテラル文字列の中にダブルクォーテーションを含めることはできる?

192名無しさん:2025/06/05(木) 11:06:53
結論から言うとできないということでw

193名無しさん:2025/06/05(木) 11:07:12
QB64と99BASICは内部動作が異なるので…

194名無しさん:2025/06/05(木) 11:07:36
補足 DATA文の扱い

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

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

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

…ってとこかw

195名無しさん:2025/06/05(木) 11:08:24
各々試してみれば分かるのでw

196名無しさん:2025/06/05(木) 11:08:53
こう、構文解析が怪しいところは使わないw

197名無しさん:2025/06/05(木) 11:09:09
んでゲーム屋小僧、コード変換はどうするの?w

198名無しさん:2025/06/05(木) 11:35:55
2バイト分のインデックスを持ってそのまま割り当てるのが速いかw

199名無しさん:2025/06/05(木) 11:36:08
128KBムダになるけどな、プログラム中で検索するのはさらにムダということでw

200名無しさん:2025/06/05(木) 11:36:20
半角と全角はどうやって区別するの?w

201名無しさん:2025/06/05(木) 11:36:51
インデックスの2バイト目が0なら半角扱いということでw

202名無しさん:2025/06/05(木) 11:37:11
1バイトずつ取り出して、インデックスに関連付けるかw

203名無しさん:2025/06/05(木) 11:38:26
そのへん、シフトJISの解釈と内部動作は同じになるかな…

204名無しさん:2025/06/05(木) 11:39:06
漢字を含むプログラムで、ファイル処理はどうなってるの?

205名無しさん:2025/06/05(木) 11:39:21
ファイル処理は漢字を含んでもそのまま行けるので、IDEと画面上の課題をクリアすればw

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
ないものは自前で揃えろ、みたいなwwwww

210名無しさん:2025/06/05(木) 11:42:27
QB64はネタに事欠かないなwwwwwwwwww

211名無しさん:2025/06/05(木) 11:42:47
要点としては、計算式で簡潔に済ませようとすると、その分オーバーヘッドが出るので、メモリがムダになってもインデックスで高速に済ませるw

212名無しさん:2025/06/05(木) 11:42:59
ワロタw

213名無しさん:2025/06/05(木) 11:44:25
ChatGPT:
まさにその通りですねwww

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

要点を振り返ると:

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

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

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

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

「ワロタ」と言える部分が多すぎるけど、それもまたQB64の魅力の一つですなw

214名無しさん:2025/06/05(木) 11:44:47
画面レイアウトの話に戻って…

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

書き込み順位 背景(背景)→BG画面書き換え→スプライト用バッファクリア・書き換え→パーティクル用クリア・書き換え→テキスト画面(前景)

215名無しさん:2025/06/05(木) 11:45:50
テキスト画面は99BASIC準拠?w

216名無しさん:2025/06/05(木) 11:46:06
それいいなw

217名無しさん:2025/06/05(木) 11:46:32
99BASICのテキスト画面って、アトリビュートとしてインバース(反転)がある筈なんだけどな、どこをいじっても出てこない、ファンクションキー表示の中だけに秘密が残ってるというかw

218名無しさん:2025/06/05(木) 11:46:47
たぶんメモリマップの外にあるセグメント割り当ての領域でやってるかw

219名無しさん:2025/06/05(木) 11:47:19
フォントのサイズはどれぐらいに?

220名無しさん:2025/06/05(木) 11:47:30
半角で20x40ドット、全角で40x40ドットぐらいが適正かw

221名無しさん:2025/06/05(木) 11:47:56
99BASICのフォントが2倍表示モードで半角16x32、全角で32x32ドットなので、若干大きめにw

222名無しさん:2025/06/05(木) 11:48:09
2の乗数にこだわらない方針でwwww

223名無しさん:2025/06/05(木) 11:48:26
99BASICの半角8x16(16x32)も使えないこともないんだけどな、スコア表示ではやや貧弱というか…

224名無しさん:2025/06/05(木) 11:48:39
しかし全角を使うほどでもない…

225名無しさん:2025/06/05(木) 11:49:06
話は横道に逸れて…w"

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
素数計算のプログラムにどんな怪しい要素があるの?w

228名無しさん:2025/06/05(木) 11:52:08
これ自体は大したことはないんだけどな、ループ変数に使う型によって計算速度が大きく変わるという…

229名無しさん:2025/06/05(木) 11:56:17
FLOATなんか使ったら日が暮れるなwwwww

230名無しさん:2025/06/05(木) 11:56:31
ワロタ!!wwwwwwwwwwwww

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が混じるとアウトということでw

236名無しさん:2025/06/05(木) 11:58:42
どれぐらいの速度差?w

237名無しさん:2025/06/05(木) 11:58:55
だいたい2倍前後でw

238名無しさん:2025/06/05(木) 11:59:06
2倍も違ったら昼寝できるぞ!!wwwwww

239名無しさん:2025/06/05(木) 11:59:18
このへんはわざとFLOATを混ぜて遅い方に合わせるw

240名無しさん:2025/06/05(木) 11:59:30
他にできそうな対策は?w

241名無しさん:2025/06/05(木) 12:00:00
初期状態の明確化ということで、Timer offとOn Error GoTo 0を混ぜるといいw

242名無しさん:2025/06/05(木) 12:00:45
ChatGPT:
> 3. 計算の最適化
> ・ 素数計算の改善 現在のプログラムでは、すべての奇数(2以外)で割り切れるかどうか
>  を確認していますが、これには最適化の余地があります。例えば、次のように素数判定
>  を行う場合、計算量が大きく減少します。
>  ・ j が 2 より大きいときに、j の平方根以下の素数で割り切れるかどうかだけチェック
>   すればよいことに気づきます。これは、数値が平方根より大きければ、それに対応
>   する小さい数でも割り切れるためです。

243名無しさん:2025/06/05(木) 12:01:02
余計なお世話ワロタw

244名無しさん:2025/06/05(木) 12:01:25
そういうところで、型の違いによる速度差を知った上で、遅い型も混ぜるということでw

245名無しさん:2025/06/05(木) 12:02:05
あなた:
そろそろお開きにするとして、感想に残ったことは?w

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


新着レスの表示


名前: E-mail(省略可)

※書き込む際の注意事項はこちら

※画像アップローダーはこちら

(画像を表示できるのは「画像リンクのサムネイル表示」がオンの掲示板に限ります)

掲示板管理者へ連絡 無料レンタル掲示板