phoboslab

Somewhat OT: if you write a blog post about a company (or product, etc.), please provide a link to the company in the first paragraph.

I know it's trivial to google, but it's still very annoying. I see this here all too often. E.g. many companies have their blog at blog.example.com but no obvious link anywhere to example.com. It's just a huge oversight.

So, out of courtesy: https://www.lytro.com/

I strongly disagree. Yes, nausea is a big problem but there are a lot of scenarios/games where you don't need locomotion or can comfortably work around it (warping, a cockpit of some sorts etc.).

Also we might be closer to solving the eye vs. inner ear discrepancy completely rather sooner than later. Samsung is working on a headset that stimulates your vestibular system to make you sense motion & acceleration: http://www.theverge.com/2016/3/14/11220836/samsung-etrim-4d-...

The DK1 is just awful in comparison to the DK2, though. Positional tracking and reduced latency of the DK2 improve the nausea situation a whole lot. I haven't had a chance to try the CV1 yet, but it's supposed to be an equally big jump.

Image hosting community site - notably without shady popup/layer/scam ads, which probably was the reason for the relatively small income. For a two person team that only worked part time on it, it still made good money.

The total dataset was just about 3TB, so storing it was not an issue.

Can someone explain to me why traffic is still so damn expensive with every cloud provider?

A while back we managed a site that would serve ~700 TB/mo and paid about $2,000 for the servers in total (SQL, Web servers and caches, including traffic). At Google's $0.08/GB pricing we would've ended up with a whooping $56,000 for the traffic alone. How's that justifiable?

You may want to play SOMA then. The whole game deals with this very subject and its implications. I can highly recommend it for the excellent storytelling, dense atmosphere and brilliant sound design.

http://somagame.com/

This AddOn really gives you a nice, high level overview of what's going on and where to optimize. I may just add that for lower level debugging WebGL Inspector[1] is also tremendously helpful.

Also, cool to see my game[2] as an example for the bad overdraw situation :)

[1] https://chrome.google.com/webstore/detail/webgl-inspector/og... [2] http://phoboslab.org/xibalba/

Ejecta lets you use Canvas+JS without the browser – at least on iOS. http://impactjs.com/ejecta

So where's the data from?

A few years ago we build a website that had a ranking algorithm somewhat similar to reddit. Upvoting a post would put in your favorites. Many users told us that oftentimes they wanted to upvotes a post without putting it in their favs, so we split the behavior and introduced a new fav button in addition to the upvote button. This worked out remarkably well. People voted more without fear of polluting their favs. The overal ranking of posts worked way better with that.

I don't think that makes sense for twitter though, because "popular tweets" are not really substantial for the platform - and I actually like that about twitter. It's not so much a popularity contest as platforms are.

So, without the need for a strong ranking, I'm not sure if more likes are actually a good outcome. What do we gain from this, other than making it harder to find your (truly) favorite tweets again?

.ico files (as used for favicons) typically contain BMPs.

I'm not a fan of using libraries for simple examples either, but WebGL just requires tons of boilerplate even for the simplest stuff.

If you just want to show a pixel shader, you probably don't need any library. Still, creating textures, setting up the buffer for your single quad, compiling pixel and vertex shaders and the shaders themselves will easily pile up to a good 100 lines of code.

Now, if you want to do anything with real 3d objects, such as in this example, you need code to:

  - generate or load the models
  - set up your camera
  - trace clicks on the canvas to the objects (not a simple feat in 3d space)
  - implement this mover widget/drag+drop of objects
  - implement some sort of lighting
  - implement some sort of shadow rendering, so it's easier to estimate 
    the position of the objects
  - (for all of the above) implement a library for 
    vector and matrix math

You'll easily end up with a thousand lines of code there, and you haven't done anything yet to solve the actual problem this article discusses.

