X
トップページ⇒昔のPC
96コメント28KB
マシン語ゲームで小数が使われていたか否か語るスレ
0001ナイコンさん
垢版 |
2018/12/17(月) 08:11:16.58
語れやハゲども
0002ナイコンさん
垢版 |
2018/12/17(月) 10:44:24.53
スプライトを使うゲームなら実装はアーケードやゲーム機、MSXなどで数えきれないほどある。
整数のみでリアルタイムゲームを作るのは、アーケードやゲーム機では黎明期を除き極めて少数派。
0003ナイコンさん
垢版 |
2018/12/17(月) 19:46:39.19
使われてたに決まってるじゃん。

=================　終了 ====================
0006ナイコンさん
垢版 |
2018/12/17(月) 22:14:05.41
小数って言っても、固定小数点だろ。

でもスプライト使ったアクションゲームでも小数使わずに作れるんじゃないの？
0007ナイコンさん
垢版 |
2018/12/21(金) 08:56:39.83
〜〜〜〜〜〜〜〜〜 今度こそ終了 〜〜〜〜〜〜〜〜〜
0008ナイコンさん
垢版 |
2018/12/23(日) 16:15:15.31
100倍で計算して100で割る
そんなんでも十分だった
0009ナイコンさん
垢版 |
2018/12/23(日) 19:36:18.98
>>8
それが固定小数点の考え方だよね
普通は256倍とか128倍、64倍などにするけど
0010ナイコンさん
垢版 |
2018/12/23(日) 20:00:09.63
小数点以下8ビットで0.00390625か　（間違ってたらスマンこ）
そこまで必要ないような希ガス
小数点以下は3ビットか4ビット前後もあれば充分なんじゃね
4ビットの根拠はないけどなんとなくそれくらいかな、と
0011ナイコンさん
垢版 |
2018/12/23(日) 20:43:07.88
1フレームで複数回の移動計算・判定処理を入れてた事例は
さすがにないだろうな。
0012ナイコンさん
垢版 |
2018/12/23(日) 20:49:11.66
整数だけだと縦or横と同じ速度で動くはずが斜では急に速度が上がるという不条理ｗ
誤差が最悪40％ぐらいでる・・・のかな？

たぶん描画エリア（座標計算が必要なエリア）の縦横どちらか長いほうの辺に合わせるのがおそらく合理的。
長辺が129〜256ドットの範囲なら小数点以下は8ビットあれば内部の座標と画面上の表示位置の誤差は最大1ドットにまで収束する・・・んでいいはず。
ちょっと自信ないけど。

本職のゲームプログラマーさんに正解を教えてもらいたい。
0013ナイコンさん
垢版 |
2018/12/23(日) 21:13:31.79
ゼビウスでは、ガルザカートでちゃんと丸く広がってたから、
それらしい計算は行われていた模様。
まあ、上記の通りビット操作の固定少数なんだろうけど。

方向が１６方向で固定だったようだから、
移動量の配列でも用意していたのだろう。
0014ナイコンさん
垢版 |
2018/12/23(日) 21:22:51.85
>>10
単純な話だけど、ビットシフトするにも時間が掛かる
実は8bitだと速いんだよね、16bitで計算して上位8bit取り出すのはノーコストだから
そんな理由で、8bitが多いと思う、精度と言うより効率だね
0015ナイコンさん
垢版 |
2018/12/24(月) 00:07:55.72
>>14
画面解像度が256ドットとしても
整数部8ビットじゃ、画面外の処理ができないので
整数部10ビット程度は必要だよ
0016ナイコンさん
垢版 |
2018/12/24(月) 00:15:50.00
>>15
俺は現役時代整数部10ビット小数部6ビットの固定小数点で演算してたなぁ
0017ナイコンさん
垢版 |
2018/12/24(月) 06:46:17.05
>>12
>>整数だけだと縦or横と同じ速度で動くはずが斜では急に速度が上がるという不条理ｗ
ああ、そりゃそうだよな
斜め移動を単純な縦移動＋横移動ってさせてたら確かにそうなってしまう
一度に縦と横の両方を移動できちゃうもんな
なるほど、単純な斜め移動でも小数が必要になるわけか
0018ナイコンさん
垢版 |
2018/12/24(月) 09:41:35.80
ふむふむ、10 : 6ビットで扱うのが主流だったわけか。
おれは12 : 4ぐらいかなあと思ってた。
001915
垢版 |
2018/12/24(月) 10:44:05.38
>>14
スプライトの座標系が-512〜+511とすると
左がスプライト側 右側がCPUから見たI/Oが
アーケードゲーム機だとこんな風に配置される様に
ハード屋さんに作ってもらうので
プログラム上でビットシフトせずに済むんだよ

