atwiki-logo
  • 新規作成
    • 新規ページ作成
    • 新規ページ作成(その他)
      • このページをコピーして新規ページ作成
      • このウィキ内の別ページをコピーして新規ページ作成
      • このページの子ページを作成
    • 新規ウィキ作成
  • 編集
    • ページ編集
    • ページ編集(簡易版)
    • ページ名変更
    • メニュー非表示でページ編集
    • ページの閲覧/編集権限変更
    • ページの編集モード変更
    • このページにファイルをアップロード
    • メニューを編集
    • 右メニューを編集
  • バージョン管理
    • 最新版変更点(差分)
    • 編集履歴(バックアップ)
    • アップロードファイル履歴
    • ページ操作履歴
  • ページ一覧
    • ページ一覧
    • このウィキのタグ一覧
    • このウィキのタグ(更新順)
    • このページの全コメント一覧
    • このウィキの全コメント一覧
    • おまかせページ移動
  • RSS
    • このウィキの更新情報RSS
    • このウィキ新着ページRSS
  • ヘルプ
    • ご利用ガイド
    • Wiki初心者向けガイド(基本操作)
    • このウィキの管理者に連絡
    • 運営会社に連絡(不具合、障害など)
ページ検索 メニュー
FPSを作ってみる@wiki
  • ウィキ募集バナー
  • 目安箱バナー
  • 操作ガイド
  • 新規作成
  • 編集する
  • 全ページ一覧
  • 登録/ログイン
ページ一覧
FPSを作ってみる@wiki
  • ウィキ募集バナー
  • 目安箱バナー
  • 操作ガイド
  • 新規作成
  • 編集する
  • 全ページ一覧
  • 登録/ログイン
ページ一覧
FPSを作ってみる@wiki
ページ検索 メニュー
  • 新規作成
  • 編集する
  • 登録/ログイン
  • 管理メニュー
管理メニュー
  • 新規作成
    • 新規ページ作成
    • 新規ページ作成(その他)
      • このページをコピーして新規ページ作成
      • このウィキ内の別ページをコピーして新規ページ作成
      • このページの子ページを作成
    • 新規ウィキ作成
  • 編集
    • ページ編集
    • ページ編集(簡易版)
    • ページ名変更
    • メニュー非表示でページ編集
    • ページの閲覧/編集権限変更
    • ページの編集モード変更
    • このページにファイルをアップロード
    • メニューを編集
    • 右メニューを編集
  • バージョン管理
    • 最新版変更点(差分)
    • 編集履歴(バックアップ)
    • アップロードファイル履歴
    • ページ操作履歴
  • ページ一覧
    • このウィキの全ページ一覧
    • このウィキのタグ一覧
    • このウィキのタグ一覧(更新順)
    • このページの全コメント一覧
    • このウィキの全コメント一覧
    • おまかせページ移動
  • RSS
    • このwikiの更新情報RSS
    • このwikiの新着ページRSS
  • ヘルプ
    • ご利用ガイド
    • Wiki初心者向けガイド(基本操作)
    • このウィキの管理者に連絡
    • 運営会社に連絡する(不具合、障害など)
  • atwiki
  • FPSを作ってみる@wiki
  • 進捗状況(2014
  • 01)

FPSを作ってみる@wiki

01)

最終更新:2014年01月23日 23:25

Bot(ページ名リンク)

- view
管理者のみ編集可

(2014/01/23)

Kdevelop(Kd)がイケてないからQtCreator(以下Qc)にすると言った矢先
QcはQcでデバッガやUIは問題ないもののエディット時に勝手に構文解析が走って
0.5秒とか無視できない範囲でプチフリーズが頻発するから困る。
Kdもそうなんだけどここまで酷くはなかった。

そもそも両者混みいったC++のキーワードを補完してくれないので「やっぱりVisualC++のIntelliSenseはサイコーだったな・・」と、
遠い目をする事多し。
エディタが使いにくいと制作意欲へのダメージも結構なもので、
プログラマはエディタにこだわると言われるのは好みの問題なんかではなく必然なのだ。

