読者です 読者をやめる 読者になる 読者になる

ヘチマのノート

主にプログラムについて、興味の湧いたことを書きます。

【VSCode】UbuntuでVSCodeが真っ白になってしまう問題について

環境

発生した問題

仮想マシンUbuntu環境にインストールしたVisualStudioCode(以下VSCode)を起動するとVSCodeのウィンドウが真っ白になってしまう。
f:id:hetima333:20170424025522p:plain

テキストファイルなどを読み込むと、タイトルバーの文字が切り替わるので読み込みはできている模様。
どうやら描画がうまくいっていないようでした。

原因

VSCodeがデフォルトでGPUを使って描画を行うようになっており、3Dハードウェアアクセラレーションを有効にした状態でVSCodeをGPUを使って描画することにより発生していたようです。

解決方法

3Dハードウェアアクセラレーションを無効にする

この方法はあまりオススメではありません。
3Dハードウェアアクセラレーションを無効にすると動作が遅くなったりすることがあります。

VirtualBoxから、該当の仮想マシンのディスプレイをクリックし(画像参照)、3Dアクセラレーションを有効化のチェックを外します。
f:id:hetima333:20170424012538p:plain:w300 f:id:hetima333:20170424021755p:plain:w300

VSCodeでGPUを使わないようにする

VSCodeの描画にGPUを使わないように設定することで正常に描画することができました。

$ code

通常上のコマンドで起動するところを

$ code --disable-gpu

とすることでGPUを使わないように設定して起動することができます。
ひとまずはこれで解決です。

通常コマンドで起動した際にもGPUを使用しないようにする

毎回起動する際に --disble-gpu と入力するのは面倒なのでデフォルトで --disable-gpu が入力されている状態に設定します。
設定ファイルを変更するので慎重に!

# nano /usr/share/code/bin/code

上記コマンドでnanoでVSCodeの設定ファイルを開きます。
nanoの部分はgeditなどの他のテキストエディタでもOKです。

設定ファイルを開いたら、

ELECTRON_RUN_AS_NODE=1 "SELECTRON" "$CLI" "$@"

と書かれている部分を探し、

ELECTRON_RUN_AS_NODE=1 "SELECTRON" "$CLI" "--disable-gpu" "$@"

と書き換えます。
これで code コマンドだけで実行した際にGPUを使用しないように設定できました。

Lancherから起動した際にもGPUを使用しないようにする

Lancherから起動するとVSCodeはGPUを使用してしまいますので、こちらも設定が必要になります。
設定ファイルを変更するので慎重に!

$ cd /usr/share/applications
$ nano code.desktop

上記コマンドでnanoで設定ファイルを開きます。
nanoの部分は先程と同様にgeditなどの他のテキストエディタでもOKです。

設定ファイルを開いたら、[Desktop Entry]の少し下にある

Exec=/usr/share/code/code -- unity-launch %U

と書かれている部分を探し、

Exec=/usr/share/code/code -- unity-launch --disable-gpu %U

と書き換えます。
これでLancherから起動した際にもGPUを使用しないように設定できました。

【Unity】warframeっぽいカメラを作ってみる-2

前回の記事

前回の記事はこちらになります。
hetima333.hatenablog.com

この記事で作成する挙動

この記事ではエイム動作を作成します。
エイム動作の参考資料です。
f:id:hetima333:20170216230225g:plain

エイム動作の仕様

エイム動作の仕様をまとめておきます。

  • エイムボタンが押された時に、ズームを開始する。
  • エイムボタンが離された時に、ズームしていない状態にする。
  • エイム動作はカメラの正面に向かって行う
    ※プレイヤーが手前(カメラの方向)を向いていても画面の奥に向かってエイム動作を行う

使用したアセット

  • UniRx
    ReactiveExtentions(Rx)をUnity向けに移植したライブラリです。
    処理ごとにスコープがはっきりしてわかりやすくなるので使用しました。
  • DOTween
    比較的簡単にトゥイーンが作成できるトゥイーンエンジンです。
    エイム動作を滑らかにするために使用しました。

