アーケードゲーム中心のつれづれ
http://sanechica.blog.shinobi.jp/
<<12 * 01/1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 *
02>>
ブログ主へのメッセージはこちら
Powered by NINJA TOOLS
2011/1/15(土) 午後 10:30
少しペナについて言及します。
ペナの判定については考えがまとまっていないので書きません。
ただ、ペナってどのように加わっているのでしょう?
これについては一つ考えがあります。
ペナ判定を受けた時点の画面がペナの重さに比例して複製されるのだと思うのです。
これによってカット数が増えますからスクロールが悪くなります。
いわゆるペナっているという状況の再現ができます。
停止するとペナが軽減されるのもこれなら説明できます。
つまり、相対的に軽減されているだけで、ペナ自体が消えているわけではないんですけどね。
先行有利の理論
まあ、後ろは抜かなきゃならないしね。
ということではなく、カット数の話です。
後ろを走るということは、前に相手の車がありますよね?
画面の中に動く物体があると、それの動きによってカット数が増えることがあるんですよ。
後ろの車はその分処理容量を損することになるんですよ。
だから先行の方が温存には良いってのは納得出来るんです。
ブーストについて
これについてはあまり研究していません。
だって、私全国は常時ブーオフ要求ですから!
ただ、多分前の車に何らかの負荷がかかっていると思います。
対戦ゴールタイムがブーオフの方が相対的に速く出るんです。
以上、この方眼紙の話は、全て私の妄想ですからね!
実際のD5が、どんなプログラムかなんて、私知りませんからっ!
少しペナについて言及します。
ペナの判定については考えがまとまっていないので書きません。
ただ、ペナってどのように加わっているのでしょう?
これについては一つ考えがあります。
ペナ判定を受けた時点の画面がペナの重さに比例して複製されるのだと思うのです。
これによってカット数が増えますからスクロールが悪くなります。
いわゆるペナっているという状況の再現ができます。
停止するとペナが軽減されるのもこれなら説明できます。
つまり、相対的に軽減されているだけで、ペナ自体が消えているわけではないんですけどね。
先行有利の理論
まあ、後ろは抜かなきゃならないしね。
ということではなく、カット数の話です。
後ろを走るということは、前に相手の車がありますよね?
画面の中に動く物体があると、それの動きによってカット数が増えることがあるんですよ。
後ろの車はその分処理容量を損することになるんですよ。
だから先行の方が温存には良いってのは納得出来るんです。
ブーストについて
これについてはあまり研究していません。
だって、私全国は常時ブーオフ要求ですから!
ただ、多分前の車に何らかの負荷がかかっていると思います。
対戦ゴールタイムがブーオフの方が相対的に速く出るんです。
以上、この方眼紙の話は、全て私の妄想ですからね!
実際のD5が、どんなプログラムかなんて、私知りませんからっ!
PR
2011/1/15(土) 午後 10:02
いかん、いかん、コーナーの話をしていたらタイヤの話に行く前に記事がのびまくっていました。
続きです。
無理して走ると何で後半のびなくなるの? タイヤじゃないの?
これの答え合わせです。
位置情報の計算に必要なデータ量は、最初から最後まで大きく変わることがありません。
しかし画像処理に必要なデータ量は、カット数によって大きく変わります。
時間毎に処理できるデータ量には限界があります。
仮に1カット加わると3MBとしましょう。1secで処理出来るデータ量を5MBとしましょう。
Aさんの走り方での5秒間のカット量は8カットでした。
Bさんの走り方での5秒間のカット量は10カットでした。
5秒後
Aさんの処理負荷は(3*8)-(5*5)=0(マイナスは全て0です)
Aさんはこの時点で負荷がありません。
Bさんの処理負荷は(3*10)-(5*5)=5
Bさんには5MBの処理負荷がかかっています。
(負荷の分だけ位置情報は遅れます)
次の5秒間
Aさんのカット数は10、Bさんのカット数は12でした。
この時点でのAさんの処理負荷は(10*3)-(5*5)+0=5
Aさんには5MBの処理負荷がかかっています。
この時点でのBさんの処理負荷は(12*3)-(5*5)+5=16
Bさんには16MBの処理負荷がかかっています。
この様に処理しきれない負荷は蓄積されていきます。
これが後半に加速が悪くなるタイヤのメカニズムであると考えます。
ちなみに、最初Aさんのところでマイナスは0であると書きました。
確かにマイナスは0です。しかし、負荷を抱えた状態でマイナスが生じた場合、マイナスはマイナスとして作用します。
つまり負荷が軽減されるのです。
アンキャンと言われているものの正体です。
これは加速を押さえることによりカット数の上昇を抑え、前のコーナーでの過負荷を軽減することにより、その後の加速を補助していると言うことです。
でもね、最初にマイナスは0ですと書きましたよね。
負荷が加わっていない状態では、やるだけ損なんですよ。
だって負荷が軽減されるわけでもないのに位置情報の進行を抑えるってことなんですから。
つまり、許容負荷内で曲がれるならアンキャンなんて無意味なんですよね。
無意味どころかかえって損しているんですよ。
直線で減速するのも、メカニズムは同じです。
いかん、いかん、コーナーの話をしていたらタイヤの話に行く前に記事がのびまくっていました。
続きです。
無理して走ると何で後半のびなくなるの? タイヤじゃないの?
これの答え合わせです。
位置情報の計算に必要なデータ量は、最初から最後まで大きく変わることがありません。
しかし画像処理に必要なデータ量は、カット数によって大きく変わります。
時間毎に処理できるデータ量には限界があります。
仮に1カット加わると3MBとしましょう。1secで処理出来るデータ量を5MBとしましょう。
Aさんの走り方での5秒間のカット量は8カットでした。
Bさんの走り方での5秒間のカット量は10カットでした。
5秒後
Aさんの処理負荷は(3*8)-(5*5)=0(マイナスは全て0です)
Aさんはこの時点で負荷がありません。
Bさんの処理負荷は(3*10)-(5*5)=5
Bさんには5MBの処理負荷がかかっています。
(負荷の分だけ位置情報は遅れます)
次の5秒間
Aさんのカット数は10、Bさんのカット数は12でした。
この時点でのAさんの処理負荷は(10*3)-(5*5)+0=5
Aさんには5MBの処理負荷がかかっています。
この時点でのBさんの処理負荷は(12*3)-(5*5)+5=16
Bさんには16MBの処理負荷がかかっています。
この様に処理しきれない負荷は蓄積されていきます。
これが後半に加速が悪くなるタイヤのメカニズムであると考えます。
ちなみに、最初Aさんのところでマイナスは0であると書きました。
確かにマイナスは0です。しかし、負荷を抱えた状態でマイナスが生じた場合、マイナスはマイナスとして作用します。
つまり負荷が軽減されるのです。
アンキャンと言われているものの正体です。
これは加速を押さえることによりカット数の上昇を抑え、前のコーナーでの過負荷を軽減することにより、その後の加速を補助していると言うことです。
でもね、最初にマイナスは0ですと書きましたよね。
負荷が加わっていない状態では、やるだけ損なんですよ。
だって負荷が軽減されるわけでもないのに位置情報の進行を抑えるってことなんですから。
つまり、許容負荷内で曲がれるならアンキャンなんて無意味なんですよね。
無意味どころかかえって損しているんですよ。
直線で減速するのも、メカニズムは同じです。
2011/1/15(土) 午後 9:16
さて、タイヤの話に移りましょう。
先日の記事でタイヤないといいました。
それはタイヤと言っているものは何なのかという考え方の違いです。
前の記事でスクロールとは、コマ数であるといいました。
コマの切り替わりを決めるものは、ある時点との差分が一定のレベルを超えた時である。
コマの切り替わること、これをカットと言います。
カットが少ない程スクロールは良いと言うことになります。
ではカットが少なくなる走り方とはどのようなものでしょうか。
それはゆっくりと真っ直ぐ走った時です。
真っ直ぐ走っている時は遠景の変化は非常に少ないです。
近景も中央付近の変化量は少ないです。
よって差分が許容量に届く回数が少なくなります。
速度を落とすと更にそれは加速します。
しかしコースは真っ直ぐではありません。
また、ゆっくり走ったのでは位置情報が進まないため意味がありません。
よってコーナーをどのように曲がるかが重要になってきます。
速く前に進むためには位置情報を前に進める必要があります。
これには最短ルートをより速いスピードで走ることが一番です。
しかし、スピードをあげると自ずとカット数が増えてしまいます。
カット数が増えると位置情報がそれに引っ張られて遅れるることになります。
だからコーナーでは減速が必要なのです。
カット数を押さえより位置情報を前に出す、そのバランスがコーナー速度を決める言うことになります。
しかし、このバランスは同じコーナーの曲がり方をしたときに成立するものです。
曲がり方が違う場合、この最適なコーナー速度は速くも、遅くもなるのです。
ではどのような曲がり方が効率的なのでしょうか?
カットは画面の差分がある一定量を超えた時に発生します。
一定量を超えた時ですから、たくさん越えても、僅かに越えても1カットです。
つまりなるべく差分が起こらない様に直線的に減速加速し、低速状態で短時間で一気に方向を変える。
という走り方が最もカット数が少なくなります。
いわゆる今はやりのドリフトです。
グリップも低速でコーナーを曲がるのでカット数は少ないです。
しかし、曲がっている時間がドリフトのそれよりは長いことになります。
故にカット数としては、ドリフトの方が得なのです。
ドリフトの立ち上がりが速いというのは、おそらく立ち上がりでの位置情報との誤差がグリップのそれに比べて少ない為だと思います。
さて、タイヤの話に移りましょう。
先日の記事でタイヤないといいました。
それはタイヤと言っているものは何なのかという考え方の違いです。
前の記事でスクロールとは、コマ数であるといいました。
コマの切り替わりを決めるものは、ある時点との差分が一定のレベルを超えた時である。
コマの切り替わること、これをカットと言います。
カットが少ない程スクロールは良いと言うことになります。
ではカットが少なくなる走り方とはどのようなものでしょうか。
それはゆっくりと真っ直ぐ走った時です。
真っ直ぐ走っている時は遠景の変化は非常に少ないです。
近景も中央付近の変化量は少ないです。
よって差分が許容量に届く回数が少なくなります。
速度を落とすと更にそれは加速します。
しかしコースは真っ直ぐではありません。
また、ゆっくり走ったのでは位置情報が進まないため意味がありません。
よってコーナーをどのように曲がるかが重要になってきます。
速く前に進むためには位置情報を前に進める必要があります。
これには最短ルートをより速いスピードで走ることが一番です。
しかし、スピードをあげると自ずとカット数が増えてしまいます。
カット数が増えると位置情報がそれに引っ張られて遅れるることになります。
だからコーナーでは減速が必要なのです。
カット数を押さえより位置情報を前に出す、そのバランスがコーナー速度を決める言うことになります。
しかし、このバランスは同じコーナーの曲がり方をしたときに成立するものです。
曲がり方が違う場合、この最適なコーナー速度は速くも、遅くもなるのです。
ではどのような曲がり方が効率的なのでしょうか?
カットは画面の差分がある一定量を超えた時に発生します。
一定量を超えた時ですから、たくさん越えても、僅かに越えても1カットです。
つまりなるべく差分が起こらない様に直線的に減速加速し、低速状態で短時間で一気に方向を変える。
という走り方が最もカット数が少なくなります。
いわゆる今はやりのドリフトです。
グリップも低速でコーナーを曲がるのでカット数は少ないです。
しかし、曲がっている時間がドリフトのそれよりは長いことになります。
故にカット数としては、ドリフトの方が得なのです。
ドリフトの立ち上がりが速いというのは、おそらく立ち上がりでの位置情報との誤差がグリップのそれに比べて少ない為だと思います。
ここで、根本的な話に戻りましょう。
なぜスクロールが悪いと遅いのかという話です。
スクロールが悪いと言うことは、画像のコマ数が多いことになります。
簡単に言うと枚数が多い紙芝居です。
但し、位置情報は別の指標で割り出されると話しました。
それならば、普通に考えれば問題ない様に思えますね。
正直、これらの演算をしているコンピューターの処理能力と通信効率が高ければ問題ないと思います。
しかし、実際D5に使われているものは、そこまで処理能力が高くありません。
All.Netも結構タイムラグが生じていますし。
では、画像処理が位置情報に遅れたらどうなるのか?
処理が間に合わない以上、どちらかに帳尻を合わせる必要が出てきます。
実はこれ、その遅れの具合によって画像に合わせる時と位置情報に合わせる時があると考えています。
基本は画像に合わせると思っています。そうしないと画面がワープすることになるからです。
つまりスクロールが悪いと、本来進んでいる筈の場所まで進めないという考えです。
では位置情報に合わせるというのは?
普通に走ってもコマ数が処理限界に近くなるコーナーです。そこは意図的に位置情報に合わせるようにコマ落ちをさせて調整しているのではと考えます。例えばいろは4セク最初の2連です。
疲れたんで続きは夜に~
ちなみにここまではブーストとか壁ペナとかは含めずに考えていますからね。
それは別の指標の話です。
なぜスクロールが悪いと遅いのかという話です。
スクロールが悪いと言うことは、画像のコマ数が多いことになります。
簡単に言うと枚数が多い紙芝居です。
但し、位置情報は別の指標で割り出されると話しました。
それならば、普通に考えれば問題ない様に思えますね。
正直、これらの演算をしているコンピューターの処理能力と通信効率が高ければ問題ないと思います。
しかし、実際D5に使われているものは、そこまで処理能力が高くありません。
All.Netも結構タイムラグが生じていますし。
では、画像処理が位置情報に遅れたらどうなるのか?
処理が間に合わない以上、どちらかに帳尻を合わせる必要が出てきます。
実はこれ、その遅れの具合によって画像に合わせる時と位置情報に合わせる時があると考えています。
基本は画像に合わせると思っています。そうしないと画面がワープすることになるからです。
つまりスクロールが悪いと、本来進んでいる筈の場所まで進めないという考えです。
では位置情報に合わせるというのは?
普通に走ってもコマ数が処理限界に近くなるコーナーです。そこは意図的に位置情報に合わせるようにコマ落ちをさせて調整しているのではと考えます。例えばいろは4セク最初の2連です。
疲れたんで続きは夜に~
ちなみにここまではブーストとか壁ペナとかは含めずに考えていますからね。
それは別の指標の話です。
2011/1/15(土) 午前 11:08
ではその情報量がどのように関連してくるのかの話です。
先程は概念を理解しやすいように2次元で話しました。
実際にはこのゲームは3次元です。つまり、ピクセルではなくボクセル考えなければなりません。
とはいえ、考え方はおなじです。x,y軸に、z軸を加え画像を計算で変化させることができます。
但し、情報量は異なります。
全ての背景画像に情報量の少ない方向と多い方向があると私は仮定しています。
ちなみに秋名湖を走るとわかりやすいのですが、画像処理は最低3でもラインで行われていると思います。
遠景と近景、そして前を走る対戦相手の居る領域です。
次にスピードとスクロールの関係です。
D5ではスクロールとスピードはリンクしていません。
わかりやすいのは後半の長いストレート(秋名下とか)の前に一度止まって見れば良いです。
そこから加速し普段と同じスピードに達した時とのスクロールが違うことがわかります。
ではスピードとは何なのか、スクロールとは何なのかの理論です。
結論から言うと私はスピードは位置情報を割り出す為の演算の指標の一つです。
スピード、走行ライン(これにハンドル舵角やブレーキ、アクセルが係わる)、走行時間に寄って実際の走行距離が決まるわけです。基本的には……。
ではスクロールとはなんなのか?
私はこれはコマ数だと考えています。
D5のTAでは、00'00"000ここまでタイムが出ますよね?
つまりこの細かさまで車の位置情報の処理が出来るといいうことです。
それを画面上に再現するために画像処理するのですが、この位置情報ほど細かくは画像切り替えされていないと考えています。
ではどのタイミングで切り替えられるのか?
結論からいえば、ある瞬間毎の画像の差分処理により、基準量を超えた時に、切り替え処理がなされていると考えます。
ちなみにこの差分処理は3ライン独立だと私は考えています。
ではその情報量がどのように関連してくるのかの話です。
先程は概念を理解しやすいように2次元で話しました。
実際にはこのゲームは3次元です。つまり、ピクセルではなくボクセル考えなければなりません。
とはいえ、考え方はおなじです。x,y軸に、z軸を加え画像を計算で変化させることができます。
但し、情報量は異なります。
全ての背景画像に情報量の少ない方向と多い方向があると私は仮定しています。
ちなみに秋名湖を走るとわかりやすいのですが、画像処理は最低3でもラインで行われていると思います。
遠景と近景、そして前を走る対戦相手の居る領域です。
次にスピードとスクロールの関係です。
D5ではスクロールとスピードはリンクしていません。
わかりやすいのは後半の長いストレート(秋名下とか)の前に一度止まって見れば良いです。
そこから加速し普段と同じスピードに達した時とのスクロールが違うことがわかります。
ではスピードとは何なのか、スクロールとは何なのかの理論です。
結論から言うと私はスピードは位置情報を割り出す為の演算の指標の一つです。
スピード、走行ライン(これにハンドル舵角やブレーキ、アクセルが係わる)、走行時間に寄って実際の走行距離が決まるわけです。基本的には……。
ではスクロールとはなんなのか?
私はこれはコマ数だと考えています。
D5のTAでは、00'00"000ここまでタイムが出ますよね?
つまりこの細かさまで車の位置情報の処理が出来るといいうことです。
それを画面上に再現するために画像処理するのですが、この位置情報ほど細かくは画像切り替えされていないと考えています。
ではどのタイミングで切り替えられるのか?
結論からいえば、ある瞬間毎の画像の差分処理により、基準量を超えた時に、切り替え処理がなされていると考えます。
ちなみにこの差分処理は3ライン独立だと私は考えています。
2011/1/15(土) 午前 10:33
最初に言っておくが、これはあくまで私の理論でてす。
ちなみに、私のランクはA3です。
信じる信じないは読んだ人の自由ですが、私は責任を負いません。
それを踏まえて、さて始めましょう。
まず第一に当たり前のことですが頭文字D5はゲームです。
実際に車が走っているわけではありません。
これで重要なのは、地動説と天動説の理論です。
言うなれば現実に車を走らせることが地動説であるなら、ゲームというのはそれを擬似的に表現するために、天動説を用いて表現しているのです。
簡単に言うと実際に運転席を移動させることが出来ないので背景を動かしているということです。
その背景を作っているのはアナログではなくデジタルです。
デジタルというものは、アナログの連続データとは違い階段状のデータです。
つまりどこかで区切られ、繰り上げ乃至切り捨てられるデータが存在するということです。
次に、アナログとデジタルの情報量の話をします。
以下の図の正方形は全て同じ大きさです。
つまりアナログでの情報量は同じです。
しかしデジタルの場合その情報量がかわってくるのです。
下の正方形の上の個数は正方形が踏んでいるマス目の個数です。
これを画素(ピクセル)と仮定します。
繰り上げ処理した場合の情報量がその個数と同義です。
同じ正方形の情報量がかわったのがわかりますよね?
最初に言っておくが、これはあくまで私の理論でてす。
ちなみに、私のランクはA3です。
信じる信じないは読んだ人の自由ですが、私は責任を負いません。
それを踏まえて、さて始めましょう。
まず第一に当たり前のことですが頭文字D5はゲームです。
実際に車が走っているわけではありません。
これで重要なのは、地動説と天動説の理論です。
言うなれば現実に車を走らせることが地動説であるなら、ゲームというのはそれを擬似的に表現するために、天動説を用いて表現しているのです。
簡単に言うと実際に運転席を移動させることが出来ないので背景を動かしているということです。
その背景を作っているのはアナログではなくデジタルです。
デジタルというものは、アナログの連続データとは違い階段状のデータです。
つまりどこかで区切られ、繰り上げ乃至切り捨てられるデータが存在するということです。
次に、アナログとデジタルの情報量の話をします。
以下の図の正方形は全て同じ大きさです。
つまりアナログでの情報量は同じです。
しかしデジタルの場合その情報量がかわってくるのです。
下の正方形の上の個数は正方形が踏んでいるマス目の個数です。
これを画素(ピクセル)と仮定します。
繰り上げ処理した場合の情報量がその個数と同義です。
同じ正方形の情報量がかわったのがわかりますよね?
2011/1/9(日) 午後 9:41
昨日眠ってしまったので続き
八方復路のセクタイムを集めてみたんだが。2セク以外は結構ばらついているんですよ。
凜風さんも参考にしてくださいな♪
八方の後は、凜風さんの全国を見ながらしゃべりまくって騒いでいただけです。
楽しかったです。
そして、電車の時間が来たので帰宅……
その前に、わざわざ関西に来たには目的があったんですよ。
と、いうことで近くのファミマへGO!
買った商品はどん兵衛です。
どん兵衛って北海道版と東日本版と西日本版があるので食べ比べがしたかったんですよ。
先日、北海道版と東日本版を食べ比べよう試食会をやったので、第2弾の仕込みにきたんです。
ということで、帰宅したのは22時でした。朝は5時半に出ました。
その後凜風さんは3'00"台に突入したそうですよ。
昨日眠ってしまったので続き
八方復路のセクタイムを集めてみたんだが。2セク以外は結構ばらついているんですよ。
凜風さんも参考にしてくださいな♪
八方の後は、凜風さんの全国を見ながらしゃべりまくって騒いでいただけです。
楽しかったです。
そして、電車の時間が来たので帰宅……
その前に、わざわざ関西に来たには目的があったんですよ。
と、いうことで近くのファミマへGO!
買った商品はどん兵衛です。
どん兵衛って北海道版と東日本版と西日本版があるので食べ比べがしたかったんですよ。
先日、北海道版と東日本版を食べ比べよう試食会をやったので、第2弾の仕込みにきたんです。
ということで、帰宅したのは22時でした。朝は5時半に出ました。
その後凜風さんは3'00"台に突入したそうですよ。
2011/1/8(土) 午後 11:11
今日は姫路の“CLUBSEGA姫路”まで遠征に行ってきました。
ここは、いつもコメントを下さる凜風さんのホームです。
片道5時間、往復で10時間の移動時間です。遠いな姫路。
(お金ケチって普通列車で行ったからなんだけどね)
木曜にいきなり『土曜ひま?』とメールしたにもかかわらず、ゲーセンまで来てくれた凜風さんに感謝です。
それで、“CLUBSEGA姫路”なのですが、行ってからわかったんですが、大きな問題がありました。
全筐体のステアリングが太いんですよ。
4台中2台がクレサ台なのですが、握力の問題で私はその筐体では走れませんでした。
まさかの5秒落ちタイムでしたよ……寄せれないよこれ。
1クレ台にやや細め(それでも通常よりは太い)のステアがあったので、その筐体粘着でした。
と言うことで、せっかく会ったのですから店対です。
でも、1クレ筐体でお願いします。2クレ筐体は、私無理です……。
コースは八復、妙上、筑往、八往で全て晴れです。
1勝3敗でその1勝も筑波で凜風さんが溝に填ったからなんですけどね~。
(そういえば、往路の2連変形溝の1個目への進入の仕方が、私と凜風さんでは違ったよ)
4戦したところで、私がギブアップ。
ハンドル太いと寄せに必要な握力が長くは持たないんです……。
その後お互いの八方復路の走りを見せ合いました。
ぶっっちゃけ全然走り方が違いました。
FD-RS(MT)とDC2(AT)の違いはあるものの、ブレーキ、アクセルのタイミングから、ステア操作、ギアに至までとにかく違う。
それなのにどちらも1秒台という。
セクタイムも全然違うんで、面白いですよ。
凜風さん(1/8)
雲井(1/6)
いかん眠くてダメだ続きは明日書きます……。
今日は姫路の“CLUBSEGA姫路”まで遠征に行ってきました。
ここは、いつもコメントを下さる凜風さんのホームです。
片道5時間、往復で10時間の移動時間です。遠いな姫路。
(お金ケチって普通列車で行ったからなんだけどね)
木曜にいきなり『土曜ひま?』とメールしたにもかかわらず、ゲーセンまで来てくれた凜風さんに感謝です。
それで、“CLUBSEGA姫路”なのですが、行ってからわかったんですが、大きな問題がありました。
全筐体のステアリングが太いんですよ。
4台中2台がクレサ台なのですが、握力の問題で私はその筐体では走れませんでした。
まさかの5秒落ちタイムでしたよ……寄せれないよこれ。
1クレ台にやや細め(それでも通常よりは太い)のステアがあったので、その筐体粘着でした。
と言うことで、せっかく会ったのですから店対です。
でも、1クレ筐体でお願いします。2クレ筐体は、私無理です……。
コースは八復、妙上、筑往、八往で全て晴れです。
1勝3敗でその1勝も筑波で凜風さんが溝に填ったからなんですけどね~。
(そういえば、往路の2連変形溝の1個目への進入の仕方が、私と凜風さんでは違ったよ)
4戦したところで、私がギブアップ。
ハンドル太いと寄せに必要な握力が長くは持たないんです……。
その後お互いの八方復路の走りを見せ合いました。
ぶっっちゃけ全然走り方が違いました。
FD-RS(MT)とDC2(AT)の違いはあるものの、ブレーキ、アクセルのタイミングから、ステア操作、ギアに至までとにかく違う。
それなのにどちらも1秒台という。
セクタイムも全然違うんで、面白いですよ。
凜風さん(1/8)
雲井(1/6)
いかん眠くてダメだ続きは明日書きます……。
2011/1/3(月) 午後 11:46
1/2
今年最初のD5は、八戸のセガワからです。
いきなりの積雪で電車運休に挫けつつ、隣町からの電車を拾って八戸へ
まずは誰もD5をやっている方はいなかったので、店舗ランクチェック
所々バグっていて、そうでないコースは全体的にTA速い……。
ちょっと入れそうになかったので、車種別で妥協して、妙義上り晴れのS14に名前を残しました~。
そのTA途中にチームリーダー登場!
と言うことで、店対したり、お話ししたりで結局10時間も八戸に居座りました。
それから夕方、3月頃に店対した方が現れたのでちょっとお話ししましたよ~。
1/3
この日は少しイベントやってから、普通に全国やるつもりでゲーセンに行ったのですが、思わぬ事態に!
まずはD5の前に行くと昨日お話しした方が今日は地元に!
今日も少し挨拶程度に会話しました。すぐに帰られたので店対とかはなしでした。
その後全国を1クレやったところで、お隣でプレイしていた方と店対する話がつきました。
ということで今日も店対!
しかも今日はランダムでやりまくりです。
途中小銭の尽きた相手が両替に向かうと……
「じゃあ、俺がやる」
そんなあなたは……師匠でした。
Cクラスだった私にD5について色々教えてくれた方です。
私、当時の師匠のクラスまでやっと来たんですよ~!
師匠は最近あまりやっていなかったらしく、結構良い勝負が出来て楽しかったよ。
で、チームカードを差したら師匠が一言
「あれ、俺このチーム前に入ってた」
えええええっ!
凄い偶然ですね。
ということで、他の方が現れるまで3人で店対しまくりでした。楽しかったです。
1/2
今年最初のD5は、八戸のセガワからです。
いきなりの積雪で電車運休に挫けつつ、隣町からの電車を拾って八戸へ
まずは誰もD5をやっている方はいなかったので、店舗ランクチェック
所々バグっていて、そうでないコースは全体的にTA速い……。
ちょっと入れそうになかったので、車種別で妥協して、妙義上り晴れのS14に名前を残しました~。
そのTA途中にチームリーダー登場!
と言うことで、店対したり、お話ししたりで結局10時間も八戸に居座りました。
それから夕方、3月頃に店対した方が現れたのでちょっとお話ししましたよ~。
1/3
この日は少しイベントやってから、普通に全国やるつもりでゲーセンに行ったのですが、思わぬ事態に!
まずはD5の前に行くと昨日お話しした方が今日は地元に!
今日も少し挨拶程度に会話しました。すぐに帰られたので店対とかはなしでした。
その後全国を1クレやったところで、お隣でプレイしていた方と店対する話がつきました。
ということで今日も店対!
しかも今日はランダムでやりまくりです。
途中小銭の尽きた相手が両替に向かうと……
「じゃあ、俺がやる」
そんなあなたは……師匠でした。
Cクラスだった私にD5について色々教えてくれた方です。
私、当時の師匠のクラスまでやっと来たんですよ~!
師匠は最近あまりやっていなかったらしく、結構良い勝負が出来て楽しかったよ。
で、チームカードを差したら師匠が一言
「あれ、俺このチーム前に入ってた」
えええええっ!
凄い偶然ですね。
ということで、他の方が現れるまで3人で店対しまくりでした。楽しかったです。
2010/12/31(金) 午後 4:57
現在のTA自己ベスト(全てオートマです)
コース/向き/晴/タイム/雨/タイム/車種
秋名湖/左周り/晴/3'20"673/雨/3'27"763/RPS13
秋名湖/右周り/晴/3'20"345雨/3'28"949//RPS13
妙義/下り/晴/2'51"433/雨/2'57"671/EG6
妙義/上り/晴/2'52"730/雨/2'59"283/RPS13
赤城/下り/晴/2'50"310/雨/2'58"288/FC3S
赤城/上り/晴/2'51"925/雨/2'59"578/FD3S
秋名/下り/晴/3'14"056/雨/3'21"995/AE86レビン
秋名/上り/晴/3'18"919/雨/3'29"810/FD3S
いろは坂/下り/晴/3'11"863/雨/3'21"571/AP1
いろは坂/逆走/晴/3'12"645/雨/3'21"952/CN9A
八方ヶ原/往路/晴/3'06"266/雨/3'15"330/EK9
八方ヶ原/復路/晴/3'02"418/雨/3'10"974/DC2
筑波/往路/晴/3'07"023/雨/3'16"636/AP1
筑波/復路/晴/3'08"016/雨/3'17"285/SE3P
長尾/下り/晴/3'19"839/雨/3'28"375/NB8C
長尾/上り/晴/3'24"269/雨/3'32"492/JZA80
微妙に更新しているコースがありますよ。
秋名湖右の更新の手がかりを見つけたんで、次に試そうかな~と。
現在のTA自己ベスト(全てオートマです)
コース/向き/晴/タイム/雨/タイム/車種
秋名湖/左周り/晴/3'20"673/雨/3'27"763/RPS13
秋名湖/右周り/晴/3'20"345雨/3'28"949//RPS13
妙義/下り/晴/2'51"433/雨/2'57"671/EG6
妙義/上り/晴/2'52"730/雨/2'59"283/RPS13
赤城/下り/晴/2'50"310/雨/2'58"288/FC3S
赤城/上り/晴/2'51"925/雨/2'59"578/FD3S
秋名/下り/晴/3'14"056/雨/3'21"995/AE86レビン
秋名/上り/晴/3'18"919/雨/3'29"810/FD3S
いろは坂/下り/晴/3'11"863/雨/3'21"571/AP1
いろは坂/逆走/晴/3'12"645/雨/3'21"952/CN9A
八方ヶ原/往路/晴/3'06"266/雨/3'15"330/EK9
八方ヶ原/復路/晴/3'02"418/雨/3'10"974/DC2
筑波/往路/晴/3'07"023/雨/3'16"636/AP1
筑波/復路/晴/3'08"016/雨/3'17"285/SE3P
長尾/下り/晴/3'19"839/雨/3'28"375/NB8C
長尾/上り/晴/3'24"269/雨/3'32"492/JZA80
微妙に更新しているコースがありますよ。
秋名湖右の更新の手がかりを見つけたんで、次に試そうかな~と。
2010/12/31(金) 午後 1:19
昨年12月~今年12月までの自分のデータ(カード8枚分)をまとめてみたよ。
最近の傾向を反映したデータではないのです。
D5を始めた当初からの積算データなのです。
全部で、
1854戦858勝、勝率46.3%
人に譲渡したカードのデータは入っていないのです。
そういうのを足すと2000戦オーバーは確実なのです。
車種別使用回数
SE3P(709回)、FD3S(322回)、DC2(320回)、CN9A(152回)、RPS13(89回)、EG6(83回)、EK9(60回)、 SXE10(35回)、NB8C(32回)、FC3S(30回)、S14(8回)、AP1(6回)、JZA80(2回)、AE86LEVIN(1回)、 SILEIGHTY(0回)、NA6CE(0回)、FD3S6(0回)
廃車済み>AP1(4回)、GC8(1回)、ZZW30(0回)
車種別勝率
S14(87.5%)、RPS13(51.7%)、DC2(51.6%)、NB8C(50.0%)、FC3S(50.0%)、JZA80(50.o%)、 SXE10(48.6%)、FD3S(48.4%)、CN9A(45.4%)、EK9(45.0%)、SE3P(43.0%)、EG6(37.3%)、 AP1(30%)、AE86LEVIN(0.0%)、GC8(0.0%)
コース別対戦数
赤城上り(379回)、八方復路(273回)、筑波復路(197回)、いろは下り(186回)、秋名下り(120回)、赤城下り(118回)、妙義下り (86回)、筑波往路(83回)、長尾下り(75回)、妙義上り(68回)、八方往路(59回)、いろは逆走(53回)、長尾上り(51回)、秋名湖右 (40回)、秋名上り(33回)、秋名湖左(32回)、ネットワークエラーによるデータ欠損(1回<八方復路>)
コース別勝率
秋名湖左(71.9%)、赤城下り(50.0%)、赤城上り(49.9%)、秋名下り(46.7%)、八方復路(46.5%)、筑波復路(46.2%)、妙義下り(45.3%)、長尾上り(45.1%)、秋名湖右(45.0%)、いろは下り(44.6%)、筑波往路(44.6%)、長尾下り (42.7%)、妙義上り(41.2%)、八方往路(39.0%)、いろは逆走(34.0%)、秋名上り(33.3%)
昨年12月~今年12月までの自分のデータ(カード8枚分)をまとめてみたよ。
最近の傾向を反映したデータではないのです。
D5を始めた当初からの積算データなのです。
全部で、
1854戦858勝、勝率46.3%
人に譲渡したカードのデータは入っていないのです。
そういうのを足すと2000戦オーバーは確実なのです。
車種別使用回数
SE3P(709回)、FD3S(322回)、DC2(320回)、CN9A(152回)、RPS13(89回)、EG6(83回)、EK9(60回)、 SXE10(35回)、NB8C(32回)、FC3S(30回)、S14(8回)、AP1(6回)、JZA80(2回)、AE86LEVIN(1回)、 SILEIGHTY(0回)、NA6CE(0回)、FD3S6(0回)
廃車済み>AP1(4回)、GC8(1回)、ZZW30(0回)
車種別勝率
S14(87.5%)、RPS13(51.7%)、DC2(51.6%)、NB8C(50.0%)、FC3S(50.0%)、JZA80(50.o%)、 SXE10(48.6%)、FD3S(48.4%)、CN9A(45.4%)、EK9(45.0%)、SE3P(43.0%)、EG6(37.3%)、 AP1(30%)、AE86LEVIN(0.0%)、GC8(0.0%)
コース別対戦数
赤城上り(379回)、八方復路(273回)、筑波復路(197回)、いろは下り(186回)、秋名下り(120回)、赤城下り(118回)、妙義下り (86回)、筑波往路(83回)、長尾下り(75回)、妙義上り(68回)、八方往路(59回)、いろは逆走(53回)、長尾上り(51回)、秋名湖右 (40回)、秋名上り(33回)、秋名湖左(32回)、ネットワークエラーによるデータ欠損(1回<八方復路>)
コース別勝率
秋名湖左(71.9%)、赤城下り(50.0%)、赤城上り(49.9%)、秋名下り(46.7%)、八方復路(46.5%)、筑波復路(46.2%)、妙義下り(45.3%)、長尾上り(45.1%)、秋名湖右(45.0%)、いろは下り(44.6%)、筑波往路(44.6%)、長尾下り (42.7%)、妙義上り(41.2%)、八方往路(39.0%)、いろは逆走(34.0%)、秋名上り(33.3%)