| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Now that it's been used in a second app without needing any changes.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
We support 128px, so let's use the whole 128px.
|
| | |
|
| |
|
|
|
|
| |
Not quite working yet. Only the very first rendering succeeds. After
that any keypress triggers a second render which aborts. Image is
getting corrupted in memory somehow.
|
| |
|
|
|
|
| |
I'm loading them in uncompressed ASCII format, and all streams and gap
buffers all over the place need to get massively scaled up to 256KB
capacity. But the tests don't yet run out of RAM, so I'll keep going.
|
| | |
|
| |
|
|
|
|
|
| |
This was the whole proximal goal in implementing balanced terminals.
Printing these is still unreliable. It always surrounds in [], which may
not work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've always been dissatisfied with the notion of escaping. It introduces
a special-case meta-notation within the tokenizer, and the conventional
approach leads to exponential "leaning toothpick syndrome" with each
level of escaping.
One potential "correct" solution is to keep string terminals
parameterizable:
[abc] => abc
[=] => =
[=[abc]=] => abc
[=[a]bc]=] => a]bc
[==[a]=]bc]==] => a]=]bc
..and so on. Basically the terminals grow linearly as the number of
escapings grow.
While this is workable, I'd like to wait until I actually need it, and
then gauge whether the need is a sign of the stack growing too complex,
with too many layers of notation/parsing. Mu's goal is just 3 notations,
and it's going to require constant vigilance to keep that from growing.
Therefore, for now, there are two notations for string literals, one
symmetric and one balanced:
"abc" => abc
[abc] => abc
The balancing notation permits nested brackets as long as they balance.
[abc [def]] => abc [def]
If you need unbalanced square brackets, use the symmetric terminals:
"abc [def" => abc [def
If you need double quotes inside strings, use the balanced notation:
[abc "def] => abc "def
If you need _both_ square brackets (whether balanced or unbalanced) and
double quotes, you're currently shit outta luck.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Super slow; each frame is cleared as a sort of progress indicator while
it computes the next frame.
In the process I realize I need to adjust every single trace in the
shell sources to be more fault-tolerant to a filled-up trace stream.
|
| |
|
|
|
| |
Smoked out some issues by rendering a single frame of Game of Life.
Incredibly slow.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Broken since commit c95648c96 on Jul 3.
Unclear what test to write for this. Should clear-stream check for NULL?
Should apply-clear?
|
| |
|
|
| |
Still no support for acute-angled control points.
|
| | |
|
| | |
|
| | |
|
| | |
|