ソースコード

PC以外にも対応できるように、InputManagerに画像のようなものを追加しました。
f:id:hetima333:20170223235222p:plain

using UniRx;
using UniRx.Triggers;
using UnityEngine;
using DG.Tweening;

public class AimCamera : MonoBehaviour
{
	[SerializeField, Tooltip("ズームする距離")]
	private float distance;

	[SerializeField, Tooltip("エイムにかかる時間"), Range(0.0f, 1.0f)]
	private float duration;

	// カメラの基点
	private Transform pivot;

	// 非エイム時のカメラの基点座標
	private Vector3 idlePivotPosition;

	/// <summary> 
	/// 更新前処理
	/// </summary>
	void Start ()
	{
		// pivotの参照
		pivot = GetComponentInChildren<Camera>().transform.parent;

		// 非エイム時のカメラの基点座標
		idlePivotPosition = pivot.localPosition;

		// エイム開始時
		this.UpdateAsObservable()
			.Where(_ => Input.GetButtonDown("Aim"))
			.Subscribe(_ =>
			{
				// 現在の位置から正面にエイム距離分だけ離れた位置に向かってトゥイーンする
				pivot.DOLocalMove(idlePivotPosition + (Vector3.forward * distance), duration)
					.SetEase(Ease.InOutCubic);
			});

		// エイム終了時
		this.UpdateAsObservable()
			.Where(_ => Input.GetButtonUp("Aim"))
			.Subscribe(_ =>
			{
				// 非エイム時のカメラの基点座標に向かってトゥイーンする
				pivot.DOLocalMove(idlePivotPosition, duration)
					.SetEase(Ease.InOutCubic);
			});

	}
}

このスクリプトは前回インスタンス化したFreeLookCameraRigにアタッチすると使用できます。
f:id:hetima333:20170224001737p:plain

実際の動作

実際の動作のサンプルgifです。比較用に床とブロックを配置しています。
f:id:hetima333:20170224002340g:plain

ImageEffectをつけると、よりそれっぽくなるかと思われます。

追記

17/02/24 エイムボタンを連打するとカメラが奥のほうに行ってしまっていたのでソースコードを修正

【Unity】warframeっぽいカメラを作ってみる-1

warframeのカメラ

warframeのカメラの主な挙動です

  • 回転
    この記事ではこれを作ります。
    あとの動作についてはまた後日記事にしたいと思います。

f:id:hetima333:20170216230045g:plain

  • 移動

f:id:hetima333:20170216230133g:plain

  • ズーム(Aim)

f:id:hetima333:20170216230225g:plain

使用したアセット

  • Standard Assets

Standard Assets>Camerasの中にあるFreeLookCameraRigを使用しました。

  • SDユニティちゃん 3Dモデルデータ

SD_unitychan_humanoidを使用しました。
Unityちゃん公式サイトよりDLできます。

実際に作ってみる

作成の一例なので、参考まで…

  1. SD_unitychan_humanoidプレハブを配置し、座標を0,0,0にしておく。
  2. FreeLookCameraRigプレハブを配置し、座標を0,0,0にしておく。
  3. 配置したFreeLookCameraRigのFreeLookCamコンポーネントTarget1.で配置したSD_unitychan_humanoidを指定します。
    f:id:hetima333:20170217001006p:plain
  4. FreeLookCameraRig>Pivotの座標を1,1,2に設定しておく。
    ここで、プレイヤーからのずれを設定します(カメラ回転の基点になる)
  5. 最後に、シーンに元々配置されていたMain Cameraを削除する。

とりあえずこれで、回転部分は完成です。
ヒエラルキーはこのようになっていると思います。
f:id:hetima333:20170217000604p:plain

実際の動作はこんな感じです。
GUIはSD_unitychan_humanoidにアタッチされているコンポーネントのIs GUIのチェックを外せば消えます。
f:id:hetima333:20170217002619g:plain

