about summary refs log tree commit diff stats
path: root/shell/primitives.mu
Commit message (Collapse)AuthorAgeFilesLines
* .Kartik K. Agaram2021-07-081-4/+4
|
* primitives for double-bufferingKartik K. Agaram2021-07-051-4/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I thought I needed these for this bouncing-ball demo: def (bounce screen) with (w (width screen) h (height screen) cx 16 cy 16 dx 12 dy 19) while 1 clear screen ring screen cx cy 16 3 5 cx += dx cy += dy when (or (cx > w) (cx < 0)) set dx 0-dx when (or (cy > h) (cy < 0)) set dy 0-dy for _ 0 (< _ 100) ++_ # delay No matter how I adjusted the delay I couldn't get rid of the jitter. So I built a double-buffered version: (bounce2 . [def (bounce2 screen) with (w (width screen) h (height screen) cx 16 cy 16 dx 12 dy 19 screen2 (new_screen (columns screen) (lines screen))) while 1 clear screen2 ring screen2 cx cy 16 3 5 cx += dx cy += dy when (or (cx > w) (cx < 0)) set dx 0-dx when (or (cy > h) (cy < 0)) set dy 0-dy blit screen2 screen for _ 0 (< _ 100) ++_]) # delay But it didn't make a difference! Turns out nothing will help you when successive frames are too far apart. This is the correct tweak to `bounce`: - dx 12 - dy 19) + dx 1 + dy (/ 19 12)) Still, we'll keep double-buffering around for the future.
* shell: fix clear on screensKartik K. Agaram2021-07-051-1/+1
| | | | | | | Broken since commit c95648c96 on Jul 3. Unclear what test to write for this. Should clear-stream check for NULL? Should apply-clear?
* expose Mu implementation of 'bezier'Kartik K. Agaram2021-07-051-1/+256
| | | | Still no support for acute-angled control points.
* replace 'circle' with Mu implementationKartik K. Agaram2021-07-051-1/+161
|
* replace 'vline' with Mu implementationKartik K. Agaram2021-07-051-1/+161
|
* replace 'hline' with Mu implementationKartik K. Agaram2021-07-051-1/+161
|
* replace 'line' with Mu implementationKartik K. Agaram2021-07-051-9/+196
|
* .Kartik K. Agaram2021-07-051-1/+1
|
* .Kartik K. Agaram2021-07-051-140/+140
|
* reading from streamsKartik K. Agaram2021-07-031-9/+115
| | | | | | The Mu shell has no string literals, only streams. No random access, only sequential access. But I've been playing fast and loose with its read pointer until now. Hopefully things are cleaned up now.
* new primitive: cons?Kartik K. Agaram2021-07-031-1/+42
|
* .Kartik K. Agaram2021-07-031-5/+10
|
* reorg primitives on screenKartik K. Agaram2021-07-021-30/+67
|
* snapshot: infixKartik K. Agaram2021-06-221-1/+1
| | | | | | | | | | | | | | | | | | | | | Like parenthesize, I'm copying tests over from https://github.com/akkartik/wart Unlike parenthesize, though, I can't just transliterate the code itself. Wart was operating on an intermediate AST representation. Here I'm all the way down to cells. That seemed like a good idea when I embarked, but now I'm not so sure. Operating with the right AST data structure allowed me to more easily iterate over the elements of a list. The natural recursion for cells is not a good fit. This patch and the next couple is an interesting case study in what makes Unix so effective. Yes, you have to play computer, and yes it gets verbose and ugly. But just diff and patch go surprisingly far in helping build a picture of the state space in my brain. Then again, there's a steep gradient of skills here. There are people who can visualize state spaces using diff and patch far better than me, and people who can't do it as well as me. Nature, nurture, having different priorities, whatever the reason. Giving some people just the right crutch excludes others.
* new macro: withKartik K. Agaram2021-06-201-1/+2
|
* .Kartik K. Agaram2021-06-121-1/+1
| | | | | Roll back to commit 70919b45f0. Recent commits add lots of extra function args for dubious benefit.
* eliminate some implicit writes to real screenKartik K. Agaram2021-06-121-1/+1
|
* try to abolish NULL from primitivesKartik K. Agaram2021-06-111-77/+504
|
* car/cdr of nil is now nilKartik K. Agaram2021-06-111-2/+18
|
* shell: remainder operationKartik K. Agaram2021-06-061-1/+65
|
* .Kartik K. Agaram2021-06-061-3/+3
|
* .Kartik K. Agaram2021-06-031-0/+1600