12 ms·
Standalone WebAssembly games using I/O devices
- TazeTSchnitzel 7y agoDoes the WebAssembly community really need to reinvent the wheel and create yet another set of new platform APIs?
- jarfil 7y agoIf people want to use WebAssembly to write non-browser applications, then it needs some non-browser API to replace the user interaction capabilities a browser's API would usually provide.
- TekMol 7y agoWhat is the benefit of replacing the browser though?
- the_mitsuhiko 7y agoThere is no browser to replace. Many of us are trying to look into WASM for loadable modules or entire binaries.
- pjmlp 7y agoI thought I already could do that since the late 80's.
- TomMarius 7y agoI tried and ran into many (well known, at this point) problems. WASM solves them.
- wffurr 7y agoWith what? lisp? Java? MSIL? https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al.. https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al.... "secure-by-default foundations for native development that are portable and scalable."
- pjmlp 7y agoYou can compile Hearbleed to WASM, secure by default, as long C or any of its derived languages are not used.
- wffurr 7y agoSure, you can build a flimsy deathtrap house on top of a solid foundation in a lot of contexts. But if the foundation is unsound, it doesn't matter if your Ada is formally verified or not.
- pjmlp 7y agoAt least the Ada folks acknowledge that the language isn't perfect, and don't pretend they were the very first one on its field.
- wffurr 7y agoI don't see anyone pretending any such thing about WebAssembly or WASI. If anything they are drawing on the decades of experience with bytecode formats and security research.
- pjmlp 7y agoApparently not, otherwise bounds checking inside of the same linear memory segment would actually be supported. Likewise, they wouldn't "forget" the formats that already had support for languages like C when talking about what is "new" with WebAssembly.
- 7y ago
- imtringued 7y agoI'm not sure I understand what you're saying. There are two core principles behind WebAssembly. First of all you can run low level programming languages like C on any architecture. This is possible if the code is available and you are willing to compile the C code before installing the application (see gentoo). Secondly the libraries/APIs that the program depends on must be available. What you're saying is that every vendor shipped their software with source code and only used cross platform APIs. Is that right?
- gdxhyrd 7y agoEh, no. Vendors everywhere will package things for your architecture and give you binaries. That is how it has always been done and is still done. Yes, you can do it differently with an IL, but that isn't new either (Java, .NET, etc.).
- pjmlp 7y ago> First of all you can run low level programming languages like C on any architecture Just like with TIMI, MSIL, EM, ADF, TendDRA, PNaCL among others. > What you're saying is that every vendor shipped their software with source code and only used cross platform APIs. Is that right? Rather that this is nothing new, and the formats listed above, already offered the same capabilities, without the same marketing.
- the_mitsuhiko 7y agoI don’t see how asmjs/wasm’s marketing would be much different to the one of pnacl/nacl. It’s just fundamentally better and that’s why people are excited.
- pjmlp 7y agoSo much better that PNaCL still outperforms WASM. https://www.pdftron.com/blog/wasm/wasm-vs-pnacl/ https://www.pdftron.com/blog/wasm/wasm-vs-pnacl/ And it doesn't offer any significant security improvements, in spite of its marketing, compiling Heartbleed into WASM is still possible.
- jarfil 7y agoThe same as from using Electron, but a step further: less overhead from unneeded browser features, ability to lock the user into a kiosk/fullscreen mode, while most of the code is still reusable.
- aurosul 7y agoYou mean like standard desktop application we had until the browser took over?
- TomMarius 7y agoThere are significant differences between standard desktop applications, Electron applications, progressive web applications, isomorphic/universal applications and so on. Usually the business case decides. If you want people to make more standard desktop applications, you should figure out a way to make it work for the common Electron app business case. Or stop throwing baseless shit in their general direction just because they've chosen a technology that does not meet your purity requirements. I'm very sure everyone in the community agrees Electron is not ideal.
- The_rationalist 7y agoElectron is the least worst technology we have for building expressive 2D GUIs. Carlo and others are just an incremental improvement. Every other GUI libraries are order of magnitude inferiors except if you just want to look like windows default utilities.
- layoutIfNeeded 7y agoImagine if apps would blend in with the host OS! The horror!
- TomMarius 7y agoSorry but the founder wants his specific UI, I can't do anything about it, my job is to do it.
- TazeTSchnitzel 7y agoWhat's wrong with using a subset of the browser APIs? Or, alternatively, one of the many existing platform APIs?
- the_mitsuhiko 7y agoBrowser APIs are not C ABIs and the platform C ABIs are typically not cross platform and make for a bad target.
- The_rationalist 7y agoBrowser APIs have C++ ABIs that can be generated through webIDL if I recall well.
- gdxhyrd 7y agoPOSIX, SDL and the usual suspects are pretty much cross-platform and run everywhere.
- pjc50 7y agoI'm not sure why you'd choose webassembly over, say, MSIL for this?
- wffurr 7y agoThe goal for WASI is a secure-by-default capabilities model for access to system APIs. It's also an open collaborative cross-vendor specification with at least four different independent implementations. MSIL/CIL is similar in some ways, but it's still largely only supported by Microsoft and doesn't sandbox binaries the same way. It's an inspiration to We assembly, but not a feasible alternative to it. Similar to Google's PNaCl bytecode. Some more detail here: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas... https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/ https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al... "secure-by-default foundations for native development that are portable and scalable."
- mwcampbell 7y agoFor user interaction that works for everyone, i.e. covering internationalization and accessibility, one could do much worse than to just use the existing web platform APIs, DOM and all. Why reinvent all that?
- flohofwoe 7y agoThere are no cross-platform APIs for something as simple as "blit a bunch of pixels to the screen" anyway, so WASI is pretty much free to define its own. I'm sure over time, and if desired, WASI will get a set of higher level platform-wrapper APIs for rendering, audio, input and networking, but the requirements are somewhat different from traditional "native" APIs, for instance, compatibility with web APIs is useful. So we'll probably see the WebGPU API for 3D rendering, instead of Vulkan, D3D12 or Metal.
- pjmlp 7y agoSDL comes to mind.
- mysterydip 7y agoWould the Java APIs be something to copy? I believe they have had cross-platform graphics classes for a long time.
- zozbot234 7y agoUm, I can think of some folks who got in a bit of legal trouble for (allegedly) ripping off the Java API. I don't think you'd want to do that!
- andybak 7y agoThis comment has made me sad about that stupid, stupid verdict all over again.
- usrusr 7y agoJava has been immensely successful and carefully modernized for decades, but none of that is true for its graphics APIs.
- pjmlp 7y agoIt looks quite modern to me, specially given what some people are fighting to get into ISO C++, or what other languages offer on their standard libraries.
- sunfish 7y agoWASI has some unique goals around extending the WebAssembly sandboxing concepts into the API space using capability-based security, forming one of the key building blocks for nanoprocesses. Beyond that, WASI will indeed likely reuse existing APIs and API concepts, rather than always inventing new things from scratch. The article linked here is an advertisement for a startup.
- amelius 7y agoImho, the WebAssembly community should focus on the missing features multithreading and shared memory. That way, we could run arbitrary code, written in arbitrary languages, and we could just compile existing code to the platform without problems, saving lots of developer time.
- flohofwoe 7y agoShared-memory multi-threading is only one piece of the puzzle though. A lot of existing code also depends on synchronous I/O (fopen, ...), or want to execute "long running loops", these are also currently not possible when running in a web browser context, at least not without hacks and workarounds. Ideally, libraries should only use a very small subset of the POSIX / C-runtime APIs (ideally none which need to call into the underlying operating system), and provide ways for the library user to override this functionality, or not depend on those at all (simple example: allow to provide input data via memory instead of letting the library call into the C runtime I/O functions). Same for threading: instead of spawning threads inside the library, provide an API which takes "chunks of work", and let the library user care about doing this across multiple threads.
- amelius 7y agoI agree to a point, but what if you wanted to port a virtual machine such as the JVM to WASM, which runs a concurrent garbage collector in the background. You can't really divide the process into "chunks of work" in that case, or only in a contrived way (starting the threads is not the issue), and you'd need the shared memory functionality to even make it work (the GC thread would need full access to the data in the other threads).
- cdcarter 7y agoGood news! WebAssembly has community group projects setup for both multithreading [0] and multi-memories [1] which would allow a module to both define a memory space and also import a shared one. There are so many parties interested in wasm, there are a ton of inflight proposals and extensions to get it beyond the mvp stage. [0]: https://github.com/WebAssembly/threads https://github.com/WebAssembly/threads [1]: https://github.com/WebAssembly/multi-memory https://github.com/WebAssembly/multi-memory
- imtringued 7y agoPeople expect their WebAssembly applications to run on more platforms than just Microsoft Windows. There is a reason why web browers have their own graphics API for example. DX12 (and previous version) is the only first class API on Windows. Metal is the only first class API on Mac/iOS. Vulkan/OpenGL are only first class on Linux (and friends) and second class on Mac/Windows. So which API are you going to choose? You'll have to choose the most popular, all or a newly created API that is first class in every compliant web browser. The same thought process happened with I/O devices and WebAssembly itself.
- zamadatix 7y agoThat abstraction work was already done with ANGLE when web standards started requiring browsers offer WebGL across the different platforms.
- WAHa_06x36 7y agoThat API is under development, it is WebGPU.
- _pmf_ 7y agoThe madness needs to stop. I find it especially grating to have the security circus on one side and the endless stream of new side channels on the other.
- deleted 7y ago[deleted]
- I_AM_A_SMURF 7y agoI'm a little out of the loop with WASI. Is there a way to play sound with it too? or is it just video output for now?
- snek 7y agowasi doesn't have sound or video, it appears wasmer exposed a nonstandard api via wasi file streams.
- xyproto 7y agoWhen people write games for ie. Steam, I assume they either use a 3D engine or something custom written in C++ for OpenGL, DirectX or Vulkan. When people write interactive 3D graphics for the web, there's ThreeJS and WebGL. Where does WebAssembly games using I/O devices fit in all of this?
- pfisch 7y agoYou can compile unity to web assembly. There are several other similar engines out there that compile to wasm.
- WAHa_06x36 7y agoThis I/O device thing seems to be a feature of one specific wasm engine that just exposes a simple framebuffer, so, it has nothing to do with anything else.
- meheleventyone 7y agoIn general if you are writing a game (that you expect to ship on multiple platforms) you’ll have some cross-platform layer that makes swapping out runtimes for each platform easy. Then the game is built on top of that. Could be in the same language or in another or both. For example LuaJIT has been popular. WebAssembly provides another target. Browsers are similar in that they are like mini-sandboxed OS’s with “standardised” interfaces. So applying the idea of standardised, sandboxed interfaces to WebAssembly you end up with WASI and probably eventually extension to GPU, audio and other interfaces useful to games. It’s actually a pretty old idea, plenty of old games were actually written to run on interpreters that were then rewritten for each platform. For example Another World which has cropped up on the front page recently takes this approach.
- marcinzelent 7y agoWhy use WebAssembly to create standalone programs, instead of some commonly used languages for writing desktop apps, like C++ or Java?
- deleted 7y ago[deleted]