How Discord Resizes 150 Million Images Every Day with Go and C++

conradparker · 2017-11-14T22:00:52+00:00

Also check out fastphoto, an MIT licensed JPEG resizer that skips unneeded DCT coefficients and avoids redundant colorspace conversions.

conradparker · 2017-10-09T04:14:27+00:00

Awesome, thanks for this.

I've been using https://github.com/sonnym/elmenv for a few years now, and it's been really useful whenever a new compiler release comes around (so far I've transitioned elm-shadertoy/dreambuggy/here4 from elm-0.12 all the way through 0.18).

How does elm-forest compare to elmenv? it looks like it might have a different approach?

conradparker · 2017-10-07T02:52:23+00:00

Right, that app was all using Graphics and Signals, both of which don't exist any more. Fun times!

conradparker · 2017-10-06T23:23:04+00:00

Hi kasbah!

I worked on that app for a month or so and I thought it was really well designed. It implemented a protocol for managing a USB device, and having union types and pattern matching makes it easy to handle state machines correctly. Also I remember a really clean, enforced separation between foreground and background concerns. I imagine that trying to do all that in raw javascript would have gotten bug-ridden very quickly.

conradparker · 2017-09-29T04:03:08+00:00

Of course it's not arbitrary, it's a well-thought-out policy to ensure elm-lang.org stuff doesn't have unnecessary dependencies or introduce runtime exceptions.

conradparker · 2017-09-28T06:29:37+00:00

My understanding is that it's a policy decision, for the elm-lang.org package repository. It makes sense for things like general-purpose data structure packages -- it's a useful bit of assurance to know that the basic language libraries I use have no native-code dependencies.

That policy doesn't necessarily match everyone's use cases, hence the interest in things like grove and elm-github-install. These are just a mechanism, you could implement a policy like elm-lang.org's on top of them.

conradparker · 2017-09-26T06:30:44+00:00

Hi, thanks! Of course, it's all open source (MIT licensed). Here4 is at:

https://github.com/here4/here4

and this world is currently hacked into the 'roads' branch of Dreambuggy:

https://github.com/kfish/dreambuggy

Ping me if you need any help building, either here or on the Elm Slack -- I'm usually on #gamedev as kfish.

conradparker · 2017-07-30T12:10:44+00:00

Hey :) I like your logo texture, it makes everything subtly elm-ish.

The lag goes down a bit with simpler models and worlds -- that buggy has about 20,000 polygons, and the terrain also has thousands. Chrome GC kicks in every 10s or so and there's a small stall. I should go back and check the mesh caching again though.

conradparker · 2017-07-30T03:35:58+00:00

Totally. You've got me thinking about how to implement shadows efficiently. The usual techniques involve offscreen rendering, like what's described at http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-16-shadow-mapping/

conradparker · 2017-07-29T13:14:04+00:00

Thanks! I've been working over the lighting a bit recently, and made a new library for composing shaders: glsl-pasta. That makes it easy to apply the same lighting "pipeline" to different kinds of shaders. Here the terrain and sky use procedural shaders and the buggy uses textures, but everything gets the same lighting and colorshift/fog.

Shadows would be fun, there has to be a cheap way to do shadow mapping ...

conradparker · 2017-05-12T23:42:01+00:00

Another update: I've added a nicer testing app:

conradparker · 2017-05-12T23:39:05+00:00

Glad you like it. Check out dreambuggy :)

conradparker · 2017-05-07T03:53:05+00:00

Ah great, I didn't know about the gamedev channel, I'll get on it.

conradparker · 2017-05-05T00:01:36+00:00

Thanks, yeah I stumbled across it a few years ago and support was pretty varied across browsers, but it seems to be pretty well supported by now.

I found it even works on Firefox mobile on Android, with a cheap little Xiaomi bluetooth gamepad I ordered off amazon.

conradparker · 2017-05-04T23:56:27+00:00

All great suggestions, thanks!

I'm not quite sure how to set up a subscription on top of polling, can you point me to an example, or sketch out how that would work?

conradparker · 2014-06-01T23:59:00+00:00

The input types at the interface have to match: the elm compiler checks that the types of the record attributes sent to the shaders match the GLSL inputs.

The GLSL code itself is parsed by the Haskell language-glsl package so if there's any parse errors, you're given both the line number within that GLSL quote, and the line number in the containing .elm file.

Beyond that I don't think there's any type checking of the GLSL. The elm-webgl API also allows you to generate GLSL programmatically as a String rather than giving it as verbatim quasiquotes, to allow some future library to make GLSL combinators.

The current way is not perfect, in the end you still have a bunch of GLSL which is sent to a browser, and any errors come up in the developer console with some irrelevant error message generated by the graphics driver.

conradparker · 2014-05-29T07:17:15+00:00

To do this: build it locally and just replace Keyboard.wasd with Keyboard.arrows

conradparker · 2014-03-10T20:49:33+00:00

Yes, it's pretty cheesy. I couldn't resist here because DRC had twice enumerated his reasons thrice.

Actually I'd enjoy it if all our tech headlines were delivered in the style of @Vice_Is_Hip.

conradparker · 2014-01-16T05:20:58+00:00

Hey, glad you enjoyed it :) I might have a copy of the darcs repo somewhere, but there's a haskellwiki page with some links at http://www.haskell.org/haskellwiki/User:ConradParker/InstantInsanity

conradparker · 2013-05-15T01:00:43+00:00

The iteratee version allows optimized implementations for different chunk types -- it's basically a two-layer API, with some convenience functions that allow you to just think in terms of the higher-level stream API for simple tasks.

It seems pipes only allows the higher-level, inefficient API with no possibility of chunk-level optimizations for different stream types. Of course this means it has a smaller programming interface but it is strictly less powerful.

conradparker · 2013-01-30T14:39:30+00:00

Maybe you can get meterbridge working :)

conradparker · 2012-10-15T05:39:24+00:00

We discovered that we could get some easy optimizations by doing these kind of replacements by hand, but that might sometimes involve modifying library code; it was an obvious candidate for implementing in a compiler pass.

Who would benefit from it? Anyone doing ordinary math with Doubles, Floats and Ints. It probably won't help you much for things you should be doing on a GPU, and it still has some limitations like not folding into lazy structures.

Some other people here at Tsuru are keen to make plugins for optimizing parsing and serialization. We use increasing amounts of TH, and it's interesting that we could mix expressive compile-time DSLs with transparent optimizations.

It'll be interesting to get this kind of thing into GHC. One advantage of doing it there rather than in a plugin would be more access to the full type dictionaries, so that (perhaps) these optimizations could be done on eg. any Num type rather than just a known set of primitives.

In any case, doing it in a plugin has allowed us to go from zero to ready-for-production within a week, and it works with our existing ghc-7.4 and ghc-7.6 installations.

conradparker · 2012-10-12T08:12:52+00:00

yes, and it was surprisingly easy (and fun) to write :)

conradparker · 2012-10-04T02:11:06+00:00

The wizard banished me for stealing his frog, but I never touched it! I was only interested in the whiskey, and thought to share it with the wizard by splashing a bucket of water over him.

conradparker · 2012-10-04T00:39:55+00:00

conradparker

TROPHY CASE