はてなブックマーク

(英語版も書きました: https://dev.to/funatsufumiya/bevy-engine-as-a-small-unity-big-processing-3edg) 1 はじめに: クリエイティブ・コーディングとProcessing ゲームエンジンってたくさんありますが、あなたは何を使ってますか？ 私はいわゆるクリエイティブ・コーディングが好きで、思いついたことを形にするために、例えばUnityやUE5、Touch DesignerやNotch、Reactなど、その都度プロトタイピングにちょうど良さそうなツールを選んでは、思いついたものを作っていたりします。 そんなときふと、クリエイティブ・コーディングの自分にとっての源流ってなんだろうと思うと、やはりProcessingだろうなと思います。 Processingの何が良かったかと振り返ると、やはり気軽さでしょう。今でもp5

概要 Bevy Engineを初めて使う人にとって、Rust言語特有の壁があります。今回は特にハマりがちな点を3つ挙げてご紹介します。 前置き Bevy Engineは、ゲームエンジンと紹介されることが多いですが、個人的にはopenFrameworksなどと同様に、汎用的な開発フレームワークと捉えています。 Bevy Engineはとてもよく設計されていて、幅広い用途に活用できるのですが、良くも悪くも現状はRust言語専用に作られていて、Rust言語以外でも使えるようにしようとする動きはなくはないものの、現状ではRustで書かざるをえません。 Rustは、C++やJavaと比べても難易度は高く、Bevyは難易度を緩和する仕組みを設けてくれてはいますが、BevyとRustにはいくつかのハマりポイントがあります。 当記事では、特にRust言語特有の事情に焦点をあて、Bevyに初めて触れる際に、

Karabiner ElementsでComplex Modificationを書く際に、いつもJISキーボードの記号とキーコードの対応関係がわからなくなって、Karabiner EventViewerで都度調べてしまうので、チートシートとして表にまとめてみた。 特にシフト同時押しの記号は慣れないと相当にややこしく、なかなかシフト同時押しの場合の記載がある記事が見つからなかったので作ってみた。 （なお、表の書き方は、同様の内容をまとめてあるこちらのサイトを参考にした。 https://did2memo.net/2019/03/31/karabiner-elements-symbol-table/ ） 対応表 シフトなし 【凡例】 「記号 (JIS)」：JISキーボードで入出力したい記号 「USでの見た目」： USキーボードで同じ場所にあるキーの見た目 「key_code」：設定すべきキーコ

M1 MacではRosetta 2を使って x86, x86_64 (以下x64) のIntelアプリやライブラリを実行できるのは有名だが、ターミナルを切り替えて使うことで、ARM非対応のツールやライブラリを使ってIntel版の開発を進めることができ、かつARM版と共存させることができる。 ARMとIntelのターミナルを切り替えて使う記事は既にあるものの、2021/2/5にARMに正式対応したHomebrew 3.0.0以前の記事しか見当たらず、Homebrew 3.0.0以降の正式対応後の手順と設定を改めてまとめてみることにした。 iTermをインストール デフォルトのターミナルでも良いのだけれど、後述の見た目を分けることができなかったり、名称変更後のターミナルがSpotlightで呼び出しにくいなどで不便が多いので、iTermをインストールしている前提で以下説明する。 Intel版

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? マインドフルネスがブームになって久しい昨今、情報源や論文数は爆発的に増えていて、関連イベントも多数あるので、これ以上情報がなくても良い気もしてしまうけど、現役のエンジニアという立場から見たマインドフルネスと、今までマインドフルネスに対して持っていた大きな勘違いを共有したくて、記事を書いてみることにした。 前提・筆者について 自分はヨガの達人でもなければ、お坊さんでもなくて、特に熱心な仏教徒というわけでもない、執筆時点ではフリーランスのエンジニア。最近は機械学習をしたり、FlutterやReactでアプリ開発をしたりしている。 マインドフ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 先日、実験的にFlutter Webを使い数ヶ月かけて開発を進め、最終的に、結局パフォーマンスの問題からReactにすべて書き換えたことがあった。 同じ失敗をする人ができるだけ少ないように、現状のFlutter Webの課題点について、主に以下のIssueから引用して共有しておこうと思う。 前提として、Flutterはとても積極的に更新が行われているので、上記Issueで挙げられている問題点は徐々に解決すると思う。現状ではまだ関連IssueはOpenのままで、少なくともここ数ヶ月は変わりなく、執筆時点で最新版のFlutter 2.5.3

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

(英語版も書きました: Comparison of C++ Low-Level Graphics, Cross-Platform Frameworks and Libraries) 最近OpenGLばっかり書いていて、ふと、MetalやDirectXでも動くクロスプラットフォームなアプリも書きたいなと思ったので調べてみた。 今回調べてみたライブラリの特徴は、 C++で実装されている ( C++14/17 など詳細は別記 ) 低レベルグラフィックスAPIに対応 ( Vulkan、DirectX11/12、Metal など ) クロスプラットフォームで動く ( Win/Mac/Linux、iOS/Android など ) UnityやUE4に比べて、軽量もしくは拡張性・組み込み性が高く、フレームワークやライブラリとして自由に使えるもの。 なお、今回は低レベルグラフィックスAPIへの対応を重視し