ここで気になるのがClangの構文解析エンジンを利用したVimの補完プラグインの存在で、早速Vimの復習から入り
.vimrcをみようみまねで書いてclang_completeやneobundle, neocomplete等を導入。
補完機能をひと通り試してみた。
ソースがマクロマクロしていてもメンバ変数や関数をちゃんと補完してくれるのはIntelliSenseを離れた身としては感動ものである。
補完の速度もまずまずだし、なんならオート補完を切ることもできる。

残るはビルドコマンドやデバッグ環境の整備だが・・
ビルドコマンドはまたの機会にするとしてデバッグはこれからもQtCreatorのお世話になりそう。
関数や変数の定義に一発で飛ぶプラグインとかも調べないといかんね。

そんな訳で現状エディットはgVimで、ビルドとデバッグはQtCreatorという形になっている

ゲームの方

くだらないミスをして一回休み。

ウィンドウが最小化されるとOpenGLのリソースを全開放、復帰させる仕様なのは承知の通り。
FPS値を表示するために毎フレーム文字列テクスチャを作成して表示するような事をしていて
1. メインスレッドがフォントテクスチャを作成、描画スレッドに渡す用のバッファに入れる
        この時OpenGLのリソース値を直接記載
2. ウィンドウ最小化
3. 描画スレッドが(すでに破棄された)フォントテクスチャを使う
4. エラー発生!
という流れでPCがフリーズしたりSEGVで落ちたりしてた。

場合によってエラーになったりならなかったりするんでかなり苦戦。

(2014/01/21)

描画スレッド

描画スレッドの実装、完了。そこそこ苦戦というか。
今までは例えばテクスチャのフィルタリング方式を変更したいとなった場合に即OpenGL APIを呼んで変更を伝えれば良かったが
マルチスレッドにした関係上すぐに変更しては描画スレッドがテクスチャを使っていた場合に不具合(最悪落ちる)が起こるので
次回描画スレッドが動いた時まで遅延させる等の処理が必要となった。
更にちょうどその時フレームスキップが起こったら変更が反映されないのでスキップされた時でも対処できるような仕組みとか、色々。

結果としてOpenGLのテクスチャとか頂点バッファ等の関連クラスを半分以上書き換える形に。
シングルスレッドで動いていたものを後からマルチスレッドにするのは大変だ。

アルゴリズムが上手く動いていれば描画スレッドが描画ソート(予定)と描画コールしてる間に
メインスレッドが次フレームのゲーム処理や描画タスクの準備をして
描画タスクはダブルバッファになってるのであるタイミングでそれを切り替えて・・・という感じで進む筈。

残る問題

シングルContextの時にデッドロックする問題が残っていて一応原因は判明してるものの・・ま、どうでしょう。
すぐ修正できればいいけど。
あとシングル時にメインスレッドでOpenGL関数を呼ぶと描画スレッドにポストして描画スレッドが暇になった時に処理、メインスレッドはそれが終わるまで待機という設計なんだけど
現状では「暇になった時 = フレームの描画をし終えた時」だけなので場合によっちゃかなり待たされるかもしれない。
適度にメッセージループを回してあげる必要がある。(でも面倒なので後)

(2014/01/15)

また間が空きそうなのでここで一旦報告。

ContextSharing出来ない環境

OpenGL APIでContext Sharingが利用できない環境(主に古いビデオドライバやAndroid)の対処を行った。
SharingしてるならそのままAPIを呼び、そうでないなら描画スレッドに要求をポストして終わるまで待つ。
言葉にするとたった一行なんだけど今までに使ったAPIを全箇所修正したり
描画スレッドにポストする部分の実装(APIに戻り値がある時の対処。voidの扱いなど)や、
リソースの開放順序が不味いらしく
アプリケーション終了時にSharing環境では問題ないのにSharingしてない場合だとSEGVになるとかあって結構時間かかった。

引き続き

