1read 100read
2013年01月ゲ製作技術4: DXライブラリ 総合スレッド その14 (213) TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▼
【pygame】pythonでゲーム製作【ぱいがめ】 (652)
【25周年】ロックRレクションを作ろう (206)
【3Dゲームエンジン】Unity質問スレッド3 (499)
DXライブラリ 総合スレッド その14 (213)
ゲーム製作者が自由にアンケートをとれるスレ (239)
【SB】Shooting Game Builder ver15【ｼｭｰﾃｨﾝｸﾞ】 (725)

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


1 ：2012/10/19 ～ 最終レス ：2013/01/17
Cを習得した程度のスキルでも、ゲームのグラフィックを比較的容易に描画する事のできる、
「DXライブラリ」に関するスレッドです。
DXライブラリに関するテクニックなどの情報交換などを行う事で、
多くのDXライブラリユーザのスキルの向上に役立てたら幸いです。
【公式】
http://homepage2.nifty.com/natupaji/DxLib/
【前スレ】
DXライブラリ 総合スレッド その13
http://toro.2ch.net/test/read.cgi/gamedev/1339368894/
【過去スレ】
01 http://pc11.2ch.net/test/read.cgi/gamedev/1197468399/
02 http://pc11.2ch.net/test/read.cgi/gamedev/1224923873/
03 http://pc11.2ch.net/test/read.cgi/gamedev/1238429676/
04 http://pc11.2ch.net/test/read.cgi/gamedev/1249822550/
05 http://pc11.2ch.net/test/read.cgi/gamedev/1259912953/
06 http://hibari.2ch.net/test/read.cgi/gamedev/1267108154/
07 http://hibari.2ch.net/test/read.cgi/gamedev/1286180687/
08　http://hibari.2ch.net/test/read.cgi/gamedev/1301818631/
09 http://hibari.2ch.net/test/read.cgi/gamedev/1310904069/
10 http://hibari.2ch.net/test/read.cgi/gamedev/1313655495/
11 http://toro.2ch.net/test/read.cgi/gamedev/1322844235/
12http://toro.2ch.net/test/read.cgi/gamedev/1330000532/
【関連スレ】
C/C++ゲーム製作総合スレッド Part1
http://toro.2ch.net/test/read.cgi/gamedev/1337516528/

2 ：
>>1
スレ立て乙

3 ：
>>1乙

4 ：
DrawGraphとかにある引数のTransFlagってデフォルトでTRUEに設定しておいて欲しいよね
自分でヘッダ書き換えろって話なんだけど

5 ：
デフォルト引数設定するだけやん

6 ：
ラップ関数作ればいいやん

7 ：
おまえら天才だな

8 ：
C#でDxLib使ってるんだけど
親ファイル
│
├Main.cs
├Game.cs
└graph
　　└graph.bmp
class Main{
　　　　static void Main() {
　　　　　　　　DX.ChangeWindowMode(DX.TRUE);
　　　　　　　　DX.DxLib_Init();
　　　　　　　　Game gm = new Game();
　　　　　　　　gm.Main();

　　　　　　　　DX.WaitKey();
　　　　　　　　DX.DxLib_End();
　　　　　　　　return;
}}
class Game{
　　　　public void Main(){
　　　　　　　　int graph = DX.LoadGraph("graph/graph.bmp");
　　　　　　　　DX.DrawGraph(0,0,graph,DX.TRUE);
}}
graph:bmpが表示されないorz
パスの指定が間違ってんのかな……

9 ：
graphフォルダはexeファイルが作成されるフォルダ(dxlib.dllを入れるフォルダ)にないとだめ

10 ：
>>9
できた!
㌧クス

11 ：
エラーチェックしないから…

12 ：
エラーで例外投げないC#とか意味ないな。

13 ：
イミフ
拾えるぞ？

