wrongwrongな開発日記

情報系大学生が挑戦したことや日常を書いていきます

ブログ開設から半年

どうやら3日前にブログ開設から半年が経過していたようです。

元々は、春休みにAndroidアプリを作成し、その後のプログラミングの備忘録として開設したブログでしたが、自作パーツやゲーム等の記事が増えて、何がテーマのブログだったっけという気分です。

一番アクセスを頂いているのは、以下の記事。

wrongwrong163377.hatenablog.com

RGB LED搭載メモリーへの注目度は高く、全2500アクセスの1/4程度のアクセス数を稼いでいます。

最初はもう少しアクセス伸びるかな、なんて妄想していましたが、アクセスを伸ばすための努力もしていませんし、こんなもんですよね。それでも、はてなアクセス解析で1日平均50アクセスまでは来ているのが、少し嬉しいです。

まあ、自由に書けるのは結構いい感じですね。読み返してみると、初めの方は文体が安定していなかったり、読みにくかったり、今更書き直そうとも思いませんが、今の自分は成長しているんだろう、と思っておきます。

最近の大きな出来事は、大学院に受かったことです。

後2年間(で、終わると良いなあ……)程学生生活を送るのは、地元の友だちなんかを見ていると置いて行かれている感が有りますが、気にせず進むのが良いのでしょう。

【Minecraft】LogisticsPipesを軽くするためのconfig設定(未検証)

こんなタイトルで記事書いておいて大変申し訳ありませんが、今回の記事の内容は未検証で、効果を確認できていません
これらの設定は、特に大規模なロジスティクスネットワークを構築した際に有効になってくると思われますが、まだ自分は大規模なロジスティクスネットワークを構築できていないので、フレームレートへの影響は検証できていません。

環境

自分の環境です。

Mod他 バージョン
Minecraft 1.7.10
Forge 10.13.4.1614-1.7.10
BuildCraft 7.1.22
LogisticsPipes 0.9.3.132

設定1 描画に関して

LogisticsPipes.cfgから、OpaquePipesをtrueに設定します。

    # Render every LP pipe opaque.
    B:OpaquePipes=true

説明を読む限り、この項目はパイプを不透明にレンダリングするということで、描画負荷を軽減することができるはずなのですが、自分の環境で設定してみた所、特に描画に変化がありませんでした。
何か勘違いしているかもしれませんが、取り敢えず検証はできていません。
(17/9/21追記)この項目は、有効にするとパイプが輸送するアイテムがレンダリングされなくなるようです。

設定2 CPUのマルチスレッドに関して

この設定は、4コア以上のCore i7のような、ハイエンド系の環境で有効と思われる設定です。
LogisticsPipes.cfg最下部の、multithreadブロック内、I:countの値を、使用しているCPUのスレッド数に合わせて変更します。
デフォルトの値は4で、今回は自分のPCのスレッド数に合わせて8に設定した例を出しています。

    # Number of routing table update Threads, 0 to disable.
    I:count=8

一個下の設定内容も、恐らく10(heighest)に設定すると、CPUでの処理速度が向上するように思えますが、やはり検証はできていません。

表現の自由と、それを規制すべきだという意見について考えたこと

先日、Twitter社日本法人が入るオフィスビル前で行われたデモをきっかけに、表現の自由と、それがどこまで許されるべきか、という内容の議論が盛り上がっています。

www.huffingtonpost.jp

この話について、自分が考えたことを日記としてまとめます。

デモについて、自分の立場

自分は、「このデモ」そのものには、賛同することができないという立場を取ります。

ネット上で散々指摘されているように、ヘイトとは言えないようなツイートまで踏みつける行為は、それを発信した方へヘイトを向けていることと何ら変わり無いと思うからです。

「ヘイトは表現として規制されるべきだ」という意見について、自分の立場

ここからはデモの話を離れ、その後巻き起こったヘイトと表現規制についての話です。

自分はネット上で、「ヘイトは表現とは言えない、だから規制されるべきだ」という意見を目にしました。また、表現の自由を振りかざしてヘイトを行う人間を擁護するのはおかしい、という意見も目にしました。

これについて、自分は全く同意できません。

というより、「他者を律しようとするようなヘイト」への対抗手段としての表現規制と言うのは、ズレた対応だと感じます。

表現と表現の範囲を超えるもの

自分の結論から言うと、ネット上にただ置いてあるだけのヘイトは、ただの自己満足に過ぎず、自己満足であるが故に表現であり、表現であるが故に自由だ、と考えています。

 自分は、表現とそれ以外の範囲との境界線を、「能動的に他者を律しようとしているか」、という部分に引いています。

