[
最新
] ■[
前年
|
前月
|
前日
|
2016/12/02
|
翌日
|
翌月
|
翌年
] ■表示[
全て
|
@gorry5のみ
|
個別
]
■グループ[
Mention
] ■その他[
Twitter:@gorry5
][
日記
] ■[
twtlog 20100921a
]
12/02 01:31
@yukizokin
3D描画の場合、当時の水平型GRAMにとっては「Y座標の算出速度」の差は、「横方向の描画に必要なビットマスクなどの計算」にかかるコストと比べると大したことにはならんです…実際、88mkIIあたりまでとの比較ならX1のほうが有利だったわけで
(tagi)
--------
12/02 01:32
(
@yukizokin
)
@gorry5
そうでした。プレーンマップだったのを、うっかり忘れてしまいます。
(tabu)
--------
12/02 01:35
(
@yukizokin
)
@gorry5
GORRYさんの超超高速ペイントルーチンもやっぱり、y軸のアドレス計算はテーブル化してたのですか?
(tite)
12/02 02:04
(
@yukizokin
)
@gorry5
あれ、『Y座標の算出』ですか。さっきコードを書いていて、アドレステーブル化よりずっと遅くなりそうで断念しました。エレガントなアルゴリズムがあったら教えてください。
(tere)
12/02 02:13
@yukizokin
あれは「b0-b10がテキストVRAMの配列と同一」「b11-13が1キャラクタ内のラインを示すオフセット」「b14-15がプレーン」とすると、テキストとグラフィックの合成ハードウェアに都合のいい構成になるんですよ
(tosu)
12/02 02:34
@yukizokin
本来「CRTCはテキストVRAMにアクセスし、その内容に従ってCGROMをアクセスしてピクセルを出力」するところ、X1は「CGROMに相当する部分にCGROMとPCGとGRAMが繋がっていて、条件分けで切り替えつつアクセスする」ことで合成を実現しています
(naku)
12/02 02:35
@yukizokin
なお、X1初代の回路図でこのへんの構造は読むことができます
URL:www.x1center.org
(nasi)
■グループ[
Mention
] ■その他[
Twitter:@gorry5
][
日記
] ■[
twtlog 20100921a
]
[
最新
] ■[
前年
|
前月
|
前日
|
2016/12/02
|
翌日
|
翌月
|
翌年
] ■表示[
全て
|
@gorry5のみ
|
個別
]