【wasm】ブラウザでC++。Emscriptenを語ろう

1 名前：L mailto:sage [2019/01/15(火) 19:50:48.94 ID:cXSiB+ud.net] タイトル通り。 ・canvas への描画が可能なことを確認。 ・emscripten_sleep() でその場で停止できることを確認。 ・付属の emrun や mongoose などで Local Server を作れば、local だけで 　wasm の起動が出来ることを確認。 ・mongoose からは、cgi も起動でき、XmlHttpRequest()でローカルファイルを JSから読み込め、cgi も自由に起動できることを確認。 ・ローカル・ファイルアクセス、clipboard の読み書きの他、Local OS の 　全ての機能を自由にできる可能性有り。 ・これを使えば、Java の JVM に変わる新たなローカル仮想環境ができる。 40 名前：デフォルトの名無しさん [2019/02/07(木) 00:00:12.17 ID:FsbblVW+.net] age 41 名前：デフォルトの名無しさん [2019/02/07(木) 17:57:22.68 ID:fRacvqu0.net] https://i.redd.it/7vuxeeptx2f21.png ↑ Chrome 内で (試作品の) 独自 Windows System (?) を実行中のキャプチャ 画像。 42 名前：L mailto:sage [2019/03/11(月) 12:54:38.07 ID:HTmv6ctw.net] >>1 自作 C++ compiler nwsc で、bsync, bwait, bresume, bcall なるものを実装し、 bsync 修飾された関数にはコンパイラが変形した特殊なコードを出力する 事で、JSのイベントループの制限を突破することに成功した。次のことが出来る � 43 名前：謔､になった/なる： 1. イベントハンドラ実行中に、独自のイベントループを作ってそこで任意のイベントの発生を 　待機/処理する。メニュー・イベントのハンドラの中でハンドラを終了する事無く、 　独自のファイル入力ダイアログを出し、OK/CANCELボタンが押されるまで待機し、 　続けて必要な処理を行うこと。 2. CPUパワーや電力を消費する事無く、その場で待機する事ができる Sleep() 関数の実装。 3. getch(), getche(), (ポケコン)BASIC の pause, wait, input 相当のものの実装。 #なお、bsync などの語頭の「b」は、「async(非同期)」の a を b に変えたもの。 　JS の async, await より強力なので a の次を表す意味で b にした。 [] [ここ壊れてます] 44 名前：L mailto:sage [2019/03/29(金) 10:50:18.05 ID:sD1xGsa7.net] >>1 自作 wasm demo を更新した。 ・Ctrl+ +, Ctrl + - での拡大縮小、Ctrl+Shift+I での開発者モードへの遷移(Chrome)が可能に。 ・コンソール出力(textarea)へのコピペに対応。 ・サーバーに置いてある jpg ファイルを読み込んで独自 Window 内への描画に対応。 　回転表示可能。 ・demo1 : 2枚の Windowにedit widget のテスト。メニューあり。ブラウザ内にある 　独自Window のドラッグ移動とサイズ変更が可能。 ・demo2 ：2枚の jpg 画像を読み込んで表示するテスト。 ・同じソースからビルドした Windows native 版も手元にある。 ・Window も Widget 類も全部自前で描画しているのでタイトルバーの色や枠の太さなどは 　自由に変えられる。原則的に native 版と wasm版で pixel 単位で全く同じ見た目。 nowsmartsoft.atwebpages.com nowsmartsoft.atwebpages.com/demo1/index.html nowsmartsoft.atwebpages.com/demo2/index.html 45 名前：L [2019/03/31(日) 12:58:32.59 ID:vDO0/VaM.net] >>1 wasmとcanvas 2Dを使った3D地形(?)のスクロールサンプルを作ってみた。 nowsmartsoft.atwebpages.com/demo_land/index.html ご覧ください。思っていたよりはちょっと遅いかな。 WebGL使ったら速くなるかもしれない。 46 名前：デフォルトの名無しさん [2019/04/01(月) 14:17:41.70 ID:QUlyRw/u.net] どうせWebGL使うんだったらwasm使う意味なくね 47 名前：L mailto:sage [2019/04/01(月) 14:30:39.86 ID:YLhs0zdh.net] wasmがなぜ重要かは、まだ言わない。 48 名前：デフォルトの名無しさん [2019/04/01(月) 14:40:56.11 ID:bzrp4n7u.net] naclとは別物なの？ 49 名前：デフォルトの名無しさん mailto:sage [2019/04/01(月) 15:00:24.18 ID:RkAplvWW.net] >>46 wasm (= WebAssembly) は、NaCl (= Google Native Client) とは別物。 50 名前：デフォルトの名無しさん [2019/04/01(月) 15:07:19.83 ID:bzrp4n7u.net] PNaClを使ってたんやね 51 名前：デフォルトの名無しさん mailto:sage [2019/04/01(月) 15:12:02.16 ID:YLhs0zdh.net] Google Native Client は、WebAssemblyの普及に伴いそちらにリソースを 集中するため開発を終了し、2019年にChromeから削除されることが発表 された。 52 名前：デフォルトの名無しさん mailto:sage [2019/04/01(月) 15:22:44.69 ID:RkAplvWW.net] >>48 「>>42 >>43」は、PNaCl ではなく、WebAssembly を使ってる。 53 名前：デフォルトの名無しさん mailto:sage [2019/04/01(月) 17:34:37.66 ID:RkAplvWW.net] >>1 どうも世界には、Java でも C# でもない共通プラットフォームを作りたがってる人たちがいて、 その中には、FireFox, Google, Apple が含まれるらしい。 WASI = WebAssembly System Interface なるものの標準化が進められており、例えば、native のファイルシステムに直接アクセスできるようになり、 それによって wasm がブラウザ内部に留まらず、Javaのようなプラットフォーム非依存の共通アプリケーション が作れる存在になることを目指しているらしい。 # 2019/03/27 の記事： https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-i 54 名前：nterface/ # 2019/03/28 の記事： https://www.infoworld.com/article/3384920/mozillas-wasi-takes-webassembly-beyond-the-browser.html なぜかタイムリーに Java への批判が出てきた。 「Java は安全な言語ではない」： # 2019/03/28 の記事： https://lemire.me/blog/2019/03/28/java-is-not-a-safe-language/ [] [ここ壊れてます] 55 名前：デフォルトの名無しさん mailto:sage [2019/04/02(火) 01:15:22.26 ID:LpV8NoZ4.net] >>1 Adobe自身も、FlashからWebAssemblyに移行するらしい： https://blogs.adobe.com/japan/201707adobe-flash-update/ >>50 アメリカの掲示板 Reddit での WASI のスレッド: [Standardizing WASI: A system interface to run WebAssembly outside the web] https://www.reddit.com/r/programming/comments/b65yn7/standardizing_wasi_a_system_interface_to_run/ 56 名前：デフォルトの名無しさん mailto:sage [2019/04/02(火) 02:11:54.11 ID:N1DZco4a.net] 何度もあらわれては消えていく"write once run anywhere"のコンセプト・・ はてさてどうなりますやら 57 名前：デフォルトの名無しさん [2019/04/02(火) 11:07:57.88 ID:5+C+zQyU.net] wasabiならもっと流行るはず 58 名前：デフォルトの名無しさん mailto:sage [2019/04/02(火) 13:50:43.70 ID:ZD2r0ERn.net] >>53 C#も、XamarineもUnityもその思想をやろうとしてると思うけど。 59 名前：デフォルトの名無しさん mailto:sage [2019/04/03(水) 01:36:20.38 ID:UEgi/Llh.net] 「C# Run Anywhere」でGoogleって、海外のサイトを見ていたら、 C#は設計上は、仮想マシン上で動くことになってるけど、MS公式の Runtimeで、大体動くのは、大体WindowsとMacだけで、実質、 Windows向けだと書いている人がいた（それが本当かどうかは分からないけど）。 少なくとも、以下のようなことは大体正しいのではないかと思う。 ・MSにとって、C#がマルチプラットフォームになることはマイナスである。 ・MSはC#をRun anywhere にすることには力を入れてないか、目指していない。 60 名前：L mailto:sage [2019/04/03(水) 15:29:38.83 ID:+15LYwzR.net] >>43 結論から言うと、ゲームに置いては、ブラウザ内アプリと native アプリのどちらで 組むかは、速度性能で選ぶ必要がなくなりそうだ。理由は以下の通り： 今回、試しに描画部分をWebGLに変えてみたら、劇的に高速になった。 詳しくは分からないが、恐らく native アプリで Direct3D を使った場合に匹敵するくらい の速度が出てると思う。結果、多くのゲームに関してはブラウザ内アプリとnative アプリで 速度差がほとんど出ないと思われる。なぜなら、mainプログラムでは描画に関しては 全く何もやることが無いといっても過言ではないのに、大抵のゲームでは描画以外の 計算は物凄く軽いから。 人体の間接などを滑らかに描画するボーンの演算ですら、プログラマブルな Vertex Shader により GPUで行えるし、パイプライン化されているので相当重い計算でも、描画速度には ほとんど影響を与えない可能性が高い。 61 名前：L mailto:sage [2019/04/03(水) 18:27:34.57 ID:+15LYwzR.net] >>1 一応、作ってみたものを公開しておくので見てね。 地形データの WebGL によるワイヤーフレーム描画のデモ： nowsmartsoft.atwebpages.com/demo_land_WebGL/index.html 地形データの WebGL によるポリゴン描画のデモ： nowsmartsoft.atwebpages.com/demo_land_Polygon/index.html まだそんなに高速化は施してないので、もっと高速になる余地がある。 例えば、頂点データはフレーム描画毎にコピーしてしまっている。 頂点カラーも 0〜255 の BYTE 形式から、0.0〜1.0 の float 形式に wasm のコードで変換している。それらは本来は不要なものだけど、 今回は修正せずに見切り発車的にそのまま公開した。 それと、実際にやってみると、時々ガタガタと止まった感じがするけど、 それは、JavaScript の GC (Garbage Collection) が時々起動してしまって いるからだと思う。 wasm を使っていても、グラフィック描画のためにはどうしてもJavaScript は使わざるを得ないので、いつのまにかこうなってしまっていた。もう ちょっと工夫すれば、GC の発生を抑えることが出来るんではないかと思っている。 今回、WebGL を始めて使ったので、その際、ネットにあったサンプルをそのまま 使ってみている部分があり、その結果、OnDraw() 関数の中で TypedArray 配列 を new したりしてしまっている。それが一番の原因ではないかと思われる。 62 名前：デフォルトの名無しさん [2019/04/04(木) 10:51:29.71 ID:4Pg7/9jZ.net] WebGL https://tech.griphone.co.jp/2018/11/05/js-on-unity-webgl/ 63 名前：L [2019/04/04(木) 16:12:58.84 ID:LemJlt/3.net] >>1 Voxel space 風の3D表示をやってみたので見てね v(⌒▽⌒)У nowsmartsoft.atwebpages.com/demo_land_Voxel/index.html 64 名前：L mailto:sage [2019/04/05(金) 16:28:39.72 ID:xS705/9I.net] >>1 一応、スマホのタッチ入力によるWindowの移動やサイズ変更に対応してみたよ。 実機では一度も試してない(スマホ持ってない)ので動作報告あったらうれしいな： nowsmartsoft.atwebpages.com/ 65 名前：デフォルトの名無しさん mailto:sage [2019/04/05(金) 19:37:10.55 ID:IRsRTegS.net] すまん 正直広告がうざくて萎える 66 名前：L mailto:sage [2019/04/05(金) 19:50:46.66 ID:xS705/9I.net] >>62 PCでテストしてたら広告が出てこなかったかが気づかなかったけど、 Chromeのスマホモードで見てみたら、非常に問題ある位置に広告が出て 来ることが分かって今、めちゃくちゃ対処に困ってるょ。 位置を変える方法が見つからない・・・。Ninja Analyzerのものなのか、 ZettaHosting (atwebpages) のものなのかも分からない。 67 名前：デフォルトの名無しさん mailto:sage [2019/04/06(土) 02:27:57.47 ID:/MkWaZI9.net] >>62 広告、消えたよ。 68 名前：デフォルトの名無しさん mailto:sage [2019/04/06(土) 02:53:07.58 ID:/MkWaZI9.net] 広告、最初の導入ページには残ってるけど、各demoページでは消えてるらしい。 69 名前：デフォルトの名無しさん mailto:sage [2019/04/06(土) 03:17:09.51 ID:d3+s3AWp.net] レイトレーシングやってほしい 70 名前：L [2019/04/06(土) 12:27:52.58 ID:c/dtyqqS.net] >>1 地形生成のアルゴリズムを変えて、山っぽくしてみたよ。 荒涼とした山肌に、心休まる緑が点在するょ： nowsmartsoft.atwebpages.com/demo_Mountain/index.html 地形データは、起動後に自分で生成してるょ。 71 名前：L [2019/04/06(土) 12:55:17.11 ID:c/dtyqqS.net] Windows に最初から入ってるブラウザの IE では残念ながら見られないので FireFox か Chrome を入れてね。FireFox が速いみたい。 72 名前：デフォルトの名無しさん mailto:sage [2019/04/06(土) 16:08:04.28 ID:DWbJNRMu.net] ソースはいつ公開しますか？ 73 名前：デフォルトの名無しさん mailto:sage [2019/04/06(土) 16:11:15.39 ID:d06Kh2dO.net] >>69 応援してくれる人が多そうなら公開するかなぁ。 74 名前：デフォルトの名無しさん mailto:sage [2019/04/06(土) 16:20:00.28 ID:c/dtyqqS.net] 言い忘れてたけど、これは新しい言語 C++ nex のコンパイラ nwsc と 新タイプの統合開発環境のデモ的なものなので、そっちを応援してくれる 人が増えそうならデモや TOOLKIT(NWSTK) のソースを公開しようかな と思ってる。 75 名前：デフォルトの名無しさん mailto:sage [2019/04/06(土) 16:29:49.76 ID:c/dtyqqS.net] ちなみに、おいらは引きこもりなのでお金が無いんだょ。 76 名前：デフォルトの名無しさん [2019/04/07(日) 16:35:02.31 ID:e/tK/Nk6.net] >>1 海外の掲示板などでに出ていた Wasm が VM(Virtual Machine)として、 JVM (Java の VM) や Flash の VM より優れていると考えられている点の 内、今思い出せるものと書いておく： 1. JVM や FlashVM は、それぞれ一社のものだが、Wasm の VMは、 　 FireFox, Chrome, Apple などの多数のベンダーの合議により 　 決まった公開仕様である事。例えば、Googleが自分勝手に 　何かしようとしても、FireFox などがそれに逆らうことが出来る(?) 　ため、問題が生じにくい、と書いている人がいた。 2. 実際、第三者的な組織から、Lucet, wasmer, wasp, wasabi, 　binaryen(元々有ったが) など色々出てきているらしい。 3. そもそも、JVM は、設計が、ほぼ Java 専用になっていて、例えば、 　 変数の型などのMeta情報が Java 専用だったり、GCを前提とした 　 仮想コード、仮想マシンになっているらしい。その結果、 　 FrontEnd に C/C++ などを含めた広く一般的な言語が対応 　するのは難しいらしい。つまり、一般的な言語の BackEnd 　としては無理があるらしい。 4. JVM は、セキュリティー上の問題がある、とされていた。 　なんでも、ブラウザと JVM の境界線上で問題が生じることが多いらしい。 　クラッカーは、ブラウザと JVM の間のセキュリティー上の約束事や 　(仕様上の)意思疎通の齟齬(?)を見つけて何かやってくるのか知れない。 5. JVM はブラウザの拡大率を変更しても追従しにくいが、wasm だと 　追従しやすいらしい。 77 名前：デフォルトの名無しさん [2019/04/07(日) 16:59:47.19 ID:e/tK/Nk6.net] >>73 6. JVMを使うには、使いたい人が自分で JRE をインストールする必要があったが、 　wasm だと、IE以外の新しいバージョンの主要なブラウザなら全て最初から 　対応している事。そのため、多くの人に届きやすいプラットフォームである。 7. Java(Applet)やFlashは既に、数年後にはChromeからは実行できなくなる予定で 　あるが、wasm は逆に、Flash(Adobe) までもが backend として対応すると 　宣言している。 78 名前：デフォルトの名無しさん [2019/04/08(月) 18:03:38.12 ID:pvsbwYPC.net] >>1 ウェブ・アプリをローカルで実行したい場合に参考になりそうなもの ・Google Gears ・PWA = Progressive Web Apps ・WASI = Wasm System Interface ・blob, fetch, XHR 79 名前：デフォルトの名無しさん mailto:sage [2019/04/08(月) 18:17:36.29 ID:N9bPT30p.net] >>75 ・Electron, Chronium ---> ブラウザの枠を超えた Window が出せる。 ・Chrome Apps (廃止) 80 名前：L [2019/04/21(日) 17:21:20.81 ID:1Wk1O9hC.net] nowsmartsoft.atwebpages.com/ ↑ demo1 の EditWidget が、MobileのOn-Screen Keyboardに対応して、 PCでも日本語の入力が出来るようになったよ。 「今まで出来なかったの?」って？　ブラウザのせいだよ〜！ 81 名前：デフォルトの名無しさん [2019/05/18(土) 16:05:19.62 ID:dUyfgnsN.net] >>1 ブラウザ上だとタイトルバーとURLアドレス欄で画面に無駄が消費されてしまう問題は、 「WebView」のようにアプリの内部にブラウザを埋め込んでしまえばいい。 それを使えば、キャッシュされてしまう問題も回避できるかもしれない。 82 名前：デフォルトの名無しさん mailto:sage [2019/05/18(土) 17:12:47.28 ID:4C+see96.net] google「そう思ってDesktopPWAって枠組み用意しときました」 83 名前：デフォルトの名無しさん mailto:sage [2019/05/18(土) 17:59:00.81 ID:81A5W8ik.net] PWAの作り方は良く分からないけど、アプリの審査がいらないのは 子供達にも向いてるかもね。 84 名前：デフォルトの名無しさん mailto:sage [2019/05/18(土) 18:07:19.99 ID:dUyfgnsN.net] でも、https必須らしいので、年間維持費がかかりそう。 ・登録料無料のhttpsを使うのには独自ドメインが必須らしい。 ・サブドメン方式でhttps使う場合は探した限り無料で出来るレンタルサイトはない。 85 名前：デフォルトの名無しさん mailto:sage [2019/05/18(土) 18:09:37.44 ID:4C+see96.net] デスクトップPWA https://developers.google.com/web/progressive-web-apps/desktop 日本語版ないからクロムの翻訳機能使ってくれ 86 名前：デフォルトの名無しさん mailto:sage [2019/05/19(日) ] [ここ壊れてます] 87 名前：01:51:24.70 ID:Z8fjcguw.net mailto: 世の中なんでも結局は金金金か!! [] [ここ壊れてます] 88 名前：デフォルトの名無しさん [2019/05/19(日) 11:00:10.59 ID:NVj9TkQF.net] ほんそれ 89 名前：デフォルトの名無しさん mailto:sage [2019/05/19(日) 11:10:01.48 ID:CRfL0LbB.net] github pagesあるやんけ 90 名前：デフォルトの名無しさん mailto:sage [2019/05/19(日) 11:28:02.61 ID:sA5/dcdL.net] netlifyあるやんけ 91 名前：デフォルトの名無しさん mailto:sage [2019/05/19(日) 12:52:29.06 ID:z0IbZyMD.net] https://yutakaaoki.github.io/ ↑良く分からんけど、ひとまず https で wasm のデモ・ページ作ってみたで〜 92 名前：デフォルトの名無しさん mailto:sage [2019/05/19(日) 17:06:00.28 ID:+a0Gc7NS.net] wasm ていう単語見るたびにいつもこいつが頭に浮んでしまう https://ja.wikipedia.org/wiki/%E3%82%8F%E3%81%95%E3%81%8A#/media/File:Wasao.jpg 93 名前：デフォルトの名無しさん mailto:sage [2019/05/19(日) 17:57:24.92 ID:pfNk1t/q.net] twitter の #wasm タグ、今年に入ってから急激に活発になってる気がする。 去年は数週間に一回の書き込み、みたいな感じだったようだけど、今月なんかは 数十分に一回の書き込み位になってる。求人広告まで沢山出だして、wasm技術者 を探す第一回目の会議(?)みたいなものまで出てきたらしい。 94 名前：デフォルトの名無しさん mailto:sage [2019/05/19(日) 18:01:09.59 ID:pfNk1t/q.net] ITの世界では、良く分からないところで誰かが商売に結び付けて大儲けし出す 事が多かったから、先に動こうとしてるんだろうか。クラウドとかも本当に メリットがあるかどうかおいておいて、ブームのようにして大金が動いている。 95 名前：デフォルトの名無しさん mailto:sage [2019/05/19(日) 19:04:28.84 ID:pfNk1t/q.net] The web always wins. # ウェブはいつも勝つ と書いてる人がいた。 面白い見方だな。 96 名前：デフォルトの名無しさん mailto:sage [2019/05/19(日) 19:11:38.67 ID:pfNk1t/q.net] 「Wasmで最も重要なのは、Secutrityの面である」 と書いている。WasmはSandBox内で動作しているので安全だと。 なるほど、「Webがいつも勝つ」一つの原因は、安全性が高いことなのか・・・。 そういえばブラウザ上で動いている限り、まずウイルス感染しないな・・・。 そうか、スマホが流行る原因も、マシンのトラブルが少ないからかもしれないな。 PCだとOSが不安定になって使えなくなることが多いのと対照的。 なるほどなぁ・・・。 97 名前：デフォルトの名無しさん mailto:sage [2019/05/19(日) 19:25:02.22 ID:pfNk1t/q.net] https://byterot.blogspot.com/2019/05/why-webassembly-matters.html ↑ ここにそのことが書いてあるよ。 98 名前：デフォルトの名無しさん [2019/05/20(月) 14:01:02.69 ID:pxNnSyNl.net] 上手くいけば、AppStore登録の月額利用料金が開発者にかからないでiPhone/iPad ようのアプリが作れるかも知れない。 iOSでも、去年の3月くらいにSafariもPWAに対応したらしいし、Chromeも使える。 となると、ウェブアプリをWasmで作っておいて、PWAを使えば普通のアプリの ようにHome画面にアイコンを登録できるし、実行時にアドレスバーも出さなく できる。Safariで駄目な場合は、iOS用のChromeもある。 99 名前：デフォルトの名無しさん mailto:sage [2019/08/11(日) 11:35:01.71 ID:UiwR3IAb.net] wikiで宣伝はアカンでよ 100 名前：デフォルトの名無しさん [2019/09/12(木) 22:35:47.25 ID:Uy9QyXie.net] >>40 トンでもねぇ色彩センスｗｗｗ さすがに草不可避ｗｗｗｗｗ 101 名前：デフォルトの名無しさん [2019/09/13(金) 10:13:11.78 ID:wKEqF87n.net] NG かどうか試してみる nowsmartsoft.atwebpages.com/ 102 名前：デフォルトの名無しさん mailto:sage [2019/11/18(月) 16:14:21.51 ID:Vzii0sJA.net] C++をソースとするwasmとPWA(Progressive Web Application)化できる ことを実際に確認することが出来た。Chrome+Win7の組み合わせで wasmアプリをローカルにインストールできてデスクトップにアイコン を作成することができる。アイコンをクリックすると、ある種の nativeアプリの様な雰囲気で起動できる。 103 名前：デフォルトの名無しさん [2019/11/18(月) 16:14:54.06 ID:Vzii0sJA.net] C++をソースとするwasmをPWA(Progressive Web Application)化できる ことを実際に確認することが出来た。Chrome+Win7の組み合わせで wasmアプリをローカルにインストールできてデスクトップにアイコン を作成することができる。アイコンをクリックすると、ある種の nativeアプリの様な雰囲気で起動できる。 104 名前：デフォルトの名無しさん [2019/11/18(月) 16:15:25.78 ID:Vzii0sJA.net] age 105 名前：デフォルトの名無しさん [2019/11/18(月) 19:53:09.11 ID:Vzii0sJA.net] https://yutakaaoki.github.io/pwa-wasm-demo1-B/ ここに wasmアプリが置いてあるが、Chromeで訪れると アドレスバーの右の方に 「インストール」という文字が現れ、しばらくすると、○で囲った + 記号に変わる。 そこをクリックすると、PWAとしてローカルPCにインストールできる。 または、右上の縦に3つの点があるボタンを押してみると、 『「PWA NWSTK」をインストール...』 というメニュー項目が出来ているので、そこをクリックしても同じ機能が働く。 106 名前：デフォルトの名無しさん mailto:sage [2019/11/20(水) 09:18:48.73 ID:Zp1gFICP.net] Mozilla、Fastly、Intel、Red HatがWebAssemblyをターゲットに「The Bytecode Alliance」 https://news.mynavi.jp/article/20191118-925267/ 107 名前：デフォルトの名無しさん [2019/11/20(水) 12:43:45.81 ID:vKT/00gf.net] >>101 https://yutakaaoki.github.io/ ここにおいてあるものは、全部PWAに対応してみた。 Windowsならインストールできると思う。 AndroidやiPhoneなどでも出来るか試して欲しい。 108 名前：デフォルトの名無しさん mailto:sage [2019/11/20(水) 12:51:31.62 ID:vKT/00gf.net] >>103 まだ本当の意味でのソースではないけど、 https://github.com/YutakaAoki/YutakaAoki.github.io 以下の https://github.com/YutakaAoki/YutakaAoki.github.io/tree/master/demo1 などに index.htmlや、*.wasm, *.js, manifest.json などは置いてある。 wasmアプリの作り方、PWAの作り方、wasmとPWAの組み合わせ方、に興味のある人は 参考までに。 109 名前：デフォルトの名無しさん [2019/11/20(水) 13:48:41.27 ID:pcdm34G4.net] で、これで何ができるの？ 110 名前：デフォルトの名無しさん mailto:sage [2019/11/20(水) 14:49:34.93 ID:vKT/00gf.net] >>105 ・セキュリティーが凄く強いアプリ。信用できないようなサイトからインストール 　しても、レジストリには読み書きできないし、システムフォルダや他のアプリの 　フォルダには、人間がマウスやキーボードなどから実際に指示しない限りは書き込めないし、 　読み込むことも出来ない。変な場所にインストールされたり、スタートアップ起動などに 　勝手にされることも無い。 ・アプリの体験版をインストールすることなく、普段のウェブ閲覧の延長線上に 　試せるのでユーザーは遊び半分で気軽に試すことが出来る。また、掲示板などから 　リンクを張った先がすぐにアプリとなっている。その後、デスクトップや 　ホーム画面にアイコンを追加し、単独アプリの用に振舞うことが出来る。 ・なぜか全てがウェブに移行するようになっており、「いつもウェブが勝つ」。 ・iPhoneやiPad用のアプリが無料で開発出来る可能性がある。今までは、 　それらをターゲットに開発するには、Mac実機がどうしても必要となり、 　かつ、AppStoreに登録しないと配布することも出来なかったが、AppStoreは 　年会費も必要で、生涯にわたってずっとコストが掛かかり続けていた。 ・ブラウザが互換性を保つので、PCで試して動けば、AndroidやiPhoneでも 　近い動作になる可能性が高い。 ・Chrome, FireFox, Safari, Edge, Opera なども wasm に対応している 　（ただし、ツールキット側がテストはしておく必要はある。）。 111 名前：デフォルトの名無しさん mailto:sage [2019/11/20(水) 15:00:00.13 ID:AFHj5vY6.net] Java Appletと何が違うの？ 112 名前：デフォルトの名無しさん mailto:sage [2019/11/20(水) 15:00:41.97 ID:vKT/00gf.net] >>106 【追加】 ・画面が、Ctrl+ +, Ctrl+ -で好きなように拡大縮小できるので、近視や老眼などで 　目が悪い人でも好きな文字の大きさで読むことが出来る。それがWebアプリでも、 　PWAアプリ化したものでも出来る。 ・ツールキットも含めてサイズがとても小さい。ブラウザさえ使える状態であれば、 　DLLやランタイムのインストールが全く不要。demo1は、*.htmlや*.js, *.wasm全て 　合わせて　150KB、demo-Mountainは、153KB。JavaランタイムもQtランタイムも 　MFCのDLLも何も要らない。 113 名前：デフォルトの名無しさん mailto:sage [2019/11/20(水) 15:11:39.18 ID:vKT/00gf.net] >>107 ・Java Appletは、訴訟トラブルのせいか、ChromeもFireFoxが対応しなくなって 　しまった。 ・wasm は、C++ が使えるので、GC を使わないプログラムが出来、 　メモリが多く使うウェブアプリを作ろうとした場合に、体感速度が非常に 　違ってくる。Javaだと、GCが走ると一分間停止するようなことがあった。 　wasm と C++ の組み合わせだと、このようなことが起きないので、 　プログラムした通りの一定の速度が維持できる。 ・Java は、逆コンパイルするとほぼ元ソースに戻せてしまう性質があった。 　それを防ぐには曖昧化などが必要であり、手間や（ツール購入の）コスト 　が掛かった。曖昧化するためにコンパイル時間が増大した。 ・Javaが有料化したという話がある。これについては諸説あるのでよく分からない。 114 名前：デフォルトの名無しさん mailto:sage [2019/11/20(水) 15:14:47.33 ID:vKT/00gf.net] >>109 ・Java Applet より起動が速い。 115 名前：デフォルトの名無しさん mailto:sage [2019/11/20(水) 15:18:23.10 ID:vKT/00gf.net] >>110 ・wasm内部からは、EM_ASM()構文などで自由にJavaScriptが使えるので、 　XHRやfetch()などを自由に使ったAjax流儀のプログラムが行える。 ・簡単に HTML 要素と共存できる。 ・ブラウザの画面を拡大したような場合に、JavaAppletだと追従するのが 　難しく、できないことはないがタイムラグが生じ易かった。 　Ctrl+ + での拡大も、JavaApplet 部分だけは置いていかれるようなことに 　なったので、対応したければ独自に工夫する必要があった。 116 名前：デフォルトの名無しさん mailto:sage [2019/11/20(水) 15:54:16.93 ID:vKT/00gf.net] >>111 ・iOSでは、もともとJavaが使えないと聞いている。 ・Androidは、基本がJavaではあるが、実際には、Google独自実装となってしまって 　おり、　Sun/OracleのJavaで昔からの標準の Swingなどを使ったものは動か 　せない。これが訴訟問題になった最も大きな原因の一つらしい。 117 名前：デフォルトの名無しさん mailto:sage [2019/11/20(水) 19:15:30.47 ID:vKT/00gf.net] >>108 ツールキットに用意されて無い機能を追加したい場合、JavaScript として書けば よいのであらゆるプラットフォームへ迅速に対応できる。 他のツールキットの場合は、iOS/Andorid/Win/Mac/Linux など用にそれぞれ 書く必要がある。 118 名前：デフォルトの名無しさん mailto:sage [2019/11/21(木) 15:21:55.41 ID:0fDEV4Sz.net] PWAは、頻繁にアップデートしたいアプリに向いている。 119 名前：デフォルトの名無しさん mailto:sage [2019/11/21(木) 16:02:31.75 ID:0fDEV4Sz.net] PWA化後のデスクトップのアイコンが、物凄くいろいろなことをやっても古いまま 全く更新できなく立った。 どうしよう。 120 名前：デフォルトの名無しさん mailto:sage [2019/11/24(日) 12:10:37.33 ID:Tuk9Q29U.net] Safariで動いていたよ。 ホーム画面への追加のボタンも出ていた。 121 名前：デフォルトの名無しさん mailto:sage [2019/11/26(火) 01:08:23 ID:t9NWfcZD.net] PWAだとストアの審査が要らない。通常、iPhoneのアプリは、iPhone流の インターフェースを持って無いと審査に通らない（Appleに脅威をもたらすと 考えられるだけで審査に通らない可能性もある。YahooゲームやLINEゲームが AppleにBANGされた歴史もある。）。PWAの場合はそんなことはなく自由 なので、PCやAndroid、iPhoneで完全に同じインターフェースにすることもできる。 そうすれば、開発も楽になる。 122 名前：デフォルトの名無しさん [2019/11/26(火) 01:16:04 ID:t9NWfcZD.net] PWAの場合、ブラウザとnative風アプリの操作感が統一できるのでユーザーは 安心して使える。WindowsとiPhoneで同じインターフェースのアプリになる。 今まではAppleの審査のためにそのようなことは出来なかった。Windowsに慣れて いるが、iPhoneを使っている人にはWindows流インターフェースの方が好まれる 可能性があるにも関わらず。 AppleはiPhoneらしさを強要するが、逆にどのプラットフォームでも同じ操作感 であることには、開発者のみならずユーザーにもメリットがある。 123 名前：デフォルトの名無しさん mailto:sage [2019/11/26(火) 01:22:29 ID:t9NWfcZD.net] Appleは審査が厳しいが、自社がそのアプリが出てくると(競争に負けて)業績が 落ちそうだと判断するともっともらしい理由を付けて審査を通さなかったり、 長く時間をかけて手間をかけさせたりする可能性がある。PWAだとその心配が無い。 ただし、PWA専用のダウンロードサイトを作ろうとすると、そのサイト自体に 規制がかかったことがあるそうだ。Appleはまるで中国や北朝鮮のようだ。 124 名前：デフォルトの名無しさん [2019/11/26(火) 01:24:58 ID:t9NWfcZD.net] >>118 https://blogs.adobe.com/japan/web-the-death-of-the-standalone-app-and-what-comes-next/ 1. より一貫したデザインを提供できます。3つの異なるデザインをiOS、Android、 　レスポンシブサイトとそれぞれ用意する代わりに、PWAの場合はすべての環境に 　対応する1つのアプリをデザインします。これはアプリ開発にかかる時間を短縮 　するだけでなく、デザインの一貫性にも繋がります。デザイナーは、1つのガイド 　ライン作成に集中でき、より有意義に時間を使うことができます。 2. 複数チャネルの組み合わせが容易です。ユーザーは、どんなデバイスから 　アクセスしても一貫性のある体験を求めています。あるデバイスで使い始め、 　他のデバイスに切り替えて再開することは自然な動作です。帰宅途中の通勤電車で 　ショッピングカートに目に付いた商品を入れたあと、自宅のPCからきちんと商品を 　確認して購入手続きを完了できるような機能はどうでしょうか？PWAであれば 　最小限の投資で実現できるでしょう。 125 名前：デフォルトの名無しさん mailto:sage [2019/11/27(水) 01:56:02.82 ID:T7KqQ5kC.net] 独自GUIを乗せることで使い勝手で他のアプリと差別化できるかも。 126 名前：デフォルトの名無しさん mailto:sage [2019/11/27(水) 01:59:18 ID:T7KqQ5kC.net] >>121 今までなら独自GUIはAppleの審査に落ちる可能性があったが、PWAなら 自由になる。それでAppleの伝統を超えた使い勝手のGUIシステムを備えた アプリを提供できれば他のアプリと差別化できる可能性が出てくる。 127 名前：デフォルトの名無しさん mailto:sage [2019/12/06(金) 02:20:17 ID:ZSKvcFXv.net] Webアプリの場合、URLのパラメータによって、プレイ中のゲーム画面 にいきなりリンクすることが出来るようになる。これで、ゲーム画面の「シェア」 が出来る。例えば、RPGで経験値、体力、魔力、所持アイテム、地図上の座標、 タワーの階層、的の位置などを全部URLのパラメータに直してしまえば、 そのシーンを他の人にシェアして、そこからプレイし始めてもらえる。これは、 native ゲームにはなかった特徴。blob や base64 による URL 化などを使えば データをURL化することは難しくはない。URLが長くなりすぎる問題はある かも知れないが。 128 名前：デフォルトの名無しさん mailto:sage [2019/12/06(金) 02:24:38 ID:ZSKvcFXv.net] >>123 RPGなどでセーブデータが大きすぎてURL化に適さない場合は、 サーバー上にシーンを圧縮セーブしておいて、その識別番号をシェアする手もある。 ユーザーが各自で無料ストレージサービスを借りて、そこにセーブしておいて、 それをシェアする手もある。 129 名前：デフォルトの名無しさん mailto:sage [2019/12/06(金) 02:45:16 ID:ZSKvcFXv.net] インストール型のゲームだと、URLを書くだけで一瞬で動いている場面を他人が 見ることはできない。しかし、ウェブゲームだとそれが出来る。ただし、 この場合、ゲームサイズを小さく作ることが重要になる。その意味で、 サイズがコンパクトになるwasmと、コンパクトなサイズのゲームライブラリが 重要となる。 130 名前：デフォルトの名無しさん mailto:sage [2019/12/06(金) 02:50:45 ID:ZSKvcFXv.net] ゲーム全体のデータが巨大だとしても、1つのシーンを見るために必要なデータは ごく少ない。その意味で、プログラム部分(コード)部分のサイズさえ小さければ、 ポリゴンやテクスチャやマップのデータは巨大でも良い。大部分のデータは サーバー上に置いて置けばいいのだから。これで、ゲームシーンを快適に シェアできるようになる。これが、ブラウザゲームならではの新しい価値。 131 名前：デフォルトの名無しさん mailto:sage [2019/12/06(金) 02:56:52 ID:ZSKvcFXv.net] インストール型ゲームでも動いているゲーム画面をシェアすることも不可能ではないが、 それには、同じゲームをインストールすることが前提となる。 一方、ブラウザゲームでは、例えば、2ch/5ch にリンクアドレスのURLを 入れるだけで、一秒後には、そのシーンを見られて、プレイも出来る。 132 名前：デフォルトの名無しさん mailto:sage [2019/12/08(日) 12:57:08.43 ID:hM3Qn2JU.net] テニスゲーム: https://yutakaaoki.github.io/demo_tennis/ 133 名前：デフォルトの名無しさん mailto:sage [2019/12/10(火) 08:37:25 ID:jvY2kg1T.net] WebAssemblyがW3Cの勧告に到達。「WebAssembly Core Specification 」「WebAssembly Web API」「WebAssembly JavaScript Interface 」の3つ https://www.publickey1.jp/blog/19/webassemblyw3cwebassembly_core_specification_webassembly_web_apiwebassembly_javascript_interface_3.html 134 名前：デフォルトの名無しさん mailto:sage [2019/12/10(火) 14:13:47.04 ID:uv70k2ai.net] ブラウザの中でのwasmは、現状、ローカルファイルシステムには自由にはアクセス できないが、その場合、mongoose.exe, Ruby, Python などでローカルサーバー を起動すれば、ブラウザ内のwasmプログラムから cgi プログラムを起動できるので ローカルOSのAPIは何でも利用できるようになるので、ローカルファイルシステムにも 自由に読み書きできるようになる。もし、このサーバープログラムが十分に高速なら、 DirectInput などを利用してフォースフィードバック付きのジョイスティックも wasmゲームから使えるようになる。 135 名前：デフォルトの名無しさん [2019/12/10(火) 14:26:39.38 ID:48kVELqA.net] ローカルサーバーをnode.jsで書くの流行ったな 136 名前：デフォルトの名無しさん [2019/12/10(火) 14:28:32.93 ID:uv70k2ai.net] >>130 ちなみに、mongoose.exe は、BSD/MIT 系ライセンス。 サイズは100MBを超えてしまっているが、Luaを無効にしてソースから ビルドし直すと、すると、サイズが1MBくらいになる。 137 名前：デフォルトの名無しさん mailto:sage [2019/12/10(火) 14:36:55.20 ID:uv70k2ai.net] mongoose.exe + CGIプログラム を配布すれば、ある種の Java仮想マシンJVMの 代替になる。JavaのSwingでGUIアプリを作る場合も JVM のインストールが必要に なるが、それが、mongoose.exe + CGI プログラム。しかし、JVMよりサイズが 小さいのでインストールが容易。 138 名前：デフォルトの名無しさん mailto:sage [2019/12/10(火) 16:23:17 ID:uv70k2ai.net] >>129 それとは直接関係ないけど、海外のサイトで昨日、目にしたのは、Googleは、 MicrosoftからOSの制御力を奪おう(無くそう)としているという見方。 PWAを発案したのもGoogle。 IntelやMozilla、RedHat、Fastlyも、別方向でwasmを拡大しようとしているので、 恐らく一社がコントロールしようとしてもwasmの勢力拡大は止められない 思われる。PWAに関しては微妙で Appleは渋々対応している感じでは有るが、 対応しないとむしろ不利になると経営判断している可能性もある。 分からないが。 139 名前：デフォルトの名無しさん [2019/12/12(木) 19:22:14.47 ID:Z8SHCwDj.net] 5chの広告に表示されている「ビビッドアーミー」などのG123なるものを やってみたら、少なくともWebGLが、昔のPC-9801の最後期レベルよりも高速な グラフィックをかけることがはっきり分かった。と言うか恐らく、初期のPlayStation よりは緻密で速いと思う。 また、Fragment Shader は再帰的関数呼び出しでも何でも書けるようで、 レイトレーシングでも何でも出来ることがわかった。つまり、WebGLを 使ったブラウザゲームは、レイトレーシングやパストレーシングレベルの 3Dグラフィックを使ったものでも何でもできるようだ。 また、Chrome には、FileSystem API だけではなく、native file systema API なる 実験的拡張がある。これはデフォルトでは disable だが、enable にすれば、 本当に native のファイルシステムのディレクトリ内のファイル一覧を取得したり 自由に読み書きできるようになるらしい。 Wasmもある程度速いし、もはや、nativeアプリは要らないかも。 Webアプリは、Win/Mac/Linux/iOS/Android 全てに共通で、 「1バイナリ」で Write Once, Run Anywhere がほぼ実現しているので ブラウザをOSとみなした場合、WindowsやiOS, Android のどれよりも シェアが大きい。これは native アプリの時代が終焉するかもしれない。 140 名前：デフォルトの名無しさん mailto:sage [2019/12/12(木) 19:26:35.52 ID:Z8SHCwDj.net] >>135 訂正。 使ったGPUは、エントリーモデルの(ビジネス用の)劇安 Intel CPU に内臓の Intel HD グラフィックのもの。それでさえ、初期 PlayStation レベルを 超えたグラフィックが描けているようだった。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef