Skip to content
Snippets Groups Projects
  1. Jul 09, 2023
    • Niklas Haas's avatar
      shaders: add GLSL macro preprocessor · 938b95a9
      Niklas Haas authored
      After a long deliberation period, I settled on this design to improve
      both the workflow of writing shaders, as well as runtime performance of
      shader generation.
      
      To integrate our own #pragma GLSL into the compilation, we need to
      preprocess C sources using a python script, with a horrible hand-written
      regex-based parser.
      
      Should mostly work. Hopefully.
      938b95a9
  2. Apr 25, 2023
    • Niklas Haas's avatar
      .gitignore: add .cache · 18a8dc1e
      Niklas Haas authored
      Used by clangd. I could enable this locally, but other users might also
      benefit from this down the line, so might as well add it globally.
      18a8dc1e
  3. Feb 13, 2023
  4. Apr 04, 2021
  5. Mar 17, 2021
    • Niklas Haas's avatar
      demos: refactor components and integrate into build system · c6f9fb97
      Niklas Haas authored
      Major refactor of the demos/ directory, accomplishing a number of goals:
      
      1. Allowing easy switching between OpenGL and Vulkan variants.
      2. Supporting both GLFW and SDL2, chosen at compile time. The window
         management itself was made entirely modular for this purpose.
      3. Refactor all of the demo programs atop these new abstractions.
      4. Building them correctly and automatically (via meson).
      
      I also plan on factoring out the nuklear code to its own helper, but I
      avoided making that part of the same commit to prevent it from blowing
      up any further.
      c6f9fb97
  6. Mar 03, 2021
    • Niklas Haas's avatar
      demos: add nuklear UI example · da42e00d
      Niklas Haas authored
      Mostly a shitty proof concept, but it runs.
      
      I plan on expanding this demo in the future, but for now it works as a
      sufficient stand-alone example, so I want to get it merged.
      da42e00d
    • Niklas Haas's avatar
      demos: factor common GLFW code out of demos · 565a532b
      Niklas Haas authored
      This simplifies the demos to focus on their specific logic rather than
      the window creation boilerplate, and also allows me to expand the amount
      of demos without needing to re-duplicate this logic over and over again.
      565a532b
  7. Nov 18, 2020
    • Niklas Haas's avatar
      demos/plplay: add proof-of-concept libavcodec-based player · 63ec8425
      Niklas Haas authored
      As the comments at the top say, this is extremely shitty and rushed.
      Proper path for refactors:
      
      - Split up into separate files, modularize the GL/VK components and load
        the correct one at runtime.
      
      - Split up rendering onto a separate rendering thread, make it take into
        account timing etc. properly.
      
      - Move it into its own directory structure and give it a meson.build.
      
      Once this is done, we could use this as a test-bed for testing e.g.
      interpolation, and finally get that patchset moving along.
      63ec8425
  8. Feb 06, 2019
    • Niklas Haas's avatar
      demos: add new GLFW demo · 7c25280c
      Niklas Haas authored
      Similar to the SDL2 demo, except it doesn't actually do anything useful
      yet. Contains all of the boilerplate for setting up a GLFW window for
      use with libplacebo, though.
      7c25280c
  9. Oct 27, 2018
    • Niklas Haas's avatar
      demos: more misc improvements · 457e1fef
      Niklas Haas authored
      Clean up some of the old/redundant size calculations, move the actual
      work out to its own function, and more importantly also throw in some
      dithering. This should provide a more realistic scenario, since
      debanding without dithering is pretty pointless.
      
      Also add a gitignore and explain how to compile the thing.
      457e1fef
  10. Oct 26, 2018
    • Niklas Haas's avatar
      demos: add new extensive video filtering demo · 2ee1e9a4
      Niklas Haas authored
      This outlines multiple possible API styles from "simple and naive" all
      the way to a complicated zero-copy asynchronous streaming API design.
      
      Maybe in the future we could present a small benchmark to demonstrate
      the improvements in throughput that are obtained from API #2? For now,
      just put the code out there to serve as documentation.
      
      Completely untested. It compiles, but that's about it. I'll probably
      expand this sample to an actually working proof of concept state
      soon-ish.
      2ee1e9a4
  11. Jan 27, 2018
  12. Jan 18, 2018
  13. Oct 25, 2017
  14. Oct 07, 2017
Loading