描画のマルチスレッド対応に関する作業を続ける。
次はメインスレッドから描画スレッドにタスクを投げてゲーム進行とは別に描画させる処理。
こちらも苦戦が予想されるが、果たして・・

(2014/01/10)

詳細という程でもなかった

詳細は後日。などと書くと
「ちゃんとした記事にしなきゃいけないのでは。もうちょっとネタが溜まってから整理して書くべきなのでは」
となって億劫になる事がわかった。なので今後そういうのは無しにする。
前回に関して言えば単に説明文を考えるのが面倒という理由だけで「詳細は後」と書いてしまったのが失敗の要因である。
肩の力を抜いて不定期更新、記事の質もバラバラとした方が更新を継続する点で有利か。

windows版

散々苦戦したけどwindows版がサウンド、グラフィックなど全部linux版と同じ様に動いた。
  • win8で30fpsになってしまう問題
これは割と単純。winXPはVSyncがデフォルトでOff, win8はOnになっているんだけど
ゲームの更新タイミングは自前で管理しているのでVSyncの同期待ちとアプリケーションのそれが微妙に噛み合わない時に
フレームスキップ機能が働いて1フレームスキップされて30fpsになっていた。
従ってOpenGLのVSyncを明示的にOffにすれば解決。

  • winXP, win8両方でウィンドウを最小化した後にポリゴンが描画されなくなってしまう問題
原因の特定までかなり苦戦した。linuxやwineで発生しなくてwindowsだと確実に発生するという。
結論から言えばグラフィックボードのドライバに起因した問題。
(wineはlinuxのドライバを使う)
何故描画されないかと言えば、深度テストに失敗していた。
ちゃんとglClearDepth()とglClear(GL_DEPTH_BUFFER_BIT)で初期化したと思っても
設定によっては深度バッファがクリアされない時があるのだ。

当方RadeonなのでGeForceは知らないが少なくともAMD Catalystドライバ環境で
glDepthWrite(GL_FALSE)でZの書き込みをOffにしたまんまglClear(GL_DEPTH_BUFFER_BIT)を呼んだ際
linux(ubuntu 32bit)版のドライバでは深度バッファがクリアされるが
winXP(32bit), win8(64bit)版では何も起こらない。

はい。非常に大事なことなのでもう一度。
深度バッファをクリアする時は必ず
glDepthWrite(GL_TRUE);
glClear(GL_DEPTH_BUFFER_BIT);
こうね。

  • win8でウィンドウを最小化した後にフリーズする
上記の原因究明でソースコードを色々いじってたらいつの間にか発生しなくなっていた。
恐らくOpenGLコンテキスト解放のタイミングを変えた時だったと思うが・・
(OpenGLのリソースを全て開放した後にコンテキストを解放するつもりが、そうなってなかった)

ゲームスレッドと描画スレッド

ゲームとして動かすには依然として問題が。
現状ゲーム進行や当たり判定等の処理を行うゲームスレッドとOpenGLのAPIを呼んでGPUにコマンドを送る描画スレッドが分かれているのに
そのあたりのデータ管理とか同期を全く実装してない。
今まではテスト用にポリゴン一枚表示出来れば良くて、描画スレッド側でポリゴン座標や頂点バッファの初期化をしていたから
問題にならなかっただけの話だ。
でも描画スレッドでデータの読み込みや何やらしてたのでは折角スレッドを分けた意味がない訳で。何とかしなきゃイカンと。

それとOpenGLのContextSharingが利用できない状況(主にAndroid)ではContextを1つだけ作って描画スレッドに持たせ、
メインスレッドから何かOpenGL APIを使った処理をしたい場合は描画スレッドにタスクを投げて処理してもらう仕組みも必要なんだが
それもまだ。
一応スレッド同期のデータ構造と「だいたいこんなんかな〜」といったアルゴリズムのメモ書きくらいはあるけど。

(2014/01/08)

