Right now this is as expected - it's what I'd mentioned before about having a slower but more capable fillPoly implementation. The current one works on a scanline basis - filling from lowest X to highest X.
I had to modify it so it handled the topmost Y coordinate correctly (eg when drawing a diamond it'd miss off the top), and then also had to add a 'slope' so that it could handle the duplicate corners that would then be produced.
However drawing vector fonts still results in something like this:
Ok, now fixed. Looks like the code mentioned initially actually does a standard polygon fill thing, which is to not fill the top and right hand pixels so that if you put polygons against each other you don't end up with overdraw - which is why the scanline code refused to draw the top pixel
My hacks will likely cause problems with more complex polygons since i'm effectively duplicating vertices at the corners :(