;;;; raylib [models] example - box collisions
;;;;
;;;; examples/models/models_box_collisions.c. The previous lane's finding was
;;;; that the whole models category is refused by the importer for want of a
;;;; defstruct, and that a models example is therefore mostly a binding
;;;; exercise. That is true of the twenty that load a Model — but not of this
;;;; one, which is why it is here: nothing in it is a Model, a Mesh or a
;;;; Material. It is two cubes, a sphere and one aggregate the package did not
;;;; describe.
;;;;
;;;; That aggregate is BoundingBox, and it is two Vector3s and nothing else —
;;;; no owned pointer, no array, no lifetime. One `defstruct` in
;;;; vendor/raylib/raylib.fln un-refuses four raylib functions at once
;;;; (CheckCollisionBoxes, CheckCollisionBoxSphere, DrawBoundingBox and
;;;; GetRayCollisionBox), and that is the cheapest widening of the 3D surface
;;;; available anywhere in the tree. Ray and RayCollision went in beside it
;;;; for examples/core-3d-picking.fln and for the same reason.
;;;;
;;;; So the answer to "is a models example just a binding exercise" is: the
;;;; ones that need Model are, and this one is the counterexample. What
;;;; separates them is not the category, it is whether the struct owns memory.
;;;;
;;;; What it also exercises, and what needed hand-writing rather than
;;;; generating: draw-cube-v, draw-sphere and draw-sphere-wires. All three
;;;; were in the generated half already, and all three moved to the
;;;; hand-written one here on `bindings`'s own rule — they are inside a frame,
;;;; in an example that ships in examples/. draw-cube-v in particular was
;;;; named there as generated *because nothing called it*; something calls it
;;;; now.
;;;;
;;;; The collision maths is written twice in the C, once per test, building
;;;; the player's box inline both times. It is a function here for the reason
;;;; the eyes example gives: two copies of the same eight expressions cannot
;;;; be checked against each other by reading them.

import rl "vendor:raylib"

const screen-width = 800
const screen-height = 450

once camera: rl/Camera3D

once player-position: rl/Vector3
once player-size: rl/Vector3
once player-color: rl/Color

once enemy-box-pos: rl/Vector3
once enemy-box-size: rl/Vector3
once enemy-sphere-pos: rl/Vector3

const enemy-sphere-size: f32 = 1.5

;; A box centred on `centre` with the given extents. raylib's BoundingBox is
;; min-corner/max-corner, not centre/size, and every collision call in the
;; family takes the corner form — so this is the conversion the C writes out
;; longhand at each of its two call sites.
;;
;; It used to be eight expressions of field arithmetic here too; it is the
;; half-extent subtracted and added now that the package carries vector
;; arithmetic — see vendor/raylib/vector.fln, which is Flan and not C
;; because raymath is `static inline` and has no symbol to bind.
fn box-around(centre: rl/Vector3, size: rl/Vector3) -> rl/BoundingBox
  let half = rl/v3-scale(size, 0.5)
  rl/BoundingBox{.min rl/v3-sub(centre, half) .max rl/v3-add(centre, half)}

fn main() -> ()
  rl/init-window(screen-width, screen-height,
                 "raylib [models] example - box collisions")
  defer rl/close-window()
  ;; The C writes this camera as a brace initialiser with a trailing 0 for the
  ;; projection, which is CAMERA_PERSPECTIVE. Named here, because the enum
  ;; exists precisely so that the 0 does not have to be remembered.
  camera = rl/Camera3D{.position rl/Vector3{.x 0.0 .y 10.0 .z 10.0} .target rl/Vector3{.x 0.0 .y 0.0 .z 0.0} .up rl/Vector3{.x 0.0 .y 1.0 .z 0.0} .fovy 45.0 .projection :projection-perspective}
  player-position = rl/Vector3{.x 0.0 .y 1.0 .z 2.0}
  player-size = rl/Vector3{.x 1.0 .y 2.0 .z 1.0}
  player-color = rl/green
  enemy-box-pos = rl/Vector3{.x -4.0 .y 1.0 .z 0.0}
  enemy-box-size = rl/Vector3{.x 2.0 .y 2.0 .z 2.0}
  enemy-sphere-pos = rl/Vector3{.x 4.0 .y 0.0 .z 0.0}
  rl/set-target-fps(60)
  until rl/window-should-close()
    ;; Update. The arrow keys move on the XZ plane, and the C's else-if chain
    ;; means only one direction applies per frame — diagonal movement is not
    ;; possible, deliberately.
    if rl/is-key-down(:key-right)
      player-position.x += 0.2
    elif rl/is-key-down(:key-left)
      player-position.x -= 0.2
    elif rl/is-key-down(:key-down)
      player-position.z += 0.2
    elif rl/is-key-down(:key-up)
      player-position.z -= 0.2
    let player-box = box-around(player-position, player-size)
    let hit = rl/check-collision-boxes(player-box, box-around(enemy-box-pos, enemy-box-size)) or rl/check-collision-box-sphere(player-box, enemy-sphere-pos, enemy-sphere-size)
    player-color = (if hit then rl/red else rl/green)
    ;; Draw
    rl/with-drawing:
      rl/clear-background(rl/raywhite)
      rl/with-mode-3d(camera):
        rl/draw-cube(enemy-box-pos, enemy-box-size.x, enemy-box-size.y,
                     enemy-box-size.z, rl/gray)
        rl/draw-cube-wires(enemy-box-pos, enemy-box-size.x, enemy-box-size.y,
                           enemy-box-size.z, rl/darkgray)
        ;; draw-sphere is draw-sphere-ex at 16 rings and 16 slices; the wires form
        ;; takes them because the tessellation is only visible in the wireframe.
        rl/draw-sphere(enemy-sphere-pos, enemy-sphere-size, rl/gray)
        rl/draw-sphere-wires(enemy-sphere-pos, enemy-sphere-size, 16, 16,
                             rl/darkgray)
        rl/draw-cube-v(player-position, player-size, player-color)
        rl/draw-grid(10, 1.0)
      rl/draw-text("Move player with arrow keys to collide", 220, 40, 20,
                   rl/gray)
      rl/draw-fps(10, 10)