Notes related to current WIP activity and plans for the future.

• solid error handling
• 100% test coverage again
• working GPU lib POC

• gpu-lib
• separate render pass handle used to set viewports, bind buffers etc.
• next up: vertex and index buffers

• separate kiba into different libs e.g.:
  • kiba-core
  • kiba-format
  • kiba-gpu
  • etc.
• font rendering -> basic UI framework

Command buffers are created from pools which are created for a specific queue. There are two ways to go about command recording. All command buffers work on the same queue. That would allow for immediate translation into commands for the buffer. Alternatively commands could be recorded to an intermediate format. That would allow for grouping/reordering of commands as well as distributing them on separate queues. The first approach will be used for now, but it could be fun to investigate the other approach once the project is more mature.

Currently all resources' destroy function enqueues them for destruction on the device. After two device updates the resources are destroyed. That assumes the user was sure that the resources could technically be destroyed once on the fly work completed.

Perhaps it would be better to hierarchically associate resources with each other e.g.:

• texture view -> texture
• pipeline -> pipeline layout
• pipeline -> shader

etc. The device update would, as an example, decrement a ref count for associated objects. If that falls to 0, destroy the associated object. That would be a safer way to handle lifetime but would require atomic ref counting.

The first approach should be faster but less flexible. Perhaps even wrong when it comes to work that takes > 1 frame to execute, especially with regards to compute work. The latter approach introduces complexity and most likely a performance hit as a trade-off for correctness. Requires more elaborate POC with compute work to test this out.

Create multiple windows and have particles emitted from the center of each window. The particles travel to the center point of the next window, treating each window as a viewport into a shared space. That means moving a window will cause the particles traveling to/from that window to alter their movement.

Just a "simple" overview of my finances being classified in a hierarchy of categories to be able to analyse average expenses, budget for certain aspects of life etc. Requires nice text rendering, UI of some kind, and graphs.

Render images as a grid of Spindas, using their unique spot patterns to represent the underlying image. Could split the image into color components and overlay the component-spindas into a single one to achieve color images.

Render images as ASCII characters. Potentially with color.

Render objects as if they were printed by a 3D printer. That means layerlines of configurable height which would essentially resemble the slicer output. A gcode renderer would also be cool, though pobably more complex.