- From: Jukka Jylänki <jujjyl@gmail.com>
- Date: Wed, 8 Jan 2014 17:21:26 +0200
- To: Marcus Geelnard <mage@opera.com>
- Cc: "Robert O'Callahan" <robert@ocallahan.org>, "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <CA+6sJ-3r5_Oa=vHBU825CK+bKDYhYGh3c0N2wK-NRPr+hWWNBQ@mail.gmail.com>
Direct3D vs OpenGL is not the correct analogy here. If Web Audio spec resolved the need for integer sample formats as WONTFIX, it would be the equivalent of WebGL having said "For simplicity, we'll only do 4xFloat32 RGBA textures as the only texture format type and don't support any other integer formats or compressed texture formats. That shall be the WebGL way.", which would have been completely horrible. Instead, OpenGL vs Direct3D is a very good example to the contrary, they are exactly in the feature parity competition business. Direct3D 11.2 just recently introduced support for "Tiled resources" ( http://msdn.microsoft.com/en-us/library/windows/desktop/dn312084(v=vs.85).aspx), a way to do virtualized textures or "megatexturing". OpenGL done the same in OpenGL 4.4 with GL_ARB_sparse_texture ( http://www.techpowerup.com/187584/khronos-releases-opengl-4-4-specification.html). Why? Since they understand that in order to stay viable as a seriously investable spec, they must compete in features. The way you program against the two APIs is immaterial in comparison, but that they both support the same _use cases_ and _features_ is extremely important. One should not confuse an API, i.e. the way you program against the features, and the features themself that the API offers. 2014/1/8 Marcus Geelnard <mage@opera.com> > What I mean is that you should keep the Web platform in mind when > designing your game engine ... > My previous post tried to illustrate why this is a not a valid counterargument to make. For projects like HTML5 port of ScummVM: http://clb.demon.fi/html5scummvm/ or the Javascript MESS emulator: http://jsmess.textfiles.com there is no "designing your game engine" step. 2014/1/8 Marcus Geelnard <mage@opera.com> > otherwise you'll just be doing a port... > Yes! We are doing a port! 2014/1/8 Marcus Geelnard <mage@opera.com> > ... and it is quite likely that the port will perform noticeably worse on > the Web compared to the originally intended platform(s). > And this will happen exactly if the Web platform is rigid and was not designed to support the same features that the projects that are to be ported needed. But since we are in the roles that can have a say over what features Web Audio supports, it does not have to be that way. Jukka
Received on Wednesday, 8 January 2014 15:21:54 UTC