D9 - D15
D8 - D14
D7 - D13
D6 - D12
D5 - D11
D4 - D10
D3 - D9
D2 - D8
D1 - D7
D0 - D6
NC - D5
NC - D4
NC - D3
NC - D2
NC - D1
NC - D0

NCは未接続
0020ナイコンさん
垢版 |
2018/12/24(月) 11:00:53.08
>>19

> ハード屋さんに作ってもらうので
> プログラム上でビットシフトせずに済むんだよ
こういうのをチート（ずる）と言わずしてなんというｗ
0021ナイコンさん
垢版 |
2018/12/24(月) 11:05:29.47
アーケードゲーは、はじめからそのソフトに見合った
ハードの設計をしてたんだもんねぇ。
0022ナイコンさん
垢版 |
2018/12/24(月) 11:48:58.49
>>18
だいたい整数部にどれだけのビットが必要か、小数部にどれだけの精度が必要か、あとは
どれだけビットシフトを減らせるか位のバランスで決める感じだよね

>>19みたいなアーケードの例はとても興味深いね、こういうトコでも普通のパソコンより有利な
条件が出てくる、専用ハードウェアだからこそだね
0023ナイコンさん
垢版 |
2018/12/24(月) 18:28:25.84
>>19
へえ、面白いなぁ
開発がソフトとハードで平行して行われるような環境ならではだね
8ビットマイコンだと既に出来上がってるハードの上で作るしかないからどうしたって不利になる
0024ナイコンさん
垢版 |
2018/12/26(水) 21:08:19.41
ある時期から8bitから16bitのスプライトマシンで固定小数使うのは常識になっていたのは知ってるし、後半の部分では実際に商品を作っていた。
ただ、前にあった書き込みで、速度はそのまま持つのではなく何段階かにしてテーブルのテーブルを持つのは実装としてあったと想像する。
MSXのザナックタイプなど、遅いCPUでそれなりに敵が多いシューティングゲームはこれを採用してるんじゃないかな。
あの手のはスプライトのちらつきを抑えるためにスプライトダブラを使ってるだろうから、それだけでもCPU負荷は大きい。
#アイテムで自機速度が少しずつ上がるとかはそのままではできなくなるが、自機だけ処理を別にすれば良い。
0025ナイコンさん
垢版 |
2018/12/27(木) 08:46:32.77
結論 : 使われてた

=============　終了 ================
0026ナイコンさん
垢版 |
2018/12/27(木) 18:40:20.82
１００なり１０００なりかけて計算すればいいだけ
ゲームボーイアドバンスなんかも固定小数使ってた
DSになるとさすがにない
0027ナイコンさん
垢版 |
2018/12/27(木) 18:49:47.40
100なり1000なりなんて手間だろ

「128なり1024なり」 って言えよ
002815
垢版 |
2018/12/27(木) 22:53:03.78
GBAはarm7
32ビットCPUなんでマシン語なんて使わんだろ
100なり1000なりかけて計算すればなんて書いちゃう奴だから
プログラムのプの字も知らないんだろうけど
0029ナイコンさん
垢版 |
2018/12/28(金) 00:22:37.43
今どきの32ビットや64ビットのコンパイラより効率のいいコードを、アセンブラで書けるようなヒトって人間辞めてるだろｗ
0030ナイコンさん
垢版 |
2018/12/28(金) 07:36:17.05
そういや昔、ゲームボーイアドバンスで
プログラムする本てのを買ったことがある。

