Writing a Vi-like Graphics Editor in Racket
jeapostrophe.github.io
jeapostrophe.github.io
My favorite part about Scribbled documentation is that everything from code samples to function names in text is clickable. Even the function names in the five-line code samples on the front page of http://racket-lang.org/ are clickable; you can just jump straight to any function's documentation from the home page of the language.
It's intriguing that it talks about very simplistic sprite definitions (8 colors), but yet seems to expect the sprites to be rendered using 3D hardware (talk of normal maps and lighting).
I agree very much with both of you. I assemble all the tiles into texture atlases (and earlier post discusses the technique) and then use a fairly simple shader to render. If you look in the gb/graphics directory [1], then you can see the GLSL code. It was originally coded for OpenGL 3.3 with geometry shaders but I switched to OpenGL 3.00 as a stepping stone to ES 2.
The whole model is based on the concept of "SNES Unbound": I want to have effectively infinite numbers of sprites with many layers and any Mode 7 effects with arbitrary scaling and rotations. This is a very small level of expectation of a modern GPU, so I can get about 1,000 FPS on my laptop with millions of sprites, because I only use a single OpenGL draw call per layer.
Anyways, I'd be happy to comment or chat more with you. Maybe I should post some screenshots of the editor.
Jay
1. https://github.com/get-bonus/get-bonus/tree/master/gb/graphi...
...so saying "Scheme+Racket vs Java+Eclipse" is really comparing apples to pineapples :) (maybe Clojure+Lighttable is closer to what you'd mean...)
In the process, it's also a major test bench for a number of development tools we're building. This is where Racket pays dividends: it has a lot of the simple web-dev stuff in a good-enough state to get you off the ground fast, but doesn't pin you down to any one thing, leaving you wide open to rip out and replace whatever you want. Don't like how the HTML templating engine works? If you're good at macros (and Racket's macros are relatively easy), it's a simple job to roll your own.
We've got a data comprehension system that has its own pseudo-byte code that treats SQL like a machine-language in need of a VM that gives us a lot of static checking of our queries. We have a migration system that can rebuild the schema and restore data as easy as compiling your application, with reversible data translations between schema versions (so that we often do. Setting up a new developer-machine/test-environment/culster-node/what-have-you is a snap). Some of this stuff would have been damn costly to not just build without Racket's macros, I shudder to think what the changes we've had to make along the way would have been like.
Racket lets us take DRY to the extreme. Almost nothing in this project has been difficult to change, or at least no more difficult than the initial effort to develop it, because there is almost never a reason to change the interface to anything, and if it does need changing, the human-readable-code level has so few interaction points it's trivial to change interfaces. Hell, even in the case where a lot of interface changes would be necessary, we could probably just write a Racket program to chop up the S-expressions for us.
The mathematics library is also very good, providing a lot of intuitive, high-performance primitives that fit our data crunching needs. And we're currently investigating using the Prolog-like Datalog language mode
And the performance is extremely good, especially if you're coming from the Python/PHP/Ruby world. I find it as expressive as Python (actually, translating Python programs is nearly 1-to-1) but with performance more like static C#. The optimizer is very good and there is a typed version of Racket that gets optimized even more. Yeah, you should use Racket even if you don't plan on learning macros, because it's as easy as Python and its a lot faster.
All along the way. Graphics primitives: standard library feature. Parallel code: super-simple, very solid, and built in. Linear algebra: very solid, very easy to use (almost as easy as basic primitives) and again, built in. Distributed package management: built-in, it's part of the regular import syntax. Racket-to-JavaScript translator: well, not quite built in yet, but the package manager might as well let you treat it as so. Cross-platform compatibility: haven't had a single issue getting people on Linux, OS X, and Windows up and running with development yet.
If you've ever tried getting Scala or Clojure or Ruby setup on your own, Racket blows them out of the water.
I'm not terrible certain the fundamental premise of the project is sound, but at the end of the year we're going to have something of value on our hands, whether it's the raw data of the knowledge base or the development tools. Racket doesn't just let us build proof-of-concepts fast, it lets us expand them into heavy-lifting mode pretty quick, too.
I did try to go with Clojure at first, but found the entire ecosystem to be very haphazard. I already knew that Racket was easy to install and easy to use, so when I started running into trouble with getting Clojure to run on Windows and Linux (it seems it is super easy if you're on OS X, but eff that noise). Also, there was no one setup with Clojure. It was clear that Clojure without Leiningen was half a product, and I consider Leiningen to be a terrible piece of software.
As for learning resources for Clojure, that was another area where I felt like Racket won out. The Racket community is very, very friendly and extremely knowledgable, and the documentation at racket-lang.org is (mostly) extremely good. The sections on macros and continuations seems like they were written by someone with intimate mathematical knowledge of the issues, but not a lot of understanding of what beginners go through, but there are other sites (Scribble-based, even!) that do a better job of explaining the features.
And yeah, I didn't want to be tied to the JVM. Clojure ends up slightly slower than raw Java because of the need to emulate certain Lispy features, and years of Java AND C# development have given a very poor opinion of the JVM. Sure, there are more libraries available, but just how many do you need? There are some holes in Racket's library ecosystem, but it's been fun trying to fill them in and I think it's a site better scenario than having 15 different ORMs to choose from, and none of them are very good.
With Clojure, I had to install a JVM, then Clojure, then Leiningen, then plugins for Vim or Emacs or whatever, then a dozen and a half dependencies for the web framework, a lot of which are still in beta, have interface-breaking changes, and the documentation hasn't kept up. It was a nightmare of poorly executed distribution, something that drives me up a wall.
With Racket, you install Racket. It has other dependencies that it needs, but it handles it because it has a real installer. You can use Vim or Emacs if you want, but you don't have to right away. You import web-based dependencies in almost the exact same way you import standard libraries. In fact, you can even do it in the same require statement:
(require net/smtp ;; standard library for interfacing with a sendmail server
(planet mordae/couchdb:1:11) ;; a reference to a specific version of a CouchDB API from a specific user
(planet xtofs/firmata/firmata)) ;; a reference to whatever is the latest version of "Firmata", a library for Arduino programming.If you do write or have written more about your experiences, please let me know .. my username at gmail . com
https://github.com/capnmidnight/philly_mud
I don't really blog that much, and when I do it's not usually about programming. Maybe I should...
or G+: https://plus.google.com/u/0/100282968888030008096/posts
The posts will show up on Tumblr and get linked on G+, but I'm not a huge fan of Tumblr's dashboard system.