リンク

warframeの公式サイト
https://warframe.com/
忍者なら無料

【Unity】オブジェクトがカメラに写っているかと注意点

OnBecameVisible()とOnBecameInvisible()を利用する

OnBecameVisibleはオブジェクトが可視状態になった時に呼ばれるメソッドです。
OnBecameInvisibleはオブジェクトが不可視状態になった時に呼ばれるメソッドです。
OnBecameVisibleはSceneViewにオブジェクトが写っている場合も呼ばれます。

using UnityEngine;

public class Visible : MonoBehaviour
{
	private bool isVisible;

	// 可視状態か
	public bool IsVisible
	{
		get { return isVisible; }
	}

	// 可視状態になった時に呼ばれる
	void OnBecameVisible ()
	{
		isVisible = true;
	}

	// 不可視状態になった時に呼ばれる
	void OnBecameInvisible ()
	{
		isVisible = false;
	}

}

可視状態についての注意点

Rendererがアタッチされていないオブジェクトには可視、不可視というものがそもそもありません(描画されないので)。
つまり、Rendererがアタッチされていないオブジェクトについては、OnBecameVisibleとOnBecameInvisibleは呼ばれません。

f:id:hetima333:20170213154823p:plain
例えば、SDユニティちゃんは画像のようにRendererがついているので注意が必要です。
(Rendererなしのオブジェクトに上のスクリプトをアタッチしても機能しません。)

対策として、インスペクタ側で可視不可視の判断に利用するRendererを指定するスクリプトを書いてみました。

using UniRx;
using UniRx.Triggers;
using UnityEngine;

public class Visible : MonoBehaviour
{
	// 可視不可視の判断に使用するRenderer
	[SerializeField]
	private Renderer targetRenderer;

	private bool isVisible;

	// 可視状態か
	public bool IsVisible
	{
		get { return isVisible; }
	}

	void Start ()
	{
		// 可視状態になった時に呼ばれる
		targetRenderer.OnBecameVisibleAsObservable()
			.Subscribe(_ => isVisible = true);

		// 不可視状態になった時に呼ばれる
		targetRenderer.OnBecameInvisibleAsObservable()
			.Subscribe(_ => isVisible = false);
	}
}

【GGJ2017】グローバルゲームジャム2017で学んだこととか

ちょっと遅くないか…?という気がしなくもないですが備忘録のような感じで…

目次 

はじめに

 

作ったゲームはこちらです↓

開発にはCocos2d-xを使用しました

チームはプログラマー2人、デザイナー1人の計3人で、私はプログラマとして参加しました

 

これをふまえた上で記事を見ていただけると幸いです

 

gitignoreは小規模でも入れたほうがいい

 

48時間のGGJは比較的小規模プロジェクトで、gitignoreを入れなくてもいいんじゃないか?ということでgitignoreなしでやってみた

→無駄なファイルの送受信で時間を取られ、gitignoreを入れたほうが時間短縮になった(当たり前といえば当たり前)

 

Linkerのエラーはビルド対象が正しいか確認する

 

プログラムをマージしてビルドする際に、何故かビルドが通らない

Windowsではビルドが通るのにMacでは通らない

→原因はXCode側でビルド対象に含めていないことでした

 

SourceTreeのブランチ分け

 

今まで何も考えず、思考停止でmasterブランチだけ使用していたのですが、機能ごとにブランチを分けて、masterブランチは常に安定版としておいたほうがいいと知りました

ちなみにブランチの作成方法(SourceTreeの場合)は、

  1. 切りたいコミットで右クリック
  2. ブランチ名を入力
  3. ブランチ作成ボタンをクリック

の簡単3ステップ!

 

考えたことを書いておく

 

48時間という限られた時間の中で効率的に作業を行うには、頭の中をできるだけスッキリさせておいたほうがいい(よさそう)なので、タスクや浮かんだアイデアはTrelloやEverNoteに放り込んでおくといい