DXライブラリ 総合スレッド その5

拡大率を予めsincosにぶち込めばいい　「回転を見越して拡大縮小する」

先生、その見越し方が分かりません

つかそういういくつもの変換を同時に適用するために
行列があるんだと思うが・・・行列を使わないなんて無駄に複雑になるだけだよ。

>>954
計算部分を自前でやってるだけで、やってることそのものは変わらない気がする

チラ裏で申し訳ない。
画像処理の入門書を読んでるんだが

(1)自前で行列（回転用行列、拡大用行列など）を用意
(2)それらを掛け合わせて、最終的な変形用の行列を作る
(3)変形用行列を関数に渡す

…みたいな感じだった。
行列をクラスにして、演算子のオーバーロードで簡単に加算や乗算が出来るようにするとか
そういう工夫がされているようだ。


あと、公式BBSでこんなの見つけた
http://hpcgi2.nifty.com/natupaji/bbs/patio.cgi?mode=past&no=1033

3D用の関数に行列使えるのがあるよ

上で話題にでてたアフィン変換だって2次元に特化した行列じゃんか
クラス公開されててちょっといじれば簡単に使えるのとかあったぞ
行列うんぬんよりクラスがわからんとか？

頂点の集合に行列を演算してできた形に描画するのはいいんだが
長方形の画像を自由変形して描画するアルゴリズムはいったいどうやって実装されてるんだろう
ピクセル単位で全部写像してたらすごく遅くなりそうだが他に方法も浮かばない

専用のハードウェアにやらせてるんだから爆速
アルゴリズムとかいう次元じゃない

>>957
3Dの方はあんまり見てなかったぜ。
これから勉強しないとな…。

>>958
クラスが分からないとかは流石に発想が飛躍しすぎじゃね？

>>959
テクニカルな最適化や、誤魔化しとかはやってるかもしれないけど、
基本的なやり方は同じで、あとはハードウェア様による力技なんじゃない？

LoadGraphを使う関数を繰り返し呼び出してると
例外が出て強制終了することがある
具体的には、
main(){

:
:
shop->open();

}
とメインの関数からクラスのメンバ関数を呼んだとき、
openを十回くらい呼び出すと、openを呼んで最初に出てくるLoadGraphで強制終了する
open内で何度もLoadGraphを呼び出しているが、最初のLoadGraph以外で強制終了したことはない
他のまったく別のクラスのメンバ関数でも、二回目に呼び出したときに
最初のLoadGraphで強制終了するので、
openでなくLoadGraphに問題があると思うんだけど
そもそもどういう状況でLoadGraphが例外出すか分かりませんか？

メモリ使用量を見る限りメモリリークなどはない
ちなみに使ってるのはBcc版

具体的の意味わかってんのかカス

例外ってどんな例外？　メッセージとか無い？
読み込んでる画像はどんな画像？　ファイルサイズとかフォーマットとか。
メモリリークかどうかもどんな環境でどれくらいのサイズの画像を読み込んでるのか教えてくれないとこっちでは判断できない
もっと詳しく

全く具体的じゃないのに具体的には、とはこれいかに。

何が例外出すか分かりませんか？だよ
どういう状況で例外出すってエラーメッセージに全部書いてあるだろうが

エスパーしてみるに、
「最初のLoadGraph」に指定してるファイルが、
　
　(1)形式的に未対応のものを指定している
　(2)指定ファイルの内部フォーマットがおかしい

のどれかなんじゃないのかな？
「最初のLoadGraph」以外は成功してるって話だし。

DX_ライブラリ使っていたら
いつもなら「ch.」(chは構造体)で設定したパロメータが表示されたのに
今日使ってたら表示されなくなった。これってどこの設定変えれば元に戻るの？

インテリセンスはよくぶっ壊れる

たまにJavaやるとEclipseの入力支援の賢さに感動する。

いや普通にVS2008の方が賢いだろ C++はダメダメだが

＞IntelliSense
最近のは分からないけど、ちょっと変なことやると対応しなくなるしなあ。

Bccのデバッガは見方がよく分からなかったのでVC++で原因を調べてみた
移植にかなり手間取ったけど、原因はnew,deleteでの
HEAP CORRUPTION DELETEDだった