それにはケーブルがついてて、そのケーブルを
ゲームボーイにつなぐことで、ROMの吸い出しが出来たんだよ。
0031ナイコンさん
垢版 |
2018/12/29(土) 22:21:47.14
>>30
なんのプログラミングだよw
0032ナイコンさん
垢版 |
2018/12/30(日) 01:01:51.30
unixuser誌でそんな連載があって、連載終了後
USB転送ケーブル付きで書籍が発売されたのよ。
何年か遅れで買ったけど、これ2003年発売なんだ。
もう15年も前の話か・・・
0033ナイコンさん
垢版 |
2019/01/01(火) 02:15:42.80
小数は使ってたよ。
float double みたいなのじゃないけど。
0034ナイコンさん
垢版 |
2019/01/02(水) 09:12:26.71
浮動少数演算がデバイスドライバになってるマシンがあったな。
浮動少数演算CPUを増設してドライバを置き換えれば、
アプリはそのままでも演算速度がアップするとか。
0035ナイコンさん
垢版 |
2019/01/02(水) 11:59:22.94
>>34
でも計算の度に呼び出すからオーバーヘッドが大きくて遅くなるんだよな
0036ナイコンさん
垢版 |
2019/01/15(火) 04:50:26.69
68000では固定小数使ってたわ。
レジスタ32ビットだったから、
上位整数、下位小数で add.l とかでロングワードで計算してた。
実際スプライトレジスタに転送するのは上位のみ。
0037ナイコンさん
垢版 |
2019/01/19(土) 01:39:17.74
>>34
68881が無いとエラー出すゲームソフトがあったよ
だからFPU無し機種の為にソフトFPUなるものがあった
当時浮動小数点演算FPUは高額だったからね
コストダウンの為にオプション扱いされてた
Macintoshなんだけどさ
0038ナイコンさん
垢版 |
2019/01/20(日) 21:22:10.67
DOSでは環境変数NO87に何か文字列を設定しておくと8087があっても使わなかったな
0039ナイコンさん
垢版 |
2019/02/06(水) 11:04:03.10
サインテーブルとか固定小数で1象限分だけ(他は反転でどうとでもなるので)作ってたな…
360度を1/4で90度分を256分解能で近似とかのインチキ演算でも低解像度だと案外バレない
0040ナイコンさん
垢版 |
2019/02/06(水) 13:32:42.24
>>39
一回転360度を256(符号なし8ビット)段階化はやるよな
オーバーフローチェックも要らなくなるし
0041ナイコンさん
垢版 |
2019/02/06(水) 14:09:14.95
DOS版のTSPという時系列分析ソフトが87系必須で、8087エミュレータでごまかしていたが劇的に遅かった
0042ナイコンさん
垢版 |
2019/02/06(水) 15:22:31.27
>>39
そんなプログラムを先月作ったがテーブルは257個じゃないと1.0相当値の入る場所が無くて困る
0043ナイコンさん
垢版 |
2019/02/06(水) 18:33:13.37
いや、角度は1度刻みで0度から90度の91項目だろ?
角度を256段階に刻む必要なんてあるか?
0044ナイコンさん
垢版 |
2019/02/09(土) 19:12:28.16
一周を360で刻む必要がゲームには無いから、扱いやすい256や1024で刻む
90より楽な理由は二進数だから
0045ナイコンさん
垢版 |
2019/02/09(土) 19:34:12.54
角度で刻むのではなくて始点のXY軸と終点XY軸では
例えば敵キャラの今いる位置を始点として
狙う自機キャラの今いる位置を終点とする
みたいな〜感じ〜　では？？？
0046ナイコンさん
垢版 |
2019/02/09(土) 20:39:44.19
>>43
0〜255の256段階だと8ビットレジスタぴったりでキリが良くて演算が楽になるからだよ
0047ナイコンさん
垢版 |
2019/02/10(日) 10:32:10.38
XY入れ替え＆符号反転の組み合わせでぐるり１周を8分割できる。
弧の8分の１の部分（0度〜45度）だけを256分割すると約0.18度刻みになる（ゲームだと精度たかすぎ？

1周を256分割してXY入れ替えも符号反転もしなければ、約1.4度刻みになる

