OK, I gotta hand it to CoPilot.
Uncategorized
40
Posts
4
Posters
84
Views
-
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.
-
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.
@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 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).
-
@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.
@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.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@G3rt nella scuola pubblica non c'è nemmeno la merenda.
Comunque il bonus è destinato a famiglia con reddito inferiore a 30000€ . Quindi praticamente fuffa ma stanno distraendo comunque fondi all'istruzione pubblica che come la sanità finirà col diventare privata
-
@matz@gts.matteozenatti.net
ieri non erano 8000?
@ALFA@nonoino.masto.host @rapitadaglialieni@puntarella.party @oblomov@sociale.network
-
Il nostro #GovernodellaVergogna spiegato facile.
-
@ALFA @rapitadaglialieni @oblomov AAAAAAAAAHHHHHHH QUALCUNO MI HA DEFOLLOWATOOOOOOOOHHHH
-
@pertho 😆
-
@Bastacosi che poi, se vai in una scuola privata, le 1500 € ci compri nemmeno la merenda.
-
@matz @rapitadaglialieni @oblomov
Non vorremmo essere pessimisti ma ieri segnava 10918 folloui e stamattina 10917!
-
How to turn of #AI in your #GMail account.
GMail -> Settings -> See all settings -> Scroll down to "Smart features" (see image below)
Turn off smart features (it will want to restart, you can do that), then go back there, go into the "Manage workspace smart feature settings" and turn the two options off
If you go back to "See all settings" you will find that a lot of sections are greyed out, because they are turned off.
