
Purely Functional 3D in Typed Racket [video] - michaelsbradley
https://www.youtube.com/watch?v=t3xdv4UP9-U&index=6&list=PLXr4KViVC0qI9t3lizitiFJ1cFIeN2Gdh
======
michaelsbradley
If you jump to 11:52, you’ll see a neat demo that shows off the engine’s
performance: 70,000 spheres (ray traced on the card), 500 lights, at 60 frames
per second. Great stuff!

[http://www.youtube.com/watch?v=t3xdv4UP9-U&t=11m52s](http://www.youtube.com/watch?v=t3xdv4UP9-U&t=11m52s)

The source code is available on GitHub:

[https://github.com/ntoronto/pict3d](https://github.com/ntoronto/pict3d)

~~~
FreezerburnV
Honestly, I'm not sure if I should be impressed with the demo they showed. I
haven't given the code a read, so take this with a grain of salt, but I feel
like the exact demo they showed off was mostly a graphics card demo. You can
get most, if not all, of that scene rendered purely on the graphics card
itself using fancy shaders without needing to hit the CPU very much. I feel
like I would have been much more impressed if they had created something such
as a level from Megaman (since they showed a sprite of Megaman near the start)
that the presenter was able to play. I would consider it more impressive since
it would have to spend more time in Racket dealing with physics, collision,
AI, etc. instead of spending the majority of the time on the graphics card.
Hopefully they'll be able to show off a demo like that soon (if one doesn't
exist already) to really show off the capabilities of the engine inside
Racket. Honestly though, the whole project is exciting for me since they're
really just trying to explore new ways of writing games. I'm looking forward
to what they do in the future.

~~~
wtetzner
It seems like the interesting thing is that it's a purely functional API. I
don't thing they were trying to demonstrate that the language is fast.

~~~
michaelsbradley
Exactly. The engine is able to make excellent use of the GPU while sporting a
purely functional API in Racket, a dialect of Lisp.

~~~
ntoronto
Right. I don't remember whether I said it in the talk, but that demo saturates
the AGP bus, meaning that the engine can extract and write scene data at about
1.5 to 2 GB/Sec.

It's possible to put a lot more static content in each frame by uploading the
vertex data to the card just once. That feature is on my to-do list.

------
racketlang
Here's the whole playlist of the rest of the talk recordings from this year's
RacketCon:

[https://www.youtube.com/playlist?list=PLXr4KViVC0qI9t3liziti...](https://www.youtube.com/playlist?list=PLXr4KViVC0qI9t3lizitiFJ1cFIeN2Gdh)

(Michael Fogus gave the keynote and there are other cool talks about games,
grahics, and other stuff)

------
webjprgm
The talk says it doesn't work on OS X because of which versions of OpenGL are
supported. Neil, is that just because you don't know very well how to use the
particular version OS X supports, or are there critical features of your
Pict3D engine that won't work in OS X's version?

(I like to do all my for-fun projects in OS X.)

~~~
ntoronto
More precisely, the problem comes from how certain Linux libraries and OS X
have responded to OpenGL's new profile system.

An OpenGL context is roughly a 3D drawing area and its associated behind-the-
scenes data. Via changes to OpenGL version 3.0 through 3.2, it became possible
to ask for specific _versions_ of OpenGL for each context. There are two kinds
of contexts: "compatibility" contexts, which expose all OpenGL features up to
the version obtained, and "core" contexts, which don't have deprecated
features. For example, starting with 3.1, a core context won't draw quads -
you have to split them into two triangles.

On Linux, Racket uses libgtkgl to get OpenGL contexts that are associated with
GTK widgets. This library won't return anything but compatibility contexts, up
to version 3.0.

On OS X, it's only possible to get an OpenGL 2.1 context or an OpenGL 3.2 or
3.3 _core_ context.

There are a few ways to fix this.

1\. The libgtkgl developers add support for core contexts and versions later
than 3.0. I doubt this will happen. They're dragging their feet.

2\. OS X adds support for compatibility contexts. Again, not hopeful.

3\. We find some other way to get an OpenGL context on Linux that's associated
with a GTK widget. There aren't many options.

4\. I develop using OpenGL 2.1. I lose a lot of shading language features that
way, though, and probably a lot of performance.

5\. I develop multiple rendering paths. I hate this idea, but it may be what I
have to do.