シューティングゲームなら、データ量をとるか処理速度をとるかのトレードオフだとおもうけど、1周256分割してそのまま座標つかうほうが良いような気がする。
256は8で割りきれるから縦横斜めが誤差なく表現できるので人間の目に対する違和感が出ないだろうし。
0048ナイコンさん
垢版 |
2019/03/07(木) 01:02:25.72
１９８０年頃のパソコンでは、実数型コンパイラを売っていたのはシャープMZだけかと思いましたが、
ほかにおもちゃメーカーのバンダイ（現バンダイナムコ）が出していた「RX-78ガンダム」という名前のパソコンには、実数型コンパイラ（カセットテープ５万円）がオプションで販売されていました！
https://blog.goo.ne.jp/2645751/e/1a679fe2fb1695d938bfee96a917ebe6
0050ナイコンさん
垢版 |
2019/03/07(木) 19:16:42.97
64倍とか256倍で計算して、あとでシフトするのがCPU的には楽だろ。いわゆる固定小数点実数。
0051ナイコンさん
垢版 |
2019/03/07(木) 20:29:12.73
100倍とか1000倍とか言ってるのは機械語やってない人や固定小数演算を知らない人に向けて分かりやすく説明してるだけだと思うぞ
0053ナイコンさん
垢版 |
2019/03/08(金) 05:32:30.87
BCDで小数点情報他に持っといて計算する感じかな？
0054ナイコンさん
垢版 |
2019/03/11(月) 09:55:59.67
>>51
このスレでそんなことに気を使う必要があるんだろうか。
0055ナイコンさん
垢版 |
2019/03/11(月) 11:33:52.93
あるのよ
そもそもこのスレが立つ原因になった奴が固定少数知らないしプログラムやってたかも怪しいから
0056ナイコンさん
垢版 |
2019/03/11(月) 12:01:44.31
>>55
8ビット機のシューティングで小数点なんて要らないだろとか言ってて笑ったよな
00571
垢版 |
2019/03/11(月) 21:27:27.87
いいぞハゲども
もっと語れや、ハゲどもめ
0059ナイコンさん
垢版 |
2019/04/11(木) 12:12:29.15
>>51
シフトくらいわかってるよ。だいたいだよ。今は使わないし
0060ナイコンさん
垢版 |
2019/04/11(木) 13:08:07.49
>>50
その程度は本人たちはそれを固定小数点だと思ってなくても、
小中学生でも思いついてやってたレベルなんだよな。コード上は小数点は出てこないから。
0061ナイコンさん
垢版 |
2019/04/11(木) 13:40:45.76
8bitマシン語ゲームで実数の乗算、除算が使われていた!!! →コードは単にレジスタをシフトしてるだけ。
0062ナイコンさん
垢版 |
2019/04/11(木) 13:48:32.82
シフトしたら小数点の位置が移動するので固定じゃない!!!
0063ナイコンさん
垢版 |
2019/04/13(土) 17:28:51.95
整数16bitx16bitの仮想画面として計算して、
表示するときに実画面のサイズに縮小した、と考えても同じコードになるな。
0064ナイコンさん
垢版 |
2019/04/15(月) 18:40:13.93
>>51
スレタイでマシン語と明記しているので、100倍とか90度とか言っちゃう奴は単に未経験の馬鹿だと思いますよ。
0068ナイコンさん
垢版 |
2020/12/07(月) 17:19:47.14
パソコンゲームのソフトハウスは、ゲーム機やMSXなどスプライトを持つ機種に進出した例外を除き、位置をバイト単位での計算しかしなかった時期が長い。プレーンVRAMを採用した機種が主流だったので仕方ないことたが。
アーケードやスプライトマシンはもちろんバイト単位ではなくドット単位で指定するのだが、計算までドット単位でしていては大雑把な動きになってしまう。ここで登場するのが固定少数での計算。
他にも1intでは処理が収まらないから全体ループの後にタイミング調整したり、タスク管理や親子構造などが無かったり、80年代のパソコンゲームのテクニックはガラパゴス化していた。
それでもパソコンゲームのほうが進んでた分野をあげるとするなら、シナリオスクリプトコンパイラがある。
0069ナイコンさん
垢版 |
2020/12/07(月) 18:29:24.85
移動キャラが移動するために必要な情報は、現在位置と角度と速度。
ファミコンとかMSXとかPCエンジンの低解像度モードなら256あれば良いので、位置情報は2バイト。上位バイトが実数、下位バイトが小数にすれば処理は速い。スプライトの位置レジスタに設定するのは上位バイトのみ。
あとは360度を256段階で刻んだ1バイトの角度情報と、2バイト固定少数の速度情報がいる。
あとは2バイト×256個のSINCOSテーブルを用意。
角度からテーブルの三角関数値を得て、速度と乗算して現在の位置座標に加算する。

問題はZ80Aや6502 1.7MHzでは遅くて乗算がネックになること。仕方ないので速度を数段階にわけて、三角関数の値を調節したテーブルを数個持ち、乗算の部分を端折る。
速度を細かく分けるほどテーブルは肥大化するので、ケースバイケース。
0070ナイコンさん
垢版 |
2020/12/07(月) 21:35:13.82
8文字でわかる要約