「自分はこう思う!」という主張を自己満足で行うことは、誰にも制限されるべきではないと、自分は思います。

それはまだ表現の範囲に留まっていると考えています。

規制されるべきものは何か

自分は、「ヘイトスピーチは表現とは言えない、だから規制されるべきだ」という意見が生まれた裏には、「表現の範囲を超え、他者を律しようとする人間は、表現としてのヘイトを行っている」という認識があるのではないかと考えています。

この認識そのものは殆ど外れていないように思います。しかし、この場合規制されるべきなのは表現の範囲を超えた行いであって、表現ではないはずです。

そもそも、法のような根拠も無しに他者を律しようとするのはただの迷惑行為でしょう。

 これはどんな人間にも関係無く言えることです。

そんな迷惑行為は規制されて当たり前です。それが規制されないのは、表現の自由とは何ら関係の無い話です。

表現としてのヘイトに立ち向かうには?

表現の範囲としてのヘイトまでやめさせようというのであれば、その主張もまた、表現の範囲から出るべきではないと、自分は思います。

権利は万人に認められたものであり、それを犯すことはどんな崇高な理由を掲げようと正当化されることはないでしょう。

終わりに

今回の件で強く感じたことは、「他者を律しようと行動する癖に、事象、原因、根拠の3つを正しく揃えることを考える人間は少ない」ということです。

これらを揃えた意見は、それが正しいのか間違っているのか他人が検証できる、だからこそ他者を律する根拠となりうるのだと、今回の件で自分は考えました。

【Minecraft】BuildCraftのポンプで水源を消すためのconfig設定

最近Minecraftの工業化やってます。Minecraft、時間泥棒ですね……。
本題通り、BCのポンプで水源を消す方法です。

設定

BCのmain.cfgから、pumpsConsumeWaterの項目をtrueに設定します。

    # Should pumps consume water? Enabling this might cause performance issues!
    B:pumpsConsumeWater=true

設定ファイルは、自分の環境ではC:\Users\[ユーザー名]\AppData\Roaming\.minecraft\versions\1.7.10-Forge10.13.4.1614-1.7.10\config\buildcraft\main.cfgでした。

注意点!

これだけの設定では、BCのポンプで水抜きを行うのは不可能です。
『水抜き→水源生成→水抜き……』のサイクルが繰り返されてしまい、水を抜ききる事ができません。
# Should pumps consume water? Enabling this might cause performance issues!とある通り、ただ処理が重くなるだけです。

対策

自分は、ProjectRedなどで導入するCodeChikenCoreの設定から、水流が水源を生成しないように設定しました。
ただし、この対策を取ると当然無限水源が利用できなくなるので注意して下さい。
設定には、CodeChikenCore.cfgから、finiteWaterをtrueに設定します。

	#If set to true two adjacent water source blocks will not generate a third.
	finiteWater=true

ファイルパスはC:\Users\[ユーザー名]\AppData\Roaming\.minecraft\versions\1.7.10-Forge10.13.4.1614-1.7.10\config\CodeChikenCore.cfgでした。

環境

自分の環境です。

Mod他 バージョン
Minecraft 1.7.10
Forge 10.13.4.1614-1.7.10
BuildCraft 7.1.22
CodeChickenCore 1.7.10-1.0.7.47-universal

購入前、自作erなら知っておいて損はないサイト紹介

自作PCを作る前に知っておいて損はない、自分が使っている/使ったことのある基本的なサイトをまとめます。

総合的な情報量が魅力、価格.com

kakaku.com

自作PCを作るなら、価格.comはかなりの量の情報を探せるので、まず最初に見るサイトとしてオススメです。

レビューもそれなりに充実していますし、ピックアップリストや口コミ掲示板への書き込みという形で質問もできます。簡単な質問であればほぼ100%返信が来ます。

注意点としては、時々キツめな返信があったり、レビューも玉石混交で、知識が無ければ判断し辛いことでしょうか。

特に、データや根拠を示していないレビューでも、好評や悪評として最初に目に入ってしまうのは分かっておいた方が良いかもしれません。

価格.comでは十分な情報を集めにくい製品があったり、価格.comでは販売している店が無いとなっていても、実際に調べてみると販売している店があったり、最安値が違っていたりする場合もあります。こういった理由もあり、価格.comは、初めに見るサイトとしてはおすすめですが、全部を頼るべきではないかな、というのが自分の意見です。

レビューとポイント

価格.comでは、レビュー投稿でKC Point(1ポイント≒1円)が手に入るキャンペーンを毎月実践していて、これがまあまあお得です。

