[HN Gopher] Standalone WebAssembly games using I/O devices
___________________________________________________________________
Standalone WebAssembly games using I/O devices
Author : panic
Score : 125 points
Date : 2020-01-18 11:07 UTC (1 days ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| I_AM_A_SMURF wrote:
| I'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 wrote:
| wasi doesn't have sound or video, it appears wasmer exposed a
| nonstandard api via wasi file streams.
| [deleted]
| xyproto wrote:
| When 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 wrote:
| You can compile unity to web assembly. There are several other
| similar engines out there that compile to wasm.
| meheleventyone wrote:
| In 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.
| WAHa_06x36 wrote:
| This 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.
| TazeTSchnitzel wrote:
| Does the WebAssembly community really need to reinvent the wheel
| and create yet another set of new platform APIs?
| flohofwoe wrote:
| There 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.
| stefan_ wrote:
| I don't understand, WASM can't use canvas?
|
| Because if you "blit a bunch of pixels to the screen", you
| don't care about performance regardless.
| flohofwoe wrote:
| A complex browser API like canvas requires much more effort
| to "emulate" in WASI than a simple 2D framebuffer access. I
| think emulating the Linux framebuffer device is the right
| first step.
|
| PS: I think there's some confusion about WASM running in
| browsers, vs WASM running on top of WASI. WASI is all about
| running WASM _outside_ the browser: https://wasi.dev/
| zozbot234 wrote:
| The Linux framebuffer device is a legacy thing which
| doesn't mesh with the way modern graphics chipsets work.
| GPUs today are practically glorified sprites engines
| where a "framebuffer", a "texture" and a "sprite" are
| essentially one and the same in implementation, and new
| entities can be created by compositing ("blitting")
| existing ones with arbitrary 3D transformations, alpha-
| blending, anti-aliasing etc. You don't want to be limited
| to a single frame-buffer with pixel-level access and
| everything being drawn/blitted by software, that would be
| dog-slow.
| swiley wrote:
| Pretty much the only popular abstraction I'm aware of
| that most GPUs share (as far as complex graphics
| operations go) is shader programs. That's a pretty
| complex abstraction compared to a framebuffer which is
| quite frankly good enough for most things.
| flohofwoe wrote:
| It's not about performance but about convenience. Having
| a way to plot single pixels with the CPU without a lot of
| boilerplate code to setup a 3D API context, creating
| textures, vertex buffers, shaders etc etc is a good thing
| to have in many situations.
|
| That this is not a good way for doing more complex
| rendering tasks seems quite obvious (e.g. in the long run
| this cannot be the _only_ API for covering all sorts of
| rendering, but it happens to be a good sweet spot for
| getting anything on screen at all, and not having to deal
| with an overly complex rendering API just to get some 2D
| image data rendered).
| gdxhyrd wrote:
| In almost no situations you want to have software, pixel-
| based access.
|
| Are we really going back 30 years?
| MrLeap wrote:
| gpu.js has this in a really (in js terms) performant way.
| I love that project.
| zozbot234 wrote:
| If convenience is what you want, that can be provided by
| a 2D canvas. This could even support a "soft
| framebuffer", i.e, a pixel-perfect canvas taking up the
| full screen, or some well-defined window inside it. But
| that would not be a _low-level rendering_ API, of course.
| pjmlp wrote:
| SDL comes to mind.
| boomlinde wrote:
| _> There are no cross-platform APIs for something as simple
| as "blit a bunch of pixels to the screen" anyway_
|
| SDL? Has ports for more obscure platforms, too
| grawprog wrote:
| Yup my first though and drawing a pixel with SDL is pretty
| easy comparatively. SDL_Window *window;
| SDL_Renderer *renderer;
| SDL_CreateWindowAndRenderer(800, 600, 0, &window,
| &renderer); SDL_RenderDrawPoint(renderer,
| 400, 300); //Renders on middle of screen.
| SDL_RenderPresent(renderer);
|
| There's also SDL bindings in a bunch of languages, a few
| official ones here
|
| https://www.libsdl.org/languages.php
| mysterydip wrote:
| Would the Java APIs be something to copy? I believe they have
| had cross-platform graphics classes for a long time.
| zozbot234 wrote:
| Um, 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 wrote:
| This comment has made me sad about that stupid, stupid
| verdict all over again.
| usrusr wrote:
| Java has been immensely successful and carefully modernized
| for decades, but none of that is true for its graphics
| APIs.
| pjmlp wrote:
| It 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.
| Jasper_ wrote:
| ... don't remind me of that proposal, lol. I think it's
| finally dead, and admitted it was a complete and utter
| failure of LEWG to let it get as far as it did [0].
|
| Unfortunately, we now have "diet graphics", which
| consists of stuffing WebKit into C++ and calling it a day
| [1], so, looking forward to where that goes! [2]
|
| [0] https://www.reddit.com/r/cpp/comments/89q6wr/sg13_2d_
| graphic...
|
| [1] http://www.open-
| std.org/jtc1/sc22/wg21/docs/papers/2018/p110...
|
| [2] Hopefully into the bin.
| LockAndLol wrote:
| What about OpenGL?
| xet7 wrote:
| OpenGL is deprecated on macOS and iOS, because Apple has
| changed to use Metal:
| https://github.com/godotengine/godot/issues/19368
|
| That's why Godot is moving to Vulkan, that can also run on
| Metal: https://godotengine.org/article/retrospective-and-
| future
|
| For Godot game developers, this will not be visible in any
| way, it's under the hood change to engine.
|
| For other apps, there is in progress development to run
| full OpenGL on top of Vulkan with Zink. There is a blogpost
| about it here: https://www.collabora.com/news-and-
| blog/blog/2018/10/31/intr...
|
| There is also a talk about it at The X.Org Developer's
| Conference 2019-10-02 here, for example Blender seems to
| work already: https://youtu.be/rV0P1ChE_5o?t=3970
|
| All conference recordings are listed at conference website:
| https://xdc2019.x.org/
| fenwick67 wrote:
| Thanks for sharing Zink, this gives me hope for OpenGL's
| future.
| WAHa_06x36 wrote:
| OpenGL really is a legacy API in 2020. There is a massive
| mismatch between modern GPU design and the OpenGL API
| design. The only reason it wasn't left behind a decade
| ago is that there wasn't a decent replacement.
|
| Today, with Vulkan and soon WebGPU available, there
| really is very little reason to hang on to OpenGL for
| anything but legacy.
| pjmlp wrote:
| Yeah, because everyone wants to be a driver writer and
| compiler expert, in addition to graphics programming.
| _pmf_ wrote:
| > What about OpenGL?
|
| You cannot create a window or handle input with OpenGL.
| pjmlp wrote:
| Sure you can, EGL is part of OpenGL set of standards.
| Jasper_ wrote:
| EGL doesn't let you create a window, it only lets you
| bind an OpenGL context to an existing platform window.
| And input isn't covered by EGL in the slightest.
| flohofwoe wrote:
| OpenGL is on the way out, and for rendering 2D image data
| it requires too much setup code (need to create the GL
| context, a swap chain, a texture, and (unless GL 1.x is
| used) a vertex buffer, shader and setting up tons of render
| state).
|
| For 3D rendering, WebGPU would be the better option to
| support in WASI because it has standalone native
| implementations:
|
| https://dawn.googlesource.com/dawn
|
| https://github.com/gfx-rs/wgpu
|
| But for blitting CPU-generated 2D image data to the screen
| WebGPU is also sort of overkill (of course it would be
| possible to create a much simplified wrapper library in
| WASM).
| pjmlp wrote:
| OpenGL will not be on the way out until Khronos defines
| an high level alternative to Vulkan, as not everyone
| enjoys being a GPU driver writer for doing graphics.
| WAHa_06x36 wrote:
| That will most likely be the already mentioned WebGPU.
| pjmlp wrote:
| That is only for browsers.
| gdxhyrd wrote:
| No, OpenGL is not "on the way out". Please back up your
| claims.
| Godel_unicode wrote:
| OpenGL is certainly used by a number of creative apps
| like Photoshop, but you can't deny that the number of
| games released with OpenGL is down significantly since
| say 2010.
| gdxhyrd wrote:
| A lot of games and apps are being released using OpenGL
| _today_.
|
| Then there is WebGL and OpenGL ES, widely used everywhere
| too.
|
| So, no, it is not going anywhere. In fact, Khronos
| themselves have said so.
| WAHa_06x36 wrote:
| OpenGL absolutely is a legacy API today. It has been an
| awful impedance mismatch to modern GPUs for about a
| decade now.
| drfuchs wrote:
| "Apple deprecates OpenGL across all OSes":
| https://www.anandtech.com/show/12894/apple-deprecates-
| opengl...
| gdxhyrd wrote:
| Apple is not Khronos.
|
| They haven't supported OpenGL for years anyway, so the
| fact they deprecate it now is irrelevant.
| dahfizz wrote:
| A cross platform library loses its potency if it doesn't
| work cross platform.
| gdxhyrd wrote:
| OpenGL does not stop being cross-platform just because it
| does not work natively in 1 platform.
|
| In any case, abstraction layers for macOS already exist.
|
| And, going by your definition, if Apple only allows
| Metal, then no API will be cross-platform ever anyway.
| pjmlp wrote:
| OpenGL was never supported on games consoles, so....
| flohofwoe wrote:
| The GL tools rot is already starting. E.g. the Radeon GPU
| Profiler supports Vulkan, D3D12, OpenCL, but not OpenGL:
|
| https://gpuopen.com/gaming-product/radeon-gpu-profiler-
| rgp/
| gdxhyrd wrote:
| That profiler is meant for _low-level_ debugging as its
| own description says. That is why it does not support
| DX11 either.
| flohofwoe wrote:
| AMD's OpenGL tools don't look too active either, e.g. the
| last release of CodeXL is from 2018, and this only
| updated dependencies or removed functionality, for
| instance this nugget from the release notes:
|
| ---
|
| * Removal of components which have been replaced by new
| standalone tools:
|
| * FrameAnalysis - use https://github.com/GPUOpen-
| Tools/Radeon-GPUProfiler
|
| ---
|
| ...that Radeon-GPUProfiler is that tool which has only
| D3D12 and Vulkan support.
|
| Look around for AMD's OpenGL activity more recently,
| there's not much, which isn't surprising because they've
| been lagging behind NVIDIA with their GL drivers since
| forever. I bet they're eager to close that chapter.
|
| NVIDIA seems more committed to GL still, but without
| having all GPU vendors on board to continue supporting
| OpenGL, Khronos won't be able to do much to keep it
| alive.
| Reelin wrote:
| > but without having all GPU vendors on board to continue
| supporting OpenGL, Khronos won't be able to do much to
| keep it alive
|
| Please don't make things up. OpenGL 4.6 was released in
| July 2017. According to Wikipedia, modern AMD and NVIDIA
| cards both gained driver support for it in April 2018.
| Intel drivers have support since May 2019.
|
| (https://en.wikipedia.org/wiki/OpenGL#OpenGL_4.6)
| gdxhyrd wrote:
| AMD has _always_ lacked tools and has never produced much
| on the software side.
|
| That is not news, and that has nothing to do with the
| state of OpenGL.
|
| Please, stop spreading misinformation about OpenGL.
| azakai wrote:
| > There 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. [..] compatibility with
| web APIs is useful
|
| Personally I think Web compatibility is _so_ useful that wasm
| off the Web should use Web APIs, instead of the direction
| WASI is going.
|
| WASI is an effort to create a new OS API layer from scratch,
| without the baggage of POSIX or the Web or such. That's
| definitely interesting, and may be a big deal in the long
| run, but it has risks (it will take a lot longer, in
| particular) and it has downsides for the Web (which is
| personally the platform I care most about).
| sunfish wrote:
| WASI 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.
| jarfil wrote:
| If 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.
| mwcampbell wrote:
| For 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?
| TekMol wrote:
| What is the benefit of replacing the browser though?
| the_mitsuhiko wrote:
| There is no browser to replace. Many of us are trying to
| look into WASM for loadable modules or entire binaries.
| pjmlp wrote:
| I thought I already could do that since the late 80's.
| TomMarius wrote:
| I tried and ran into many (well known, at this point)
| problems. WASM solves them.
| wffurr wrote:
| With what? lisp? Java? MSIL?
|
| https://hacks.mozilla.org/2019/11/announcing-the-
| bytecode-al.... "secure-by-default foundations for native
| development that are portable and scalable."
| pjmlp wrote:
| You can compile Hearbleed to WASM, secure by default, as
| long C or any of its derived languages are not used.
| wffurr wrote:
| Sure, 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 wrote:
| At 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 wrote:
| I 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 wrote:
| Apparently 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.
| zozbot234 wrote:
| > bounds checking inside of the same linear memory
| segment
|
| That can be supported in the source language.
| pjmlp wrote:
| Which is meaningless for module consumers and hardly any
| different from native processes.
| zozbot234 wrote:
| AIUI, wasm does support using _multiple_ linear memory
| segments at the same time. You don 't get that on native
| processes short of using memory segmentation, which no
| modern architecture supports.
| pjmlp wrote:
| CPUs like SPARC ADI and ARM MTE offer much better memory
| protection than what is being sold by WASM.
|
| Solaris, iOS and future Android versions take advantage
| of their existence.
| imtringued wrote:
| I'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 wrote:
| Eh, 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 wrote:
| > 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 wrote:
| I 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 wrote:
| So much better that PNaCL still outperforms WASM.
|
| 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.
| the_mitsuhiko wrote:
| The reason people are excited about WASM is neither
| security nor performance.
| jarfil wrote:
| The 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 wrote:
| You mean like standard desktop application we had until
| the browser took over?
| TomMarius wrote:
| There 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.
| dkersten wrote:
| > the common Electron app business case
|
| Serious question: what is the common electron app
| business case?
|
| Being able to run as a desktop app as well as in a
| browser?
| TomMarius wrote:
| From my POI: Yes, and reuse developers and code you
| already have for the web version.
| dkersten wrote:
| Ok, thanks, that makes sense.
|
| The reuse developers part I suppose could be achieved
| with QtQuick since QML is javascript based, but beyond
| the language, not that much else translates and you can't
| completely get away from C++ for anything non-trivial, so
| it's not really an electron competitor.
| aurosul wrote:
| > There are significant differences between standard
| desktop applications, Electron applications
|
| That is certainly true.
|
| But I was answering to
|
| > _The 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._
|
| namely _Desktop applications_
|
| Wasmer claim is
|
| > _Use the tools you know and the languages you love.
| Compile everything to WebAssembly. Run it on any OS or
| embed it into other languages._
|
| There's no browser involved here, just _compile once, run
| everywhere_
|
| I have the feeling I already heard it...
| The_rationalist wrote:
| Electron 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 wrote:
| Imagine if apps would blend in with the host OS! The
| horror!
| TomMarius wrote:
| Sorry but the founder wants his specific UI, I can't do
| anything about it, my job is to do it.
| [deleted]
| pjc50 wrote:
| I'm not sure why you'd choose webassembly over, say, MSIL for
| this?
| wffurr wrote:
| The 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-
| webas...
|
| https://hacks.mozilla.org/2019/11/announcing-the-bytecode-
| al... "secure-by-default foundations for native development
| that are portable and scalable."
| TazeTSchnitzel wrote:
| What's wrong with using a subset of the browser APIs? Or,
| alternatively, one of the many existing platform APIs?
| the_mitsuhiko wrote:
| Browser APIs are not C ABIs and the platform C ABIs are
| typically not cross platform and make for a bad target.
| The_rationalist wrote:
| Browser APIs have C++ ABIs that can be generated through
| webIDL if I recall well.
| gdxhyrd wrote:
| POSIX, SDL and the usual suspects are pretty much cross-
| platform and run everywhere.
| _pmf_ wrote:
| The 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.
| amelius wrote:
| Imho, 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 wrote:
| Shared-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 wrote:
| I 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 wrote:
| Good 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 [1]:
| https://github.com/WebAssembly/multi-memory
| gdxhyrd wrote:
| Where is this all being discussed and developed?
| cdcarter wrote:
| There is a W3C sponsored Community Group
| https://www.w3.org/community/webassembly/.
|
| Development of the spec(s) happen in the open on the
| various github projects
| (https://github.com/WebAssembly/). Meeting notes,
| agendas, proposals, etc... are all kept as markdown in
| the git repositories.
| imtringued wrote:
| People 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.
| WAHa_06x36 wrote:
| That API is under development, it is WebGPU.
| zamadatix wrote:
| That abstraction work was already done with ANGLE when web
| standards started requiring browsers offer WebGL across the
| different platforms.
___________________________________________________________________
(page generated 2020-01-19 23:00 UTC)