14 ：
マップ3Dの2Dアクションだけど、段差にくっ付きながらジャンプすると引っかかってジャンプしない
これ判定の仕方が悪いよね…
移動→本体座標ずらす→埋まってたら戻す、って当たり判定してるんだけど
仮の座標伸ばして本体座標を動かさないようにした方がいいかな

15 ：
>>14
真上、あるいは段差から離れる方向へのジャンプなら問題ない？

16 ：
真上とかは問題ないですね
キャラは2Dでマップ3Dだから当たり判定に線引いてみたら左右に移動してる時は当たり判定ずれてる…

17 ：
SetChangeScreenModeGraphicsSystemResetFlag()なんて関数があったのね…
わざわざグラフィックハンドルを自前で管理して
ウィンドウモード切替時にロードし直すように実装した後に知ったぜ…
つか関数名なげーよｗ

18 ：
バグ見つけたぜ
対応してもらえるかな？

19 ：
バグかどうか怪しい、あるいは環境依存かもしれないと思った場合は
一度ここに最小コードを晒してみても良いのよ。

20 ：
よく考えてみたら正しい動きっぽい

21 ：
受け取った文字列(FileName)+数字(i)のpngファイルの画像ハンドルを
可能な限りvector配列に突っ込むって処理なんですが、
もっと綺麗に書ける気がするんですけど、どうしたらいいですか？
int tmpHandle = LoadGraph((FileName+"0"+".png").c_str(),0);
for(int i=1;-1==tmpHandle;i++){
HandleFrame.push_back(tmpHandle);
ostringstream oss;
oss << FileName << i << ".png";
tmpHandle=LoadGraph(oss.str().c_str(),0);
}

22 ：
>>17
リピートアフタミー！
セットチェンジスクリーンモデルグラフィックスリセットフラグ！！！

23 ：
モデルちゃう、モードや

24 ：
3Dアクションで大量のパーティクルをステータス与えて演算してDrawPolygonIndexed3Dで描画してるんだけど
ずっと1万エフェクトぐらいでfpsが5以下になるレベルまで落ちてたからいよいよグラボ載せようかと思ってたんだが
ふと描画無しで演算だけさせたら、それでも10ぐらいまで落ちるんだけどなにか仕様上の問題ってあったかな
CPUは4つのコアが均等に20%ぐらいの負荷がかかってる状態だから問題無いと思うんだけど

25 ：
２コアユーザー切り捨てですか？

26 ：
記憶を頼りに書いたけど実際ちゃんと測ったら2つ目のコアが50～90%ぐらいで他は10～30%ぐらいの負荷だった
演算の最適化と評判悪いけどマルチスレッドしか無いかな
あとグラボ載せたら描画関係の演算はGPUに行くからCPUの方は余裕できたりってするかな

27 ：
>>21
書式

28 ：
DXライブラリ初期化の前に設定ファイル(ユーザが前回のプレイで設定したコンフィグ)を読み込んで
指定された画面サイズで起動するのと、まずは320×240(デフォルト)で起動しておいて「起動中...」とか
メッセージを表示しつつ設定ファイルを読み込んでから画面サイズを自動で変更するのだと後者の方が
安全なのかな？自分がプレイヤーだった場合の視点だと起動時にまどろっこしいのは苦手だから悩む

29 ：
前者だろ。後者の目的が分からん。そんなゲームは見たことない。

30 ：
>>29
Windowsみたいな起動ロゴ表示されたりプロンプトで起動準備するPCゲーは珍しくないでしょ？
DXライブラリなら特殊な知識を必要とせずにこれが擬似的に表現できると思ったんだけど

31 ：
>>30
珍しくないって例えば何てタイトル？
そんなゲームは少なくとも商業ゲームでは記憶にない。
そもそもそれをする理由がないし。
スプラッシュスクリーンはロードに時間のかかる重量級ソフトが
ユーザーに対して、フリーズとロードを区別できるようにするためのもの。
例えばPhotoshopやEclipseがそう。Windowsがこれら以上に重量級なのは言わずもがな。

