OK, I gotta hand it to CoPilot.
Uncategorized
34
Posts
3
Posters
74
Views
-
@matt I hadn't heard of it. I kind of settled on Qt because it's so mature, has accessibility features baked in, has good tooling (qmillint, Gammaray, etc.), and I could find a lot of examples (I simply need examples, my brain can't do anything with just an API reference). And, it's not terrible that I got an excuse to refresh and modernize my C++ skills a little bit.
But, when it comes to building something big, I kind of already know I don't want to use C++ or Qt. Probably Rust or Zig.
@matt oh, they're aiming straight for Qt's embedded/auto market, huh? They have a backend targeting Linux without X or Wayland. Very embeddy. https://docs.slint.dev/latest/docs/slint/guide/backends-and-renderers/backend_linuxkms/
-
@matt oh, they're aiming straight for Qt's embedded/auto market, huh? They have a backend targeting Linux without X or Wayland. Very embeddy. https://docs.slint.dev/latest/docs/slint/guide/backends-and-renderers/backend_linuxkms/
@matt but, it looks really nice! Reactive UIs seemingly without the island of garbage upon which they built React.js.
-
Qt Quick/QML has too many ways to make runtime errors. Why am I dealing with static types and a compiler and static analyzers if I can still have random brokenness I'll only find at runtime by clicking the right place?
This does not spark joy.
More progress on the sprite editor. Preview looks OK, now (it was stretched to fill the space before, because I'm still figuring out how to make things specific sizes and shapes and locations in QML). Save also works correctly.
I also made a little guy with a big butt and big ears, I guess.
-
More progress on the sprite editor. Preview looks OK, now (it was stretched to fill the space before, because I'm still figuring out how to make things specific sizes and shapes and locations in QML). Save also works correctly.
I also made a little guy with a big butt and big ears, I guess.
Tried to refactor Main.qml into separate components without any alteration of the appearance or functionality.
In the distance, sirens.
-
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.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
We has flip.
-
@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).
-
@hipsterelectron @clayote @shoofle @mtrc love this idea
-
@hipsterelectron @clayote @shoofle @mtrc also merriam-webster dot com doesn't have a definition for "sinophobia" which I found out just now because I wanted to double check the spelling since I'm talking to smart people, and merriam-webster dot com not having a definition for "sinophobia" is absolutely sinophobic and honestly a lot more immediately problematic
-
@hipsterelectron @clayote @shoofle @mtrc "this john guy seems racist" was the other main conclusion I came away with, though for my own happiness I decided to assume the unfortunate framing was a clumsy attempt to at a setup for the second part to wherein he is circumstantially illiterate and a structured set of rules processed without requiring his understanding does not empower him to understand the text, but the thought experiment doesn't improve anything and makes him seem sinophobic
-
@aeva @clayote @shoofle @mtrc related possibility might be a similar construction of time-based "feeding" input, but with some sort of not-too-complex transformation that makes it possible to produce predictable output if you can guess the relationship. it would be cool to try to "feel" the response of the machine and to grasp the way it "understands" my input by intuition
-
Why do you think the hardware didn’t do that byte flipping itself?
-
@aeva @clayote @shoofle @mtrc i consider the chinese room experiment to be quite literally racist in that it assumes a human being does not learn chinese in the act of translating it by rote. i think the language was chosen precisely to obscure this basic fact. it makes the circular assumption that a human can somehow ever be made to act like a turing machine. possibly the most ridiculous and unserious thing which is taught in "AI" courses.
