Hi RandyGaul I created online documentation for cute_framework, using docsify.js, and customized the theme, and it looks pretty good, The cute_framework doc online address is here, if you think it's ok, I'll be happy to pull request

8:43 PM] Limyc: How can I check if I'm going to overflow the sg_buffer with the current batch? I'm rendering circles using batch_circle_line and I assert when I hit around 171 circles using an iter count of 10. It asserts at lower circle counts if I draw  higher resolution circles.
sg_append_buffer: overall appended size is bigger than buffer size
[8:44 PM] Randy: https://github.com/RandyGaul/cute_framework/blob/master/src/cute_batch.cpp#L391
[8:44 PM] Randy: it's hard coded for now
[8:45 PM] Randy: Feel free to add a simple function to adjust or get the buffer size
[8:50 PM] Limyc: okay, so for now, there's no way to check if adding something to the batch will exceed the buffer size. I'll need to write that myself
[8:51 PM] Limyc: Would it make sense for CF to split batches up automatically if they are too big?
[8:51 PM] Randy: https://github.com/RandyGaul/cute_framework/blob/master/src/cute_gfx.cpp#L120-L141
[8:51 PM] Randy: Well sokol_gfx is supposed to be dropping draw calls silently if you overflow
[8:52 PM] Randy: But maybe sokol_gfx was changed
[8:52 PM] Randy: And added that nice error message you found
[8:54 PM] Limyc: looks like you can define SOKOL_VALIDATE_NON_FATAL to silently drop overflowed calls
[8:54 PM] Randy: ah that sounds new to me
[8:54 PM] Randy: the perks of using actively maintained software 🙂
[8:56 PM] Limyc: Validation starts here: https://github.com/RandyGaul/cute_framework/blob/master/libraries/sokol/sokol_gfx.h#L15465
And asserts here: https://github.com/RandyGaul/cute_framework/blob/master/libraries/sokol/sokol_gfx.h#L13690
[8:56 PM] Limyc: Should I make an issue for this? If so, what exactly?
[8:57 PM] Randy: Make a pull request
[8:57 PM] Randy: Unless you want me to try and change things
[8:58 PM] Randy: Then go ahead and make an issue, you can just screenshot our convo here, or post in the relevant details
[9:00 PM] Limyc: okay, I'll make an issue then. I think it's worth considering friendlier ways to detecting and handling overflows instead of dropping the draw calls silently.
[9:01 PM] Limyc: I'm not sure how I'd use triple_buffer_append as the public CF api currently stands, and maybe that's the solution and there's just missing docs or an example 
[9:02 PM] Randy: the triple_buffer_apped is lower level
[9:02 PM] Randy: you shouldn't have to deal with it directly when using the batch api
[9:02 PM] Randy: I think not silently dropping the calls is a good thing
[9:03 PM] Randy: Just need to expose a getter/setter for the buffer size
[9:04 PM] Limyc: yeah, I'd rather have the assert than not. What's missing is an easy way to detect the overflow at draw time and handle it 

add this

struct entity_config_t
{
	const char* entity_name;
	array<const char*> component_types;
};

void app_register_entity_type(app_t* app, entity_config_t entity_config);

expose app context pointer audit code and look for other breakage points, such as function pointers or other statically stored pointers provide a reset all routine to patch in new pointers

Just use a static app context pointer -- nobody will ever use more than one app. No need to force it into the API everywhere. Credit to @apirux for the idea.

Right now the cmake options to turn off cryptography aren't implemented. This feature is a nice-to-have to simplify builds for non-networked games, or games that just don't want to deal with the cryptography dependency (even though it's not external).

Based on the suggestion by RoiG :)

The purpose is to add type safety to the system function pointer, making it difficult to crash in the event the entity composition is adjusted but the system has not yet been.

play_sound needs to return instances

instances need modulation in real time, especially the sample index

lifetime management needs to be well thought through

would be great to have cute framework compile from source without any dependencies in the minimal case. Not everyone wants networking features, and some people will want to use their own platform code