32 ：
自分の知ってる洋ゲーだと、
起動ランチャーからPlayとOptionが選べて
Optionからウィンドウ・フルスクリーンまたは解像度の選択をすることで
Play時の画面が変わるタイプと、
とりあえずフルorウィンドウモードで起動させておいてゲーム内オプションから
画面モード、解像度が切り替わるタイプがあるね。
スプラッシュロゴを先に表示させてーって言うのはなくもない気がする。
確かあれは…ｱﾘｽｿﾌﾄ

33 ：
アリスソフトはスプラッシュスクリーンじゃなくねと思ったら古いのは一見そうだったな
でもあれはオプションでスキップできるからやっぱりスプラッシュスクリーンじゃないんじゃね

34 ：
そんな面倒なことするなら、さっさと起動してサークルロゴでも表示して、その隙に読み込むほうがマシ

35 ：
つーか、あんなくだらない質問する人がスプラッシュスクリーンが必要になるほどのゲーム作ってるとは思えんｗ

36 ：
初心者だからこそ大量のデータを非効率的に読み込んで時間がかかるんだろ
データ量が多いゲーム＝いいゲームってどこの小学生だよ

37 ：
>>32
ランチャーでオプションの設定、MODの切替とかできるゲームは腐るほどあるね
開発ブログのフィード表示したりとか
でも>>28が言ってるような、設定読むためにスプラッシュスクリーン表示するゲームってのは聞いたことないな

38 ：
初心者が初心者なりに試行錯誤しながら
ゲーム作っちゃいかんのか？

39 ：
前に自分がやったときは、
別途にGUIアプリを作っておき、そこからゲーム本体を起動する形にしてた。
GUIアプリはルートディレクトリに、ゲーム本体の方は下位ディレクトリに置くようにして、
ユーザには基本的に前者を起動させるようにする。
解像度とかの設定は、起動時に引数で渡すなり、iniファイルを経由するなり。

40 ：
わざわざ別アプリにしなくても、Windowsアプリケーションならゲームのexeに組み込めるけどね
ゲームのメインループに行く前にそのダイアログのプロシージャだけwhileで回しておけばいい

41 ：
俺もDLLの数がかさんだ時やってるなあ

42 ：
DXライブラリなら、ini読んで最初の描画するまで1秒とかからないよね
前者も後者も時間は変わらないと思うんだけど
最初の描画の前に、巨大なファイル読み込みをしてしまって時間かかってるなら、
それをやめて、最初の描画のあとで巨大なファイル読み込みすればいいと思う

43 ：
3Dゲーム作ってるんだけど、キャラモデルの影が強すぎる…
みんな調整とかしてるの？マップの方はなんともないのに

44 ：
アクティビジョンのトニーホークシリーズで、画面解像度とか、Fogのオンオフとか選べるランチャー経由で起動してたな。
exe直だと前回と同じオプションのままで起動だったと思う

45 ：
>>24
均等に負荷かかってるならマルチスレッド処理してるってことだよね？
処理の粒度が細かすぎるとかじゃないかな。粒度が細かすぎると、同期APIでカーネルスケジュラーが
頻繁に起されて、CPUの負荷が上がらなくなるように見えたはず。

46 ：
俺だけみたいだな、モデルの問題か
XファイルなのがDXライブラリと相性が悪いとかじゃないならいいや

47 ：
CSSスプライト見たいな手法って画像のロード時間だけで
描画とかゲームの速度自体に影響するのかな？

48 ：
一応テクスチャ切り替えの手間が省けるからちゃんと軽くなる
そこが結構重いとか重くないとかいう噂は聞いたことあるけどそういえば調べたことはないな・・

49 ：
速度よりは、全く同じように使えるようにする工夫が気になる

