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

L · 2019/01/15(火) 19:50:48.94

タイトル通り。

・canvas への描画が可能なことを確認。
・emscripten_sleep() でその場で停止できることを確認。
・付属の emrun や mongoose などで Local Server を作れば、local だけで
　wasm の起動が出来ることを確認。
・mongoose からは、cgi も起動でき、XmlHttpRequest()でローカルファイルを
JSから読み込め、cgi も自由に起動できることを確認。
・ローカル・ファイルアクセス、clipboard の読み書きの他、Local OS の
　全ての機能を自由にできる可能性有り。
・これを使えば、Java の JVM に変わる新たなローカル仮想環境ができる。

**デフォルトの名無しさん** · 2019/04/01(月) 17:34:37.66

>>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-interface/
# 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/

**デフォルトの名無しさん** · 2019/04/02(火) 01:15:22.26

>>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/

**デフォルトの名無しさん** · 2019/04/02(火) 02:11:54.11

何度もあらわれては消えていく"write once run anywhere"のコンセプト・・
はてさてどうなりますやら

**デフォルトの名無しさん** · 2019/04/02(火) 11:07:57.88

wasabiならもっと流行るはず

**デフォルトの名無しさん** · 2019/04/02(火) 13:50:43.70

>>53
C#も、XamarineもUnityもその思想をやろうとしてると思うけど。

**デフォルトの名無しさん** · 2019/04/03(水) 01:36:20.38

「C# Run Anywhere」でGoogleって、海外のサイトを見ていたら、
C#は設計上は、仮想マシン上で動くことになってるけど、MS公式の
Runtimeで、大体動くのは、大体WindowsとMacだけで、実質、
Windows向けだと書いている人がいた（それが本当かどうかは分からないけど）。
少なくとも、以下のようなことは大体正しいのではないかと思う。
・MSにとって、C#がマルチプラットフォームになることはマイナスである。
・MSはC#をRun anywhere にすることには力を入れてないか、目指していない。

L · 2019/04/03(水) 15:29:38.83

>>43
結論から言うと、ゲームに置いては、ブラウザ内アプリと native アプリのどちらで
組むかは、速度性能で選ぶ必要がなくなりそうだ。理由は以下の通り：

今回、試しに描画部分をWebGLに変えてみたら、劇的に高速になった。
詳しくは分からないが、恐らく native アプリで Direct3D を使った場合に匹敵するくらい
の速度が出てると思う。結果、多くのゲームに関してはブラウザ内アプリとnative アプリで
速度差がほとんど出ないと思われる。なぜなら、mainプログラムでは描画に関しては
全く何もやることが無いといっても過言ではないのに、大抵のゲームでは描画以外の
計算は物凄く軽いから。
人体の間接などを滑らかに描画するボーンの演算ですら、プログラマブルな Vertex Shader
により GPUで行えるし、パイプライン化されているので相当重い計算でも、描画速度には
ほとんど影響を与えない可能性が高い。

L · 2019/04/03(水) 18:27:34.57

>>1
一応、作ってみたものを公開しておくので見てね。

地形データの WebGL によるワイヤーフレーム描画のデモ：
http://nowsmartsoft.atwebpages.com/demo_land_WebGL/index.html

地形データの WebGL によるポリゴン描画のデモ：
http://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 したりしてしまっている。それが一番の原因ではないかと思われる。

**デフォルトの名無しさん** · 2019/04/04(木) 10:51:29.71

WebGL
https://tech.griphone.co.jp/2018/11/05/js-on-unity-webgl/

L · 2019/04/04(木) 16:12:58.84

>>1
Voxel space 風の3D表示をやってみたので見てね v(⌒▽⌒)У
http://nowsmartsoft.atwebpages.com/demo_land_Voxel/index.html

L · 2019/04/05(金) 16:28:39.72

>>1
一応、スマホのタッチ入力によるWindowの移動やサイズ変更に対応してみたよ。
実機では一度も試してない(スマホ持ってない)ので動作報告あったらうれしいな：
http://nowsmartsoft.atwebpages.com/

**デフォルトの名無しさん** · 2019/04/05(金) 19:37:10.55

すまん
正直広告がうざくて萎える

L · 2019/04/05(金) 19:50:46.66

