I was just wondering if we will ever be able to scale sprites again without experiencing blurring and pixelation on the c++ target? The vector/scaling capabilities was always one of the greatest features about the flash platform but I understand this might not be as easy to do with GPU-acceleration.
Picture for clarification:
This is something that needs to be considered, I’m not 100% sure of the right solution yet.
In Flash, it’s a software renderer. Redrawing every frame is not a big deal. However, with hardware rendering, drawing something in software once, or every frame, can be a big deal, and surprise performance-wise. Currently graphics draw at 1:1 scale, and use hardware transforms from then on. I’m concerned of the performance if we draw at the final transform size, like what if you tween the scale, etc.
Well could there not be an option to force a redraw? Since scaling down currently works perfectly, could the DisplayObject not cache some kind of an upper limit so you could scale flawlessly between 0.0 and say 2.0? And whenever the scale passes the 2.0(or whatever) threshold It would redraw the graphics and give you a new upper limit.
tl;dr only redraw when passing some magic threshold
Is it perhaps possible to force to switch to a software renderer in other targets than flash? e.g. for apps that don’t demand hw acceleration.
You could try --window-hardware=false if you want, to try it running through Cairo entirely
Thanks for the answer @singmajesty,
now I am reading the openfl cmd help (used to write command --help I didn’t get it until I tried openfl help).
I tried to compile with window hardware on false but I still never get the nice vectorial results that flash brings in any other platform; the same happens with other backends being the neko the worse usually .
Here a comaprison cpp (window hw false) vs default flash:
If you zoom you can see that the result in CPP never gets as nice as in flash; not sure why it never looks as good as flash but perhaps I missed something about the hxml configurations.
Later I may open a separate thread about how defined looks something as simple as a polygon.
Are you scaling the Sprite? Can you try comparing without a scale value?
No, the sprite is not scaled, normal size and the triangle is made drawing by given vertices; you can see the source code for the draw here; and the whole code with the main here.
But the same happens with any sprite, included text or traces. In HTML is also quite bad, especially while compared to any other framework for HTML.
Here is an elm example on the left (safari) which I translated to OpenFL (on the right; chrome) using the same code as before. The results are the same independently from the browser.
(zoom on the vertices of the triangle or in the hexagon to see difference).
As you see there is a considerable difference between both i and all that they are doing is to draw a simple polygon based on the coordinates; I don’t really know how the render process works but to make a polygon I expected results as good as vectorial ones.
Is there any place where the rendering could be tuned to improve the rendering? (I even don’t know what I am looking for, density per pixel maybe).
Note: Elm is not a haxe framework as OpenFL but another programming language.
Okay, so this does not look aliased, but perhaps could be bumped by 0.5 pixel or something to be sharper on some edges. Is this what you mean?
Yes, it is exactly what I mean… Is there any documentation to get started on that topic? Does OpenFL provide a way to tune those things? And… it is possible to increase the density of pixels?
I am trying to look for any option on the Sprite methods that would led me to do those things; any link to examples / documentation / manuals …?
I am searching on the forum for older questions, but at the moment I just found antiAliasing for textField…
This looks like the difference of setting (x, y) and (x + 0.5, y + 0.5) in the canvas renderer code, the types of nuances that are not a property, but micro-optimizations that could be made to the renderer to make it even sharper.
At the moment, your first desktop screenshot looks scaled to me, but the web browser screenshot looks “correct”
I hope you understand what I mean
On the neko/native target I appreciated quite good improvements by having twice big all sizes and then scaling everything at 0.5 (I don’t have now a screenshot), the sides of the triangle needed to be smoothed because I could see the pixels drawing the line (as in Bresenham’s algorithm).
That trick in HTML5 had no visible effects.
I should live with it