マシン語ゲームで小数が使われていたか否か語るスレ
>>43
0〜255の256段階だと8ビットレジスタぴったりでキリが良くて演算が楽になるからだよ XY入れ替え&符号反転の組み合わせでぐるり1周を8分割できる。
弧の8分の1の部分(0度〜45度)だけを256分割すると約0.18度刻みになる(ゲームだと精度たかすぎ?
1周を256分割してXY入れ替えも符号反転もしなければ、約1.4度刻みになる
シューティングゲームなら、データ量をとるか処理速度をとるかのトレードオフだとおもうけど、1周256分割してそのまま座標つかうほうが良いような気がする。
256は8で割りきれるから縦横斜めが誤差なく表現できるので人間の目に対する違和感が出ないだろうし。 1980年頃のパソコンでは、実数型コンパイラを売っていたのはシャープMZだけかと思いましたが、
ほかにおもちゃメーカーのバンダイ(現バンダイナムコ)が出していた「RX-78ガンダム」という名前のパソコンには、実数型コンパイラ(カセットテープ5万円)がオプションで販売されていました!
https://blog.goo.ne.jp/2645751/e/1a679fe2fb1695d938bfee96a917ebe6 64倍とか256倍で計算して、あとでシフトするのがCPU的には楽だろ。いわゆる固定小数点実数。 100倍とか1000倍とか言ってるのは機械語やってない人や固定小数演算を知らない人に向けて分かりやすく説明してるだけだと思うぞ BCDで小数点情報他に持っといて計算する感じかな? >>51
このスレでそんなことに気を使う必要があるんだろうか。 あるのよ
そもそもこのスレが立つ原因になった奴が固定少数知らないしプログラムやってたかも怪しいから >>55
8ビット機のシューティングで小数点なんて要らないだろとか言ってて笑ったよな >>51
シフトくらいわかってるよ。だいたいだよ。今は使わないし >>50
その程度は本人たちはそれを固定小数点だと思ってなくても、
小中学生でも思いついてやってたレベルなんだよな。コード上は小数点は出てこないから。 8bitマシン語ゲームで実数の乗算、除算が使われていた!!! →コードは単にレジスタをシフトしてるだけ。 シフトしたら小数点の位置が移動するので固定じゃない!!! 整数16bitx16bitの仮想画面として計算して、
表示するときに実画面のサイズに縮小した、と考えても同じコードになるな。 >>51
スレタイでマシン語と明記しているので、100倍とか90度とか言っちゃう奴は単に未経験の馬鹿だと思いますよ。 パソコンゲームのソフトハウスは、ゲーム機やMSXなどスプライトを持つ機種に進出した例外を除き、位置をバイト単位での計算しかしなかった時期が長い。プレーンVRAMを採用した機種が主流だったので仕方ないことたが。
アーケードやスプライトマシンはもちろんバイト単位ではなくドット単位で指定するのだが、計算までドット単位でしていては大雑把な動きになってしまう。ここで登場するのが固定少数での計算。
他にも1intでは処理が収まらないから全体ループの後にタイミング調整したり、タスク管理や親子構造などが無かったり、80年代のパソコンゲームのテクニックはガラパゴス化していた。
それでもパソコンゲームのほうが進んでた分野をあげるとするなら、シナリオスクリプトコンパイラがある。 移動キャラが移動するために必要な情報は、現在位置と角度と速度。
ファミコンとかMSXとかPCエンジンの低解像度モードなら256あれば良いので、位置情報は2バイト。上位バイトが実数、下位バイトが小数にすれば処理は速い。スプライトの位置レジスタに設定するのは上位バイトのみ。
あとは360度を256段階で刻んだ1バイトの角度情報と、2バイト固定少数の速度情報がいる。
あとは2バイト×256個のSINCOSテーブルを用意。
角度からテーブルの三角関数値を得て、速度と乗算して現在の位置座標に加算する。
問題はZ80Aや6502 1.7MHzでは遅くて乗算がネックになること。仕方ないので速度を数段階にわけて、三角関数の値を調節したテーブルを数個持ち、乗算の部分を端折る。
速度を細かく分けるほどテーブルは肥大化するので、ケースバイケース。 sinテーブル(実際はcosテーブル)は0.0〜1.0の小数になるので、テーブルは小数部1バイトのみでいい
68k機で実数/小数各16bitの場合でもcosテーブルは小数のみ16bit
さらに「360度を256分割」はさすがに荒いので、ベクトルベースの演算が必要な場合は
「90度を256分割」、残りの象限は反転とXY入れ替えで対応できる
低解像度の2Dアクションやシューティング等でせいぜい32方向くらいなら、
sin/cosなど使わず最初から移動量ベースでテーブル化
まあ>>69はこの通り最適化も足りてないし、現役世代の経験談ではない薄っぺらい妄想、ということはわかる 当時sin(cos)テーブルを作るのに、なぜかBASICの実数演算を使ってASCIIファイルに吐かせる…という謎な作業をした思い出
BASIC使ったのはそれが最後くらいだな XかYレジスタに角度が入っていればSINもCOS1命令で済む6502が最強 ゼロページって言ったっけ?、0〜ffhはレジスタ代わりに高速アクセスできるんでしょ。 余程単純なゲームじゃなきゃsincosテーブルは必須。 このスレの殿堂入りは、「角度は一度刻みで0から90の91段階」の>>43と、
sin/cosテーブルをわざわざ0しかない整数部まで持つと言った>>69が双璧かな
その前の>>68もまあ実経験のない薄っぺらい妄想丸出しが見て取れるので、>>69と同一人物だろう
新年初(嘲)笑いにどうぞ… 角度と速度で持つわけないよ
dx,dyを毎割込みx,yに足す方式のほうが計算簡単だし
壁に当たってはねかえる(dxまたはdyをマイナスにする)放物線を描いてジャンプする(dyに毎割込み重力加速度を足す)といった動きが簡単に実現できる あと乗算に時間かかるのはその通りだが
x2→左シフト
x4→左シフト2回
x3→左シフト+元の数
x1.5→右シフト+元の数
のような高速な代用手段がよく使われる Z80なら左シフトよりADD A,AかADD HL,HLだな >>80
dx,dyを計算するのに必要。
複雑な動きをしないとか親子関係オブジェクトとか追尾とかない、至極単純なゲームなら構わないが。 >>85
sinテーブルが必要じゃないと言ってるんじゃなく
>>69の言うようにオブジェクトのワークで(角度・スピード)の形で持つことはまずなく(dx,dy)の形がほとんどだと言ってる
またスピードの異なるsinテーブルも不要でひとつのテーブルからシフト演算でx1.5x1.25程度なら作れるので
自機と敵の弾程度の速度差だったらこれで十分 >>50-51
そうじゃなくて、右から3文字目の横にコンマを挿入すれば済む、
っていう話をしてるんだと思うよ これ美麗映像のHDD録画推奨のマスト回だったんだな この人のBCDの説明が下手すぎて腹立ったわww
https://days-of-programming.blogspot.com/2020/05/picbcd-2.html
Z80のDAA命令はたった4クロックで2桁を処理してくれるなんて万能すぎる
PICマイコンにも入れてほしかった >>94
わからんほどじゃないが、まー確かに一人で悦に入ってるような記事ではあるな。
Z80 の DAA は、8ビット演算をした直後じゃないとちゃんと機能しないから、
普段の計算で BCD に必要な処理もやってるんじゃないかな。それ用のフラグもあるっぽいし。