Well, the thing is, if the physics or render steps (not necessarily the logic) don't advance there's no change in the world or the screen buffer for the pc to show you, so, that's what those frame counters are showing, not how many frames the screen shows, but how many frames the game can output after it finishes its calculations. You can also have a game running at 200 frames but your screen at 60.
So, when someone unlocks the frame rate probably they just increased the physics steps per second which has the unintended consequences you described because the forces are not adjusted to how many times they're being applied now.
And a bit yeah, if you know your target is 30fps and you don't plan on increasing it then it simplifies the devlopment of the physics engine a lot, since you don't have to test for different speeds and avoid the extra calculations to adjust the forces.
I can't imagine this flow working with any DB without an UI to manage it.How are you going to store all that in an easy yet flexible way to handle all with SQL?
A table for notes?What fields would it have? Probably just a text field.Creating it is simple: insert "initial note"... How are you going to update it? A simple update to the ID won't work since you'll be replacing all the content, you'd need to query the note, copy it to a text editor and then copy it back to a query (don't forget to escape it).Then probably you want to know which is your oldest note, so you need to include
created_atandupdated_atfields.Maybe a title per note is a nice addition, so a new field to addtitle.What about the todo lists? Will they be stored in the same notes table?If so, then the same problem, how are you going to update them? Include new items, mark items as done, remove them, reorder them.Maybe a dedicated table, well, two tables, list metadata and list items.In metadata almost the same fields as notes, but
descriptioninstead oftext. The list items will havestatusandtext.Maybe you can reuse the todo tables for your book list and links/articles to read.
This already exists, several note taking apps which wrap around either the filesystem or a DB so you only have to worry about writing your ideas into them.I'd suggest to not reinvent the wheel unless nothing satisfies you.
What are the pros of using a DB directly for your use case?What are the cons of using a note taking app which will provide a text editor?
If you really really want to use a DB maybe look into https://github.com/zadam/triliumIt uses sqlite to store the notes, so maybe you can check the code and get an idea if it's complicated or not for you to manually replicate all of that.If not, I'd also recommend obsidian, it stores the notes in md files, so you can open them with any software you want and they'll have a standard syntax.