取り急ぎ急いでないけどwindowsでも完動しました報告。
スクリーンショットのためにウィンドウを無理やり小さくしたので文字がボサボサなのは仕様。
imageプラグインエラー : ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (sdl_winxp.png)
詳細はまた後で。

(2014/01/07)

自作エンジンがwineで動いたし、前回の修正によりwindowsでもフリーズすることなく動いた・・・これで安心

とは行かず、例によって例のごとく不具合発生。しかもwinXPとwin8で挙動が違っていた。
具体的には
winXP: 60fpsで動作。ウィンドウ最小化した後の復帰時はサウンドも問題ないが、何故かポリゴンの描画がされなくなる(画面クリアは効く)
win8: 30fps位で動作。ウィンドウ最小化した後のサウンドも問題ないが、フリーズする(恐らくOpenGL API関連)
更にvirtualboxへインストールしたwinXPでも試したらこちらはOpenGLのContextSharingに対応してない様子で描画出来ず。
winXPとwin8で動作速度が違うのは垂直同期設定のデフォルトが異なってるからだろうと思い、インターバルを0にしてみるも改善されなかった。

とりあえずプログラムをシンプルにしてGLSLを使わない昔ながらのglBegin()〜glVertex3f()〜glEnd()の形式で
描画してみたらこれは普通に動くので、これはGLSLかVBOやIBOの設定で何かミスってる可能性大。

(2014/01/05)

ここに来て大域照明に興味が出だしたけどここはグッとこらえてweb記事を見るだけにしておく。
その前に基本的なシャドウマップをやっておきたい。

windows版の不具合

windows版でアプリケーション終了時にフリーズしてしまう問題。
かなり究明に時間を食ってしまったが
thread_local(TLS)宣言した変数を、std::threadを介さずwindowsのCreateThreadや_beginthreadexを通して触っていた事が原因のようだ。
std::thread以外のAPIで作った子スレッドからTLS変数を参照すると子スレッドのルーチンが終了した後でも
親スレッドからは終了とみなされずそこで固まってしまう。
ちなみに親スレッドからTLS変数を使う分には問題ないが、たまたま上手く動いてるだけとも限らない。

あとこれはwineでのみ発生する不具合なのだがサイズ固定のウィンドウを一旦最小化してもとに戻すと
60x60位のサイズに復元されてしまい、サイズ固定なのでユーザーはにっちもさっちも行かなくなる。
この為wineで試す際はRESIZABLEに設定する必要があった。

#追記
上記のフリーズ問題を解決し、ようやくWindows版が動く段階まで来た。

現時点で予定してるデモは
  • サウンドの再生、停止、ウィンドウの最小化による一時停止と復帰
  • OpenGLによるポリゴン表示
  • キーボードとマウス入力
  • 文字列描画
  • ファイル読み込み
要するにOpenGLとSDLとFreeTypeとOpenALのテスト。

見た目としては前に書いたように画面中央に立方体が回ってるだけなので、ぶっちゃけ動かしても面白くないと思う。
しかし作業を一旦区切る意味でもここらでアップしておこうかと。

その後はAndroidで動かしてみるか、ゲームっぽいもの作ってみようか、
視覚に訴える要素(リアルタイムシャドウ)でも入れようか・・・迷っている

(2014/01/04)

ぼちぼちWindows版が動いてる
フォントをLinuxと同じ様に表示できて、キー入力もちゃんと効く。音も大丈夫。
年明け丸3日経ってまだそこか!っていう意見については、まぁ、そうだねぇとしか。

で、大体動きはするんだけどアプリケーション終了時、スレッドの同期のとこでwindows版だけが内部でデッドロックしてるのか止まってしまって調査中。
linux版はちゃんと動くのに、何が悪いのか。

#追記
とりあえず今回はバグの原因を大体突き止めたから良いものの
相変わらずMinGWでコンパイルしたプログラムのデバッグ効率が悪すぎる。
なんかwin機をリモートで動かしてデバッグというのが出来るらしいが、自分にそこまでのスキルが無い。

(2014/01/01)

