Following from njuri's response below, I have added a new image asset and placed within it three images: 200 x1, 400 x2, and 600 x3 (please see image below):
Launch Screen in Xcode for Swift
Is this correct? I wasn't sure if you meant 200 x1, 400 x2 and 600 x3 or 200 x1, x2, x3; 400 x1, x2, x3; 600 x1, x2, x3 (in other words 3 images or 9 images).
Also, I have the 'Universal' box checked. Is that correct?
Thanks.
When working with asset catalogs select the placeholder for the asset you will be using and the inspector on the far right bottom will tell you what the expected size. Repeat this for every image you intend to use to find out the size you need.
Related
the problem I'm facing is more a matter of logic and algorithm than a specific language functionalities, i'm coding it in lua, but i believe it could be replicated in other languages with no major problems.
First of all, I'm going to show you some properties and default settings that i'm having to use to come up with a solution.
1. I have a general function that displays an image on the screen, given the X, Y position and W, H dimension, to facilitate understanding, this function is drawImage(x, y, w, h)
2. All values and calculation will be based on a default resolution and aspect ratio, which in this case is the developer's. These variables will be these: DEV_SCREEN_W = 1366, DEV_SCREE_H = 768, (aspect ratio is 16:9)
3. So far, we have a function that displays an image on the screen, and default screen values to which the X, Y position and W, H dimensions of a given image will be set.
4. Now, we have the CLIENT, which can be anyone, with any resolution and aspect ratio, this client will run the code on his computer.
5. Knowing this, we need to make an algorithm, so that the positions and dimensions of the image stay relatively the same regardless of the screen being used to show it.
Knowing these properties and definitions we can proceed with the problem. Let's assume that me as a developer, having a screen whose values are DEV_SCREEN_W = 1366, DEV_SCREE_H = 768 i want to set an image at position X = 352, Y = 243 with W = 900, H = 300. So At the developer screen, i'll have this:
Okay, now let's add one more image, with position and dimension X = 352, Y = 458, W = 193, H = 69
Okay, now we need to write an algorithm that keeps the same dimension and position on the screen regardless of size, as W and H are different for each resolution, we can't use pixel points to define, my solution was to define the position between 0 and 1, so the position would represent a certain percentage of the screen, the same for the W and H.
Let's suppose i get the screen information from the client and I get CLIENT_SCREEN_W = 1280, CLIENT_SCREEN_H = 720.
Since it's the same aspect ratio, I could apply this concept to both position and dimension as it would remain perfectly proportional to the screen, so i would have:
Getting the percentage based on the DEV screen for BOTH images would be like:
X = 352/DEV_SCREEN_W * CLIENT_SCREEN_W,
Y = 243/DEV_SCREEN_H * CLIENT_SCREEN_H,
W = 900/DEV_SCREEN_W * CLIENT_SCREEN_W,
H = 300/DEV_SCREEN_H * CLIENT_SCREEN_H,
Basically, for those who didn't understand what is happening, i get the data of how many % position in pixels represents from the developer's screen (X = 352/DEV_SCREEN_W) that is (X = 352/1366 = 0.2576) and multiply this result by the W of the client screen: 0.2576 * CLIENT_SCREEN_W, that is 0.2576 * 1280 = 329. Thus, we concluded that 329 and 352 are relatively the same position in different resolutions.
Following this concept, no matter what resolution the client uses, the images are always in the same proportion, both in position and in dimension, ONLY IF IT IS IN RATIO 16:9 (the same as the developer)
And this is where the problem arises, applying this same concept to any ratio, on a 4:3 screen the both image would be stretched:
despite keeping the same X and Y relative to the screen, the W and H had to be altered out of proportion to fit the screen, obtaining the result seen above, which cannot happen.
To avoid this, i set a proportion rate, which i get by dividing the client's screen by the dev's, thus getting how much of one represents the other, and i multiply that by W and H of both images so that both are proportionately resized to their original dimension, instead of multiplying by a relative value between 0 - 1 arbitrarily.
Getting the proportion would be like:
PROPORTION_RATE = CLIENT_SCREEN_W/DEV_SCREEN_W
Applying it:
W = 900*PROPORTION_RATE, H = 300*PROPORTION_RATE
Basically, this multiplication for aspect ratio, makes the image stay in the exact proportion of the screen resizing it, however, applying this, the images lose their relative position, as seen in the image below:
As you can see, despite keeping the same proportion in W and H, the image lost its structural organization in relation to the original position defined on the developer's screen.
I've been in this problem for a while
The closest I got was to add on the Y and X axis how much a certain image has decreased, however, if i do that both images will be corrected, but they would still be out of relative position between them, as shown in the image below:
[]
This problem of logic and algorithm is a little beyond my applicable knowledge, alone I can't find a solution, so I sincerely ask for help, or direction to the way where I can solve it.
Based on your comments, you want to scale both axes by the same amount, and you want to handle ratio mismatch by adding empty stripes at window edges as needed.
First you compute the scale: scale = min(w2/w1, h2/h1), where w1,h1 is the source size, and w2,h2 is the target size.
Next, assuming 0,0 is in the center of the screen, you can just do x2 = x1*scale, y2 = y1*scale, where x1,y1 are source coordinates and x2,y2 are converted coordinates.
But if 0,0 is in a corner of the screen for you (which is more probable), you have to do something like:
offset_x = (w2 - w1 * scale) / 2
offset_y = (h2 - h1 * scale) / 2
Then:
x2 = x1 * scale + offset_x
y2 = y1 * scale + offset_y
What is the GIMP API call to crop a layer to a selection, equivalent to Layer -> Crop to Selection in the GUI?
I looked in the Procedure Browser but the calls I found (gimp-crop and gimp-image-crop) perform the crop on the image, not a layer.
(What I really want to do is cut-and-paste multiple layers at once; I'm making a plug-in to help.)
You use pdb.gimp_layer_resize() using the data from pdb.gimp_selection_bounds(image).
x0,y0 = pdb.gimp_drawable_offsets(layer)
non_empty, x1, y1, x2, y2 = pdb.gimp_selection_bounds(image)
pdb.gimp_layer_resize(layer,x2-x1,y2-y1,x0-x1,y0-y1)
I want an user to draw something. I will rotate that image many times and I will save each file to a folder. A template is img<degree>.png, for example img24.png is the original image rotated by 24 degree. It's like using Rotate tool, set it to 24 degree and export it with default sittings.
The problem is that every time I rotate and export to png the files getting bigger and bigger. When the original file is 100x100 & 380B, the 9th file is 413x412 2,47KB. I want the images to stay at the same size (100x100 in the above example).
(define (degrees-to-radians degrees) (/ (* degrees *pi*) 180))
(define (script-fu-rotate-and-save in-image in-drawable directory-name) ; degree)
(let ((ind 0) (x 0) (y 0))
(while (< ind 361)
(set! x (car (gimp-image-width in-image)))
(set! y (car (gimp-image-height in-image)))
(gimp-item-transform-rotate in-drawable (degrees-to-radians ind) FALSE (/ x 2) (/ y 2))
(file-png-save-defaults 1 in-image in-drawable (string-append directory-name "/img" (number->string ind) ".png") (string-append directory-name "/temp.png"))
(set! ind (+ ind 45))
)
)
;(gimp-displays-flush) ; show changes on image
)
(script-fu-register
"script-fu-rotate-and-save" ;name
"rotate and save"
"Rotates and saves"
"me"
"copyrights"
"today"
""
SF-IMAGE "image-main" 0
SF-DRAWABLE "drawable-main" 0
SF-DIRNAME "directory-name" ""
;SF-ADJUSTMENT "label" '(value lower upper step_inc page_inc digits type)
;SF-ADJUSTMENT "degree" '(1 1 360 1 1 0 0)
)
(script-fu-menu-register "script-fu-rotate-and-save" "<Image>/Rotate and save")
If you rotate a rectangular image, you must either obtain a slightly larger image, or clip off some of that data. Often the area of interest is in fact roughly circular and the corners either background or transparent. However it's unlikely that a rotate algorithm will make that decision for you.
If you iteratively rotate, you not only get an accumulation of size, you also get an accumulation or error because pixels don't match (to see how to suppress this effect, look up rotatebyshear, in the binary image library (here). So the image will start to blur. So you need to always start from your original image, and apply the total rotation.
If you compare gimp-item-transform-rotate to its - now deprecated - predecessor, you will notice that it has an additional paramter called clip-result, with four possible values (the number in parens is the numeric value of the option):
TRANSFORM-RESIZE-ADJUST (0)
TRANSFORM-RESIZE-CLIP (1)
TRANSFORM-RESIZE-CROP (2)
TRANSFORM-RESIZE-CROP-WITH-ASPECT (3)
The current gimp-item-* API get the value from the current context, gimp-context-set-transform-resize is used to set the value you desire.
The default is TRANSFORM-RESIZE-ADJUST (0) - this enlarges the layer on every rotate, and if you rotate the same layer over and over again, the results become bigger and bigger.
You want to try TRANSFORM-RESIZE-CLIP (1) - this clips the rotated layer to the original size.
The remaining two options are a bit harder to understand - there you definitely want to have a look at the user manual. These options are common to the transform tools, btw.
The issue with error accumulation, as indicate in Malcolm's answer, remains. you definitely want to rotate a copy of the original layer by the accumulated angle, instead of rotating the same layer over and over again.
I have a player tile and I want to set the x and the y for the player as a variable, but I can't seem to get it to work.
I tried putting a few numbers behind the function drawq but it just stretched it.
Links to full code (The important one is newgame.lua, I just put the other 2 together with it):
Line 49 - 53
http://xedus.nl/test_builds/maploader.lua
Line 57 - 64
http://xedus.nl/test_builds/main.lua
Line 38 - 46 http://xedus.nl/test_builds/newgame.lua
PS: Sorry, I couldn't put the code in this post, but SO keep nagging me about using the CTRL+K, while I did.
In line 44 you have...
love.graphics.drawq(playertile, Quads[number2], x2, y2)
...(Quads). Shouldn't it be...
love.graphics.drawq(playertile, QuadsP[number2], x2, y2)
...(QuadsP) instead?
Just guessing.
It seems that a won't be visible unless a height and width is specified. Is this true?
This seems rather tedious. Couldn't the bounds of the line imply the correct width and height?
<Canvas Height="200" Width="200" HorizontalAlignment="Left" Background="Beige">
<!-- This is visible -->
<Line X1="20" Y1="40" X2="70" Y2="90"
Stroke="Black" StrokeThickness="4" Height="100" Width="100" />
<!-- This is not visible -->
<Line X1="10" Y1="10" X2="50" Y2="50"
Stroke="Black" StrokeThickness="4"/>
</Canvas>
(I'm using Silverlight 3.)
In SL 4, MS shows examples of mixing X1, X2, Y1, Y2 with Canvas.Left
In my own experience, with Visual Studio 2010, in order to see the line in the designer view, I had to set non zero width and height, while also using X,Y to set the line within that space.
No, you can use one of this templates to define coordinates:
X1, X2, Y1, Y2
Canvas.Left, Canvas.Top, Width, Height.
If you use them together, CLR may sometimes show your controls wrong.
It seems that the line is drawn at a point (X1, Y1) relative to the Canvas.Left, Canvas.Top of the Line element. So not specifying the Canvas.Left, Canvas.Top means that the line is actually drawn at the point (X1, Y1).
It's like the control dimensions (or the drawing surface of the line) is determined by the Canvas.Left, Canvas.Top, Width, Height and the actual line is render by (X1, Y1) and (X2, Y2) relative to Canvas.Left, Canvas.Top.
The RotateTransform uses the Canvas.Left, Canvas.Top values (unless another Center is specified) and not the X1 etc values. So any transforms on the line may not work as expected if those values differ.
I have silverlight 4, and I resolved the problem specifing the canvas width, canvas height, x1, x2, y1, y2.