Unity学習用 画面を作成する
目標：W18×H16のダンジョンをTilemapで作成する
①画面イメージを決める
単位
- px(ピクセル)
コンピューターのディスプレーなどの画面を構成する最小単位の点。単位面積当たりのピクセル数が多いほど、精密な表示ができる。 画素。<1>
- ユニット
nity ではピクセルではなく、「ユニット」と呼ばれる単位で距離やサイズを表現しています。一般的に、1 Unity ユニットを 1 メートルと考えることがグッドプラクティスです。このシナリオにおいて、たとえば平均的なヒューマノイドモデルは 1.7 から 1.8 ユニットの大きさになります。これは絶対的な考え方ではありませんが、物理演算を使ったゲームを正常に動かすときには役立つ考え方です。（中略）
2D ではスケールの問題の重要性は下がりますが、プロジェクトで物理演算を使う場合は、やはりスケールのことを考慮するほうがいいでしょう。Tilemap を使っている場合は、シンプルに取り回せるように、1 タイル = 1 ユニットになるようスケールを設定するのがいいでしょう。<2> - Tile
Tileクラスは、タイルマップ上にスプライトを描画するための単純なクラスです。 Tile はTileBaseから継承されます。<3>
上記を参考に１タイル＝１ユニットと設定する。
画像サイズは、床は16px×16px = 1ユニット、人物は32px×32px=1ユニット
今回の設定は18タイル×16タイルにしたいので、画面に18Unit×16Unitを収めたい。
②Asset画像の設定
Asset画像はPixels Per Unit（１ユニットあたりのピクセルサイズ）を床は16、
人物は32に設定する。
今回はFilter ModeはPoint（no Filter）にしておく。
【参考】Filter Mode
Point：ピクセルを 1 つ 1 つブロックのように表示する
Biliniear：平均化され、滑らかに表示する
Trilinear：Bilinear とほぼ同じだが、ミップマップレベルにおいてブレンドして表示する
③メインカメラを設定
Camera
Size 画面の縦半分にUnitがいくつ入る設定にするか
今回はUnitを縦に18にしたいから9を設定
引用
- https://www.weblio.jp/content/%E3%83%94%E3%82%AF%E3%82%BB%E3%83%AB
- https://blog.unity.com/ja/technology/choosing-the-resolution-of-your-2d-art-assets
- https://docs.unity3d.com/ja/2019.4/Manual/Tilemap-ScriptableTiles-Tile.html
参考
https://shikaku-sh.hatenablog.com/entry/unity-2d-camera-orthographicsize-better-way
初心者プログラミング日記 SwiftUI⑧
WWDC20 App essential in SwiftUI をみることにしました。
（全然プログラム書いてない。。15分だし）
Views - それぞれのViewがUIの一部を定義する
目に見える全てがView。文字も、枠も、リストも。
スクリーンに見える全てのピクセルがViewになんらかの形で定義されている。
ただし、スクリーンに映るViewは全てが同じアプリのものではない。
（当たり前に聞こえるが大事なんだな）
アプリAのViewもあればアプリBのViewもあるってわけだ。
１つのアプリがスクリーンの全てを完全にコントロールしているわけではないから。
その代わりプラットフォームがアプリの表示をコントロールしている。
異なるSceneで表示させている。プラットフォームって何かと思ったら各端末のOSのことね。
Sceneを表示させる方法はWindow
（iPadのプラットフォームなどは複数のWindowを並べて表示できる）
Sceneはアプリもアプリコンテンツの１要素。
Appは各モデルにデータを提供するが、それぞれのアプリが独立したデータ保持をすることができる。Appに＠StateObjectを持ってきた意味がやっとわかった。
参考BuilddocumentScensApps
初心者プログラミング日記 SwiftUI ⑦ ストレージのお話
WWDC20 Data Essential in SwiftUIにUIストレージのお話が出てきました。
例によって初心者の意訳なので、信用できない情報です。
Process Lifetimeということで、State,StateObject,Constantはデータを保持するけど、
Appが落ちた時には無くなっちゃうよ。だから、Extendede Lifetimeということで、
延命するためストレージ、SceneStorageとAppStorageを用意したよ。
あくまでUIのだけどね。
@SceneStorage-アプリの現在の状態に関する軽微な情報を保存するのに最適
スコープはScene
SwiftUIが管理
Viewからのみアクセス可能
@AppStarage-設定変更の保存などに最適
スコープはApp
ユーザーのデフォルトを使って保持される
App内からでもViewからでもどこからでもアクセス可能
Custom Lifetime
ObservableObject-プログラムを書くことで、サーバーや他のサービスで保存が可能
初心者プログラミング日記 SwiftUI ⑥ ObseravableObject
WWDC20 Data Essential in SwiftUIを見ています。
2つ目のルカさんのパートはObseravableObjectについてでした。
下記初心者の私の意訳なので、違う可能性ありありです。
＠Stateと＠Bindingでも良いけど、本来データやプログラムはUIとは分けるよね？
そうなると＠State と＠Bindingは使えないから、その場合の方法を伝えるね。
その場合はクラスでObseravableObjectを使うんだ。
で、使いたいプロパティに@Publishedをつけると、そのタイプにした、
＠ObservedObject
＠StateObject
＠EnvironmentObject
をつけたプロパティをSwiftUIが監視して、どれかに変化があったら、全部変更してくれるよ。
＠ObseravedObjectは更新したいインスタンスにつければ良い。
でも、例えば更新したけど、そのUIが削除されてしまう可能性があるインスタンスもあるよね。
そういう時は、＠StateObjectを使うんだ。削除された後のタイミングでUIを更新するからね。
あとは、複雑な構造になって、＠ObseravedObjectから階層的に遠いViewのインスタンスを更新したい時。その時は、＠EnvironmentObjectを使えば、直接的に使えるよ。
初心者プログラミング日記 SwiftUI④ SwiftUIのライフサイクル
WWDC20 Data Essentials in SwiftUIに移る
こんばんはNattsuXです。仕事で落ちているので、こんな時はLet'sプログラミング！
これまでコード模写である程度理解してきましたが、もう少し仕組みの部分を理解したいと
思って再チャレンジしています。
下記仮説なので、明日試そうと思います（Xcodeがアップデートして使えない。。。）
前提：下記のような画面表示でボタンを押すと"犬"が"猫"になるアプリがあったとする
犬
ボタン
通常
ビルド（body実行）→View→レンダリング→画面表示（Viewは捨てる）
→画面のボタンをタップ→ボタンは押せるけど猫にならない。（Viewは捨てられている）
@State付き
ビルド（body実行）→View→レンダリング→画面表示（Viewは捨てる、
Stateのついたプロパティにはストレージが割り当てられる）
→画面のボタンをタップ（イベント）
→StateのついたプロパティのSource of Truthが変化(犬から猫になる)
→Viewを再構築→Viewからストレージに接続→レンダリング
→犬から猫に変わって画面表示（Viewは捨てる）
初心者プログラミング日記 SwiftUI③
WWDC20 Introduction to SwiftUI続き（42分42秒あたりから）
//
// SandwichStore.swift
// Landmarks
//
//
import Foundation
//サンドイッチを含む変更可能なオブジェクト
//テスト用に単集合インスタンスも用意
//私たちがオブジェクトを変更する時にはSwiftUIへの指示が必要なので、
//変更するオブジェクトにはObseravableObjectを継承させる
class SandwichStore: {
var sandwiches: [Sandwich]
init(sandwiches: [Sandwich] = []){
self.sandwiches = sandwiches
}
}
let testStore = SandwichStore(sandwiches: testData)