前月から連続レビューで300ポイント、その製品への初めてのレビューなら50ポイント、レビューした製品が発売から1年以内なら50ポイント手に入ります。

月1度投稿を繰り返していけば1年で3600円、Amazonギフト券iTunesカードと交換できるので、自作erじゃなくても使いみちは結構あります。

まあ、バイトとかに比べてしまうと実入りは微々たるものなんですが……。

 メモリーはここで探す、PC SHOP Ark

www.ark-pc.co.jp

 メモリー選びで個人的にオススメなサイトは、PC SHOP Arkの通販サイトです。

モリーは、ヒートシンクのカッコよさやレイテンシーなどの情報が重要ですが、価格.comではサムネイルが登録されてなかったり、レイテンシーが書いてなかったりと、探しにくい状態です。

PC SHOP Arkは、それらの情報に加え、メモリーに関する情報、品揃え、探しやすさがあり、見ているだけでも非常に楽しくなれるサイトです。

品揃えという点では、OVER CLOCK WORKSの通販サイトもおすすめです。

www.ocworks.com

 結構安い&ポイントがお得、EC-JOY

www.ecj.jp

 価格.comでも最安値が度々付いているEC-JOYですが、その真価はゲームポイントだと思っています。

1日1度、3分掛からずプレイできるゲームでポイントが獲得でき、自分の実例としては、1年7ヶ月で約1万ポイント(1ポイント=1円)、月500円以上のペースでポイントが溜まっていました。

先日レビューしたTt eSPORTS VENTUS Z RGB MO-VEZ-WDLOBK-01も、このポイントを利用して0円で手に入れたものです。

価格.comよりよっぽど時間効率が良いですね。

自作系パーツは豊富ですが、ここで一式揃えるのは厳しいので、そういう意味では周辺機器や、相性といった保証が絡まないものの購入にオススメなサイトです。

番外、Amazon.com(米尼)

www.amazon.com

番外編として、Amazon.comを紹介します。

代理店税や個人輸入などのキーワードでおなじみですね。

日本では高いパーツを安く買えたり、手に入らないパーツでも買える場合があるので、知っておいて損はないサイトです。

特にAmazon.comは購入の解説サイトも充実しており、トラブル対応が少し面倒という以外は、デメリットよりメリットのほうが大きいサイトです。

特に最近は価格差から、AMD製品の輸入が流行っている印象を受けています。

終わりに

個人的には、購入の際は、まず今挙げたようなサイトで探してから、CPU、マザー、メモリーに関しては一括で買える店で買うことをお勧めします。

TSUKUMOなんかは、通販でも店頭でも品揃えが良くて優秀ですね。

AndroidのOpenGL ESで、カメラからの入力の各画素を処理する

最近AndroidOpenGL ESを触っているので、少しだけ記事にしてみます。
多分タイトルは正確ではないんだろうなあ……。
OpenGL ESやGLSLに関しては全く詳しくないというか、自分のやりたいことはフラグメントシェーダを書くだけで実現できてしまったので、とりあえずその部分だけを記事にしています。

元にしたプロジェクト

今回のプロジェクトは、以下のプロジェクトをコピペして、OpenGL ESのバージョンを3.1に変え、フルスクリーン表示にしたものです。
qiita.com
カメラからの入力を受け取るための部分はこのプロジェクトのまんまです。

サンプルプロジェクト

全体は以下のGitHubリポジトリを参照して下さい。
ランタイムパーミッション関連を書いていないので、必要であればカメラパーミッションの設定をお願いします。
github.com

フラグメントシェーダ

OpenGL ESでは、GLSLで記述されたフラグメントシェーダが、各頂点の色に関する処理を行います。(今回は各頂点=各画素位のノリで書いていますが多分厳密には違う……)
今回はテストコードとして、画面の左半分であれば赤にノイズを掛け、青と緑を強める、という処理を実装してみました。
この内容はRenderer.java内に書いてあります。
今回は書いていませんが、行列演算も可能です。

#extension GL_OES_EGL_image_external : require
precision mediump float;
//texcoordVaryingには、テクスチャの0.0から1.0までの位置情報が格納されている
varying vec2 texcoordVarying;
uniform samplerExternalOES texture;

//https://stackoverflow.com/questions/4200224/random-noise-functions-for-glsl
//0.0から1.0の一様乱数を返す関数、
//入力はその都度変わる何か、例えば色情報を用いる
float rand(vec2 co){
  return fract(sin(dot(co.xy, vec2(12.9898, 78.233))) * 43758.5453);\n" +
}