50 ：
めっちゃ影響するぞ
最悪の状態と最高の状態を比べると数倍から数十倍もの速度差がでる
最悪の場合をテストするには、画像Aと画像Bそれぞれの画像からグラフィックハンドルを作って交互に描画
最高の状態をテストするには、画像Aと画像Bを結合した一枚の画像を作って、LoadDivGraphで読み込むか、
もしくは画像Aと画像Bを結合した一枚の画像を読み込んでグラフィックハンドルを作り、DerivationGraphでそれぞれのハンドルを作って、
交互に描画

最悪のパターンなんて、実際には弾幕シューティングでわざわざ別画像の弾を交互にばら撒きまくとか、
別テクスチャのマップチップを交互に敷き詰めるとか、奇妙な状況でしか起こり得ないけど

51 ：
へぇ、メモリに入ったら同じかと思ってた

52 ：
書いてて思ったけど、テクスチャ切り替えの発生回数をカウントする関数が欲しいな
最適化プログラム作る際の参考になりそう

53 ：
実際どのぐらい違うんだろうね
3Dだとモデルを描画する度にテクスチャが切り替わってると思うんだけど

54 ：
>>45
まさか今更相手してくれるとは思わんかったありがとう
えっとID変わってるけど>>26の通り、改めて計測してみると
大体計測の単位時間あたり2～3単位時間に1回ぐらい100%になるコアがある
でも他のコアは20～30%ぐらいだし2～3単位時間に1～2回は60～80%ぐらいしか稼働してない
fpsは常時3～5程度
ソースコードは公式の3Dサンプルプログラムをひたすら改変したものだけどマルチスレッド処理は書き加えてない
描画関数をコメントアウトしても同じぐらいの負荷とfps
でもパーティクルの運動とかの記述はそのままに描画関係の行列計算とかを大量に含む部分を切ったら1万パーティクルでもfps59.6～59.9で安定
今のところテストでグラフィックハンドルは1つしか使ってないので>>50で言う最悪の状態にはなってないはず
将来的にはもっと大量のエフェクトを描きたいので出来れば10万～100万ぐらい扱いたい
最適化は一切してないので描画関係の行列計算がかなり多いように感じる
でもCPUの計算能力や描画関数の呼び出しとかとの相対的な負荷が想像がつかないのでどの程度影響与えてるかわからない
1万～10万ともなると普通の四則計算や行列計算の負荷もバカにならないのかな

55 ：
連投スマン
仮にマルチスレッド処理をさせるようになって>>45の状況になったしたら
CPUの負荷が上がらなくなるように「見える」だけで実際は限界まで負荷かかってるの？

56 ：
>>54
あれーじゃあなんで均等に負荷がかかってるんだっていう疑問がわいてくる・・・
前段の部分は、行列計算が重いのかなぁ・・・。でもその場合はそのスレッドが全力で走るはずだよね。
後段の方は、実際にも限界まではかかってないよ。
粒度が細かすぎの場合カーネルオブジェクトで同期すると（最悪時には同じ
オブジェクトをそれぞれのスレッドでロックをとりにいくから）1/スレッド数 ぐらいしか
はたらかなくなっちゃう、で、ただただカーネルスケジュラーが走る分だけ重くなる。
（スピンロックの時は全力でスピンし続けるからすべてのスレッドが上限に張り付くのが見える。）

57 ：
>>56
紛らわしいことしてごめん
>>24の均等に負荷ってのは間違いで>>26や>>54の通りどれか1つのコアは高負荷状態になってる
他の3つは確かに割と均等だけど……
でも確かに自分でも処理落ちしてるんだからどれかのコアは常時100%負荷じゃないとおかしいとは思ってる
一応CPUはi5 2500Kでそこまで古いわけじゃないからちゃんとしてやれば別に毎フレーム数万回の運動計算ぐらいなら大丈夫だと思うんだけど
さすがに100万エフェクトに上限設定したらアイドル時？の毎フレームのループ処理だけでfps40ぐらいまで落ちるけど
もう少しして描画関係の関数が落ち着いたらマルチスレッド処理するようにしてみようかな
そのときにもうちょっと勉強して参考にさせてもらうよ
でもまあなんとなくのイメージは分かったありがとう
あとつい勢いでグラボも積んでみたんだけど、ソフトウェアレンダリングじゃなくてハードウェアレンダリングにするのは
SetUseSoftwareRenderModeFlag でFALSE返せばいいんだろうか
これを入れる前後でGPUの負荷も変わったように見えない……
0～40%ぐらいまでしか上がったこと無いんだけど

