Reply to Re: 0.5 preview
If you don't have an account, just leave the password field blank.
Yup, it seems it runs in OpenGL by default, just as you said.
Btw, while there are some discrepancies in how the two renderers handle scaling *INSIDE* the sprite, I think that is to be expected. Every renderer will have different pixel interpolation I imagine, so the inner pixels can't be expected to be the same unless the exact same scaling algorithm is used. I think I mentioned this in the read me and the PDF appendix chapter.
The issue is the outer bounds of the sprite. In your first image, this seems to happen for the bottom right corner at scales of: 95, 90, 85, 80, 75, 65, and 55. It's the same for the 2nd picture too actually. At all of these scales, the bottom right corner is off by 1 pixel both horizontally and vertically.
If you look at "size1_chart.png" in the TEST_CHART_2 folder, the 4th column, the FreeDink column, manifests bottom right corner issues at the scales: 95, 90, 85, 80, 75, 70, 65, 65, 60, 55, 40, 30, 20, and possibly 10, hard to tell with that one as it's too small. In addition, it also has the wrong upper right corner at scales 90, 80, 40, 20 and 10. Which in your pictures does not seem to happen. [*]
I think that we should only expect the outer bounds and trimming edges to be the same between different engine implementations.
Although, that being said, different rendering of the inner pixels can affect shadows in a way that is not really demonstrated by these rectangular test sprites I used. Depending on the scaling algorithm, it can lead to funky situations where the shadow grid pattern either becomes solid black or fully disappears. Perhaps I should think about updating the test dmod so that it also has realistic sprites that have shadows as well?...
Edit:
* - actually, I am curious if the original freedink version has different outer bounds issues on different operating systems and such, hmm! I only tested these under Windows 10.
Edit 2:
Now that I think about it, I think I have some flaw in how I handled this... All of my sprites have their position set to *EVEN* coordinates. But having the sprites be at *ODD* coordinates might affect rendering too... So really, I should just double up all the test screens and offset all the sprites by a pixel, and see what happens under those circumstances.
I may just do that this weekend... And maybe add some scripting so each screen explains what exactly you should look for.
Btw, while there are some discrepancies in how the two renderers handle scaling *INSIDE* the sprite, I think that is to be expected. Every renderer will have different pixel interpolation I imagine, so the inner pixels can't be expected to be the same unless the exact same scaling algorithm is used. I think I mentioned this in the read me and the PDF appendix chapter.
The issue is the outer bounds of the sprite. In your first image, this seems to happen for the bottom right corner at scales of: 95, 90, 85, 80, 75, 65, and 55. It's the same for the 2nd picture too actually. At all of these scales, the bottom right corner is off by 1 pixel both horizontally and vertically.
If you look at "size1_chart.png" in the TEST_CHART_2 folder, the 4th column, the FreeDink column, manifests bottom right corner issues at the scales: 95, 90, 85, 80, 75, 70, 65, 65, 60, 55, 40, 30, 20, and possibly 10, hard to tell with that one as it's too small. In addition, it also has the wrong upper right corner at scales 90, 80, 40, 20 and 10. Which in your pictures does not seem to happen. [*]
I think that we should only expect the outer bounds and trimming edges to be the same between different engine implementations.
Although, that being said, different rendering of the inner pixels can affect shadows in a way that is not really demonstrated by these rectangular test sprites I used. Depending on the scaling algorithm, it can lead to funky situations where the shadow grid pattern either becomes solid black or fully disappears. Perhaps I should think about updating the test dmod so that it also has realistic sprites that have shadows as well?...
Edit:
* - actually, I am curious if the original freedink version has different outer bounds issues on different operating systems and such, hmm! I only tested these under Windows 10.
Edit 2:
Now that I think about it, I think I have some flaw in how I handled this... All of my sprites have their position set to *EVEN* coordinates. But having the sprites be at *ODD* coordinates might affect rendering too... So really, I should just double up all the test screens and offset all the sprites by a pixel, and see what happens under those circumstances.
I may just do that this weekend... And maybe add some scripting so each screen explains what exactly you should look for.
