アカウント名:
パスワード:
どうもよく分からんのだけど……。単純な最近傍補間の話だよね？だったら、小数点演算とかLUTに頼らず、DDAでやるのが定石じゃないのかな。
# 的外れなコメントだったら、申し訳ないです。
>、小数点演算とかLUTに頼らず、DDAでやるのが定石
禿同と言うか全く仰る通りでそれ ( 系な事 ) をビット操作でシミュるのが今回の主旨で回路図後半のこの記述
> * LS(AS/F/ALS/S/HCT/N)306 × 2 的回路挿入 → 拡縮度 31 ( 拡大率 2.0 ) まで処理 ?
は拡大方法の一例なのですがつまり縮小メインな処理だが予め拡大しておくその縮小 ( 間引き ) 法則それがカウンタ IC 出力結果とのパラメータ比較です( そのパラメータは前述の通り LUT 無しに動的生成されたものです )
回転処理が絡んで来ると LUT 頼みな高速性が欲しくなるかも知れませんが
ここにぶら下げるのが適切なのか分かりませんが
> * アドレス挿げ替え成功時 → 準コプロとして半ダイレクト拡縮 ?
アドレス挿げ替えというのはシャドーイング ( 的なもの ) の事で例としては本体起動時に IPL-ROM が先頭領域に現れる感じの小細工です
回路図コメントにある通り T ( G ) -RAM なりの特定領域に書込みなりした際にそれを拾って PCG をその時に動的拡縮してスプライトVRAM へハードウェア高速転送できないかと目論んでいます ( 単にアドレスバスをショートさせるだけですが未経験な方法 )
# -DTACK 発生前に単に挿げ替えればそれでいいという前提で暫定設計してみます
この拡縮回路自体は内部クロック 4 サイクル程度で処理完了しますので回路図デフォの 100 MHz 水晶の場合ならばOutside X68000 P.64 のタイミング表を見る限りX68k 10 MHz の 1 サイクルに間に合う場合も充分想定出来ると皮算用しています( 回路図中> * シフトピクセル数生成 ( 0 ( 1 ) - 3 ( 4 ) )
の段の LUT 動的生成部分は内部 1 サイクルを経ずにその場で処理完了≒ ハードワイアド LUT 回路 )
又回路図中の 20 MHz で代用してある部分を 50 MHz にせずとも拡縮処理自体は X68k 10 MHz の 2 サイクル程度しかかけていませんのでmove 命令のサイクルには矢張り充分間に合うでしょう( X68k シリーズの格チップは 74AS シリーズ程度には高速か )
当回路では贅沢にもアドレス値それ自体で拡縮パラメータを表現していますのでベストケースでは move 命令 3 回だけで元データ 16 ビット分のスプライトデータを縮小出来る事になろうかと皮算用していますが例えば 1/5 縮小の場合は単純計算で 5 回の縮小回路稼働が必要でありその場合は 2 × 5 + 1 = 11 内部クロックが最低限必要ですがどう最悪な転び方をしようとも move 命令のサイクルには充分間に合うでしょう
> 例えば 1/5 縮小の場合は単純計算で 5 回の縮小回路稼働が必要であり> その場合は 2 × 5 + 1 = 11 内部クロックが最低限必要ですが> どう最悪な転び方をしようとも move 命令のサイクルには充分間に合うでしょう
これは所謂デカキャラ ( 若者言葉 ) に付いてなのですが現状では拡縮一回毎にソフトウェア転送が必要なので内部サイクル 11 回でなく68k MPU レベルの move なり 11 回が必要です申訳ありません訂正させて下さい# 慌てて執筆するとおかしな勘違いをして碌な事にならないと身に染みている筈だったのに# 申訳ないやら悔しいやら
但しと言うか勿論スプライト一つだけならば拡縮 1 回だけで済みます( ピクセルを左シフトして体裁を整える ( 中央寄せ他 ) 場合は回路図最後辺りのコメント通り更にダミー拡縮 1 回が必要ですこの時には ( ヒネり無しで考えると ) 例えば敵弾の様な透明部分を把握済なスプライトパターンを指定する必要がありますがその指定をミドルウェア経由で半自動でと予定しています )
便宜上スプライトパレット領域に擬えての説明となります
スプライトパレットスロット 1 本毎に拡縮率を割り振ってあり現状ですと縮小のみをサポートしているので一言で言えばパレットスロット 0 番が拡縮率 0 ( 縮小率 15 ) に対応しており表示ピクセル数は 1 ピクセルのみと最小表示 ( 最高縮小 ) となり又パレットスロット 15 番つまり最終スロットが拡縮率 15 ( 縮小率 0 ) に対応しており表示としては拡縮なし状態となります
その際には縮小演算回路としては真面目に処理して拡縮なしとなりますのでここをハードウェアレベルでフックして別の演算に割当てるという構想は回路図コメントの通りです
同様にパレットスロット 0 番から 3 番までは単に 4 ビット × 例えば 4 ピクセル分を取出すたけですし回路規模の点からハードウェアレベルサポートを省略してあるので矢張り回路図コメント通りにゆくゆくは別のハードウェア演算に割当てたい所です( bfins / bfffo 命令支援回路等 )
>その縮小 ( 間引き ) 法則それがカウンタ IC 出力結果とのパラメータ比較
ここは一見分かり難いのですが回路図投稿冒頭例の様に縮小 ( 間引き ) 法則を固定してしまってあるのでそれに合わせた間引回路となっています# BG 向けとまでは言えない回路ですがスプライトには向いていて# しかも処理コストが小さい回路ではなかろうかと思います
第二ビットと第三ビットを入換えているのはシフト回数に単純比例した位置のピクセルを間引いてしまうと縮小処理というよりも単なる削取り処理になってしまうのでそれを防ぎつつ最大限違和感ない間引パターンを生成する為です( 4ビット単位処理なのでそのやり方を適用出来ました )
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
拡縮 (スコア:0)
どうもよく分からんのだけど……。
単純な最近傍補間の話だよね？
だったら、小数点演算とかLUTに頼らず、DDAでやるのが定石じゃないのかな。
# 的外れなコメントだったら、申し訳ないです。
Re:拡縮 (スコア:2)
>、小数点演算とかLUTに頼らず、DDAでやるのが定石
禿同と言うか全く仰る通りでそれ ( 系な事 ) をビット操作でシミュるのが今回の主旨で
回路図後半のこの記述
> * LS(AS/F/ALS/S/HCT/N)306 × 2 的回路挿入 → 拡縮度 31 ( 拡大率 2.0 ) まで処理 ?
は拡大方法の一例なのですがつまり縮小メインな処理だが予め拡大しておく
その縮小 ( 間引き ) 法則それがカウンタ IC 出力結果とのパラメータ比較です
( そのパラメータは前述の通り LUT 無しに動的生成されたものです )
回転処理が絡んで来ると LUT 頼みな高速性が欲しくなるかも知れませんが
謝々々々 台湾宮廷料理海味館 名●屋市熊の前二丁目 ( MiniStop 対面 )
ハードウェア転送 (スコア:2)
ここにぶら下げるのが適切なのか分かりませんが
> * アドレス挿げ替え成功時 → 準コプロとして半ダイレクト拡縮 ?
アドレス挿げ替えというのはシャドーイング ( 的なもの ) の事で
例としては本体起動時に IPL-ROM が先頭領域に現れる感じの小細工です
回路図コメントにある通り T ( G ) -RAM なりの特定領域に書込みなりした際に
それを拾って PCG をその時に動的拡縮してスプライトVRAM へハードウェア高速転送
できないかと目論んでいます ( 単にアドレスバスをショートさせるだけですが未経験な方法 )
# -DTACK 発生前に単に挿げ替えればそれでいいという前提で暫定設計してみます
謝々々々 台湾宮廷料理海味館 名●屋市熊の前二丁目 ( MiniStop 対面 )
高速性 (スコア:2)
この拡縮回路自体は内部クロック 4 サイクル程度で処理完了しますので
回路図デフォの 100 MHz 水晶の場合ならば
Outside X68000 P.64 のタイミング表を見る限り
X68k 10 MHz の 1 サイクルに間に合う場合も充分想定出来ると皮算用しています
( 回路図中
> * シフトピクセル数生成 ( 0 ( 1 ) - 3 ( 4 ) )
の段の LUT 動的生成部分は内部 1 サイクルを経ずにその場で処理完了
≒ ハードワイアド LUT 回路 )
又回路図中の 20 MHz で代用してある部分を 50 MHz にせずとも
拡縮処理自体は X68k 10 MHz の 2 サイクル程度しかかけていませんので
move 命令のサイクルには矢張り充分間に合うでしょう
( X68k シリーズの格チップは 74AS シリーズ程度には高速か )
当回路では贅沢にもアドレス値それ自体で拡縮パラメータを表現していますので
ベストケースでは move 命令 3 回だけで
元データ 16 ビット分のスプライトデータを縮小出来る事になろうか
と皮算用していますが
例えば 1/5 縮小の場合は単純計算で 5 回の縮小回路稼働が必要であり
その場合は 2 × 5 + 1 = 11 内部クロックが最低限必要ですが
どう最悪な転び方をしようとも move 命令のサイクルには充分間に合うでしょう
謝々々々 台湾宮廷料理海味館 名●屋市熊の前二丁目 ( MiniStop 対面 )
Re:高速性 (スコア:2)
> 例えば 1/5 縮小の場合は単純計算で 5 回の縮小回路稼働が必要であり
> その場合は 2 × 5 + 1 = 11 内部クロックが最低限必要ですが
> どう最悪な転び方をしようとも move 命令のサイクルには充分間に合うでしょう
これは所謂デカキャラ ( 若者言葉 ) に付いてなのですが
現状では拡縮一回毎にソフトウェア転送が必要なので
内部サイクル 11 回でなく68k MPU レベルの move なり 11 回が必要です
申訳ありません訂正させて下さい
# 慌てて執筆するとおかしな勘違いをして碌な事にならないと身に染みている筈だったのに
# 申訳ないやら悔しいやら
但しと言うか勿論スプライト一つだけならば拡縮 1 回だけで済みます
( ピクセルを左シフトして体裁を整える ( 中央寄せ他 ) 場合は
回路図最後辺りのコメント通り更にダミー拡縮 1 回が必要です
この時には ( ヒネり無しで考えると ) 例えば敵弾の様な透明部分を把握済なスプライトパターン
を指定する必要がありますがその指定をミドルウェア経由で半自動でと予定しています )
謝々々々 台湾宮廷料理海味館 名●屋市熊の前二丁目 ( MiniStop 対面 )
シフトピクセル数を生成する回路部分の補足など (スコア:2)
便宜上スプライトパレット領域に擬えての説明となります
スプライトパレットスロット 1 本毎に拡縮率を割り振ってあり
現状ですと縮小のみをサポートしているので
一言で言えばパレットスロット 0 番が拡縮率 0 ( 縮小率 15 ) に対応しており
表示ピクセル数は 1 ピクセルのみと最小表示 ( 最高縮小 ) となり又
パレットスロット 15 番つまり最終スロットが拡縮率 15 ( 縮小率 0 ) に対応しており
表示としては拡縮なし状態となります
その際には縮小演算回路としては真面目に処理して拡縮なしとなりますので
ここをハードウェアレベルでフックして別の演算に割当てるという構想は
回路図コメントの通りです
同様にパレットスロット 0 番から 3 番までは単に 4 ビット × 例えば 4 ピクセル分
を取出すたけですし回路規模の点からハードウェアレベルサポートを省略してあるので
矢張り回路図コメント通りにゆくゆくは別のハードウェア演算に割当てたい所です
( bfins / bfffo 命令支援回路等 )
謝々々々 台湾宮廷料理海味館 名●屋市熊の前二丁目 ( MiniStop 対面 )
Re:拡縮 (スコア:2)
>その縮小 ( 間引き ) 法則それがカウンタ IC 出力結果とのパラメータ比較
ここは一見分かり難いのですが回路図投稿冒頭例の様に縮小 ( 間引き ) 法則を
固定してしまってあるのでそれに合わせた間引回路となっています
# BG 向けとまでは言えない回路ですがスプライトには向いていて
# しかも処理コストが小さい回路ではなかろうかと思います
第二ビットと第三ビットを入換えているのは
シフト回数に単純比例した位置のピクセルを間引いてしまうと
縮小処理というよりも単なる削取り処理になってしまうのでそれを防ぎつつ
最大限違和感ない間引パターンを生成する為です
( 4ビット単位処理なのでそのやり方を適用出来ました )
謝々々々 台湾宮廷料理海味館 名●屋市熊の前二丁目 ( MiniStop 対面 )