[過去ﾛｸﾞ] DXライブラリ 総合スレッド その19 [無断転載禁止]©2ch.net (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
158(1): 名前は開発中のものです。 [sage] 2016/12/18(日) 21:08:52.00 ID:oO1EoBtD(3/4) AAS
流れがつかめませんが、解決したんですか
ちなみに>>155でいうと、自分はパターン２派。可読性が良くなると思うから。
画像Ａ.のdrawFadeIn()とdraw()で重複するブロックが肥大化してきたら、その重複部分をinline関数に切り出してる
しかし・・・
確かに可読性が悪いとストレスの原因になるが、
可読性を確保する労力が新たなストレスと生むというジレンマ・・・
159(1): 名前は開発中のものです。 [sage] 2016/12/18(日) 22:50:19.71 ID:w4mjhhpa(7/7) AAS
>>158
混乱させてしまったようで、申し訳ないです
155の意図をやっと把握しました（訂正に訂正を重ねてホンマ……）
パターン１は、どこかでフェードインの命令要求を登録した後、draw関数を呼び出します
draw関数内では、透過度の変更要求の確認、透過度の更新、および、DXライブラリ「SetDrawBlendMode」の呼び出しを行います
透過度の変更要求がない場合は、SetDrawBlendModeを使いません
なので、通常描画もフェードイン描画も一律draw関数を呼びだすことになります
パターン２は drawFadeIn とdraw を別関数にします
フェードインするときは、drawFadeInを呼び出して、引数として透過度の更新情報を渡します
結論としては、皆さん「パターン２がマシ」と仰っているので、その路線で進めようと思います
描画処理専門のブラシクラスも含めて、検討してみます
可読性に関しては、最近、可読性を確保するためのストレスに負け始めてます
重要なのは重々承知ですが、やはり面倒……
趣味なはずなのに、仕事と同様のストレスを感じる
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.027s