JP3941702B2

JP3941702B2 - 画像処理装置

Info

Publication number: JP3941702B2
Application number: JP2003023444A
Authority: JP
Inventors: 佳司吉田
Original assignee: Yamaha Corp
Current assignee: Yamaha Corp
Priority date: 2003-01-31
Filing date: 2003-01-31
Publication date: 2007-07-04
Anticipated expiration: 2023-01-31
Also published as: JP2004233747A

Description

【０００１】
【発明の属する技術分野】
この発明は、描画性能の向上を図った画像処理装置に関する。
【０００２】
【従来の技術】
パチンコやテレビゲーム等においては、スプライト（小画像）を使用した画像表示がしばしば行われる。図７はスプライトを使用した画像表示装置の構成を示すブロック図であり、この図において、符号１はＣＰＵ（中央処理装置）、２は画像処理装置、３は圧縮されたスプライトのパターンが記憶されたパターンＲＯＭ、４は液晶等による表示装置である。画像処理装置２はＣＰＵ１からの指示を受け、パターンＲＯＭ３からスプライトパターンを読み出し、読み出したパターンをデコード（伸張）して圧縮前のスプライトパターンに戻し、内部のスプライトバッファに展開する。次いで、スプライトバッファからパターンを読み出し、拡大、縮小、回転、変形等のレンダリング処理を行って内部のフレームバッファに描画する。次いで、描画したパターンデータを表示装置４の水平／垂直走査タイミングに合わせて読み出し、表示装置４へ出力する。従来のスプライトによる表示処理に関する先行技術文献として特許文献１〜３が知られている。
【０００３】
【特許文献１】
特開2002-16810号公報
【特許文献２】
特開2002-112263号公報
【特許文献３】
特開2002-341859号公報
【０００４】
【発明が解決しようとする課題】
ところで、従来の画像処理装置においては、スプライトパターンをスプライトバッファに展開する処理と、展開されたパターンに対するレンダリング処理を行ってフレームバッファの所定位置に描画する処理を同期化して行っていたため、どちらか遅い方の処理がボトルネックとなり描画性能を低下させていた。
本発明は上記事情を考慮してなされたもので、その目的は、描画性能の向上を図った画像処理装置を提供することにある。
【０００５】
【課題を解決するための手段】
この発明は上記の課題を解決するためになされたもので、請求項１に記載の発明は、所定サイズのブロック単位で圧縮されて記憶された画像データであって、複数ブロックで１つの画像パターンを構成する画像データをパターンメモリから読み出す第１の読出手段と、前記第１の読出手段によって読み出されたブロック単位の画像データをデコードして圧縮前の画像データに戻すデコーダと、ファーストイン・ファーストアウトメモリとして機能し、書き込み、読み出しを同時に実行できない記憶手段であって、前記デコーダによってデコードされた画像データを複数の画像パターン分展開できる容量を有し、読み出しより書き込み処理が優先される第１の記憶手段と、前記デコーダによってデコードされた画像データを前記第１の記憶手段に書き込む書込手段と、前記第１の記憶手段から前記画像データを読み出す第２の読出手段と、フレームバッファとして機能し、書き込み、読み出しを同時に実行できない記憶手段であって、書き込みより読み出し処理が優先される第２の記憶手段と、前記第２の読出手段によって読み出された前記画像データに所定の処理を行って前記第２の記憶手段に書き込む制御手段と、前記第２の記憶手段から画像データを読み出し、表示装置へ出力する表示手段とを具備し、前記書込手段および前記第２の読出手段が、前記第１の記憶手段をファーストイン・ファーストアウトメモリとして読出／書込制御することを特徴とする画像処理装置である。
【０００６】
請求項２に記載の発明は、スプライトの属性が記憶された属性テーブルと、前記属性テーブル内のデータに基づいて、所定サイズのブロック単位で圧縮されたスプライト画像データであって、複数ブロックで１つの画像パターンを構成する画像データをパターンメモリから読み出す第１の読出手段と、前記第１の読出手段によって読み出されたブロック単位の画像データをデコードして圧縮前のスプライト画像データに戻すデコーダと、ファーストイン・ファーストアウトメモリとして機能し、書き込み、読み出しを同時に実行できない記憶手段であって、前記デコーダによってデコードされた画像データを複数の画像パターン分展開できる容量を有し、読み出しより書き込み処理が優先される第１の記憶手段と、前記デコーダによってデコードされたスプライト画像データを前記第１の記憶手段に書き込む書込手段と、前記第１の記憶手段から前記スプライト画像データを読み出す第２の読出手段と、フレームバッファとして機能し、書き込み、読み出しを同時に実行できない記憶手段であって、書き込みより読み出し処理が優先される第２の記憶手段と、前記第２の読出手段によって読み出されたスプライト画像データに前記属性テーブル内のデータに基づく所定の処理を行って前記第２の記憶手段に書き込む制御手段と、前記第２の記憶手段からスプライト画像データを読み出し、表示装置へ出力する表示手段とを具備し、前記書込手段および前記第２の読出手段が、前記第１の記憶手段をファーストイン・ファーストアウトメモリとして読出／書込制御することを特徴とする画像処理装置である。
【０００７】
請求項３に記載の発明は、請求項２または請求項３に記載の画像処理装置において、前記制御手段における所定の処理は、画像データの拡大、縮小、回転、変形等のレンダリング処理であることを特徴とする。
【０００８】
【発明の実施の形態】
以下、図面を参照し、この発明の実施の形態について説明する。図１はこの発明の一実施の形態による画像処理装置１１の構成を示すブロック図である。この図において、符号１３はスプライト属性テーブルであり、スプライト属性データがＣＰＵ（図示略）によって登録される。ここで、スプライト属性データには、パターンＲＯＭ３内のスプライトパターンの格納アドレス、パターンの拡大、縮小、回転、変形等を決めるパラメータ、表示位置を指示するデータ等がある。１４はデコードコントローラであり、パターンＲＯＭ３内の圧縮されたスプライトパターンのデコード処理を制御する。１５はＲＯＭインターフェイスであり、パターンＲＯＭ３へ読出アドレスを出力し、パターンＲＯＭ３から読み出されたパターンデータをデコーダ１６へ出力する。
【０００９】
デコーダ１６はパターンＲＯＭ３から読み出されたパターンデータのデコード（伸張処理）を行ってスプライトバッファインターフェイス１７へ出力する。スプライトバッファインターフェイス１７は、デコーダ１６から出力されるスプライトパターンをスプライトバッファ１８に展開する。また、レンダリングエンジン２１からの指示を受けてスプライトバッファ１８内のパターンデータを読み出し、レンダリングエンジン２１へ出力する。ここで、スプライトバッファ１８は複数のスプライトパターンを展開できる容量をもっている。２０はレンダリングコントローラであり、スプライト属性テーブル１３内のスプライト属性データを読み出し、読み出した属性データをレンダリングエンジン２１へ出力する。
【００１０】
レンダリングエンジン２１は、レンダリングコントローラ２０の指示に従ってスプライトバッファ１８から読み出されたパターンデータのレンダリング処理を行い、その処理済みのデータをフレームバッファインターフェイス２２へ出力する。フレームバッファインターフェイス２２はレンダリングエンジン２１から出力されるパターンデータをフレームバッファ２３に描画する。また、ディスプレイコントローラ２５からの指示を受けてフレームバッファ２３からパターンデータを読み出し、ディスプレイコントローラ２５へ出力する。フレームバッファ２３は表示装置４の表示ドット対応でパターンデータが書き込まれるメモリであり、ダブルバッファ構成となっている。ディスプレイコントローラ２５は画像表示のための各種のタイミング信号を生成して表示装置４へ出力し、また、フレームバッファ２３から読み出されたパターンデータをそのタイミング信号に同期させて表示装置４へ出力する。
【００１１】
次に、上述した画像処理装置１１の動作を図２および図３に示すフローチャートを参照して説明する。
デコードコントローラ１４は、まず、スプライト属性テーブル１３にアクセスし、パターンＲＯＭ３のスプライト格納アドレスを取得する（図２のステップＳａ１）。次に、取得したアドレスをＲＯＭインターフェイス１５へ出力し、１ブロックの読み出しを指示する。ここで、１ブロックは１６×１６ドットのデータであり、スプライトパターンは通常ｎ（ｎ：１より大きい整数）ブロックのデータによって構成されている。上記の指示を受けたＲＯＭインターフェイス１５は、パターンＲＯＭ３から１ブロックのパターンデータを読み出し、デコーダ１６へ出力する。デコーダ１６はそのパターンデータのデコードを行う（ステップＳａ２）。そして、１ブロックのデコードが終了すると（ステップＳａ３）、スプライトを構成するの全ブロックのデコードが終了したか否かをチェックし（ステップＳａ４）、終了していない場合は、ＲＯＭインターフェイス１５が次のブロックの読み出しを行い、読み出されたパターンデータがデコーダ１６によってデコードされる（ステップＳａ２）。
【００１２】
以下、上述した動作が繰り返えされ、最初のスプライトを構成する全ブロックのデコードが終了すると（ステップＳａ４がＹＥＳ）、再びステップＳａ１へ戻り、次のスプライトの格納アドレスをスプライト属性テーブル１３から読み出す。以後、上記と同様にして次のスプライトパターンのデコード処理が行われる。
【００１３】
一方、デコーダ１６において１ブロックのデコード処理が終了すると、スプライトバッファインターフェイス１７によってデコード終了後のパターンデータがスプライトバッファ１８に展開される（ステップＳａ５）。ここで、スプライトバッファ１８はＦＩＦＯ（ファーストイン・ファーストアウト）メモリとして機能し、ブロック単位でパターンデータが順次展開される。スプライトバッファインターフェイス１７は、まず、スプライトバッファ１８がＦＵＬＬの状態にあるか否かをチェックし（ステップＳａ６）、否であった場合に展開を実行する（ステップＳａ７）。
【００１４】
そして、１ブロックの展開が終了すると（ステップＳａ８）、全ブロックの展開が終了したか否かをチェックし、終了していない場合（ステップＳａ９がＮＯ）、再び、ステップＳａ５へ戻り、次のブロックのデコードが終了するのを待って、そのブロックのパターンデータをスプライトバッファ１８に展開する。また、全ブロックの展開が終了した場合は（ステップＳａ９がＹＥＳ）ステップＳａ１へ戻る。
このように、スプライトバッファ１８には、パターンＲＯＭ３内のスプライトパターンがブロック単位でデコードされた後、ＦＩＦＯ方式で順次展開される。
【００１５】
次に、フレームバッファ２３の描画処理について図３を参照して説明する。
レンダリングコントローラ２０は、スプライト属性テーブル１３から、スプライトパターンの拡大、縮小、回転、変形等を決めるパラメータ、表示位置を指示するデータ等のスプライト属性データを読み出し（ステップＳｂ１）、レンダリングエンジン２１へ出力する。レンダリングエンジン２１は、レンダリングコントローラ２０から受けたパラメータに基づいて初期パラメータの計算を行う（ステップＳｂ２）。次に、スプライトバッファ１８がＥＭＰＴＹであるか否かをチェックし（ステップＳｂ３）、ＥＭＰＴＹでない場合は、描画処理を行う（ステップＳｂ４）。
【００１６】
すなわち、まず、スプライトバッファインターフェイス１７へスプライトパターンの読み出しを指示する。スプライトバッファインターフェイス１７は、その指示を受け、スプライトバッファ１８からレンダリングエンジン２１で属性データに基づいて計算された座標（アドレス）に該当するデータを読み出し、レンダリングエンジン２１へ出力する。レンダリングエンジン２１は、そのデータをレンダリングコントローラ２０から受けた表示位置を示すデータと共にフレームバッファインターフェイス２２へ出力する。フレームバッファインターフェイス２２は、そのパターンデータを、表示位置データに対応するアドレスに描画する（ステップＳｂ４、Ｓｂ５）。
【００１７】
フレームバッファ２３への描画処理は、回転、変形等の処理があるため、スプライトバッファ１８のＥＭＰＴＹの確認はスプライト単位で判断している。スプライト１個の全体のイメージがスプライトバッファ１８に展開されていないと、描画処理を開始できない。そして、スプライトの全描画が終了すると（ステップＳｂ６がＹＥＳ）、ステップＳｂ１へ戻り、レンダリングコントローラ２０が次のスプライトの属性データをスプライト属性テーブル１３から読み出す。そして、読み出した属性データに基づいて次のスプライトの描画処理が行われる。
【００１８】
このように、スプライトバッファ１８の読み出しは、書き込みと非同期で行われる。すなわち、スプライトバッファ１８は、前述したように複数のスプライトパターンを展開できる容量をもっており、そのスプライトバッファ１８を１６×１６ドットを１ブロックとする単位でＦＩＦＯ化することにより、ＦＩＦＯがＦＵＬＬにならない限りフレームバッファ２３の描画終了を待たずに次のスプライトのパターンデータをデコードしてスプライトバッファ１８に展開することができる。また、レンダリングコントローラ２０はＦＩＦＯがＥＭＰＴＹでなければフレームバッファ２３へ描画を継続することができる。これにより、パターンＲＯＭ３内のパターンデータのデコード処理とフレームバッファ２３の描画処理の時間の違いを考慮することなくそれぞれの処理を行うことができ、この結果、描画処理能力を向上させることができる。
【００１９】
次に、図４〜図６を参照しフレームバッファ２３の書き込み／読み出し動作を詳述する。
フレームバッファ２３に描画するためには、スプライトバッファ１８からパターンデータを読み出す必要がある。スプライトバッファインターフェイス１７では、デコーダ１６におけるデコード処理を止めないように、スプライトバッファ１８の展開アクセスを優先する。したがって、展開アクセスが行われていない時間においてスプライトバッファ１８のパターンデータの読み出しが行われる。このため、スプライトバッファ１８に展開している期間はフレームバッファ２３の描画はできない。
【００２０】
一方、フレームバッファインターフェイス２２においては、表示装置４の画面にノイズを出さないため、フレームバッファ２３の表示アクセス（すなわち、読み出しアクセス）が優先される。したがって、表示アクセス期間においては、フレームバッファ２３の描画を行うことができない。
【００２１】
このように、フレームバッファ２３の描画は、スプライトバッファ１８の展開アクセスの期間およびフレームバッファ２３の表示アクセスの期間の双方において実行できず、このため、描画性能が悪い問題があった。そこで、この実施形態においては、フレームバッファ２３の表示アクセス期間をスプライトバッファ１８の展開アクセス期間に合わせる（同期させる）ことによって両アクセスを同じ期間において行うようにし、これにより、フレームバッファの描画性能の向上を図っている。
【００２２】
以下、図４〜図６を参照して詳述する。図４はダブルバッファとして構成されているフレームバッファ２３の表示／描画切換動作を示すタイミングチャートであり、図においてV-BLANKNはフレーム周期のタイミングを示し、BANK0はダブルバッファの一方を、BANK1は他方を示している。この図に示すように、BANK0とBANK1は１フレームの表示が行われる毎に表示・描画・表示・・・と切り換えられる。なお、BANK0とBANK1のバスラインは共通であり、このため、ダブルバッファ構成であっても描画と表示（読出）を同時に行うことはできない。また、ダブルバッファ構成としているのは、描画期間を１フレームとるためであり、所定フレームの表示中においてその内容が書き換えられるのを防ぐためである。また、この実施形態はシングルフレームバッファ構成の場合も適用可能である。
【００２３】
図５はフレームバッファ２３の表示アクセスのタイミングを説明するためのタイミングチャートであり、HDSPは１ラインの水平表示期間を示し、”Ｌ”レベルの期間が水平非表示期間を示している。表示アクセスは、表示装置４の画面の次のラインに表示するデータを現在のラインの表示期間の終了のタイミング（すなわち、水平非表示期間の開始タイミング）でディスプレイコントローラ２５からフレームバッファインターフェイス２２にリクエストされる（図５のDSPREQ）。１ライン分の表示データは次のラインの表示期間の開始時点までにフレームバッファから読み出されることが必要である。一方、スプライトバッファ１８の展開アクセスは、例外を除いて、水平非表示期間に最低１回は発生する。そこで、フレームバッファインターフェイス２２は、ディスプレイコントローラ２５からのリクエストを待機させておき、スプライトバッファ１８の展開アクセスのタイミング（図５のOPENREQ）の立ち上がり時点から表示アクセス（図５のDSPACK）を開始する。
【００２４】
これにより、スプライトバッファ１８の展開アクセスと、フレームバッファ２３の表示アクセスを同期させることができる。スプライトバッファ１８の展開アクセスの期間とフレームバッファ２３の表示アクセスの期間がほぼ等しい場合、両者の終了タイミングもほぼ等しくなり、終了直後から滞りなくフレームバッファ２３への描画を再開することが可能となる。
【００２５】
他方、スプライトバッファ１８の展開アクセスが発生しない状態で、水平表示期間の開始時点から逆算して１ライン分の表示データを読み出せるタイミングとなった場合、フレームバッファインターフェイス２２はスプライトバッファ１８の展開アクセスの有無にかかわらずフレームバッファ２３の表示アクセスを強制的に実行する。図６はこの場合のタイミングチャートであり、DSPLIMITが表示アクセスの強制実行のタイミングを示している。これにより、例外的にスプライトバッファ１８の展開アクセスがなかった場合も、間違いなくフレームバッファ２３の表示アクセスを実行することができる。
【００２６】
【発明の効果】
以上説明したように、この発明によれば、第１の記憶手段（スプライトバッファ）をファーストイン・ファーストアウトメモリとして読出／書込制御するようにしたので、圧縮された画像データのデコード処理と、第２の記憶手段（フレームバッファ）の書込処理の時間の違いを考慮することなくそれぞれの処理を行うことができ、この結果、描画処理能力を向上させることができる。
【図面の簡単な説明】
【図１】この発明の一実施形態による画像処理装置の構成を示すブロック図である。
【図２】同実施形態の動作を説明するためのフローチャートである。
【図３】同実施形態の動作を説明するためのフローチャートである。
【図４】同実施形態におけるフレームバッファ２３の描画／表示タイミングを示すタイミングチャートである。
【図５】同実施形態におけるフレームバッファ２３の表示タイミングを説明するためのタイミングチャートである。
【図６】同実施形態におけるフレームバッファ２３の表示タイミングを説明するためのタイミングチャートである。
【図７】スプライトを使用した画像表示装置の構成を示すブロック図である。
【符号の説明】
３…パターンＲＯＭ、４…表示装置、１１…画像処理装置、１３…スプライト属性テーブル、１４…デコードコントローラ、１５…ＲＯＭインターフェイス、１６…デコーダ、１７…スプライトバッファインターフェイス、１８…スプライトバッファ、２０…レンダリングコントローラ、２１…レンダリングエンジン、２２…フレームバッファインターフェイス、２３…フレームバッファ、２５…ディスプレイコントローラ。

