vendor/raylib/modes.flan: five macros over the five pairs the package binds -- with-drawing, with-mode-2d, with-mode-3d, with-texture-mode, with-scissor-mode. A second file with no declare-c in it, split out on vector.flan's reasoning: raylib.flan is the package's statement about C and nothing here names C, so nothing here can be made wrong by raylib changing. Each expands to (do (begin-... args) body... (end-...)) -- the calls the author used to type, in the order they typed them. No let, no gensym: nothing binds a name, so there is nothing for a caller's name to collide with. What it removes is the End* that is missing, wrong, or no longer beside its Begin*. What it cannot remove is a body leaving through the unwind path: a return or an invoke-restart skips the rest of the do and the End* with it. defer is the obvious fix and is refused inside a loop body, which is where a pair always lives -- checked, not assumed. So sand.flan's discipline stays: keep the restart boundary outside the pair. 35 call sites converted across examples/ and sand.flan. The one left is core-scissor-test.flan, whose Begin and End sit in two separate `when`s with the drawing between them -- a conditional pair is a shape a bracketing macro cannot express. test/programs/rl-with.flan covers with-scissor-mode, which no example can, with a frame function unreachable from main so it needs no libraylib; rl-with-reject.flan is the arity half.
61 lines
2.4 KiB
Plaintext
61 lines
2.4 KiB
Plaintext
;;;; raylib [core] example - input mouse
|
|
;;;;
|
|
;;;; examples/core/core_input_mouse.c. Needed three new bindings — show-cursor,
|
|
;;;; hide-cursor and cursor-hidden? — which are now in vendor/raylib.
|
|
;;;;
|
|
;;;; The C's `else if` chain over the seven mouse buttons is a `cond` here.
|
|
;;;; That is not a workaround: `cond` is what Flan has and it is the same
|
|
;;;; first-match-wins shape, with `:else` where C falls off the end. The order
|
|
;;;; matters in both — two buttons pressed on the same frame give the earlier
|
|
;;;; one, which is the C's behaviour and not an accident of the port.
|
|
;;;;
|
|
;;;; The colour has to be a `defvar` rather than a `let`, for the reason
|
|
;;;; core-input-keys' position does: it is state between frames.
|
|
|
|
(import rl "vendor:raylib")
|
|
|
|
(defconst screen-width 800)
|
|
(defconst screen-height 450)
|
|
|
|
(defvar ball-color rl/Color)
|
|
|
|
(defn main [] ()
|
|
(rl/init-window screen-width screen-height
|
|
"raylib [core] example - input mouse")
|
|
(defer (rl/close-window))
|
|
|
|
;; The C also initialises the ball's POSITION, to {-100,-100} so it starts
|
|
;; off-screen. That is dead there and is not here: the first thing the loop
|
|
;; does is overwrite it with get-mouse-position, before anything is drawn.
|
|
(set ball-color rl/darkblue)
|
|
|
|
(rl/set-target-fps 60)
|
|
|
|
(until (rl/window-should-close?)
|
|
;; Update
|
|
(when (rl/key-pressed? :h)
|
|
(if (rl/cursor-hidden?) (rl/show-cursor) (rl/hide-cursor)))
|
|
|
|
(let [ball (rl/get-mouse-position)]
|
|
(set ball-color
|
|
(cond
|
|
(rl/mouse-button-pressed? :left) rl/maroon
|
|
(rl/mouse-button-pressed? :middle) rl/lime
|
|
(rl/mouse-button-pressed? :right) rl/darkblue
|
|
(rl/mouse-button-pressed? :side) rl/purple
|
|
(rl/mouse-button-pressed? :extra) rl/yellow
|
|
(rl/mouse-button-pressed? :forward) rl/orange
|
|
(rl/mouse-button-pressed? :back) rl/beige
|
|
:else ball-color))
|
|
|
|
;; Draw
|
|
(rl/with-drawing
|
|
(rl/clear-background rl/raywhite)
|
|
(rl/draw-circle-v ball 40.0 ball-color)
|
|
(rl/draw-text "move ball with mouse and click mouse button to change color"
|
|
10 10 20 rl/darkgray)
|
|
(rl/draw-text "Press 'H' to toggle cursor visibility" 10 30 20 rl/darkgray)
|
|
(if (rl/cursor-hidden?)
|
|
(rl/draw-text "CURSOR HIDDEN" 20 60 20 rl/red)
|
|
(rl/draw-text "CURSOR VISIBLE" 20 60 20 rl/lime))))))
|