>>62
PCでテストしてたら広告が出てこなかったかが気づかなかったけど、
Chromeのスマホモードで見てみたら、非常に問題ある位置に広告が出て
来ることが分かって今、めちゃくちゃ対処に困ってるょ。
位置を変える方法が見つからない・・・。Ninja Analyzerのものなのか、
ZettaHosting (atwebpages) のものなのかも分からない。

**デフォルトの名無しさん** · 2019/04/06(土) 02:27:57.47

>>62
広告、消えたよ。

**デフォルトの名無しさん** · 2019/04/06(土) 02:53:07.58

広告、最初の導入ページには残ってるけど、各demoページでは消えてるらしい。

**デフォルトの名無しさん** · 2019/04/06(土) 03:17:09.51

レイトレーシングやってほしい

L · 2019/04/06(土) 12:27:52.58

>>1
地形生成のアルゴリズムを変えて、山っぽくしてみたよ。
荒涼とした山肌に、心休まる緑が点在するょ：
http://nowsmartsoft.atwebpages.com/demo_Mountain/index.html

地形データは、起動後に自分で生成してるょ。

L · 2019/04/06(土) 12:55:17.11

Windows に最初から入ってるブラウザの IE では残念ながら見られないので
FireFox か Chrome を入れてね。FireFox が速いみたい。

**デフォルトの名無しさん** · 2019/04/06(土) 16:08:04.28

ソースはいつ公開しますか？

**デフォルトの名無しさん** · 2019/04/06(土) 16:11:15.39

>>69
応援してくれる人が多そうなら公開するかなぁ。

**デフォルトの名無しさん** · 2019/04/06(土) 16:20:00.28

言い忘れてたけど、これは新しい言語 C++ nex のコンパイラ nwsc と
新タイプの統合開発環境のデモ的なものなので、そっちを応援してくれる
人が増えそうならデモや TOOLKIT(NWSTK) のソースを公開しようかな
と思ってる。

**デフォルトの名無しさん** · 2019/04/06(土) 16:29:49.76

ちなみに、おいらは引きこもりなのでお金が無いんだょ。

**デフォルトの名無しさん** · 2019/04/07(日) 16:35:02.31

>>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 だと
　追従しやすいらしい。

**デフォルトの名無しさん** · 2019/04/07(日) 16:59:47.19

>>73
6. JVMを使うには、使いたい人が自分で JRE をインストールする必要があったが、
　wasm だと、IE以外の新しいバージョンの主要なブラウザなら全て最初から
　対応している事。そのため、多くの人に届きやすいプラットフォームである。

7. Java(Applet)やFlashは既に、数年後にはChromeからは実行できなくなる予定で
　あるが、wasm は逆に、Flash(Adobe) までもが backend として対応すると
　宣言している。

**デフォルトの名無しさん** · 2019/04/08(月) 18:03:38.12

>>1
ウェブ・アプリをローカルで実行したい場合に参考になりそうなもの
・Google Gears
・PWA = Progressive Web Apps
・WASI = Wasm System Interface
・blob, fetch, XHR

**デフォルトの名無しさん** · 2019/04/08(月) 18:17:36.29

>>75
・Electron, Chronium ---> ブラウザの枠を超えた Window が出せる。
・Chrome Apps (廃止)

L · 2019/04/21(日) 17:21:20.81

http://nowsmartsoft.atwebpages.com/

↑ demo1 の EditWidget が、MobileのOn-Screen Keyboardに対応して、
PCでも日本語の入力が出来るようになったよ。

「今まで出来なかったの?」って？　ブラウザのせいだよ～！

**デフォルトの名無しさん** · 2019/05/18(土) 16:05:19.62

>>1
ブラウザ上だとタイトルバーとURLアドレス欄で画面に無駄が消費されてしまう問題は、
「WebView」のようにアプリの内部にブラウザを埋め込んでしまえばいい。
それを使えば、キャッシュされてしまう問題も回避できるかもしれない。

**デフォルトの名無しさん** · 2019/05/18(土) 17:12:47.28

google「そう思ってDesktopPWAって枠組み用意しときました」

**デフォルトの名無しさん** · 2019/05/18(土) 17:59:00.81

PWAの作り方は良く分からないけど、アプリの審査がいらないのは
子供達にも向いてるかもね。

**デフォルトの名無しさん** · 2019/05/18(土) 18:07:19.99

