rendertarget_attach(3)

πŸ“¦
version 0.7.1 Β· 2 versions
, in nixos 26.05

πŸ’… rendertarget_attach β€” bestie edition

okay so this is a page from the Arcan Lua API manual, and it's basically about rewiring which video object hangs off which rendertarget. yes it's as iconic as it sounds. let's go πŸŽ€


✨ NAME ✨

rendertarget_attach β€” modify the attachment statement of a video object πŸ’–


πŸ¦‹ SYNOPSIS πŸ¦‹

nil
rendertarget_attach( rendertarget, source, detach_state )

like, that's literally the whole call signature right there. no cap. ✨


🌸 DESCRIPTION 🌸

so every video object has at least one connection to a rendertarget β€” that's its primary one β€” and honestly it can have a bunch more (those are the secondary ones, connecting it to other rendertargets too). 🫢

the primary connection is the main character here, because it also defines lifespan. meaning: if the object acting as the primary connection gets deleted, everything else attached to it gets deleted too. gone. poof. 😭 so yeah, that association matters a lot, and you can change it either when you're creating new rendertargets or dynamically using this very function. slay.

  • rendertarget specifies the attachment point
  • source refers to the object that should be attached or detached
  • detach_state determines if the primary attachment should be reassigned (RENDERTARGET_DETACH) or kept (RENDERTARGET_NODETACH)
⚠️ okay this part is important, don't skip it: only WORLDID or a vid that has been previously flagged as a rendertarget (using define_rendertarget or define_calctarget or define_recordtarget) are valid values for rendertraget. yes, the original really does spell it rendertraget there. we love a typo. πŸ’€

πŸ‘‘ NOTES πŸ‘‘

  1. relative properties (scale, position etc.) are all defined against the current primary rendertarget, and they are not recalculated on attach/detach operations. the common pattern for handling objects that should have the same storage but live inside different rendertargets is:
    • use null_surface to create a new container,
    • then image_sharestorage to make sure source and the new object have the same backing store,
    • and then finally
    • rendertarget_attach the new object with RENDERTARGET_DETACH.
  2. (this one is literally blank in the original, so. enjoy the vibes πŸ“)
  3. deleting an object also implies detaching it from all rendertargets. it's giving automatic cleanup. ✨
  4. a rendertarget cannot be attached to itself. no self-attachment, we don't do that here. πŸ™ˆ
  5. objects that have been flagged as persistant cannot be part of other rendertargets. periodt.

πŸ”₯ EXAMPLE πŸ”₯

here's the whole thing, verbatim, because you know I'm not touching a single character of it:

function rendertarget_attach0()
      local rtgt = alloc_surface(VRESW, VRESH);
      resize_image(rtgt, 200, 200);
      local obj_a = color_surface(32, 32, 0, 255, 0);
      show_image({rtgt, obj_a});
      define_rendertarget(rtgt, {obj_a});
      local new_obj = color_surface(64, 64, 255, 0, 0);
      show_image(new_obj);
      move_image(new_obj, VRESW * 0.5, VRESH * 0.5);
      rendertarget_attach(rtgt, new_obj, RENDERTARGET_NODETACH);
end

look at that. iconic. πŸ’…


🌈 SEE ALSO 🌈

iykyk β€” go read those next, bestie. 🧚


okay that's the whole page!! this one comes courtesy of targetcontrol, dated October 2026 β€” so like, future vibes only. mwah πŸ’œπŸŒΈβœ¨

πŸ“¦ where this page comes from