初期のファミコンゲームなどを解析してると面白い。

お金などを管理するのに
たとえば9999だと
09090909と4バイトも使ってたりしてる。
ファミコンでその冗長的な方法は許されないと思うが
社内で誰もそのおかしさを指摘できる人がいない、そんな幸せな1980年代。

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

　今まで天才チンパンジー「アイちゃん」の言語訓練へ並々ならぬ
ご理解とご放置を賜り、誠にありがとうございます。
さて、このたびは「アイちゃん」に関する大きな発見を致しましたので
報告をさせていただきます。
すでに>>1の書き込みを見て気づかれている方もおられるでしょうが、
「アイちゃん」が夢を見ていることが証明される形となりました。
以前から、夢を見ているという推測はなされていたのですが、
今回の件はそれを証明する大きな発見となりました。
　これからもより一層のご理解とご放置をお願いいたします。


　　　　　　　　　　　　　　　　　　京都大学霊長類研究所一同

チラシの裏級の独り言でスレ立てる人ってなんなの？
リアルで会話する相手がいないの？

16進数→10進数変換するルーチンを入れる容量すらなかったとか＜ちょっとありえないか

もしくは、お金や経験値等のパラメータって結局は画面表示しなくちゃならないわけで
「だったら10進で管理しておいて、表示するときに「0」のキャラコードにバイト単位で加算して表示すべきキャラコードを求めたほうが処理が速いじゃないか。
それでもなくても点数その他は常時表示しなければならない情報＝必ず毎フレーム通る部分なんだから、そんなところでただでさえ非力なCPUの処理時間を増やしてられないだろ」
と考えた、とかじゃないのかなあ

もっともその点数なりなんなりを何で表示するんだという問題もありそうだけど
スプライト枚数は圧倒的に少ないからたぶんBGで表示、となると一度BG-RAM？にキャラコードを書き込んでおけば毎フレーム処理しなきゃいけないわけでもないよな…
いや、やっぱり処理速度の問題じゃないだろうか。ファミコンのCPUのレジスタ構成がどうなってるかは知らないけど、たぶん16→10進変換を書いたら意外に処理時間を食ってしまう貧相な仕様だったんだろうファミコンで作ってないから知らないけど

今のわけえもんは2進化10進数も知らないのか

せっかくだから個人的にちょっと気になってる件も調べてくれないだろうか？>>1
アクションゲームで「ジャンプ」する仕様があるじゃない。マリオとか色々あるけど
アレをどんな実装で実現してるのか、どういう方法が多いのかが昔から気になってるんだ…

個人的に固定小数点＋加減速でジャンプさせるのが好みなんだけど(容量が少なくて済む気がする)
ファミコン時代からずっとやってた会社の先輩は「絶対にテーブルで座標値を持つべきだ」と発言してた
実際はどっちの方法が多いんだろう？ それぞれどんなメリット・デメリットがあると思う？

>>6
しらない。

16進数だと9999を表示するときに10で割ったり、10の除算の余りの演算をやらないといけないからでしょ
表示を考えると16進数で持つよりも、4バイト使う方が効率的だよ

>>6
ファミコンのCPUは、BCD回路は省略されてたような。

表示は楽になるかもしれないけど
加減算処理は面倒にならない？

09090909ってのは画面表示用のキャラクタ値（のオフセット）だろ
>>1が何を解析したのかは知らんがおそらく別のアドレスに
内部でお金として扱っている16ビット値があるはず

いやけっこうあるよ

>>12
ファミコンってワークとして使えるRAMが少ないんじゃないの？どのくらいだかしんないけど
なのにわざわざ「本当の値」と「表示用の値」を別々にワークに持つだろうか…？
「本当の値」と「表示用の値」の両方に使える持ち方・値の管理方法があるなら
俺ならそっちを選びそうな気がするけど

でも今度はプログラム側の容量が増えちゃうような気もする

>>14
じゃ16進→10進をどこで計算するんだよｗ

そもそもファミコンのレジスタは8bitだぞ

アンポンタンの>>1は逃げ出したのか？