58 ：
行列計算は用意された関数を使ってるわけじゃなく自前？
だとしたら普通にその計算が重いだけだと思う
昔自前で座標変換してたコードを発掘してみたら三角関数たっぷりの糞重そうなコードだった
１万パーティクルというと頂点数はその数倍あるだろうし、その上ソートとかもあるとしたらかなりの重さになると思う
弾幕STGの弾の計算処理との比較での想像だけど

59 ：
>>58
行列計算は主にDXlibのMGetRotAxisがほとんどかな
自前で用意したのは使ってない
1パーティクルあたり6頂点(4インデックス)の長方形の板ポリを
時間経過に合わせて自由に変形できるようにしたりしてる
あともう一つ心配な要素としてパーティクル構造体のメンバがかなり多いことがある
個人的な話だけど今まですごく不自由な環境で真似事みたいなことを長いことしてたから
パーティクル一つ一つの運動や展開にとにかく自由度をもたせた結果、
数えてみると一つのパーティクルごとに(unsigned)charが42、intが26、floatが23 程あった
計算がここからの引用の演算が9割なんだけどこれって影響あるかな

60 ：
MGetRotAxisでも頂点を個別に処理してると重そうだな
何をやろうとしてるのはかよくわからないが、頂点数が多い場合はカメラの側を動かすとかの工夫が要ると思う
頂点一つの変換だけで三角関数が数十回使われるからね
構造体の重さだけど、それが問題になるのはメモリコピーや再配置が行われる場合
つまり、構造体の配列をソートしたり、構造体を関数などに直接渡すときだけ
ソートが含まれる場合は、その配列は構造体のポインタにしておくと早くなる
関数の場合は参照渡しかポインタで

61 ：
3D空間に文字を表示する方法ってある？
リファレンスみたけどそれっぽい関数が見当たらなくて
内容変化するからテクチャーに貼って表示する方法は使えない

62 ：
内容変化するなら毎フレーム描画し直せばいいじゃん？
まぁヘッダ読むと多分見つかると思うよ
未確認だけど

63 ：
更新来てるね
毎度お疲れ様です

64 ：
自分で制作中のプログラムを 3.09 に載せ替えただけで、60 FPS に届くようになった。

65 ：
更新しようと思ったらＶｉｓｕａｌＳｔｕｄｉｏも２０１２とかなってるのかよ知らなかったわ

66 ：
VC++11はconstexpr以下もろもろサポート無しで萎えたんだけど使ってる人いるの
http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx
だいたいXP対応するっつってもツールで対応するみたいだしもうなんか覚えるの面倒くさいしいいや（ﾊﾞｶ
http://blogs.msdn.com/b/vcblog/archive/2012/06/15/10320645.aspx

67 ：
ライブラリの更新ってまだ軽量化の可能性とか残ってるもんなの？

68 ：
少なくともDXライブラリはソース見る限りエラーチェックが一番の重くなる原因だと思うから、まだまだ軽量化はできると思うよ
数年前にはライブラリ作者自身がDirectX生で使うより10倍以上遅いって言ってたし

69 ：
＞①１万枚が１つのテクスチャを使用していて、且つ全く動かず、１画像辺り16x16サイズであり、それを１万枚毎フレーム描画する、
という条件でしたらDirectXを直接扱う場合はビデオカードの性能が良ければＤＸライブラリの１０倍以上高速に描画できると思います
＞②動かない、という条件のみ変えて１万枚の画像がランダムに画面上を等速直線運動している(画面端にぶつかったら跳ね返る)という場合ですと
差はいきなり縮まってＤＸライブラリのDrawGraphを使う場合より１．５倍ほど高速に描画できると思います、ただ、ＤＸライブラリの
DrawPrimitive2Dを上手く使用した場合は恐らく速度差は殆ど無いと思います
これだべ？
10倍遅いは誤解を招くべ