Decoding an MPEG1 video is of course much more taxing on the CPU than scrolling through a large image, but low-res videos shouldn't be a problem even on older mobile devices. jsmpeg uses WebGL to speed up the decoding process a bit. On an iPhone5S, it can decode 720p video in realtime[1].

jsmpeg only unpacks the current frame into memory instead of decoding the whole video at once, so it's memory footprint should be much lower. MPEG1 files are also much smaller than storing individual JPEG frames.

[1] http://phoboslab.org/files/jsmpeg/benchmark-720p.html

Same demo video as mpeg1, 243kb, decoded in JavaScript: http://phoboslab.org/files/jsmpeg/cat/

Longer demo: http://phoboslab.org/files/jsmpeg/

Really nice work. This doesn't seem to an official site of BMW, though!?

Porsche[1] and Renault[2] did something similar lately. It's great to see WebGL used for this in production. Honestly, I'm surprised it took so long. Visualizing cars with WebGL seems like a no brainer, especially when most current websites load dozens of images for their "360° views".

[1] http://www.porsche.com/microsite/911/germany.aspx#showroom/9...

[2] http://www.littleworkshop.fr/renaultespace/

For my system it hovers around 50-70ms[1][2]. Tested with an 800x600 window at ~7% cpu utilization on a Core i5. My desktop monitor is a Dell u2711, which seems to add about 15ms latency itself[3].

I'm not sure how much latency OSX or Chrome adds (at least a frame more than Firefox[4]); Mobile Safari seems to be a bit faster, as evident in the video. I don't have a second Windows machine for comparison.

Edit: When connecting on the same machine, latency is 2 frames (33ms) exactly[5].

[1] http://phoboslab.org/files/jsmpeg/jsmpeg-vnc-latency.mp4

[2] http://phoboslab.org/files/jsmpeg/jsmpeg-vnc-latency.jpg

[3] http://www.anandtech.com/show/2922/4

[4] http://phoboslab.org/log/2012/06/measuring-input-lag-in-brow...

[5] http://phoboslab.org/up/B2u6w.png

Afaik nvidia's NVCUVID API only supports H264 encoding, which would require a JavaScript H264 decoder. So far I haven't been able to get the one JS H264 decoder I know of (Broadway) to work reliably and fast enough for large video sizes.

I wish the industry would just get their act together and support a common video codec in browsers along with a JavaScript API that can deal with decoding single frames. Currently native streaming support for the <video> element in browsers is extremely poor and proposed solutions like MPEG-DASH or HLS add around 10 seconds(!) of latency.

These are not running in the browser, though. And previous Remote Desktop solutions that are viewable in a browser can't handle 60fps (let alone anything >10fps for full motion).

Not at all. At least not for me. It's only in hindsight that everything appears obvious.

I spent a considerable amount of time trying to figure out the track textures. It was only when I looked at the game in an emulator again (psxemu[1], which comes with nice debugger that lets you record frames and single step through draw calls) that I noticed that the track faces are subdivided at run time. This gave me the clue to look for textures in different LOD levels.

Still, it feels great once you get it working. Reverse Engineering is like solving really rewarding puzzle!

[1] http://psxemulator.gazaxian.com/

I believe he meant the race tracks, not audio tracks.

I read somewhere that WipEout XL used a similar data format as the original WipEout, but Wipeout 3 looked like it had a completely new game engine.

The camera path is a cheap hack, extracted from certain track faces and has a lot of damping to smoothen things out. Going through the track in certain parts was a tradeoff.

Nice writeup and quite elegant code!

Curiously, the line drawing functions in Ejecta[1] (which reproduces the Canvas2D API) is one of the most complicated parts of the whole project and certainly has the ugliest code of it[2]. It's fast and works reliably, but maintaining it is a nightmare.

[1] http://impactjs.com/ejecta

[2] https://github.com/phoboslab/Ejecta/blob/master/Source/Eject...