8*8で64ビット化するツインドライブシステムとか、トランザムじゃ
ないか？Linux的には。

>>15
あーなるほどー
お金とか体力とか全部最初から10進で格納されてたら
16進→10進変換は不要＝プログラム側の容量は全然増えないのか
(パラメータを16進でユーザに知らせることが要求される場面って、まず無いし…)

キャラの座標値とかは10進で表示する場面がないから
最初から終わりまで16進で扱えばいいし…
RAM・ROM容量が少ないファミコンだからこそ
10進で各種数値を持つことは効果があるのですね？

この手法は、現在の、メモリが贅沢にある環境だと
別の何かに使えそうな気がしてきました
たとえば 1bit を 1byte で格納しちゃうとか

どういう場面でチョー便利になるのか
プログラミング初心者だから判りませんけど

馬鹿は発言しなくていい。

気になって検索してみたら
bitをbyteで持つことで、bit単位での圧縮？符号化？する処理のパフォーマンスを向上させる
という手法は既にあるのですね…
(しかしスゲー容量のメモリを使いそう…
でも部分部分に分けて・ブロックに分けて処理をすれば速度と容量のバランスが取れのかな)

>>21
ヒントが一切含まれない煽りは、煽ってる本人も同様もしくはそれより酷い無知であることを周囲に晒すので
少し違う煽り方を工夫したほうがいいように思いますよ

私には、貴方が、「そんなアホなやり方あるわけねえだろ」と思ってた、と見えてます
「○○とかではもうやってんだよ馬鹿」と書いてくれれば「わあ、この人物知りだ。スゲエ」と感心したでしょうに
貴方は馬鹿ですね

さむい

それにしても、
そこだけ見れば容量が少なくなるからと言って、特に考えず16進で値を持つと、かえって容量が増えてしまう・処理速度がかかってしまう場面もあるとは…
目先のことに囚われず、トータルで見て優劣を考える、そういう視点がプログラミングには時として必要なのだと言うことを、ファミコンのプログラムを通じて教えてくれた>>1に感謝します

「なんでこうしてるんだろ変じゃないか」
「はたしてこんな方法もあるのだろうか」
と疑問を呈してくれる存在は、良い存在ですね
自身の知識量を何も明らかにすることなく、他者の無知ぶりをただ詰るだけの発言を繰り返す、そんな人間よりも、よほど人の役に立つ存在でしょう

例え自分の知識・考えが間違っていても、どんどん疑問を呈するべきなのでしょうね
受け手が賢ければ、その疑問からスレを発展させ、様々な知識を皆で共有できる状態を実現してくれるのですから
受け手が賢ければ…

日曜の真昼間にこんなところに書き込んでる時点で
馬鹿でさむくてぜんぜん賢くねえけどな

>>25
いや、俺には馬鹿でさむくてぜんぜん賢くねえとは思えない。
むしろなるほどなと思うぞ。

>>19
変換は不要だけど、10進同士の四則演算は別途コーディングする必要があるぞ。
CPUがBCD演算サポートしてなければ。

まあ４バイト使ったほうが楽だな。

BCDだって変換処理はあるわけだけど、16で割る（＝シフト）で済むので
10で割るより速度はだいぶ違うだろうね
除算をサポートしてるCPUならコード量はあんまし変わらないと思うけど

そこだけ見れば有意義に見えるレスでもトータルで見たら殆ど無意味なレスってのもあるよね。

>>6
ドラえもんの亜種かと思った

>>1
復活の呪文とかをいじって、所持金額を変える奴がいるからじゃないの？その対策じゃね？

>>27
ﾀﾞﾒｰｼﾞ算出とかだと乗除が出てきそうだけど
ｹﾞｰﾑ中での お金管理程度なら 加減算だけあれば目的に達するんじゃね？

実装の手間と有限なﾘｿｰｽとの鬩ぎ合いなんだろうな

変換処理の実行回数

BCDで保存しておく場合、数値の増減の回数に等しい。

16進数で保存しておく場合、表示するフレーム数に等しい。
秒間３０フレームなら、１秒表示すれば３０回は呼び出される。

>>1

文字フォントに変換するのが楽