Is it possible to put multiple repeating gradients on a single sprite master image? I've got about 5 1px X 400 px gradients that could be combined to reduce the page requests. It's pretty much my last place to go for reducing object requests. I haven't seen any techniques for this while searching. My own experimentation hasn't had good results.
Assuming that all the areas you're applying the background gradients to are less than 400px high, you can tile the five sprites vertically to give you a single 1x4000px image.
You could apply the appropriate part of the sprite by specifying a vertical offset, and setting background-repeat:repeat-x.
The vertical offset would be 400 * (index of the sprite you want): 0px for the first, 400px for the 2nd, 800px for the 3rd, etc.
Related
My aim is to draw a set of texures (128x128 pixels) as (gap-less) tiles without filtering artifacts in XNA.
Currently, I use for example 25 x 15 fully opaque tiles (alpha is always 255) in x-y to create a background image in a game, or a similar number of semi-transparent tiles to create the game "terrain" (foreground). In both cases, the tiles are scaled and drawn using floating-point positions. As it is known, to avoid filtering artifacts (like small but visible gaps, or unwanted color overlaps at the tile borders) one has to do "edge padding" which is described as adding an additional fringe of a width of one pixel and using the color of adjacent pixels for the added pixels. Discussions about this issue can be found for example here. An example image of this issue from our game can be found below.
However, I do not really understand how to do this - technically, and specifically in XNA.
(1) When adding a fringe of one pixel width, my tiles would then be 129 x 129 and the overlapping fringes would create quite visible artifacts of their own.
(2) Alternatively, once could add the padding pixels but then not draw the full 129x129 pixel texture but only its "center" (without the fringe) e.g. by choosing the source rectangle of this texture to be (1,1,128,128). But are then the padding pixels not simply ignored or is the filtering hardware really using this information?
So basically, I wonder how this is done properly? :-)
Example image of filtering issue from game: Unwanted vertical gap in brown foreground tiles.
How do I explain the Histogram of Oriented Gradients algorithm to a layman?
Finding the "gradient" of a pixel is finding if there is an edge passing through that pixel, the orientation of that egde and how visible is this edge.
As we are taking into account the direction of the edges, we say "oriented gradients".
The "histogram" counts how many pixels have an edge with a specific orientation. The pixels that have visible edges count more than the pixels that have soft edges.
For example if we have a square in the image, we will see that the HOG has a lot of pixels counted in the vertical direction, and the same amount of pixels counted in the horizontal direction, no pixels would get counted in the diagonal directions. If we had a rectangle laying flat, there would be more pixels in the horizontal direction than in the vertical, because the horizontal edges are longer. If we had a diamond, we would count pixels with diagonal edges. This way you can recognize shapes just comparing the histograms (how many pixels have edges in each direction).
If we need to find squares (or faces, or people or anything) of a specific size, we divide the image in blocks of the size of the squares we want to find and compare the HOG that we obtain with the HOG of the thing that we are searching.
I have found the lecture given by Dr. Silvio on HoG to be extremely effective in explaining the concept. I have used to this when I was studying myself and also for explanation to others and it has worked really well every time. HTH
PS - Copyrights for the slides belong to Dr. Silvio and his group.
I am trying to implement a 2-D fast collision detection with Quad-Tree.
AFAIK, Quad-Tree divides a region into 4 sub-regions, north-west, north-east, south-east and south-west. This dividing works perfectly with a square. But what if the region is a non-square rectangle? In that case, we cannot divide the long edge and the short edge evenly, and the short edge determins how far we can divide.
Am I right on this? Is that meant to be?
Simply take the max of width, height of the bounding box of the region of interest as the side length of the quad tree.
Another solution:
Two quad tree implementtaions that i have seen uses a rectangle internaly, so that would run out of the box, even if the provided root bounds is not a square. They divide both the width and the height of the bounds in each subdivision step. But note that there are ovr 10 different Quadtree types. I am talking about Rectangle Quadtrees.
One implemention explictly uses a a side length which is divided by 2, so that would not work fine for non square root bounds.
However, I still recommend my first sentence, better use a square as root bounds.
This then works for all quad tree types.
How to draw a circle overlapping another circle in the moved phase of touch event,such that no gap is left out between the circles.The circles must be tightly packed to one another,so that even when user moves his hand on the screen faster or lightly,no gap must be present between the circles.
Just two circles? Or many circles? If just two, then detecting if they overlap is simply verifying that their centers are not closer than the sum of their radii. For example, if Circle1's raduis is 10 pixels, and Circle2's radius is 25 pixels, then they overlap if the center of Circle1 is less than 35 pixels from the center of Circle2.
So if you do your calculations in the "moved" phase and find that they're too close, you have to adjust the position of one of them. How you go about that will depend on the specifics of your application. You could:
Keep the y coordinate of the moving circle the same, and calculate the necessary x coordinate to maintain the required distance.
Same as above but swap x and y.
As above, but move the "unmoving" circle away from the "moving" circle.
Some other calculation that makes sense for your application.
NOTE: You should accept some of the answers you've been given.
Let's say I take a picture of two hammers side-by-side (although they may be aligned differently, but always one on the right and one on the left), wherein each might look like this, and I want to calculate the ratio of the lengths of the handles of the hammers.
For example, the output from an input image would be the length of the red part of the one on the left (its handle) divided by the length of the handle of the one on the right.
How would I go about doing this?
If you know the handle color it doesn't sound hard. Just select those pixels and take the longer side of a minimum oriented bounding box.
Here are a couple of hints:
Make sure that the bounding boxes of the hammers don't overlap. If you can guarantee this, try this approach:
Scale the image to width=10%, height=10px. Find the largest amount of pixels in background color near the middle of the image. That allows you to separate the two hammers into individual images. Multiply the positions by 10 to transform them back into coordinates of the original image.
Create two images (one for each hammer)
Crop the border
Scale the image to width = 10px, height = 10%. Count all reddish pixels (save the image and examine the pixel values for red and non-red parts to get an idea what to look for)