70 ：
それだ
うろ覚えだったわ
でも関数によってはまだまだ数倍高速化できるのは事実
描画関係じゃなくね

71 ：
描画関係以外で速度求めるって一体どんな関数使ってんだよ…

72 ：
1フレームに数千回呼び出す関数なんかはエラーチェックでかなり処理食われたりするよ
多数のオブジェクトに別々の動作をさせるようなプログラムだとたまに起こる

73 ：
いや…自分で定義した関数ならともかく、DXライブラリの関数で数千回とか何やっとるん…？

74 ：
想像できないなら想像できないでいいと思うよ

75 ：
性格悪っ！

76 ：
だってめんどくさそうな人だから相手したくないんだもん

77 ：
だったら無視すればいいだけ！

78 ：
アホす

79 ：
自演まるわかり

80 ：
プログラマブルシェーダー２．０を使用できる環境では通常の描画処理にも
ピクセルシェーダーを使用するように処理を変更。

81 ：
DXlibがソースそのままでWindowsStore用のアプリ生成出来ればええな
昔作った奴いつくかそんなに日本語部分多くないから英語でリリースして
外人さんの感想聞きたい

82 ：
まず海外のフリゲ公開サイトにでも登録してみたら

83 ：
>>81
すぐには無理でしょ。
.ＤｘｌｉｂがNETベースのC++/CLIかC#あたりに移植されれば別だが。
当然、自分のゲームソースも同じようにC++/CLIかC#に移植になるけど。

84 ：
更新されてたんで久々に更新したら
SetCreateDrawValidGraphChannelNumでチャンネル数2で良かったものが3必要になってた

85 ：
DXライブラリのソース追っていくのすげーきついな

86 ：
ちょっとお前らの経験則から助言いただきたいんだけど、筋力から物理攻撃力を求める時みたいに
元の数値さえあれば格納しておかなくても計算で導き出せるような項目をわざわざ格納しようかなと
思ってしまう 計算の複雑さ×使用頻度 の目安ってどんなもん？
そういう数値は格納したら格納したで整合性を保つための更新タイミングも考えなくちゃいけないけど
そういう手間も加味して評価するよね、こっちは管理者が更新するようにして解決しようと思うけど

87 ：
何を言ってるかよく良く解らんが、
全てを最新状態に更新する処理を作っておいて、
装備を変えるときとかにそれを呼び出せばいいんちゃう？
（デバフ喰らったりしたときとかはまた別になるのかもしれんけど）
新しい項目を追加したりした時その方が変更楽じゃない？
でもDXライブラリと関係ないよね。

88 ：
>>86
外部ファイルやらDBやらを使ったり、算出にランダム要素などが加わるならキャッシュする。
そうでなければ気にしないかなあ。

89 ：
俺はそういう場合、キャラクラスですべて管理するようにしておいて、
実数値もメンバとして用意しつつ、変化と再計算もメンバ関数にする
アイテムを装備する場合とか能力変化技を受ける場合、そのキャラの装備関数能力変化関数を呼ばせる
その中で毎回再計算関数を呼べば数値は常に最新になるし
そもそも実数値をほとんど使わないとしても、格納しておかないと、規模が大きいゲームになってくるとデバッグが面倒になったりする

90 ：
環境によって作成できる最小テクスチャサイズってあるのかな
MakeScreen(8, 8, TRUE)
と小さい画像作ったんだけど、テクスチャ幅が8以下の画像だと
初期化もされないうえにClearDrawScreenをやってもクリアされないっぽくゴミが残る
これより一回り大きい幅16になるとゴミも消えてくれる

91 ：
>>87-89
ｻﾝｸｽ。とりあえずインターフェイスを計算結果側の項目に絞っておけば
後からどっちにも対応できて良さそうだね

