Color of a screen pixel: Difference between revisions
→{{header|8086 Assembly}}
Puppydrum64 (talk | contribs) m (put entries in alphabetical order) |
Puppydrum64 (talk | contribs) |
||
Line 7:
The mouse cursor may or may not have to be active in a GUI created by your program. These functions are OS related.
<br><br>
=={{header|6502 Assembly}}==
How this is done, and whether this is even possible, depends entirely on your video hardware (some machines such as the NES cannot control color data or graphics data at the pixel level.)
===easy6502/6502js===
Video memory is mapped into $0200-$05ff, and the bottom 4 bits of each byte represent the pixel's color.
<lang 6502asm>LDA $0200 ;get the color of the top-left pixel of the screen
LDA $05FF ;get the color of the bottom-right pixel of the screen.</lang>
===Nintendo Entertainment System===
The NES can't determine the color of a single pixel. The closest you can get is a 16 pixel by 16 pixel section of graphics. And that only tells you the palette in use at that location, not the actual color. Color cells are 2 bits per 16x16 section, in the order of top-left, top-right, bottom-left, bottom-right.
<lang 6502asm>;this code will fail to produce the desired result unless it executes during vblank or forced blank.
;address $23C0 = first color cell of nametable $2000
LDA #$23
STA $2006
LDA #$C0
STA $2006
LDA $2007
AND #%11000000 ;00------ = top-left corner uses palette 0, 01------ = top-left corner uses palette 1, etc.</lang>
This code assumes no scrolling has taken place, as it only reads the color cells from the top-left nametable. Generally speaking, reading VRAM in this way is not a good practice, as it's very slow and can only be done during vBlank when you have better things to do. For an actual game, it's much easier to keep a shadow of this data in normal RAM and read that instead, and pretend that VRAM is write-only.
=={{header|8086 Assembly}}==
| |||