スレすらないや
C言語のような難解でクールな記述ができる言語ほど、プログラマ受けは良い。
頻繁にある命令を短く効率よく書けた言語でしょ
今はハードの性能が上がってエディタや辞書にいくらでも登録できるようになったから
どれを使っても大差なくなってきてる
ゲーム作るには大差がありすぎるが？
DirectXやOpenGL使うならなおさら
やってできなくもないが、他の言語よりも遙かに苦労した挙げ句に遅い。
一時期は優遇されてたんだけどな
まあ企業主体の処理系の末路なんてこんなもん
ちょっと凝った事をやろうとするととてつもなくめんどくさくなる。
C言語はカルト教団の手続きを円滑に進めるギョーカイ用語に近いからね
両方大事だと思う
ｗｗ
ｋｗｓｋ
ベーシックは国内でも国際的にも規格化されている。
vbはmsがベーシックに文法を似せてｇｕｉ用にした独自拡張
つまりベーシックもどき。ただしデファクトスタンダードである。
何か長ったらしい言葉の頭文字を集めた言葉だよね。
BASICでくくらてはいるが、方言の集まりじゃないのか？ｗｗ
昔のマイコンでROMに載って動いてたものが偽物BASIC
今は何をお使いなのかと思ったら、
Wolf RPG Editor
DX ライブラリ
という方でした。
C#あたりも一緒だが
だから昔のＶＢが好き。
再UP可能でしたら、ぜひお願いします。
ＶＢでゲーム作りたい人、自分以外は絶滅したかと思ったよ。
たぶん、ＶＢ６は使っていないだろうから、の方をＵＰしました。
しばらく放置してたから自分で知らん内にコードを書き換えてしまったかも
しれませんので上手くいかなかったらごめんなさい。
ttp://homepage1.nifty.com/shifu2/DL/STG_Sample.zip 私、個人の活動状況は、VB2010でマルチスレッド用のエンジンを作成し、マルチコア環境では
そこそこの性能が出ることがわかった後、シミュレーションゲームの作成にかかったのですが、
思いのほか、自分の絵が下手であることを悟り、これをお蔵入りにしました。
（音楽は全部完成しているので、いつか製作を再開したいと思っている。）
その後、、今度はアセンブラで別のエンジンを開発。これはＶＢから呼び出し可能なＤＬＬで、
現在は、ツールをＶＢ６に戻して、お試し用に、上記とは別の簡単なシミュレーションゲームを製作中です。
さすがにＶＢでアセンブラの開発はできないので、ここはＶＣ＋＋の力を借りてます。
ＳＳＥ２が機能するエンジンを使えばＶＢでも、今まで以上のパフォーマンスが出せる…ハズ
ちなみに、ＶＣ６ではＳＳＥ２までの開発しかできない。VC2010ならそれ以上の拡張命令も使えるが、
Windows2000のユーザーを見捨てる事になるので、今回はＳＳＥ２までにしました。
使っているのはまさかのVB6.0です。（笑）
ゲームを作り続けていたわけではなく、数年ぶりの出戻りです。
自己流で作っていたのでグラフィックの移動等で挫折していました。
再度VBで挑戦するか、VC#をいちから勉強しなおすかという状況です。
自分としては慣れ親しんだVBで作りたいのが本音なので、「ここまで出来る」という目標にさせていただきたいです。
なるべく汎用性のあるのがいい
何が良いでしょうか？
難し過ぎるようなら、Java。
将来、VC++へのステップアップが必要なら、VC#2010。
ちょっとカッコつけたいなら、Ruby。
そこら辺よくわからないんだよな
ＶＣ++は難しいからね。気合入れてかかった方がいいよ。
経験者はムズいのわかってるから、くじけても責めないよ。がんばって！！
速度も実数計算を多用しなければほとんど同等
そもそも今の性能なら、3Dの剛体100個の物理計算とかをやらない限りはボトルネックにならないし
言語仕様がC++よりすっきりしててオススメ
でも、まともにDelphiが書けるレベルならC++もC#もRubyもぐぐりながら書ける
ttp://http://ja.wikipedia.org/wiki/CompJapan あと、VBは.netになってから色々と機能が拡張されて
重ささえ気にしなければC#と同等の事が出来るようになった
タダで使えるから未だにVB6を使ってるなら乗り換えたほうが賢明かと
ＶＢ2010はvatptr関数とかないのよ。
ＡＰＩがポインタを要求してきたときに、ＶＢ６のありがたみが嫌というほどわかる。
VarPtr関数です。ＶＢ2010だとガベージコレクタがらみで、ややこしい処理
になるのよ。
Dim Str As String = "AAAA"
Dim L As Integer
Dim C() As Char
Dim B() As Byte
Dim G As GCHandle
Dim Ptr As IntPtr
C = Str.ToCharArray()
B = System.Text.Encoding.GetEncoding("Shift_JIS").GetBytes(C)
L = UBound(B) + 1 'サイズを指定する必要がある場合に使う
G = GCHandle.Alloc(B, GCHandleType.Pinned)
Ptr = G.AddrOfPinnedObject().ToInt32()
面倒だわＶＢ2010。
初心者にVBのどの辺が優しいのだのかが疑問だ。
VB
Dim i As Integer = 0;
C#, Java, C++
int i = 0;
まあ、複数行に渡る命令を書く場合や、メモリー使ったりする場合には面倒だが。
動的メモリーはVBでは使わん
あと、VBはExcelとかと連係する場合に楽だな
影響するもんなの？
メインメモリを効率良く再配置してくれるといっても、コード組む側からしたら、
ポインタを使うとき、データを勝手に移動されないように、いちいちロックしないと
いけないので、面倒極まりないんですけど。
もしかしたら、メモリの開放忘れてメモリリークさせるバグが多かったので、
それを防止する為につけたのかもしれないけど…。
Vistaのせいかな？あのころ、メモリ不足でパフォーマンスが落ちるＰＣが多かったからな。
でも .net って Vista より先じゃなかったっけ？
ロックするとか意味不明だし、プログラム向いてないから病院いっとけ。
の下から２行目が、ガベージコレクタをロックしているコードなんだけど、
意味不明なのかい？
君にヒトを素人扱いできる程に技量があるとは、とても思えんが…。
ttp://http://dobon.net/vb/dotnet/vb6/objptr.html ヒトを病人扱いする前に用語のひとつもググってみれば？
（JavaのJNIも同様）
繋ぎ目を隔離したラッパークラスを通さずに直接ネイティブを呼べば面倒なのは当たり前。
いたるところでガベージコレクションをロックするかのようなことを書いて、
GCが邪魔だと呟いているのは実に意味不明だ。
どうやらロックの意味は理解できたようだな。ひとつ勉強になっただろ。
では逆に問う。君はＧＣの利点として何か実感できるものがあるのか？
ＧＣのある言語とそうでない言語で同じ動作をするプログラムを組んだとして、
あきらかにＧＣの優位性を感じる場面に遭遇できるのはどのようなケースだ？
ちなみに自分はＶＢ５からのユーザーだが、ＡＰＩは当たり前のように使っている。
ロックの意味もわかってないからあちこちでロックしまくってるわけだろ。
普通の人はそんなことしないので、ロックするといわれてもわかりません。
DLL、SQLとかVBの外にあるものは隔離して
VBのみで完結しているように設計を作るのは基本。
＞ＡＰＩは当たり前のように使っている。
Win32のことか？DirectXラッパぐらい作ってから言えよｗ
＞ＧＣの利点として何か実感できるもの
スマートポインタ（参照カウンタ）を使うようなケース。
自分もそのぐらいは作ったんだろうな。ＣＰＵで演算したデータをバック・スクリーン
サーフェスに転送する場合、ロックもかけず、ＡＰＩも使わず、どーやーって
転送しているんだ？おしえてくれよ。
スマートポインタ使うと、アプリの速度が上がるとでも言いたいのか？
俺が聞いたのはコーディングの話じゃない。実行上の有利性だ。
＞俺が聞いたのはコーディングの話じゃない。アプリの速度だ。
生産性の話をしていたのに、突然実行速度の話に変わったな。
GCは主に生産性の向上を目的として導入されているのに、おかしな話だ。
まあGCが得意なパターンにマッチすれば速くもなる。
C++でRAIIだと重いdelete()が集中しがちだが、
GCだと実際に解放するのを後回しにして、
負荷が軽い頃合に並列GCが少しずつ解放してくれたりする。
ならライブラリを使っている限り、アプリケーション層ではＡＰＩ(dll)を呼ぶ必要はなく、
従ってロックなどしないはずだ。そうでなければライブラリに存在意義がない。
ライブラリを作ったような妄想に浸っていただけだったというオチだな。
バックサーフェスのLockメソッドを実行して、引数の構造体からポインタを
取得し、ＡＰＩの movememory を使って転送する。
ちなみにDX9のフレームバッファに直接書き込む場合は、メソッドがあるので
ＡＰＩは使わないようだが、ロックはしなければならない。
おまえさんのライブラリではどーやってんのかなあ？答えてないぞ。
なにしろで「DirectXラッパぐらい」って言ってんだから、「ぐらい」なんだろ。
簡単にできそうじゃねーか？当然作ってあるんだろ
強がっても本当はDirectXライブラリなんて作った事ないんだろ。まあ昨日までロックを
知らなかったんだから無理も無い。
そのくせ態度だけはでかいんだよな。ヒトを低脳よばわりとかして…
ＧＣが効果を出すのはごく限られた状況だけ、ほとんどは余計なプロセスが動くだけで
ＳＴＧなんかを作る人からは嫌われている。
ＧＣがメモリをいじくりまわしても、無造作にメモリ使いまくるコード組んでりゃいつかは
足りなくなってスワップするし、ようはスワップがちょっと遅れて来るぐらいの効果しか期待できない。
とりあえず自分で「ぐらい」と言った「DXライブラリ」作ってみそ。そしたら少しは認めてやるわ。
初心者に1から10まで教えたりはしない。
あと話がコロコロかわるわ、分散するわ、人の書いたことが理解できないわ、
そんなお前と話をしても漠然と広がるばかりで一向に収束しない。
理由は単純、ID:wVU/jdLoがなりふり構わず言い返したいだけだからだ。
何がしたいの？そんなにくやしかった？
そして「ロックを使わずにピクセルデータをバックサーフェスに転送できる！！」とも言えないんだな
くやしいのう。くやしいのう。
＞俺はお前の先生じゃないからな。
＞初心者に1から10まで教えたりはしない。
じゃあひとつだけでいいよ。
ロックを使わずにピクセルデータをＣＰＵからバックサーフェスに転送できる方法
とやらを教えてくれ。
コードを表示してこっちで試して正しく動作したらオマエの勝ちでいい。
できなければオマエの負け。
オレはロック使わないと絶対にできないと思ってる初心者だから、先生よろしくたのむよ
…しかしコイツ本当に一度でもDirectXのコード組んだことあんのかよ？
ＡＰＩも使ったことないんじゃねーの？
どっちが初心者だよまったく…バカじゃねーの？
ロックするとか意味不明だし、プログラム向いてないから病院いっとけ。
こんな事書いてる辞典でお前がライブラリなんか作れないことは自明のこと。
一個一個ロックしてコールバック呼ぶ間抜けな姿が目に浮かぶわｗ
DirectXで頂点バッファとかVRAM転送に関するロックと
マネージコード(VB, C#, Java)のGCに関するロックは全く違う話だってのもわからないだろ？
初心者が強がったところでまたひとつ恥をかいてるよ。バカじゃねーの？
そうだな。俺の完全勝利ってこと。
普通にロックなんて誰もしないものｗ
おかしな知ったかぶりでGCを批判するぐらいなら
全部C++で書けばいんじゃないの？
ロックせずにコールバック呼べるよ～？ｗ
俺のC#ライブラリを使う限り、誰もGCロックなんてしないし、
SlimDXやMDX、XNAなど普通のライブラリやフレームワークはみ～んなそう。
ついで抽象度を高めればDirectXのロックもライブラリ層で消せますな。
低脳ライブラリではコールバックの名前が変わっただけで隠蔽性も何もなく、
ロックしてまわるそうです。一体何のためのライブラリなのか謎ですな（苦笑）
dll(C)側とコネクタとなるマネージコード側の両方を書くのは必須。
これ知識というより普通は気付く。
低脳にも理解できたかな？ ひとつ勉強になっただろ。
先生にありがとうございましたって、しっかり頭下げとけよｗ
DirectDrawでも話の芯は全く同じだ。
を書いてみろ。
DirectXなんて時間かかって面倒くさいだけで、
可能・不可能を論じれば誰でもできる簡単なことだからな。
完全勝利
言い回しが古すぎるね。
Direct3D9ではIDirectSurfaceを直接操作せず、IDirect3DTexture経由で事足りる。
以下、テクスチャを1ドット毎白く塗りつぶす例。
D3DLOCKED_RECT lockRect;
pTexture->LockRect(0, &lockRect, NULL, D3DLOCK_DISCARD);
for(int y=0; y<h; y++)
{
for(int x=0; x<w; x++){
DWORD color = 0x00ffffff;
BYTE* p = (BYTE*)lockRect.pBits + lockRect.Pitch*y + 4*x
memcpy(p, &color, sizeof(DWORD));
}
}
pTexture->UnlockRect(0);
ライブラリユーザーは"ロックなど不可視"なはずだ。
virtual void FillTexture(int rgbColor) = 0;
低脳にも理解できたかな？ ひとつ勉強になっただろ。
先生にありがとうございましたって、しっかり頭下げとけよｗ
void __stdcall s2sp15MoveMemory32SSE2( long ptrSrcZeroDTSC, long ptrDstZeroDTSC, long SrcWidth, long LinePlusByte,long StartTop, long WorkHeight )
// 同サイズでの３２ビットカラーデータ転送。サイズは送り側 SrcWidth を、８の倍数にすること。
{
__asm
{
mov ebx,LinePlusByte
mov esi,ptrSrcZeroDTSC
mov edi,ptrDstZeroDTSC
mov eax,SrcWidth
movd mm0,eax
shl eax,2 // 32ビットなので４倍
mov ecx,StartTop
mul ecx
add esi,eax // ソース開始アドレス
movd eax,mm0
shl eax,2 // 32ビットなので４倍
add eax,ebx // LinePlusByte
mul ecx
add edi,eax // デスティネーション開始アドレス
movd eax,mm0
shr eax,2 // ４点ずつ処理する
movd mm6,eax
mov eax,WorkHeight
add eax,ecx
movd mm5,eax // エンドライン
mov eax,ebx
or eax,edi
test eax,0xf
jnz LL201 // アライメントＮＧ
movd eax,mm5
cmp eax, ecx
je LL99
movd mm7,ecx
movd ecx,mm6
LL102:
dec ecx
js LL120
movdqa xmm0,[esi]
movntdq [edi],xmm0
add esi,16
add edi,16
jmp LL102
LL120:
add edi,ebx // ダイレクトＸでのライン加算
movd ecx,mm7
inc ecx
jmp LL101
movd eax,mm5
cmp eax, ecx
je LL99
movd mm7,ecx
movd ecx,mm6
LL202:
dec ecx
js LL220
movdqa xmm0,[esi]
movdqu [edi],xmm0
add esi,16
add edi,16
jmp LL202
LL220:
add edi,ebx // ダイレクトＸでのライン加算
movd ecx,mm7
inc ecx
jmp LL201
LL99:
emms
}
return;
}
書き込みを高速化できる。
ところ構わず糞を垂れるのは痴呆なのだろう。病院逝っとけ。
やはり病人のようだな。相手し切れん。
アスペの特徴
①勝ち負けに異常にこだわる （常に生と死や○か×かの極端な二択）
②性的なことで相手を罵倒するのが好き （性への異常な執着）
③相手を知的障害者や奇形児と罵倒する （生理的に苦痛などの一般的な感情の欠落）
④揚げ足 （自分では分析・考察ができないため周囲の言葉を借り「それはお前」とオウム返し）
⑤個人情報や姿・容姿への一方的な思い込み （「相手は○○であるから△△である」という決め付け）
⑥自分は常に被害者である （周囲が自分の意見を分かってくれないのは周囲が悪いという自己中心的な考え）
⑦粘着質 （少しでも気に入らない相手には徹底的な誹謗中傷を行う）
⑧感情的になると幼稚な言葉や短文での罵倒 （うんち、お漏らし、死ね、臭い等の言葉の連投）
ttp://logsoku.com/thread/hayabusa.2ch.net/livejupiter/1280374335/ のコメントってずれてないか？
のコメントって脱線してないか？
で言ってる話をころころ変えてるのって、どっちの方だ？！
そうだよ。俺はDLLにヒープを渡す際に行うGCのロックについて回答した。
しかし回答に対してwVU/jdLo（）が突然、
DirectXでサーフェスのVRAMをロックする仕方を教えてくれと言い出した。
以後、彼はGCとDirectX、２つの話を同じ話とした誤った前提をもとに得意面で執拗に追及しはじめる。
またwVU/jdLo（）はGCのロックが面倒だという当初の題目()を覆し、
「俺が聞いたのはコーディングの話じゃない。実行上の有利性だ。（実行速度） 」
などと捏造する。
その後も謎の要求を繰り返す。
「オフスクリーンサーフェスにピクセル配列を転送するコードを書いてみろ。」
「コードを書いたらオマエの勝ちでいい。 できなければオマエの負け。」
しかたがないので、wVU/jdLoが繰り返し要求していたコードを書いた()。
何か意味や目的があるのかしらないが満足したらしく、
ID:wVU/jdLoは意味もなく >>175- を張ったということだ。
だが俺のせいにされても困るな。頭のおかしい人が1人で暴れてて、
こっちは二転三転する話に付き合ってやっただけだから。
まあ、.netのガベコレに苦労してる人が多いのは分かった。
メモリー管理は初心者には相変わらずの鬼門だな。
でもさ、.netではAPIのかわりになるような命令がいっぱいあるから、
API呼び出す必要はほとんど無いような・・・
＞Vistaのせいかな？あのころ、メモリ不足でパフォーマンスが落ちるＰＣが多かったからな。
＞でも .net って Vista より先じゃなかったっけ？
メモリーの断片化はもっと昔から問題になってたわけだが？
とにかく動的メモリーを使いまくると正体不明でアプリが落ちるわ、
落ちた後でもOSが不安定になるわで動的メモリー管理は敷居が高かった。
まあ、断片化しないようにメモリーを使えば問題ないわけだが。
何個も動かしていた場合にも、メモリーの断片化が発生していたな。
メモリーの虫食い現象と呼んだ方が分かりやすいかな？まあ詳しい話は
フラグメンテーションでぐぐれ。こればっかしは、ガベコレを使わない限り、
メモリーを増やした所でアプリが落ちるのを延期するぐらいの意味しか無い。
何とかしてくれると勘違いしているようだが、スワップファイルを
ページングで何とかなる容量は32bitだと2Gバイトまでなんだよな。
64bitOSの場合だとHDDの許す限り何とかしてくれるんだろうけど。
ttp://http://technet.microsoft.com/ja-jp/windows/mark_03.aspx 数をこなしてる上級者でも忘れたり、ちょっとしたポカをする。
だから上級者でもガベージコレクションはかなりありがたい。
.netやjvmのメモリコンパクションはあまり期待できない。
あとメモリリークではなく断片化でアプリ落ちるか？
は仮想メモリのアドレスサイズの話だろうか。
あとはメモリー破壊へとまっしぐら。もしくは例外終了かな？
これは初めて知った。んー、VBはメインで使う言語じゃないから気にしないでおくか。
＞は仮想メモリのアドレスサイズの話だろうか。
そうだよ。
グーグル検索⇒『来島のモノノリウエ』
UD63T2V610
