OK, I gotta hand it to CoPilot.
Uncategorized
61
Posts
4
Posters
420
Views
-
@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.
-
We has flip.
Undo/redo works, with infinite(ish) history. Now to refactor the multisprite bank thing to be more sensible (start with one sprite, and add an Add Sprite button, along with sprite operations like copy/paste), and maybe change the layout some, though I'm not sure how, yet. I guess Spritemate gets it pretty close to right.
-
Undo/redo works, with infinite(ish) history. Now to refactor the multisprite bank thing to be more sensible (start with one sprite, and add an Add Sprite button, along with sprite operations like copy/paste), and maybe change the layout some, though I'm not sure how, yet. I guess Spritemate gets it pretty close to right.
Now we're cooking. Redesigned the sprite bank to start with one sprite and allow adding an arbitrary number of additional sprites.
Next up...animation? I've been putting it off because it's scary. I guess I still need to fix save/load to deal with multiple sprites, also.
-
Now we're cooking. Redesigned the sprite bank to start with one sprite and allow adding an arbitrary number of additional sprites.
Next up...animation? I've been putting it off because it's scary. I guess I still need to fix save/load to deal with multiple sprites, also.
Oh, no, packaging a Qt app is a pain in the ass. I didn't think this through.
-
Oh, no, packaging a Qt app is a pain in the ass. I didn't think this through.
I should hyperfixate on making software more often. It's true I'm eating exclusively things I can make in the microwave, but now I've got icons, and it's starting to look like the real deal, like a tool someone might choose to use.
-
I should hyperfixate on making software more often. It's true I'm eating exclusively things I can make in the microwave, but now I've got icons, and it's starting to look like the real deal, like a tool someone might choose to use.
Preview is back, but now it's for showing animation. I still don't know how to implement animation, but I know where it's gonna go.
-
Preview is back, but now it's for showing animation. I still don't know how to implement animation, but I know where it's gonna go.
It never gets old. Making little guys move around on the screen is never not fun. Still buggy in the controls, but with the right jiggling the handle, we have animation.
-
It never gets old. Making little guys move around on the screen is never not fun. Still buggy in the controls, but with the right jiggling the handle, we have animation.
It's gone too far, somebody needs to stop me.
Importing a PNG character sheet. I start with a little dinosaur buddy from Itch.io, and load it straight into Spritely with no processing other than picking the row of little guys I wanted in the animation and cropping it to that size.
-
It's gone too far, somebody needs to stop me.
Importing a PNG character sheet. I start with a little dinosaur buddy from Itch.io, and load it straight into Spritely with no processing other than picking the row of little guys I wanted in the animation and cropping it to that size.
This is the image I started from. Not exactly 1:1, but I think it works pretty well for an afternoon/evening and given the limitations of the C64. I'll try to tackle animating overlay sprites at some point, so I can also import that fine black line as a second high res sprite. That's a lot more complicated, though, as it needs to accommodate different resolutions and such. (From here: https://arks.itch.io/dino-characters)
-
This is the image I started from. Not exactly 1:1, but I think it works pretty well for an afternoon/evening and given the limitations of the C64. I'll try to tackle animating overlay sprites at some point, so I can also import that fine black line as a second high res sprite. That's a lot more complicated, though, as it needs to accommodate different resolutions and such. (From here: https://arks.itch.io/dino-characters)
Jebus. Packaging Qt apps is terrible. And, a Qt Quick app is huge. I mean, my binary is under 200k, but by the time the Qt runtime libs are included the install footprint is going to be 10+MB. Obviously still much smaller than the hundreds of MB of an Electron package. But, this still isn't sitting right with me...I set out to learn how to make compact, portable, applications and this aint it.
Qt Quick is nice to develop for, but it's so unpleasant to package and deploy and quite big.
-
Jebus. Packaging Qt apps is terrible. And, a Qt Quick app is huge. I mean, my binary is under 200k, but by the time the Qt runtime libs are included the install footprint is going to be 10+MB. Obviously still much smaller than the hundreds of MB of an Electron package. But, this still isn't sitting right with me...I set out to learn how to make compact, portable, applications and this aint it.
Qt Quick is nice to develop for, but it's so unpleasant to package and deploy and quite big.
So, I was planning to focus on packaging, documentation, and getting this thing published this weekend, but, I think I'm actually going to use the time to rebuild the UI in something else. Slint has a kinda cranky license, but seems to have a tiny runtime and looks great. Dear Imgui is not really accessible (not super relevant for a drawing program maybe, but if I'm learning a new thing, I want to be able to make accessible software with it, it's the minimal bar for a GUI toolkit, IMHO).
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
-
@Pare @De_Treias @luca @dariosoldi @torino
Mi riprometto di darti dati a riguardo, ma se fosse come tu dici, che con le rinnovabili non si arriva MAI a saturare domanda non si parlerebbe tanto di accumuli.
Non ci sarebbe mai energia in più da destinargli, così come pure l'"idrogeno verde".
-
@aeva unfortunately one cannot disregard what they have already regarded (my trilingualism is getting the best of me)
-
https://medium.com/@brunosaetta/moltbook-simulazione-o-specchio-sociale-32a5de0e6913
Un esperimento che guarda alle macchine per spiegare l'umano. Moltbook, simulazione o specchio?
-
okay fedi what's the meta for a desktop soldering iron + hot air station these days? within ~$100-200 USD (preferably cheaper but w/e)
-
@davew so. Expensive google.
I’m not shit talking you here. I’m seriously a fan of this approach. It’s also what ultimately led me to ditch my ChatGPT subscription and move to Kagi where I can get that info from Kagi Assistant
-
@coso_come_se_chiama Che teste di cazzo, non ce la fanno proprio
-
@gabxcos @snow @synthBirba più che altro searxng è un metamotore, i risultati che da tendono ad essere quelli dei motori di ricerca che usa
che io sappia la maggior parte delle istanze searxng alla fin fine come motori generici ha dentro i soliti, google, bing, duckduckgo, che in realtà rimanda risultati di bing, al più i progetti wikimedia diretti
poi c'è modo di abilitargli anche cose più di nicchia, tipo appunto marginalia, o — ancora più interessante — motori diversi tipo istanze di yaci, magari self-hostate, avendo allo stesso tempo i risultati mainstream e iniziare ad usare soluzioni davvero indipendenti quando possibile.
(da noi c'è una cosa sperimentale che fa ricerche fondamentalmente sui bookmark del gruppo di amici, ma è molto sperimentale, non è sempre attiva, e non è automatizzata, ogni tot vengono aggiunti dei link esportandoli a mano)
