| Re: 改行対応DrawFormatString ( No.4 ) |
- 名前：丈槍由紀 日時：2016/03/03 21:34
もしできることならば、タブ文字の対応もしてくれると嬉しいです
|
| Re: 改行対応DrawFormatString ( No.5 ) |
- 名前：夢幻ノ月夜 日時：2016/03/06 10:53
\nと\tに反応して改行するようにしてくれると信じてます
|
| Re: 改行対応DrawFormatString ( No.6 ) |
- 名前：管理人 日時：2016/03/07 01:55
お待たせしました、改行に対応したバージョンをアップしましたので
よろしければこちらをダウンロードして下さい m(_ _)m
https://dxlib.xsrv.jp/temp/DxLibVCTest.exe // VisualC++ 用
https://dxlib.xsrv.jp/temp/DxLibBCCTest.exe // BorlandC++ 用
https://dxlib.xsrv.jp/temp/DxLibGCC_DevCppTest.exe // Dev-C++ 用
https://dxlib.xsrv.jp/temp/DxLibGCC_MinGWTest.exe // MinGW 用
https://dxlib.xsrv.jp/temp/DxLibDotNet.zip // .NET用
https://dxlib.xsrv.jp/temp/DxLibMakeTest.exe // ソース
(中身を既存のライブラリのファイルに上書きして、BCCをお使いの
場合は『再構築』を、VCをお使いの場合は『リビルド』を、
Dev-C++をお使いの方は「Rebuild All(Ctrl+F11)」をして下さい)
> yumetodoさん
> 折り返し幅を引数で渡せると嬉しいです
SetFontLineSpace と SetFontLineSpaceToHandle という関数で行間のピクセル数を指定できるようにしました
// デフォルトフォントハンドルの字間を変更する
int SetFontSpace( int Pixel ) ;
// フォントハンドルの行間を変更する
int SetFontLineSpaceToHandle( int Pixel, int FontHandle ) ;
> (その場合は何行になったかを何らかの方法で知りたいです)。
GetDrawStringWidth の機能を強化した GetDrawStringSize を追加しました
// デフォルトフォントハンドルを使用した文字列の描画幅・高さ・行数を取得する
int GetDrawStringSize( int *SizeX, int *SizeY, int *LineCount, const TCHAR *String, int StrLen, int VerticalFlag = FALSE ) ;
// フォントハンドルを使用した文字列の描画幅・高さ・行数を取得する
int GetDrawStringSizeToHandle( int *SizeX, int *SizeY, int *LineCount, const TCHAR *String, int StrLen, int FontHandle, int VerticalFlag = FALSE ) ;
引数 LineCount で行数を取得できます
> 丈槍由紀さん
> もしできることならば、タブ文字の対応もしてくれると嬉しいです
ＤＸライブラリの文字列描画はテキストエディタのように「文字数」単位の描画位置決定ではないので
タブ対応すると Office Word のように
『タブ１つが文字『B』では6文字分だけど、スペース文字では8文字分、小文字の『a』では7文字分』
のようなことになり、テキストエディタ的な文字数基準のタブだと思われる方は混乱してしまいますし、
フォントが変わって文字幅が変わるとタブの位置が変わってしまったりと実用的ではないので
申し訳ありませんが対応は見送らせてください m(_ _;m
> 夢幻ノ月夜さん
> \nと\tに反応して改行するようにしてくれると信じてます
\n だけに反応して改行するようにしました
\t はタブを意味するのですが、なぜ改行なのでしょうか？
 |
| Re: 改行対応DrawFormatString ( No.7 ) |
- 名前：だみあん 日時：2016/03/08 05:46
>> 折り返し幅を引数で渡せると嬉しいです(その場合は何行になったかを何らかの方法で知りたいです)。
> SetFontLineSpace と SetFontLineSpaceToHandle という関数で行間のピクセル数を指定できるようにしました
行間の幅の話ではなく既定の文字数もしくは行全体の幅（px）を越えると自動で改行の意味なのでわ？
それはさておき質問なのですが。
1.
DrawString(0, 0, _T("あいうえお\nかきくけこ\nさしすせそ\n"), -1);
2.
DrawString(0, 0, _T("あいうえお"), -1);
DrawString(0, 20, _T("かきくけこ"), -1);
DrawString(0, 40, _T("さしすせそ"), -1);
この場合、1の場合は複数行分を一括で一度に描画するので、
2の行数回分DrawStringに比べて低コスト。
とか描画コスト的に有利だったりするのでしょうか？（改行処理のコストは無視して、描画速度だけの話です）
だとするなら、大量の行数の文字列を一括で低コストに描画する機能として、別の存在意義が出てくるのですが。
単に内部で描画開始位置を算出して行数分DrawStringしてるだけのラッパーなのでしょうか？？
そして今回の機能追加についてなのですが。
現状では自前で改行処理などを行っている場合、
そのあとにまたライブラリ側で改行文字を走査する処理が入ってしまう感じになってしまいますよね。
DrawString系自体に改行処理が付加されるのは、すでに必要のない改行処理が何度も行われ好ましくない感じです……。
少ない文字数なら気にならないレベルなのかもしれませんが、大量の文字を一度に描画する時には
結構影響出るような気がするので。（改行文字検索に文字列全走査しますよね
なので単純に一行単体の関数で改行付の文字描画できるのも、
それはそれでちょっと使う分には使い勝手は良さそうですが
できればDrawString系とは別関数として改行処理付文字描画関数がある方がうれしいのです……。
（それにそもそもDrawString系に折り返しの文字数指定の引数追加するのは無理でしょうし）
そこで改行処理と文字描画は分離しているかんじで
出力用文字のテキストバッファのような物とかどうでしょうか。
デバッグ出力のように表示領域をあらかじめ指定して、そこに文字を追加していき、
任意のタイミングで一括描画のような感じです。
文字チャットとか、ドラクエ風のメッセージ表示のようなイメージです。
バッファの中身はクリアするまで残り続ける形で。
以下適当に妄想。関数名とかそれっぽいの適当につけました。
// 文字数指定（行数, 一行の最大文字幅)してバッファを作成
// この場合５行*２０文字のバッファ
// 最大文字幅越えると自動改行。最大行数越えたら頭の行が消える
// 三番目の引数は改行文字検出を行うかの設定（自前で事前に改行処理を行っている場合な何もしないを選択出来る様に）
int textBufferHandle = MakeTextBuffer(5, 20, TRUE) ;
// 行間(px)指定などはハンドルに対して行う感じ
SetStringBufferLineSpace(textBufferHandle, 5 );
// バッファの中身初期化
ClearTextBuffer(textBufferHandle);
// この処理は毎フレーム行うのでなく、文字登録時や文字変更時のみ行う
{
// 文字をバッファに登録 ToHandle版も
// Put〜は末尾に改行自動挿入 Apennd〜は末尾改行追加無し
PutTextBuffer(textBufferHandle, _T("あいうえお\nかきくけこ"), -1); // 一行目、二行目
AppendTextBuffer(textBufferHandle, _T("さしすせそ"), -1); // 三行目になる
AppendTextBuffer(textBufferHandle, _T("たちつてと"), GetColor(255,0,0));// 三行目"さしすせそ"の後ろに文字色を赤で追加
}
// (0，0)を描画開始位置にして、ここで画面に全行一括描画
DrawTextBuffer(0, 0, textBufferHandle);
こんな形だと現在の行数、描画範囲（px）なども文字列を再指定せずハンドル経由で取得できますし
文字の走査の部分と描画を分けたことで、自前で字句解析など行って改行処理などしている場合も
最終的な文字出力のみバッファに登録という形にするだけで競合しません。
文字数での強制改行や、行の途中の文字色変更とかにも対応できます。
また各種オプション設定もハンドルに対して行う感じになるので
DrawString実行時に適用される設定をグローバルな関数・変数で設定変更する方法にくらべ
影響範囲が限定的で済みますし。
余談ですが、既定文字数越えたら自動改行は、日本語の場合、
行頭、行末の禁則処理なんかも必要になると思います。
あとは一括して最後に文字描画位置を算出する形になるので
アライメント指定で中央添えや右添え等の処理をするのなんかも簡単にできるかと。
ＤＸライブラリにあわせてＣ言語ライクな感じで書いてみましたが
クラスを使えるのであれば、バッファはstlのコンテナで持っている感じで
バッファに対して直接appendとかpush_front、push_backといったコンテナ系共通のメソッド名で
操作出来るほうのが直感的ではあるのですが。
ていうかこれ普通にprintfDxの豪華版なだけですね……。
個人的には、改行処理等の字句解析処理と描画処理が分かれていて
一括描画の部分で行数分DrawString行うのと比べて描画コストの軽減が見込めるのであれば
改行処理等は自前で行い、バッファ登録で一括描画処理だけ利用できる形にすれば
自前の処理と競合することなく描画コストの軽減のメリットだけ得られるなと思ったりして。
一括描画での描画コストの軽減が見込めないのではれば、現行の自前処理のままで
ＤＸライブラリ側の改行処理は使わないだけで済みますし。
と言う感じで、DrawStringに無駄なコスト追加はちょっと……。
複数行一括描画で高速化見込めるならその部分だけ利用したい。
といった所です。
|
| Re: 改行対応DrawFormatString ( No.8 ) |
- 名前：丈槍由紀 日時：2016/03/08 17:47
管理人さん
>ＤＸライブラリの文字列描画はテキストエディタのように「文字数」単位の描画位置決定ではないので
>タブ対応すると Office Word のように
>『タブ１つが文字『B』では6文字分だけど、スペース文字では8文字分、小文字の『a』では7文字分』
>のようなことになり、テキストエディタ的な文字数基準のタブだと思われる方は混乱してしまいますし、
>フォントが変わって文字幅が変わるとタブの位置が変わってしまったりと実用的ではないので
>申し訳ありませんが対応は見送らせてください m(_ _;m
あちゃ、等幅フォントのことしか考えていませんでした
なるほど確かにそれだと使いづらくなってしまうかもしれませんね。。。
\tが入ったら指定のピクセル数の倍数になるまで字間をあける、みたいな感じにできたら
デバッグ描画などが見やすくなると思ったのですが、、
|
| Re: 改行対応DrawFormatString ( No.9 ) |
- 名前：Sura 日時：2016/03/09 02:04
私も、だみあん様の意見に賛成です。
フルスクリーン上でのデバック作業なんかに重宝します。printfDxの強化版としたほうが良いように思います。
例えば、デバッグ情報が多すぎて画面に表示できないときなど、文字バッファが生きていれば、スクロール処理などで確認できるし、
だみあん様のご指摘のように、余計な負荷は望ましくないように思います。
|
| Re: 改行対応DrawFormatString ( No.10 ) |
- 名前：管理人 日時：2016/03/09 02:28
> だみあんさん
> 行間の幅の話ではなく既定の文字数もしくは行全体の幅（px）を越えると自動で改行の意味なのでわ？
なるほど、言われてみればその通りですね、勘違いしてしまいました
> 1.
> DrawString(0, 0, _T("あいうえお\nかきくけこ\nさしすせそ\n"), -1);
>
> 2.
> DrawString(0, 0, _T("あいうえお"), -1);
> DrawString(0, 20, _T("かきくけこ"), -1);
> DrawString(0, 40, _T("さしすせそ"), -1);
>
> この場合、1の場合は複数行分を一括で一度に描画するので、
> 2の行数回分DrawStringに比べて低コスト。
> とか描画コスト的に有利だったりするのでしょうか？
はい、計測してみましたが10%ほどCPU負荷は低いようです
> 現状では自前で改行処理などを行っている場合、
> そのあとにまたライブラリ側で改行文字を走査する処理が入ってしまう感じになってしまいますよね。
厳密な比較はまだできていませんが、簡易的な計測結果では1〜2%程負荷がアップしていました
> できればDrawString系とは別関数として改行処理付文字描画関数がある方がうれしいのです……。
改行文字に対応しているだけで別の関数にしてしまうと関数が大量に増えてしまうので
それはちょっとできません…
> そこで改行処理と文字描画は分離しているかんじで
> 出力用文字のテキストバッファのような物とかどうでしょうか。
すみません、今回「改行文字くらいは対応してもいいかな」と思って改行文字に対応しましたが、
本格的なレイアウトに対応できるテキスト描画機能を整備するつもりはありません
ただ、「複数の文字列をまとめて描画して負荷軽減」は有効そうなので、その内実装するかもしれません
> yumetodoさん、丈槍由紀さん、Suraさん
すみません、今まで一切制御文字に対応していなかった状態で改行文字に対応すると言うことの意味を
よく考えていませんでした、少し考えれば当たり前なのですが、改行文字に対応するのならタブ文字にも、
タブ文字にも対応するのなら自動改行にも、自動改行に対応するのならついでに行末の禁則処理にも、
となるのは当然ですよね…
ただ、私の中で文字列描画のレイアウト機能に着手する気になったというわけでもなく、軽い気持ちで
「改行文字くらいには対応していたほうがいいかな？」と思っただけなので、申し訳ありませんが
今回は「改行文字に対応した」以上のことはしない方向でいこうと思います
|
| Re: 改行対応DrawFormatString ( No.11 ) |
- 名前：だみあん 日時：2016/03/09 04:37
> はい、計測してみましたが10%ほどCPU負荷は低いようです
なんと、やはり高速化が見込めるのですか。
個人的にはこの部分が一番気になっていたので。
> 厳密な比較はまだできていませんが、簡易的な計測結果では1〜2%程負荷がアップしていました
改行処理自体は微々たるもの……ですか。
ＤＸライブラリの現在の仕様では内部コードはwchar_t=utf-16で、
サロゲートペアがらみの処理も入ってるようなので
結局文字全走査の処理は常に入ってる……？。
そしてそのついでに改行処理もというなら、改行処理うんぬんも
特別それだけで負荷になっている感じでも無かったりするのでしょうか。
> すみません、今回「改行文字くらいは対応してもいいかな」と思って改行文字に対応しましたが、
> 本格的なレイアウトに対応できるテキスト描画機能を整備するつもりはありません
結局そういう多機能な感じの物は
いろいろ追加でアレも欲しいコレも欲しいになってしまうので際限無くなってしまいますね……。
なのでその辺は自前でやるべき部分なのでしょうね。
> ただ、「複数の文字列をまとめて描画して負荷軽減」は有効そうなので、その内実装するかもしれません
改行処理以外でも、いろいろ文字周りの処理をすると
文字列を細切れに分割してそれぞれ個別にDrawStringすることになるので
これは是非とも欲しい機能です。
期待して待つことにします。
|
| Re: 改行対応DrawFormatString ( No.12 ) |
- 名前：yumetodo 日時：2016/03/14 01:59
>すみません、今まで一切制御文字に対応していなかった状態で改行文字に対応すると言うことの意味をよく考えていませんでした
ですよね。無茶めちゃハードル高い内容をさらっと「対応します」となって
「実は長年このためにコードを暖めていたのか？」
とか思いましたが、そんなことはなかった。
内部の文字コードをchar32_t型を使ってUTF-32にできればもうすこし楽だったんでしょうが、
そうするためにはその部分だけdll切り出しとかしないといけず(DxLibがターゲットとするコンパイラの殆どでchar32_t型が使えない)
やむを得ないところでしょうね。
ところでお伺いしたいのですが、
画面幅から文字をはみ出ないように制約をかける場合、
GetDrawStringWidthで描画した時の必要な長さを計算するしか無いと思うのですが、
現状だと、等幅フォントではない場合、長さがオーバーした時には一文字ずつ減らしながらGetDrawStringWidthで確認するという重そうな処理になってしまう気がします
(オーバした長さから文字数を決め打ちすればもうすこしましになると思いますが)。
これを、GetDrawStringWidthに文字数分(描画時の文字数、std::u32string::size()の戻り値)のsize_t型配列を引数経由で渡したら一文字ずつに要した文字の幅を書き込んでくれたりしないですかね？
(あれ、そういえばフォントハンドルのフォントが等幅か調べる関数あったっけ)
|
| Re: 改行対応DrawFormatString ( No.13 ) |
- 名前：へけぽん 日時：2016/03/15 06:40
横からすみません
リファレンスページのDrawFormatStringの説明に
＞流石に \t や \n のエスケープシーケンスを表現することは 出来ませんが、普通に使う分には問題無いはずです。
と、ありますが、今回の更新で\nでの改行だけは出来るようになったとの認識で間違いないのですよね？
説明文の修正をお願いしますm(_ _)m
|
| Re: 改行対応DrawFormatString ( No.14 ) |
- 名前：イヌイット 日時：2016/03/15 20:41
Dotnet版でDrawStringの動作確認をしたところ改行が機能していませんでした
確認お願いします
もう一つ、同様に日本語入力系の関数(KeyInputStringなど)の
改行対応版も用意していただけないでしょうか
今までの機能だけで複数行の入力をしようとしたところ、
各行ごとにハンドルを用意して、カーソル位置と左右キーの状態によって
入力先の行を切り替えるという煩雑な実装になっていたので、
実装をライブラリ側にお願いしたいです
Enterを押すしても中断されずに改行になり、
入力を中断するにはescで抜けるかGetKeyInputを呼ぶかしかないという仕様で結構です
|
| Re: 改行対応DrawFormatString ( No.15 ) |
- 名前：管理人 日時：2016/03/21 15:31
> yumetodoさん
> これを、GetDrawStringWidthに文字数分(描画時の文字数、std::u32string::size()の戻り値)の
> size_t型配列を引数経由で渡したら一文字ずつに要した文字の幅を書き込んでくれたりしないですかね？
ご希望に添えるかわかりませんが、機能を追加してみたバージョンをアップしましたので、
よろしければダウンロードしてください m(_ _)m
https://dxlib.xsrv.jp/temp/DxLibVCTest.exe // VisualC++ 用
https://dxlib.xsrv.jp/temp/DxLibBCCTest.exe // BorlandC++ 用
https://dxlib.xsrv.jp/temp/DxLibGCC_DevCppTest.exe // Dev-C++ 用
https://dxlib.xsrv.jp/temp/DxLibGCC_MinGWTest.exe // MinGW 用
https://dxlib.xsrv.jp/temp/DxLibDotNet.zip // .NET用
https://dxlib.xsrv.jp/temp/DxLibMakeTest.exe // ソース
(中身を既存のライブラリのファイルに上書きして、BCCをお使いの
場合は『再構築』を、VCをお使いの場合は『リビルド』を、
Dev-C++をお使いの方は「Rebuild All(Ctrl+F11)」をして下さい)
こんな関数を追加してみました
// デフォルトフォントハンドルを使用した文字列の１文字毎の情報を取得する
// InfoBuffer ： 文字の情報を格納する DRAWCHARINFO 構造体の配列への先頭アドレス、NULL でもOK
// String ： 情報を取得する文字列
// StrLen ： 情報を取得するサイズ( バイト数 )
// 戻り値：解析した文字数
int GetDrawStringCharInfo( DRAWCHARINFO *InfoBuffer, const TCHAR *String, int StrLen ) ;
// 描画文字列一文字の情報
struct DRAWCHARINFO
{
TCHAR Char[ 3 ] ; // 文字
BYTE Bytes ; // 文字のバイト数
float DrawX, DrawY ; // 描画位置
float SizeX, SizeY ; // 描画サイズ
} ;
ご所望の通り GetDrawStringWidth の戻り値を一文字単位で取得するような関数です
ただ、文字列のサイズの指定は文字数ではなくバイト数です、これは GetDrawStringWidth が
バイト単位なのにこちらは文字数単位だと統一感が無いな…と思ったからです…
あと、座標やサイズが float 型なのは、今回一緒に追加した以下の関数の内の拡大系の関数の関係です
( 計算結果に小数点以下の値を含むことがあるため )
// デフォルトフォントハンドルを使用した書式付き文字列の１文字毎の情報を取得する
int GetDrawFormatStringCharInfo( DRAWCHARINFO *InfoBuffer, const TCHAR *FormatString, ... ) ;
// デフォルトフォントハンドルを使用した文字列の１文字毎の情報を取得する
int GetDrawExtendStringCharInfo( DRAWCHARINFO *InfoBuffer, double ExRateX, double ExRateY, const TCHAR *String, int StrLen ) ;
// デフォルトフォントハンドルを使用した書式付き文字列の１文字毎の情報を取得する
int GetDrawExtendFormatStringCharInfo( DRAWCHARINFO *InfoBuffer, double ExRateX, double ExRateY, const TCHAR *FormatString, ... ) ;
// フォントハンドルを使用した文字列の１文字毎の情報を取得する
int GetDrawStringCharInfoToHandle( DRAWCHARINFO *InfoBuffer, const TCHAR *String, int StrLen, int FontHandle ) ;
// フォントハンドルを使用した書式付き文字列の１文字毎の情報を取得する
int GetDrawFormatStringCharInfoToHandle( DRAWCHARINFO *InfoBuffer, int FontHandle, const TCHAR *FormatString, ... ) ;
// フォントハンドルを使用した文字列の１文字毎の情報を取得する
int GetDrawExtendStringCharInfoToHandle( DRAWCHARINFO *InfoBuffer, double ExRateX, double ExRateY, const TCHAR *String, int StrLen, int FontHandle ) ;
// フォントハンドルを使用した書式付き文字列の１文字毎の情報を取得する
int GetDrawExtendFormatStringCharInfoToHandle( DRAWCHARINFO *InfoBuffer, double ExRateX, double ExRateY, int FontHandle, const TCHAR *FormatString, ... ) ;
> へけぽんさん
> 今回の更新で\nでの改行だけは出来るようになったとの認識で間違いないのですよね？
ご指摘ありがとうございます、修正しました m(_ _;m
> イヌイットさん
手元で Dotnet版を試してみましたが、問題なく改行されました
改行には \n のみ対応しているのですが、イヌイットさんはどのように確認されたのでしょうか？
> もう一つ、同様に日本語入力系の関数(KeyInputStringなど)の
> 改行対応版も用意していただけないでしょうか
MakeKeyInput に改行を許可するかどうかの引数を追加してみましたので、よろしければこちらを
ダウンロードしてください m(_ _)m
( KeyInputString など他の関数はエンターキーで決定の判定を行うので未対応です )
https://dxlib.xsrv.jp/temp/DxLibVCTest.exe // VisualC++ 用
https://dxlib.xsrv.jp/temp/DxLibBCCTest.exe // BorlandC++ 用
https://dxlib.xsrv.jp/temp/DxLibGCC_DevCppTest.exe // Dev-C++ 用
https://dxlib.xsrv.jp/temp/DxLibGCC_MinGWTest.exe // MinGW 用
https://dxlib.xsrv.jp/temp/DxLibDotNet.zip // .NET用
https://dxlib.xsrv.jp/temp/DxLibMakeTest.exe // ソース
(中身を既存のライブラリのファイルに上書きして、BCCをお使いの
場合は『再構築』を、VCをお使いの場合は『リビルド』を、
Dev-C++をお使いの方は「Rebuild All(Ctrl+F11)」をして下さい)
一番後ろの引数 EnableNewLineFlag を TRUE にするとエンターキーを押しても決定されず、改行になります
// 新しいキー入力ハンドルの作成
int MakeKeyInput(
int MaxStrLength,
int CancelValidFlag,
int SingleCharOnlyFlag,
int NumCharOnlyFlag,
int DoubleCharOnlyFlag = FALSE ,
int EnableNewLineFlag = FALSE
) ;
イヌイットさんの仰る通りエンターキーが改行になる事で MakeKeyInput としての「決定」の操作が
無くなりますので、自前で決定の処理を実装するようにしてください
因みに即興で複数行に対応したのでテキストエディタやブラウザの文字列入力フォームほどのクオリティは
ありません、恐らく操作していて「あれ？」と思う部分があると思いますが、大目にみてください m(_ _;m
( どう見てもバグだったり、どうしても許容できない点がありましたらご指摘ください )
|
| Re: 改行対応DrawFormatString ( No.16 ) |
- 名前：yumetodo 日時：2016/03/22 23:02
実験してみました。
gist.github.com/yumetodo/480ee94bbe530acc91ce
で、結果の前に
>int GetDrawStringCharInfoToHandle( DRAWCHARINFO *InfoBuffer, const TCHAR *String, int StrLen, int FontHandle ) ;
これ、だめですよね、InfoBufferへの書き込みがバッファーオーバーランしかねない気が。またIPAから突かれません？
size_t GetDrawStringCharInfoToHandle( DRAWCHARINFO *InfoBuffer, size_t InfoBufferSize, int FontHandle, const TCHAR *String, size_t StrLen);
size_t GetDrawStringCharInfoToHandle( DRAWCHARINFO *InfoBuffer, size_t InfoBufferSize, int FontHandle, const TCHAR *String);//StrLenはライブラリ側で
ですよね？byte列の長さと文字数は一致しませんし。
で実験結果ですが便利そうです。意地悪して_UNICODEをdefineしてさらにUnicodeの闇と名高い絵文字を使ってみましたが、
そもそもTCHARがwchar_tでも動いたんですね、DxLibって。
U+0031 U+20E3
ja.wikipedia.org/wiki/Unicode6.0の携帯電話の絵文字の一覧#.E4.B8.80.E8.A6.A7
はなんかぐちゃぐちゃになってますが(多分font側ではなくDxLib側の問題)ほかはちゃんと動いているようです。
|
| Re: 改行対応DrawFormatString ( No.17 ) |
- 名前：yumetodo 日時：2016/03/22 23:10
いや、
U+1F1EB U+1F1F7
もなんかおかしいか。ばらけとる。
|
| Re: 改行対応DrawFormatString ( No.18 ) |
- 名前：管理人 日時：2016/03/23 04:00
|
| Re: 改行対応DrawFormatString ( No.19 ) |
- 名前：yumetodo 日時：2016/03/23 15:26
>ご指摘の通りの引数を追加しました
どうもです。
>複数の文字で1文字を表す結合文字列については対応していません
あ、やっぱり。なんか残念だけど対応は簡単ではないので仕方ないか・・・。ただ将来対応することを見越すと
TCHAR Char[ 3 ] ; // 文字
3では足りない気が。こういう構造体って後から変え難いですし。UTF-8を考えると7とか9くらいの要素数が必要・・・？
|
| Re: 改行対応DrawFormatString ( No.20 ) |
- 名前：だみあん 日時：2016/03/23 23:42
> 追加の処理負荷は微々たるものです
気にしなくて良いレベルなのですね。
安心しました。
> その代わり、改めて文字列描画の処理の無駄が無いか探して改良したことで少し高速に動作するようにすることが
> できましたので、よろしければその改良を行ったこちらのバージョンをお使いください m(_ _;m
// フォントタイプはDX_FONTTYPE_ANTIALIASING_EDGE_4X4使用
int x,y;
for (int i = 0; i < 1000; ++i){
x = DxLib::GetRand(1280);
y = DxLib::GetRand(720);
DxLib::DrawStringToHandle(x, y, _T("あいうえお"), -1, fontHandle ) ;
}
こんな感じのコードで試してみたところ、
以前のverだと、ＣＰＵ使用率50〜80％ぐらいで、たまにに画面がカクカクっとなったりしたのですが
新しい方だと20％前後で安定しています。画面もカクつくことも無いです。
ものすごく低負荷になってますね。
環境とかにも拠るのでしょうけど、うちの場合では少しどころじゃない高速化になってますｗ
文字が画面一杯に埋め尽くすようなケースの場合、
ＣＰＵファンがうなりをあげたりするのが気になっていたのですが
このｖｅｒからは気にしなくても良くなったようなので、大変うれしい改良です（＾＾
それも特別な処理なしに軽量化というのはありがたいです。
これで一行を複数分けてのDrawStringも問題にならないとおもいます。
ありがとうございました。
あとついでの話なのですが（そして随分古い話を蒸し返すようでアレなのですけど……）
影付きフォントタイプの要望
ttp://hpcgi2.nifty.com/natupaji/bbs/patio.cgi?mode=view&no=3410
（これまたついでに報告ですが「こちらから Google さんを利用しての検索もできます( 作 JEXさん )」のほうで出来る
掲示板の過去ログ検索の検索先と検索結果のＵＲＬが旧サイトのままのようです。）
自前で行う影付の文字描画処理は常にDrawStringの回数が二倍になるのですが
今回の件でその辺の負荷も減るなというところで、保留とされていたこの件思い出しまして。
> 仮に対応するとしたらアンチエイリアスの設定と、
> 縁付きか、影付きか、などの装飾の設定を分けて指定するように作り変えないと
> 無駄にフォントタイプが増えてしまいそうです
> アンチエイリアスと装飾の設定を分けるといった大きめの変更は難しいです
今回改めて見返してみたところ、
フォントタイプの指定の部分が、影付一つつけると
無駄にタイプが増えてしまうとのことですが
00000000 DX_FONTTYPE_NORMAL
00000001 DX_FONTTYPE_EDGE
00000010 DX_FONTTYPE_ANTIALIASING
00010010 DX_FONTTYPE_ANTIALIASING_4X4
00100010 DX_FONTTYPE_ANTIALIASING_8X8
00000011 DX_FONTTYPE_ANTIALIASING_EDGE
00010011 DX_FONTTYPE_ANTIALIASING_EDGE_4X4
00100011 DX_FONTTYPE_ANTIALIASING_EDGE_8X8
設定はビット単位で行われていますよね。
単純に定数ですべてのフォントタイプの組み合わせを用意して設定という方式を止めて
フォントタイプ設定用の値を取得する関数を用意すればよいのでは無いでしょうか。
作成される値自体は今までの値と同じであれば従来の指定もそのまま使えますし。
// フォントタイプ作成
int CreateFontType(アンチェリ使用とアンチェリのグレード, 文字飾り（エッジ..影等） );
一番目の引数は以下の値だけ有効
DX_FONTTYPE_NORMAL // アンチェリ無し
DX_FONTTYPE_ANTIALIASING
DX_FONTTYPE_ANTIALIASING_4X4
DX_FONTTYPE_ANTIALIASING_8X8
二番目の引数は文字飾り系のみ有効
DX_FONTTYPE_NORMAL // 飾り無し
DX_FONTTYPE_EDGE
DX_FONTTYPE_DROP_SHADOW（0b00000100）// 影付とりあえず空いてる３ビット目あたり使用？
// この例だとDX_FONTTYPE_ANTIALIASING_EDGE_4X4指定と等価
DxLib::ChangeFontType( CreateFontType(DX_FONTTYPE_ANTIALIASING_4X4, DX_FONTTYPE_EDGE) );
な感じだと
DX_FONTTYPE_DROP_SHADOW一つ増えるだけで済むと思いますし、
過去のソースコードとの互換性も保たれると思います。
今回の件でDrawStringの回数が二倍になってもDrawString自体の負荷が減ったので
それほど描画負荷的には気にすることは無くなったのですが
やはりフォントタイプに影付があると
影付文字のためにDrawString系すべてにラッパを作る手間が無くなるので
（あと影付とエッジ付は排他的に処理したいというのもあります）
追加してくれるとありがたいのですが……。
それでも元の記事にもある
＞ 現状の機能の組み合わせでも表現可能というのも大きいです・・・
と言う点で、やはり難しいですかね……。
よろしければ再考していただきたく思います。
|
| Re: 改行対応DrawFormatString ( No.21 ) |
- 名前：管理人 日時：2016/03/27 22:04
|
| Re: 改行対応DrawFormatString ( No.22 ) |
- 名前：だみあん 日時：2016/03/28 02:50
> なので、申し訳ありませんが引き続き保留とさせてください m(_ _;m
そうですか、残念です（ＴＴ；
タイミング的にいろいろと過渡期にあるようで、時期が悪かったと思うことにします。
もとの改行付〜の話からは随分それてしまいましたが
> Direct3D 11 を使う場合に限定されますが更に少しだけ文字列描画( というより DrawGraph などを含めた画像描画全般 )を
> 高速化できましたので、よろしければお試しください m(_ _)m
描画高速化は喜ばしいのですが、現状、Direct3D 11使用にしてしまうと
Direct3D 9用のシェーダをつかっているのでその辺が使えなくなってしまいます。
Direct3D 11利用時に高速化と言うとこで、そろそろDirect3D 9用とDirect3D 11用のシェーダを
両方用意するべきかなとおもったのですが
Direct3D 11版シェーダーについてリファレンスを確認してみたところ
> Direct3D 11 版作成直後で今後変更される可能性があるので、今のところリファレンスでは非公開です。
となっています。
> 今度はPS2レベルで止まっている『3D機能の強化』が大きな項目として待っているので
あたりにも関わってきそうなところですよね……。
この辺も含めて、気長に待つことにします（＾＾；
|
| Re: 改行対応DrawFormatString ( No.23 ) |
- 名前：管理人 日時：2016/03/28 04:07
|