about summary refs log tree commit diff stats
path: root/500fake-screen.mu
Commit message (Collapse)AuthorAgeFilesLines
* make fake screens more realisticKartik K. Agaram2021-06-061-9/+33
| | | | The real screen silently clips coordinates out of bounds.
* shell: scrolling the traceKartik K. Agaram2021-05-291-1/+2
|
* start double-bufferingKartik K. Agaram2021-05-181-0/+39
| | | | | Amazing how much difference it makes even when the implementation is so naive and slow.
* .Kartik K. Agaram2021-04-211-0/+11
|
* reimplement pixel graphicsKartik K. Agaram2021-04-191-50/+101
| | | | | | | | | | | Before: we always drew pixels atop characters, and we only drew pixels that were explicitly requested. After: we always draw pixels atop characters, and we only draw pixels that don't have color 0. Both semantics should be identical as long as pixels are never drawn atop characters.
* .Kartik K. Agaram2021-04-191-33/+33
|
* add some checksKartik K. Agaram2021-04-191-2/+18
| | | | | | | Even if they duplicate lower-level ones, we have an opportunity for better error messages. Any time I see a hard-to-debug error message, I should be asking myself, "what higher-level primitive should catch and improve this error?"
* start cleaning up pixel graphicsKartik K. Agaram2021-04-191-1/+1
| | | | | | Filling pixels isn't a rare corner case. I'm going to switch to a dense rather than sparse representation for pixels, but callers will have to explicitly request the additional memory.
* Revert "allow drawing all pixels"Kartik K. Agaram2021-04-181-2/+3
| | | | It causes us to run out of memory during tests.
* allow drawing all pixelsKartik K. Agaram2021-04-171-3/+2
| | | | So far we aren't running out of memory. Might as well loosen our belts.
* shell: horline working nowKartik K. Agaram2021-04-151-1/+9
| | | | And we give a high-level error when the pixel buffer fills up.
* shell: don't lose pixel graphics when moving cursorKartik K. Agaram2021-04-141-0/+1
|
* shell: pixel graphicsKartik K. Agaram2021-04-131-0/+431