Closed MetalMaxMX closed 5 months ago
Basically when I get through this TODO list. The big items have to do with documentation and samples work. I have to get up some high quality samples, but also figure out how to write down steps for other users to contribute to the docs, contribute a sample, etc.
Here's my TODO list copy + pasted from my personal notes. It's likely some of these will get cut for a future release version.
[x] remove quadtree [x] command buffer [x] run unit tests in CI [x] get samples running from embedded resources [x] remove all copying of sample/test resources from CMake [x] remove mbedtls [x] https ios [x] put spin animation back and put docs back [x] consolidate handle vs opaque pointer [x] consolidate _mem -> _from_memory [x] sprite play direction [x] document sprite origin slice [x] docs auto-delete unused [ ] high dpi stuff [ ] optional input callback registration [ ] png cache docs [ ] text width/height [ ] text alignment bug [ ] sync cute headers pass [ ] Beef up coroutine docs on stack size (especially dx callstacks) [ ] Camera related docs on flow: camera - draw - screen-view [ ] docs pass on all pages [ ] example code for all pages [ ] low level graphics tutorial-esque thing, some sample like hello-triangle [ ] custom draw context support [ ] automated build script for debug/release, mingw, vs2019, macos universal [ ] unit test a star [ ] old link in qu3e to randygaul.net [ ] refactor input to Noel-esque abstraction, actual bindings of some kind [ ] wrap up math toy demo [ ] website search function cannot find cf_clear_color [ ] Reorganize cute snake as a coroutine example [ ] Tidy up pongish and use as demo game [ ] Consider video tutorial on getting started from scratch, going through the docs on Windows [ ] Figure out (verify?) srgb/color space settings, add docs on this somewhere [ ] Think of way to make cf_app_update and cf_app_draw_onto_screen call order more robust, harder to f-up [ ] Audit this link for bug https://github.com/RandyGaul/cute_framework/blob/8ad507069d139d780f0a32dc1ad1dbbde286a26f/src/cute_aabb_tree.cpp#L420-L423 [ ] Audit this link for bug https://github.com/RandyGaul/cute_framework/blob/8ad507069d139d780f0a32dc1ad1dbbde286a26f/src/cute_aabb_tree.cpp#L844-L845 [ ] Look into more accurate sleep mechanism for framerate limiter (non-vsync path) [ ] Add tolerance check to shader primitive types, rather than direct float compare [ ] Example for cute handle table, maybe audit the API too [ ] Broadphase abstraction, expose AABB expansion constant as a tunable [ ] Draw pop's are too easy to leak. Just clear all pushes at end of the frame? Or, just note in doc (feels not good enough)? [ ] Document http stuff [ ] Build and use doc parser as a part of workflow validation [ ] sintern docs in string page, not just in hashtable page [ ] Depth option for app [ ] PR and contribution guideline docs, for both samples and for CF code [ ] Online sample page web builds [ ] Automate running docs generator as a part of workflow [ ] Shape editor sample [ ] Space game sample [ ] Turn on dark mode for the website [ ] Broadphase wrapper [ ] Toggle duplicate sound FX culling [ ] Audio loading in its own header [ ] Docment json stuff
Ah, I see. It does seems like most of the items aren't about technical features but rather bookkeeping like you mentioned? (documentation, website, and all)
So I imagine that the current state, codewise, is pretty close to 1.0?
That’s right. There just some minor code things to change at this point.
Hi! Wanted to retake this topic to discuss a few things about the cute_framework.
1) Why are the enemy sprites in the repository saved as .ase format? Does that mean it supports that format natively? (Could it also work with .ase generated files from LibreSprite as well?)
2) Scripting languages. Are any supported? Or the recommended way is to go full C++ as the main method of scripting things?
Should work with libresprite, yes. Aseprite format is natively supported and recommended! Although, support for loading up png images and pushing in your own animation data is also supported just in case someone wants to do their own thing.
For gameplay and scripting I highly recommend to try one of the two coroutine implementations. You can see a good example using Routine in the spaceshooter example (I’m actively working on this sample at the moment). The design of CF makes it pretty easy to implement lots of gameplay related things directly in C or C++, so I don’t really think using a scripting language is necessary. You can find some good examples by Noel Berry on his YouTube channel! Him and I collaborated a bit (he did most of the work) on the Routine implementation.
Hi. I've been thinking about how to answer and I didn't know that you collaborated with Noel Berry of Celeste fame! That's quite something admittedly. I've seen them using a Linux distro as of recently (presumably Fedora?) so that's quite interesting and all.
So the best way to go about this is with C/C++? Huh, all right then, does makes sense. Specially for performance reasons I imagine.
Nice that it works with LibreSprite! And works as well with regular PNG files. I wonder if QOI may also be supported in the future? What with that format being well received here and there.
Well, he wrote 95% of it! I just really liked it and mostly copied it. Noel mentioned he wanted to learn how to use Linux, so I think he's trying out dev there for fun. That's what I recall from watching his streams on youtube/twitch.
My personal opinion on why doing this in C++ is nice, is mainly that it's simple. When using something like Routine it's quite easy to spin up one-off logic really quickly without too much effort. The extra complexity of binding a scripting language is just not worth it.
What is QOI?
Let me know if you have other questions!
I've been using CF for a handful of personal projects, and it's been mostly smooth sailing for the past year. There's a quirk or bug here and there, but nothing major and Randy's been quick to respond to feedback and PRs.
I shipped a tiny GTMK jam game with CF, so that's something.
@RandyGaul QOI is the Quite Okay Image format - https://qoiformat.org/
I’m open to adding QOI as a natively supported image format to CF. I see they have low-dependency C files for reference loader and saver. It would be quite easy to support in a very similar way to the PNG support. If anyone wants to add this feature in as a PR I can write down some technical notes for guidance.
It’s a bit low priority to do it myself at this time though. So I’ll leave it as an option for any interested contributors.
Closing this out in anticipation of 1.0 release.
Well, what the title says!