ゲームプログラマーの技術レベルは高い。 (690ﾚｽ)
上下前次1-新
101(2): 02/08/19 22:04 ID:mF4sVHfd(1) AAS
ゲームプログラマーの技術レベルは確かに高い。
正確には高くなったと言うべきだと思う。
ドラクエIやスーマリ程度ならまだ俺でも何とかなるレベルだと思うけど
HALOクラスになるとぜってー無理。
シェーダーはバンプ使ってるから、タンジェントスペースとか
そういう幾何学的な部分を理解しなきゃならないし
動きのアルゴリズムは力学に精通しなきゃ無理だろうし、
省4
102(1): 02/08/19 22:27 ID:??? AAS
>>101
頑張って、覚えた単語を並べてみたんだな。お疲れ。
103(1): 02/08/19 22:32 ID:hadwfHiP(1) AAS
>>98
大手の会社は自社製ミドルウェアほとんどもってないね。
あってもチーム単位でしか利用されない（特にＫ社）
俺が中堅の会社に転職したとき、入った当初（２年ぐらい前）
あまりの技術の蓄積の無さに愕然としたよ。
大きくなるほど自社製ツールにこだわらないんだなって感じた。
金で買えちゃうからって自社製の物を作らないっていうのはかなり納得いかなかった。
104: 02/08/19 23:00 ID:??? AAS
あーK社ね。つーか、あそこの蓄積しなさっぷりはヤバイだろ。
高気圧B○YとYOU儀王のミドルウェアっぷりにはまいったが。
105(1): 02/08/19 23:21 ID:??? AAS
>>102
そういう意地悪なレスはやめよぅ。
君がその悪癖をちょっとでも我慢すれば、
ここももうちょっとマシになるのに。
106(1): 02/08/19 23:51 ID:??? AAS
>>101
確かに、そういうプログラマーを取り上げてほしい。
普段、表に出てこない分、そこから得るものは沢山あると思う。
ゲームプログラマーによる、高度な技術の紹介になると、
紹介するつもりが、そこらの専門誌より詳しくなりそうで怖い。
山ほどアセンブラでコーディングするらしいしね。
107: 02/08/19 23:52 ID:??? AAS
バンプくらいは今時ハードがやる。
家庭用ゲームの場合、ハードでサポートされないものは
ほとんど採用されない。ハードの機能をうまく使って
なんとかうまくごまかせる場合だけやる。
動きのアルゴリズムも、全部が力学に則って
バカ正直に作ってるわけじゃない。
それっぽく見えるように、うまくごまかして作る。
省5
108(1): 02/08/19 23:53 ID:??? AAS
DirectX9でｱｾﾝﾌﾞﾘの時代ﾌｶｰﾂ
109(1): 02/08/20 00:12 ID:??? AAS
>>108
シェーダー周りだけでしょ？
今までもレンダ周りを作るとなると
どうせアセンブラだったんだし。
正直、面倒が増えただけって感じ。
描画関係なんか全部ハードでやってくれや。
この点では昔のスプライトゲーム機の方が
省1
110: 02/08/20 02:00 ID:??? AAS
>>109
スプライトといっても、レースゲーム「パワードリフト」とかの類だと、3D で
来んだ方が楽な気もする。（あれはスプライトだけで組んだんだそうだ）
111: 02/08/20 02:11 ID:??? AAS
>>105-106
いや、だからゲームプログラマが天才だというのは妄想だって。（もちろん、一部に
例外はいるけど、そりゃゲーム業界に限らん）
CG に関しては、SGI や ATI, それとゲームメーカーでも一部大手にいる研究職
の人間はともかく、他は「論文読んで理解できる」レベルなら十分だし、そこまで
能力を要求されないケースが大半。AI だってそう。
112: 02/08/20 10:45 ID:??? AAS
研究職に比べて総合力は凄いと思うな。少なくとも低くは無い。
113: 02/08/20 13:06 ID:??? AAS
ほな なんで俺の給料はこんな安いんでっか
114: 02/08/20 22:43 ID:??? AAS
ビジュアルノベルとか作ってる奴は除いとこう。
115: 02/08/21 16:35 ID:??? AAS
あれはもはやプログラマー抜きでも作れるからね。
116(1): 02/08/31 23:00 ID:/GiuOGTr(1) AAS
> 大手の会社は自社製ミドルウェアほとんどもってないね。
> あってもチーム単位でしか利用されない（特にＫ社）
体質が古いだけだと思ってたけど、割と当たり前なのかな?
while (true) {
1. あるプロジェクト用に最適化をかけたライブラリを作る。
2. プロジェクト終了後に整備して公開。
3. 別プロジェクトに移る。
省11
117(4): 02/09/01 16:31 ID:emv4FjR0(1) AAS
>103と同じような経験あり。
といっても俺はデザイナーなんだけど。
うちの会社は、ほんとに開発ツールを作らない。
それが有るのと無いのでは効率がぜんぜん違うのに、
デザイナーの上の人に言ってもわかってもらえない。
同期のプログラマに聞いたら、
昔からゲームオンリーでやってた人は、大抵、
省4
118(2): 02/09/01 16:43 ID:??? AAS
>>117
開発ツールって、どっちかというアプリケーションプログラマとしての
経験やスキルがいるからね。
ゲームオンリーでやってきた人はそういうプログラムを作るのは
つまらないと思うだろうし。
大手だったらアプリケーションプログラマを中途で採用して、
開発ツール専業で作ってもらうというのもありかもしれない。
119(1): 02/09/01 17:11 ID:EGQi8DSZ(1) AAS
>>117
なんで優秀なプログラマをツールにまわさなあかんねん。という
考えもある。でもデザイナで自分でツールつくちゃうパワフルマン
もいるよ。愚痴ってる暇があるなら挑戦ぐらいはしたんだよな？
120: 02/09/01 17:52 ID:??? AAS
俺はアプリケーションプログラマだったけど、
プログラムで生成したプロシージャルテクスチャや
フラクタルの美しさに惹かれて、デザイナーに転職したよ。
あんまり大がかりなのは無理だけど、基本的なツールなら１日あれば
十分作れる。不満があれば自分で機能追加。
数式間違えて、不可思議な模様が出たりするのも面白い。
特定の操作でバグが出るなら、バグが起こらないように操作すればいい。
省1
121(2): 02/09/01 17:54 ID:xIdjFJT5(1) AAS
若くてゲームばかり作ってるプログラマにも
プログラマの手抜きと最適化（の思い込み）重視で
ゲームの設計を狭めてしまう人はいる。
手抜きや技術の低さから来る理不尽な仕様を
デザイナーに強制しないようこころがけよう。
122: 02/09/01 17:57 ID:j8AvQ1dX(1) AAS
>手抜きや技術の低さから来る理不尽な仕様を
>デザイナーに強制しないようこころがけよう。
無理でしょ、根本的に。そういうのを強制すればするほど、
パフォーマンスは上がるんだから。(w
123(3): 02/09/01 17:59 ID:??? AAS
自分が楽をするために仕様を制限するプログラマはいるね。
124(1): 02/09/01 18:15 ID:??? AAS
>123
制限少なくしようと思ったらかなり大変だし。
125(1): 02/09/01 19:12 ID:??? AAS
「定義ファイルはタブは使うなよ。
半角スぺースで桁をそろえろって言っただろう！ 」
ほんとのこと言えよ。
お前らはツールなんてやりたくない。手抜きたいんだろ。
126: 02/09/01 21:29 ID:??? AAS
>>118
大手だと、新卒採用の段階で研究系、ツール系、ゲーム系と間口を用意してる
企業もあるね。
>>124
> 制限少なくしようと思ったらかなり大変だし。
ハード上の制約はどうやっても越えられないし…。
127(1): 02/09/01 22:01 ID:??? AAS
>>123
時間が無制限にあるなら、それでもかまいませんよ。
その場合の責任は、当然あなたが取ってくれますよね？（藁
128: 02/09/01 22:20 ID:LpSDR9P0(1/2) AAS
>116
一番いいのは
while( true )
{
・ライブラリを特定のゲームに特化したカスタムバージョンのライブラリ
を作成して、それでゲームを作成
・プロジェクト終了後に汎用的に使えるもの、特定のジャンルなら流量できるもの、
省11
129: 02/09/01 22:20 ID:LpSDR9P0(2/2) AAS
>117
やっぱそうなんだね。
うちも全て買えばいいっていう考えが主流だよ。
高価なＣＧツールでゲームで使える部分なんて半分ぐらいしか無いのにね。
実際はツールプログラムのほうがプログラム的にもレベルを上げやすいと思うんだけど
（メモリーの制約とかがないからオブジェクト指向とかの色々なプログラミング技法で組める
省5
130: 02/09/01 22:23 ID:wTqfQ1+e(1) AAS
>>123
っていうかそれは常識だろ。
期限内にその仕様は無理だと決める権限はプログラマだろ。
何いってんだ。お前は。
若い時は、まぁ、やってやります！！って思っちゃうけど。
131: 02/09/02 00:24 ID:??? AAS
>>121
デザイナが楽をするためにプログラマにサービス残業させるのはやめよう。
本業がある上に、なんでデザイナのサポートまでしなきゃなんねえんだよ。
デザイナがプログラマのサポートするとこなんか見たことねえのによ。
まあ、１番の問題は、無理なスケジュールを押し付ける役職者にあることに早く気付け。
>>125
最初の取り決めを守れないDQNがいくら吠えても無駄。
省1
132(1): 02/09/02 00:35 ID:??? AAS
なにやら必死な人が多いな（藁
133: 02/09/02 01:03 ID:??? AAS
>>132
ゲームソフト産業は今や斜陽産業ですから。
みなさん生き残りに必死なのです。
134: 02/09/02 01:07 ID:??? AAS
みな、若き日の過ちを苦々しく思っているのだろう
135(1): 02/09/02 01:13 ID:??? AAS
企画がいなくて、
キャラ担当やマップ担当が、そのデータを作る直前に各自で内容も決める。
思いついたが吉日。スケジュールは伸び放題
って仕事もあったよ、昔はさあ・・・
あの頃は俺もまわりの雰囲気にのまれてホイホイ仕様変更したけど
結局責められるのは俺だったなあ･･･
136(1): 02/09/02 01:45 ID:??? AAS
>>135
身につまされるなぁ…
スケジュールが厳しくなると、今度はツール制作や
仕様変更なんかに対応していられなくなって、
>>117 みたいな奴に陰口たたかれるんだよな。
結局どっち転んでもプログラマのせいにされるんだよな。
137: 02/09/02 01:51 ID:??? AAS
毅然とした態度で理路整然と>>127みたいな事が言えたらなぁ・・・・
138(2): 02/09/02 02:57 ID:??? AAS
>>136
全くなぁ。
ツールが（技術的に）作れない奴なんてさすがに居ないだろ、とね。
作れないのは時間的に問題が有ったりするから．．．．。
139: 02/09/02 06:57 ID:OxVR3ylF(1) AAS
>>121
俺の方針としては、２Dの演出関係とかも、全部、３Dツール上で
デザイナーに編集してもらって、拡張アニメーションとして、出してもらってる。
これを、元同僚に話したら「デザイナーの負担がでか過ぎる」と反論された。
これについてはどう思う？
140: 02/09/02 07:14 ID:??? AAS
1.ハードウェア
2.開発環境+デバッグ環境(場当たり的)
3.ライブラリ(使い捨て)
4.ナンダ？
結局は常に1に立ち戻る必要性が有る事が、
業務用アプリとかとの最大の違いとして、
141: 02/09/02 07:27 ID:??? AAS
Xboxまんせー
142(29): 02/09/03 00:35 ID:ELMH1ABY(1) AAS
>>138
正確には「作りたくない」だろうね。
WindowsGUIやMFCなどの知識を習得するのが面倒なのだろう。
個人的に思うのは、ツールプログラムを軽く見ている奴が多すぎ。
ツールなんて誰でも作れると言いつつ、まともなツールを作ったことのない奴がほとんど。
いくら高度なシステムを作っても、インターフェイスがテキストベースで
デザイナーやプランナーに負荷かけて効率や品質落としているようでは意味無いし、
省4
143(1): [???] 02/09/03 00:39 ID:??? AAS
ゲームプログラマーの技術は高いやつが多い。
が、それで面白いゲームが作れるようになるかどうかは
別の話のようだ。
144: 02/09/03 00:44 ID:??? AAS
■ 参考資料： >>143 の発言リスト
2chｽﾚ:gamedev
2chｽﾚ:gamedev
2chｽﾚ:gamedev
2chｽﾚ:gamedev
夏休みは終わったのにネ
145(1): 02/09/03 02:09 ID:??? AAS
>>142
> これからの時代は、システムの実装（＝ライブラリ）から、インターフェイスの整備（＝ツール）までを
> 一貫して構築できるプログラマが求められると思うよ。
分業。
146(1): 02/09/03 02:10 ID:??? AAS
>>142
んなもん一貫して求められネーって。アプリケーションプログラマと
組み込みプログラマの違いわかる？
MAXのプラグインぐらいなら書いてやるけどそれ以上を求められるなら
賃上げ交渉からお願いしたいわ。年齢×１万切ってる給料で求められて
も困りますわ。マジで。
147(3): 138 02/09/03 02:29 ID:??? AAS
>>142
不思議な事を言われているような。
GUIの知識なんて そんな勉強せずとも作れると思うけどなぁ。
>>145の言ってる通り、分業が普通だろうし、
ツール作るプログラマーが普通にいるだろう。
もしもそう言う人が居ないなら、速急に作るべきですな。
148(1): 02/09/03 02:46 ID:??? AAS
>>147
甘い。
DQN会社のDQN管理職どもは、まるでそんなことは分かってない。
ツール作成や社内ネットワーク管理を一生懸命やってると
「遊んでないで仕事しろ」
と言われて、給料下げられるのさ。
149: 02/09/03 03:14 ID:??? AAS
>>147
っていうかゲームそのものがGUIの塊なのにね。142はかなり意味不明。
150: 02/09/03 06:50 ID:??? AAS
一貫して開発しる！なんてのは
給料を年１億ほどもらわないとやってられん
ツールだって立派な売り物になるくらいだ
簡単に作れるわけないだろが…アホか(藁
151(2): 142 02/09/03 07:11 ID:b+KCxfGa(1) AAS
>>146
ツールとシステムを分離すると、物にもよるけど意思疎通が遅れるんだよね。
システムに変更や追加が入るたびにツール側に修正をお願いしなければならないし、
逆にツール使用者の意見をシステム側に反映させるにも時間がかかる。
変更や改良が頻繁におこるのがゲーム開発だから、そこで分業してしまうと非常に効率が悪くなる。
またGUIだけでなくプレビュー（エミュ）機能をつけようと思った場合、システム側と同等の実装が必要になる。
最近は、ＡＩ担当、エフェクト担当、オブジェクト担当、背景担当とパート単位にわけて、
省3
152(1): 02/09/03 13:44 ID:??? AAS
>>151
むにゃむにゃ。あなたの会社のメインプログラマさんは何をやっている
のですか？その意思疎通を一括して行うのがメインPGじゃないのれすか？
話だけ聞いていると相当無能なメインPGさんだと思います。
複数人が同じものを作る事ほど不効率な事はありませぬ。
153(1): 142 02/09/03 17:36 ID:n9Q0aUGU(1) AAS
>>152
複数人が同じ物を作る？？？意味不明。
メインプログラマは、リソースやタスク管理、低レベルIO、あとは各パートをまとめるのが仕事。
例えば、オブジェクト担当なら、実機でのオブジェクト表示やモーション再生を実装すると同時に、
市販ツールなどからデータをコンバートするプラグインも書く。
エフェクト担当は、実機でパーティクルシステムを実装すると同時に、
ジェネレータを組み合わせてエフェクトを構築するツールも作る。
省3
154(2): 02/09/03 21:34 ID:X3bsDIkZ(1) AAS
うちは、専卒のバイトにプラグインからコンバーターまで
一通りやらせてますが何か?w
155: 02/09/03 21:54 ID:rbHcpDCj(1) AAS
>>148
そんな会社の馬鹿窓から投げ捨てろー
一番のリストラ対象だ。
と言って自分から会社を飛び出しましょう。
>>151
ライブラリーにしてまとめれば、
実装はほとんど考えなくてええんちゃうん？
省2
156(2): 02/09/03 22:12 ID:??? AAS
>>153
そりゃあんたの
>最近は、ＡＩ担当、エフェクト担当、オブジェクト担当、背景担当とパート単位にわけて、
>それぞれがシステムの実装から、ツールやプラグインの整備までを行うのが主流になりつつあると思うけど
の部分へのレスですが？なんか読み違いしてる？
>だいたい最近はメインプログラマがすべてを把握できる規模じゃなくなっているのよ。
まぁここを読めば大体言いたい事はわかりますた。でも規模が大きく
省1
157(2): 142 02/09/03 22:34 ID:??? AAS
>>154
つまり、あんたの会社は所詮その程度のレベルってことだね（藁
俺は中小から大手組みの人間だけど、
結局、中小と大手のプラグインやツールに対する認識の差が技術力、開発力の差に繋がってんだよね。
なんか中小へぼメーカーの人間って驚くほどツールに対する認識が甘い。
プラグインやコンバーターなんて下っ端の仕事だと考えている。
逆に大手では最先端のＣＧ知識をもったプログラマがプラグインを書いてグラフィッカーを支援している。
省12
158: 02/09/03 23:12 ID:??? AAS
>>157
つーかもう学校はじまってんじゃねーの？早く寝ろよ。
159: 02/09/03 23:16 ID:??? AAS
>>157
イタタ…。ムキになるなよ。みっともない。
160(1): 02/09/03 23:45 ID:??? AAS
>大手じゃ、エフェクトやメニューなんて市販ツールからコンバートかけてるし、
>イベントは、市販ツールから出力したデータ元に、専用ツールで編集してるし、
>背景の頂点カラーなんて、フォトンマップ使ったプラグインで自動計算よ。
必死で覚えた言葉を総動員するのはいいけど、こんなの中小でも普通です。
それでもこだわりのデザイナは最後に手動で頂点カラーつけるがな。という
か今時頂点カラーってのはちょっとダサすぎなぐらい。
それにしてもワナビー臭がぷんぷんする文章だな。
161(1): 02/09/03 23:46 ID:??? AAS
142じゃないけど、>>156はワナビーっぽい。
最後のセリフは、FFの技術を語っているときにシナリオが・・・と語り出す厨みたい。
162: 02/09/03 23:54 ID:??? AAS
>>161
ん？そう？ゲームプログラマの技術はゲームを面白くするために
あると思ってるからね。新しい技術を身につけるのはそりゃ面白い
けどそれが品質アップに繋がらないのは本末転倒だと思わない？
海外のゲームエンジンの考えって技術の前にゲームデザインあり
きだと思うし。（一応そういうスレだし）
ま、厨っぽい事には否定はせんが。
163(1): 02/09/03 23:58 ID:??? AAS
>>160
フォトンマップ使ったプリライティングを普通ですなんていっちゃうなんてスゲーな（藁
そんなの大手でもどこもやってねーべ。
せいぜい市販ツールのラジオシティ機能使って焼き付けるぐらいだろう。
142も痛いが、言葉の意味も知らずに普通ですなんていっちゃう160も痛いね。
そんな中小が無理せんでも…。
164(1): 154 02/09/04 00:02 ID:I4i7Lcwo(1/4) AAS
あー、その程度の会社のバイトの154だ。w
否定はしないよ。それまでに作られたツールのソース見たけど、
吐き気がするほど汚かったし、Win32APIだし、リソースファイ
ルも使ってねーし、未だにCだしで、まぁ、そんなレベルだ。w
ちょっと愚痴っちゃうけど、もう、そのツールにバグが出るた
びに酷い目にあってるんだ。(メンテもやらされてんのよ。泣)
グローバル変数多すぎてもうどこがどこかわかんねーんだよ、
省8
165: 02/09/04 00:22 ID:??? AAS
>>163
あれ？FinalRenderってフォトンマップじゃなかったけか？あちゃー
強烈に勘違い。逝って来る。とはいえ、自分でフォトンマップレンダ
書くわけじゃないのならあんまり差はない気が（汁
>>164
大手はツールを起こすに値するデザイナがいるってことも重要じゃない？
使い手あってこそのツールだし。まぁそのツールはひどすぎるが。
166(3): 02/09/04 00:31 ID:??? AAS
え、頂点カラーって、今時ダサい技術なんだ。
じゃ、いったいどんな方法使ってんの?
･･･あ、企業秘密か。失敬失敬(w
167(1): 02/09/04 00:43 ID:??? AAS
>>166
マジレスすると、ライトマップ。呼び方は社によって違うかも知れ
ないけど単に陰影をテクスチャに落としてマルチテクスチャで張るだけ。
特別な事でもなんでもないね。
168: 02/09/04 00:46 ID:I4i7Lcwo(2/4) AAS
ゲームぐらいポリゴン荒いとフォトンマップかラジオシティか
より、メッシュをどう分割するかの方が大事な気がするが。
かといってツールが勝手に割っちゃっていいですか？って言う
とそれは困るとか言われちゃうんですが。w
169: 02/09/04 00:49 ID:??? AAS
途中で142名乗るのやめたのか・・・？
170: 02/09/04 00:50 ID:I4i7Lcwo(3/4) AAS
うちもマルチテクスチャぐらい当たり前になってほすぃ・・・。
171: 02/09/04 01:06 ID:??? AAS
どうでもいいけど、デザイナーが工夫してローポリ化した解像度の低いモデルに
ラジオシティーとか、フォトンマップとかの色を頂点単位で焼き付けると酷いこと
にならないかなぁ？（ライトマップテクスチャを作るのならともかく）結局
どちらにしろ手修正が必要な気が…。
ラジオシティーまでいかなくても、今できる動的ライティングでかなりゲームの印象
は変わる気がする。
外部ﾘﾝｸ[htm]:users.pandora.be
172(1): 166 02/09/04 01:10 ID:iLcFjOBz(1) AAS
お、(wなんて書いたのに、レス帰ってきた。
嬉しいんで、も少し質問していい？
今うち、ＰＳ２エンジンの転換期なんで、
質を上げれる情報なら、何でも聞いておきたいんだよ。
ライトマップ(?)の、ポリゴンで作る影/頂点カラーの影と
比べてのメリットデメリット、よかったら教えてもらえる？
カプコンの鉄騎とか、ＰＣゲームでよくその手法見るけど、
省3
173: 02/09/04 01:22 ID:??? AAS
>>172
いや、メリットは168が言ってる事が回避出来るからじゃん。
描画コストと頂点演算コストを図りに掛けて描画コストの方が
全然余ってるからだけど。
ドットブツブツはバイリニアである程度はなんとかなるけど、
こればっかはしょうがないね。テクスチャ解像度増やせばナントカ
なるけど、その辺は作るゲーム内容にもよるし。
省2
174(1): 02/09/04 01:35 ID:I4i7Lcwo(4/4) AAS
メモリは頂点カラーに比べてライトマップ分余計に
食うし、そのライトマップも頂点カラー以上の解像度(?)
を持っていなければ意味ないだろうから、容量的に結構
きついものがありそうだな・・・。
175: 02/09/04 01:42 ID:??? AAS
>>174
濃淡のいらないテクスチャならCLUT弄れば4bitが1bit×4として扱えるじゃん？
0001,0010,0100,1000の４つを切り替えるわけね。これを使えばメモリは結構開放
されると思うけど。（絵的にはキチャナイから2bit×２のがマシかも）
ま、こればっかはゲームの種によるのでご自分の判断でどうぞとしか言えません。
176(3): 02/09/04 02:07 ID:oIlJt/Uu(1) AAS
ライトマップは今時普通なんだ。
マルチテクスチャは、フィルレート半分だし、微妙だなー。
ツールプログラムは、経験ないなー。
エクスポーター（というか、クラスのセーブ）自分で書く。
ぐらいはやらされたけど。
ツールの人は、プレビュー用のインポーター＆インターフェイスを担当。
177(1): 02/09/04 02:33 ID:??? AAS
頂点カラーでパースが付かないハードでも
マルチテクスチャなら付いたりする不思議。
178: 02/09/06 20:32 ID:7VVzpWZF(1) AAS
もっと知りたいあげ。
179: 1 02/09/06 21:10 ID:??? AAS
こんな長続きするとは思ってもみなんだ
180(2): 142 02/09/06 22:17 ID:VhDMMzQq(1) AAS
>>167
頂点カラーがダサイというから、頂点毎の球面調和係数を用いた動的ライティングでも語ってくれるのかと思いきや、
ライトマップ（プ。
せめてパーピクセルライティングぐらいにしてくれませんかね。
最近やっとライトマップの存在を知って嬉しくてたまらないんでしょうか。
>>176
マルチ’パス’テクスチャの間違いでわ。
省3
181: 02/09/06 22:23 ID:??? AAS
人違い。
上下前次1-新書関写板覧索設栞歴
あと 509 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s