I'm playing with Open Flash Chart. Take a look at this chart:
http://teethgrinder.co.uk/open-flash-chart-2/line-solid-dot.php
As you can see, the rounded dot points look ugly. Some of them are more rounded, some of them less, they don't look the same, as they should. I don't know AS3 and have no idea what is the case. I checked the source code:
this.graphics.lineStyle( 0, 0, 0 );
this.graphics.beginFill( colour, 1 );
this.graphics.drawCircle( 0, 0, style.get('dot-size') );
this.graphics.endFill();
I tried to change the size or draw rectangles instead, but they still don't look the same. I guess the problem is somewhere else...
EDIT: I also noticed, that other elements also looks a little bit different (and they shouldn't) - for example axis ticks. My guess is that it is the quality problem. But when I right-click on the flash object, there is an option "quality" and the "high" is set (there is also a "medium" and a "low" to choose). Can I increase the quality level somewhere else?
From hollow dots, I came to realize there is something around each dot which separated each dot from the connecting lines & also produced blurry hollow dots.
Setting the attribute "halo_size" to 0 helped in this case.
I noticed the same gap in your sold dots examples as well. Maybe that's the problem.
To set stage quality, simply use:
stage.quality = "low";
stage.quality = "medium";
stage.quality = "high";
You may set it in the main class itself which happens to be the document class for this project.
I noticed that if the chart size is 400 x 400 these inconsistencies cease to exist. So the problem we see is a scaling problem & not at the place we think.
Besides, Setting line style allows a proper border around the circle. This will at least appear better.
this.graphics.lineStyle(1, colour, 1);
this.graphics.beginFill( colour, 1 );
this.graphics.drawCircle( 0, 0, style.get('dot-size') );
this.graphics.endFill();
Related
I have a single pixel sprite. To this sprite I add four sprites, each a quarter of a square. To offset the sprites, all i do is change their anchor points.
For example:
top right square is at anchor: (0,0);
bottom right : (0,1);
bottom left : (1,1);
top left : (1,0);
I expected the sprite edges to meet perfectly so that it looks like one big square. Instead there are black lines between the edges of each square so it looks like I have placed four squares close together.
I use texture packer to create a sprite sheet, containing the various squares.
Is there some setting in cocos2d-x or some code I must change to get the sprites to align perfectly ?
Edit: This is for cocos2d-x 3.1.1 and higher. Changing the anchor point is necessary and unavoidable.
EDIT: I use sprite frames from a sprite sheet created using TexturePacker. This was the problem. See my answer below.
The problem has something to do with using a sprite sheet (created using TexturePacker) to hold the pieces together. When you place the frames from the sprite sheet together to form a complete image the lines appear.
You can make the black lines disappear by setting the "Extrude" option in Texturepacker to at least 1.
EDIT: For those of you updating sprite positions based on a physics simulation, black lines can be caused by "sub pixel" positions. Try to either move your objects by complete pixels. Or search for answers with "sub pixel" for other solutions.
casting positions calculations to int type didn't help ?
Generally after certain float calculations like multiplying and divide and then complier auto demoting to to int may result in variation of 1px.
for example 26.500123 can be treated as pixel 26 or 27, depending to your casting methodology.
Test Case:
Are you saying you did this ?
auto testNode = Node::create();
auto s1 = Sprite::create("Images/1.png");
s1->cocos2d::Node::setAnchorPoint(Point(1,0));
auto s2 = Sprite::create("Images/2.png");
s2->cocos2d::Node::setAnchorPoint(Point(0,0));
auto s3 = Sprite::create("Images/3.png");
s3->cocos2d::Node::setAnchorPoint(Point(1,1));
auto s4 = Sprite::create("Images/4.png");
s4->cocos2d::Node::setAnchorPoint(Point(0,1));
testNode->addChild(s1);
testNode->addChild(s2);
testNode->addChild(s3);
testNode->addChild(s4);
testNode->setPosition(Point(screenSize.width/2,screenSize.height/2));
this->addChild(testNode);
and you got 1px gap ? i did that same with cocos2dx 3.1
i got this fine lady
Don't change anchorPoint, you'll regret it later. Calculate the correct position for each sprite.
Make sure the position x/y are on pixel boundaries. Casting to int will do the trick though Retina devices allow for 0.5 positions as well due to pixel density being 2x the point resolution.
Point #2 is also why you shouldn't use anchorPoint because you can't cast the position to integers when offsetting the texture with the anchorPoint.
The problem
I'm trying to create a brush tool with opacity jitter (like in Photoshop). The specific problem is:
Draw a stroke on an HTML canvas with different levels of opacity. Pixels with higher opacity should replace pixels with lower opacity; otherwise, pixels are left unchanged.
Transparency should not be lost in the process. The stroke is drawn on a separate canvas and merged with a background canvas afterwards.
The result should look like this. All code and the corresponding output can be found here (JSFiddle).
Because you can't stroke a single path with different levels of opacity (please correct me if I'm wrong) my code creates a path for each segment with different opacity.
Non-solution 1, Using the 'darken' blend mode
The darken blend mode yields the desired result when using opaque pixels but doesn't seem to work with transparency. Loosing transparency is a dealbreaker.
With opaque pixels:
With transparent pixels:
Non-solution 2, Using the 'destination-out' compositing operator
Before drawing a new stroke segment, subtract its opacity from subjacent pixels by using the 'destination-out' compositing operator. Then add the new stroke segment with 'source-over'. This works almost but it's a little bit off.
Looking for a solution
I want to avoid manipulating each pixel by hand (which I have done in the past). Am I missing something obvious? Is there a simple solution to this problem?
"Links to jsfiddle.net must be accompanied by code."
Because you can't stroke a single path with different levels of opacity (please correct me if I'm wrong)
You're wrong =)
When you use globalCompositeOperation = 'destination-out' (which you are in lineDestinationOut) you need to set the strokeStyle opacity to 1 to remove everything.
However, simply changing that in your fiddle doesn't have the required effect due to the order of your path build. Build the 10% transparent one first, the whole length, then delete and draw the two 40% transparent bits.
Here's a jsfiddle of the code below
var canvas = document.getElementById('canvas');
var cx = canvas.getContext('2d');
cx.lineCap = 'round';
cx.lineJoin = 'round';
cx.lineWidth = 40;
// Create the first line, 10% transparency, the whole length of the shape.
cx.strokeStyle = 'rgba(0,0,255,0.1)';
cx.beginPath();
cx.moveTo(20,20);
cx.lineTo(260,20);
cx.lineTo(220,60);
cx.stroke();
cx.closePath();
// Create the first part of the second line, first by clearing the first
// line, then 40% transparency.
cx.strokeStyle = 'black';
cx.globalCompositeOperation = 'destination-out';
cx.beginPath();
cx.moveTo(20,20);
cx.lineTo(100,20);
cx.stroke();
cx.strokeStyle = 'rgba(0,0,255,0.4)';
cx.globalCompositeOperation = 'source-over';
cx.stroke();
cx.closePath();
// Create the second part of the second line, same as above.
cx.strokeStyle = 'black';
cx.globalCompositeOperation = 'destination-out';
cx.beginPath();
cx.moveTo(180,20);
cx.lineTo(260,20);
cx.stroke();
cx.strokeStyle = 'rgba(0,0,255,0.4)';
cx.globalCompositeOperation = 'source-over';
cx.stroke();
cx.closePath();
Use two layers to draw to:
First calculate the top layer opacity 40% - 10% and set this as alpha on top layer
Set bottom layer to 10%
Set top layer with dashed lines (lineDash) (calculate the dash-pattern size based on size requirements)
Draw lines to both layers and the bottom layer will be a single long line, the top layer will draw a dashed line on top when stroked.
Copy both layers to main canvas when done.
#HenryBlyth's answer is probably the best you're going to get; there's no native API to do what you're being asked to do (which, in my opinion, is kinda weird anyways... opacity isn't really supposed to replace pixels).
To spell out the solution in one paragraph: Split up your "stroke" into individual paths with different opacities. Draw the lowest opacity paths as normal. Then, draw the higher opacities with "desitination-out" to remove the low-opacity paths that overlap. Then, draw the high opacity paths as usual, with "source-over", to create the effect desired.
As suggested in the comments to that answer, #markE's comment about making each path an object that is pre-sorted before drawing is a great suggestion. Since you want to perform manual drawing logic that the native API can't do, turning each path into an object and dealing with them that way will be far easier than manually manipulating each pixel (though that solution would work, it could also drive you mad.)
You mention that each stroke is being done on another canvas, which is great, because you can record the mouseevents that fire as that line is being drawn, create an object to represent that path, and then use that object and others in your "merged" canvas without having to worry about pixel manipulation or anything else. I highly recommend switching to an object-oriented approach like #markE suggested, if possible.
This page shows some animations in HTML5 canvas. If you look at the source of the scroller, there's a statement to save the context after clearing the rectangle and restoring it after the animation. If I substitute the restore statement with another ctx.clearRect(0, 0, can.width, can.height statement, nothing works. I thought the restore is restoring the cleared rectangle but it seems its restoring more info. What's that extra info that's needed for the next frame?
I am not looking for HTML5 textbook definitions of Save and Restore but I want to understand why they are needed in this specific example.
UPDATE
It's frustrating to get an answer where I specifically already mentioned in the question I don't want to get the definitions of save() and restore(). I already know Save() saves the state of the context and Restor()e restores it. My question is very specific. Why is restore() used in the manner in the example when all the Save did is saved an empty canvas. Why is restoring an empty canvas not the same as clearing it?
Canvas state isn't what's drawn on it. It's a stack of properties which define the current state of the tools which are used to draw the next thing.
Canvas is an immediate-mode bitmap.
Like MS Paint. Once it's there, it's there, so there's no point "saving" the current image data, because that would be like saving the whole JPEG, every time you make a change, every frame...
...no, the state you save is the state which will dictate what coordinate-orientation, dimension-scale, colour, etc, you use to draw the NEXT thing (and all things thereafter, until you change those values by hand).
var canvas = document.createElement("canvas"),
easel = canvas.getContext("2d");
easel.fillStyle = "rgb(80, 80, 120)";
easel.strokeStyle = "rgb(120, 120, 200)";
easel.fillRect(x, y, width, height);
easel.strokeRect(x, y, width, height);
easel.save(); // stores ALL current status properties in the stack
easel.rotate(degrees * Math.PI / 180); // radians
easel.scale(scale_X, scale_Y); // any new coordinates/dimensions will now be multiplied by these
easel.translate(new_X, new_Y); // new origin coordinates, based on rotated orientation, multiplied by the scale-factor
easel.fillStyle = "gold";
easel.fillRect(x, y, width, height); // completely new rectangle
// origin is different, and the rotation is different, because you're in a new coordinate space
easel.clearRect(0, 0, width, height); // not even guaranteed to clear the actual canvas, anymore
easel.strokeRect(width/2, height/2, width, height); // still in the new coordinate space, still with the new colour
easel.restore(); // reassign all of the previous status properties
easel.clearRect(0, 0, width, height);
Assuming that you were only one state-change deep on the stack, that last line, now that your canvas' previous state was restored, should have successfully cleared itself (subpixel shenanigans notwithstanding).
So as you can see, it has very, VERY little to do with erasing the canvas.
In fact, it has nothing to do with erasing it, at all.
It has to do with wanting to draw something, and doing the basic outlining and sweeping colours/styles, and then manually writing in the colours for the smaller details on top, and then manually writing all of the styles back the way they were before, to go back to sweeping strokes for the next object, and on and on...
Instead, save general states that will be reused, create a new state for smaller details, and return to the general state, without having to hard-code it, every time, or write setter functions to set frequently-used values on the canvas over and over (resetting scale/rotation/affine-transforms/colours/fonts/line-widths/baseline-alignment/etc).
In your exact example, then, if you're paying attention, you'll see that the only thing that's changing is the value of step.
They've set the state of a bunch of values for the canvas (colour/font/etc).
And then they save. Well, what did they save?
You're not looking deep enough. They actually saved the default translation (ie: origin=0,0 in original world-space).
But you didn't see them define it?
That's because it's defined as default.
They then increase the step 1 pixel (actually, they do this first, but it doesn't matter after the first loop -- stay with me here).
Then they set a new origin point for 0,0 (ie: from now on, when they type 0,0 that new origin will point to a completely different place on the canvas).
That origin point is equal to x being the exact middle of the canvas, and y being equal to the current step (ie: pixel 1 or pixel 2, etc... and why the difference between starting at 0 and starting at 1 really doesn't matter).
Then what do they do?
They restore.
Well, what have they restored?
...well, what have they changed?
They're restoring the point of origin to 0,0
Why?
Well, what would happen if they didn't?
If the canvas is 500px x 200px, and it starts at 0,0 in our current screen space... ...that's great...
Then they translate it to width/2, 1
Okay, so now when they ask to draw text at 0,0 they'll actually be drawing at 250, 1
Wonderful. But what happens next time?
Now they're translating by width/2, 2
You think, well, that's fine... ...the draw call for 0,0 is going to happen at 250, 2, because they've set it to clear numbers: canvas.width/2, 2
Nope. Because current 0,0 is actually 250,1 according to our screen. And one translation is relative to its previous translation...
...so now you're telling the canvas to start at it's current-coordinates' 0,0 and go left 250, and down 2.
According to the screen (which is like a window, looking at the map, and not the map, itself) we're now 500px to the right, and 3 pixels down from where we started... And only one frame has gone by.
So they restore the map's coordinates to be the same origin as the screen's coordinates (and the rotation to be the same, and the scale, and the skew, etc...), before setting the new one.
And as you might guess, by looking at it, now, you can see that the text should actually move top to bottom. Not right to left, like the page says...
Why do this?
Why go to the trouble of changing the coordinate-system of the drawing-context, when the draw commands give you an x and y right there in the function?
If you want to draw a picture on the canvas, and you know how high and wide it is, and where you'd like the top-left corner to be, why can't you just do this:
easel.drawImage(myImg, x, y, myImg.width, myImg.height);
Well, you can.
You can totally do that. There's nothing stopping you.
In fact, if you wanted to make it zoom around the screen, you could just update the x and y on a timer, and call it a day.
But what about if you were drawing a game character? What if the character had a hat, and had gloved hands, and big boots, and all of those things were drawn separate from the character?
So first you'd say "well, he's standing at x and y in the world, so x plus where his hand is in relation to his body would be x + body.x - hand.x...or was that plus..."
...and now you have draw calls for all of his parts that are all looking like a notebook full of Grade 5 math homework.
Instead, you can say: "He's here. Set my coordinates so that 0,0 is right in the middle of my guy". Now your draw calls are as simple as "My right hand is 6 pixels to the right of the body, my left hand is 3 pixels to the left".
And when you're done drawing your character, you can set your origin back to 0,0 and then the next character can be drawn. Or, if you want to attempt it, you can then translate from there to the origin of the next character, based on the delta from one to the other (this will save you a function call per translation). And then, if you only saved state once the whole time (the original state), at the end, you can return to 0,0 by calling .restore.
The context save() saves stuff like transformation color among other stuff. Then you can change the context and restore it to have the same as when you saved it. It works like a stack so you can push multiple canvas states onto the stack and recover them.
http://html5.litten.com/understanding-save-and-restore-for-the-canvas-context/
When drawing lines with the HTML5 canvas element, is it possible to define the stroke style of the lines? Basically in Photoshop and other similar programs, you can define a stroke style for lines that looks like it is "hand drawn". Is is possible to do anything like that in HTML5 canvas or am I shooting for the moon here?
Thanks
-Jesse
It is possible but not by default. See ShadowCloud's post for what you can do by default (very little).
Depending on what you want, it shouldn't be too hard.
If by "hand drawn" you mean you want jitter, you'd have to break up every drawn line/curve into smaller parts and add some noise to each of the points.
If you want a brush you'd have to break up every drawn line/curve into smaller parts and call drawImage every few pixels to emulate a photoshop brush.
Almost all of them rely on breaking up your lines and curves into smaller bits, so you should figure that out foremost.
If you decide to implement these and are having trouble breaking up bezier curves and want help, let me know and I'll give you my code for that.
There is no standard API in HTML5 Canvas to manage such thing.
You can just set the color or the width of the stroke, for example:
context.strokeStyle = '#f00'; // red color
context.lineWidth = 4; // 4px wide
// Draw some rectangles.
context.fillRect (0, 0, 100, 100);
context.strokeRect(0, 0, 100, 100);
You can try to get more control using a library (Processing.js or Fabric.js)
I'm using the AS3 drawRoundRect function as in the following snippet:
g.lineStyle(1, 0x808080, 1, true);
g.drawRoundRect(0, 0, 100, 24, 12, 12);
As you can see, pixel hinting is on.
The problem I'm having is corners being anti-aliased way too much, they are way too blurry and not even symmetrical on the above snippet. Frankly, the drawRoundRect function draws the ugliest rounded rectangles that I've ever seen.
Is there a way to make AS3 draw more crisp rectangles?
Thanks!
:)
fills are rendered much better than lines. as you can see here:
const thickness:Number = 1;
g.beginFill(0x080808);
g.drawRoundRect(0, 0, 100, 24, 12);
g.drawRoundRect(thickness, thickness, 100 - 2 * thickness, 24 - 2 * thickness, 12 - thickness);
g.endFill();
g.lineStyle(thickness, 0x080808, 1, true);
g.drawRoundRect(0, 50, 100, 24, 12);
well, it is not SOOOOOOOOOOO unincredibly better ... :-S ... but at least its symetric ... and the smudges on the corners are more like little beads ... :-D
greetz
back2dos
I've had similar problems in the past. It usually came down to one of the movieclips along the display path not being on an even pixel. Flash then tries to render fractional pixels, which it can't do, which caused distortion and blurriness.
So, make sure all your movieclips/sprites are on an even pixel (I know you're drawing the rect on even pixels, but if the displayobject it belongs to, or any of its parents aren't on an even pixel, it would be causing the problem).
I've had the same deal, as well. One hacky trick you could try is to apply a minor blur filter to the parenting object.
It looks like you're using the drawRoundRect method of the Graphics class.
If the object you're working with is a UIComponent, you could try using the drawRoundRect method of UIComponent. It takes an Object for the cornerRadius value, rather than setting ellipse width and height values. I'm not 100% sure that the cornerRadius value isn't converted into ellipse width and height, but it seems like it'd be something to try.
Also, you could try the GraphicsUtil class's drawRoundRectComplex. It takes a Number for each corner's radius. Again, not completely sure that it doesn't eventually use the same underlying mechanics as drawRoundRect.
When you using drawRoundRect set X to be half of thickness, and then thickness will be on rounded pixel. In this your case try:
g.lineStyle(1, 0x808080, 1, true);
g.drawRoundRect(0.5, 0.5, 99, 23, 12, 12);