自作ライブラリを組み込んだプログラムをMinGW一回ビルドするのに
最後のリンクだけで1分は余裕で掛かるの何とかして欲しい。
(ちなみにLinux用は20秒程度)

パス

通常、linuxでパスを記述する時は
絶対: /AAAA/BBBB
相対: CCCC/DDDD
のようにして

windowsのパスだと
絶対: C:\AAAA\BBBB
相対: CCCC\DDDD
という感じになる。

パスクラスに入力する時はスラッシュとバックスラッシュを自動で統一するようにしたんだけど先頭のドライブ文字の対応を忘れていた。
対応しなければ・・

(2014/01/01)

新年あけまして進捗どうでしょう?<●> <●>

駄目でした><

等とやってる場合じゃない、ことよろ。

アラインメントずれの原因

先日触れたalignas(16)してるのに16byteアラインされてない問題を、あれからもう少し調べてみた。
SDL_Threadが絡んでるのはほぼ確定かなと。
具体的にはMinGW w64 & SDL2においてSDL_CreateThread()でスレッドを作成し、子スレッドでalignas(16)した構造体やクラスをスタックに置くとずれる。

ずれる幅の条件がいまいちわかってないのだが
自分の環境だとmainからすぐスレッド作ってその内部のスタックで
アラインメント指定の構造体を作ると4byteずつズレている。
windowsプログラムでは本来WinMainから始まるが
SDLmainによりlinux等と同じ様にmain関数から始まるようにすると今度は8byteずれる。
孫スレッドを作ってみてもズレ幅は変わらないようだ。

ちなみにWinAPIのCreateThread()や、_beginthreadex()ではズレない。
SDL_Threadのソースをちらっと見ると内部で同じ様に上記の関数を呼んでいるが・・・?
インラインアセンブラ使ってる部分がちょっと怪しい。
この辺はもうちょっと読まないとわからないか。

最初はSDLのビルド済みMinGW用バイナリが変なのかなと思い、自分でリポジトリから取ってきてビルドしてみたけど変わらず。
勿論ググった所で探し方が悪いのか何も出やしない
こうなると自分でライブラリのパッチを作るか諦めてwindowsで動くpthreadライブラリを使うなど別の手段をとるかになる。
pthreadで統一するのも悪くはないが、あまりSDL以外のライブラリに依存するとSDLを使う意義が薄れる。
もし3,4行の修正でSDL_Threadが動くならその方が楽なのだが。アラインメントの問題だけだし。

そもそもalignasした変数をスタックに置く時にどういった処理をしているんだろう。
SDL_CreateThreadの子スレッド経由でThreadFuncを呼ぶとずれるが、親スレッドから直接呼べばズレない。
構造体のサイズはalignasの時点で揃えられてしまうんだろうけどメモリのオフセットは実行時に決めている?

追記)原因は

結論から言えばSDLにバグがあるわけではなく、スタックアラインメントの問題。

gccは速度のためにスタックポインタのアラインメントをデフォルトで16byteに合わせているのだが
当然その調整にメモリを余計に食ってしまうので任意でアラインメントサイズを変更できる。
それがgccの-mpreferred-stack-boundary=N (Nは2の乗数倍を表し、N>=2とする)オプションだ。
組み込み用途なんかで速度よりメモリを節約したい場合は2を指定し、そうでないならデフォルト(=4)やそれ以上に設定する。

で、注意しなければならないのは
Nが小さい設定でコンパイルされたルーチンからNが大きい設定のルーチンを呼ぶとアラインメントがずれたままになる
大変重要な事なのでもう一度言う。
Nが小さいルーチンからNが大きいルーチンを読んではいけない

どうしてか?と聞かれても当方gccに詳しくないのでわからんとしか言えないが
gccのリファレンス
ページ中盤
To ensure proper alignment of this values on the stack, the stack boundary must be as aligned as that required by any value〜〜〜 の辺りに書いてある。

対策

