The idea that you functionally compose images like this:
(place-image image-1 x y
(place-image image-2 x y
(place-image image-3 x y)))
Which draws image1 on top of image2 on top of image 3, which is backwards from
the "painters order" that would draw image 3, then image 2, then image 1.
This imperative, side-effect-ing code is a little less clear to a beginner with
the OOP and DC concepts, but It better represents what actually happens, and it
is much easier to modify the code without worrying about the nesting.
(send dc draw-bitmap imag3 x y)
(send dc draw-bitmap imag2 x y)
(send dc draw-bitmap imag1 x y)
-----Original Message-----
From: racket-users@googlegroups.com [mailto:racket-users@googlegroups.com] On
Behalf Of David Grenier
Sent: Monday, August 24, 2015 1:14 PM
To: Racket Users
Cc: John Carmack
Subject: [racket-users] Re: My son's game in Racket
On Monday, August 24, 2015 at 12:28:07 PM UTC-4, John Carmack wrote:
> We “released” my 10 year old son’s game that was done in Racket:
> www.1k3c.com
>
>
>
> I’m still taking a little heat from my wife for using an obscure
> language instead of something mainstream that is broadly used in industry,
> but I have nothing but good things to say about using Racket and DrRacket for
> a beginning programmer, and highly recommend it.
>
>
>
> I can’t recommend 2htdp/universe for this sort of thing, though. I
> had to drop to the native GUI bitmaps for performance reasons, hack around
> the lifecycle to support a separate editor window, and I still don’t know how
> to make the Quit menu item actually exit the app on the Mac version.
>
>
>
> I completely understand the reasoning for the way 2htdp/universe is
> built, and saying that a “real” project should use the grown-up APIs is fine,
> but the evolution from making a little animation to controlling it somehow to
> fleshing it out into a game is so natural that recommending a fairly big
> rewrite is unfortunate.
>
>
>
> I’m a big booster of functional programming, but I’m not sure that the
> functional drawing paradigm ever really sank in while my son was working with
> it, rather it felt like you just drew everything backwards with missing
> parenthesis at the end. I suspect that using the standard imperative GUI
> drawing code will make perfect sense to him.
>
>
>
> I’m not sure yet if we are going to migrate to the regular GUI code for
> upcoming work, or jump all the way to OpenGL so he can learn the joys of “Why
> is the screen all black?”
>
>
Not clear what was meant both times you wrote "backwards" are you referring to
the lisp-style function call? Something that could be alleviated by say F#'s
pipe forward operator?
let (|>) a f = f a
or Clojure's -> macro?
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit
https://urldefense.proofpoint.com/v1/url?u=https://groups.google.com/d/optout&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=Kjg6LltY9QjkipKooaVldA%3D%3D%0A&m=HArZE0M9OqU4wspKLzQzG6N5gO9ncSxPP9qVzkUgoVU%3D%0A&s=b451faca736dc42c554f148983e7279865ef32be9ddf2df75f5c88c15dd34a73.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
