TIC-80
TIC-80 copied to clipboard
nesbox
Capturing a cover image (F7) doesn't pick up current palette
Using version 0.90.1724 (8e9dfe2) on OS X.
If I run my cart waferscale (which doesn't include a palette chunk in the .tic file, but sets a custom palette in the TIC() function) and press F7 to capture a cover image, then save the cart as a new file - the resulting cover image uses the default palette instead of my custom one.
We have metadata carts for such cases
But you have to upload two carts, the first is a clean cart with only your code, the second is a cart with a cover and description part.
Yep, that's what I did - the problem is that I can't easily capture a cover image to go into the metadata cart, because the image I capture comes out with the wrong palette.
It's by design because the cover is just 240x136 raw buffer of the current screen and it knows nothing about the current palette in VRAM. So, to avoid this you can use the import screen image.png command for the metadata cart with the palette you want.
Hmm, closer, but still not quite there - if I import a .png and immediately export it, it gets converted to the default palette.
Imported screenshot:
Exported result:
I think I understand the problem better now - since I'm only ever changing the palette from code with poke, it never actually gets set persistently at the "cart level", as it would if I was manually editing the palette through the sprite editor. So, when I save my metadata cart - even after I've let the cart run and update the 'in-memory' palette - it will be saved with the default palette (specifically, the cart will include a CHUNK_DEFAULT chunk), and any cover image I attach to the cart (either with F7 or import) will use that default palette. Of course, this wasn't a problem before 0.90, when the cart embedded the cover image as a .gif and used whatever palette was set on that image.
Right now, the only way for me to get around this would be to ensure that the cart contains a CHUNK_PALETTE chunk with my desired palette, which (I think) I can only do by manually setting it in the sprite editor or hacking the .tic file directly.
I guess it would be too much of a breaking change to modify the behaviour of F7 and import to overwrite the cart-level palette, so the best alternative would be for the CHUNK_SCREEN chunk to include the palette data associated with that screen (or to introduce a new chunk type for that purpose).
would be to ensure that the cart contains a CHUNK_PALETTE chunk with my desired palette, which (I think) I can only do by manually setting it in the sprite editor
Exactly.
so the best alternative would be for the CHUNK_SCREEN chunk to include the palette data
If we continue to allow it to be captured/saved with F7 then this makes sense... although this still doesn't solve the issue of changing the palette in OVR or per scanline - which I assume are simply impossible to represent with the new cover image?
If we continue to allow it to be captured/saved with F7 then this makes sense... although this still doesn't solve the issue of changing the palette in OVR or per scanline - which I assume are simply impossible to represent with the new cover image?
That may be, unfortunately. I decided to upload my techdemo I released on Jan 1st to the site and the cover for it is absolutely awful.
I'm not sure what the solution is to this, as I didn't see any sort of option to upload a metadata only cart. If there was I might be able to bake in all the effects into a single static image for cover purposes.
As it stands, the textured triangles rendered across the front and sides of the main shape are black, despite being white in both the texture editor and default palette. I do change the palette at runtime but it should still remain white if it's only using the default palette as it appears to be.
The rest is seemingly rendered as if the same palette is used for the entire screen, but due to there being OVR() effects I kinda expected that to look funny.
The cover was rendered with 1.1.2837 Pro (be42d6f) if that matters.
