【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/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の種類やバージョンに関係なく動く可能性が高い。

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

アプリストアにはアプリが多すぎて、まみれてしまう。
ウェブアプリなら、検索エンジンからダイレクトに探せるのでアプリストアよりは、まみれる度合いがましになる。

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

・WasmやPWAが、TwitterやLineなどでshareし易いことは、
　企業にとってはのどから手が出るくらい価値がある。
　nativeアプリだと気に入ったアプリを友達にシェアしにくいが、
　WasmアプリだとURLだけですぐにシェアできる。これはアプリの普及や
　宣伝にとって意義は大きい。
・PC/Mac/iPhone/Androidで見た目や使い勝手が同じであることは、
　アプリのブランド価値を高める。
　これは、コンビニが全国で同じレイアウトと品揃えであることで
　安心感と利便性を高めることで勝ち残ってきたことと通じるものがある。

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

企業にとっては、プラットフォームごとにビルドし直さないでよいことだけでも
価値は大きい。
マルチプラットフォーム対応なのに最終プログラムが1種類だけで済むことは
メンテナンス性は劇的に向上する。
nativeアプリをマルチプラットフォームに対応させる場合、OSごとにビルドされた
最終プログラムのバックアップだけでも慎重を要し、生産性が下がる。
開発時にはいちいち、各プラットフォームごとにビルドする時間と手間、
テストが必要で、その時にトラブルも出易かった。例えば、
新しいバージョンのAndroidが出てきたら、新しいAndroidSDKをインストール
しなくてはならないが、それでツールキット側のバージョンが合わなくてトラブル
が発生し、その解決のために一週間以上も無駄になることもあっただろう。
Wasmなら、最終プログラムは一度ビルドするだけで済むのでそのようなトラブルが
生じないし、テスト工数も激減する。

**デフォルトの名無しさん** · 2020/04/13(月) 18:12:02.53

MDI Child Window に対応 :
https://yutakaaoki.github.io/demo1/index.html

◆QZaw55cn4c · 2020/04/13(月) 21:47:32.08

>>153
で、ブラウザごとにデバッグするわけですか…

**デフォルトの名無しさん** · 2020/04/13(月) 23:46:07.73

>>155
HTML5は他企業も含めた共通規格なので、一度決まった仕様は比較的安定して動作するため、ツールキット側が一度デバッグしてあれば、そので動くアプリは1つのブラウザで動作チェックしさえすれば、ツールキットがサポートしているどのブラウザでも動作し易い。

**デフォルトの名無しさん** · 2020/04/14(火) 00:37:46.92

HTML5はGoogleの規格なので、Googleの都合でいかようにも変わると思います。

**デフォルトの名無しさん** · 2020/04/14(火) 01:07:56.72

>>157
確かにFireFoxのMozillaもGoogle傘下にあるようなものだし。
でも、SafariやEdgeもあるので、今まで動いていた古い仕様が動かなくなる可能性は割と低そうという希望的観測がある。

**デフォルトの名無しさん** · 2020/04/14(火) 01:12:20.23

でも、実行プログラムがindex.htmlとmain.wasmなどの1種類で、
プラットフォームごとにビルドし直さなくて良いというのは安心感はある。

◆QZaw55cn4c · 2020/04/14(火) 19:22:31.95

>>156
write once, run anywhere といわれていた Java JVM も、蓋を開けてみれば write once, debug anywhere となってしまった現実をご存知ですか？

◆QZaw55cn4c · 2020/04/14(火) 19:23:13.73

>>159
でもデバッグは各ブラウザ毎にしないといけませんね…

**デフォルトの名無しさん** · 2020/04/15(水) 14:42:27.93

>>161
やはり、「XX OS対応」と書くためには、XX OSでテストする必要はあるでしょう。
ただ、ビルド回数が少なくて済むことは時間の節約になりますし、
他の事で手一杯の忙しいときに、あるプラットフォーム向けのビルドだけ
(起きるはずも無い)エラーが起きてその対応に追われる心配も無いです。

**デフォルトの名無しさん** · 2020/04/15(水) 14:46:20.72

>>162
1. Win/Android/iOS/Mac/Linuxで最終テストは必要。
2. しかし、ソース修正後、ビルドは一度だけでよい。
3. 2.により、仕上げの段階で1箇所修正するだけで5つのプラットフォームごとに
　5回ビルドして5回テストする、という効率の悪い事態は起きない。

**デフォルトの名無しさん** · 2020/05/25(月) 03:25:23.82

あがれ

**デフォルトの名無しさん** · 2020/05/28(木) 17:15:51.05

懸念事項だったローカルファイルシステムへのファイル保存について、
今後の Edge Browser では何か進展が有るらしい。

Native file system access
Up until now websites were not allowed to save files in a specific location on the user device.
This meant that online photo editors required users to upload the photo they wanted to edit and then download it to their device, while a native one would have just given the option to replace the existing one.
Starting from Edge 86 (version 83 is the latest one at the time of writing) developers will be able to replace all files the user selects in a session, thus enabling productivity apps on the web to even more useful.

**デフォルトの名無しさん** · 2020/05/28(木) 17:47:36.62

>>165
どうやら、PWAアプリを起動時に指定したファイル群に、ユーザーにファイルダイアログで毎回選択させること無くいつでもアプリがプログラム的に書きこめるようになるらしい。

**デフォルトの名無しさん** · 2020/07/14(火) 00:20:51.75

age

**デフォルトの名無しさん** · 2021/03/11(木) 04:16:55.67

wasmからGPU使うにはWebGL呼び出しになりますか？

**デフォルトの名無しさん** · 2021/03/20(土) 23:25:10.94

>>168
WebGPU は使ったことは無いが、WebGL 以外に WebGPU もある。
Wasmはそれ自体では副作用や入出力は行えないので、やりたいときはJSを
使うことになるので、GPUを使いたい場合は、JSでGPUを使う方法を調べる
ことになる。Wasmは、EM_ASM 文などの中に書いた JS コードを呼び出す
ことで副作用や入出力を行う。