忍者ブログ

slack diary

鉄道模型シミュレーター(VRM)を紹介するホームページ「CaldiaのVRM Room」の更新情報と、Caldia本人の日常ぐだぐだ日記。

VRMNXのウワサ

ウワサっつーかネタバレと言うか。
I/Oに岩渕さんのインタビューが載ってました。
個人的に気になったところは以下の2箇所。
・DirectX12対応
・スクリプト言語はPython採用

DirectX12対応は昨今のPC環境に追従して素直に歓迎ですね。
ただしDirectX12はWindows10以降しか対応していないため、自分のようなWindows8.1やWindows7では遊べないことになります。
これを期にWindows10へ移行するのも検討ですかね~。

Python採用はついに!といった感想です。
アセンブリチックなスクリプト言語はおそらく内部で高速に動作させるには致し方なかったとはいえ、ユーザーからすれば未知の言語であり取っ付きにくく、汎用性も流用性も乏しいものでした。(おまけにVRM以外使えない)
それがRPGツクール等と同様に汎用プログラム言語で実装されるということになります。
NXの対応次第ですが、オブジェクト指向でコードが書けたりファイルIO、ネットワークIOも実装できれば他のアプリケーションなんかと連携できて楽しみが増えそうです。
外部エディタも使えると尚良し。

インタビューで強調していたところと言えば、既存のVRMは古いコードを「CPUパワーでゴリ押し」しているのに対して、NXはコードを刷新して処理をDirectDrawに置き換えているので今まで以上に高効率な動作になることが期待されます。(GPUを効率良く使うってことですね)
作り込めば作り込むほど重くなっていたレイアウトも改善されることに期待します。

 

おまけ。
鉄道模型チックにレールをブワーッと敷いて列車を並べてニヤニヤするレイアウト。
よく見たら地形の縁が消えてますが、NXは俯瞰でも耐えられる描画方法になれば嬉しいですね。

色々な新機能も実装されそうですが、ダウンロード前提になるなら基本設計が出来た段階でソフトを公開してちょっとずつ機能を追加していくようなプロダクトスケジュールがいいなぁ。

他にもインタビューではWebで公開されていない情報が載っていたので気になる方は要チェックです。(・ω・)



2018-12-11-0002
MX→NX
タイトルを盛大に誤爆したのを修正。スパロボじゃねーんだぞ…。
※記事URL直したので一部リンク壊れてるかも
PR

コメント

1. 無題

Python対応は私も楽しみです!
できることが一気に増えすぎて、逆に何やったらいいか分からなくなりそうでもありますが・・・

外部パッケージのおかげで行列計算がラクになり、
フライスルーカメラの制御とかは書きやすくなるかな?と期待しています。


でもやはり実行速度に不安はありますね・・・
同じことするにも、上手なコードと下手なコードで全然スピードが違うので…って、そこまでの処理はデジタル汽車ぽっぽゲームでは必要ないか?

2. 無題

AKAGI氏、楽しみですよね~!
とりあえず自分は鉄道そっちのけでひたすらプログラミングしてる可能性があります。
VRMでRPG作ったりとか、VRMでシューティング作ったりとか。(笑)
・・・というのは冗談にしろ、コードの管理体系(レイアウト単位で保持されるのか、オブジェクト単位なのか)と公開されるAPIのお作法なんかを探る事になりそうです。
お行儀の良いコードと悪いコードの実行速度比較も見てみたいですね。

実行速度に関しては昔からスクリプト言語を触っているとそういった声をよく聞きますが、自分的には問題視していません。
理由は昨今におけるスクリプト言語の普及している要因がまさに「使える実行速度になってきたから」です。
例えばJavascriptでよく聞く「JITコンパイラ」という仕組みがありますが、当然Pythonにも実装が存在しています。(Numbaあたりが有名)
同じ汎用スクリプトである「Lua」もFactorioを始めとしたゲームに使われており、ちゃんと実装すれば(この場合の実装とはユーザーのスクリプトのコーディングではなく受け取るゲームエンジン側の処理)ネイティブコードと遜色ない動作をしてくれるでしょう。

もう一つの理由としては「PyCUDA」の存在です。
自分も詳しくはないのですが、乱暴に言うなれば「PythonをGPUで実行する仕組み」(Pythonから呼べるCUDA(GPGPU)のAPI)があるらしいです。
OpenCLとの親和性も高いようで前々から岩渕さんが目をつけていた可能性があり、どちらかと言うとVRMNXとしてはこちらが本命で、ゲームエンジン部分にPyCUDA実装の目処がついたんじゃないかなーと思います。
まあ、そうは言ってもゲームのフレームレートと計算の実行速度は別に同期していなくてもいいので、計算速度は多少遅くてもいいからユーザーフレンドリーな環境は歓迎です。

とりあえずそれっぽいキーワードを並べてみましたがちゃちゃっとググっただけなので認識間違いがあるかも知れませんのであしからず。

3. VRMpyの妄想

>VRMでRPG作ったりとか、VRMでシューティング作ったりとか
VRM関係なく普通のPythonで書けばいいじゃん!的なツッコミはさておき(笑)
高級(言語で作った大したことない)スプライトゲームは私も作ってるかも(笑)

VRM的にマジメな話では
import ○○
みたいな感じで昔のgws/1.0みたいなのがガバッと読み込めるといいなあなんて思いますね。
コードの保守性が爆上がりしそうです!
JITコンパイラも、I/Oのハナシを超拡大解釈すると、あるかも?ですね。


PyCUDAはサンプルコードを回したのみですが、
おそらく並列処理の設計次第でかなりパフォーマンスが変わる(で、おそらくは、並列処理が不要な処理ならふつうにCPUが処理したほうがいろいろベター?)な気がします。GPGPUの適用分野がほとんど機械学習でサチってる状況をみると汽車ぽっぽゲームで恩恵を受けるのは厳しそうな予感です。
(PyCUDAはGeForceのみで、Radeonでは動かないみたいですし)
(岩渕さんなら、やっちゃえGPGPU!とかってOpenCLをユーザーに投げて来ないとは言えませんが笑)
A列車的なパーティクル(エージェント)シミュレーションをVRMに組み込むとなったら、強力かも?
どんなVRMになるのか想像もつきませんが……。

本当に楽しみです!

4. 無題

>VRM関係なく普通のPythonで書けばいいじゃん
いっときVRM4で流行ったミニゲーム系もそうなのですが、「VRMの資源(車両とかストラクチャとか)でゲームを作る」っていうのが楽しいと思うのですよ。

>昔のgws/1.0みたいなのがガバッと読み込めるといいなあなんて思いますね
同意。
ライブラリ毎にコードを分割管理しておき、それらはglobalではなく必要な時にインポートできれば、使い分けや競合が起きなくて良いですね。メタ属性としてライブラリ名・バージョン・作者・前提ライブラリ(前提はimportしなくても取り込む)を包括した上で簡単なファイルインポートやエクスポート、またはNugetみたいにネットワークライブラリへコミット&ダウンロードで共有出来れば理想的です。

>A列車的なパーティクル(エージェント)シミュレーションをVRMに組み込むとなったら、強力かも?
PyCUDA動かしたフットワークの軽さは素晴らしい!
目的が違うから難しいかな…。けれど自前で疑似実装できそうな気はしますね。
シミュレーションでエージェントと聞くと某シムシティのGlassBoxを思い出します…うぅ…。

最新コメント

[05/30 Caldia]
[05/19 C-PON]
[10/03 vrmkyobuilding]
[05/10 Caldia]
[05/04 USO800鉄道]