I'm building graphic editing web page using svg.
Almost everything is fine except resizing rotated rect.
The problem is, the fixed point (the opposite one that moves to resize) is not fixed.
It's almost fixed, but slightly moving around while resizing.
I think this problem is common because some of the examples has same result.
Try below example (6. Putting it all together).
https://shihn.ca/posts/2020/resizing-rotated-elements/
Why this happen and how can I fix this?
If you are talking about the slight jiggle of the fixed corner, then that will just be due to matematical rounding errors. If you don't want it to jiggle like that, then calculate the position of that fixed corner once, after the rotation changes. Then reuse thos coordinates while you are dragging the other corner. Don't recalculate the corner every time.
Related
I want to detect that the sprite has encountered a color in pygame, which function should I use to achieve this function.
Though it is possible to get the color at any point in the surface that you want to check against using get_at() (docs here). You would need to find the new area that your sprite covered that it did not cover last time and check every pixel in that, and if other things were moving around you would have to check if your sprite now overlapped with any of those area and check that. Or you could decide that was too complicated and just run through every pixel under your sprites location (without you sprite drawn yet) and check for that color.
It is possible, but would likely not be very fast.
An alternative is if you know where those colors are you can mark those areas using rects, circles, sprites or masks (see here and here) that you can check against. That is usually much faster. These do not have to be drawn and so would be invisible. They would just be used to mark areas for the collision check.
If you do not know exactly where the colors are in the background or the other images, you can create masks based on the colors in them using pygame.mask.from_surface() or pygame.mask.from_threshold() (docs here and here).
<------This is an image I made in Photoshop...
It's basically a 160 x 160 box of white with a texture applied.
Below is what it looks like with "background-repeat" in the CSS. I was hoping it'd balance out. Is there a certain percentage the textile has to be at, or size of the original box? For it to be a perfect repeatable texture?
Im trying to do this myself, since I cant find grid patterns that fit the style.
Question: Whats the trick on making textures in Photoshop, that appear as balanced whole backgrounds when repeated?
If you look at the below image where it's in effect, on the very basic start of what Im working on, you can notice it doesnt quite fit together.
Any and all help greatly appreciated. Thanks in advance.
If you want that background for a webpage is better the use of repeating-linear-gradient. It is very easy of implement, less assets to download and it is supported by major browsers.
Look in the top left corner of your image. You'll note that the dark line starts at roughly 4-5 pixels from the top. Then look at the top right corner, and you'll note that the top line starts at just perhaps 2px from the top.
When this image is repeated twice side by side, there will be a disconnect. Just crop the image and shave off the two or three pixels until your lines connect. Repeat by cropping the bottom of the image for vertical alignment.
If you want to do this experimentally, increase the size of your canvas, and copy the pattern into a new 160x160 layer. Place them side by side, and then move the layers one pixel at a time so that they overlap. Where the overlap aligns is where you should crop the image.
My graphics are looking blurry unless I add or subtract a half pixel to the Y coordinate.
I know this is a symptom that usually happens when the coordinates are set to sub-pixel values. Which leads me to believe one of my views must be off or something.
But I inspected the window, view controller and subviews, and I don't see any origins or centers with sub-pixel values.
I am stumped, any ideas?
See if somewhere you are using the center property of a view. If you assign that to other subviews, depending on their sizes they may position themselves in half pixel values.
Also, if you are using code to generate the UI I would suggest using https://github.com/domesticcatsoftware/DCIntrospect. This tools allows you in the simulator to look at all the geometry of visible widgets. Half pixel views are highlighted in red vs blue for integer coordinates. It helps a lot.
I'm adding "mouse rotation" to my 2D drawing program. I've got all the code working, by basically calculating the rotation angle from the original mouse click to wherever the mouse currently is.
I also draw a transparent rectangle that rotates, instead of actually rotating the image on every mouse movement event.
Now, my problem is the drawing of this rectangle. I draw the rectangle from the image's x/y position, with its width/height being what the image reports.
However, after rotating a rectangular image, its new width and height is much bigger, as these two screenshots should help clarify: During rotation, and after rotating then rotating again -- the little "handles" show where the images' x/y/width/height extends to
In the second screenshot, because of the rotation, the image has been padded, sort of with whitespace (it's hard to describe with text!). E.g. an image that's 200x100 can end up like 150x150 (approximately) after rotating, which looks a bit strange when resizing the 2nd time.
Does anyone have an idea how to fix this?
As a rule of thumb, never rotate/resize a previously rotated image as the small errors will start creeping in.
Generally, it is easier to keep a copy of the original image and base ALL changes off that image.
For example, the first rotate is 5 degrees. The second rotate is 15 degrees. To render the second image, rotate the original copy 20 degrees and display that.
Not sure if that helps or if I have misread your question.
You should probably keep track of the image's current rotation, so that you can re-draw the rectangle around the image at its current rotation. If you are going to need to rotate more than 1 thing, you will have to keep track of layers, and the rotation of each one.
You'll need to store the original dimensions of the image and the current angle of rotation so that you can effectively back out the rotations correctly. Also, you'll need to save the original image data.
What's happening now is that your program loses the information about the original image size, so it uses what it sees (correctly). What you want is a fresh redraw from the original image data, just with a different rotation.
I'm using Löve2D for writing a small game. Löve2D is an open source game engine for Lua. The problem I'm encountering is that some antialias filter is automatically applied to your sprites when you draw it at non-integer positions.
love.graphics.draw( sprite, x, y )
So when x or y is not round (for example, x=100.24), the sprite appears blurred. The same happens when the sprite size is not even, because (x,y) points to the center of the sprite. For example, a sprite which is 31x30 big will appear blurred again, because its pixels are painted in non-integer positions.
Since I am using pixel art, I want to avoid this all the way, otherwise the art is destroyed by this effect. The workaround I am using so far is to force the coordinates to be round by littering the code with calls to math.floor(), and forcing all the sprites to have even sizes by adding a row or column of transparent pixels with the paint program, if needed.
Is there some command to deactivate the antialiasing I can call at program startup?
If you turn off anti-aliasing you will just get aliasing, hence the name! Why are you drawing at non-integral positions, and what do you want it to do about those fractional parts? (Round them to the nearest value? Truncate them? What about if they're negative?)
Personally I would leave the low level graphics alone and alter your code to use accessors for x and y that perform the rounding or truncation that you require. This guarantees your pixel art ends up drawn on integer boundaries while keeping the anti-aliasing on that you might need later.
Another possible work around may be to use math.floor() to round your integers as a cheap workaround.
In case anyone is interested, I've been asking in other places and found out that what I am asking is already requested as feature: http://love2d.org/forum/tracker.php?p=2&t=7
So, the current version of Löve that I'm using (0.5.0) still doesn't allow to disable the antialias filter, but the feature is already in the SVN version of the engine.
you can turn off anti-aliasing by adding love.graphics.setDefaultFilter("nearest", "nearest", 1) to love.load()