「ケースバイケース」
0071ナイコンさん
垢版 |
2020/12/08(火) 06:32:58.23
sinテーブル(実際はcosテーブル)は0.0〜1.0の小数になるので、テーブルは小数部1バイトのみでいい
68k機で実数/小数各16bitの場合でもcosテーブルは小数のみ16bit
さらに「360度を256分割」はさすがに荒いので、ベクトルベースの演算が必要な場合は
「90度を256分割」、残りの象限は反転とXY入れ替えで対応できる

低解像度の2Dアクションやシューティング等でせいぜい32方向くらいなら、
sin/cosなど使わず最初から移動量ベースでテーブル化

まあ>>69はこの通り最適化も足りてないし、現役世代の経験談ではない薄っぺらい妄想、ということはわかる
0072ナイコンさん
垢版 |
2020/12/08(火) 06:35:09.33
当時sin(cos)テーブルを作るのに、なぜかBASICの実数演算を使ってASCIIファイルに吐かせる…という謎な作業をした思い出
BASIC使ったのはそれが最後くらいだな
0073ナイコンさん
垢版 |
2020/12/10(木) 12:22:48.90
XかYレジスタに角度が入っていればSINもCOS１命令で済む6502が最強
0075ナイコンさん
垢版 |
2020/12/11(金) 01:42:58.25
ゼロページって言ったっけ?、0〜ffhはレジスタ代わりに高速アクセスできるんでしょ。
0078ナイコンさん
垢版 |
2021/01/02(土) 07:29:25.96
余程単純なゲームじゃなきゃsincosテーブルは必須。
0079ナイコンさん
垢版 |
2021/01/03(日) 09:04:44.49
このスレの殿堂入りは、「角度は一度刻みで0から90の91段階」の>>43と、
sin/cosテーブルをわざわざ0しかない整数部まで持つと言った>>69が双璧かな

その前の>>68もまあ実経験のない薄っぺらい妄想丸出しが見て取れるので、>>69と同一人物だろう
新年初(嘲)笑いにどうぞ…
0080ナイコンさん
垢版 |
2021/01/03(日) 09:33:58.34
角度と速度で持つわけないよ
dx,dyを毎割込みx,yに足す方式のほうが計算簡単だし
壁に当たってはねかえる(dxまたはdyをマイナスにする)放物線を描いてジャンプする(dyに毎割込み重力加速度を足す)といった動きが簡単に実現できる
0083ナイコンさん
垢版 |
2021/01/03(日) 20:49:48.97
あと乗算に時間かかるのはその通りだが

x2→左シフト
x4→左シフト２回
x3→左シフト+元の数
x1.5→右シフト+元の数

のような高速な代用手段がよく使われる
0085ナイコンさん
垢版 |
2021/01/04(月) 11:06:20.48
>>80
dx,dyを計算するのに必要。
複雑な動きをしないとか親子関係オブジェクトとか追尾とかない、至極単純なゲームなら構わないが。
0086ナイコンさん
垢版 |
2021/01/04(月) 11:07:50.74
>>83
乗数が固定ならね。
0087ナイコンさん
垢版 |
2021/01/04(月) 22:39:33.21
>>85
sinテーブルが必要じゃないと言ってるんじゃなく
>>69の言うようにオブジェクトのワークで(角度・スピード)の形で持つことはまずなく(dx,dy)の形がほとんどだと言ってる
またスピードの異なるsinテーブルも不要でひとつのテーブルからシフト演算でx1.5x1.25程度なら作れるので
自機と敵の弾程度の速度差だったらこれで十分
0088ナイコンさん
垢版 |
2022/05/08(日) 23:16:45.34
ジャイアント馬場「アニメジャナイ」
0089ナイコンさん
垢版 |
2022/12/04(日) 09:46:53.00
秋元康さんこんにちは(´･ω･`)っ
0090ナイコンさん
垢版 |
2023/05/21(日) 09:31:19.00
ここだっったのか
0091ナイコンさん
垢版 |
2023/05/24(水) 03:19:05.58
>>50-51
そうじゃなくて、右から３文字目の横にコンマを挿入すれば済む、
っていう話をしてるんだと思うよ
0093ナイコンさん
垢版 |
2023/05/27(土) 19:07:51.45
これ美麗映像のHDD録画推奨のマスト回だったんだな
0095ナイコンさん
垢版 |
2023/07/29(土) 22:08:31.91
>>94
わからんほどじゃないが、まー確かに一人で悦に入ってるような記事ではあるな。
Z80 の DAA は、8ビット演算をした直後じゃないとちゃんと機能しないから、
普段の計算で BCD に必要な処理もやってるんじゃないかな。それ用のフラグもあるっぽいし。
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況