3 ms·
This is honestly so mind blowing, I wouldn't believe it if it wasn't from someone as trustworthy as Wellons. I've been making all of these mistakes except 1 (u
by suprjami 4y ago
This is honestly so mind blowing, I wouldn't believe it if it wasn't from someone as trustworthy as Wellons.
I've been making all of these mistakes except 1 (using vsync).
My stuff works fine but I'm going to try rewrite my current project how this page suggests.
- suprjami 4y agoI tried it but I don't like it. I think you have a choice to make between writing "a C application" which also uses SDL but probably only runs easily on computers, or writing "an SDL application" which can be easily ported to all weirdo SDL platforms without a complete standard library like maybe Vita or PSP or GP2x or RISC OS or BeOS or something obscure. Say you're writing a game where you want to decouple the game logic from the render, so your game can be more easily ported to different output formats like ncurses or even a different graphics library like raylib. In that situation I think it would be an error to depend on any SDL library functions like `SDL_calloc`. Or if you did, you'd need to have your own function pointer set for everything you used, like a global ops struct of function pointers with `my_ops->calloc()` (which is how I'm handling cross-render implementation too). The SDL set is also missing some things, like I need locale support for wchar. Overall, I don't want to write "SDL C", I want to write C99.