92 ：
初心者です。画像表示のためのラッパクラスを作っていて
画像ハンドルと、DxLibのDrawRotaGraph3の引数と同じ項目（描画位置以外）をメンバ変数として持ち
各メンバに値をSetした後にDraw(int x, int y)で描画できるようにする予定なのですが、
拡大率が1.0倍で回転角度も0度のような、DrawRotaGraph3を使わずともDrawGraphで描画可能な場合、
やはりDrawGraphを使って描画した方が処理が速いのでしょうか？

93 ：
速度のことは必要になるまで考えるな
以上

94 ：
自己解決した
ListUpTexSize関数内で、２のｎ乗ではなくて良い場合の条件に合致するとき
最小サイズ未満の場合が抜けていたのがうまくいかない理由だった
MIN_TEXTURE_SIZEで最小サイズを変更できるけど上記の部分も変更しないと
最小サイズが適用されないことがある

95 ：
>>93
確かに。とにかく突き進んでみます

96 ：
MV1SetMaterialTypeってトゥーン表示に出来るみたいだけど
リファレンスに乗ってない？使い方が分からない…

97 ：
プロローグによくあるような、画面上部にイラストがあって、下部に「むかしむかし、、、」みたいなかんじで文字をだしたりしようとおもってるんですけど、ああいうのってムービー作って再生させてるんですか？
実装しようとするとフェードインアウトとか結構手間がかかりそうで。

98 ：
全然手間じゃない
フェードはフラグを用意しておいて、TRUEなら透明度が255になるまで毎フレーム増やす、FALSEなら透明度が0になるまで毎フレーム減らす、
みたいな感じに組めばすぐできる
そんなのでムービーにするのはバグや相性問題の元だからやめとけ

99 ：
>>98
なるほどー。相性とかあるのか、、、。
わかりました。今日の夜やってみます。

100read 1read
1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
むしろjavascriptでゲーム作ろうぜ (688)
素人がツクールで神作品目指すスレ２７本目 (869)
みんなで「キモオタの大冒険３D」作ろうぜ (416)
シューティングゲーム（非FPS）製作技術総合 (963)
シェーダープログラマが集うスレ (539)
C++でFC版ドラクエっぽいRPGを作る Lv4 (580)
--log9.info------------------
好きな妹キャラ挙げてけ (220)
もしも同じ声優のキャラがみんな同じクラスだったら (334)
喰い逃げしそうなアニメキャラ（シェリル以外） (885)
マクロスＦのランカってぶっちゃけ歌下手だよね ｽﾚ8 (885)
シェリルとランカなぜ差がついたのか？part62 (979)
ガンダムに乗せたら強そうなキャラは？ (385)
Rを吸ってそうなアニメキャラは？ (858)
外見が似ているキャラを挙げるスレ (530)
美形、美少女だから許されてるキャラ (278)
酔って公園で全裸になり捕まりそうな女性キャラ (910)
デジモンテイマーズ☆松田タカト×加藤樹莉★萌えスレ (253)
【ﾐﾙｷｨﾎｰﾑｽﾞ】コーデリア＆エルキュールかわいい3 (457)
こんなイナズマイレブンは嫌だ！ (387)
【クロス】ジョジョの奇妙な東方Project 9【ＳＳ】 (406)
リリカルなのはシリーズの設定を議論するスレ (394)
【キタユメ】ヘタリア男女カプを語るスレ14【総合】 (810)
--log55.com------------------
【人型から】先進ロボット兵器総合 16【UAVまで】
【軍事】軍事系特殊部隊 Part57
かわぐちかいじ「空母いぶき」愛読者スレ19
【軍事】マクロス 第伍拾六船団【技術】
韓国新型戦車K-2 Part107
軍用拳銃を語るスレ FEG PA-63ナバ
信じられないが、本当だ!! Part169
【中野で閑居し】清谷信一part47【ブログで為す】