bool is hacked into kv as a string "true" or false" requiring quotes to be present should be natively supported as simply true or false when serialized

this would require a small refactor and extra parsing, but, definitely worth it

Use or expose scancodes as well so can pick physical layout — use case example: WASD for movement but user isn’t using QWERTY, needs to be a physical mapping.

Not sure how I want to do this. Need to think it through more.

Currently CF drops draw calls if too much data is requested to be sent to the GPU and issues a printed warning to stderr. This should work fairly well for development, but, an alternative may be much better.

Instead of dropping the draw call the vertices can be stored on the CPU in temporary memory, to be flushed to the GPU later. This would allow the entire system to handle temporary stalls in framerate, and simply render things a bit slower until the GPU catches up. The temporary overflow buffer can also fill up, at which point the entire CPU needs to hang and wait for the GPU, and a loud warning can be printed that to explain how the entire process is simply GPU bound.

What are we doing?

Converting cute_framework headers to be C compatible, while leaving an optional namespaced C++ API in place.

What work is remaining?

• [x] Prefix all types, functions, and globals with cf_
• [X] Remove the cute namespace from everything part of the C api
• [x] Wrap the namespaced c++ api inside #ifdef CUTE_CPP
• [x] Alias cf_ prefixed types inside namespaces with their original short name
• [x] Move member function implementations into free functions
• [x] Replace default arguments in functions
• [x] Rename overloaded functions with a numerical or type postfix
• [ ] Replace usage of templated types in C api
• [ ] Replace using statements with typedefs
• [x] Typedef all structs
• [ ] Surround C api with extern "C"
• [x] Add #ifdef CUTE_NO_CPP to cute_defines.h for C-only mode when compiling as C++
• [ ] Verify that all cute headers compile in a C99 project
• [ ] Verify that all changes compile using emscripten

Per-file progress

• [x] cute_a_star.h
• [x] cute_aabb_tree.h
• [x] cute_alloc.h
• [x] cute_app.h
• [x] cute_array.h
• [x] cute_aseprite_cache.h
• [x] cute_audio.h
• [x] cute_base64.h
• [x] cute_batch.h
• [x] cute_c_runtime.h
• [x] cute_circular_buffer.h
• [x] cute_clipboard.h
• [x] cute_color.h
• [x] cute_concurrency.h
• [x] cute_coroutine.h
• [x] cute_debug_printf.h
• [x] cute_defer.h
• [x] cute_defines.h
• [x] cute_dictionary.h
• [x] cute_doubly_list.h
• [x] cute_ecs.h
• [x] cute_error.h
• [x] cute_file_system.h
• [x] cute_file_system_utils.h
• [x] cute_font.h
• [x] cute_gfx.h
• [x] cute_handle_table.h
• [x] cute_haptics.h
• [x] cute_hashtable.h
• [x] cute_https.h
• [x] cute_image.h
• [x] cute_input.h
• [x] cute_joypad.h
• [x] cute_kv.h
• [x] cute_kv_utils.h
• [x] cute_lru_cache.h
• [ ] cute_math.h
• [x] cute_memory_pool.h
• [x] cute_networking.h
• [x] cute_png_cache.h
• [x] cute_priority_queue.h
• [x] cute_rnd.h
• [ ] cute_sprite.h
• [x] cute_string.h
• [x] cute_string_utils.h
• [x] cute_strpool.h
• [x] cute_symbol.h
• [x] cute_timer.h
• [x] cute_typeless_array.h
• [x] cute_utf8.h
• [x] cute_version.h
• [x] cute_window.h

Notes from discord chat