//フラグメントシェーダのメイン関数
void main() {
  //色情報を取得, ここで取得されるのは0.0 〜 1.0の範囲の値を持つrgbaのベクトル
  vec4 v = texture2D(texture, texcoordVarying);
  //画面の左半分の場合処理する
  if(texcoordVarying.x < 0.5){
    //rに-0.5 〜 0.5の範囲の乱数を載せている
    //配列と同じようにアクセスできる
    v[0] += (rand(vec2(v[0] * v[1],v[0] * v[2])) - 0.5);
    //g, bを入力と1.0の平均で置き換える
    //このように、ベクトルはxyzw表記でアクセスしたり、ベクトルの一部を低次元のベクトルとして演算することが可能
    v.yz = vec2((v.y + 1.0)/2.0, (v.z + 1.0)/2.0);
  }
  gl_FragColor = v;
}
スクリーンショット

実行するとこんな感じになります。
f:id:wrongwrongwrongwrong163377:20170829185104p:plain

java上での取り扱い

上記のGLSLコードは、java内では、以下のようにStringで記述します。

    private static final String FRAGMENT_SHADER =
            "#extension GL_OES_EGL_image_external : require\n" +
                    "precision mediump float;\n" +
                    //texcoordVaryingには、テクスチャの0.0から1.0までの位置情報が格納されている
                    "varying vec2 texcoordVarying;\n" +
                    "uniform samplerExternalOES texture;\n" +

                    //https://stackoverflow.com/questions/4200224/random-noise-functions-for-glsl
                    //0.0から1.0の一様乱数を返す関数、
                    //入力はその都度変わる何か、例えば色情報を用いる
                    "float rand(vec2 co){\n" +
                    "    return fract(sin(dot(co.xy, vec2(12.9898, 78.233))) * 43758.5453);\n" +
                    "}\n"+

                    //フラグメントシェーダのメイン関数
                    "void main() {\n" +
                    //色情報を取得, ここで取得されるのは0.0 〜 1.0の範囲の値を持つrgbaのベクトル
                    "  vec4 v = texture2D(texture, texcoordVarying);\n" +
                    //画面の左半分の場合処理する
                    "  if(texcoordVarying.x < 0.5){\n" +
                    //rに-0.5 〜 0.5の範囲の乱数を載せている
                    //配列と同じようにアクセスできる
                    "    v[0] += (rand(vec2(v[0] * v[1],v[0] * v[2])) - 0.5);\n" +
                    //g, bを入力と1.0の平均で置き換える
                    //このように、ベクトルはxyzw表記でアクセスしたり、ベクトルの一部を低次元のベクトルとして演算することが可能
                    "    v.yz = vec2((v.y + 1.0)/2.0, (v.z + 1.0)/2.0);\n"+
                    "  }\n"+
                    "  gl_FragColor = v;\n" +
                    "}\n";

余談

カメラ入力に対して各画素への処理を行いたい場合、例えばOpenCVを使うようなことが考えられますが、実際に比較してみると、OpenGL ESのを用いたほうがはるかに高速でした。
これは、画像処理をGPUで行うため計算が高速であることと、カメラから取り込んだデータを処理するまで、処理した後でデータ転送や変換が少ないことが原因でしょう。
勉強し始めたばかりなので分からないことだらけで、特にAndroid上での取り扱いに関しては資料が少なく、苦戦中です。。。

リンクスサポートセンターへの、Corsair製各種DDR4メモリーのヒートシンク高に関する問い合わせ

リンクス様のサポートセンターへ、Corsair製各種DDR4メモリーヒートシンク高に関して問い合わせを行いました。

問い合わせ内容の公開に関しては許可を頂いたため、記事として残します。

リンクス様、回答、並びに内容の公開をご承諾頂き、誠にありがとうございます。

頂いた情報に関しては、別記事に追記を行っています。

wrongwrong163377.hatenablog.com

wrongwrong163377.hatenablog.com

回答内容

以下、回答の内容です。

実測値にて最も高い部分でおおよそ

Dominator Platinum 55mm
Vengeance LED 49mm
Vengeance RGB 49mm
Vengeance LPX 34mm

となってります。ソースとしては
「代理店による実測値」
程度の記載でお願い致します。

Vengeance LPXは上部に突起がいくつもあり、また平らでなく外側にいくほど少し低くなっています。
もっとも高い部分を計測すると34mmですが、計測する箇所によって数字はばらつくと思われます。

各社で公開している数字につきましても、ヒートシンクがでこぼこしている場合、
もっとも高い部分を計っていない可能性もあり、また、ヒートシンク取り付け時の
わずかなズレ等もありますので、数字はあくまで目安であると考えます。

よろしくお願い致します。