SDLのライブラリは既存のバイナリを使うとNが2なので不具合が起こる。従って自分でビルドする
とはいえ何も難しいことはなく、何時ものように
./configure --host=i686-w64-mingw32 (...あと適当にオプション)
と打ち、Makefileを作ったらおもむろにテキストエディタで開き
EXTRA_CFLAGS = -Iinclude -I../include  -mmmx -m3dnow -msse -mpreferred-stack-boundary=2 -Wall
となっている行のmpreferred-stack-boundaryの項目を消しておく。
後は普通にmakeすればOK。
「01)」をウィキ内検索
LINE
シェア
Tweet
添付ファイル
  • gvim.jpg
  • gvim.png
  • sdl_win8.png
  • sdl_winxp.PNG
FPSを作ってみる@wiki
記事メニュー
  • トップページ
  • 参考資料ブックマーク等
  • Tips

Media

  • 頂き物
Screen shot
  • FPS_page1
  • FPS_page2
  • FPS_page3
  • Other_page1
Drawing
  • Drawing(analog)
  • Drawing(digital)
  • Drawing(digital) 2
  • Drawing(digital) 3
  • Drawing(digital) 4
  • Drawing(digital) 5
  • Drawing(digital) 6
  • Drawing(digital) 7
  • Drawing(digital) 8
  • Drawing(digital) 9
  • Drawing(digital) 10
  • Drawing(digital) 11
  • Drawing(digital) 12
  • Drawing(digital) 13
Movie
  • movies-list

Old Contents

  • トップページ(old)
  • メモ書き
  • 力仕事UP場
  • ゲームシステムとか
  • バグ・動作報告
  • program(twilve)

Progress log

  • (2018/03)
  • (2017/04)
  • (2017/03)
  • (2016/10)
  • (2016/09)
  • (2016/08)
  • (2016/07)
  • (2016/06)
  • (2016/05)
  • (2016/04)
  • (2016/03)
  • (2016/02)
  • (2016/01)
  • (2015/12)
  • (2015/11)
  • (2015/10)
  • (2015/09)
  • (2015/08)
  • (2015/07)
  • (2015/06)
  • (2015/05)
  • (2015/04)
  • (2015/03)
  • (2015/02)
  • (2015/01)
  • (2014/12)
  • (2014/11)
  • (2014/10)
  • (2014/09)
  • (2014/08)
  • (2014/07)
  • (2014/06)
  • (2014/05)
  • (2014/04)
  • (2014/03)
  • (2014/02)
  • (2014/01)
  • (2013/12)
  • (2013/11)
  • (2013/10)
  • (2013/09)
  • (2013/08)
  • (2013/07)
  • (2013/06)
  • (2013/05)
  • (2013/04)
  • (2013/03)
  • (2013/02)
  • (2013/01)
  • (2012/12)
  • (2012/11)
  • (2012/10)
  • (2012/09)
  • (2012/08)
  • (2012/07)
  • (2012/06)
  • (2012/05)
  • (2012/04)
  • (2012/03)
  • (2012/02)
  • (2012/01)
  • (2011/12)
  • (2011/11)
  • (2011/10)
  • (2011/09)
  • (2011/08)
  • (2011/07)
  • (2011/06)
  • (2011/05)
  • (2011/04)
  • (2011/03)
  • (2011/02)
  • (2011/01)
  • (2010/12)
  • (2010/11)
  • (2010/10)
  • (2010/09)
  • (2010/08)
  • (2010/07)
  • (2010/06)
  • (2010/05)
  • (2010/04)
  • (2010/03)
  • (2010/02)
  • (2010/01)
  • (2009/12)
  • (2009/11)
  • (2009/10)
  • (2009/09)
  • (2009/08)
  • (2009/07)
  • (2009/06)
  • (2009/05)
  • (2009/04)
  • (2009/03)
  • (2009/02)
  • (2009/01)
  • (2008/12)
  • (2008/11)
  • (2008/10)
  • (2008/09)
  • (2008/08)
  • (2008/07)
  • (2008/06)
  • (2008/05)
  • (2008/04)



