Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
New wiki page stub to fill: IsTheWebReadyForGamingYet
36 views
Skip to first unread message
Benoit Jacob
Oct 25, 2011, 2:44:02 PM10/25/11
to dev-platform
Hi,
I've started a stub of a wiki page,
https://wiki.mozilla.org/Platform/IsTheWebReadyForGamingYet
to keep track of what still needs to be accomplished to claim that the
open Web platform is 100% ready for gaming, and to have a single link
to show game developers all the great ongoing progress in this area.
Please expand and improve it.
Cheers,
Benoit
I've started a stub of a wiki page,
https://wiki.mozilla.org/Platform/IsTheWebReadyForGamingYet
to keep track of what still needs to be accomplished to claim that the
open Web platform is 100% ready for gaming, and to have a single link
to show game developers all the great ongoing progress in this area.
Please expand and improve it.
Cheers,
Benoit
David Rajchenbach-Teller
Oct 25, 2011, 3:03:04 PM10/25/11
to Benoit Jacob, dev-platform
Good idea.
I don't see anything about, well, the obvious competitors: DirectX and
the console SDKs.
Cheers,
David
I don't see anything about, well, the obvious competitors: DirectX and
the console SDKs.
Cheers,
David
Benoit Jacob
Oct 25, 2011, 3:08:58 PM10/25/11
to David Rajchenbach-Teller, dev-platform
This wiki page is only about web-based gaming, so the only competition
that I'm aware of is Flash and Silverlight.
My rationale is I don't care that much about whether gaming happens on
the web or elsewhere (desktop, consoles) --- but _if_ it happens on
the web then I care about it being the _open_ web as opposed to
proprietary platforms.
Benoit
2011/10/25 David Rajchenbach-Teller <dte...@mozilla.com>:
that I'm aware of is Flash and Silverlight.
My rationale is I don't care that much about whether gaming happens on
the web or elsewhere (desktop, consoles) --- but _if_ it happens on
the web then I care about it being the _open_ web as opposed to
proprietary platforms.
Benoit
2011/10/25 David Rajchenbach-Teller <dte...@mozilla.com>:
Cedric Vivier
Oct 26, 2011, 12:57:05 AM10/26/11
to Benoit Jacob, dev-platform
Awesome initiative.
On Wed, Oct 26, 2011 at 03:08, Benoit Jacob <jacob.b...@gmail.com> wrote:
> This wiki page is only about web-based gaming, so the only competition
> that I'm aware of is Flash and Silverlight.
Shouldn't we consider NativeClient as a competitor as well?
(it will likely have a larger installed base than Silverlight soon, if
not already)
Cheers,
On Wed, Oct 26, 2011 at 03:08, Benoit Jacob <jacob.b...@gmail.com> wrote:
> This wiki page is only about web-based gaming, so the only competition
> that I'm aware of is Flash and Silverlight.
(it will likely have a larger installed base than Silverlight soon, if
not already)
Cheers,
Christian Legnitto
Oct 26, 2011, 1:03:22 AM10/26/11
to Benoit Jacob, David Rajchenbach-Teller, dev-platform
On Oct 25, 2011, at 12:08 PM, Benoit Jacob wrote:
> This wiki page is only about web-based gaming, so the only competition
> that I'm aware of is Flash and Silverlight.
Thanks,
Christian
Benoit Jacob
Oct 26, 2011, 7:21:49 AM10/26/11
to Cedric Vivier, cleg...@mozilla.com, dev-platform
2011/10/26 Cedric Vivier <ced...@neonux.com>:
JS+DOM APIs, so Native Client is clearly a competitor of that.
2011/10/26 Christian Legnitto <cleg...@mozilla.com>:
thought it was purely an (old) legacy thing. Will add. Again,
clarifying that by web platform I mean JS + DOM APIs, Java is not part
of that.
Cheers,
Benoit
> Shouldn't we consider NativeClient as a competitor as well?
> (it will likely have a larger installed base than Silverlight soon, if
> not already)
Good point, I'll further clarify that wiki page to say it's about
> (it will likely have a larger installed base than Silverlight soon, if
> not already)
JS+DOM APIs, so Native Client is clearly a competitor of that.
2011/10/26 Christian Legnitto <cleg...@mozilla.com>:
> Java applets are used for a lot of games on the web (specifically pogo.com, which is a very popular website that caused us to release a chemspill 3.6 update when we broke it). Not sure if Java is considered open these days or not but I wouldn't consider it part of the web platform in any case.
I didn't know that java-for-web-applications was still on the map, I
thought it was purely an (old) legacy thing. Will add. Again,
clarifying that by web platform I mean JS + DOM APIs, Java is not part
of that.
Cheers,
Benoit
Henri Sivonen
Oct 26, 2011, 9:35:06 AM10/26/11
to dev-pl...@lists.mozilla.org
On Wed, Oct 26, 2011 at 2:21 PM, Benoit Jacob <jacob.b...@gmail.com> wrote:
> I didn't know that java-for-web-applications was still on the map, I
> thought it was purely an (old) legacy thing. Will add.
Oracle seems to be trying to revive Java browser plug-in usage:
> I didn't know that java-for-web-applications was still on the map, I
> thought it was purely an (old) legacy thing. Will add.
https://www.infoworld.com/d/application-development/oracles-ambitious-plan-client-side-java-175241
I wouldn't bet on Oracle succeeding here, but it's still prudent to
compare JavaFX for features.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
aapo.l...@gmail.com
Oct 27, 2011, 6:23:00 AM10/27/11
to dev-platform
On Tuesday, 25 October 2011 21:44:02 UTC+3, Benoit Jacob wrote:
> I've started a stub of a wiki page, [...] to keep track of what still needs
That list looks quite comprehensive to me, but since we're talking 100 % here, I thought I would add my two cents. I have lately been trying to develop a moderately complex game in JavaScript and WebGL. The good news is that most difficulty has had to do with my lack of game development experience. Basic 3D was relatively easy to pick up but AI is proving to be a time sink like no other.
However, there have been some browser-related annoyances too. The ones missing from the above page are:
* Clean yet fast code *
In general, I have been very happy with JavaScript performance I have seen in Firefox and Chrome. As a representative example, I converted a simple collision-detection system from JavaScript to WebCL as an experiment. My test case was only twice as fast as a CPU-based WebCL kernel (Samsung WebKit implementation) than it was in JavaScript (Firefox, Chrome). Not optimal, because 2x performance differential might mean reducing the scope of the game to (for example) 1000 units from the 2000 possible with native code, but by no means a showstopper.
The problem is that to achieve this level of performance I have to, for example, preallocate all my temporary vectors and matrices and return the results from basic vector and matrix operations in explicit parameters. In C# or C++ I could just implement them as stack-allocated values and do away with the extra parameters. I could overload the operators to make the code cleaner still. This can make a big difference in AI code, for example.
This doesn't really mean that I'm pining for stack-allocated user-defined value types, since something like escape analysis could help here, but see below.
* Consistent arithmetic *
Some types of games, especially RTSes, depend on being able to execute code perfectly consistently on multiple machines. Floating point numbers greatly complicate this because x86 processors have an "extended precision" mode when floating point operations are performed in 80 bit internal precision even if the operands are stored externally in 64 bits.
I'm not sure if it's just too subtle for me, but even though ECMAScript 5 specification specifies the rounding mode for floating point, it doesn't seem to specify internal precision. Okay, so I'll stick to integer values and be careful not to overflow. But every time I need to divide, I'll have to remember to add | 0 after the operation and that is yet another thing that makes the code less readable.
* Predictably decent performance *
If I write a piece of well thought out C or C++ code, I can expect relatively decent baseline performance, even if my compiler isn't that good or advanced optimizations are turned off. With JavaScript, C-rivaling performance comes from VM wizardry that is:
- Vendor-specific, i.e. even though Firefox and Chrome tend achieve relatively even results, they achieve them by subtly (and not so subtly) different means.
- Underdocumented, i.e. code can get qualified for or disqualified from certain optimizations based on heuristics that are complex and fully described only in JS engine source code.
- Invisible, i.e. even though there are ways to find out how the JS engine has chosen to compile a certain piece of code, it requires a separate debug build and must be dug up from some textual dump instead of being conveniently available in Firebug.
Even if Firefox added escape analysis, I would be afraid to rely on it in my APIs because it might not exist in Chrome and Safari and there might not be any documentation to help me fully understand how it works and what the limitations are.
* Three out of three browser coverage *
I have seen a couple of cases where two out of Firefox, Chrome and Safari fully implement some spec or feature, but the remaining one is missing something important to me. So far there has always been an easy enough workaround that allows me to progress, but each such encounter tends to take one evening to resolve. Examples of these features include:
- Firefox taking long to implement DataView (bug 575688, close to done now, it seems)
- Chrome and Safari taking long to implement Function.prototype.bind
- Safari deciding to stick to hixie-76 WebSocket for now
tl;dr Building a pretty nice JavaScript-based RTS seems eminently doable, but the code can end up cruftier than my aesthetic sensibilities approve of.
The above comes with a huge disclaimer, namely that I'm not a game developer but a web developer who is occasionally working on a game for no particular reason. My opinions might not match those of people who do this for a living.
--
Aapo Laitinen
> I've started a stub of a wiki page, [...] to keep track of what still needs
> to be accomplished to claim that the open Web platform is 100%
> ready for gaming, [...].
That list looks quite comprehensive to me, but since we're talking 100 % here, I thought I would add my two cents. I have lately been trying to develop a moderately complex game in JavaScript and WebGL. The good news is that most difficulty has had to do with my lack of game development experience. Basic 3D was relatively easy to pick up but AI is proving to be a time sink like no other.
However, there have been some browser-related annoyances too. The ones missing from the above page are:
* Clean yet fast code *
In general, I have been very happy with JavaScript performance I have seen in Firefox and Chrome. As a representative example, I converted a simple collision-detection system from JavaScript to WebCL as an experiment. My test case was only twice as fast as a CPU-based WebCL kernel (Samsung WebKit implementation) than it was in JavaScript (Firefox, Chrome). Not optimal, because 2x performance differential might mean reducing the scope of the game to (for example) 1000 units from the 2000 possible with native code, but by no means a showstopper.
The problem is that to achieve this level of performance I have to, for example, preallocate all my temporary vectors and matrices and return the results from basic vector and matrix operations in explicit parameters. In C# or C++ I could just implement them as stack-allocated values and do away with the extra parameters. I could overload the operators to make the code cleaner still. This can make a big difference in AI code, for example.
This doesn't really mean that I'm pining for stack-allocated user-defined value types, since something like escape analysis could help here, but see below.
* Consistent arithmetic *
Some types of games, especially RTSes, depend on being able to execute code perfectly consistently on multiple machines. Floating point numbers greatly complicate this because x86 processors have an "extended precision" mode when floating point operations are performed in 80 bit internal precision even if the operands are stored externally in 64 bits.
I'm not sure if it's just too subtle for me, but even though ECMAScript 5 specification specifies the rounding mode for floating point, it doesn't seem to specify internal precision. Okay, so I'll stick to integer values and be careful not to overflow. But every time I need to divide, I'll have to remember to add | 0 after the operation and that is yet another thing that makes the code less readable.
* Predictably decent performance *
If I write a piece of well thought out C or C++ code, I can expect relatively decent baseline performance, even if my compiler isn't that good or advanced optimizations are turned off. With JavaScript, C-rivaling performance comes from VM wizardry that is:
- Vendor-specific, i.e. even though Firefox and Chrome tend achieve relatively even results, they achieve them by subtly (and not so subtly) different means.
- Underdocumented, i.e. code can get qualified for or disqualified from certain optimizations based on heuristics that are complex and fully described only in JS engine source code.
- Invisible, i.e. even though there are ways to find out how the JS engine has chosen to compile a certain piece of code, it requires a separate debug build and must be dug up from some textual dump instead of being conveniently available in Firebug.
Even if Firefox added escape analysis, I would be afraid to rely on it in my APIs because it might not exist in Chrome and Safari and there might not be any documentation to help me fully understand how it works and what the limitations are.
* Three out of three browser coverage *
I have seen a couple of cases where two out of Firefox, Chrome and Safari fully implement some spec or feature, but the remaining one is missing something important to me. So far there has always been an easy enough workaround that allows me to progress, but each such encounter tends to take one evening to resolve. Examples of these features include:
- Firefox taking long to implement DataView (bug 575688, close to done now, it seems)
- Chrome and Safari taking long to implement Function.prototype.bind
- Safari deciding to stick to hixie-76 WebSocket for now
tl;dr Building a pretty nice JavaScript-based RTS seems eminently doable, but the code can end up cruftier than my aesthetic sensibilities approve of.
The above comes with a huge disclaimer, namely that I'm not a game developer but a web developer who is occasionally working on a game for no particular reason. My opinions might not match those of people who do this for a living.
--
Aapo Laitinen
aapo.l...@gmail.com
Oct 27, 2011, 6:23:00 AM10/27/11
to mozilla.de...@googlegroups.com, dev-platform
On Tuesday, 25 October 2011 21:44:02 UTC+3, Benoit Jacob wrote:
> I've started a stub of a wiki page, [...] to keep track of what still needs
> to be accomplished to claim that the open Web platform is 100%
Gervase Markham
Oct 28, 2011, 11:41:01 AM10/28/11
to
On 25/10/11 19:44, Benoit Jacob wrote:
> https://wiki.mozilla.org/Platform/IsTheWebReadyForGamingYet
Bikeshed: surely, in the style of earlier efforts, "canweplayyet" :-)
Gerv
> https://wiki.mozilla.org/Platform/IsTheWebReadyForGamingYet
Bikeshed: surely, in the style of earlier efforts, "canweplayyet" :-)
Gerv
Jeff Gilbert
Oct 28, 2011, 12:23:30 PM10/28/11
to Gervase Markham, dev-pl...@lists.mozilla.org
Surely it would be "arewefunyet"?
_______________________________________________
dev-platform mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
dev-platform mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Benoit Jacob
Nov 1, 2011, 8:38:46 AM11/1/11
to Jeff Gilbert, dev-pl...@lists.mozilla.org, Gervase Markham
Per popular request, and as this is how people were starting to refer
to this page anyways,
https://wiki.mozilla.org/Platform/AreWeFunYet
thanks to KaiRo.
Benoit
2011/10/28 Jeff Gilbert <jgil...@mozilla.com>:
to this page anyways,
https://wiki.mozilla.org/Platform/AreWeFunYet
thanks to KaiRo.
Benoit
2011/10/28 Jeff Gilbert <jgil...@mozilla.com>:
> Surely it would be "arewefunyet"?
>
> ----- Original Message -----
> From: "Gervase Markham" <ge...@mozilla.org>
> To: dev-pl...@lists.mozilla.org
> Sent: Friday, October 28, 2011 8:41:01 AM
> Subject: Re: New wiki page stub to fill: IsTheWebReadyForGamingYet
>
>
> ----- Original Message -----
> From: "Gervase Markham" <ge...@mozilla.org>
> To: dev-pl...@lists.mozilla.org
> Sent: Friday, October 28, 2011 8:41:01 AM
> Subject: Re: New wiki page stub to fill: IsTheWebReadyForGamingYet
>
0 new messages