Pixel Graphics hiccups

SynapticBytes

So following on from my old post about drawing polygons and lines, I'm still having issues with what actually gets rendered by the pixel drawing methods.

As well as the issue with lines not drawing the last point specified, I have an issue which is probably related, with polygons and rectangles not drawing the top-right pixel on any corner point. Here's an example screenshot using drawRect, but the same thing happens with drawPoly.

I know it's pretty small, but hopefully you can see that the top right corner has a small gap unlike the other three corners. When I query the colour on that point, it is returning the background colour. This is causing me no end of trouble as in my game, my player travels along the path circumscribed by the border of the polygon, testing the pixel colour to see if it has moved into open space. The problem is, I want to travel around the corner of the polygon, but it's hitting a roadblock when it sees that vacant pixel. I could manually patch it if I could identify the points it's happening on, but that's not easy to tell from just a list of points. My other option is just to overwrite every corner in my polygon after I draw it, but that's a real kludge.

Is this something we have to live with, or is there a way around it?

Thanks.

SynapticBytes

Well I've gone with the hack for now, with the following function

fixCorners = function(polygon, colour)
for point in polygon
gfx.setPixel point[x], point[y], colour
end for
end function

Suggestions if this format is more or less performant? IF statement speed vs setting pixel speed. I'd think graphics ops are slower than if statements? Not that the impact matters in my code, so I'll leave mine at the first, cleaner function.

fixCorners = function(polygon, colour)
for point in polygon
if gfx.pixel(point[x], point[y]) != colour then
gfx.setPixel point[x], point[y], colour
end if
end for
end function

PS - really wish the code/quote tags would stop stripping whitespace...

jstrout

Your fix looks fine for now. I've already fixed some issues with fillPolygon (particularly on perfectly horizontal edges), but drawPolygon with the default 1-pixel-thick line simply does a series of line commands under the hood. So if line is not always drawing the last pixel — and in some cases not the first? — then this would cause the problem you're seeing.

So I've added this to my to-do list, and I'll get it fixed.

On quoting code: I think it works OK as long as you put three backticks on a line by itself both before and after the code block, like so:

which appears as:

Thing.canGet = function()
	if self.size > 10 then
		printWrap "The "+ self.name + " is much too large to pick up."
		return false
	end if
	return true
end function

jstrout

Here's a fun little test program I'm working with today...

clear
gfx.width = 960/5
gfx.height = 640/5
gfx.scale = 5
cx = gfx.width/2
cy = gfx.height/2
r0 = 10
r1 = cy * 0.8

for ang in range(0, 359, 10)
	radians = ang * pi/180
	x0 = round(cx + r0 * cos(radians))
	y0 = round(cy + r0 * sin(radians))
	x1 = round(cx + r1 * cos(radians))
	y1 = round(cy + r1 * sin(radians))
	gfx.setPixel x0, y0, color.pink
	gfx.setPixel x1, y1, color.pink
	gfx.line x0, y0, x1, y1, color.blue
end for

It draws a bunch of lines at various angles (always from the small radius towards the large radius), but first it plots the start and end points in pink. Then it draws the lines in blue. If everything were working pixel-perfect, there would be no pink left, as it would be overdrawn by the blue lines. But...

So, yeah. Good catch. 🙂

jstrout

...and... after the fix:

😁

Coming to you in Mini Micro v0.8!

jstrout

...or, you could grab the latest bleeding-edge build (currently 0.73), which contains this fix and a handful of others.