でも、https必須らしいので、年間維持費がかかりそう。
・登録料無料のhttpsを使うのには独自ドメインが必須らしい。
・サブドメン方式でhttps使う場合は探した限り無料で出来るレンタルサイトはない。

**デフォルトの名無しさん** · 2019/05/18(土) 18:09:37.44

デスクトップPWA
https://developers.google.com/web/progressive-web-apps/desktop
日本語版ないからクロムの翻訳機能使ってくれ

**デフォルトの名無しさん** · 2019/05/19(日) 01:51:24.70

世の中なんでも結局は金金金か!!

**デフォルトの名無しさん** · 2019/05/19(日) 11:00:10.59

ほんそれ

**デフォルトの名無しさん** · 2019/05/19(日) 11:10:01.48

github pagesあるやんけ

**デフォルトの名無しさん** · 2019/05/19(日) 11:28:02.61

netlifyあるやんけ

**デフォルトの名無しさん** · 2019/05/19(日) 12:52:29.06

https://yutakaaoki.github.io/
↑良く分からんけど、ひとまず https で wasm のデモ・ページ作ってみたで～

**デフォルトの名無しさん** · 2019/05/19(日) 17:06:00.28

wasm ていう単語見るたびにいつもこいつが頭に浮んでしまう
https://ja.wikipedia.org/wiki/%E3%82%8F%E3%81%95%E3%81%8A#/media/File:Wasao.jpg

**デフォルトの名無しさん** · 2019/05/19(日) 17:57:24.92

twitter の #wasm タグ、今年に入ってから急激に活発になってる気がする。
去年は数週間に一回の書き込み、みたいな感じだったようだけど、今月なんかは
数十分に一回の書き込み位になってる。求人広告まで沢山出だして、wasm技術者
を探す第一回目の会議(?)みたいなものまで出てきたらしい。

**デフォルトの名無しさん** · 2019/05/19(日) 18:01:09.59

ITの世界では、良く分からないところで誰かが商売に結び付けて大儲けし出す
事が多かったから、先に動こうとしてるんだろうか。クラウドとかも本当に
メリットがあるかどうかおいておいて、ブームのようにして大金が動いている。

**デフォルトの名無しさん** · 2019/05/19(日) 19:04:28.84

The web always wins. # ウェブはいつも勝つ
と書いてる人がいた。
面白い見方だな。

**デフォルトの名無しさん** · 2019/05/19(日) 19:11:38.67

「Wasmで最も重要なのは、Secutrityの面である」
と書いている。WasmはSandBox内で動作しているので安全だと。

なるほど、「Webがいつも勝つ」一つの原因は、安全性が高いことなのか・・・。
そういえばブラウザ上で動いている限り、まずウイルス感染しないな・・・。
そうか、スマホが流行る原因も、マシンのトラブルが少ないからかもしれないな。
PCだとOSが不安定になって使えなくなることが多いのと対照的。
なるほどなぁ・・・。

**デフォルトの名無しさん** · 2019/05/19(日) 19:25:02.22

https://byterot.blogspot.com/2019/05/why-webassembly-matters.html
↑
ここにそのことが書いてあるよ。

**デフォルトの名無しさん** · 2019/05/20(月) 14:01:02.69

上手くいけば、AppStore登録の月額利用料金が開発者にかからないでiPhone/iPad
ようのアプリが作れるかも知れない。
iOSでも、去年の3月くらいにSafariもPWAに対応したらしいし、Chromeも使える。
となると、ウェブアプリをWasmで作っておいて、PWAを使えば普通のアプリの
ようにHome画面にアイコンを登録できるし、実行時にアドレスバーも出さなく
できる。Safariで駄目な場合は、iOS用のChromeもある。

**デフォルトの名無しさん** · 2019/08/11(日) 11:35:01.71

wikiで宣伝はアカンでよ

**デフォルトの名無しさん** · 2019/09/12(木) 22:35:47.25

>>40
トンでもねぇ色彩センスｗｗｗ
さすがに草不可避ｗｗｗｗｗ

**デフォルトの名無しさん** · 2019/09/13(金) 10:13:11.78

NG かどうか試してみる
http://nowsmartsoft.atwebpages.com/

**デフォルトの名無しさん** · 2019/11/18(月) 16:14:21.51

