Slashdot Mirror
Team Fortress 2 Running In a Web Browser Using WebGL
An anonymous reader writes "Unreal Engine now runs in Flash and Crytek is considering porting CryEngine to Flash, but perhaps the Source Engine could go a different route. A software developer who works for Motorola Mobility has managed to get the engine and a level from Team Fortress 2 running in a browser using WebGL. There are still a few features and effects missing, but he claims it achieves a solid 60fps and has a video to prove it. Hopefully this gives Valve ideas; it'd be cool if older Source games became playable in your favorite browser, or even directly in Steam."
That's the one thing major thing missing from HTML5 + WebGL - Audio control. Add sample level audio control and we're golden.
Loading...
I PUSH LEETLE CART!!!!!!!!!
I'm also pretty sure that the guy just got a TF2 level to render and didn't port Valve's Source engine to JS. So its also missing the entire Source engine.
Should add that I think its cool he did this, but the summary is misleading (redundant, I know).
finally, source for linux?
Why would I want to play in a web browser instead of natively?
CryEngine on Flash!? I think we have a new benchmark, everyone!
"When information is power, privacy is freedom" - Jah-Wren Ryel
That's one hell of a job application, dude.
In flash, really ? Flash is so much ressource hungry, no? Hope you Web gamers have gamer machines...
JavaScript can already work with binary data. In fact, there are several libraries already out there that do it. Or you could build your own.
Simple way in the same way that you split large images in to sprites, do the same with audio in one single file.
Once it is loaded, you can do whatever you want with it in JS. Be it mixing or just slicing and playing as background audio.
You could even mix several audio tags together to make the mixing part considerably simpler instead of doing the mixing in binary
The only downside is you have to make loads of instances of audio elements if you want to cover a large amount of mixing. But it you are looking for simple, this is doable right now, even without HTML5 stuff.
This capability existed before HTML4 even existed. HTML5 Audio just makes things simpler.
Pix of hats or it didn't happen.
Demanding constant attention will only lead to attention.
So far as I can tell, there is a W3C API that is already implemented in Chrome.
http://chromium.googlecode.com/svn/trunk/samples/audio/index.html
https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html
Do you still LOL?
I'm not sure that I want or need my games running in a browser, and I'm certainly no fan of Steam (I will never buy a DRMed game that depends on another company continuing to exist for me to continue to own it), but what in the world does or even directly in Steam even mean? I have used Steam (I bough Half-life pre-Steam and it was later "upgraded" to force me to use Steam, and I've used it for some free demos). It certainly doesn't seem likely or desirable that the little Steam tray thing would run a game, and that anyone would want it to. Why worry about keeping flash embedded in Steam up to date, when keeping the browser current is enough grief?
I'm an American. I love this country and the freedoms that we used to have.
What are you talking about? Are you suggesting generating and inserting HTML audio elements into the document to support the playback of a subset of samples? That's craziness. Why don't I just build the Sears Tower out of toothpicks for the next 1,000 years.
I would love to see an HTML 5 (or any JavaScript driven code for that matter) that could submit samples to audio playback that didn't lag or skip and didn't require a plugin.
I think HTML 5 is great, but missing that one thing to be a true 'killer platform.' Good audio control/synchronization (hell, I don't have to have sample level submission, but then let me know where in the playback it is...) would be amazing.
Loading...
I don't think Javascript was meant for manipulating binaries. JS has is being used way beyond what it was designed to do. Maybe it's time for a new web front-end language.
Yeah, I still "LOL" at the frothing at the mouth of every WebGL demo that comes out because there is no quality audio in HTML5/4/whatever.
I have known about the Audio nodes API for almost two years (before it was published as the "Web Audio API.") I was hoping something like that would be part of HTML5, it isn't.
Who cares if it works in Chrome? It needs to work in Firefox, Chrome, and IE.
Loading...
I'd upvote you informative if I could.
I was going to comment that it doesn't appear to be running 60 FPS, but he claims it does when it is running alone (presumably without the video recording software).
I've done some stuff with WebGL and there is some great potential here. As was mentioned above, sound is one issue that needs some serious attention in the browser environment. The other is input.
The guy didn't port the TF2 engine to WebGL since he doesn't have the source code. What he did is make a map loader that can partially load a TF2 level and display it with WebGL, but you can't actually play in it.
Mada mada dane.
As the developer of the demo in question, can I request a change in the article title? I did NOT port the Source Engine to a browser, not even close. I've simply loaded some of the visual resources and demonstrated that they can be displayed at game-appropriate speeds. It's a long way to go from here to "Team Fortress In a Browser".
Ah, the famous quantum claim. "It was working fine before everyone else started looking at it!" Usually preceded by a "Hey guys, check this out!"
"None can love freedom heartily, but good men; the rest love not freedom, but license." --John Milton
the video looked more like it was going around 19fps, not 60.
Voxels are the FUTURE, all hail voxels.
Yeah, when I read that, my first thought was that I'm caught in a time warp and got sent back to April 1.
The Cry engines are already pretty much the most resource-intensive things out there, though they do look great. But I can't imagine how or why anyone with a functioning brain cell would want to "port" such an engine to something so woefully underpowered and feature-limited as Flash.
I do not fail; I succeed at finding out what does not work.
This I do agree with.
I hate how the script element has pretty much just become the javascript element in recent times.
Microsoft were at least decent in that they were supporting other scripts in their browsers. (even if it was 2 of theirs)
Alternatives for not only JavaScript, but the HTML DOM as it is.
How much better would it be to have a simple interfacing syntax for designing interfaces without having the overhead crap you get with the thousands of attributes forced on them that most of the time aren't even needed? XUL seems nice.
A more modern FTP system since FTP is terrible and outdated. I don't care if it "still works", it is awful.
HTTP too, actually. SPDY really needs a speedy deployment, it considerably improves communications between 2 nodes for pretty much every use you can throw at it.
Also, I'd quite like to see something like Gopher, or even Gopher, come back for simple communication pages. Basic styling, same basic syntax, done. Some sites simply do not need the overhead of HTML and CSS, or even JS.
Even the most basic of basic dynamic loading of content if you absolutely need to. It'd certainly open a bunch of more applications for it, but still be a small enough spec and not use a lot of resources.
The web as it is now is an absolute fustercluck of outdated tech, incorrect use and high resource usage.
Too much has been forced on HTTP and it is at the breaking point.
Of course, not likely going to happen now. Too many idiots on the internet now. Too much change would confuse their puny brains, they can barely turn computers on as it is.
Screw it, lets all go back to newsgroups.
don't you ever feel nostalgic for the good ol' days of "this website is best viewed with [insert favorite browser here]"
that's what these idiots want to take us back to, and thank goodness it aint gonna happen =)
html is for txt and js is for buttons and scrollbars. we're gonna keep it that way.
So really what this guy did was take a level from Team Fortress 2 and render the basic geometry + some lightmapping.
I'm not really sure what the big deal is. Based on what the title and summary suggested, I expected a hell of a lot more than a map loader. He did not get TF2 running in a browser, not anything from the Source Engine. All he did was load and render a TF2 map. If this sort of thing wasn't possible in WebGL to begin with there would be no point in WebGL at all, so the fact that he's gotten this much to work isn't surprising. It's not as if TF2 is really pushing the envelope in terms of graphical prowess. Its popularity doesn't have so much to do with graphics as it does with gameplay.
I would love to see an HTML 5 (or any JavaScript driven code for that matter) that could submit samples to audio playback that didn't lag or skip and didn't require a plugin.
The problem is that that's fucking hard. Even if you aren't using a shittastic motherboard "codec".
There's a reason it took several versions for XNA to support dynamic sample playback.
If you're looking for TF2 in a browser, why not simply do a google image search for "hats".
Agreed, though progress is being made. Both Mozilla and Google have submitted proposals to the W3C, and already have some support in their browsers. Firefox uses the Audio Data API, and Chrome the Web Audio API. Obviously it'll be a while before one gets standardized (given the W3's track record, could be a very long time) and support becomes universal across browsers, but it's a start.
Replying to myself; I see below you're already aware of these. From two years ago. And it's still at the proposal stage.
It begs the question, what exactly is it the W3C does all day? Do they just spend all their time surfing the internet? And if so, wouldn't they want to approve this stuff faster so they'll have more ways to goof off?
How many more things are we going to have to program in JavaScript? Man, its getting insane how far out of its sweet spot we have gotten.
Please don't let them put anything else "in Flash". It isn't necessary (WebGL). It isn't secure (ever). It isn't needed (full stop).
It's been hard enough to play video streams "through" flash on Linux, don't push the next gaming craze down the same toilet.
Moore's law is not a law. Theory, yes; Predictable trend, certainly; Law, no.
If the Amiga can do it in 7mhz and in 1985-2000, then get with it dudes , get some elite old school coders to do it . And hurry up slow ass.
Liberty freedom are no1, not dicks in suits.
That really didn't look like 60 fps to me. I don't know if it was just the way it was recorded, or the guy's mouse but that didn't really look like it was achieved 'a solid 60 fps'.
Maybe he should port the video recording software to JS first.
Well, screen grabbing software is processing and IO intensive, I can easily see a screen grabbing app bottleneck the (already highly utilized) CPU resulting in a 50-80% preformance loss. Don't forget that in order for webGL to offload data to the GPU, browser javascript has to do a lot of computation. So yes that claim is much more plausible than saying the same thing for a (flash) binary.
-- no sig today
The W3C has a lot of fronts to manage every time they progress some proposal. I have been following a handful of discussions (mostly on sockets and applications) and the amount of data and discussions that are monitored and moved around is very big. The W3C moves slow because the web can't break. So every new functionality or modified behavior has to be very well thought out.
BTW: I don't know if it was the version (aurora 9), or that i was on fedora, but the last time I visited the mozilla sound experiments nothing worked.
-- no sig today
Oh, sure, I realize it's a very complex task they have, I was speaking mostly in jest. I know I'm not alone in my frustration of their slower-than-molasses processes, but while I sometimes think they move too slow, I know they're still far more qualified for the job than I am. As you say, you can't break the old stuff with updates, and the new stuff you want to make sure you get right the first time.
As for Mozilla, I tried out some of their sound demos earlier today. They technically worked, but on my reasonably fast system I got slowdown, scratching, and lag. Meanwhile, the Chrome demos worked perfectly, even with a WebGL visualizer running on the page and 20 other tabs open. If this is the best Mozilla has to offer, I tend the think the Web Audio API is going to win this battle. That is, when the W3C eventually accepts it to the point other browsers begin implementing it, which if we're lucky will happen before HTML6 becomes the next big thing.
You misunderstand the process and many do.
Here is a rundown of what it looks like:
Step 1: someone has an idea
Step 2: a possible API is discussed on the w3c mailinglist
Step 3: an API is drafted
Step 4: 1 or 2 browsermakers implement it in their browser, do use a 'vendor' prefix
Step 5: people look at how well it works, discuss it on the w3c mailinglist.
Step 6: Webpage authors are encouraged to try it out (and use it in production) with the vendor prefix.
Step 7: proposals for a standard are made
Step 8: I think people vote on it
Step 9: standards are approved and it is a standard. An actually "industry standard" too. Because pretty much everyone agrees on the standard.
Step 10: browser vendors change their browsers and people can use it without the browser-prefix
I'm sure sometimes step 2 and/or step 3 are skipped.
You can see a video of a coneference which explains it in detail:
http://vimeo.com/16326857 from 20:36 till 32:00
Summary: browsers implement what they want and when everyone agrees about the API it .
While the process looks kind of weird from the outside. But the idea is that what becomes the standard should be stable, so it can be set in stone and works like everyone wants.
New things are always on the horizon
Of course, I know there's a lot of work involved; like I said to justforgetme above, I was (mostly) joking about how long it seems to take. I realize it takes a lot of time to get everything right, and you need to do it right the first time or else everyone will support your broken version until the earth crashes into the sun. I'm just impatient and want my WebAudio NOW, dammit! :-)
If you really, really do want it.
You can help write the draft, it costs nothing to join the w3c mailinglists.
New things are always on the horizon
Already exists, and already supported by Webkit. Firefox has a similar, but proprietary, interface.