Right now, whenever you want a sprite that can do any sort of hit-testing, you have to (1) create a new Bounds and assign to localBounds, (2) assign its width and height (almost always from the image width and height).

It'd be nice to make life easier for the simple and common case, by automatically instantiating this localBounds as soon as you do any operation on the sprite that implies the need for one. So, as soon as you call contains, overlaps , worldBounds, corners, or setCorners; or use it as the argument to some other contains call.

When any of these things happen, if localBounds is null, then initialize it to a new Bounds set to match the current image of the sprite.

The order of events here got me confused. Either I don't understand it correctly or it might be a yet undetected bug:

_viewImage = function(pic)
        // ...
	prevMode = display(0).mode
        // Setting display-mode of 0 to pixel ...?
	display(0).mode = displayMode.pixel
        // Before saving the previous display?
	prevDisp = display(0)
	g = new PixelDisplay
	g.install 0

Isn't the code above setting the display-mode before even saving it?

I would have thought the order of events needs to be:

_viewImage = function(pic)
        // ...
	prevMode = display(0).mode
	prevDisp = display(0)
        // Maybe this line is redundant thanks to ...
	display(0).mode = displayMode.pixel
        // ... the following 2 lines?
	g = new PixelDisplay
	g.install 0

Also, would setting the mode to pixel not be redundant since we are installing a PixelDisplay at slot 0 anyway?

The view command currently draws images at 1:1 size. This can be too big or small to clearly see the image. Add the use of + and - to zoom in and out by a factor of sqrt(2).

In the case of viewing a tileset, don't change the size of the numbers drawn; only change where they are drawn to match the scaled image.

If anything modifies the maps that serve as keys in qa.namedMaps, the subsequent qa.namedMaps[x] raises a "Key not found" error. It may affect qa.typeOf and qa.assertType.

]import "qa"
]
]qa.namedMaps[map]
map
]
]import "mapUtil"
]
]qa.namedMaps[map]
Runtime Error: Key Not Found: '{"hasIndex": FUNCTION(self, index), "
indexes": FUNCTION(self), "indexOf": FUNCTION(self, value, after), "
len": FUNCTION(self), "pop": FUNCTION(self), "push": FUNCTION(self,
value), "pull": FUNCTION(self), "shuffle": FUNCTION(self), "sum": FU
NCTION(self), "remove": FUNCTION(self, k), "replace": FUNCTION(self,
 oldval, newval, maxCount), "values": FUNCTION(self), "get": FUNCTIO
N(key, defaultValue), "hasValue": FUNCTION(v, includeInherited=0), "
sortedIndexes": FUNCTION(), "inverse": FUNCTION(), "filterIndexes":
FUNCTION(func), "filterValues": FUNCTION(func), "applyToValues": FUN
CTION(func), "pairs": FUNCTION(), "swap": FUNCTION(key1, key2)}' not
 found in map [line 1]
]

add in the follow code as a function to sprites as part of localbounds check maybe or a spriteUTIL that could be imported.

Sprite.overSolidPixel`` = function(pos)
x = (pos.x - self.x) / self.scale + self.image.width/2
y = (pos.y - self.y) / self.scale + self.image.height/2
c = self.image.pixel(x,y)
text.row = 25
return c[-2:] > "88"
end function

Use case would be such as in the blog post at https://dev.to/joestrout/pixel-perfect-sprite-clicks-20dl

Small issue ... On line 1257:

Swatch.make = function(x, y, c=color.white, selected=false)
	noob = new Swatch
	noob.init x, y, c, selected
	return noob
end function

The argument c=color.white does not have a "literal" as default value.

This will cause a parsing error in MM 1.2.

Solution would be of course something like:

Swatch.make = function(x, y, c=null, selected=false)
        if c == null then c = color.white
	noob = new Swatch
	noob.init x, y, c, selected
	return noob
end function

This came up as part of Advent of Code 2023, Day 18.

Given this polygon:

[[461938, 1], [461938, -56406], [818609, -56406], [818609, -919646],
 [1186329, -919646], [1186329, -1186328], [609066, -1186328], [609066, -356353], 
[497057, -356353], [497057, -1186328], [5411, -1186328], [5411, -500254], [0, -500254], [0, 1]]

...we get different answers using the built-in mathUtil.polyArea than we do with custom code implementing the Shoelace algorithm:

MathUtil.polyArea:  952408211456
Custom polygonArea: 952408144115

And the custom code's answer is correct. Here's the code for that:

polygonArea = function(verts)
    area = 0.0
    n = verts.len
    j = n - 1
    for i in range(0,n-1)
        area += (verts[j][0] + verts[i][0]) * (verts[j][1] - verts[i][1])
        j = i
    end for
    return abs(area / 2.0)
end function

Minimal reproducing case:

foo: bar
baz: {
    this is the bug: //right here
}
qux: aaa

Expected parsing (of course, a less forgiving parser would probably choose to error here):

{
    "foo": "bar",
    "baz": {"this is the bug": null},
    "qux": "aaa"
}

What we get instead:

{
    "foo": "bar",
    "baz": {"this is the bug": null, "qux": "aaa"}
}

By adding a check for asvalue in my implementation, I was able to achieve the former parsing (to an extent; if there's another key on the next line, it will be interpreted as the value of "this is the bug", with that key's value becoming the value of "" due to a different bug that has to do with colons in value strings but I am a firm believer in "garbage in, garbage out" and if you've stumbled across that bug your GRFON file has worse issues than slightly awkward parsing).

Here you can see the issue with the "Squawk Test 1" example GRFON file (which, due to the bug mentioned in the last parenthetical, interprets the author as having a "www" of "http", a "" of null, and then promptly wigs out):

As you can see, "context" and the squawks are attributed to "author" despite obviously being in the top level collection.

Sprites already have the concept of "local" and "world" coordinates, embodied in their localBounds and worldBounds properties.

But sometimes (as in #10), it's handy to convert between these coordinate systems. It might be nice to have localToWorld and worldToLocal methods that do this, taking into account scaling, rotation, and position in the same way that worldBounds does.

This would make it easier to figure out the sprite image pixel under a screen point, though that still will require a bit of math since images are centered on local 0,0.

Execute the view command against a text file. Instead of using ESC to exit, press CTRL-C. This breaks out of code execution back to the REPL. See the screenshot. The output of the print statements should be across multiple lines.

MiniBASIC captures CTRL-C and tells the user to use "exit", so I'm assuming its possible to capture it in the code for the view command.

MiniMicro partially works on WSL!

But, it crashes if you try to mount a folder.

Probably a WSL problem. I'm probably missing certain packages, just don't know what ones.