C++をソースとするwasmとPWA(Progressive Web Application)化できる
ことを実際に確認することが出来た。Chrome+Win7の組み合わせで
wasmアプリをローカルにインストールできてデスクトップにアイコン
を作成することができる。アイコンをクリックすると、ある種の
nativeアプリの様な雰囲気で起動できる。

**デフォルトの名無しさん** · 2019/11/18(月) 16:14:54.06

C++をソースとするwasmをPWA(Progressive Web Application)化できる
ことを実際に確認することが出来た。Chrome+Win7の組み合わせで
wasmアプリをローカルにインストールできてデスクトップにアイコン
を作成することができる。アイコンをクリックすると、ある種の
nativeアプリの様な雰囲気で起動できる。

**デフォルトの名無しさん** · 2019/11/18(月) 16:15:25.78

age

**デフォルトの名無しさん** · 2019/11/18(月) 19:53:09.11

https://yutakaaoki.github.io/pwa-wasm-demo1-B/

ここに wasmアプリが置いてあるが、Chromeで訪れるとアドレスバーの右の方に
「インストール」という文字が現れ、しばらくすると、○で囲った + 記号に変わる。
そこをクリックすると、PWAとしてローカルPCにインストールできる。
または、右上の縦に3つの点があるボタンを押してみると、
『「PWA NWSTK」をインストール...』
というメニュー項目が出来ているので、そこをクリックしても同じ機能が働く。

**デフォルトの名無しさん** · 2019/11/20(水) 09:18:48.73

Mozilla、Fastly、Intel、Red HatがWebAssemblyをターゲットに「The Bytecode Alliance」
https://news.mynavi.jp/article/20191118-925267/

**デフォルトの名無しさん** · 2019/11/20(水) 12:43:45.81

>>101
https://yutakaaoki.github.io/
ここにおいてあるものは、全部PWAに対応してみた。
Windowsならインストールできると思う。
AndroidやiPhoneなどでも出来るか試して欲しい。

**デフォルトの名無しさん** · 2019/11/20(水) 12:51:31.62

>>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の組み合わせ方、に興味のある人は
参考までに。

**デフォルトの名無しさん** · 2019/11/20(水) 13:48:41.27

で、これで何ができるの？

**デフォルトの名無しさん** · 2019/11/20(水) 14:49:34.93

>>105
・セキュリティーが凄く強いアプリ。信用できないようなサイトからインストール
　しても、レジストリには読み書きできないし、システムフォルダや他のアプリの
　フォルダには、人間がマウスやキーボードなどから実際に指示しない限りは書き込めないし、
　読み込むことも出来ない。変な場所にインストールされたり、スタートアップ起動などに
　勝手にされることも無い。
・アプリの体験版をインストールすることなく、普段のウェブ閲覧の延長線上に
　試せるのでユーザーは遊び半分で気軽に試すことが出来る。また、掲示板などから
　リンクを張った先がすぐにアプリとなっている。その後、デスクトップや
　ホーム画面にアイコンを追加し、単独アプリの用に振舞うことが出来る。
・なぜか全てがウェブに移行するようになっており、「いつもウェブが勝つ」。
・iPhoneやiPad用のアプリが無料で開発出来る可能性がある。今までは、
　それらをターゲットに開発するには、Mac実機がどうしても必要となり、
　かつ、AppStoreに登録しないと配布することも出来なかったが、AppStoreは
　年会費も必要で、生涯にわたってずっとコストが掛かかり続けていた。
・ブラウザが互換性を保つので、PCで試して動けば、AndroidやiPhoneでも
　近い動作になる可能性が高い。
・Chrome, FireFox, Safari, Edge, Opera なども wasm に対応している
　（ただし、ツールキット側がテストはしておく必要はある。）。

**デフォルトの名無しさん** · 2019/11/20(水) 15:00:00.13

Java Appletと何が違うの？

**デフォルトの名無しさん** · 2019/11/20(水) 15:00:41.97

>>106
【追加】
・画面が、Ctrl+ +, Ctrl+ -で好きなように拡大縮小できるので、近視や老眼などで
　目が悪い人でも好きな文字の大きさで読むことが出来る。それがWebアプリでも、
　PWAアプリ化したものでも出来る。
・ツールキットも含めてサイズがとても小さい。ブラウザさえ使える状態であれば、
　DLLやランタイムのインストールが全く不要。demo1は、*.htmlや*.js, *.wasm全て
　合わせて　150KB、demo-Mountainは、153KB。JavaランタイムもQtランタイムも
　MFCのDLLも何も要らない。

