OK, I gotta hand it to CoPilot.

[swelljoe@mas.to]

Maybe that joke is obscure tumblore and I should explain.

[swelljoe@mas.to]

I just looked into what it costs to sell games and stuff on Itch.io, and creators can set their own amount to give to Itch.io, instead of the flat 30 that Steam and all the app stores take. That's nice. That's really nice. From now on, if I can buy a game there instead of Steam, I'm doing that, because I never feel great about so much of the money not going to the creator.

[swelljoe@mas.to]

This post is deleted!

[swelljoe@mas.to]

Looks exactly the same, but now most of the QML types are in their own files, Main.qml is much smaller, and we have 0 qmllint complaints. Most of this evening has been spent trying to reason out what recommendation `qmllint` is making and why. C++ and Qt docs are always so unopinionated. I need these folks to take a stand. If it's worth spitting out a warning in qmllint, it's worth being clear about what the user should do.

My little man drawing skills keep getting worse, somehow.

[swelljoe@mas.to]

C64 folks, is it reasonable to think in terms of "sets of eight sprites?" I know you can have more or less, and I know one might more be thinking of sets of three or four for animations...but, for some reason, I think this layout kind of makes sense to me.

I'm thinking animation will be visualized by selecting two or more sprites from the eight shown, and then I'll bring back the preview box as an animation preview.

#retrocomputing #commodore64

[swelljoe@mas.to]

Spritemate handles it like this. You click to add more sprites to work with, and that's also pretty intuitive and reasonable. No animation support, though.

[swelljoe@mas.to]

OK, animation with overlay sprites is confusing. It seems like it makes sense to group the overlay with the sprite it overlays...so you can increment a, umm, pointer or whatever you call it in assembly, and have the offset remain the same always. So, each frame in an animation displays two sprites adjacent to each other in memory.

But, what if the overlay is re-used? If I have two different little guys who have the same outline, but different multicolor, I can no longer count on adjacency.

[swelljoe@mas.to]

Feature parity with Spritemate, now, I think?

[swelljoe@mas.to]

Oh, but I don't have flip and copy/paste features, which reminds me if you want your little guy to run both directions you have to have sprite drawings for both directions, because the C64 can't flip its sprites.

Or, in my case, all four directions, since I'm doing a rogue-like/rogue-light, and maybe that's an impossible amount of resources...four sets of sprite data for all monsters seems like it will add up fast, especially with overlays. 64 bytes*2*4*number of characters.

[maxoakland@mastodon.social]

@swelljoe oof no flipping is such a bad design decision. SMS had that flaw despite a lot of other really cool features

[swelljoe@mas.to]

@maxoakland they were working within very tight constraints, I think it's amazing how much people have been able to wring out of the 64. And, I suspect one could come up with alternatives...I mean flipping bytes isn't computationally intensive, so you could do it yourself on the CPU, but I guess it'd need copies since the VIC is reading sprite memory directly, so you can't update it in place, at least not without glitches (I'm guessing, I have no idea what I'm talking about).

[maxoakland@mastodon.social]

Why do you think the hardware didn’t do that byte flipping itself?

[swelljoe@mas.to]

@maxoakland they had to stop somewhere. The C64 was already more advanced on that front than any other personal computer. I do think it's unfortunate we didn't get new capabilities in the 128. It's basically the same graphics as the 64. And, the 80-column mode was not usable for games (except a rogue-like, maybe, or maybe for an information display for the game on the 40-column display, since you could have both at once).

[swelljoe@mas.to]

We has flip.

[yth@mstdn.social]

@swelljoe @maxoakland I would say flipping bytes at runtime to save memory space is a poor trade-off. It will take too much cpu. There won’t be glitches as long as you don’t update stuff while it is being drawn, so do it while the beam is not on the sprite. You could create flipped copies at init time to save loading time and disk space.

[yth@mstdn.social]

@swelljoe Use lookup tables. Wanting to increase the sprite pointer sounds like premature optimisation

[swelljoe@mas.to]

@yth @maxoakland yeah, I think given the trade-offs you probably just want to have both directions pre-drawn. In emulators and modern C64 setups, disk speed and space is not a major issue.

[yth@mstdn.social]

@swelljoe There’s no real connection between the amount of visible sprites (8) and the amount of “sprites” (graphic data) in memory that you can use for animation frames. So having 8 sprites in that screen feels quite arbitrary.

[swelljoe@mas.to]

@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).

[swelljoe@mas.to]

@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.