OK, I gotta hand it to CoPilot.
Uncategorized
52
Posts
4
Posters
195
Views
-
Tried to refactor Main.qml into separate components without any alteration of the appearance or functionality.
In the distance, sirens.
Maybe that joke is obscure tumblore and I should explain.
-
Maybe that joke is obscure tumblore and I should explain.
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.
-
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.
This post is deleted! -
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.
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.
-
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.
-
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
-
@stefano "how I decided to become a painter...?"
-
@liilliil well, in other contexts, calling someone a racist slur is not OK, even if it's not prohibited by copyright law. So, "there's no copyright problem" does not automatically mean that the activity is OK. An extreme example but hopefully we've established that copyright is not the be-all and end-all of ethics.
-
@jesterchen this is definitely an interesting line of reasoning! Question back: is there a significant difference between asking for the recipe, and reverse-engineering it?
-
@evan Oh don't worry, I'm aware of the other point of view. I know it too well. I know it well enough to know of the absolute destruction it has done.
So if I choose not to entertain it by speaking it, it is not because of lack of curiosity.
-
@virtuous_sloth complex minds sometimes try to stretch their boundaries and see things from another point of view.
-
@evan
And coincidentally this...
-
Decided on Slint, after a think on the subject. I've started rewriting, and I guess it won't be terribly painful, but it's going to be at least another week before I can call the thing done.
Seems like a lot just to avoid packaging Qt, but if you think so, you've probably never tried to package Qt (where all deps are bundled, so the user doesn't need to install anything other than the package).
-
@evan I have no need to; I answered yes.