**デフォルトの名無しさん** · 2019/11/20(水) 15:11:39.18

>>107
・Java Appletは、訴訟トラブルのせいか、ChromeもFireFoxが対応しなくなって
　しまった。
・wasm は、C++ が使えるので、GC を使わないプログラムが出来、
　メモリが多く使うウェブアプリを作ろうとした場合に、体感速度が非常に
　違ってくる。Javaだと、GCが走ると一分間停止するようなことがあった。
　wasm と C++ の組み合わせだと、このようなことが起きないので、
　プログラムした通りの一定の速度が維持できる。
・Java は、逆コンパイルするとほぼ元ソースに戻せてしまう性質があった。
　それを防ぐには曖昧化などが必要であり、手間や（ツール購入の）コスト
　が掛かった。曖昧化するためにコンパイル時間が増大した。
・Javaが有料化したという話がある。これについては諸説あるのでよく分からない。

**デフォルトの名無しさん** · 2019/11/20(水) 15:14:47.33

>>109
・Java Applet より起動が速い。

**デフォルトの名無しさん** · 2019/11/20(水) 15:18:23.10

>>110
・wasm内部からは、EM_ASM()構文などで自由にJavaScriptが使えるので、
　XHRやfetch()などを自由に使ったAjax流儀のプログラムが行える。
・簡単に HTML 要素と共存できる。
・ブラウザの画面を拡大したような場合に、JavaAppletだと追従するのが
　難しく、できないことはないがタイムラグが生じ易かった。
　Ctrl+ + での拡大も、JavaApplet 部分だけは置いていかれるようなことに
　なったので、対応したければ独自に工夫する必要があった。

**デフォルトの名無しさん** · 2019/11/20(水) 15:54:16.93

>>111
・iOSでは、もともとJavaが使えないと聞いている。
・Androidは、基本がJavaではあるが、実際には、Google独自実装となってしまって
　おり、　Sun/OracleのJavaで昔からの標準の Swingなどを使ったものは動か
　せない。これが訴訟問題になった最も大きな原因の一つらしい。

**デフォルトの名無しさん** · 2019/11/20(水) 19:15:30.47

>>108
ツールキットに用意されて無い機能を追加したい場合、JavaScript として書けば
よいのであらゆるプラットフォームへ迅速に対応できる。
他のツールキットの場合は、iOS/Andorid/Win/Mac/Linux など用にそれぞれ
書く必要がある。

**デフォルトの名無しさん** · 2019/11/21(木) 15:21:55.41

PWAは、頻繁にアップデートしたいアプリに向いている。

**デフォルトの名無しさん** · 2019/11/21(木) 16:02:31.75

PWA化後のデスクトップのアイコンが、物凄くいろいろなことをやっても古いまま
全く更新できなく立った。
どうしよう。

**デフォルトの名無しさん** · 2019/11/24(日) 12:10:37.33

Safariで動いていたよ。
ホーム画面への追加のボタンも出ていた。

**デフォルトの名無しさん** · 2019/11/26(火) 01:08:23.77

PWAだとストアの審査が要らない。通常、iPhoneのアプリは、iPhone流の
インターフェースを持って無いと審査に通らない（Appleに脅威をもたらすと
考えられるだけで審査に通らない可能性もある。YahooゲームやLINEゲームが
AppleにBANGされた歴史もある。）。PWAの場合はそんなことはなく自由
なので、PCやAndroid、iPhoneで完全に同じインターフェースにすることもできる。
そうすれば、開発も楽になる。

**デフォルトの名無しさん** · 2019/11/26(火) 01:16:04.21

PWAの場合、ブラウザとnative風アプリの操作感が統一できるのでユーザーは
安心して使える。WindowsとiPhoneで同じインターフェースのアプリになる。
今まではAppleの審査のためにそのようなことは出来なかった。Windowsに慣れて
いるが、iPhoneを使っている人にはWindows流インターフェースの方が好まれる
可能性があるにも関わらず。

AppleはiPhoneらしさを強要するが、逆にどのプラットフォームでも同じ操作感
であることには、開発者のみならずユーザーにもメリットがある。

**デフォルトの名無しさん** · 2019/11/26(火) 01:22:29.32

