-
Notifications
You must be signed in to change notification settings - Fork 122
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
Software rendering fixes from lime - gone! #143
Comments
I've investigated this a little more. All the same nearest neighbor rasterization issues are broken again in the latest nme. The problem is either due to the pixel-center sampling or the (unnecessary?) rounding while converting to Fixed10. I haven't confirmed this. Both changes were made back in lime here: openfl/lime@cda7b69. |
This looks more like an offset issue than a scaling issue. Should be able to tell by putting a pixel at 0,0 in the bitmap and seeing where it comes out. |
Thinking about this again - what are you using to do the render? Tiles, bitmap, beginBitmapFill, triangles? For pixel-aligned, 1:1 scaling the smooth render should look exactly the same as the nearest-neighbour scaling. |
This is a bitmap font, which is using tiles to render. I'll grab nme-dev and try reapplying my previous fixes. I'm pretty sure the problem is related to one of the two issues I found and fixed before: either sampling from the pixel centers or the rounding before converting to Fixed10. |
To add a little more info, all tiles are set with integer pixel coordinates and hardware mode renders correctly. |
Reapplying openfl/lime@cda7b69 improves things but doesn't fix the problem completely. There are still cut-off tiles and Stage scaling problems. I'll try to put together a simple project that illustrates the problem clearly. |
Ok. Sample project here: https://www.dropbox.com/s/utviyu3e5xuyqds/SoftwareRasterizationError.zip It draws a grid of tiles into the main sprite, then calls BitmapData.draw() to copy the sprite into a child Bitmap for comparison. Build/run to see this: Note the offset sampling on the left side. The right side is the same sprite copied into a BitmapData, which for some bizarre reason doesn't exhibit the problem. The offset sampling is dependent on the sprite's scale. Everything renders properly in hardware mode. |
The right side is working I think because it does the render at 1:1 and then a scale. |
Works perfectly. Thanks Hugh!
Interesting. That gives me an idea to render to an offscreen Sprite and save some performance in software mode... |
There were several important software rendering fixes that Josh and I made to lime. These have been lost with the merge back into nme.
Fix low-quality software tile rasterization issues
openfl/lime@cda7b69
Fix software fallback on some older/more minimal graphic cards
openfl/lime@7ab0953
It looks like Hugh (@hughsando) rewrote the software bilinear interpolation, which is great, but in doing so broke the nearest neighbor rasterization again. Hugh, did you intentionally leave out these fixes (I don't claim they were perfectly implemented) or is this an oversight?
The text was updated successfully, but these errors were encountered: