Author: demensdeum

Donki Hills は 1 年以上にわたって Steam に登場しています。

ちょうど 1 年前にこのプロジェクトが Steam ページに登場し、それ以来、ゲームは大きな進歩を遂げてきました。この間、ドンキヒルズがどのような方向に発展すべきかについて、多くの実験、変更、模索が行われました。

ゲームプレイの作業は継続しており、現在、プロジェクトは徐々にその本当の姿を獲得しつつあります。ドンキ ヒルズは、コメディの一人称ローグライク パロディ サバイバル ホラーという本来の姿に変わり始めています。

ホラーとユーモア、探検、そして予期せぬ状況が出会う奇妙な冒険。あなたは街に行き、物を探し、謎を解き、マリアにつながる秘密を徐々に明らかにしなければなりません。

以下は、プロトタイプの次のプレイテストからの新しいスクリーンショットです。これはまだゲームの最終的な外観ではありませんが、街の雰囲気とプロジェクトが進んでいる方向性をすでに感じることができます。

あなたの反応をとても楽しみにしています! 👀
新しい方向性はどうですか？ゲームの雰囲気やアイデアについてはどのような印象をお持ちですか？

ドンキヒルズをウィッシュリストに追加し、開発をフォローし、プロジェクトをサポートしてくださった皆様に感謝します❤️

まだまだたくさんの実験、新しい仕組み、そして奇妙な冒険が待っています。

https://store.steampowered.com/app/3476390/Donki_Hills/

最新のゲーム用ラップトップのメーカーは、プロセッサが負荷時に最大 90 度、さらには 100 度に達するようにシステムを構成していることがよくあります。この問題は、要求の厳しいゲームや重い作業を実行する夏に特に深刻です。

極度の加熱により、スロットルが有効になり (物理的な損傷を防ぐためにプロセッサ周波数をリセットします)、パフォーマンスの急激な低下、フリーズ、FPS の低下につながります。過熱に対処する方法 (冷却パッドの使用から電圧低下まで) は数多くありますが、この記事では、Windows 11 以前のバージョンのオペレーティング システムに関連する最も簡単で最速の方法について説明します。

この方法は、電源設定を通じてプロセッサの最大状態を制限することです。

1. Windows 検索またはコントロール パネルから電源オプションを開きます。
2. アクティブな電源プランで、追加パラメータを変更するセクションに移動します。
3. プロセッサ電源管理 ブランチを見つけます。
4. [最大プロセッサ状態] オプションを展開します。
5.プラグインの値を 100% から 80% 以下に変更します。

これらの設定を適用すると、プロセッサーは過剰な熱を発生させる極端な周波数まで自動的にオーバークロックしなくなります。最大ピークパフォーマンスは約 20% 低下しますが、プロセッサーが過熱することはなくなります。スロットリングを行わずに周波数を下げて安定した動作を行うことは、100 度未満の温度での過熱によるパフォーマンスの急激な急上昇よりもはるかに優れており、システムにとって快適です。

ラップトップはそれぞれ固有であるため、ユーザーは実験して、過熱することなく望ましいパフォーマンスを提供できる最適なバランス (パーセンテージ) を見つけることをお勧めします。

この投稿では、Surreal Engine ゲーム エンジンを WebAssembly に移植する方法について説明します。
https://demensdeum.com/demos/SurrealEngine/”
超現実的なエンジン – Unreal Engine 1 の機能のほとんどを実装するゲーム エンジン、このエンジン上の有名なゲーム -アンリアル トーナメント 99、アンリアル、デウス エクス、アンダイング。これは、主にシングルスレッド実行環境で動作する古典的なエンジンを指します。
私はもともと、妥当な期間内に完了できないプロジェクトに挑戦して、Twitch のフォロワーに私にもできないプロジェクトがあることを示すという考えを持っていました。最初のストリーム中に、Emscripten を使用して Surreal Engine C++ を WebAssembly に移植するタスクが実行可能であることに突然気づきました。

1 か月後、WebAssembly でフォークとエンジンのアセンブリをデモンストレーションできるようになります。
https://demensdeum.com/demos/SurrealEngine/
オリジナルと同様に、コントロールはキーボードの矢印を使用して実行されます。次に、これをモバイル コントロール (タチ) に適応させ、Unreal Championship 99 レンダリングの正しいライティングやその他のグラフィック機能を追加する予定です。

どこから始めればよいですか?

まず最初に言いたいのは、Emscripten を使用すればどんなプロジェクトでも C++ から WebAssembly に移植できるということですが、唯一の問題は機能がどの程度完成するかということです。ライブラリ ポートがすでに Emscripten で使用できるプロジェクトを選択します。 Surreal Engine の場合は、エンジンが SDL 2、OpenAL – を使用しているため、非常に幸運です。図書館。どちらも Emscripten に移植されています。ただし、Vulkan はグラフィックス API として使用されており、現在 HTML5 では利用できません。WebGPU の実装作業は進行中ですが、これもドラフト段階であり、完全に標準化された後、Vulkan から WebGPU へのさらなる移植がどれほど簡単になるかも不明です。したがって、Surreal Engine 用に独自の基本的な OpenGL-ES / WebGL レンダラーを作成する必要がありました。

プロジェクトのビルド

Surreal Engine でシステムを構築 – CMake は、Emscripten がネイティブ ビルダーを提供するため、移植も簡素化します。えむけ、えむけ。
Surreal Engine の移植は、Death-Mask と呼ばれる WebGL/OpenGL ES および C++ で作成した最新ゲームのコードに基づいていました。そのため、開発ははるかに簡単で、必要なビルド フラグとコード サンプルがすべて揃っていました。
CMakeLists.txt の最も重要なポイントの 1 つは Emscripten のビルド フラグです。以下はプロジェクト ファイルの例です。

set(CMAKE_CXX_FLAGS "-s MIN_WEBGL_VERSION=2 
-s MAX_WEBGL_VERSION=2 
-s EXCEPTION_DEBUG 
-fexceptions 
--preload-file UnrealTournament/ 
--preload-file SurrealEngine.pk3 
--bind 
--use-preload-plugins 
-Wall 
-Wextra 
-Werror=return-type 
-s USE_SDL=2 
-s ASSERTIONS=1 
-w 
-g4 
-s DISABLE_EXCEPTION_CATCHING=0 
-O3 
--no-heap-copy 
-s ALLOW_MEMORY_GROWTH=1 
-s EXIT_RUNTIME=1")

ビルド スクリプト自体:

clear
emmake make -j 16
cp SurrealEngine.data /srv/http/SurrealEngine/SurrealEngine.data
cp SurrealEngine.js /srv/http/SurrealEngine/SurrealEngine.js
cp SurrealEngine.wasm /srv/http/SurrealEngine/SurrealEngine.wasm
cp ../buildScripts/Emscripten/index.html /srv/http/SurrealEngine/index.html

次に、プロジェクト ファイル システム プリローダーを含む index.html を準備しましょう。 Web にアップロードするために、Unreal Championship Demo バージョン 338 を使用しました。CMake ファイルからわかるように、解凍されたゲーム フォルダーがビルド ディレクトリに追加され、Emscripten のプリロード ファイルとしてリンクされています。

メインコードの変更

次に、ゲームのゲーム ループを変更する必要がありました。無限ループを実行することはできません。これによりブラウザがフリーズします。代わりに、emscripten_set_main_loop を使用する必要があります。この機能については、2017 年のメモ「SDL C++ ゲームの HTML5 (Emscripten) への移植」
while ループを終了するコードを if に変更し、ゲーム ループを含むゲーム エンジンのメイン クラスをグローバル スコープに表示し、グローバル オブジェクトからゲーム ループ ステップを呼び出すグローバル関数を作成します。

#if __EMSCRIPTEN__
#include <emscripten.h>
Engine *EMSCRIPTEN_GLOBAL_GAME_ENGINE = nullptr;
void emscripten_game_loop_step() {
	EMSCRIPTEN_GLOBAL_GAME_ENGINE->Run();
}
#endif

この後、アプリケーションにバックグラウンド スレッドがないことを確認する必要があります。存在する場合は、シングルスレッド実行用に書き直す準備をするか、Emscripten の phtread ライブラリを使用します。
Surreal Engine のバックグラウンド スレッドは音楽の再生に使用され、データは現在のトラック、音楽の再生の必要性、または音楽の不在に関するメイン エンジン スレッドから取得され、バックグラウンド スレッドはミューテックス経由で新しい状態を受け取り、新しい音楽の再生を開始するか一時停止します。バックグラウンド スレッドは、再生中に音楽をバッファリングするためにも使用されます。
pthread を使用して Emscripten 用の Surreal Engine を構築する試みは失敗しました。SDL2 ポートと OpenAL ポートは pthread サポートなしで構築されており、音楽のために再構築したくなかったためです。そこで、BGM ストリームの機能をループを使用したシングルスレッド実行に移行しました。 C++ コードから pthread 呼び出しを削除することで、バッファリングと音楽再生をメイン スレッドに移動し、遅延がないよう、バッファを数秒増やしました。
次に、グラフィックとサウンドの具体的な実装について説明します。

Vulkan はサポートされていません!

はい、Vulkan は HTML5 ではサポートされていませんが、すべてのマーケティング パンフレットでは Vulkan の主な利点としてクロスプラットフォームおよび広範なプラットフォームのサポートが紹介されています。このため、簡素化された OpenGL タイプの基本的なグラフィックス レンダラーを独自に作成する必要がありました。 ES はモバイル デバイスで使用され、最新の OpenGL のファッショナブルな機能が含まれていない場合もありますが、WebGL に非常によく移植されており、まさに Emscripten が実装しているものです。基本的なタイル レンダリング、最も単純な GUI 表示用の bsp レンダリング、およびモデルとマップのレンダリングの作成は 2 週間で完了しました。おそらくこれがこのプロジェクトで最も困難な部分でした。 Surreal Engine レンダリングの全機能を実装するには、まだ多くの作業が必要です。そのため、読者からのコードやプル リクエストの形での支援を歓迎します。

OpenAL がサポートされています!

幸運なことに、Surreal Engine はオーディオ出力に OpenAL を使用していることです。 OpenAL で単純な Hello World を作成し、Emscripten を使用して WebAssembly で組み立てたので、すべてがいかに単純であるかが明らかになり、サウンドの移植に着手しました。
数時間のデバッグ後、Emscripten の OpenAL 実装にはいくつかのバグがあることが明らかになりました。たとえば、モノラル チャネル数の読み取りを初期化するときにメソッドが無限数を返し、無限サイズのベクトルを初期化しようとすると、C++ が例外 Vector::length_error でクラッシュします。
モノラル チャンネルの数を 2048 にハードコーディングすることで、この問題を回避することができました。

		alcGetIntegerv(alDevice, ALC_MONO_SOURCES, 1, &monoSources);
		alcGetIntegerv(alDevice, ALC_STEREO_SOURCES, 1, &stereoSources);

#if __EMSCRIPTEN__
		monoSources = 2048; // for some reason Emscripten's OpenAL gives infinite monoSources count, bug?
#endif

ネットワークはありますか?

Surreal Engine は現在オンライン プレイをサポートしていませんが、ボットでのプレイはサポートされていますが、これらのボット用の AI を作成する人が必要です。理論的には、Websocket を使用して WebAssembly/Emscripten 上にネットワーク ゲームを実装できます。

結論

結論として、Emscripten ポートが存在するライブラリの使用と、Emscripten 上の WebAssembly 用に C++ でゲームを実装した過去の経験のおかげで、Surreal Engine の移植は非常にスムーズに完了したと言えます。以下は、このトピックに関する知識源とリポジトリへのリンクです。
も、も、も、モンスターを倒せ！
また、できれば WebGL/OpenGL ES レンダリング コードでプロジェクトを支援したい場合は、Telegram で私に書いてください:
https://t.me/demenscave

リンク

https://demensdeum.com/demos/SurrealEngine/

https://github.com/demensdeum/SurrealEngine-Emscripten

https://github.com/dpjudas/SurrealEngine

2 つのデバイスが NAT または厳格なファイアウォールの内側にあり、お互いを直接「見る」ことができない場合、VPN が標準的なソリューションであるようです。しかし、本格的な L3 トンネル (WireGuard や OpenVPN など) は冗長であることが多く、root 権限が必要で、仮想インターフェイスの設定が必要で、既存のルートと競合する可能性があります。

このような場合、HTTP 上で実行され、データ転送に WebSocket を使用する TCP/UDP トンネルである Chisel を使用すると便利です。このノートでは、中間サーバーを介してあるクライアントから別のクライアントにポートを「転送」する方法を説明します。

それはどのように機能しますか?

状況を想像してください。クライアント A (ホーム サーバーなど)、クライアント B (職場のラップトップ)、およびパブリック IP アドレスを持つ VPS があるとします。クライアント A と B は VPS にアクセスできますが、相互にはアクセスできません。

転送スキームは次のようになります。
1.クライアント A は VPS に接続し、サーバー上で「リバース」ポートを開きます。これで、サーバーのポート X に送信されるすべてのものがクライアント A のポート Y に送信されます。
2.クライアント B は VPS に接続し、ローカル マシンからポート Z をサーバーのポート X に転送します。
3. その結果、クライアント B は localhost:Z にアクセスし、最終的に クライアント A:Y に到達します。

このアプローチは、VPS との通信に L3 層が実装されていない場合、またはクライアント間のルーティングを構成する機能がない場合のソリューションの 1 つです。私たちはアプリケーションとポートレベルのみで作業します。

ステップ 1: サーバーを起動する

VPS では、Chisel をサーバー モードで実行するだけです。 --reverse フラグは、クライアントがサーバー側でポートを開くことができるようにするために必要です。

chisel server --port 8080 --reverse

ステップ 2: クライアント A (ソース) に接続する

クライアント A がポート 3000 でローカル Web サーバーへのアクセスを開きたいとします。彼は VPS に接続し、「サーバー上のポート 2000 を予約して、それを私に 3000 に転送してください」と言います。

chisel client vps-ip:8080 R:2000:127.0.0.1:3000

これで、VPS のポート 2000 (ループバック インターフェイス上) がクライアント A につながります。

ステップ 3: クライアント B (コンシューマー) の接続

現在、クライアント B はこのリソースにアクセスしたいと考えています。同じ VPS に接続し、ローカル ポート 8080 をサーバーのポート 2000 に転送します。

chisel client vps-ip:8080 8080:127.0.0.1:2000

準備ができて！ここで、クライアント B で http://localhost:8080 を開くと、クライアント A でサービスが実行されていることがわかります。

安全性とニュアンス

Chisel は、--auth フラグによる認証をサポートしています。これは、パブリック サーバーを介して作業する場合に強く推奨されます。 TLS 証明書を使用してトラフィックを暗号化することもできます。

このアプローチの主な利点は、TUN/TAP デバイスや複雑なルーティング テーブルが必要ないことです。これは、WebSocket 接続を介してポートをバインドするという 1 つのことだけを実行する必要最低限​​のトンネルです。 Chisel がポート 443 経由で動作するように設定されている場合、これは企業プロキシ経由でも機能します。

出力

Chisel は、特定のネットワーク タスク用のユーティリティです。本格的な VPN を設定せずに、分離されたノード間でポートを転送する必要がある場合、リレー サーバーを介した順方向トンネルと逆方向トンネルの組み合わせが完全に実行可能なソリューションであることがわかります。

リンク

https://github.com/jpillora/chisel

コードの作業に何時間も費やし、仮説を検討し、条件を調整しても、バグは依然として再現されます。おなじみですね？この欲求不満の状態は「ゴーストハンティング」と呼ばれることがあります。プログラムは、あなたの修正を無視して、独自の生活を送っているようです。

この状況の最も一般的で最も迷惑な理由の 1 つは、アプリケーション内の完全に間違った場所でエラーを探していることです。

「偽症状」の罠

エラーを見つけると、エラーが「発生」した場所に注意が集まります。しかし、複雑なシステムでは、バグ (クラッシュまたは不正な値) が発生しても、それは長い一連のイベントの終わりにすぎません。結末を修正しようとすると、病気ではなく症状と闘うことになります。

ここでフローチャートの概念が登場します。

実際にどのように機能するか

もちろんフローチャートを毎回紙に直接描く（描画する） 必要はありませんが、アーキテクチャのガイドとして頭の中に入れておくか手元に置いておくことが重要です。フローチャートを使用すると、アプリケーションの操作を結果のツリーとして視覚化できます。

この構造を理解していないと、開発者はしばしば暗中模索になります。状況を想像してみてください。1 つの条件ブランチでロジックを編集している間に、アプリケーションは (特定のパラメータのセットにより) 考えもしなかったまったく別のブランチに移動します。

<ブロック引用>
結果: アルゴリズムの一部で「完璧な」コード修正に何時間も費やしましたが、当然のことながら、アルゴリズムの別の部分で実際に失敗した問題は何も修正されません。

バグを克服するためのアルゴリズム

閉ざされたドアを叩くのをやめるには、診断のアプローチを変える必要があります。

• 結果ツリーで状態を見つける:コードを記述する前に、アプリケーションがたどったパスを正確に判断する必要があります。どの時点で論理が間違った方向に進んだのでしょうか?問題の原因となった特定の状態 (状態) は何ですか?
• 再現は成功の 80% です: これは通常、テスターと自動テストによって行われます。バグが「浮遊」している場合、開発は条件を共同で検索するプロセスに関与します。
• できるだけ多くの情報を使用する: ローカリゼーションには、ログ、OS バージョン、デバイス パラメータ、接続タイプ (Wi-Fi/5G)、さらには特定の通信事業者さえも重要です。

エラーの瞬間を捉えた「写真」

理想的には、バグを修正するには、バグが再現された時点のアプリケーションの完全な状態を取得する必要があります。インタラクション ログも非常に重要です。インタラクション ログには、最終ポイントだけでなく、ユーザー パス全体 (障害が発生する前にどのようなアクションが行われたか) も示されます。これは、同様の状態を再度作成する方法を理解するのに役立ちます。

今後のヒント: 複雑なケースが発生した場合は、その状況が再び発生した場合に備えて、コードのこのセクションに拡張デバッグ ログ情報を追加してください。

AI 時代の「とらえどころのない」状態の問題

LLM (大規模言語モデル) を使用する最新のシステムでは、古典的な決定論 (「1 つの入力、1 つの出力」) が違反されることがよくあります。まったく同じ入力データを渡しても、異なる結果が得られます。

これは現代の運用システムの非決定性が原因で発生します。

• GPU 並列処理: GPU 浮動小数点演算は常に結合的であるとは限りません。スレッドの並列実行により、数値の加算順序が若干変更される可能性があり、結果に影響を与える可能性があります。
• GPU の温度とスロットル: 実行速度と負荷分散は、ハードウェアの物理的状態に依存する場合があります。大規模なモデルでは、こうした微細な違いが蓄積され、出力時に異なるトークンが選択される可能性があります。
• 動的バッチ処理: クラウドでは、リクエストが他のリクエストと結合されます。バッチサイズが異なると、カーネルでの計算の計算が変わります。

そのような状況では、「同じ状態」を再現することはほぼ不可能になります。ここであなたを救うことができるのは、テストへの統計的アプローチのみです。

ロジックが失敗した場合: メモリの問題

「安全でない」言語 (C または C++) を使用している場合、メモリ破損が原因でバグが発生する可能性があります。

これらは最も深刻なケースです。1 つのモジュールでエラーが発生すると、別のモジュールのデータが「上書き」される可能性があります。これにより、通常のアプリケーション ロジックを使用して追跡できない、完全に説明不可能な孤立した障害が発生します。

アーキテクチャ レベルで身を守るにはどうすればよいですか?

このような「謎の」バグを回避するには、最新のアプローチを使用する必要があります。

• マルチスレッド プログラミング パターン:明確な同期により競合状態が排除されます。
• スレッドセーフな言語: コンパイル時にメモリの安全性を保証するツール:
  • Rust: 所有権システムによりメモリ エラーが排除されます。
  • Swift 6 同時実行性:強力なデータ分離チェック。
  • Erlang: アクター モデルを通じてプロセスを完全に分離します。

概要

バグを修正するということは、新しいコードを書くことではなく、古いコードがどのように機能するかを理解することです。管理者が触れてもいないブランチを編集するのは時間を無駄にする可能性があることを覚えておいてください。システムの状態を記録し、AI の非決定性の要素を考慮して、安全なツールを選択します。

(更新後も機能し続けるソリューションを作成する方法)

「アプリはパブリック API のみを使用でき、現在出荷されている OS 上で実行する必要があります。」 Apple アプリレビューガイドライン

新しいフレームワークを使い始めて、「もうすべて自分で理解できるだろう、ドキュメントを読むのは長すぎる」と思ったことがあるのは、決して一人ではありません。私たちの多くは、最初に試してから指示を見るという自然な調査本能を持っています。それはまったく普通のことです。

ただし、この段階では、調子に乗って、コードはうまく機能するものの、システムの明白ではない機能に依存しているという状況に陥りがちです。

単に「自分で解決する」だけでは不十分な場合があるのはなぜですか?

フレームワーク、特にクローズドなフレームワークは、複雑で多層のシステムです。多くの場合、次のような内部ロジックと最適化が隠蔽されます。

* 公開ドキュメントには記載されていません。
* 動作が将来も維持されることを保証するものではありません。
* 新しいバージョンのリリースにより変更される可能性があります。
* 開発者に知られている、まだ修正されていない機能が含まれている可能性があります。

私たちが直感的に行動すると、文書化されたルールではなく、ランダムな観察に基づいてアーキテクチャを構築してしまうリスクがあります。これにより、コードが更新に対してより敏感になる可能性があります。

ドキュメントは制限ではなく、信頼できるサポートです

フレームワーク開発者は私たちを助けるマニュアルを作成します。ドキュメント内で動作すると、次の結果が得られます。

* 安定性;
* サポート;
* 予測可能なシステム動作。

これらの制限を超えると、さらなるリスクを負うことになり、そのようなコードの保守がより困難になります。

実験？確かに。ただし、境界を理解した上で。
好奇心は開発者にとって素晴らしい特性です。新しいことを探索して試すことは絶対に必要です。しかし、ここに小さな願いがあります。

最も快適に実験できる方法は、ベスト プラクティスに頼ることです。

ドキュメントは、どのパスが最も安全で作成者によってサポートされているかを示すマップです。

外部の視点: 専門家のアドバイス

私たちは経験豊富な同僚から次のことを学ぶことがよくあります。

* 役立つ講座を開催しているので、
* カンファレンスで講演する
* 素晴らしい本やブログを書き、
* 独自のビジョンを共有します。

彼らの多くは本当に貴重な経験を共有しています。しかし、覚えておく価値があるのは、著者のアプローチが公式ドキュメントと矛盾している場合、それらは脆弱であることが判明する可能性があるということです。

このような「経験的パターン」は、次のような場合があります。

* フレームワークの特定のバージョンでのみ動作します。
* アップデートに敏感です。
* 異常な状況では予期しない動作をする可能性があります。

コミュニティから学ぶことは素晴らしく、やりがいのあることです。ただし、アドバイスは、たとえ最も権威のあるものであっても、必ず公式マニュアルで注意深く確認する必要があります。

SOLID について少し説明

SOLID 原則からの 3 つのアイデアは、このアプローチを完全に補完します。

* オープン/クローズの原則: パブリック API を通じて動作を拡張するように努め、可能であれば、隠れた実装に依存しないようにします。
* リスコフ置換原則: 特定の実装ではなく、契約に依存します。そうしないと、内部での変更が予期せぬ問題を引き起こす可能性があります。
* 依存関係の反転: 詳細ではなく抽象化に基づいて依存関係を構築します。

実際には、これは、フレームワークの内部の文書化されていない詳細に結び付けられると、システムが脆弱になることを意味します。
パブリック インターフェイスとコントラクトに基づいて、次の結果が得られます。

* フレームワークの変更からコードをより適切に分離します。
* テストの容易さ。
* アーキテクチャの予測可能性と信頼性。

バグがある場合はどうすればよいですか?

すべてがルールに従って行われたにもかかわらず、結果が期待を満たさないことも起こります。フレームワークは進化しますが、常に完璧であるとは限りません。そのような場合:

* 問題を再現する最小限のサンプルを構築します。
* 文書化された API のみが使用されていることを確認してください。
* バグレポートを送信してください – 開発チームはあなたの仕事に感謝し、支援しようと努めます。

例が回避策に依存している場合、開発者がサポートを提供することは非常に困難になります。

フレームワークを最大限に活用する方法

*ドキュメントを参照してください。
* 著者のガイドと推奨事項に従ってください。
* 説明されている機能内で実験してください。
* インターネットからのアドバイスを公式情報源で確認してください。
* フレームワーク契約を尊重しながらバグをローカライズします。

結論

フレームワークは、独自のゲームルールを持つ強力なツールです。それらを忘れると、コードが過度に脆弱になる危険があります。しかし、私たちは皆、作成された製品が長期間存続し、マイナーアップデートのたびに緊急の修正を必要としないことを望んでいます。

マニュアルとドキュメントは、真に信頼できるソリューションを作成するのに役立つ優れたサポートです。

ソース

https://developer.apple.com/app-store/review/guidelines/
https://en.wikipedia.org/wiki/SOLID
https://en.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/RTFM

このノートでは、Linux 上で iOS 用の C++ SDL アプリケーションを構築し、有料の Apple Developer サブスクリプションなしで ipa アーカイブに署名し、ジェイルブレイクなしで macOS を使用してクリーンなデバイス (iPad) にインストールする手順について説明します。

まず、Linux 用のビルド ツールチェーンをインストールしましょう。
https://github.com/tpoechtrager/cctools-port

ツールチェーンをリポジトリからダウンロードし、Godot Engine Web サイトの指示に従ってインストールを完了する必要があります。
https://docs.godotengine.org/ru/latest/development/compiling/cross-compiling_for_ios_on_linux.html

現時点では、Xcode dmg をダウンロードし、そこから SDK をコピーして cctools-port をビルドする必要があります。この段階は macOS で簡単に完了できます。インストールされている Xcode から必要な SDK ファイルをコピーするだけです。アセンブリが成功すると、ターミナルにはクロスコンパイラー ツールチェーンへのパスが含まれます。
次に、iOS 用の SDL アプリケーションの構築を開始できます。 cmake を開いて、C++ コードをビルドするために必要な変更を追加しましょう。

SET(CMAKE_SYSTEM_NAME Darwin)
SET(CMAKE_C_COMPILER arm-apple-darwin11-clang)
SET(CMAKE_CXX_COMPILER arm-apple-darwin11-clang++)
SET(CMAKE_LINKER arm-apple-darwin11-ld)

これで、cmake と make を使用してコンパイルできるようになりましたが、$PATH をクロスコンパイラー ツールチェーンに追加することを忘れないでください。

PATH=$PATH:~/Sources/cctools-port/usage_examples/ios_toolchain/target/bin

フレームワークと SDL と正しくリンクするために、それらを cmake で記述します。たとえば、Space Jaguar ゲームの依存関係です。

target_link_libraries(
${FSEGT_PROJECT_NAME}
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libclang_rt.ios.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2_mixer.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2_image.a
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreServices.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/ImageIO.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/Metal.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/AVFoundation.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/GameController.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreMotion.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreGraphics.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/AudioToolbox.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreAudio.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/QuartzCore.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/OpenGLES.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/UIKit.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/Foundation.framework"
)

私の場合、SDL、SDL_Image、SDL_mixer ライブラリは、静的リンクのために事前に macOS 上の Xcode でコンパイルされています。 Xcode からコピーされたフレームワーク。また、libclang_rt.ios.a ライブラリも追加されました。これには、iOS 固有のランタイム呼び出し (isOSVersionAtLeast など) が含まれます。 Android と同様に、モバイル バージョンでサポートされていない機能を無効にして、OpenGL ES を操作するためのマクロが含まれています。
ビルドの問題をすべて解決したら、arm 用にアセンブルされたバイナリを取得する必要があります。次に、ジェイルブレイクなしのデバイス上でアセンブルされたバイナリを実行することを考えてみましょう。
macOS では、開発者プログラムの料金を支払うことなく、Xcode をインストールし、Apple ポータルに登録します。 Xcode でアカウントを追加します ->設定 ->アカウント、空のアプリケーションを作成し、実際のデバイス上に構築します。組み立て中に、デバイスは無料の開発者アカウントに追加されます。組み立てて起動した後、アーカイブをビルドする必要があります。これを行うには、[汎用 iOS デバイスと製品] -> [汎用 iOS デバイスと製品] を選択します。アーカイブ。アーカイブが構築されたら、そこからembedded.mobileprovisionファイルとPkgInfoファイルを抽出します。デバイスへのビルド ログから、正しい署名キーを含む共同設計行、拡張子 app.xcent を持つ資格ファイルへのパスを見つけてコピーします。
アーカイブから .app フォルダーをコピーし、アーカイブ内のバイナリを Linux のクロスコンパイラーでコンパイルされたバイナリ (SpaceJaguar.app/SpaceJaguar など) に置き換えます。次に、必要なリソースを .app に追加し、アーカイブから .app 内の PkgInfo およびembedded.mobileprovision ファイルの整合性を確認し、必要に応じて再度コピーします。 codesign コマンド – を使用して .app に再署名します。 codesign には、署名用の入力キー、資格ファイルへのパス (.plist 拡張子で名前変更可能) が必要です。
再署名した後、Payload フォルダーを作成し、拡張子 .app を持つフォルダーをそこに移動し、Payload を持つ zip アーカイブをルートに作成し、アーカイブの名前を拡張子 .ipa に変更します。その後、Xcode でデバイスのリストを開き、新しい ipa をデバイスのアプリケーションのリストにドラッグ アンド ドロップします。この方法では、Apple Configurator 2 によるインストールは機能しません。再署名が正しく行われると、新しいバイナリを含むアプリケーションが 7 日間の証明書とともに iOS デバイス (iPad など) にインストールされます。テスト期間にはこれで十分です。

ソース

https://github.com/tpoechtrager/cctools-port

https://docs.godotengine.org/ru/latest/development/compiling/cross-compiling_for_ios_on_linux.html

https://jonnyzzz.com/blog/2018/06/13/link-error-3/

https://stackoverflow.com/questions/6896029/re-sign-ipa-iphone

https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html

この投稿では、Ubuntu で MinGW32 ツールチェーンを使用して Windows 用のライブラリとアプリケーションを構築するプロセスについて説明します。
wine をインストールします。

sudo apt-get install wine mingw-w64

これで、Windows 用の C/C++ アプリケーションを構築できるようになります。

# C
i686-w64-mingw32-gcc helloWorld.c -o helloWorld32.exe      # 32-bit
x86_64-w64-mingw32-gcc helloWorld.c -o helloWorld64.exe    # 64-bit
 
# C++
i686-w64-mingw32-g++ helloWorld.cc -o helloWorld32.exe     # 32-bit
x86_64-w64-mingw32-g++ helloWorld.cc -o helloWorld64.exe   # 64-bit

収集したexeはwineで確認できます。
次に、CMake ビルド、CMakeLists.txt ファイルへの変更を見てみましょう。MinGW 固有のものをビルド ファイルに追加します。

if (MINGW32)
set(CMAKE_SYSTEM_NAME Windows)
SET(CMAKE_C_COMPILER i686-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER i686-w64-mingw32-g++)
SET(CMAKE_RC_COMPILER i686-w64-mingw32-windres)
set(CMAKE_RANLIB i686-w64-mingw32-ranlib)
endif()

// для сборки shared dll
elseif (MINGW32)
add_library(FlameSteelEngineGameToolkit.dll SHARED ${SOURCE_FILES})
else()

// обязательно линкуем со всеми зависимостями
if (MINGW32)
target_link_libraries(
                        FlameSteelEngineGameToolkit.dll 
                        -static-libgcc
                        -static-libstdc++
                        SDL2 
                        SDL2_mixer 
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCore/FlameSteelCore.dll
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelBattleHorn/FlameSteelBattleHorn.dll
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCommonTraits/FlameSteelCommonTraits.dll)

set_target_properties(FlameSteelEngineGameToolkit.dll PROPERTIES
        PREFIX ""
        SUFFIX ""
        LINK_FLAGS "-Wl,--add-stdcall-alias"
        POSITION_INDEPENDENT_CODE 0 # this is to avoid MinGW warning; 
        # MinGW generates position-independent-code for DLL by default
)
else()

私たちは以下を収集します:

cmake -DMINGW32=1 .
make

出力は、収集している内容に応じて dll または exe になります。実際の例として、新しい Cube-Art-Project とそのライブラリのリポジトリをご覧ください。
https://gitlab.com/demensdeum/cube-art-project

https://gitlab.com/demensdeum/FlameSteelEngineGameToolkitFSGL

https://gitlab.com/demensdeum/cube-art-project-bootstrap

出典
https://arrayfire.com/cross-compile-to-windows-from-linux/

この投稿では、CMake と osxcross を使用して、Ubuntu ビルド マシン上で macOS 用のクロスプラットフォーム C++ アプリケーションをビルドする方法について説明します。
まず、osxcross ツールチェーンをインストールします。
https://github.com/tpoechtrager/osxcross
インストールは 3 段階で行われ、依存関係をダウンロードします。

cd tools
./get_dependencies.sh

Apple 公式 Web サイトから XCode.xip をダウンロードし、XCode から SDK をダウンロードします。

./gen_sdk_package_pbzx.sh /media/demensdeum/2CE62A79E62A4404/LinuxSupportStorage/xcode111.xip

最後のステップで XCode の使用許諾契約を読んでいただければ幸いです。次に、必要なプレフィックスを使用してツールチェーンを構築します。

INSTALLPREFIX=/home/demensdeum/Apps/osxcross ./build.sh 

これで、前の手順のプレフィックス ディレクトリから osxcross を使用できるようになります。 CMake の新しいビルド マクロを追加し、必要なものをすべて記述してみましょう。

if (OSXCROSS)
SET(CMAKE_SYSTEM_NAME Darwin)
SET(CMAKE_C_COMPILER o64-clang)
SET(CMAKE_CXX_COMPILER o64-clang++)
SET(CMAKE_C_COMPILER_AR x86_64-apple-darwin19-ar)
SET(CMAKE_CXX_COMPILER_AR x86_64-apple-darwin19-ar)
SET(CMAKE_LINKER x86_64-apple-darwin19-ld)
SET(ENV{OSXCROSS_MP_INC} 1)
endif()

動的リンクは私にとっては成功しなかったので、ライブラリを静的にエクスポートします。

if (OSXCROSS)
add_library(FlameSteelCore STATIC ${SOURCE_FILES})
else()

次に、osxcross に必要なライブラリがないという事実に直面するかもしれません。私は SDL2 を使用しているときにこれに遭遇しました。 osxcross は既製のライブラリ パッケージをサポートしています –マックポート。たとえば、SDL2-mixer をインストールすると、次のようになります。

osxcross-macports -v install libsdl2_mixer

この後、cmake-make リンクで通常どおりライブラリ/アプリケーションの構築を開始できます。必要に応じてライブラリの静的リンクを指定することを忘れないでください。

ライブラリの手動アセンブリ

現在、静的リンク中にライブラリが正しくアーカイブされないという問題に遭遇しました。最終的なアプリケーションをビルドするときに、次のエラーが表示されます。

file was built for archive which is not the architecture being linked (x86_64)

このチケットと非常に似ており、回避策を実装することができ、ビルドが正しく完了しました。静的ライブラリを解凍し、osxcross アーカイバを使用して新たにビルドしましょう。

ar x ../libFlameSteelCore.a
rm ../libFlameSteelCore.a
x86_64-apple-darwin19-ar rcs ../libFlameSteelCore.a *.o

また、私が個人的に考えている問題の 1 つは、Ubuntu 上で macOS アプリケーションを直接実行する機能 (少なくとも一部の機能) が欠如していることです。もちろん、darling というプロジェクトはありますが、サポートにはまだ不十分な点が多くあります。

ソース

https://github.com/tpoechtrager/osxcross

現在では、クラウド サービスに依存する必要はなくなり、独自のハードウェアだけで高品質の画像を生成できるようになりました。この投稿では、ComfyUI を使用して最新の FLUX モデルをコンピューター上でローカルに実行する方法について説明します。

ComfyUI はノードベースのアーキテクチャを使用します。これにより、次のことが可能になります。
– 生成のあらゆる段階を完全に制御します。
– 既成の「ワークフロー」を簡単に共有

FLUX は大規模なモデルであるため、ハードウェア要件は SD 1.5 または SDXL よりも高くなります。
– ビデオ カード (GPU): 12 GB VRAM 以上を搭載した Nvidia RTX (快適な作業用)。 8 GB 以下の場合は、量子化バージョン (GGUF または NF4) を使用する必要があります。
– ランダム アクセス メモリ (RAM): 最低 16 GB (32 GB 以上が望ましい)。
– ディスク容量: モデルとコンポーネント用に約 20 ～ 50 GB。

FLUX を開始する最も簡単な方法は、既製のテンプレートを使用することです。ワークフロー ウィンドウで Flux text to image を検索してインストールするだけです。

「Text to Image (Flux.1 Dev)」ノードに英語でプロンプトを書き、解像度 (FLUX は 1024×1024 以上で適切に動作します) を選択して、実行 を押します。

第 1 世代では、モデルがビデオ カード メモリにロードされるため、時間がかかる場合があります。

https://github.com/comfyanonymous/ComfyUI

コード (いわゆる Vibe コーディング) の作成にニューラル ネットワークを使用したいと考えていて、たとえば Nvidia RTX ビデオ カードを備えたかなり強力なコンピューターを持っている場合は、環境全体を完全に無料でマシンに展開できます。これにより、有料サブスクリプションの問題が解決され、コードがどこにも送信されないため、NDA の下でプロジェクトを安全に作業できるようになります。この投稿では、LM Studio、VS Code、Continue 拡張機能のローカル バンドルを組み立てる方法について説明します。

ローカル Vibe コーディング用ツール

快適な作業のためには、次の 3 つの主要なコンポーネントが必要です。
– LM ​​Studio: ローカル LLM をダウンロードして実行するための便利なアプリケーションです。 GGUF モデルの操作に伴うすべての複雑さを引き受け、OpenAI API と互換性のあるローカル サーバーを構築します。
– VS Code: 人気があり、馴染みのあるコード エディタです。
– Continue: ニューラル ネットワークを作業環境に直接統合する VS Code の拡張機能。チャットしたり、リファクタリング用のコードをハイライトしたり、オートコンプリートをサポートしたりできます。

ハードウェア要件

ローカル言語モデルはメモリを大量に消費します。
– ビデオ カード (GPU): 8 GB VRAM 以上を搭載した Nvidia (70 ～ 80 億のパラメータを持つモデルで快適に作業するため)。重いモデルには 16 GB の VRAM が必要です。
– ディスク容量: さまざまなダウンロード モデルを保存するために約 500 GB。

リンクの構成

セットアップ プロセスは非常に簡単で、ターミナルでの複雑な操作は必要ありません。
1. LM Studioをダウンロードしてインストールします。組み込みの検索を使用して、Qwen Coder や gemma3:12b などの軽量モデルを見つけます。
2. LM Studio で、「ローカルサーバー」タブに移動し、「サーバーの開始」をクリックします。デフォルトでは、「http://localhost:1234/v1」で起動します。
3. VS Code を開き、プラグイン ストアからContinue 拡張機能をインストールします。
4. Continue 構成ファイルを開き、LM Studio から「openai」プロバイダーとローカルサーバーのアドレスを指定して新しいモデルを追加します。

その後、「続行」サイドバーでローカル LLM と直接通信し、コードについて質問したり、新しいコンポーネントを生成したりできます。

なぜこれが機能するのでしょうか?

前に書いたように、LLM はフラット構造と WET (Write Everything Twice) コードの方が優れています。ローカル パラメーター モデルは、複雑なアーキテクチャの設計に関しては GPT-4 のような巨大モデルに劣るかもしれませんが、ボイラープレート コードの生成、単純な関数のリファクタリング、およびラピッド プロトタイピングについては十分以上の能力を備えています。

さらに、ローカル Vibe コーディングを使用すると、コードがマシンから離れることはありません。このため、この組み合わせは企業開発や機密データの取り扱いに最適です。

出力

ローカル ニューラル ネットワークは、プログラマーを完全に置き換えたり、複雑なシステムを設計したりすることはできません。ただし、LM Studio + VS Code + Continue の組み合わせにより、クラウド サービスからの独立性が提供され、プライバシーが維持されます。これは、小さなモデルの制限を我慢してプロジェクト アーキテクチャを独立して制御する意欲がある場合、日常的なタスクに完全に機能する補助ツールです。

リンク

https://code.visualstudio.com/
https://lmstudio.ai/
https://continue.dev/

ソース

https://youtu.be/IqqCwhG46jY
https://www.youtube.com/watch?v=7AImkA96mE8

以前は、ニューラル ネットワークを使用してビデオを作成することは、Runway や Luma などのクラウド サービスの特権でした。現在、最新の Nvidia グラフィック カードをお持ちであれば、コンピュータ上で高品質のビデオを生成できます。この記事では、ComfyUI と効果的なLTX-2.3 モデルを使用してローカル ビデオ生成を設定する方法を説明します。

ビデオ生成用ツール

仕事のためには次のものが必要です。
– ComfyUI: ノードベースのアーキテクチャを備えた強力なインターフェイスで、生成プロセスを柔軟にカスタマイズできます。
– LTX-2.3: Lightricks の最新モデル。比較的適度なビデオ メモリ要件でスムーズで詳細なビデオを作成するために最適化されています。

ハードウェア要件

ビデオの生成は、画像を操作するよりもはるかにリソースを大量に消費するプロセスです。
– ビデオ カード (GPU): 768×512 の解像度には、8 GB VRAM を搭載した Nvidia RTX が最低限必要です。快適な操作とより高い解像度を実現するには、16 ～ 24 GB の VRAM を搭載することが非常に望ましいです。
– ランダム アクセス メモリ (RAM): 最低 32 GB。ビデオ モデルと VAE は、ダウンロード時に多くのスペースを消費します。
– ディスク容量: モデル自体と関連コンポーネント用に約 500 GB。

セットアップと起動

ComfyUI で LTX-2.3 を起動するプロセスは次のとおりです。
1. ComfyUI を更新します: このモデルは比較的新しいため、最新バージョンのインターフェースがインストールされていることを確認してください。
2. ワークフローのインストール: 最も簡単な方法は、LTX ビデオ用の既製の JSON テンプレートを見つけることです。このモデルでは、ビデオ潜在スペースを処理するには特定のノードが必要です。
3. プロンプトとパラメータ: シーンの説明を英語で入力します。 LTX-2.3 は動きをよく理解していることに注意してください (例: 「カメラが周回する」、「速い動き」)。

LTX-2.3 を選ぶ理由

LTX-2.3 は、独自のクラウド サービスと同等の結果を提供しながら、ローカルで実行できるという点で注目に値します。これにより、次のことが得られます。
– 完全なプライバシー: プロンプトや生成されたビデオが他の人のサーバーに送信されることはありません。
– コントロール: 試行ごとに料金を支払うことなく、フレーム レート (FPS)、解像度、プロンプトの強度を試すことができます。

ローカル ビデオ生成は現在も開発が進められており、LTX-2.3 は「ホーム ハリウッド」の世界への素晴らしい入り口となります。

リンク

https://github.com/comfyanonymous/ComfyUI
https://huggingface.co/Lightricks/LTX-Video

現在では、コンテンツを作成するためにクラウド サービスに依存する必要はありません。高品質の音楽をすべて自分のハードウェアで生成できます。この投稿では、ComfyUI を使用して最新の ACE-Step-1.5 モデルをコンピュータ上でローカルに実行する方法について説明します。

ComfyUI はノードベースのアーキテクチャを使用します。これにより、次のことが可能になります。
– オーディオ生成のあらゆる段階を完全に制御します。
– 既成の「ワークフロー」を簡単に共有。

ACE-Step-1.5 は、大量の計算リソースを必要とする音楽生成のための高度なモデルです。ハードウェア要件は、多くの単純なシンセサイザーの要件よりも高くなります。
– ビデオ カード (GPU): 8 GB VRAM 以上 (12 GB 以上を推奨) を搭載した Nvidia RTX により、高品質で快適な作業が可能です。
– ランダム アクセス メモリ (RAM): 最低 16 GB (32 GB 以上が望ましい)。
– プロセッサ (CPU): AVX/CUDA コンピューティングを適切にサポートする最新のマルチコア プロセッサ。
– ディスク容量: モデルとコンポーネント用に約 20 ～ 50 GB。

ACE-Step-1.5 を実行する最も簡単な方法は、既製のオーディオ生成テンプレートを使用することです。ワークフローウィンドウで音楽テキストをオーディオに検索してインストールするだけです。

ジャンルと雰囲気を説明するプロンプト (たとえば、「重低音のある高揚感のあるシンセウェーブ トラック」) を「プロンプト入力」ノードに書きます。希望の期間を指定して実行を押します。
第 1 世代では、モデルがビデオ カード メモリにロードされ、複雑な音響パターンが処理されるため、時間がかかる場合があります。

https://github.com/comfyanonymous/ComfyUI
https://www.youtube.com/watch?v=UAlLD5fS7-c

ChatGPT のようなものを起動したいと思っていて、たとえば Nvidia RTX ビデオ カードを備えたかなり強力なコンピューターを持っている場合は、ollam プロジェクトを実行できます。これにより、ローカル マシン上で既製の LLM モデルの 1 つを完全に無料で使用できるようになります。 ollama は、ChatGPT の方法で LLM モデルと通信する機能を提供します。最新バージョンでは、画像を読み込み、出力データをjson形式でフォーマットできる機能も発表されました。

また、プロジェクト自体も Apple M2 プロセッサを搭載した MacBook で実行しましたが、AMD の最新モデルのビデオ カードがサポートされていることもわかっています。

macOS にインストールするには、ollam Web サイトにアクセスしてください。
https://ollama.com/download/mac

「macOS 用のダウンロード」をクリックすると、ollama-darwin.zip 形式のアーカイブがダウンロードされます。アーカイブ内には Ollama.app があり、これを「アプリケーション」にコピーする必要があります。この後、Ollama.app を起動します。おそらく、最初の起動時にインストール プロセスが発生します。その後、トレイにオラマのアイコンが表示されます。トレイは右上の時計の隣にあります。

その後、通常の macOS ターミナルを起動し、コマンドを入力して ollam モデルをダウンロード、インストールし、実行します。利用可能なモデル、説明、およびその特性のリストは、ollam Web サイトでご覧いただけます。
https://ollama.com/search

発売時にビデオカードに適合しない場合は、パラメータが最も少ないモデルを選択してください。

たとえば、llama3.1:latest モデルを起動するコマンドは次のようになります。

ollama run llama3.1:latest

Windows と Linux のインストールは一般的に似ていますが、場合によっては ollam インストーラーがあり、さらに Powershell 経由でインストーラーを操作します。
Linux の場合、インストールはスクリプトを使用して行われますが、特定のパッケージ マネージャーのバージョンを使用することをお勧めします。 Linux では、通常の bash ターミナル経由で ollam を起動することもできます。

情報源
https://www.youtube.com/watch?v=Wjrdr0NU4Sk
https://ollama.com

ビデオを安定させて手ぶれを除去したい場合は、「ffmpeg」ツールが強力なソリューションを提供します。組み込みフィルター `vidstabdetect` と `vidstabtransform` のおかげで、複雑なビデオ エディターを使用せずにプロフェッショナルな結果を達成できます。

仕事の準備

始める前に、`ffmpeg` が `vidstab` ライブラリをサポートしていることを確認してください。 Linux では、次のコマンドでこれを確認できます。

bash  
ffmpeg -filters | grep vidstab  

ライブラリがインストールされていない場合は、追加できます。

sudo apt install ffmpeg libvidstab-dev  

brew による macOS のインストール:

brew install libvidstab
brew install ffmpeg

それでは、プロセスに進みましょう。

ステップ 1: 動作分析

まず、ビデオの動きを分析し、安定化パラメータを含むファイルを作成する必要があります。

ffmpeg -i input.mp4 -vf vidstabdetect=shakiness=10:accuracy=15 transfile=transforms.trf -f null -  

パラメータ:

揺れ: ビデオの揺れレベル (デフォルトは 5、より複雑な場合は 10 まで増やすことができます)。
精度: 分析精度 (デフォルトは 15)。
transfile: モーションパラメータを保存するファイル名。

ステップ 2: 安定化を適用する

これで、変換ファイルを使用して安定化を適用できるようになりました。

ffmpeg -i input.mp4 -vf vidstabtransform=input=transforms.trf:zoom=5 output.mp4

パラメータ:

input: 変換パラメータを含むファイル (最初のステップで作成) を指します。
ズーム: 黒いエッジを除去するためのズーム係数 (例: 5 – アーティファクトが除去されるまで自動ズーム)。

私は、1936 年のアラン・チューリングの論文「解像度の問題への応用による計算可能な数について」の最初のページの翻訳を紹介します。最初の章には、後に現代のコンピューティングの基礎となるコンピューターの説明が含まれています。

この記事の全訳と説明は、アメリカの普及者 Charles Petzold による「Reading Turing: A Journey through Turing’s Historical Article on Computability and Turing Machines」(ISBN 978-5-97060-231-7、978-0-470-22905-7) というタイトルの本で読むことができます。

元の記事:
https://www.astro.puc.cl/~rparra/tools/PAPERS/turing_1936.pdf

解像度問題への応用による計算可能な数値について

午前チューリング

[1936 年 5 月 28 日に受領 – 1936 年 11 月 12 日に読了]

「計算可能な」数値は、小数としての表現が有限の方法で計算できる実数として簡単に説明できます。一見すると、この記事では数値を計算可能なものとして扱いますが、整変数、実数変数、計算可能な変数、計算可能な述語などの計算可能な関数を定義して調査することは、ほぼ同じくらい簡単です。ただし、これらの計算可能なオブジェクトに関連する基本的な問題は、どの場合でも同じです。詳細な検討のために、考慮する方法が最も面倒ではないため、計算可能なオブジェクトとして計算可能な数値を選択しました。計算可能な数値と計算可能な関数などの関係については、近いうちに説明したいと思っています。同時に、計算​​可能な数値で表現される実変数の関数理論の分野でも研究が行われます。私の定義によれば、実数は、その 10 進数表現が機械で記述できる場合に計算可能です。

パラグラフ 9 と 10 では、計算可能な数値には、当然計算可能であると考えられるすべての数値が含まれることを示すために、いくつかの議論を示します。特に、いくつかの大きなクラスの数値が計算可能であることを示します。これらには、たとえば、すべての代数的数値の実部、ベッセル関数のゼロの実部、数値 π、e などが含まれます。ただし、次の計算不可能な定義可能な数値の例でわかるように、計算可能な数値には定義可能な数値がすべて含まれるわけではありません。

計算可能な数値のクラスは非常に大きく、多くの点で実数のクラスと似ていますが、依然として数えることが可能です。 §8 では、反対と思われる特定の議論を検討します。これらの議論の 1 つが正しく適用されると、一見するとゲーデル* の結論と似た結論が導き出されます。これらの結果は非常に重要な応用分野を持っています。特に、以下に示すように (§11)、解像度の問題には解決策がありません。

最近の記事で、アロンゾ・チャーチは「効果的な計算可能性」という考えを紹介しました。これは私の「計算可能性」という考えと同じですが、定義はまったく異なります。チャーチも解決の問題に関して同様の結論に達しています。 「計算可能性」と「効率的に計算可能」が同等であることの証明は、この記事の付録に示されています。

1. コンピュータ

計算可能な数とは、小数点以下の桁が有限の方法で数えられる数であることはすでに述べました。ここではより明確な定義が必要です。この記事では、§9 に到達するまで、ここで与えられた定義を正当化する実際の試みは行いません。今のところ、（このための）（論理的な）根拠は、人間の記憶には必然的に限界があるということだけを述べておきます。

実数を計算する過程にある人間と、有限数の条件 q1、q2、…、qR のみを満たすことができる機械を比較してみましょう。これらの条件を「m 構成」と呼びます。この（つまり、そのように定義された）マシンには「テープ」（紙に似たもの）が装備されています。機械内を通過するこのベルトはいくつかのセクションに分かれています。それらを「正方形」と呼びましょう。このような各正方形には、何らかの「シンボル」を含めることができます。いつでも、「このマシン内にある」シンボルを含むそのような正方形は 1 つだけ、たとえば r 番目の正方形だけです。このような正方形を「スキャンされたシンボル」と呼びます。 「スキャンされた文字」は、いわばマシンが「直接認識している」唯一の文字です。ただし、m 構成を変更することで、マシンは以前に「見た」(スキャンした) 文字の一部を効果的に記憶できるようになります。いつでもマシンの可能な動作は、m 構成 qn とスキャンされたシンボル *** によって決まります。このシンボルのペアを qn、「構成」と呼びましょう。このように指定された構成によって、特定のマシンの可能な動作が決まります。スキャンされた正方形が空白である (つまり、文字が含まれていない) 構成の一部では、マシンはスキャンされた正方形に新しい文字を書き込み、その他の構成ではスキャンされた文字を消去します。このマシンは移動して別のマスをスキャンすることもできますが、この方法では右または左に隣接するマスにのみ移動できます。これらの操作に加えて、マシンの m 構成を変更することもできます。この場合、書かれた文字の一部は、計算される実数の小数部分である一連の数字を形成します。残りは「記憶を助ける」ための不正確なマークにすぎません。この場合、上記の不正確なマークのみを消去することができる。

ここで考慮される演算には、計算で使用されるすべての演算が含まれると私は主張します。このステートメントの理論的根拠は、機械理論を理解している読者にとっては理解しやすいものです。したがって、次のセクションでは、「マシン」、「テープ」、「スキャンされた」などの用語の意味の理解に基づいて、問題の理論を展開していきます。

*ゲーデル「プリンキピア数学 (1910 年、1912 年、1913 年にホワイトヘッドとラッセルによって出版) および関連システムの形式的に決定不可能な文について、第 1 部」Journal of Mathematics。 『物理学』ドイツ語月刊誌第 38 号 (1931 年、173-198 ページ)。
** アロンゾ・チャーチ、「初等整数理論における決定不可能な問題」、American J. of Math.、第 58 号 (1936 年)、345-363 ページ。
*** アロンゾ チャーチ、「解決問題に関するメモ」、J. of Symbolic Logic、No. 1 (1936)、40-41 ページ