- Home
- 一覧
- 雑記
-
[自キ]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は固定されていない。とても見栄えが悪いが使用する分には問題ない。
プレート組み立て
それぞれのパーツをねじで留め固定した。
パームレスト
紙粘土を成形し乾燥後グリップテープを張り付けた。
こちらも見栄えは悪いが多少弾力もありグリップ力もあるため性能としては十分。
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②
視野角は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}$$ 一般化できました。サインコサインタンジェントを図に書き込んでいくだけなので簡単です。
-
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② 異なるアスペクト比に視野角を変換
-
[自キ]初めての自作キーボード テンキー(試作)
自作キーボードやってみたいと唐突に思い道具をそろえ挑戦することに。
初めてなこともありキー数の少ないテンキーを作り自作キーボードを大まかに理解することを目的とした。
また今回自作キーボードに挑戦するうえで「手配線で自作キーボードを作る講座 – おかゆ++」さんを参考にしました。
購入した材料
Pro Micro(単体) 660円
マイコン
Kailhロープロファイルスイッチ(10個)白 440円×2セット
キースイッチ。分厚くなりそうだったのでロープロファイルにした。18キーで作ったため20個購入。
MBK Choc Low-Profile Keycaps 550円×2セット
キーキャップ。キースイッチよりキーキャップの方が高いとは!
タクタイルスイッチ – 2pin 3.5x6x4.3mm 11円
リセットスイッチ。結果としてはわざわざリセットスイッチ設けなくてもピンセットで短絡させればいいかなと思った。
高速スイッチング・ダイオード 1SS178(100本入) 100円
ダイオード
プラ板(PC)数百円
9×11cm程度×2枚使用。いわゆるサンドイッチプレートみたいな感じ。特に理由なくPC板を購入したが柔らかく加工がしやすかった半面テンキー自体もふにゃふにゃになった。
ネジ・スペーサー 数百円
プラ板固定用。ネジはM3、スペーサーは1cmのやつ。
完成
4×5の18キーで空いたところにマイコン張り付ける感じのテンキーとなりました。汚い出来上がりですね。雑で不器用だな。
組み立て
プラ板の切り出し
普通キーボードは1キー19.05mm四方でつくられていること、ねじ止めする余白を1cmとったことから
縦86.2mm、横105.25mmを2枚アクリルカッターで切り出しました。
プラ板の穴あけとキースイッチの固定
普通アクリルプレートは14mm角の穴をあけキースイッチをはめると思うのですが加工するのが非常にめんどくさいと思ったので別の方法をとることにしました。
Kailh choc v1のデータシートから足の位置を確認してプラ板に電動ドリルで穴をあけました。また、キースイッチを差し込みボンドで固定しました。
行列の配線
格子配列なので手配線は直線ばかり、単純でした。
promicroとの配線
回路とpromicroを耐熱電子ワイヤで配線します。今回は下側の9つのpin、promicroに書いてある5~10、14~16を使用しました。耐熱電子ワイヤをはんだ付けしました。promicroにはんだ付けするのは穴同士が近いし少しめんどくさい。
組み立て
promicroはボンドでプラ板に張り付け、そこら辺にあったUSBを刺しておきました。
スペーサーをプラ板で挟みねじ止めしキーキャップをはめたら本体は完成。
Firmware
config.h
#pragma once #include "config_common.h" /* USB Device descriptor parameter */ #define VENDOR_ID 0xFEED #define PRODUCT_ID 0x0000 #define DEVICE_VER 0x0001 #define MANUFACTURER Tsuiha #define PRODUCT tenki01 /* key matrix size */ #define MATRIX_ROWS 4 #define MATRIX_COLS 5 #define MATRIX_ROW_PINS { B1, B3, B2, B6 } #define MATRIX_COL_PINS { C6, D7, E6, B4, B5 } #define UNUSED_PINS /* COL2ROW, ROW2COL */ #define DIODE_DIRECTION COL2ROW
「define MATRIX」で行列を定義する必要があるらしい。今回だと縦に4キー横に5キーなので行(ROW)が4、列(col)が5とします。
「MATRIX_PINS」で行と列で使用するマイコンのピンを指定します。テンキーの0~3行、0~4列で配線したピンを指定します。
「COL2ROW」はcolからrow(縦線から横線)に電流が流れるということらしい。ダイオードの向きと対応させます。
tenki01.h
#pragma once #include "quantum.h" #define LAYOUT( \ k01, k02, k03, k04, \ k11, k12, k13, k14, \ k20, k21, k22, k23, k24, \ k30, k31, k32, k33, k34 \ ) { \ { KC_NO, k01, k02, k03, k04 }, \ { KC_NO, k11, k12, k13, k14 }, \ { k20 , k21, k22, k23, k24 }, \ { k30 , k31, k32, k33, k34 } \ }
行列とキーの名前を対応させます。わかりやすく座標をそのまま名前にするのが定番なのだろうか。今回は左上のスペースは使用しないがこのように空欄にし下のカッコ内で「KC_NO」とすればよいらしい。
keymap.c
#include QMK_KEYBOARD_H #define BASE 0 const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { [0] = LAYOUT( KC_7 ,KC_8 ,KC_9 ,KC_KP_SLASH , \ KC_4 ,KC_5 ,KC_6 ,KC_KP_ASTERISK, \ KC_DELETE ,KC_1 ,KC_2 ,KC_3 ,KC_KP_MINUS , \ KC_BSPACE ,KC_0 ,KC_KP_DOT,KC_ENTER,KC_KP_PLUS \ ), };
先ほどの行列に合わせてキーコードを打ち込む。
あとはうまくコンパイルできればqmktoolboxで書き込んで完成。
今回は一発で動作したので良かった。
反省とか
- 無事完成しテンキーとして動作、使用することができた。調べたり作ったりの中でなんとなく自作キーボードについて理解が深まった気がする。
- PC板が柔らかく加工しやすいのはよかったがふにゃふにゃになった。素材や厚さはしっかり考えた方がよさそう。
- 簡単だったのでプラ板に穴をあけスイッチを差し込んだが、プラ板が薄い必要があったりキーボードが厚くなったりするのであまりよくないので14mm角にはめ込むほうがよいかな。
- promicroに直接配線したが作業がとてもやりにくかったので棒状のやつを差し込みそこに巻き付けてはんだ付けする方がよさそう。
- 縦の配線、ダイオードの足そのまままげてつなげればよさそう。
初めてにしてはちゃんとできたしまあ上出来なんじゃないだろうか。