mrhyperpenguin

This is just speculation but probably nothing. Imgix should be doing their image processing with GPGPU technology (CUDA or OpenCL) which should be pretty much available anywhere.

Technically Apple has had their Metal API available for a while now but I kind of doubt they're using that for image processing.

Note that there's a difference between predicting your age and estimating how old somebody looks (i.e. you could look older for your age).

>Can't it be done just with a shader ?

Yep. If you look at the "How?" and "Performance vs Quality" sections, you can see that you need to render the scene six times to get the surrounding environment, so all you would just need to do is make a shader for the projection[0]. (Rendering the scene six times is pretty common in graphics in order to generate light probes for dynamic lighting and global illumination.)

I suspect with a modern GPU implementation (Vulkan) and some other minor optimizations, this could run pretty easily in real-time.

[0] - http://tksharpless.net/vedutismo/Pannini/panini.pdf

I believe functional programming does have its place in games and graphics, but I don't think it should completely replace imperative/OO programming (yet). Some aspects of game/graphics development map better to OOP (e.g. graphics apis) and should be handled with such tools.

I think, for now, a hybrid OOP/FP approach would be best. Right now, I'm prototyping a game engine in F# and C# to see if one could be viable. Incorporating FP has definitely simplified and allowed me to reason better about parts of code but I'm not sure if the tools and languages work well with each other enough yet.

Also see [0] for some thoughts about FP and game development.

[0] - https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced...

Not DirectX only per se but DirectX first and OpenGL later.

I think a lot of games featured in Humble Bundles used to be that way. A lot of games used to be (and some still are) initially only released on Windows with Mac/Linux ports released later.

Similarly, circular harmonics [0] allows you to project a function onto coefficients of a single angle instead of two.

[0] - http://www.blackpawn.com/texts/ch/default.html

Students and businesses can get (and keep) the software for free through DreamSpark and BizSpark.

The title of the article is really sensationalized. The resolution is still going to pass, just without the "covered business method" (CBM) provision. People in Congress support CBM and are actively trying to find a way to make it work. Plus we could always try and reform software patents at its source and make it harder to grant the lower quality patents.

Check out Shadertoy if you haven't.

https://www.shadertoy.com/

Yeah, as a technical guy I would tend to go with the full 3D route. It might be 10x the upfront work but having a fully automated pipeline might save you a lot of work down the line. For example just changing the color of a character could be as few as two clicks in the full 3D solution, but you might have to manually go through each sprite sheet with the other route.

And technically you could export the sprite sheet with however many frames you want (and be able to lower and increase the number easily) while still getting the exact same results as the Sprite Lamp solution. And of course artists could go in and manually make any changes they want.

It's interesting hearing the perspective of the artists. Thanks.

Wouldn't that still require 4x the amount of work though? (Assuming four lighting profiles.)

I could see this getting prohibitive when creating animations for example.

As far as lighting goes, I think it would be as performant as it gets. It's the same idea as deferred shading; you only have to shade the pixels that the light affects.

As for types of lights and colors, yes, I think that would all be possible.

Pretty cool. I hope all goes well for the author.

But I can't help feeling that generating normal maps from full 3D models would be more robust overall.

For instance you could easily make things like a walking animation or calculate ambient occlusion (pretty standard 3ds max work.) Render it into a sprite sheet and you have the pipeline to dramatically reduce the amount of work artists would have to do.

I guess Sprite Lamp would be best geared toward indies/studios without 3D modelers and can't invest in the aforementioned tech.

This is cool nonetheless.

The OP checked the "stay signed in" option when logging in to his or her Google account on another computer and all of the accounts that were logged in were listed in one menu. He thought Google had merged the accounts and ended up deleting his account.

The solution is simple, just click the sign out button and Google signs out all accounts that are configured to "stay signed in." Alternatively, he could have cleared his cookies or waited for them to expire.

Some people have been saying this is because of bad UX on Google's part. Google is kind of in a catch-22 situation here. They want to upgrade how multiple users check their Gmail on one browser but no one wants to learn how use their new system (I got frustrated when they introduced their new UI to compose emails and had to show a tutorial on how to use it.)

Here's a link to why Pidgin chose to do this.

https://developer.pidgin.im/wiki/PlainTextPasswords

What's wrong with the platform owner controlling what's run on the platform? Seems pretty standard these days.

I had issues connecting to Facebook. Though, my roommate had no issue whatsoever. Even stranger, I could access Facebook in IE but not Chrome, Chrome Canary, or Firefox.

This is why I chose to learn DirectX first rather than OpenGL.

It's kind of like the Android vs iOS debate. DirectX is like iOS in that there's one main feature set which runs on a lot of devices. Whereas OpenGL was pretty fragmented because of extensions.

The only fragmentation on DirectX that I remember is the vertex-texture fetch (which was only supported by NVIDIA cards) vs render to vertex buffer (only supported by ATI cards) features in DirectX 9.0c. After that, Microsoft really started emphasizing the notion of a standard feature set.

OpenGL moved away from all of that starting with OpenGL ES which is partly why it has became so popular.

Looks good. Does anyone know what BRDF was used? Or the technique for the reflections? I think you could get away with cubemap reflections for this particular scene.

Coincidentally, the NSA is at my school today. They're passing out flyers[0] with a cryptography puzzle presumably to recruit students.

[0] http://i.imgur.com/0braj.jpg

People are poor. Some people can't afford to replace their phone if it becomes damaged.

Instead of quadtrees take a look at spatial hashing[0]. It's more simple than quadtrees and the performance is similar if not better.

[0] http://www.gamedev.net/page/resources/_/technical/game-progr...

Probably not. The author of this WebGL app is updating the particles on the CPU which probably explains the low particle count.

Now-a-days it's pretty much standard to use two floating-point off screen textures to store, update, and draw the particles completely on the GPU. This way, you can get 1M+ particles easy.

I think forrestthewoods is pointing out that making games, even social games, is hard.

Sure it's possible for one person to develop a successful social game. But how many of those people can develop two successful social games? 5? 10+? The only name that comes to my mind is Zynga.

There was a controller mod that addressed this exactly [1].

[1] http://youtu.be/XkiyxzvsAYo

I think the question may be asking what do you despise (you despise this thing so much it keeps you up at night.)

I agree with this. I waited 30 seconds just looking at ads while the page was 'loading'. After that I just left because I felt you were more interested in show me ads than content.

The GPU Gems article talks about summed area tables in the context of variance shadow maps, specifically percentage closer soft shadows variance shadow maps where variable-width blurs are used extensively. Didn't really mean to cite the stuff about VSMs (sorry), more so the SAT stuff toward the latter half of the article as it would apply to DoF.

I believe the precision/overflow issues can be mitigated using modern GPU hardware (the authors mention this in section 8.5.2 of the article.) Now-a-days it is pretty much standard to have floating-point render targets (especially with deferred rendering and light-pre pass renderers) so 16/32 bits per component should be adequate especially if you apply the tricks the authors present in the article. Not to mention that now we have DirectCompute/OpenCL/CUDA.

Though I don't really see people talking about SATs that much (I myself have never implemented them.) Maybe there is an underlying reason why people don't? Bandwidth maybe? I would imagine it would be pretty taxing on the system to recompute the SAT every frame.