cudoku/todo.txt

- "premade" (but also customizable) ui elements (buttons, text boxes, etc) with instanced rendering
- border decorations for shapes (maybe. or maybe only for ui elements)
- some kind of ui layout/hierarchy system (for later, when we actually need it)
- grid texture (draw_image? or draw_texture? func)

- sooo a bit of a problem... since we render all our text in one draw call
  at the end of the frame. this means that we can't have text that's rendered
  in behind anything else. This needs to be fixed because drawing any overlay
  will result in all the text being drawn OVER everything else, which might not be
  the desired behavior at times (e.g. help/win overlay where the board numbers need to be
  rendered under the overlay(s))
  - possible solutions :Clueless:
    - z-index based on the order of creation (e.g. the first drawable created has the lowest z-index)
      I _think_ this works because we can just chuck a global z-index whenever we call
      draw_text or draw_quad/etc.. and the shader _should_ take care of everything
    - every draw_text call actually makes a single draw call (compromises on performance but way easier to use)


text rendering improvements
  - [ ] unicode support (allows for non-ascii characters)
    - unicode support removed for the foreseeable future
  - [x] atlas texture for text glyphs (this means we only load in one texture for all text)
    - [x] better estimation of atlas width and height (currently the generated atlas texture
          has a lot of empty space (over 50% of the texture's height))
       - ended up just looping over the ascii glyphs and finding the max width and height

  - SDF generation allowing for better text scaling (slower but visually better)
    - SDF is too slow if we want to support unicode. it's acceptably fast for ascii only though.
    - An alternative is to use MSDF at a much lower pixel height (e.g 16) which results in
      better scaling than SDF (almost perfect) and is fast enough to include unicode.
    - Another alternative is using a pre-baked SDF texture atlas. This is the fastest
      but it's also the least flexible because we can't load arbitrary fonts
    - Maybe also rendering text as vector using bezier curves. Sounds like a lot of work though.

      Will probably end up using MSDF (if I can get it to work with C lol)

  - [x] instanced rendering for text (this means we only have to do one draw call for all text)
    running into problems. we got the positions to instance correctly but the texture coordinates
    are more difficult to work with because we can't just send a texcoord per vertex per instance
    - Ended up passing hardcoded texcoords of all glyphs to the shader using a uniform array which allows us to render infinite
      instances of text in one draw call without exceeding any buffer limits. Of course this does mean that if we were to support
      unicode we'd have to make the uniform array bigger and its size dynamic. So unicode is dropped for now