Appleは審査が厳しいが、自社がそのアプリが出てくると(競争に負けて)業績が
落ちそうだと判断するともっともらしい理由を付けて審査を通さなかったり、
長く時間をかけて手間をかけさせたりする可能性がある。PWAだとその心配が無い。
ただし、PWA専用のダウンロードサイトを作ろうとすると、そのサイト自体に
規制がかかったことがあるそうだ。Appleはまるで中国や北朝鮮のようだ。

**デフォルトの名無しさん** · 2019/11/26(火) 01:24:58.56

>>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であれば
　最小限の投資で実現できるでしょう。

**デフォルトの名無しさん** · 2019/11/27(水) 01:56:02.82

独自GUIを乗せることで使い勝手で他のアプリと差別化できるかも。

**デフォルトの名無しさん** · 2019/11/27(水) 01:59:18.80

>>121
今までなら独自GUIはAppleの審査に落ちる可能性があったが、PWAなら
自由になる。それでAppleの伝統を超えた使い勝手のGUIシステムを備えた
アプリを提供できれば他のアプリと差別化できる可能性が出てくる。

**デフォルトの名無しさん** · 2019/12/06(金) 02:20:17.94

Webアプリの場合、URLのパラメータによって、プレイ中のゲーム画面
にいきなりリンクすることが出来るようになる。これで、ゲーム画面の「シェア」
が出来る。例えば、RPGで経験値、体力、魔力、所持アイテム、地図上の座標、
タワーの階層、的の位置などを全部URLのパラメータに直してしまえば、
そのシーンを他の人にシェアして、そこからプレイし始めてもらえる。これは、
native ゲームにはなかった特徴。blob や base64 による URL 化などを使えば
データをURL化することは難しくはない。URLが長くなりすぎる問題はある
かも知れないが。

**デフォルトの名無しさん** · 2019/12/06(金) 02:24:38.19

>>123
RPGなどでセーブデータが大きすぎてURL化に適さない場合は、
サーバー上にシーンを圧縮セーブしておいて、その識別番号をシェアする手もある。
ユーザーが各自で無料ストレージサービスを借りて、そこにセーブしておいて、
それをシェアする手もある。

**デフォルトの名無しさん** · 2019/12/06(金) 02:45:16.50

インストール型のゲームだと、URLを書くだけで一瞬で動いている場面を他人が
見ることはできない。しかし、ウェブゲームだとそれが出来る。ただし、
この場合、ゲームサイズを小さく作ることが重要になる。その意味で、
サイズがコンパクトになるwasmと、コンパクトなサイズのゲームライブラリが
重要となる。

**デフォルトの名無しさん** · 2019/12/06(金) 02:50:45.17

ゲーム全体のデータが巨大だとしても、1つのシーンを見るために必要なデータは
ごく少ない。その意味で、プログラム部分(コード)部分のサイズさえ小さければ、
ポリゴンやテクスチャやマップのデータは巨大でも良い。大部分のデータは
サーバー上に置いて置けばいいのだから。これで、ゲームシーンを快適に
シェアできるようになる。これが、ブラウザゲームならではの新しい価値。

**デフォルトの名無しさん** · 2019/12/06(金) 02:56:52.29

インストール型ゲームでも動いているゲーム画面をシェアすることも不可能ではないが、
それには、同じゲームをインストールすることが前提となる。
一方、ブラウザゲームでは、例えば、2ch/5ch にリンクアドレスのURLを
入れるだけで、一秒後には、そのシーンを見られて、プレイも出来る。

**デフォルトの名無しさん** · 2019/12/08(日) 12:57:08.43

テニスゲーム:
https://yutakaaoki.github.io/demo_tennis/

**デフォルトの名無しさん** · 2019/12/10(火) 08:37:25.30

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

**デフォルトの名無しさん** · 2019/12/10(火) 14:13:47.04

ブラウザの中でのwasmは、現状、ローカルファイルシステムには自由にはアクセス
できないが、その場合、mongoose.exe, Ruby, Python などでローカルサーバー
を起動すれば、ブラウザ内のwasmプログラムから cgi プログラムを起動できるので
ローカルOSのAPIは何でも利用できるようになるので、ローカルファイルシステムにも
自由に読み書きできるようになる。もし、このサーバープログラムが十分に高速なら、
DirectInput などを利用してフォースフィードバック付きのジョイスティックも
wasmゲームから使えるようになる。

