220 lines
7.1 KiB
Text
220 lines
7.1 KiB
Text
Notes on Graphica (June 30 2024)
|
|
|
|
Graphica is the name of the graphics extension for ilo. In the
|
|
Konilo system, this is in the `g:` namespace, and can be loaded
|
|
with either:
|
|
|
|
* g
|
|
|
|
or:
|
|
|
|
'(g) needs
|
|
|
|
|
|
Status:
|
|
|
|
- Level 0: is functional on ilo+x11 in an internal, unreleased
|
|
build. This is projected to be published in early July.
|
|
- Level 1: we've implemented the functions (for 1bpp) but have
|
|
not tied them all into the ilo+x11 vm yet. Work on the 2, 4,
|
|
and 8bpp modes has been done. We expect to have this by the
|
|
end of July.
|
|
- Level 2: parts of this have been implemented in test code. It
|
|
is expected to follow shortly after level 1 is complete (and
|
|
may be merged into level 1 prior to that?)
|
|
- Level 3: no timeline for starting this yet, though some
|
|
preliminary experiments towards it have been written.
|
|
|
|
|
|
Architectural Notes
|
|
|
|
- graphics memory is separate from the addressable ilo memory.
|
|
- the functionality is divided into a few general levels, with
|
|
increasing host requirements & complexity
|
|
- drawing operations take in points, which pack the x,y
|
|
coordinates into a single value
|
|
- Level 0 is slow due to routing all drawing through the pixel
|
|
draw word. Level 1 will have VM support for more optimal
|
|
drawing and will be significantly faster.
|
|
- display resolutions being targetted initially are:
|
|
|
|
- 320x240
|
|
- 640x384 (* this is the res. I am mostly using internally)
|
|
- 640x480
|
|
- 800x600
|
|
- 360x360
|
|
- 720x720
|
|
|
|
|
|
Level 0
|
|
|
|
- 1 bit per pixel (black/white)
|
|
- Konilo vocabulary:
|
|
|
|
g:query/level (-n)
|
|
g:query/colors (-n)
|
|
g:query/font (-hw)
|
|
g:query/screen (-hw)
|
|
g:set-color (n-)
|
|
g:point (xy-p)
|
|
g:unpoint (p-xy)
|
|
g:pixel (p-)
|
|
g:get-pixel (p-n)
|
|
g:clear (-)
|
|
g:hline (pw-)
|
|
g:vline (ph-)
|
|
g:line (pp-)
|
|
g:rect (pp-)
|
|
g:circle (pr-)
|
|
g:triangle (ppp-)
|
|
|
|
Level 1
|
|
|
|
- 2, 4, and 8 bit per pixel (4, 16, and 256 color)
|
|
- user defined color palette (using RRGGBB values)
|
|
- Konilo words:
|
|
|
|
g:set-palette (a-)
|
|
g:get-palette (a-)
|
|
|
|
- VM support for:
|
|
|
|
g:clear (-)
|
|
g:hline (pw-)
|
|
g:vline (ph-)
|
|
g:line (pp-)
|
|
g:rect (pp-)
|
|
g:circle (pr-)
|
|
g:triangle (ppp-)
|
|
|
|
- Notes:
|
|
- Palettes
|
|
- Konilo array, with 1 entry per color
|
|
- default palette will be setup to emulate CGA (2bpp) or
|
|
VGA (4 or 8bpp; colors outside the first 16 will be set
|
|
to 0 by default)
|
|
- Arland expects to provide several loadable palettes
|
|
|
|
Level 2
|
|
|
|
- Konilo words:
|
|
|
|
g:set-foreground (n-) (alias to g:set-color)
|
|
g:set-background (n-) (for fill operations)
|
|
g:fill (p)
|
|
g:rect/filled (pp-)
|
|
g:circle/filled (pr-)
|
|
g:triangle/filled (ppp-)
|
|
|
|
Level 3:
|
|
|
|
- Konilo words:
|
|
|
|
g:polygon (ap-)
|
|
g:polygon/filled (ap-)
|
|
g:scene (ap-)
|
|
|
|
- Notes:
|
|
|
|
- scenes are stored as an array of points and drawing
|
|
commands, with the drawing being done relative to a
|
|
provided starting point. the exact format is still being
|
|
designed.
|
|
- polygons are arrays of points, with lines being drawn
|
|
between each point
|
|
- the polygon portion of this might get folded into level 2
|
|
|
|
Notes:
|
|
|
|
- the loading process will probably use `g:query/level` to
|
|
select between level 0 & level 1 implementations at load time.
|
|
|
|
|
|
Future:
|
|
|
|
- To be determined.
|
|
- We are looking at 3D, non-palette based colors, and sprites
|
|
- 3D references:
|
|
- https://www.cs.drexel.edu/~deb39/
|
|
Classes/Papers/comp175-06-pineda.pdf
|
|
- https://www.drdobbs.com/architecture-and-design/
|
|
optimizing-pixomatic-for-x86-processors/184405765
|
|
|
|
|
|
Implementation Details:
|
|
|
|
The Graphica extension is assigned to device id #12. Pass the
|
|
required parameters, operation id, and device number to the
|
|
`io` instruction.
|
|
|
|
+------+-------+-----------+-----------------------------------+
|
|
| ID # | Level | Stack Use | Action |
|
|
+======+=======+===========+===================================+
|
|
| 0 | 0 | -n | return graphica level |
|
|
| 1 | 0 | -n | return num of supported colors |
|
|
| 2 | 0 | -hw | return font height, width |
|
|
| 3 | 0 | -hw | return display height, width |
|
|
| 4 | 0 | n- | set the pixel color for drawing |
|
|
| 5 | 0 | p- | draw a pixel at p |
|
|
| 6 | 0 | p-n | return the color of pixel at p |
|
|
| 7 | 1 | - | clear the display |
|
|
| 8 | 1 | pw- | draw a horizontal line w wide |
|
|
| 9 | 1 | ph- | draw a vertical line h high |
|
|
| 10 | 1 | pp- | draw a line between two points |
|
|
| 11 | 1 | pp- | draw a rectangle |
|
|
| 12 | 1 | pr- | draw a radius r circle at center p|
|
|
| 13 | 1 | ppp- | draw a triangle |
|
|
| 14 | 1 | a- | set palette to colors in array a |
|
|
| 15 | 1 | a- | store current palette in array a |
|
|
| 16 | 2 | n- | set foreground color |
|
|
| 17 | 2 | n- | set background color |
|
|
| 18 | 2 | p- | fill area around p w/background, |
|
|
| | | | stopping when foreground is found |
|
|
| 19 | 2 | pp- | draw a filled rectangle |
|
|
| 20 | 2 | pr- | draw a filled circle |
|
|
| 21 | 2 | ppp- | draw a filled triangle |
|
|
| 22 | 3 | a- | draw a polygon. a is an array of |
|
|
| | | | points |
|
|
| 23 | 3 | a- | draw a filled polygon. a is an |
|
|
| | | | array of points |
|
|
| 24 | 3 | ap- | draw a scene using point p as the |
|
|
| | | | origin (top left) |
|
|
+------+-------+-----------+-----------------------------------+
|
|
|
|
Points:
|
|
|
|
The x, y coordinates are packed into a single cell to
|
|
keep overall stack structure cleaner. These can be unpacked
|
|
as needed by the drawing words (level 0) or graphica device
|
|
(levels 1+)
|
|
|
|
:g:point (xy-p) [ #16 shift-left ] dip or ;
|
|
:g:unpoint (p-xy) [ #16 shift-right ] [ #65535 and ] bi ;
|
|
|
|
Consider: adding a sigil for defining points as something like
|
|
<100,200>
|
|
may be useful? will be discussing this w/Arland soon
|
|
|
|
Note: we've explored leaving just the coordinates on the stack
|
|
in the prototypes, but ultimately decided that using a
|
|
point structure was better for our needs.
|
|
|
|
Note: it might be worth looking at changing the points to
|
|
also pack in a z coordinate for future 3D support? (this
|
|
would be ignored/unused for 2D operations)
|
|
|
|
Other:
|
|
|
|
- a simple turtle style drawing vocabulary has been written
|
|
using this, as has a vocabulary for formula generated art
|
|
- in the prior experiments we have also implemented a few
|
|
visual programs (paint, conway's life, a mandebrot viewer,
|
|
and dice simulator) which we plan to update to work with
|
|
the final implementation. This will likely be in the fall of
|
|
2024
|
|
|
|
|
|
Related, but external parts to be covered by other extensions:
|
|
|
|
- realtime keyboard state
|
|
- mouse / pointer state
|