5-15-24

Realized it's a lot easier to do journals when I don't have to name each one. Also giving short, vague names to each post is starting to feel pretentious. "Simple is best" get eem outta here.

Gonna start organizing my life. I trimmed off my awful beard and moustache (low quality pic on homepage). Now I just need to get a haircut.

I need to take 2000 mcg cyanocobalamin per week. I have a 1000 mcg pill, so I will take it every wednesday and saturday. Took one today.

I'm working on adding native text support to tiny3d so I can port WordCloud to it. The picture below is using Windows GDI, which is all I have implemented so far. I want to see if I can get parity between that, CoreText on macOS and whatever the hell I find is best for text on Linux. I'm sure I can just grab freetype and use that. I have used it before, but it's honestly pretty damn janky and batteries-not-included for being the go-to text api. I might be able to use GTK or Pango or X11, who knows. It took me a while to sift through all the audio apis on Linux and eventually discover that pa_simple is basically the only one worth supporting. Currently the linux backend uses raw X11 for the window, error message boxes (thanks to bro) and legacy OpenGL context (GTK does not support legacy OpenGL). I plan to use avcodec to do image, audio and video loading.

I suppose I should just declare the purpose of tiny3d since I haven't done it anywhere. It's supposed to be the simplest plug and play app/game development library for C, but also produce the tiniest possible binaries (excluding demoscene compression techniques), by utilizing as much of the system libraries of the big 3 (win,mac,linux) as possible. OpenGL 1.1 because if it's good enough to make Notch 2.5 billion $, it's good enough for everyone. Stereo 44100 hz audio output by default, just throw bytes into it. One window, no more, no less. No user defined callbacks, just define functions like "mousedown" or else the linker will yell at you. Image, audio, video loading and saving, maybe zip compression (though the support matrix is unfortunately not there. Microsoft has a file level, undocumented zip capability (lmao) but we really want in memory compression. sdefl is so tiny it would probably rival any system lib implementation, but at that point people should just include it on their own and it defeats the somewhat troll purpose of the library to go out of its way to use every ridiculous system lib I can find.), threading, simple sockets (who tf needs to do all this specification like INET, blah blah, the api should just be IP and Port like god damn, still undecided on UDP vs TCP but Minecraft uses both so UDP is probably important. GafferOnGames has a full blog series on designing a multiplayer server architecture using UDP.), really I would like controller support, I think it would be really fun to play some games on my TV with my dad. This native text solution, combined with a system query for what keyboard layout the user is using (AZERTY, Cyrillic, etc.), could allow you to display the correct controls to the user by just mapping the scancodes to the right glyphs and drawing them on some key icons. As far as I can tell, just about every keyboard in the world has the same *GEOMETRIC* layout of scancodes, and that's all that really matters. So your game should be programmed in scancodes, and then just display the right glyphs to the user. WASD on qwerty turns into <AOE on dvorak. Going further, the API should give the scancode and utf-8 char on keydown and keyup.

1:57 PM: I'm cooking brown rice right now. Just set a 20 minute timer on Google. They changed their timer ui, it's a lot fancier now. I want to make some frutiger aero shit man.

Figured out how to get GDI to draw japanese characters: had to save the source file with the L"" japanese string in UTF-16 LE format.