**デフォルトの名無しさん** · 2019/12/10(火) 14:26:39.38

ローカルサーバーをnode.jsで書くの流行ったな

**デフォルトの名無しさん** · 2019/12/10(火) 14:28:32.93

>>130
ちなみに、mongoose.exe は、BSD/MIT 系ライセンス。
サイズは100MBを超えてしまっているが、Luaを無効にしてソースから
ビルドし直すと、すると、サイズが1MBくらいになる。

**デフォルトの名無しさん** · 2019/12/10(火) 14:36:55.20

mongoose.exe + CGIプログラムを配布すれば、ある種の Java仮想マシンJVMの
代替になる。JavaのSwingでGUIアプリを作る場合も JVM のインストールが必要に
なるが、それが、mongoose.exe + CGI プログラム。しかし、JVMよりサイズが
小さいのでインストールが容易。

**デフォルトの名無しさん** · 2019/12/10(火) 16:23:17.02

>>129
それとは直接関係ないけど、海外のサイトで昨日、目にしたのは、Googleは、
MicrosoftからOSの制御力を奪おう(無くそう)としているという見方。
PWAを発案したのもGoogle。
IntelやMozilla、RedHat、Fastlyも、別方向でwasmを拡大しようとしているので、
恐らく一社がコントロールしようとしてもwasmの勢力拡大は止められない
思われる。PWAに関しては微妙で Appleは渋々対応している感じでは有るが、
対応しないとむしろ不利になると経営判断している可能性もある。
分からないが。

**デフォルトの名無しさん** · 2019/12/12(木) 19:22:14.47

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 アプリの時代が終焉するかもしれない。

**デフォルトの名無しさん** · 2019/12/12(木) 19:26:35.52

>>135
訂正。
使ったGPUは、エントリーモデルの(ビジネス用の)劇安 Intel CPU に内臓の
Intel HD グラフィックのもの。それでさえ、初期 PlayStation レベルを
超えたグラフィックが描けているようだった。

**デフォルトの名無しさん** · 2019/12/13(金) 00:07:05.15

PWAは自社に不利になるはずなのに何故、Appleも採用したかについて。
PWAはGoogleが推進しているものだが、Googleは、検索エンジンを
iOSのデフォルト検索エンジンにしてもらうために、毎年Appleに
一兆円を払っている。ところが、このカネの流れのために、
AppleもGoogleの意向を無視できない状況になっているのではないか
と考えられる。

**デフォルトの名無しさん** · 2019/12/13(金) 10:10:45.11

板違い
マ板池

**デフォルトの名無しさん** · 2019/12/30(月) 11:57:40.01

アップル、Mac App Store外アプリの「公証」要件を厳格化。2020年2月3日から
https://japanese.engadget.com/jp-2019-12-25-mac-app-store-2020-2-3.html

**デフォルトの名無しさん** · 2019/12/30(月) 12:16:48.85

登録済でも放置されてるものは消えるのか
胸熱

**デフォルトの名無しさん** · 2020/01/05(日) 08:50:18.44

ブラウザでゲームのマップ作れて操作するのは見たことあるよ。
もう今ブラウザ主流？
ただいちいちサイトに繋いだりサーバーにアクセスするから普通のアプリよりは不安要素あるけど。セーブもしたりできるしな。
何でブラウザでやるのかがわからない。

**デフォルトの名無しさん** · 2020/01/05(日) 16:24:57.29

>>141
ある外国の学者が言ったそうだ。
「存在する技術はぎりぎりまで使われる」
と。

典型的な例は、HDDの容量が以前では考えられないほど増大しているのに、テレビ録画など新しい使い方が見出されていつまでたっても不足していること。

ユーザー目線で考えたときのブラウザでやるメリットは、
・インストール作業が要らないこと。もし起動が十分速ければ、次々とゲームを試すことも出来る。
・理論上は、URLに状態やセーブ番号などを含ませておけば、そのURLを掲示板などに張っておくだけでプレイ場面を世界中の人に見て貰えること。
・プログラムがブラウザのサンドボックス内から外に悪さが出来ないので、たとえ野良アプリであってもマシンにあく栄起用を与える可能性が低いこと。
・iOS/Android/Windows/Mac/Linux など全く違うOSでも全く同じ使用感でゲームが出来ること。
・Appleの独自規制に引っかかることもないので開発者の自由な発想のゲームで遊ぶことが出来る。

