Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Oval fix asymmetry #563

Merged
merged 1 commit into from
Sep 28, 2022
Merged

Oval fix asymmetry #563

merged 1 commit into from
Sep 28, 2022

Conversation

ibillingsley
Copy link
Contributor

@ibillingsley ibillingsley commented Sep 11, 2022

Follow-up to #561.
I believe I figured out the discrepancy with drawOval compared to the TIC-80 version used as reference.

Their parameters are an inclusive bounding box. When calculating a and b from width and height we need to subtract 1 to match their algorithm. This seems to correct the asymmetry we were seeing at certain sizes:
wasm4-screenshot-1

@desttinghim fyi

@ibillingsley
Copy link
Contributor Author

ibillingsley commented Sep 11, 2022

For comparison I also tried porting this algorithm from stackoverflow, but I couldn't get the fill quite right. Also it seems less optimized for performance, but has a slightly rounder look at some sizes.
wasm4-screenshot-2

Edit: I pushed my unfinished work on this here if someone wants to play with it.

@JerwuQu
Copy link
Contributor

JerwuQu commented Sep 11, 2022

Nice!

I'm kinda wondering why some of the radii seem to give ovals more resembling octagons in the current solution. Comparing to the second one it's very clear. Is this something that could be fixed?

@ibillingsley
Copy link
Contributor Author

ibillingsley commented Sep 11, 2022

Probably. I tried tweaking some of the parameters but wasn't able to improve it without messing up something else. Would take some work to fully understand the algorithm. I think it's partly because of this condition:

if (err2 >= dx || 2 * err > dy) {
// Move horizontal scan

If I remove || 2 * err > dy (which seems to prevent doubled pixels in the outline) it looks like this:
wasm4-screenshot
but then the vertical and horizontal ones are inconsistent in some cases.

Comparing to the second one it's very clear.

It's a bit of a mixed bag. I agree the 16x16 circle looks better in algorithm 2, but 14x14 looks better in algorithm 1.

@maxcurzi
Copy link
Contributor

I think the latest iteration looks great
image

In the previous the circles have a round shape but the pixels are not drawn with a consistent symmetry (
image

We're splitting hairs (pixels) and the problem here is that there doesn't seem to be a "more correct" way of drawing pixellated circles. https://twitter.com/retronator/status/1029358469185462273/photo/1

In that tweet the top set has circles that are very close to real circles, while the others tend to become octagons...

@desttinghim
Copy link
Contributor

I agree that the top set in that tweet looks the best. In a reply the creator of a pixel art software apparently improved their algorithm to make better ellipses.

@aduros
Copy link
Owner

aduros commented Sep 12, 2022

Thank you everyone for looking into this.

@aduros
Copy link
Owner

aduros commented Sep 28, 2022

This seems like an improvement overall, feel free to iterate on it more if anything looks odd. Thanks!

@aduros aduros merged commit 1ca55a1 into aduros:main Sep 28, 2022
@hazeycode
Copy link
Contributor

My little oval shadows and now rectangle shadows :( I guess I should just paint the shape I want though!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants