Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | . | Kartik K. Agaram | 2021-07-24 | 1 | -0/+3 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-24 | 1 | -5/+4 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-22 | 2 | -31/+0 |
| | |||||
* | update memory map doc and anticipate a gotcha | Kartik K. Agaram | 2021-07-22 | 3 | -3/+15 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-20 | 3 | -46/+46 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-20 | 39 | -531/+94 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-20 | 18 | -41/+41 |
| | | | | | Update run instructions for linux/app/ examples, and make sure they are correct. | ||||
* | . | Kartik K. Agaram | 2021-07-20 | 4 | -1346/+2 |
| | | | | | Delete the examples from Crenshaw. They're extremely rudimentary, and they were really just trial runs for the Mu toolchain. | ||||
* | start work on running the Mu toolchain atop Mu | Kartik K. Agaram | 2021-07-19 | 14 | -14/+14 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-19 | 2 | -10/+3 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-19 | 2 | -3/+71 |
| | |||||
* | error message when trying to jump to primitive | Kartik K. Agaram | 2021-07-19 | 1 | -0/+15 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-19 | 1 | -9/+9 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-19 | 1 | -21/+0 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-19 | 2 | -2/+1 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-19 | 1 | -176/+0 |
| | |||||
* | render functions in MRU order | Kartik K. Agaram | 2021-07-19 | 4 | -45/+92 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-17 | 1 | -2/+2 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 2 | -1/+101 |
| | |||||
* | forgot to `git add` a file | Kartik K. Agaram | 2021-07-16 | 1 | -0/+1098 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 2 | -3/+3 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 6 | -1539/+1363 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 2 | -1133/+23 |
| | |||||
* | more powerful load-sectors | Kartik K. Agaram | 2021-07-16 | 3 | -18/+46 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 5 | -33/+33 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 3 | -21/+0 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 241 | -9375/+18695 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 89 | -102/+293 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 2 | -5/+5 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 1 | -1/+1 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-16 | 1 | -55/+0 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-15 | 6 | -45929/+0 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-14 | 1 | -0/+1217 |
| | |||||
* | color dithering seems to be working | Kartik K. Agaram | 2021-07-14 | 1 | -1/+8 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-14 | 1 | -0/+1 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-14 | 1 | -1/+1 |
| | |||||
* | clarify a corner case in 2's complement integers | Kartik K. Agaram | 2021-07-14 | 1 | -0/+31 |
| | | | | https://merveilles.town/@akkartik/106577885001702701 | ||||
* | dithering ppm files using all 256 colors | Kartik K. Agaram | 2021-07-13 | 1 | -2/+205 |
| | | | | | Not quite working yet, but yields an interesting 'sketching-like' effect. | ||||
* | scaling the palette working on third attempt | Kartik K. Agaram | 2021-07-13 | 1 | -2/+16 |
| | | | | | See commits b4e997adb8 and 2777479a94. This seems like a good sign that dithering is now extremely precise. | ||||
* | get rid of our ugly rounding code | Kartik K. Agaram | 2021-07-13 | 1 | -8/+1 |
| | | | | | | | | | | | | | | | It turns out "truncating" the last 4 bits is actually more accurate, because it divides up the palette evenly. Before: 0-7 -> 0 8-0x17 -> 1 0x18-0x27 -> 2 ... 0xd8-0xe7 -> 0xe 0xe8-0xff -> 0xf The first interval is just 8 shades, and the final interval is 24 shades. | ||||
* | clean up some unseemly speckles | Kartik K. Agaram | 2021-07-13 | 1 | -3/+2 |
| | | | | | | | Turns out they were a bug after all, and scaling the palette was just making them more obvious. The bug: I was carefully clamping to 0xf0 to avoid rounding later, but I forgot to do so for values between 0xf0 and 0xff. As a result, some values could round up past 0xff and turn black. | ||||
* | cleanup | Kartik K. Agaram | 2021-07-13 | 1 | -65/+5 |
| | |||||
* | give up on .pgm files with color depths != 255 | Kartik K. Agaram | 2021-07-13 | 1 | -9/+5 |
| | | | | | | Things kinda seem to work for color depths close to 255, but it isn't really the goal here, and I don't have the skills of numerical analysis to track this down. | ||||
* | undo | Kartik K. Agaram | 2021-07-13 | 1 | -19/+7 |
| | |||||
* | experiment | Kartik K. Agaram | 2021-07-13 | 1 | -7/+19 |
| | | | | | Now scaling pixels to 255 levels looks a lot better. Still worse, though. On both t.pgm and barbara.pgm. | ||||
* | now t.pgm looks right | Kartik K. Agaram | 2021-07-13 | 1 | -7/+7 |
| | |||||
* | clamp the upper bound of nearest-color as well | Kartik K. Agaram | 2021-07-13 | 1 | -30/+53 |
| | | | | | I'd kinda convinced myself it would never happen, but observations say otherwise. Unless there's a bug elsewhere.. | ||||
* | . | Kartik K. Agaram | 2021-07-13 | 1 | -6/+11 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-13 | 1 | -14/+10 |
| | |||||
* | finally a clue: error is going over 255 | Kartik K. Agaram | 2021-07-13 | 1 | -9/+75 |
| | | | | Exactly in the places to the right of the line. |