3 ms·

I disagree. But I understand your view. The thing is I don't want the game running IN the browser. I want it running standalone, but being web enabled and havin

I disagree. But I understand your view. The thing is I don't want the game running IN the browser. I want it running standalone, but being web enabled and having the facilites it provides.

tyingq 8y ago
The WASM folks have plans to deepen the browser ties with direct DOM access, tying threads to webworkers, GC that's tied to the browser js, etc. I can see why you want what you do, but it will get harder over time.
- rafaelvasco 8y ago
  Unfortunate.
- neurotrace 8y ago
  That's not quite true. They intend to create a way of interfacing with ANY GC which would then allow them to make APIs that call in to the DOM. None of this would tie it directly to browsers. The whole intent is to keep it platform-agnostic, last I heard. > An important constraint is that, while WebAssembly should allow tight integration with the Web, it should not bake in details or Web standards dependencies that prevent execution in a non-Web embedding. This suggests a design (called opaque reference types below) that hides the details of JavaScript and WebIDL behind Web-embedding-specific builtin modules. On the other hand, WebAssembly can define a set of native GC primitives that allowed portable GC code to be written regardless of the host environment. https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16
  - tyingq 8y ago
    That's encouraging. As far as I can tell, threading is currently webworker centric.
computmaxer 8y ago
What? If it isn't in the browser, what's the difference between that and something you download on Steam?
- rafaelvasco 8y ago
  For the user almost none. The difference is for the devs. If I want to make a cross platform game now, I have to worry about which Graphics api I will use, OpenGL, Direct3D, Vulkan etc. What sound api I will use. What Display, Input, abstraction I will use. Etc. If I could have a unified api and runtime abstracting all that already for me, making full cross platform games would be easier, assuming I don't want to use Unity. But that is of a much bigger scope that just WebAssembly. We already have that power, but we are chained to the browser. The discussion is to free that runtime from the scope of the browser. Decouple it. The final dream is having a unified, Desktop, Consoles (Ps4 and Switch) and Browser runtime with a unified API (where sensible). One can dream.
  - openbasic 8y ago
    One does not simply develop cross-browser. Different browsers have different issues with different graphics cards. As soon as you're not drawing a textured triangle anymore, things get hairy. Same for the audio API. And don't get me started on the sad state of WebRTC and websockets.
    - beetwenty 8y ago
      Yes, it's just not viable to develop for browsers unless you have the maintenance budget for a moving target. I decided on that after living through the Flash era and trying HTML5 for a little while. The browser is backwards compatible only for certain kinds of applications.
    - rafaelvasco 8y ago
      Well, yeah. I agree. You escape from several problems in native environments and find another several in the web.

I disagree. But I understand your view. The thing is I don't want the game running IN the browser. I want it running standalone, but being web enabled and having the facilites it provides.

tyingq 8y ago

The WASM folks have plans to deepen the browser ties with direct DOM access, tying threads to webworkers, GC that's tied to the browser js, etc. I can see why you want what you do, but it will get harder over time.

rafaelvasco 8y ago
Unfortunate.
neurotrace 8y ago
That's not quite true. They intend to create a way of interfacing with ANY GC which would then allow them to make APIs that call in to the DOM. None of this would tie it directly to browsers. The whole intent is to keep it platform-agnostic, last I heard. > An important constraint is that, while WebAssembly should allow tight integration with the Web, it should not bake in details or Web standards dependencies that prevent execution in a non-Web embedding. This suggests a design (called opaque reference types below) that hides the details of JavaScript and WebIDL behind Web-embedding-specific builtin modules. On the other hand, WebAssembly can define a set of native GC primitives that allowed portable GC code to be written regardless of the host environment. https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16
- tyingq 8y ago
  That's encouraging. As far as I can tell, threading is currently webworker centric.

computmaxer 8y ago

What? If it isn't in the browser, what's the difference between that and something you download on Steam?

rafaelvasco 8y ago
For the user almost none. The difference is for the devs. If I want to make a cross platform game now, I have to worry about which Graphics api I will use, OpenGL, Direct3D, Vulkan etc. What sound api I will use. What Display, Input, abstraction I will use. Etc. If I could have a unified api and runtime abstracting all that already for me, making full cross platform games would be easier, assuming I don't want to use Unity. But that is of a much bigger scope that just WebAssembly. We already have that power, but we are chained to the browser. The discussion is to free that runtime from the scope of the browser. Decouple it. The final dream is having a unified, Desktop, Consoles (Ps4 and Switch) and Browser runtime with a unified API (where sensible). One can dream.
- openbasic 8y ago
  One does not simply develop cross-browser. Different browsers have different issues with different graphics cards. As soon as you're not drawing a textured triangle anymore, things get hairy. Same for the audio API. And don't get me started on the sad state of WebRTC and websockets.
  - beetwenty 8y ago
    Yes, it's just not viable to develop for browsers unless you have the maintenance budget for a moving target. I decided on that after living through the Flash era and trying HTML5 for a little while. The browser is backwards compatible only for certain kinds of applications.
  - rafaelvasco 8y ago
    Well, yeah. I agree. You escape from several problems in native environments and find another several in the web.