OVR palette change

[potato25]

There's currently an existing issue with poke() inside OVR() function here : #1305

But can you change palette of OVR() using code with poke() function ?

I also couldn't find RAM specifications for OVR() function

[joshgoebel]

But can you change palette of OVR() using code with poke() function ?

The OVR palette isn't held in VRAM that I know of.

I also couldn't find RAM specifications for OVR() function

I don't think OVR has any interactions with actual RAM/VRAM.

---

I'd be very curious to hear the backstory from @nesbox on OVR() or be pointed to discussion of why it was added. Of everything in the API it alone seems very strange to me in that it seems to break all the rules of the "fantasy" computer - creating a non-fantasy graphics layer on top of everything else - purely for user convenience?

It's already quite simple to draw an overlay (horizontal) with just TIC alone... just call a custom overlay() function as the last line of the TIC() function - and writes directly to VRAM, like everything else. Of course your SCN() callback(s) for that area of the screen should set your "overlay" palette correctly.

Now doing a vertical overlay though is quite difficult - since now SCN() and palette changes might break everything... is this singular use case the only reason OVR exists?

Was it only added to make working with scanlines and colors not infuriating?

---

It feels like to truly make OVR part of the fantasy platform "hardware" that it's palette AND the graphics buffer (another ~16kb "layer") it writes to would both need to exist in the mapped RAM of the machine. But now also you're purposely breaking the idea of what scanlines are. If we're pretending these are literal scanlines that the "hardware" can make certain changes per-line to adjust color before the line is rendered - then OVR should not exist at all. It's a function for user convenience that would be impossible in the real world.

There is no way to just magically paint a second layer/pass on a CRT over the top of the first layer... this is very "fantasy" indeed.. lol. So maybe in some ways we're just fully embracing the concept of fantasy computer? Or perhaps I'm being too literal. I have no idea.

It's certainly possible I suppose to say we have "powerful fantasy graphics hardware" that makes all this somehow possible... that despite our very direct/low-level control of SCN that behind the screens the "graphics hardware" itself has an abstracted per-pixel control of color that it exerts when reading the OVR and VRAM buffers side by side as a scanline is written to the screen. Just seem like a strange mix of low-level implementation plus high-level abstraction.

[atesin]

hi..... i dont found an overlay being a weird/impossible idea on a retro computer

take atari "player-missiles" as example, that were 4 vertical bars, single color each, 8 pixel wide each, custom pixel width each, that could be moved horizontally, and had collision check... and graphic chip drew (puts in framebuffer ram) after (i.e. over) the screen

there was not direct basic commands to work with them, all operations (sprite, position, width, color, get/clear collision registers, etc) had to be done through peek and poke, or assembler... was not so friendly but very powerful and fast

i believe all atari 8-bit games had to use them