**デフォルトの名無しさん** · 2020/01/05(日) 18:19:27.95

https://www.businessinsider.jp/post-187542

*アップルは、国境を超えて表現を規制する力を持っている。

アップルのガイドラインでは、性的な表現について、次のような記載がある。

｢Webster辞書で『美的または情緒的な感覚ではなく、性的興奮を引き起こすような、性器または性行為の明確な記述または表示』と定義される、あからさまに性的またはわいせつなコンテンツ｣

欧米や日本、イスラム教徒の多い中東など、国、地域ごとに｢わいせつ｣の考え方には違いがある。

しかし、デベロッパーに対しては、アメリカのアップルが決めたガイドラインが一律に適用されるため、｢ローカルルールは存在しない｣と言われる。

6〜7年ほど前、ゲームの世界でも、ガラケーからスマホに一気に移行する波が訪れた。そのころには、アップルの基準に合わせるため、露出度の高い女性キャラクターの服装を描き直す作業に追われたという。

ゲーム会社の幹部のひとりは｢アップルは、国境を超えて表現を規制する力まで持った。しかし本来は、国や企業がそれぞれの文化や戦略に合わせて考えるべきことなのでは。現状では、毒っけのあるコンテンツはつくれない｣と話す。

**デフォルトの名無しさん** · 2020/01/07(火) 18:36:15.80

昔の chip8 という CPU エミュレータが一瞬で起動しちゃう:

https://blog.scottlogic.com/2017/12/13/chip8-emulator-webassembly-rust.html
https://colineberhardt.github.io/wasm-rust-chip8/web/

二番目のリンク先で、start というボタンをマウスでクリック後、wキーを押すとブロック崩しの様なゲームが動き出す。
キーボードのqで左、eで右にラケットが動く。

**デフォルトの名無しさん** · 2020/03/11(水) 16:21:40.05

https://yutakaaoki.github.io/demo1/index.html
MessageBox が出せるようになった。
C++のプログラム中で
nexMessageBox("タイトル文字列","メッセージ文字列", MB_OKCANCEL);
などとすると、ボタンが押されるまでその場で停止する。
JSやブラウザ、Wasmでは、本来、「その場で待機」することは出来ないので、
nwsc の bsync, bwait, bresume 機構を用いている。

**デフォルトの名無しさん** · 2020/03/11(水) 16:24:14.20

>>145
なお、JSとC++の組み合わせる際に、ちょっとした問題があって、今のところ、トータル200個以上のWindowを生成すると異常を来たすので、決して、ダイアログを何度も生成しないでね・・・。
理論上は直せるけれど、まだ直せてない。

**デフォルトの名無しさん** · 2020/03/11(水) 19:28:39.62

STLが使いたい。

**デフォルトの名無しさん** · 2020/03/11(水) 20:30:36.35

>>147
以下は他のコンパイラを使う場合は関係ない話だけど。
コンテナ類は、C++ nexでも本家C++以上に便利になるように独断と偏見で独自サポートしている。
STLは、templateをかなり深く使用していると思われるので、C++ nex側のそれに追いつけなければ、そのままではSTLのコンパイルは難しい。
なお、今のところtemplateを簡単に使えるようにしたtemplなるものを C++ nexでもサポートしているが、本家C++のtemplateも徐々にサポートしていく予定。

**デフォルトの名無しさん** · 2020/03/27(金) 04:03:07.14

Wasmアプリは次のようなことで需要がありそうだ：
・nativeアプリの場合、ストレージの容量制限でインストールできない事があるが、
　Wasmならブラウザ内で動くのでその心配は少ない。
・nativeアプリの場合、インストールするのに新しいVersionのOSを要求されること
　があるが、Wasmなら、余り関係ない。

**デフォルトの名無しさん** · 2020/03/27(金) 04:06:39.29

>>149
nativeアプリの場合、Win7で動いていたものがWin10で動かなかったり、逆に、Win10を要求されたり
する。
Androidアプリの場合も、バージョン○○以上が必要条件などとあったりする。

ところが、Wasmアプリの場合、余りそういうことは無い。
ブラウザのバージョンが有る一定以上のものでありさえすれば、OSの種類やバージョンに関係なく動く可能性が高い。