2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん:2009/10/05(月) 12:57:48
お金などを管理するのに
たとえば9999だと
09090909と4バイトも使ってたりしてる。
ファミコンでその冗長的な方法は許されないと思うが
社内で誰もそのおかしさを指摘できる人がいない、そんな幸せな1980年代。

2 :デフォルトの名無しさん:2009/10/05(月) 13:10:42
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

                  京都大学霊長類研究所

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


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

4 :デフォルトの名無しさん:2009/10/05(月) 20:38:33
チラシの裏級の独り言でスレ立てる人ってなんなの?
リアルで会話する相手がいないの?

5 :デフォルトの名無しさん:2009/10/05(月) 22:25:00
16進数→10進数変換するルーチンを入れる容量すらなかったとか<ちょっとありえないか

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

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

6 :デフォルトの名無しさん:2009/10/05(月) 22:31:27
今のわけえもんは2進化10進数も知らないのか

7 :デフォルトの名無しさん:2009/10/05(月) 22:33:01
せっかくだから個人的にちょっと気になってる件も調べてくれないだろうか?>>1
アクションゲームで「ジャンプ」する仕様があるじゃない。マリオとか色々あるけど
アレをどんな実装で実現してるのか、どういう方法が多いのかが昔から気になってるんだ…

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

8 :デフォルトの名無しさん:2009/10/05(月) 22:52:35
>>6
しらない。

9 :デフォルトの名無しさん:2009/10/06(火) 00:00:20
16進数だと9999を表示するときに10で割ったり、10の除算の余りの演算をやらないといけないからでしょ
表示を考えると16進数で持つよりも、4バイト使う方が効率的だよ

10 :デフォルトの名無しさん:2009/10/06(火) 01:38:10
>>6
ファミコンのCPUは、BCD回路は省略されてたような。

11 :デフォルトの名無しさん:2009/10/06(火) 03:13:20
表示は楽になるかもしれないけど
加減算処理は面倒にならない?

12 :デフォルトの名無しさん:2009/10/06(火) 03:39:16
09090909ってのは画面表示用のキャラクタ値(のオフセット)だろ
>>1が何を解析したのかは知らんがおそらく別のアドレスに
内部でお金として扱っている16ビット値があるはず

13 :デフォルトの名無しさん:2009/10/06(火) 11:14:58
いやけっこうあるよ


14 :デフォルトの名無しさん:2009/10/06(火) 13:19:35
>>12
ファミコンってワークとして使えるRAMが少ないんじゃないの?どのくらいだかしんないけど
なのにわざわざ「本当の値」と「表示用の値」を別々にワークに持つだろうか…?
「本当の値」と「表示用の値」の両方に使える持ち方・値の管理方法があるなら
俺ならそっちを選びそうな気がするけど

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

15 :デフォルトの名無しさん:2009/10/06(火) 14:53:40
>>14
じゃ16進→10進をどこで計算するんだよw


16 :デフォルトの名無しさん:2009/10/06(火) 21:56:03
そもそもファミコンのレジスタは8bitだぞ

17 :デフォルトの名無しさん:2009/10/11(日) 03:17:13
アンポンタンの>>1は逃げ出したのか?

18 :デフォルトの名無しさん:2009/10/11(日) 04:38:54
8*8で64ビット化するツインドライブシステムとか、トランザムじゃ
ないか?Linux的には。

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

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

20 :デフォルトの名無しさん:2009/10/11(日) 11:38:50
この手法は、現在の、メモリが贅沢にある環境だと
別の何かに使えそうな気がしてきました
たとえば 1bit を 1byte で格納しちゃうとか

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

21 :デフォルトの名無しさん:2009/10/11(日) 12:49:54
馬鹿は発言しなくていい。

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

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

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

23 :デフォルトの名無しさん:2009/10/11(日) 13:37:27
さむい

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

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

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

25 :デフォルトの名無しさん:2009/10/11(日) 13:46:35
日曜の真昼間にこんなところに書き込んでる時点で
馬鹿でさむくてぜんぜん賢くねえけどな

26 :デフォルトの名無しさん:2009/10/11(日) 16:04:06
>>25
いや、俺には馬鹿でさむくてぜんぜん賢くねえとは思えない。
むしろなるほどなと思うぞ。

27 :デフォルトの名無しさん:2009/10/11(日) 16:08:28
>>19
変換は不要だけど、10進同士の四則演算は別途コーディングする必要があるぞ。
CPUがBCD演算サポートしてなければ。

28 :デフォルトの名無しさん:2009/10/11(日) 16:23:45
まあ4バイト使ったほうが楽だな。


29 :デフォルトの名無しさん:2009/10/11(日) 22:14:43
BCDだって変換処理はあるわけだけど、16で割る(=シフト)で済むので
10で割るより速度はだいぶ違うだろうね
除算をサポートしてるCPUならコード量はあんまし変わらないと思うけど

30 :デフォルトの名無しさん:2009/10/15(木) 10:28:43
そこだけ見れば有意義に見えるレスでもトータルで見たら殆ど無意味なレスってのもあるよね。

31 :デフォルトの名無しさん:2009/10/17(土) 11:05:54
>>6
ドラえもんの亜種かと思った

32 :デフォルトの名無しさん:2010/06/09(水) 11:19:34
>>1
復活の呪文とかをいじって、所持金額を変える奴がいるからじゃないの?その対策じゃね?

33 :デフォルトの名無しさん:2010/06/09(水) 11:48:19
>>27
ダメージ算出とかだと乗除が出てきそうだけど
ゲーム中での お金管理程度なら 加減算だけあれば目的に達するんじゃね?

実装の手間と有限なリソースとの鬩ぎ合いなんだろうな

34 :デフォルトの名無しさん:2010/06/09(水) 12:11:33
変換処理の実行回数

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

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

11 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)