ごめんよ、DXライブラリ

VS2008EEC#でDXLib使ってるけど、ゲーム開発はなんでC++が多いいのか・・・？
C#使いやすいと思うんだが・・・

C#とC++と、どっちも知らない人間（俺みたいな）が始めようとしたら
そりゃデフォルトで解説されてるC++使うよ。

>>974
>>975
素人はメモリ管理で苦労させられる
C#はライブラリの導入・セッティングまでも驚くほど簡単だ

むしろメモリ管理を隠蔽化されると不安になる

C#は動作速度どうなんだ？
あと.NETないと動かないんだっけ　それはどうでもいいが

>>978
今のPCスペック考えると動作速度気にするのは意味無いかな
同人レベルならFFやメタルギアのような実写モーションやるわけではないし
HSPよりは圧倒的に速いよ、ニコ動見てもHSP+Easy3Dで3Dアクション作ってる奴がたくさん居る
C#もJavaもゲーム製作には十分過ぎる

>>974
>>975の理由もあるが、
単純に、C言語覚えたから次はorいよいよC++に〜とかって感じじゃない？
JAVAとかの経験がなければガベコレとかも知らないだろうし。
メモリ管理とかはまぁゲ製作以外で活かせる人なら勉強にもなるから良いやー、とか。

C#は解析が簡単なんじゃないの？
改造し放題だと市販のゲームには向かないと思う

>>974
公式サンプルがC言語で書かれているし、どれか一つ言語を覚えるとしたら自然にC言語になるんじゃないかな。
DXライブラリ自体もC言語で書かれてるしね。

>>981
難読化ツールというものがある。
それにC言語でも解析は可能なので市販する場合は独自に暗号化する必要がある。
特に画像、サウンド、シナリオテキストは見えてしまうとマズいので。

そりゃデータは暗号化するだろうけど、それは言語とは関係ない話では？

>>982
ぜってー使ったこと無いだろ＞難（ｒｙ
あのスカスカ具合を見てから言えｗ
データも言語関係ないし

C++はWiondows標準のexeファイルを作成でき、そのまま実行できる
C#やJAVAはWindows非標準の中間ファイルしか作れず実行環境のインストールをユーザーに説明し、納得させ、実行させなければいけない
余計なソフトのインストールを嫌うユーザーは多い
速度よりも何よりもこの差があるからC#やJAVAは選ばれない

インストーラーで強制インストールとかまんこい

デフォルトでインストール済（）笑

>>983
どの言語にしても暗号化は必要と言いたかったのだけど・・・

>>984
>あのスカスカ具合を見てから言えｗ
どの難読化ツールを使ったか知らないけど、それでスカスカだと感じたんならしょうがないね・・・
そこまでセキュリティが必要なものを作っている人もいないと思うけどなあ。

>>981
現状の市販ゲームが改造し放題なのばかりなのに何言ってるんだ。

>>984
無料のやつしか使ったこと無いだろ

DXライブラリから話がずれてるぞ。

もっと単純に考えると
ゲーム会社とかで使われてる言語は
圧倒的にC++が多いからじゃねーの？

趣味でゲーム作ってるだけって人も多いだろうけど
ゲーム作ってる以上そっちに興味沸くのは当然だろ？

よくわからんけどC#で製作されてるのって箱○ぐらいらしいじゃん
そして箱○があの状況だし…

いや、常識的に考えて、3DゲームをC++以外で作るのは無理がある

C#でDxLib.dll使ってるとコードを書いてるときの違和感が半端じゃない。

わかる
ラップしたくなるけどそんなことするくらいなら普通にDirectX叩いても大して変わらないし

すまん。
言いたかった事は、C#や.net使うと、意外ににC++でやってる様な小技が
簡単にできたりとか。
３Ｄとか使わないで、ノベルゲとか作るならC#+DXlibが楽だと思ったからなんだ。

>>994
頭にDX.付け忘れたり。

たいていDXライブラリ自体がボトルネックになるから言語なんか何使っても速度はそんなに変わらないよ

a

b

うぅぅい

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。