Claims

所定サイズのブロック単位で圧縮されて記憶された画像データであって、複数ブロックで１つの画像パターンを構成する画像データをパターンメモリから読み出す第１の読出手段と、
前記第１の読出手段によって読み出されたブロック単位の画像データをデコードして圧縮前の画像データに戻すデコーダと、
ファーストイン・ファーストアウトメモリとして機能し、書き込み、読み出しを同時に実行できない記憶手段であって、前記デコーダによってデコードされた画像データを複数の画像パターン分展開できる容量を有し、読み出しより書き込み処理が優先される第１の記憶手段と、
前記デコーダによってデコードされた画像データを前記第１の記憶手段に書き込む書込手段と、
前記第１の記憶手段から前記画像データを読み出す第２の読出手段と、
フレームバッファとして機能し、書き込み、読み出しを同時に実行できない記憶手段であって、書き込みより読み出し処理が優先される第２の記憶手段と、
前記第２の読出手段によって読み出された前記画像データに所定の処理を行って前記第２の記憶手段に書き込む制御手段と、
前記第２の記憶手段から画像データを読み出し、表示装置へ出力する表示手段と、
を具備し、前記書込手段および前記第２の読出手段が、前記第１の記憶手段をファーストイン・ファーストアウトメモリとして読出／書込制御することを特徴とする画像処理装置。
スプライトの属性が記憶された属性テーブルと、
前記属性テーブル内のデータに基づいて、所定サイズのブロック単位で圧縮されたスプライト画像データであって、複数ブロックで１つの画像パターンを構成する画像データをパターンメモリから読み出す第１の読出手段と、
前記第１の読出手段によって読み出されたブロック単位の画像データをデコードして圧縮前のスプライト画像データに戻すデコーダと、
ファーストイン・ファーストアウトメモリとして機能し、書き込み、読み出しを同時に実行できない記憶手段であって、前記デコーダによってデコードされた画像データを複数の画像パターン分展開できる容量を有し、読み出しより書き込み処理が優先される第１の記憶手段と、
前記デコーダによってデコードされたスプライト画像データを前記第１の記憶手段に書き込む書込手段と、
前記第１の記憶手段から前記スプライト画像データを読み出す第２の読出手段と、
フレームバッファとして機能し、書き込み、読み出しを同時に実行できない記憶手段であって、書き込みより読み出し処理が優先される第２の記憶手段と、
前記第２の読出手段によって読み出されたスプライト画像データに前記属性テーブル内のデータに基づく所定の処理を行って前記第２の記憶手段に書き込む制御手段と、
前記第２の記憶手段からスプライト画像データを読み出し、表示装置へ出力する表示手段と、
を具備し、前記書込手段および前記第２の読出手段が、前記第１の記憶手段をファーストイン・ファーストアウトメモリとして読出／書込制御することを特徴とする画像処理装置。
前記制御手段における所定の処理は、画像データの拡大、縮小、回転、変形等のレンダリング処理であることを特徴とする請求項１または請求項２に記載の画像処理装置。