Piero Bosio Social Web Site Personale

@evan of course. But, copyright was a secondary piece of evidence for my assertion about recipes, not the primary one. Copyright cannot be claimed on a recipe because culturally, recipes were considered in the public domain long before copyright existed. Humanity throughout history thinks you should be allowed to make nice meals.

@evan 100%, no question. There's a long history of recipes being in the commons. Even when written down, they're not eligible for copyright protection.

I stumbled on Webview (https://github.com/webview/webview) as an option, which uses web technology for the UI in a way I hadn't even considered, and results in a tiny package and tiny executable with few extra dependencies. Web tech is very accessible. Plenty fast, runs everywhere (Linux, Windows, Mac OS, mobile, BSDs, all seemingly have Webview support out of the box or via a single package install) with minor tweaks. And, web browsers don't break backward compatibility.

Still considering my options.

So, I was planning to focus on packaging, documentation, and getting this thing published this weekend, but, I think I'm actually going to use the time to rebuild the UI in something else. Slint has a kinda cranky license, but seems to have a tiny runtime and looks great. Dear Imgui is not really accessible (not super relevant for a drawing program maybe, but if I'm learning a new thing, I want to be able to make accessible software with it, it's the minimal bar for a GUI toolkit, IMHO).

Jebus. Packaging Qt apps is terrible. And, a Qt Quick app is huge. I mean, my binary is under 200k, but by the time the Qt runtime libs are included the install footprint is going to be 10+MB. Obviously still much smaller than the hundreds of MB of an Electron package. But, this still isn't sitting right with me...I set out to learn how to make compact, portable, applications and this aint it.

Qt Quick is nice to develop for, but it's so unpleasant to package and deploy and quite big.

This is the image I started from. Not exactly 1:1, but I think it works pretty well for an afternoon/evening and given the limitations of the C64. I'll try to tackle animating overlay sprites at some point, so I can also import that fine black line as a second high res sprite. That's a lot more complicated, though, as it needs to accommodate different resolutions and such. (From here: https://arks.itch.io/dino-characters)

It's gone too far, somebody needs to stop me.

Importing a PNG character sheet. I start with a little dinosaur buddy from Itch.io, and load it straight into Spritely with no processing other than picking the row of little guys I wanted in the animation and cropping it to that size.

#RetroComputing #C64

It never gets old. Making little guys move around on the screen is never not fun. Still buggy in the controls, but with the right jiggling the handle, we have animation.

@timmy I hate how stupid they all are. It's just so embarrassing that these are the people who destroyed American democracy.

It took so little. The dumbest, meanest, internet trolls showed up, claimed to be wallet inspectors, and every major institution from media to universities to tech companies, just handed over their wallets.

Preview is back, but now it's for showing animation. I still don't know how to implement animation, but I know where it's gonna go.

I should hyperfixate on making software more often. It's true I'm eating exclusively things I can make in the microwave, but now I've got icons, and it's starting to look like the real deal, like a tool someone might choose to use.

Oh, no, packaging a Qt app is a pain in the ass. I didn't think this through.

RE: https://floss.social/@omgubuntu/115583973694128369

I think it's worth pointing out Mozilla has utterly lost the browser wars. It's been a rout over the past decade as Mozilla has retreated from every front.

Even if I trusted Mozilla leadership to make decisions on AI, I don't trust they know how to stop the corporate take over of anything.

Now we're cooking. Redesigned the sprite bank to start with one sprite and allow adding an arbitrary number of additional sprites.

Next up...animation? I've been putting it off because it's scary. I guess I still need to fix save/load to deal with multiple sprites, also.

Undo/redo works, with infinite(ish) history. Now to refactor the multisprite bank thing to be more sensible (start with one sprite, and add an Add Sprite button, along with sprite operations like copy/paste), and maybe change the layout some, though I'm not sure how, yet. I guess Spritemate gets it pretty close to right.

Hey, so a fun thing about the AI bubble is that agentic AI needs web search APIs. There was a project I worked on in the past, that I would still like to finish, that needed a cheap search API that allows date-based queries, so it could fetch results from the past 24 hours.

Historically, this seemingly simple idea was not considered worth implementing by anyone except Google, and they implemented it only for API uses that didn't fit my project.

Now? Several. All targeted at AI usage.

@zarfeblong @matt source being findable isn't the same as Open Source. Open Source means you can legally remix and legally sell or give away your new version.

You still can't ship a game called "Zork" (trademarks are still protected), but Open Source means the game and story can be repurposed in whatever way you want...and it means it can live forever, even if the owners of the IP decide it's not worth keeping available and playable on current hardware (which has happened a few times).

I didn't even know Microsoft owned Zork. But, I'm glad they've open-sourced it. https://opensource.microsoft.com/blog/2025/11/20/preserving-code-that-shaped-generations-zork-i-ii-and-iii-go-open-source

@yth yeah, now that I've spent more time reading about how folks use sprites, I agree the Spritemate model makes more sense...click to add new sprites to the editor, as many as you want. And, it makes sense to think in terms of a single character with its animation frames and overlays, if any, as the object you save (as either a native file for reloading, or as KickAssembler .bytes).

I'll make that change tomorrow.

@yth not trying to optimize for performance, just trying to simplify. I have a hard time holding assembly code in my head because it takes so much of it to do things. Having it so that every sprite is 64 bytes, plus 64 byte offset for its matching overlay, feels comforting. But, I guess the assembler can paper over that entirely and just load the right addresses (I'm guessing, I haven't done enough actual assembly in KickAssembler to know what it can do).