rdunnington / rjd Goto Github PK

Still need tests for:

• rjd_math_mat4
• rjd_geo_sphere_sphere
• rjd_geo_sphere_box
• rjd_geo_box_box
• rjd_geo_ray_point
• rjd_geo_ray_sphere
• rjd_geo_ray_box
• rjd_geo_ray_boxfast

Could potentially adapt tests from:

• https://github.com/walbourn/directxmathtest
• https://github.com/walbourn/directxtktest
• https://aka.ms/atgsplcollision

When I wrote this initially I didn't fully understand how the slotmap worked. The internals need a rework. Can look to zig-slotmap for an example.

Currently you can use slot handles allocated from one map with a different map. Think about adding a pointer to the associated slotmap in debug to avoid mixing slotmaps? Could also be a sentinel value if less than 8 bytes is desired.

Right now there's no way to configure sampler settings other than editing the hardcoded ones in both D3D11 and Metal backends. We should expose a way to create a sampler state and bind it to a texture when issuing draw commands.

Ensure both metal and d3d11 support stencil attachments when drawing.

You could build a profiler using this, but the scope of this lib is to define a platform-independent high resolution timer, not a general-purpose instrumented or sampling profiler.

The debug layer is always on for D3D11 and Metal. It should default to off and have an option to turn it on via the context_desc. Same with shaders.

Basically a cross-platform way to register for a watch on file changes for a given set of files/folders. Poll to get latest changes.

Less macros is better. Let's replace RJD_RESULT_OK() with an inline function that returns an empty rjd_result, equivalent to what the macro does:

static inline rjd_result_ok(void)
{
    return (struct rjd_result){0};
}

rjd should have some basic functionality to load obj and/or GLTF files and such. Some potential samples:

• nontextured teapot
• textured model
• sponza scene

Currently the shader_create() function only takes uncompiled shaders. It should have an option to consume precompiled shaders as well.

Some feedback from Chad:

I didn't want to have to specify a capacity for my array upfront. I tried a capacity of 0 and got an assert :( Main reason is that I didn't know what the capacity would be. Second reason is I wasn't sure if capacity implied static size or dynamic size.

Metal has support for a depth buffer associated with the backbuffer out of the box. But D3D11 and DXGI only have color buffer support.

The API theoretically supports this but it's untested and probably broken in Metal. The D3D11 backend doesn't support it at all yet. The implementation should be pretty straightforward though.

rjd_istream is buffered, but rjd_ostream isn't. Ideally these APIs would mirror each other in capability and let you choose to use buffering or not.

Currently everything is written assuming you're building for debug. Logging and extra validation checks are on. There should be a RJD_DEBUG macro and corresponding rjd_debug_on() function to help systems determine if they should remove extra debug checks or not.

Metal supports MSAA out of the box. However, in D3D11 the FLIP_DISCARD mode of presenting doesn't support MSAA. We need to render to an offscreen render target that does support MSAA, then copy the image over to the backbuffer immediately before presenting.

Some feedback from Chad:

I was confused by the existence of rjd_mem_alloc_array and rjd_array_alloc
I think the confusion is between mem_array and array. Which one should I use when? From reading the code it looks like mem_*_array is an implementation detail of the array functions and so it shouldn't be used explicitly.... But I say that with only a cursory glance at the code.
Hmm... You could go the other route and have the default mem_alloc require nitems and itemsize like calloc.
If a user wants a "block" of generic bytes you could have a mem_alloc_block(numbytes)
I like reserving the array keyword for interactions with the dynamic array

It's too easy to allocate with one function and free with the other. Each container should have a magic number in the header to help the user quickly identify any alloc/free mismatches.

It compresses code and has the potential to be slightly more optimal.

What's the license for the code in this library?

A platform-independent file watching library. Ideally you pass it a directory to watch, then periodically poll it to see what's changed. Maybe something like

rjd_result rjd_filewatcher_start(struct rjd_filewatcher* watcher, const char* path, struct rjd_filewatcher_options);
void rjd_filewatcher_stop(struct rjd_filewatcher* watcher);
rjd_result rjd_filewatcher_poll(struct rjd_filewatcher* watcher, struct rjd_filewatcher_changes* changes);

Both Metal and D3D11 backends assume when you upload a texture it only has 1 mip. The interface should expose options to upload multiple mips.

Right now the interface of RJD_RESULT lets you pass a runtime string, but we should assert it's of the form "Some error" to avoid this mistake.