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

Software rendering fixes from lime - gone! #143

Closed
dukope opened this issue Jun 28, 2014 · 9 comments
Closed

Software rendering fixes from lime - gone! #143

dukope opened this issue Jun 28, 2014 · 9 comments

Comments

@dukope
Copy link

dukope commented Jun 28, 2014

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?

@dukope
Copy link
Author

dukope commented Jun 28, 2014

I've investigated this a little more. All the same nearest neighbor rasterization issues are broken again in the latest nme. Sample image here

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.

@hughsando
Copy link
Member

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.

@hughsando
Copy link
Member

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.

@dukope
Copy link
Author

dukope commented Jun 28, 2014

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.

@dukope
Copy link
Author

dukope commented Jun 28, 2014

To add a little more info, all tiles are set with integer pixel coordinates and hardware mode renders correctly.

@dukope
Copy link
Author

dukope commented Jun 28, 2014

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.

@dukope
Copy link
Author

dukope commented Jun 28, 2014

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:

screen shot 2014-06-29 at 1 18 19 am

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.

@hughsando
Copy link
Member

The right side is working I think because it does the render at 1:1 and then a scale.
The sampling at the screen pixel centers was ok, and is needed, but the problem was that the bilinear sampling of the source texture coordinates needs an offset before truncation, while the nearest-neighbour sampling does not. This should be fixed now - the dependencies for bitmapfill.h are a bit screwy, so you may need a clean before a rebuild.

@dukope
Copy link
Author

dukope commented Jun 29, 2014

Works perfectly. Thanks Hugh!

The right side is working I think because it does the render at 1:1 and then a scale.

Interesting. That gives me an idea to render to an offscreen Sprite and save some performance in software mode...

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

No branches or pull requests

2 participants