OK, I gotta hand it to CoPilot.
Uncategorized
38
Posts
4
Posters
81
Views
-
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.
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.
-
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.
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.
-
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.
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.
-
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.
Feature parity with Spritemate, now, I think?
-
Feature parity with Spritemate, now, I think?
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.
-
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.
@swelljoe oof no flipping is such a bad design decision. SMS had that flaw despite a lot of other really cool features
-
@swelljoe oof no flipping is such a bad design decision. SMS had that flaw despite a lot of other really cool features
@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 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).
Why do you think the hardware didn’t do that byte flipping itself?
-
Why do you think the hardware didn’t do that byte flipping itself?
@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).
-
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.
We has flip.
-
@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).
@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.
-
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 Use lookup tables. Wanting to increase the sprite pointer sounds like premature optimisation
-
@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 @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.
-
@swelljoe Use lookup tables. Wanting to increase the sprite pointer sounds like premature optimisation
@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).
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Come dicevo, è morto.
Larry Summers takes leave from Harvard after Epstein emails release https://www.axios.com/2025/11/20/epstein-larry-summers-harvard-university-leave
-
@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).
-
Digitale, Bruxelles si piega alle Big tech e a Trump | il manifesto
https://ilmanifesto.it/digitale-bruxelles-si-piega-alle-big-tech-e-a-trump
> Ue (Europa) Una semplificazione dopo l’altra, ma sempre nel segno dell’inchino a Donald Trump. Prima è toccato al Green Deal, ieri alla mobilità militare e presto all’industria bellica nel suo complesso. Ora però sono le regole digitali a finire sotto la scure della de-regolamentazione. L’Ue aveva varato norme ambiziose per un settore in rapida evoluzione, come quelle
-
@fucinafibonacci cosa si intende per crisi? Si vendono poche bici, non ci sono squadre, non ci sono ciclabili?... @sport @claudio1883.bsky.social
-
@stefano thanks Stefano. What flavour of IMAP server do you choose or recommend?
-
@matz@gts.matteozenatti.net
no, lo fa apposta, per mantenerti umile!
@ALFA@nonoino.masto.host @oblomov@sociale.network
-