Shameless plug: check out jsmpeg[1] - it's an MPEG1 decoder written in JavaScript that's capable of low latency streaming via WebSockets, weighs only ~25kb gzipped, offloads part of the decoding to the GPU via WebGL and runs smoothly on an iPhone4.

Of course it has some drawbacks, as MPEG1 is a pretty old codec. The data rate is fairly high and it struggles with high resolution streams. 720p still decodes nicely in realtime on most mobile devices, though.

[1] https://github.com/phoboslab/jsmpeg

You can check the libc version with:

dpkg -s libc6

For my Debian 7 servers it reports "Version: 2.13-38+deb7u7" after upgrading. Everything below that (eg. "*u6") is vulnerable. I don't know about the specific version numbers in Ubuntu though.

Edit: the fixed Ubuntu version is "2.15-0ubuntu10.10"

Thanks, I'll have a look!

I can't use WebRTC yet because I want to have support for IE and especially Safari & Mobile Safari. I want to add audio for an iOS App[1] that's using jsmpeg[2] for video streaming.

[1] http://instant-webcam.com/

[2] https://github.com/phoboslab/jsmpeg

I'm currently trying to get realtime audio streaming over WebSockets to work. I'm encoding audio using libspeex on the server side (an iOS device) and decoding it again on the client using speex.js[1].

Transmitting Speex "frames" (where each frame is a 20ms chunk of audio) over WebSockets and decoding in JS works beautifully. However, I have a really hard time to queue up these 20ms AudioBuffer nodes perfectly, without producing any glitches or pops. I'm not sure its even possible with the current API.

What I would like to have is an AudioBuffer node where I can dynamically append chunks while its playing. Since all(?) source nodes are for one time only use, the browser could free the data that was already played again.

An AudioBuffer that allows modification of the data while it's playing would work too - you could just loop it and use it as a ring buffer. However, my understanding of the spec is, that modifying an AudioBuffer's data is explicitly prohibited once its playing.

[1] https://github.com/jpemartins/speex.js/

Without having played Mario Galaxy myself, judging from screenshots it seems the game is using shadow maps[1] or just static geometry for fake shadows[2].

[1] http://screens.latestscreens.com/wii/screenshots/supermariog...

[2] http://images9.gry-online.pl/galeria/galeria_duze3/169624250...

Persistence and syncing for non-nerds.

A few years ago, I tried to convince my colleagues (they're more designers than programmers) to use IRC for informal communication. Using IRC was (and still is) a no-brainer for me. My desktop PC runs all day, so I'm in IRC all day. But for them, joining IRC meant opening their laptops, starting their client and then pinging out 15 minutes later when their laptop went to standby.

When they were in IRC, they had this urge to really be there in IRC. I.e. monitoring it, reading everything, responding in seconds, excusing themselves when they had to go to the bathroom, and finally, finding excuses to close their IRC client again.

I have a totally different mode of operation with IRC, where it's OK to have the client open and not respond for hours or at all if you don't fell like it. I guess it's something you have to learn.

Installing BNCs solved some of the issues, but not all. Also, installing a BNC is not something your average designer-type nerd today wants to deal with.

So we ended up with KickOff for a while, but it never really worked reliably. We're now on Slack and quite happy, but I still want to try some of the various IRC "cloud" services; mainly those for self hosting.

We have the Piratenpartei in Germany, full of nerds and people who take a strong stance for privacy, net neutrality and many other things tech related. They get laughed at and ridiculed (often for good reason) and are considered "unelectable" by many, even in the tech field.

BUT they force other parties to think more about these issues and take position themselfs. I think the Piratenpartei is extremely beneficial for the political landscape here.

I have often wondered why the US seemed so slow to adopt these ideas. From my limited understanding, a good deal of the problem is probably the 2 party system in the US, but that doesn't mean a "HN party" couldn't apply a lot of pressure to democrats and republicans alike.

Just a 64 bit integer (BIGINT).