記事メニュー2

Update Log

取得中です。
人気記事ランキング
  1. Drawing_analog
もっと見る
最近更新されたページ
  • 2686日前

    menu_L
  • 2686日前

    進捗状況(2018/03)
  • 2686日前

    Drawing_digital_13
  • 2686日前

    Drawing_digital_12
  • 2686日前

    トップページ
  • 2892日前

    Drawing_digital_11
  • 2973日前

    Drawing_digital_10
  • 3005日前

    進捗状況(2017/04)
  • 3046日前

    進捗状況(2017/03)
  • 3097日前

    頂き物
もっと見る
人気記事ランキング
  1. Drawing_analog
もっと見る
最近更新されたページ
  • 2686日前

    menu_L
  • 2686日前

    進捗状況(2018/03)
  • 2686日前

    Drawing_digital_13
  • 2686日前

    Drawing_digital_12
  • 2686日前

    トップページ
  • 2892日前

    Drawing_digital_11
  • 2973日前

    Drawing_digital_10
  • 3005日前

    進捗状況(2017/04)
  • 3046日前

    進捗状況(2017/03)
  • 3097日前

    頂き物
もっと見る
ウィキ募集バナー
新規Wikiランキング

最近作成されたWikiのアクセスランキングです。見るだけでなく加筆してみよう!

  1. MadTown GTA (Beta) まとめウィキ
  2. AviUtl2のWiki
  3. R.E.P.O. 日本語解説Wiki
  4. 機動戦士ガンダム EXTREME VS.2 INFINITEBOOST wiki
  5. シュガードール情報まとめウィキ
  6. ソードランページ @ 非公式wiki
  7. ドラゴンボール Sparking! ZERO 攻略Wiki
  8. シミュグラ2Wiki(Simulation Of Grand2)GTARP
  9. 星飼いの詩@ ウィキ
  10. Dark War Survival攻略
もっと見る
人気Wikiランキング

atwikiでよく見られているWikiのランキングです。新しい情報を発見してみよう!

  1. アニヲタWiki(仮)
  2. ストグラ まとめ @ウィキ
  3. ゲームカタログ@Wiki ~名作からクソゲーまで~
  4. 初音ミク Wiki
  5. 検索してはいけない言葉 @ ウィキ
  6. 機動戦士ガンダム バトルオペレーション2攻略Wiki 3rd Season
  7. 発車メロディーwiki
  8. Grand Theft Auto V(グランドセフトオート5)GTA5 & GTAオンライン 情報・攻略wiki
  9. オレカバトル アプリ版 @ ウィキ
  10. SDガンダム ジージェネレーションジェネシス 攻略Wiki
もっと見る
全体ページランキング

最近アクセスの多かったページランキングです。話題のページを見に行こう!

  1. 過去の行動&発言まとめ - 鹿乃つの氏 周辺注意喚起@ウィキ
  2. マイティーストライクフリーダムガンダム - 機動戦士ガンダム EXTREME VS.2 INFINITEBOOST wiki
  3. 魚拓まとめ - 鹿乃つの氏 周辺注意喚起@ウィキ
  4. 参加者一覧 - ストグラ まとめ @ウィキ
  5. 1103環境(遊戯王) - アニヲタWiki(仮)
  6. 前作からの変更点 - 機動戦士ガンダム EXTREME VS.2 INFINITEBOOST wiki
  7. 魔獣トゲイラ - バトルロイヤルR+α ファンフィクション(二次創作など)総合wiki
  8. コレクター・ユイ - アニヲタWiki(仮)
  9. サーヴァント/一覧/クラス別 - Fate/Grand Order @wiki 【FGO】
  10. 画像倉庫 - 鹿乃つの氏 周辺注意喚起@ウィキ
もっと見る

  • このWikiのTOPへ
  • 全ページ一覧
  • アットウィキTOP
  • 利用規約
  • プライバシーポリシー

2019 AtWiki, Inc.