3月にブログを始めてからの累計アクセスが1,000を超えました!
まずは安定して1日20アクセス位稼ぐのを目標に頑張っていきたいと思います。
3月にブログを始めてからの累計アクセスが1,000を超えました!
まずは安定して1日20アクセス位稼ぐのを目標に頑張っていきたいと思います。
【6/24 MSI Fan Day開催記念企画】
— MSI JAPAN (@MSI_JP) 2017年6月16日
TwitterにあなたのMSIに対する熱い思いを投稿してください。抽選で、MSIオリジナルグッズをプレゼントします!投稿には、ハッシュタグ「#MSIJPFANDAY」を忘れずに。応募期間は6月30日(金)まで!😜😜😜😜 pic.twitter.com/T9ZnxJzs2H
こちらのキャンペーンに応募していましたが、まさかの当選!開封しました!
何が届くか知らないまま待ってましたが、思ってたより大きな箱……。
お?
おおーっ!
すごい!かっこいい!
このページのドラゴンのフィギュア4種類でした!エフェクト付き!
なんかもう、かっこよすぎて中身取り出せなかったです^^;
MSI Dragon-G Mini Seriesというそうです。というかコレ、国内では手に入らないやつですよね。
しばらく自分だけで愛でたら、研究室に持っていって守護龍になってもらう予定です。
MSIのGS43やGS32のような軽量ゲーミングノートが自分の好みにドンピシャ
— wrongwrong (@wrongwrong16337) 2017年6月16日
GTX 10シリーズや、MAX-Qのように、軽量なゲーミングノートを実現する技術が出てきた中、MSIの軽量ゲーミングノートには大きく期待しています!#MSIJPFANDAY
ご期待頂き、ありがとうございます👍
— MSI JAPAN (@MSI_JP) 2017年6月29日
数年後を見据えて秘密兵器開発中🤗
MSIさん!本当にありがとうございました、こっちもワクワクしながら待ってます!
Androidでは、c++のみで書かれるNativeActivityがあります。
github.com
これは通常のActivityと同じように、別のActivityから遷移させることが可能です。
今回は、この遷移についてやった内容を記事にしました。
上のGoogleのサンプルのnative-activityサンプルを利用し、タッチイベントでNativeActivityに遷移を行うサンプルプロジェクトをGitHubに上げました。
github.com
これについて解説を行います。
今回は、先程貼ったGoogleのサンプルコードを、遷移先で動かそうと思います。
そのための準備を行っていきます。
Include C++ supportで自動生成されるnative-lib.cppは使わないので消します。
次に、プロジェクトのapp/src/main/cppフォルダに、サンプルプロジェクトのandroid-ndk/native-activity/app/src/main/cpp/main.cppを置きます。
app/CMakeLists.txtの内容を、以下で置き換えます。
cmake_minimum_required(VERSION 3.4.1) # build native_app_glue as a static lib set(${CMAKE_C_FLAGS}, "${CMAKE_C_FLAGS}") add_library(native_app_glue STATIC ${ANDROID_NDK}/sources/android/native_app_glue/android_native_app_glue.c) # now build app's shared lib set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=gnu++11 -Wall -Werror") # Export ANativeActivity_onCreate(), # Refer to: https://github.com/android-ndk/ndk/issues/381. set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -u ANativeActivity_onCreate") add_library( native-activity SHARED src/main/cpp/main.cpp ) target_include_directories(native-activity PRIVATE ${ANDROID_NDK}/sources/android/native_app_glue) find_library( log-lib log ) target_link_libraries( native-activity android native_app_glue EGL GLESv1_CM ${log-lib} )
大概がサンプルからのコピペで、ソースのパス位しか変えていません。
注意点としては、ビルド後のコードはnative-activityとなっている点でしょうか。
後述するAndroidManifest.xmlと、MainActivityでのloadLibraryでは、この名前を指定します。
app/build.gradleのexternNativeBuild内、cmakeの項目に、abiFiltersとargumentsの追記を行い、以下のようにします。
apply plugin: 'com.android.application' android { compileSdkVersion 25 buildToolsVersion "25.0.3" defaultConfig { applicationId "com.wrongrong.changetonativeactivitysample" minSdkVersion 9 targetSdkVersion 25 versionCode 1 versionName "1.0" testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" externalNativeBuild { cmake { abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a', 'arm64-v8a', 'mips', 'mips64' arguments '-DANDROID_PLATFORM=android-9', '-DANDROID_TOOLCHAIN=clang', '-DANDROID_STL=gnustl_static' } } } ︙
自動生成されるcmakeの項目にはcmakeのフラグについて記述(c++11を指定した場合、c++11に関する記述)がありますが、これは先程CMakeLists.txt内に記載を行ったので、消してしまって構いません。
AndroidManifest.xmlの、application部に、activityに関して追記を行い、以下のようにします。
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.wrongrong.changetonativeactivitysample"> <application android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:roundIcon="@mipmap/ic_launcher_round" android:supportsRtl="true" android:theme="@style/AppTheme"> <activity android:name=".MainActivity"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <!-- Our activity is the built-in NativeActivity framework class. This will take care of integrating with our NDK code. --> <activity android:name="android.app.NativeActivity" android:label="@string/app_name" android:configChanges="orientation|keyboardHidden"> <!-- Tell NativeActivity the name of our .so --> <meta-data android:name="android.app.lib_name" android:value="native-activity" /> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> ︙
ここまで行った変更に合わせ、MainActivity.javaの内容を変更します。
public class MainActivity extends AppCompatActivity { static { System.loadLibrary("native-activity"); } @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); TextView tv = (TextView) findViewById(R.id.sample_text); } //タップイベントで、nativeactivityに遷移する @Override public boolean onTouchEvent(MotionEvent event) { Intent intent[] = new Intent[1]; intent[0] = new Intent(MainActivity.this, NativeActivity.class); startActivities(intent); return true; } }
ここまで紹介した手順によって、NativeActivityに遷移することができます。
アクティビティの遷移は、以下のサイトを参考にさせていただきました。
akira-watson.com
今回はNativeActivityへの遷移まで実践しました。
このような場合のActivity間のデータのやり取りはどのようにするのかはまだ検証していないので、検証したらいつか記事にするかもしれません。
以前c++で実験してみたif文と%(剰余)の比較をjavaでもやってみました。
wrongwrong163377.hatenablog.com
プロジェクト全体はGitHubに上げました。
github.com
public class Main { public static int MAX = 1000000000; public static int If(){ int i = 0; int j = 0; long start = System.nanoTime(); while(i < MAX) { if((j+=1) == 100) j = 0; i++; } long end = System.nanoTime(); System.out.println("If Time:" + (end - start) / 1000000f + "ms"); return i + j; } public static int Mod(){ int i = 0; int j = 0; long start = System.nanoTime(); while(i < MAX){ j = (j+1)%100; i++; } long end = System.nanoTime(); System.out.println("Mod Time:" + (end - start) / 1000000f + "ms"); return i + j; } public static void main(String[] args) { int Ifres = If(); int Modres = Mod(); System.out.println("If :" + Ifres + "\nMod:" + Modres); } }
実行結果は以下の通りです。
10回ほど実行して最速だったものを選びました。
Mod | If |
---|---|
3383[ms] | 249[ms] |
前回の結果からどちらが速いかという結果については予想できていましたが、c++に比べてjavaのifの結果が滅茶苦茶速いですね。
何回やっても結果はかなり安定していたので、計測ミスではないと思います。
Modに関しても、言うほど遅くはありません。
こうなってくると、以前やったAndroid上でのc++とjavaの速度比較の結果が何だったのか気になります。
wrongwrong163377.hatenablog.com
気になるけど検証する時間が……。
時間計測はこちらのサイトを参考にさせて頂きました。
qiita.com
wrongwrong163377.hatenablog.com
Thermaltake Tt eSports VENTUS Z MO-VEZ-WDLOBK-01のリフトオフディスタンス(LOD)について少しだけ検証してみました。
計測は、ARTISAN 飛燕 Value Edition M ジャパンブラック HI-VE-JB-Mの上で、10円玉(厚さ1.5mm程度)を重ねた上にマウスを置いて行います。
ARTISAN 飛燕 Value Edition M ジャパンブラック HI-VE-JB-M
また、設定項目としてリフトオフコントロールがあったので、これについても検証します。
上のデフォルトの状態では、10円玉1枚でも反応しない=LOD1.5mm以下でした。
ここから一目盛右の「高」側に設定したところ、ギリギリ反応するかしないかというような反応を見せました。
反対に「低」側に寄せた所、やはり反応しなかったので、LOD1.5mm以下で動かせると見て間違い無いでしょう。
Thermaltake Tt eSports VENTUS Zを購入したので、(酷い)写真付きでレビューしたいと思います。
とても持ちやすく使いやすい印象を持っています。
パッケージの外観はこんな感じでした。
意外と小さな印象です。
内容はマウスと説明書とステッカーでした。
USBの端子にはThermaltakeのロゴが刻印されています。
重りは4.5gx3個が、マウスに装備された状態で同封されていました。
持った感じは、「軽くてコンパクト」でした。
また、自分の自然な持ち方では、とても持ちやすく感じました。
手は大きくない方だと思いますが、十分持ちやすかったです。
ボタン配置に関しても、押し辛そうなボタンは無く、誤爆しそうに感じたのは左上の2ボタンについてのみで、押し間違いはそこまで気にせずに済みそうかなと感じました。
とりあえず第一印象はここまでとして、これ以上の感想は使い込んでからしようと思います。
ここで一度コケました。
公式サイトからインストールファイルを落としてこなければならないのですが、このリンクがわかりにくいです。
正しいリンクは↓の、通り、COMMAND CENTERのようです。
TT ESPORTS COMMAND CENTER V2.0000 | 2017/03/09 | GAMING SOFTWARE V2.0 |
ちなみに一番上のTT ESPORTS PLUS+は、インストールするとMSのIMEが英語入力のみ&キーボードを英字キーとして認識するというトラブルを起こした上、内容はドライバではなく意味の分からないゲーム的な何かでした。(これを期にGoogle IMEユーザーになったよ!)
正しいリンクから落とした.rarファイルを解凍し、実行(セキュリティーソフトで止められる場合がありますが、そのままインストール)して下さい。
起動後は、すぐにマウスのファームウェアアップデートの通知が来るかと思います。
機能性は十分ですが、とりあえず日本語翻訳はゴミです。
また注意点として、表示されている画像にはライトオプション(イルミネーション)の設定が反映されません。
デフォルトでは以下のように設定されています。
センサー設定はパフォーマンスの項目から行います。
軸別の解像度や、XY軸の回転、リフトオフディスタンス、ポーリングレートなど、基本的な機能の設定がすべて揃っていました。
また、この項目はプロファイル毎に設定可能です。
左右クリックやスクロールクリック含めすべてのキーのカスタマイズが可能です。
設定の翻訳がちょっとアレなので、分かりにくそうな部分を書きます。
正直この部分は、項目内にも翻訳がおかしいのか何なのか気になる項目がありますが、この辺りを把握していれば基本的な設定は全部できます。
ただ、シングルキー機能の中でコンボキーの設定が見つけられなかったので、自分はマクロとしてコンボキーを登録し、割り当てました。
マクロ設定には興味が無いので画像だけとします。
ここではNewMacroという名前でCtrl+fを設定しています。
イルミネーションは。ライトオプションから設定します。
こちらも興味が無いので画像のみとします。
OSD表示に対応しており、プロファイル切り替えなど、様々な場面で画面に表示が行われます。
起動時のプログラム自動起動や、OSDの有効/無効化は、デスクトップ右下のプログラム一覧に表示されるアイコンを右クリックすると設定できます。
CPU使用率が何だか高いので、基本的な設定が済んだら切っておくのが良いと思います。
別記事で検証した内容を記載します。
wrongwrong163377.hatenablog.com
買ってからすぐのレビューなので、使っていくうちに印象が変わるかもしれませんが、第一印象は非常に良いものでした。
個人的には、軽量さ、持ちやすくて誤爆し辛い形状、多彩な設定項目と機能の3点が非常に気に入りました。
この辺りに常に不満を抱えながらマウスを利用していたので、買って大正解という印象です。
自作PCのケースファンの基礎的な4つのスペックについて解説します。
ケースファンのスペックをしっかり解説しているサイトが案外見つからなかったので書きました。
今回はファンの性能部分に主眼を置いて書いたので、ケース全体のエアフローやファンの制御方式などには深く触れていません。一応以下の情報(少し古いですが)も見て頂けるとありがたいです。
ファンの大きさを決定する要素です。
基本的に大きく厚いファンほど大風量・静音になる傾向があります。またファンが厚ければ厚いほど高静圧になる傾向があります。
よくケースに搭載可能なファン径として採用されているのは120mm、140mm、200mmの3種類です。通常のファンの厚みとしては25mmがよく採用されています。
薄型ファンとしては15mm、20mm厚のものが、厚型ファンとしては38mmのものなどがあります。
ファンの形状として、厚さや径の他にリブの有無も重要な選択ポイントとなります。リブの有無に関しては以下のページにて詳しく解説されています。
USED NOTE ケースファンの話 その2 リブの有り無し
ラウンドフレームファンは、Cryorig XF140などのような、フレーム形状が円形に近いファンです。
ファンの径は140mmだが固定は120mmのねじ穴など、径よりも一回り小さい穴に固定する形を取っているものが多く、省スペースである性質上CPUクーラー用のファンによく採用されています。
ケースファンとしてラウンドフレームファンを選ぶ際は、ねじ穴のサイズが対応しているからといって径の大きさが合わなければケースに入らない点に注意が必要でしょう。
ファンの出す音量を表す数値です。
この数値が意外と曲者で、出ている数値は単位がdBであることが殆どであり、ホンやラウドネスレベルといった単位ではないため、単純な「うるささ」を表してはいません。
例えば高めの音が出るファンは同じdB値でもうるさく感じたり、音質によっても動作音が不快に感じる場合があります。
基本的にファンの回転数(RPM)に比例して動作音は大きくなりますが、高品質なケースファンでは高回転数でも比較的静穏性に優れる場合もあります。回転数以外にも、ケースファンの軸の種類や質、ファン形状による風切音の違いなどによって静穏性が変わります。
静穏性を確認する際は最初に見る数値ではありますが、前述の通り意外に当てにならない数値なので、レビューなども確認しておくと良いでしょう。
高くて色がダサくてもよければ、Noctua製のファンは静穏性と風量や静圧に優れた高品質なファンだとされています。
騒音値以外のもう一つの目安として、ファンの回転数制御のレンジがどれだけ広いかが有ります。
ケースファンは常に最高速で運用するだけでなく、マザーボードやファンコントローラーによって、温度に合わせて速度を制御することもできます。ここで回転数をあまり下げられないファンを選んでしまうと、負荷を掛けている訳でも無いのに音が気になるという状況が発生する場合もあります。
一方高速でも低速でも動かせるファンを購入することで、必要な時には高速、そうでない時には低速に制御し、いつもは静かだが必要なときは冷却性能を発揮するようにすることも可能です。
最近では必要が無い時には完全にファンを止めてしまうセミファンレス機能に対応したファンやファンコントローラ・マザーボードも有るため、回転数制御に関してはシステム全体で考えてみても面白いでしょう。
音の性質については、下記のWikipediaの項目が分かりやすいと思います。
CFM、m^3/hなどの単位で表される値で、よくファンのスペックに記載されています。
これは、遮るものの無い状態で(ここ重要)ファン径に対してどれだけの量の空気を流すことができるかという値です。
mmーH2Oなどの単位で表される値です。
この値はケースファンにとってかなり重要な値のはずですが、案外公表されていないことがある値です。
静圧とは閉じた空間に対してどれだけ空気を送り込むことができるかという値です。
風量と静圧の関係については、以下の記事が詳しく解説しています。
風量が多いからといって静圧が高いとは限らないという点は誤解されていると思います。特にケース内の気圧が高い状態(これを正圧状態と言い、ケース内に埃が入りにくくなる。対義語は負圧状態)を作ろうと思うと、採用すべきなのは高風量ではなく高静圧なファンです。ラジェーターにファンを付ける場合にも、高風量よりは高静圧なファンを選ぶ必要が有ります。
一方遮るものの少ない状態で効率良く排気したいなどの用途では高風量のファンが適しています。
ケースファンが最大動作のために要求する電流です。
一般的なファンの利用方法では問題になる場合は殆どありませんが、大電流を要求する特殊なファンや、分岐ケーブルを利用して1つのコネクタに多くのファンを接続する場合には過電流が問題となる場合があります。
過電流はマザーボード・ファンコントローラー等を壊す場合もありますので、繋ぎたいファンの消費電力に対する機器のコネクタの供給電流量は調べる必要が有ります。もし供給可能量を超えている場合には、分岐を減らして別のコネクタと合わせる、電源に直接接続する、ファンコントローラーを導入するなどの対策があります。
また、基本的に1つのファンコネクタが供給している電流量は2Aであることが多いです。
ケースファンの選び方としてはここで紹介した4つのスペックを基準に大体選んでいくことができると思います(騒音値は別ですが……)。
おまけとして面白い機能を持ったファンを紹介します。
ENERMAXのD.F.シリーズのファンは、PC起動時にファンを逆回転して埃を払う、DustFreeRotation(DFR)technologyを採用したファンです。
本文中で紹介したUCDFS12Pは2017/7/8日発売のD.F.シリーズ最新(2017/7/13)の製品で、最大11.131mm-H2Oという超高静圧を実現しているファンです。
最近のライティングの流行に合わせて、各社からRGBで制御可能なファンが続々登場しています。
ただし、案外汎用4ピンLEDヘッダで制御できる製品が少ない点は注意が必要でしょうか。
少し前までは一色で光れば十分だったことを考えると、相当な進歩だと思います。
最後はファンではなくファングリルです。
以前も紹介した商品ですが、この製品の利点はライティングを考えるときにケースファンの選択肢が広がる点です。ケースファンには静圧や風量などのスペックの違いがありますが、RGB LED内蔵ファンとなると選択肢が狭くなりがちです。しかし、この製品を使うことでそういった制約を気にせずにファンを選ぶことができます。