|
Post by elmer on Apr 19, 2022 16:43:43 GMT
But brings a little more glitches at the top part of the screen, when animated metasprite appears there. Ah sorry, I thought that you were talking about animating CHR in the background layer, and not about uploading new frames of meta-sprite SPR data. Yes, uploading new meta-sprite SPR data during vblank is possible, but it has the same caveats that were mentioned in the previous posts, together with the fact that meta-sprites are usually bigger (more KBytes of data), and so harder to update-in-place without visible tearing unless you have *really* fine control of your environment's interrupt-handling, which just isn't a part of the standard HuC library/environment. Since you're trying to make your meta-sprite library usable for HuC developers, I would *stongly* recommend that you both support, and encourage your users to use, a double-buffering scheme for meta-sprites in VRAM. Yes, that costs a bunch of VRAM, but it does offer a simple solution to the tearing glitches.
|
|
|
Post by 0x8bitdev on Apr 19, 2022 17:17:06 GMT
Yes, I meant 'sprite patterns' data -> SATB synchronization. Since you're trying to make your meta-sprite library usable for HuC developers, I would *stongly* recommend that you both support, and encourage your users to use, a double-buffering scheme for meta-sprites in VRAM. 'Double buffering for meta-sprites'... How ?
|
|
|
Post by 0x8bitdev on Apr 19, 2022 17:46:13 GMT
Storing a copy of sprite-data in VRAM and then making VRAM-VRAM DMA ?
|
|
|
Post by elmer on Apr 19, 2022 18:02:56 GMT
Storing a copy of sprite-data in VRAM and then making VRAM-VRAM DMA ? Yes, but no. Yes to having 2 copies of a meta-sprite's SPR data in VRAM, for example lets call them A and B, stored at VRAM $6000-6FFF and at VRAM $7000-7FFF. A) Is the meta-sprite SPR data that is currently being displayed on the screen. B) Is the meta-sprite SPR data that you're current writing to so that you can switch to it on the next vblank. When the next vblank hits, and the VDC's SAT is updated from the SATB in VRAM, then ... A) Is the meta-sprite SPR data that you're current writing to so that you can switch to it on the next vblank. B) Is the meta-sprite SPR data that is currently being displayed on the screen. No, you don't need to do a VRAM-VRAM DMA, you just change the sprite's VRAM address in its SATB entry, and that change gets used when the SATB in VRAM is copied to the VDC's internal SAT at the beginning of the next vblank (after you set the VDC's flag to tell it to update the SAT).
|
|
|
Post by 0x8bitdev on Apr 19, 2022 19:15:18 GMT
Ok. I'll try to make that as option.
|
|
dogen
Deep Blooper
Posts: 30
|
Post by dogen on Apr 21, 2022 19:41:39 GMT
I probably shoulda posted my demo by now.. I have 2 versions now. One for supergrafx with the 2 layers and one for regular pc engine because someone said supergrafx makes it less cool lmao. Had to remove some sprites but I figured out how to make the background scroll at 2 speeds (now 3 lol) to fake it though.
Maybe with music I will. Out of context it might be a little weird but hopefully more goofy.
|
|
|
Post by 0x8bitdev on Apr 22, 2022 15:08:22 GMT
The meta-sprite rendering library for HuC has been finished and awaiting testing and feedback. Details you can find here - Dev tools: MAPeD-SPReD (win/linux). But... as fo HuC, I ran into a problem. And the problem name is "maximum 25 characters for names". On the one hand, it's enough. But when you try to give a readable name to your sprite in editor, then exporter adds a little prefix\postfix to exported names. And as result 25 character isn't enough. And you have to shorten your readable names to something awful like "frgas_erwefw_werg01_LEFT"... to fit them into 25 characters -prefix\postfix. At least 32 would be enough, but better - 64 to forget about this problem. BTW, the PCEAS has more than 25 chars for names. And I didn't have this problem using PCEAS.
|
|
|
Post by turboxray on Apr 26, 2022 18:56:47 GMT
Storing a copy of sprite-data in VRAM and then making VRAM-VRAM DMA ? Yes, but no. Yes to having 2 copies of a meta-sprite's SPR data in VRAM, for example lets call them A and B, stored at VRAM $6000-6FFF and at VRAM $7000-7FFF. A) Is the meta-sprite SPR data that is currently being displayed on the screen. B) Is the meta-sprite SPR data that you're current writing to so that you can switch to it on the next vblank. When the next vblank hits, and the VDC's SAT is updated from the SATB in VRAM, then ... A) Is the meta-sprite SPR data that you're current writing to so that you can switch to it on the next vblank. B) Is the meta-sprite SPR data that is currently being displayed on the screen. No, you don't need to do a VRAM-VRAM DMA, you just change the sprite's VRAM address in its SATB entry, and that change gets used when the SATB in VRAM is copied to the VDC's internal SAT at the beginning of the next vblank (after you set the VDC's flag to tell it to update the SAT). If you turn off SATB auto dma, you won't need two buffers in vram. Just one, and manually call the update. Not a big deal but if you're tight on vram then it helps.
|
|
|
Post by elmer on Apr 27, 2022 1:53:29 GMT
If you turn off SATB auto dma, you won't need two buffers in vram. Just one, and manually call the update. Not a big deal but if you're tight on vram then it helps. Sure ... for the attributes, but they're neither the biggest problem (because you can turn off auto DMA), nor are they the biggest memory user, i.e. 8-bytes per attribute vs 128-bytes-minimum for a sprite pattern. If your animation involves new sprite patterns as well as new sprite attributes, then double-buffering may well be unavoidable if you're trying to avoid sprite tearing and corruption.
|
|
|
Post by turboxray on Apr 27, 2022 3:43:32 GMT
If you turn off SATB auto dma, you won't need two buffers in vram. Just one, and manually call the update. Not a big deal but if you're tight on vram then it helps. Sure ... for the attributes, but they're neither the biggest problem (because you can turn off auto DMA), nor are they the biggest memory user, i.e. 8-bytes per attribute vs 128-bytes-minimum for a sprite pattern. If your animation involves new sprite patterns as well as new sprite attributes, then double-buffering may well be unavoidable if you're trying to avoid sprite tearing and corruption. Ohh nvm I thought you meant two SATB buffers.
|
|
|
Post by 0x8bitdev on May 24, 2022 12:27:16 GMT
It seems like I've found a bug in HuC v3.99-978acaa, 2022-02-22
This version generates empty labels - ' _:', and respectively error - 'Label multiply defined'. But HuC v3.99-c266d57, 2018-07-07, does not. Everything compiles Ok! This bug doesn't allow to use two libraries for tilemaps and sprites in one project. test_proj.zip (41.91 KB) [upd]: please, take a look at HuC's ./src/huc/defs.h, line 191, 192 - 25 characters for names are too small 64 would be enough for all times!
|
|
|
Post by elmer on May 24, 2022 15:24:26 GMT
This bug doesn't allow to use two libraries for tilemaps and sprites in one project. Thanks for the bug-report and example, I'll take a look. please, take a look at HuC's ./src/huc/defs.h, line 191, 192 - 25 characters for names are too small 64 would be enough for all times! I recently changed the size of HuC labels from 25 to 47, but I really don't want to make it larger than that, because HuC's optimizer sometimes concatenates a string to a label and makes a fake "label", and pushing beyond 47 characters will be in danger of breaking PCEAS's limit of 63 characters. Will 47 characters be enough?
|
|
|
Post by 0x8bitdev on May 24, 2022 15:47:01 GMT
I recently changed the size of HuC labels from 25 to 47, but I really don't want to make it larger than that, because HuC's optimizer sometimes concatenates a string to a label and makes a fake "label", and pushing beyond 47 characters will be in danger of breaking PCEAS's limit of 63 characters. Will 47 characters be enough? Thanks! 47 should be enough.
|
|
|
Post by elmer on May 24, 2022 16:36:02 GMT
It seems like I've found a bug in HuC v3.99-978acaa, 2022-02-22
This version generates empty labels - ' _:', and respectively error - 'Label multiply defined'. But HuC v3.99-c266d57, 2018-07-07, does not. Everything compiles Ok! OK, the change in behavior is because of something that turboxray added. I need to ask him what he was trying to do before just changing it back.
|
|
|
Post by elmer on May 24, 2022 17:45:24 GMT
OK, the change in behavior is because of something that turboxray added. I need to ask him what he was trying to do before just changing it back. Never mind, I understand now, it was a cut-n-paste bug introduced when he was adding the new #incasmlabel capability. It's fixed and checked-in. 0x8bitdev , if you build HuC from source, you can grab the contents of my repo, but be aware that we're in the middle of moving stuff around for the transition to an "organization". As mentioned in the other thread, the biggest user-facing change is that you need to change "include/pce" to "include/huc".
|
|