diff --git a/vendor/raylib/generated.flan b/vendor/raylib/generated.flan
index 9d09d65..56ec50e 100644
--- a/vendor/raylib/generated.flan
+++ b/vendor/raylib/generated.flan
@@ -199,7 +199,6 @@
 (declare-c image-draw-text [dst (Ptr Image)  text string  pos-x i32  pos-y i32  font-size i32  color Color] "ImageDrawText")
 (declare-c image-draw-text-ex [dst (Ptr Image)  font Font  text string  position Vector2  font-size f32  spacing f32  tint Color] "ImageDrawTextEx")
 (declare-c load-texture-cubemap [image Image  layout i32] Texture2D "LoadTextureCubemap")
-(declare-c update-texture [texture Texture2D  pixels (Ptr u8)] "UpdateTexture")
 (declare-c update-texture-rec [texture Texture2D  rec Rectangle  pixels (Ptr u8)] "UpdateTextureRec")
 (declare-c gen-texture-mipmaps [texture (Ptr Texture2D)] "GenTextureMipmaps")
 (declare-c set-texture-wrap [texture Texture2D  wrap i32] "SetTextureWrap")
@@ -230,7 +229,6 @@
 (declare-c get-codepoint-count [text string] i32 "GetCodepointCount")
 (declare-c get-codepoint [text string  codepoint-size (Ptr i32)] i32 "GetCodepoint")
 (declare-c get-codepoint-next [text string  codepoint-size (Ptr i32)] i32 "GetCodepointNext")
-(declare-c get-codepoint-previous [text string  codepoint-size (Ptr i32)] i32 "GetCodepointPrevious")
 (declare-c text-is-equal [text-1 string  text-2 string] bool "TextIsEqual")
 (declare-c text-length [text string] u32 "TextLength")
 (declare-c text-split [text string  delimiter i8  count (Ptr i32)] (Ptr (Ptr i8)) "TextSplit")
diff --git a/vendor/raylib/raylib.flan b/vendor/raylib/raylib.flan
index bd2b447..d121c4d 100644
--- a/vendor/raylib/raylib.flan
+++ b/vendor/raylib/raylib.flan
@@ -589,6 +589,37 @@
 
 (declare-c unload-texture [texture Texture2D] "UnloadTexture")
 
+;; Refilling a texture's pixels from a CPU-side buffer.
+;;
+;; Both of these are hand-written and both call UpdateTexture, which is the
+;; whole of what a `void *` parameter is: raylib does not care what the buffer
+;; is an array *of*, only that it is the right number of bytes in the format
+;; the texture was made with. `cimport.ml` has to render that `void *` as
+;; something and renders it `(Ptr u8)`, so the generated line could only ever
+;; offer one of the two faces, and the one it picked is the wrong one for the
+;; commonest caller: LoadImageColors answers `(Ptr Color)` and handing that
+;; straight on is what the C does.
+;;
+;; So the package says both, under two names, and the header check now agrees
+;; with both — a `void *` is opaque about its element type by construction, so
+;; there is no disagreement there for it to report (lib/cimport.ml's
+;; [ptr_agrees]). Before that arm existed the call site had to spell the cast
+;; by hand as `(addr (.r (at (slice-from-ptr pixels n) 0)))` — the address of
+;; the first field of the first element, which is the right address and reads
+;; like an apology.
+;;
+;; Neither one checks that the buffer is big enough, because neither can: the
+;; length raylib wants is width * height * bytes-per-pixel of the *texture*,
+;; and a pointer has no length. That is the same deal every raylib pointer
+;; parameter offers.
+(declare-c update-texture
+  [texture Texture2D  pixels (Ptr u8)]
+  "UpdateTexture")
+
+(declare-c update-texture-colors
+  [texture Texture2D  pixels (Ptr Color)]
+  "UpdateTexture")
+
 ;; How a texture is sampled when it is drawn at anything other than its own
 ;; size. The header says `int` on SetTextureFilter and means one of these six.
 ;;
@@ -1499,3 +1530,36 @@
 ;; no owning array type to give that to — a (Ptr GlyphInfo) with a separate
 ;; count is what the language would force, which is the C API with the safety
 ;; removed rather than a binding.
+
+;; ── One codepoint backwards ─────────────────────────────────────────
+;;
+;; The one entry point in raylib that reads *backwards* from the pointer it is
+;; handed, and therefore the one that a Flan `string` must never reach. The
+;; shim crosses a string as ptr+len in and a NUL-terminated *copy* out, so the
+;; bytes in front of what C receives belong to the allocator; GetCodepointNext
+;; beside it never notices, because it only reads forwards. GetCodepointPrevious
+;; reads the copy's prefix — which is somebody else's memory — and answers 0,
+;; which is also its answer for genuinely malformed UTF-8. Nothing in the
+;; result tells the two apart. docs/PORTING.md §A.1 is the whole story.
+;;
+;; So the declaration says `(Ptr u8)` and means it. That is a hand-written line
+;; over a `const char *` the importer would have rendered as `string`, which is
+;; exactly the case lib/cimport.ml's [ptr_agrees] exists for, and the generated
+;; half no longer carries the string-faced version at all — a binding that is
+;; wrong for the only direction it reads in is worse than no binding.
+(declare-c get-codepoint-previous-raw
+  [text (Ptr u8)  codepoint-size (Ptr i32)] i32
+  "GetCodepointPrevious")
+
+;; The face a caller wants: the bytes and an offset into them, rather than an
+;; interior pointer they had to build. `at` bounds-checks the offset, which is
+;; the one thing the raw call cannot do for itself.
+;;
+;; `offset` is where the *next* codepoint starts; the answer is the codepoint
+;; before it and `codepoint-size` is that one's length in bytes, so the
+;; previous offset is `offset` minus what comes back through the pointer. At
+;; offset 0 there is nothing behind it and raylib is not asked.
+(defn get-codepoint-previous [text [u8]  offset i32  codepoint-size (Ptr i32)] i32
+  (if (<= offset 0)
+    (do (set (deref codepoint-size) 0) 0)
+    (get-codepoint-previous-raw (addr (at text offset)) codepoint-size)))