[10:20 PM] Randy: The main problem would be the usage of templated data structures in the implementation of some of the features, like the serialization and the ECS
[10:21 PM] Randy: However, it's possible to compile a C interface and leave the implementation using some C++
[10:21 PM] Randy: Then the main pain point is just some of the templated stuff in the API, but it's not too much
[10:21 PM] Limyc: I'm mostly interested in a c interface, and if it's just some grunt work, I might just do it
[10:22 PM] Randy: It's not a big deal to write C versions of function overloads and whatnot
[10:22 PM] Randy: I would absolutely support you here. I would do it myself, but priorities dictate I work on the other things first, like docs and bugs
[10:22 PM] Randy: So if you do it, that would super awesome
[10:25 PM] Limyc: is there a particular way you would want the interface work done?
[10:26 PM] Randy: https://github.com/RandyGaul/cute_headers/blob/master/cute_sound.h
GitHub
[cute_headers/cute_sound.h at master · RandyGaul/cute_headers](https://github.com/RandyGaul/cute_headers/blob/master/cute_sound.h)
Collection of cross-platform one-file C/C++ libraries with no dependencies, primarily used for games - cute_headers/cute_sound.h at master · RandyGaul/cute_headers
cute_headers/cute_sound.h at master · RandyGaul/cute_headers
[10:27 PM] Randy: This is a pretty good way to create C versions without default arguments
[10:27 PM] Randy:
cs_audio_source_t* cs_load_wav(const char* path, cs_error_t* err /* = NULL */);
cs_audio_source_t* cs_read_mem_wav(const void* memory, size_t size, cs_error_t* err /* = NULL */);
[10:27 PM] Randy: In each header you can #ifdef __cplusplus the C++ header, and in the #else have the C versions
[10:28 PM] Randy: For overloaded functions you can append 2 to the name
[10:28 PM] Randy: Should probably also have a macro to force C-only as an optional macro
[10:29 PM] Limyc: Would you want to keep the namespaced C++ functions wrapped with #ifdef _cplusplus, and those just call into the cf_* functions?
[10:29 PM] Randy: Yeah I think that's a good way to do it
[10:29 PM] Randy: In the places where an array<T> is returned there's a few options on what to do
[10:30 PM] Randy: We can probably discuss those case-by-case
[10:33 PM] Randy: cute_string.h should probably not have a C version at all
[10:33 PM] Randy: I see array<T> in cute_ecs.h and cute_https.h
[10:33 PM] Randy: but those should be easy to change to a C-style implementation
[10:35 PM] Randy: Overall it's a straightforward port to C
[10:35 PM] Limyc: okay, so globals, functions, types all get cf_
overloads get a numerical postfix.
keep the namespaced functions wrapped by an ifdef
deal with templates on a case-by-case basis
[10:35 PM] Randy: sounds pretty good
[10:35 PM] Randy: And ask questions if you need help with anything, we can always discuss things if you're unsure which option to take
[10:37 PM] Limyc: do you want to alias types inside the cpp namespace for convenience and not breaking anyone who updates?
namespace cute {
using ecs_entity_t = cf_ecs_entity_t;
}
 
[10:37 PM] Randy: yeah that's a good idea
[10:38 PM] Randy: that works well
[10:38 PM] Randy: Probably the big one here would be the sprite
[10:39 PM] Randy: https://github.com/RandyGaul/cute_framework/blob/master/include/cute_handle_table.h
[10:39 PM] Randy: Here's a similar example to how the sprite can be implemented. The C version is the "main" version and the C++ one just calls into the C functions and holds the struct instance
[10:40 PM] Randy: But the sprite would still just be POD style as opposed to the handle_table is heap allocated

The docs are unclear that in order to draw stuff using a png_cache, you must call make_batch(png_cache_get_pixels_fn(my_png_cache), my_png_cache) create a custom batch_t.

If you fail to create the custom batcher and just use sprite_get_batch() like I did, you'll get an error in the console when attempting to draw a sprite inside a png_cache_t. The error is "Aseprite cache -- unable to find id <img_id>"

https://github.com/RandyGaul/cute_framework/blob/master/include/cute_math.h

References to c2 need to be updated. c2 is not user-facing in CF, and cute_math.h should reference only itself in the comment docs.