hyousi

  • Home
  • 一覧
  • [自キ]手配線で60%キーボード(試作)を作る

    60%キーボードを手配線で作りました。自キ制作レポートです。

    窮屈ですが69キーの自作キーボードを作りました。

    前の記事:[自キ]チルトグリップ対応の左手デバイス(試作)

    設計方針

    私はUS配列がJIS配列より好きだ。JISは手を動かさないとENTERが押せないがUSは指を動かすだけで押せるからだ。それにJIS配列の{}が上下にずれてるのおかしいだろ。

    しかしUS配列で日本語キーボードを打つと不便だと思う。_が打てないのだ。

    ということでENTERキーにアクセスしやすいUS配列ライクで日本語キーボードのキーを網羅したキーボードが欲しい。

    最近は75%を使用していて丁度60%キーボードはほんとに快適なのかと思っていたため60%を制作することに決めた。

    出来上がり

    打鍵感は外側のキーが少し硬いのは仕方ないか。カチャカチャなるわけでもないし悪い感じはせず普通に使えるものができた。キーキャップは足りなかった分を前回の余りで補った。

    PBTキーキャップはサラサラしているのがいいですね。

    OEMプロファイルは一般的ではありますがやっぱり少し背が高いです、他のキーキャップも触ってみたい。

    US配列で日本語設定で_と|を打てるのはめちゃくちゃ使いやすい。US配列使っていた時のストレスがなくなり最高。今まで_を打つのにWIN+SPACEでUSキーボードに切り替えSHIFT+-を打つというめんどくささだった。

    材料

    キーレイアウト

    Keyboard Layout Editor (keyboard-layout-editor.com)にて作成しました。

    窮屈ですが実質65%キーボードです。市販のプレートで詰め込めるだけ詰め込みました。

    キーマップはとりあえず詰めてみました。

    組み立て

    プレート

    2uShiftのモノを今回購入してみました。プレートにキースイッチをはめ込みボンドで固定。


    配線

    ダイオードを手配線、69個あるのが大変。

    promicroとリセットスイッチ、回路を配線。これでキーボードとしてはもう機能しそう。

    なぜかリセットスイッチ外からアクセスできないところに配置。気が向いたら外からアクセスできるようにします。promicroはキーボードの下に隠して配置するより上とかにスペースを設けた方が都合いいのかもしれないと思った。


    キーボードケース

    できるだけシンプルで簡単なケースにしようと思った。木材をのこぎりでカット。全然まっすぐ切れてなかった。のこぎりなんて普段使わんもん。電動のこぎりか厚みのある樹脂板の方が楽だったかも。

    ボンドで接着。ねじ止めする予定だったが予定から組み替えたりしてたらよくわからなくなった。


    組み立て

    家にあったラッカースプレーで適当に塗装、リア板の穴にUSBアダプタをボルトとナットで固定。

    リア板を溝に挿しこむ、キーボード乗せる、ねじで固定、ゴム足をつけて完成

    Firmware

    config.h

    #pragma once
    #include “config_common.h”

    #define VENDOR_ID 0xFEED
    #define PRODUCT_ID 0x0002
    #define DEVICE_VER 0x0001
    #define MANUFACTURER Tsuiha
    #define PRODUCT 60percent01

    #define MATRIX_ROWS 10
    #define MATRIX_COLS 7

    #define MATRIX_ROW_PINS { D1, D4, D7, B4, B5, D2, D0, C6, E6, F5 }
    #define MATRIX_COL_PINS { F6, F7, B1, B3, B2, B6, D3 }
    #define UNUSED_PINS

    #define DIODE_DIRECTION COL2ROW

    10行7列で作りました。


    60percent01.h

    #pragma once

    #include “quantum.h”

    #define LAYOUT( \
     k00, k01, k02, k03, k04, k05, k06, \
     k10, k11, k12, k13, k14, k15, k16, \
     k20, k21, k22, k23, k24, k25, k26, \
     k30, k31, k32, k33, k34, k35, k36, \
     k40, k41, k42, k43, k44, k45, k46, \
     k50, k51, k52, k53, k54, k55, k56, \
     k60, k61, k62, k63, k64, k65, k66, \
     k70, k71, k72, k73, k74, k75, k76, \
     k80, k81, k82, k83, k84, k85, k86, \
     k90, k91, k92, k93, k94,  k95   \
    ) { \
    { k00, k01, k02, k03, k04, k05, k06  }, \
    { k10, k11, k12, k13, k14, k15, k16  }, \
    { k20, k21, k22, k23, k24, k25, k26  }, \
    { k30, k31, k32, k33, k34, k35, k36  }, \
    { k40, k41, k42, k43, k44, k45, k46  }, \
    { k50, k51, k52, k53, k54, k55, k56  }, \
    { k60, k61, k62, k63, k64, k65, k66  }, \
    { k70, k71, k72, k73, k74, k75, k76  }, \
    { k80, k81, k82, k83, k84, k85, k86  }, \
    { k90, k91, k92, k93, k94, k95, KC_NO } \
    }

    keymap.c

    #include QMK_KEYBOARD_H

    const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    LAYOUT(
     KC_DELETE  ,KC_BSPACE    ,KC_EQUAL     ,KC_MINUS   ,KC_0     ,KC_9    ,KC_8 , \
     KC_BSLASH  ,KC_RBRACKET ,KC_LBRACKET ,KC_P     ,KC_O    ,KC_I     ,KC_U     , \
     KC_PGUP    ,KC_ENTER   ,KC_QUOTE    ,KC_SCOLON ,KC_L     ,KC_K    ,KC_J , \
     KC_PGDOWN  ,KC_UP     ,KC_INT1      ,KC_SLASH  ,KC_DOT  ,KC_COMMA ,KC_M , \
     KC_RIGHT     ,KC_DOWN   ,KC_LEFT     ,KC_JYEN   ,KC_RCTRL ,MO(1)     ,KC_RSHIFT , \
     KC_ESCAPE   ,KC_1       ,KC_2      ,KC_3     ,KC_4     ,KC_5    ,KC_6 , \
     KC_TAB    ,KC_Q       ,KC_W     ,KC_E     ,KC_R     ,KC_T    ,KC_7 , \
     KC_GRAVE    ,KC_A       ,KC_S      ,KC_D     ,KC_F     ,KC_G    ,KC_Y , \
     KC_LSHIFT    ,KC_Z       ,KC_X      ,KC_C     ,KC_V     ,KC_B    ,KC_H , \
     KC_LCTRL   ,KC_LGUI     ,KC_LALT     ,MO(1)     ,KC_SPACE ,KC_N       \
    ),
    LAYOUT(
    _______ ,KC_PSCREEN ,KC_F12 ,KC_F11 ,KC_F10 ,KC_F9 ,KC_F8 , \
    _______ ,_______ ,_______ ,_______ ,_______ ,_______ ,_______ , \
    KC_HOME ,_______ ,_______ ,_______ ,_______ ,_______ ,_______ , \
    KC_END ,KC_MS_WH_UP ,_______ ,_______ ,_______ ,_______ ,KC_MAIL , \
    KC_MS_WH_RIGHT ,KC_MS_WH_DOWN ,KC_MS_WH_LEFT ,_______ ,_______ ,_______ ,_______ , \
    _______ ,KC_F1 ,KC_F2 ,KC_F3 ,KC_F4 ,KC_F5 ,KC_F6 , \
    _______ ,_______ ,_______ ,_______ ,_______ ,_______ ,KC_F7 , \
    _______ ,KC_MEDIA_PREV_TRACK,KC_MEDIA_PLAY_PAUSE,KC_MEDIA_NEXT_TRACK,_______,_______ ,_______ , \
    _______ ,_______ ,_______ ,KC_CALCULATOR ,_______ ,_______ ,_______ , \
    _______ ,_______ ,_______ ,_______ ,_______ ,_______ \
    )
    };

    どうせだからfnキーも活用していきたい。

    反省点

    60%キーボードとして普通に使えるものができた。

    キーボードケースの工作精度がひどすぎたのでまともに作れる方法を考える。

    強く押し込むとたわむが、このたわみ自体は悪いものではないらしい。しかし基板なしのプレートのみだと不安な部分はある。

    キーボードの高さは既製品とほぼ同じだったがもう数ミリは薄型化の余地がある。

    アクリルカット注文しサンドイッチとか積層で作るのが強度を担保できるのでアリかもしれない。でもちゃんとケースの方が見た目いい気がする。でもアクリルカット注文すると今回の場合一番金のかかる部品がケースになるんだよなあ。

    最近のキーボードはホットスワップのモノが多いし中華メーカーであれば8000円程度でホットスワップの完成品が日アマでも売っている。製作費用は8000円程度だったのでわざわざパーツを集めて作る意味は薄い。

    個人的なUS配列ライクなJIS用自作キーボードの試作という目的は達成されついでに矢印キーも入れることができたので目標は達成されたと思う。

    次の記事:左右分割40%キーボード(試作)を手配線で作る 自作キーボード

  • [自キ]FPS専用の左手デバイス(試作)を手配線で作る

    FPSゲーム用チルトグリップ対応ホイール付き左手デバイスを手配線で作りました。自キ制作レポートです。

    21キー+ホイール+ホイールクリックのレイアウトで自作キーボードを制作しました。

    前の記事:[自キ]初めての自作キーボード テンキー(試作)

    設計方針

    左手デバイスといえばRazerやAzeronが有名だと思います。それらの左手デバイスに触発され制作をしました。

    EC2等左右非対称の自然に握れるマウスがあるのなら左手も同様なのではないか、傾斜をつけチルトグリップに対応させてみる。

    キーボードはロウスタッガードですが手に合わせたキーレイアウトを採用し自然に指を配置できるようにしてみる。

    販売されている左手デバイスは親指にアナログスティックを配置したものが多いですが今回マウスホイールを配置してみる。背景としてBFVでスライディング・パルクールをマウスホイールに割り当てるとよいのですができればマウスは左右クリックに指を置いておきたい。なので左手に割り当てようと思ったわけです。

    これらのことから 21キー+ホイール+ホイールクリックの左手デバイスを制作することにしました。ダンボールで試しに作ってみていい具合の角度等を模索し 制作に入りました。

    出来上がり

    左が低くて右が高くなっておりチルトグリップに対応しています。キーボードだと下に押し下げる感じですが、握りこむように持てて安定感があります。

    手前が低くて奥が高く、また上の段と下の段を折り曲げ傾斜をつけることで指のみでアクセスしやすくなっています。単純ですがかなり効果は高く押しやすくなりました。キーボードだとZが非常に押しにくいと感じていたのですが指の動線にフィットし解消されました。

    親指でほぼSpaceキーから指を動かさずホイール操作を行うことができます。

    材料

    マイコンPro Micro- 遊舎工房
    ダイオード1SS178-秋月電子通商
    配線用ワイヤはんだメッキ線 0.6mm-秋月電子通商
    耐熱電子ワイヤー 外径1.22mm-秋月電子通商
    キースイッチEPOMAKER AKKO (Vintage White)-Amazon
    キーキャップMIHIYIRY PBT キーキャップ-Amazon
    ホイール周りglorious Model O-から流用
    プレートPC板 2mm厚
    パームレスト紙粘土、グリップテープ

    キーレイアウト

    Keyboard Layout Editor (keyboard-layout-editor.com)にて作成しました。

    赤線の部分は折り曲げ傾斜がつけられています。手に合わせてキー配置を微調整しました。

    組み立て

    プレート

    トッププレート、ボトムプレート、サムプレートの3枚 についてPC板をアクリルカッターで切り出した

    キースイッチ用の穴もアクリルカッターで開ける予定だったが気が遠くなったのではんだごてで溶かし四角く穴をあけた。当然部屋は樹脂が溶けた異臭がひどかった。穴の淵には溶けた樹脂がたまっていてペンチで取り除く必要があった。最後にやすりで削り整えた。もうやりたくない。

    折り曲げもはんだごてで熱を加えて行った。


    配線

    キースイッチ、マイクロスイッチ、ホイールエンコーダをそれぞれはめこみボンドで固定した。

    ダイオードとワイヤをはんだ付けし手配線。

    配線が汚いしpromicroは固定されていない。とても見栄えが悪いが使用する分には問題ない。


    プレート組み立て

    それぞれのパーツをねじで留め固定した。

    画像に alt 属性が指定されていません。ファイル名: 10f466f157e460bd9f29d9ef5173f9d6-1024x966.jpg

    パームレスト

    紙粘土を成形し乾燥後グリップテープを張り付けた。

    こちらも見栄えは悪いが多少弾力もありグリップ力もあるため性能としては十分。

    Firmware

    config.h

    # pragma once
    #include “config_common.h”

    #define VENDOR_ID 0xFEED
    #define PRODUCT_ID 0x0001
    #define DEVICE_VER 0x0001
    #define MANUFACTURER tsuiha
    #define PRODUCT leftdevice01

    #define MATRIX_ROWS 4
    #define MATRIX_COLS 6

    #define ENCODERS_PAD_A { D3 }
    #define ENCODERS_PAD_B { D2 }
    #define ENCODER_RESOLUTION 4


    #define MATRIX_ROW_PINS { B1, D4, B4, E6 }
    #define MATRIX_COL_PINS { B6, B2, F7, C6, D7, B5 }

    #define DIODE_DIRECTION COL2ROW

    黄色線で示した部分が今回ホイールを使用するのでその分となります。他は行列の指定です。


    leftdevice01.h

    #pragma once

    #include “quantum.h”

    #define LAYOUT( \
        k01, k02, k03, k04,    \
     k10, k11, k12, k13, k14, k15, \
     k20, k21, k22, k23, k24, k25, \
     k30, k31, k32, k33, k34, k35 \
    ) { \
    { KC_NO,  k01, k02, k03, k04, KC_NO}, \
    { k10 ,   k11, k12, k13, k14, k15  }, \
    { k20 ,   k21, k22, k23, k24, k25  }, \
    { k30 ,   k31, k32, k33, k34, k35  } \ }

    こんな感じの配線にしました。


    keymap.c

    #include QMK_KEYBOARD_H

    #define BASE 0
    const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
     [0] = LAYOUT(
             KC_1  ,KC_2  ,KC_3  ,KC_4    ,    \
      KC_TAB   ,KC_Q  ,KC_W  ,KC_E  ,KC_R   , KC_H , \
      KC_LSHIFT ,KC_A  ,KC_S  ,KC_D  ,KC_F    , KC_B , \
      KC_LCTRL  ,KC_Z  ,KC_X  ,KC_C  ,KC_SPACE ,KC_V \
      ),
    };

    bool encoder_update_user(uint8_t index, bool clockwise) {
    if (index == 0) { /*First encoder */
     if (clockwise) {
      tap_code(KC_J);
     } else {
      tap_code(KC_K);
     }
    } else if (index == 1) { /*Second encoder */
     if (clockwise) {
      tap_code(KC_DOWN);
     } else {
      tap_code(KC_UP);
     }
    }
    return true;
    }

    黄色線がエンコーダの部分です。Second encoderについてはよくわかりません。公式ドキュメントのコピペです。

    JとKにホイールを割り当ててありますが当然普通にマウスホイールを割り当てることもできます。

    反省点

    見た目はよろしくないが、使用感は非常に満足のいくものだった。

    PC板の加工についてだがこれがよくなかった。もっと簡単な方法を検討する必要がある。見立てが甘かったのだが、やっていてほんとに嫌になった。

    ・ホットナイフを使うのはどうか、はんだごてと大差ないような気もするが多少ましだろうか。

    ・折り曲げ部は折り曲げるのでなくL字の金具を使うのもいいかもしれない。

    ・アクリルカットを注文するのはどうだろうか。折り曲げ箇所が多く難がある気がする。

    ・3Dプリンタを使用するのがよいかと安直に思うのでそのうち導入したい。

    左手デバイスというのだからアナログスティックを搭載するのもよいと思う。親指でホイール

    操作するのはなかなか快適なのでアナログスティックにこだわる必要はない気もする。

    キー配列は手にはあっていたが数字キーが少し指から遠かった。手に合っているのもよいがキー密度を上げ指の移動量を減らす方が重要かもしれない。あるいはazeronのようにマイクロスイッチを用いることで省スペース化し密度を上げるのもいいかもしれない。

    本体、パームレストともに見栄えよく高クオリティなものを作りたい。

    机の上にキーボードを一つしか置きたくないというようなことがなければ、導入しない手はないというほどには快適であった。チルトグリップなのは好みがわかれるところだが、そうでないものを設計し使用すればよい。

    個人的には左右対象マウスを使用するときは使いやすかったが、非対称マウスを使用するときはキーボードの方が使用感がよかった。平面タイプの左手デバイスを制作するのもよいかもしれない。

    Razerは1万円、Azeronは2万円とキーボード同等の値段がするが今回制作したものは材料費3000円程度であり格安で最高の快適さを得られた。

  • 通常時視野角からADS視野角を求める FPSとFOV③

    視野角の変換式でアスペクト比の比率を用いましたが今回はモニターディスタンスを係数として利用することにします。また画面上のズーム倍率で視野角を変換し腰だめ視野角からADS視野角を求めます。

    前の記事:FPSとFOV② 異なるアスペクト比に視野角を変換

    タンジェントで整理する

    $$
    \mbox{[出力fov]}=atan\left(
    \frac{\mbox{[変換先アス比]}}{\mbox{[変換元アス比]}}
    tan\left( \mbox{ [入力fov]}\frac{\pi}{360}\right)
    \right)
    \frac{360}{\pi}
    $$

    アスペクト比による視野角の変換式はタンジェントで表された式でした。

    では上記前回のイメージ図もタンジェントで整理し直します。

    上図では半径を1として書き込みましたが今回は1/cosθとして書き込んでみます。

    右の三角形についてa、b、cを求めます。

    $$
    a =\frac{1 }{ cosθ}
    $$
    $$
    cosθ = \frac{b }{ a} = \frac{b }{ \left(\frac{1 }{ cosθ}\right)}
    \\b = 1
    $$
    $$
    sinθ = \frac{c }{ a} = \frac{c }{ \left( \frac{1 }{ cosθ }\right)}
    \\c = tanθ
    $$

    左の三角形についてa、b、cを求めます。

    $$b = 1$$
    $$cosφ = \frac{b }{ a} = \frac{1 }{ a}
    \\a = \frac{1 }{cosφ}$$
    $$tanφ = \frac{c }{ b} = \frac{c }{ 1}
    \\c = tanφ$$

    求めた数値を書き込んでみます。

    画面(弦)の部分をタンジェントで表すことで見やすくなりました。

    モニターディスタンスの導入

    $$\frac{\mbox{[変換先アス比]} }{\mbox{ [変換元アス比]}}$$

    アス比による視野角変換式中のこの部分を書きかえます。

    16:9→4:3の変換で係数は3/4=0.75でした。これは水平方向に4:3画面が16:9画面の75%の長さであるということです。

    つまりアスペクト比の比は変換前後で画面上の長さの何%であるかということを表していることがわかります。これは画面上の距離ですからモニターディスタンスです。

    この画面中央から端まで、変換前後で何パーセントかというのがモニターディスタンスでありMD〇%と表します。

    腰だめ時を変換前、ADS時を変換後とすると画面上で何%の位置までズームするかを考えることでADS時の視野角を求められそうです。

    では係数をMDに置き換え前回同様に変換式を求めてみます。

    この時の満たすべき条件は、画面の長さ割合をMDとして

    $$ \mbox{ [ADS時画面比]} = \mbox{ MD}* \mbox{ [hipfire時画面]}
    \\ex) \mbox{ [4:3画面長さ]} = 0.75 * \mbox{ [16:9画面長さ]}$$

    となればよいです。画面長さ( c )は先程求めましたね。代入します

    $$[ADS時画面比] = \mbox{ MD} * \mbox{ [hipfire時画面]}
     \\tanφ = \mbox{ MD} * tanθ
     \\ φ = atan( \mbox{ MD} * tanθ )$$

    radをdegに直します

    $$ \mbox{ [ADSfov]} \frac{\pi }{ 360} = atan \left[ \mbox{ MD} * tan \left( \mbox{ [hipfire fov]} \frac{ \pi }{360} \right)\right]
    \\
    \mbox{ [ADSfov]} = atan\left[ \mbox{ MD} * tan\left( \mbox{ [hipfire fov]} \frac{ \pi}{ 360} \right) \right]\frac{360}{\pi}$$

    腰だめ視野角と、ADS時に画面の何%までズームするかわかればADSfovが求められることがわかりました。

    ADS視野角を求めてみる

    スクショを取ってADS視野角を求めてみます。スクショを取ると横1920ドットですね。画面半分だと960ドットになります。

    ズーム時の画面割合がMDなので

    $$MD=\frac{\mbox{960-[ズーム分]}}{960}$$

    となります。先ほどの式のMDに代入します。

    $$ \mbox{ [ADSfov]} = atan\left[ \frac{ \mbox{960 – [ズーム分]} }{ 960 } tan\left( \mbox{[hipfire fov]} \frac{ \pi}{ 360} \right) \right] \frac{360}{\pi}$$

    ただこの計算式では画面中央から端までの比ですから、すべて16:9HFOVでしか求められませんので主流である4:3fovにはその都度変換し直さなくてはなりません。

    スクショからADS視野角を求めてみました↓

    [計算機]スクショからADS視野角を計算する-Screenshot ADS FOV Calculator

    まとめ

    視野角はタンジェントで考えられることがわかりました。またモニターディスタンスを考えることで画面上の長さと視野角を結びつけることができました。

    次の記事:FPSとFOV④ モニターディスタンスで感度を変換する

  • 異なるアスペクト比に視野角を変換 FPSとFOV②

    視野角はFOVタイプによって数値が変わるためアスペクト比に応じて変換する必要があります。大体CS:GOは1:1fov74、4:3fov90、16:9fov106ということは有名ですが、どうやって相互に変換しているのかという話です。

    前の記事:FPSとFOV① 視野角の種類とイメージ

    三角関数について

     角度θ、辺a、b、cを持つ図のような直角三角形についてサインコサインタンジェントはこの式のように表せます。

    16:9FOVから4:3FOVへの変換を考える

      θ の部分が16:9モニターの右半分で見えている範囲で、φの部分が4:3モニターの左半分で見えている範囲です。

    画面上で縦の視野角を合わせると4:3fovは16:9fovの75%の横幅を持ちます。

    $$\frac{ 4 }{ 3 } ÷ \frac{ 16 }{ 9 } = \frac{ 12 }{ 9 } ÷ \frac{16 }{ 9 } = \frac{1.33 }{ 1.77} = \frac{3 }{ 4 }= 0.75$$

    2つの画面長さ(↔の部分)がこの75%の幅を持つという条件を満たせばよいわけです。

    また16:9fovを4:3fovに変換し角度を求めるわけですからφをθの関数で表したい。

    まず右の黒い三角形16:9fovについて考えます。半径は特に意味もないので1とします。

    三角関数からそれぞれの辺の長さが求まりますね。

    $$a=1
    \\cosθ = \frac{b }{ a }= b
    \\sinθ = \frac{c }{ a} = c$$

     

    次に左のオレンジの三角形の辺の長さを求めます。

    $$b = cosθ$$
    $$cosφ = \frac{b }{ a} = \frac{cosθ }{ a}
    \\a = \frac{cosθ }{ cosφ}$$
    $$tanφ =\frac{ c }{ b }= \frac{c }{ cosθ}
    \\c = cosθ tanφ$$

    「4:3fovは16:9fovの75%の横幅を持つ」という条件を二つの三角形の c について満たせばよいですね。

    また、求めたいのはφですからφについてまとめます。

    $$1 : 0.75 = sinθ : (cosθ tanφ)
    \\0.75 sinθ = cosθ tanφ
    \\tanφ = 0.75 \frac{sinθ }{ cosθ} = 0.75 tanθ
    \\φ = atan( 0.75 tanθ ) = atan\left( \frac{3 }{ 4}tanθ \right)
    $$

    求めることができました。

    θとφではわかりづらいです。三角形を作り画面の半分の角度を用いて計算したので2倍すれば視野角になります。また[rad]だとわかりづらいので[deg]に直します。

    $$2θ[rad] = \mbox{16:9fov[rad]} =\mbox{ (16:9fov[deg])} \frac{\pi}{180}
    \\θ = \mbox{[16:9fov]} \frac{\pi}{360}$$
    $$φ = \mbox{[4:3fov]} \frac{\pi}{360}$$

    θとφに代入し4:3fovについて解きます。

    $$\mbox{[4:3fov]}\frac{\pi}{360} =atan\left[ \frac{3 }{ 4} tan\left(\mbox{[16:9fov]} \frac{\pi}{360}\right) \right]
    \\\mbox{[4:3fov]} = atan\left[ \frac{3 }{ 4} tan\left(\mbox{[16:9fov]} \frac{\pi}{360}\right) \right]\frac{360}{\pi}$$

    16:9fovから4:3fov を求める式ができました。

    アスペクト比に応じて視野角を変換

    ここで式中の3/4に注目します。3/4はどこから出てきた数字でしょうか。

    $$\frac{ 4 }{ 3 } ÷ \frac{ 16 }{ 9 }= \frac{3 }{ 4 }$$

    この条件式でした。こう書き直すことで一般化できそうです。

    $$\frac{3 }{ 4}= \frac{4 }{ 3} ÷ \frac{16 }{ 9} → \frac{\mbox{[変換先アス比]}}{\mbox{[変換元アス比]}}$$
    $$\mbox{[出力fov]} = atan\left[ \frac{\mbox{[変換先アス比]} }{\mbox{ [変換元アス比]}} tan\left(\mbox{[入力fov]} \frac{\pi}{360}\right) \right]\frac{360}{\pi}$$

    一般化できました。サインコサインタンジェントを図に書き込んでいくだけなので簡単です。

     

    計算フォーム:[計算機]異なるアスペクト比に視野角を変換 Aspect-ratio FOV Calculator

    次の記事:FPSとFOV③ 通常時視野角からADS視野角を求める

  • FPSの視野角と感度① 視野角とアスペクト比

    FPSの視野角と感度の関係は自分に合った設定を考える上で重要です。

    一度理解してしまえば単純なことですが、知ろうとする人自体が少なく、理解している人がとても少ないので解説します。

    できるだけかなり嚙み砕いて記述しましたのでそんな当たり前のことを、という部分はどんどん飛ばしていってください。

    はじめに

    じゃあこの記事を追えば強い設定が知れるかというとそうではありません。

    強い設定とは、いろいろな値をそれぞれの組み合わせで全て試行していき経験的に一番パフォーマンスが出た設定であると考えます。

    そのため直接強さに関わるとは思えませんが、ここら辺を理解している人と理解していない人とではFPSゲームに対する理解度が全く異なります。それはSNSなどで設定に詳しい人が重宝されていることから明らかです。

    これらは知らなくてもいい事、ではなくFPSをプレイするうえで最低限知っている必要がある事だと私は思っています。

    仕組みを何も知らなければ、APEXの視野角を103に設定してVALORANTと揃えたとかいう素っ頓狂なことを平気で言ってしまうわけです。(嘘だと思う方もいると思いますがこのラインの方が実際多数派のようです。)

    この記事は視野角と感度について、ゲーム内部でどのように計算されているのかという設定を行う上で最低限必要な知識を身に着けること、またその感覚を得ることが目的となっています。

    具体的には視野角の変換と導出、ADS感度の計算方法と変換までを行います。

    実際のゲーム間での視野角計算方法の差異

    私にも混同していた時期がありました。fov90が一般的らしいぞということでBFをHor90に設定し、R6Sもfov90に設定し揃えたぞと思っていた時期が。しかしそれは誤りです。

    CS:GOがfov90というのは有名です。ではR6Sのfov90、APEXのfov90、BFのHor90、OW90はどれも90ですが同じ視野角でしょうか?同じではありません。

    実際どう違うのかというと

    • R6Sfov90 → CS:GOfov106.26
    • APEXfov90 → CS:GOfov89.25
    • BF Hor90 → CS:GOfov90.27
    • OW90 → CS:GOfov73.74

    となっておりそれぞれ同じfov90であるにもかかわらず異なっていることがわかります。

    これらの差異はアスペクト比というゲーム内FOVタイプが異なるによって引き起こされています。

    アスペクト比とは

    アスペクト比とは長方形における長辺と短辺の比率のことです。

    ディスプレイは横長な状態で使用されるのが普通だと思いますので、FPSにおいては横と縦の画面比と言い換えることができます。

    通常のPCモニターはアスペクト比 16:9 です。

    これを比率としてあらわすと 16÷9 で 1.77… となります。

    実際に計算を行う上では何対何ではなく、このアスペクト比率 長辺÷短辺 の値を使用します。

    • 16:9→1.77…
    • 4:3→1.33…

    といった具合です。

    一般的なPCディスプレイが16:9 であることはフルHDディスプレイの解像度が 1920×1080、つまり 1920÷1080=16÷9 であることから分かります。

    アスペクト比と画面

    ディスプレイが 16:9 なのだから使用されるアスペクト比は16:9しかないのではないかというとそうではありません。

    ゲーム内設定でアスペクト比を変更することができます。

    16:10, 3:2, 4:3, 5:4 等を選択することができます。

    CS:GOを例に16:9と4:3を見てみます。

    16:9
    4:3黒帯(Black Bar)

    このように複数のアスペクト比を使用することができます。

    そして上記画像を比較してみると16:9では壁が見えていますが、4:3では壁までの範囲しか見えていません。横方向の見えている範囲、つまり描画されている水平視野角(Horizontal FOV)が異なっていることがわかります。

    一方で床から空の縦方向に見えている範囲、つまり垂直視野角(Vertical FOV)は等しいです。

    このようにアスペクト比が変わるとFOV設定はそのままなのに見えている範囲、視野角が変わることがわかります。

    またこの4:3画面を横に引き伸ばし黒帯をなくすことで4:3画面を16:9スケールの引き延ばしでプレイすることも可能です。視野角を考える際には引き延ばしについても考慮する必要があります。

    引き延ばすことによって水平方向画面上では4:3の画面範囲がそのまま16:9のアスペクト比に拡大され変更されます。

    アスペクト比と視野角の種類(FOVタイプ)

    CS:GOでは、アスペクト比が変わると画面左端から右端の描画範囲、水平視野角HFOVが異なっていることが分かりました。

    ではアスペクト比ごとに実際に視野角がいくつであるのかを見ていきます。

    注目するアスペクト比は

    • 16:9
    • 4:3
    • 1:1

    の3種類です。基本的にゲームの視野角の計算方法はこの3つのどれかに当てはまるためです。

    視野角が広い外側から 16:9(ピンク線) 、4:3(青線)、1:1(赤線)のアスペクト比における画面外枠となっています。

    CS:GOは一般にアスペクト比 4:3 画面(青線)の時視野角が90度であることが知られています。(このことは振り向き分と画面端までのマウスの移動量を測ることなどして簡単に検証することができます。)

    それではアスペクト比ごとの水平視野角HFOVを示してみます。(計算方法は先の記事で解説します)

    • 16:9 →106.26度
    • 4:3 →90度
    • 1:1 →73.74度

    CS:GOはこの3つのアスペクト比の画面においてこのような水平視野角が描画されています。

    また 1:1 のアスペクト比というのは横と縦が同じであるということなので垂直視野角もこの 73.74度であるということです。

    よって特別なことがない限り垂直視野角 VFOVは1:1HFOVと一致します。

    よってなぜ代表アスペクト比がこの3種類なのかというと

    • 16:9→現在のディスプレイのアスペクト比
    • 4:3→昔のディスプレイのアスペクト比
    • 1:1→ディスプレイの縦方向を基準とする場合

    ということです。

    ここまでで画面アスペクト比が変わると視野角も変わることが分かりました。

    しかしアスペクト比 16:9 の画面のCS:GOの視野角の値 90度 がアスペクト比 4:3 に対応していることはややこしいです。

    そこでアスペクト比を置き換えて、FOVタイプ を用いて表されます。つまりCS:GOにおいて

    • 16:9FOV=106.26deg
    • 4:3FOV=90deg
    • 1:1FOV=73.74deg

    このときCS:GOはFOVタイプ4:3における90度と言います。

    また、ややこしいのですがCS:GOでアスペクト比4:3黒帯画面を16:9に引き伸ばすと、16:9画面が4:3相当になるのでこのとき 16:9FOVは90度となります。

    垂直視野角 VFOV は引き伸ばされていないため 73.74度のままです。

    4:3(引き延ばし)

    視野角が何度であるのかについて、何度であるかだけでなくFOVタイプ(アスペクト比)と共に記載しなければ意味不明であることが分かりました。

    FOV90といったところで、1:1なのか4:3なのか16:9なのか16:10なのかアスペクト比が分からないと何も示せていないということです。

    ゲームごとの基準視野角

    ゲームごとにアスペクト比を変更した際に基準となる方向があります。

    先ほどのCS:GOの画像を再度示します。

    16:9
    4:3黒帯(Black Bar)

    次にVALORANTの場合を示します。

    様子が異なっていることが分かるでしょうか。

    CS:GOでは4:3にすることで横方向の描画範囲が狭まりましたがVALORANTでは縦方向の描画範囲が広くなっています。

    つまりCS:GOではアスペクト比を変更したとき縦方向、VFOVはそのままであるのに対し

    VALORNTはアスペクト比を4:3にすると横方向、HFOVがそのままであることが分かります。

    これの何が問題であるかというと、まずVALORANTは16:9HFOVが103であることが知られていますが、4:3(Black Bar)でプレイした際にはHFOVがそのままであるので、

    4:3FOVが103となり、16:9FOVが118.36に変わってしまうということです。

    VALORANTで4:3引き延ばしを行うと実際には縦方向の押し縮みになるということですね。

    多くのタイトルではCS:GOと同じ方式ですが、このようにアスペクト比によって視野角が変わる特殊例があります。なので視野角を記述する際はFOVタイプを併記しなくては情報を伝えることができないということです。

    視野角のイメージ

    円を描いてみます。すると視点を中心として上空から俯瞰した状態となります。

    視野角とは視野の角度ですから、図のように見えている範囲を扇形(青線)とすればその中心角が視野角となります。

    その扇形に弦(オレンジ線)を引くことができます。この弦が周囲を映し出す画面になっているというわけです。

    例えば自分から等距離に4人の敵(黒点)がいたとして、図中の矢印のように画面に射影されるわけです。

    またこの4人の敵についてみてみると、自分からは等距離ですが、画面からの距離だと外側の敵ほど近くなっています。

    というのは画面(オレンジ線)を上にスライドしていくと外側の敵が先に画面にぶつかります。この画面との距離感が画面に映るサイズ感と一致するということです。

    なので等距離のモノでも画面中央と比べ画面端に映すとより大きく拡大されて見えるわけですね。

    画面中央の方が角度の密度が濃く、画面端に寄るほど角度の密度が薄いことがわかります。


    もう少し例を示します。円はプレイヤーの真上からの俯瞰図、矩形は画面上とします。

    円の中心がプレイヤーの視点として円周上つまりプレイヤーから等距離な一に敵が5人いると仮定します。

    ピンクで塗りつぶしている部分が画面に描画されている範囲、画面相当の角度とします。

    ということで視野角についてこのようなイメージで話を進めていきます。

    おわり

    最初の話をするとゲームタイトルごとにFOVタイプが異なった表記をしておりCS:GOは4:3FOV、R6Sは1:1FOV、OWは16:9FOVです。

    それぞれゲーム内で同じ視野角の値に揃えたところでFOVタイプが異なっているので何も揃わないということはわかったと思います。

    FOVタイプが異なっていてはゲーム間で視野角を正しく比較することができません。(4:3FOV90と16:9FOV103はどれだけ異なるのかどっちがどれだけ広いのか?)

    よって視野角を揃えるにはFOVタイプ間で値を相互に変換する必要があるというのが次につながる話です。

    次の記事:FPSとFOV② 異なるアスペクト比に視野角を変換