In the close event I persist the window position as follows:
localStorage.lastlayout = JSON.stringify({
"left": win.x,
"top": win.y,
"width": win.width,
"height": win.height
});
On start, I restore it with:
data = JSON.parse(localStorage.lastlayout);
win.moveTo(data.left, data.top);
win.resizeTo(data.width, data.height);
The problem is the position is off. As far as I can tell, I get the inner position. When setting I set the outer position. The windowing title and borders only accounted for when setting.
As this is cross-platform code I cannot test it on all platforms (yet) and I don't know if it is possible to get the metrics of the windowing engine so that I can correct it programmatically (think about the user changing the DPI or theme on Windows).
Is there a way to compensate for this?
Ok, I've nailed it. I detect the offsets in respect to a known position (0, 0) and then detract it from the desired position. It's not perfect but it works:
win.resizeTo(128, 128);
win.moveTo(0, 0);
log("dbg", "win", "detected metrics: " + win.x + ", " + win.y);
win.moveTo(data.left - win.x, data.top - win.y);
win.resizeTo(data.width, data.height);
The initial resize is necessary for some reason. It looks like the title and borders are not drawn at all on some platforms if the window is not large enough. Next I move it to the origin. The win.x and win.y contain the offsets at this point. The second moveTo() uses the corrected coordinates and finally I resize the window to the actually desired size.
Related
I created a new path2d following the instructions in the my first game article: http://docs.godotengine.org/en/3.0/getting_started/step_by_step/your_first_game.html
I wanted to move the "box" on screen so that I could see how the mobs spawn in, but when I ran the scene, it stayed off screen.
I created a new path2d, centered this one in the middle of the screen, and it works like I wanted it to, but now I moving this one in the editor doesn't update the position in game.
What's going on?
Thanks
func _on_mobtimer_timeout():
$mobtimer.wait_time = 0.1 + randf() / 2
$mobspawn/moblocation.set_offset(randi())
var mob = Mob.instance()
add_child(mob)
var direction = $mobspawn/moblocation.rotation + PI/2
mob.position = $mobspawn/moblocation.position
direction += rand_range(-PI/8, PI/8)
mob.rotation = direction
mob.set_linear_velocity(Vector2(rand_range(200, 200 + score * 30), 0).rotated(direction))
A Node2D's position property is relative to it's parent's position. The code from the Dodge The Creeps tutorial assumes that MobPath is located at 0, 0 and fails when that assumption is false.
In your case you are taking a MobSpawnLocation's position relative to MobPath and then setting it as the new Mob's global position.
Luckily Node2D's have another property that we can use in these circumstances global_position. It can be used like this:
mob.position = $mobspawn/moblocation.global_position
http://docs.godotengine.org/en/stable/classes/class_node2d.html#member-variables
This isn't a full solution, but I found a weird workaround. Instead of changing the position in the editor, if you use the nodes on the orange box (at the intersection of orange and blue), you can kind of alternate to move the box around.
I can't seem to get a QGraphicsEllipseItem to show up in my view. I am attempting to use it in combination with a QGraphicsLineItem:
# Instantiate the line object:
self.profileLine = QGraphicsLineItem()
self.profileLine.setPen(QPen(Qt.yellow, 1.0))
self.profileLine.setLine(self.StartX, self.StartY, self.StopX, self.StopY)
self.scene.addItem(self.profileLine)
# Instantiate the circle:
self.profileStopHandle = QGraphicsEllipseItem()
self.profileStopHandle.setPen(QPen(Qt.yellow, 1.0))
self.profileStopHandle.setRect(self.StopX, self.StopY, 50, 50)
self.scene.addItem(self.profileStopHandle)
Later, in my mouse move event, I determine the current mouse coordinates, assign them to StopX/StopY and redraw the line from the start point to the new stop point as well as draw the ellipse around the new stop point:
self.profileLine.setLine(self.StartX, self.StartY, self.StopX, self.StopY)
self.profileStopHandle.setPos(self.StopX, self.StopY)
The line shows up fine and behaves just as it should, but no matter what I cannot seem to get the ellipse to draw. I know the point coordinates I'm passing to it are correct because they are the same ones I'm using for the line. The ellipse just never appears as if it was never created in the first place. What am I doing wrong here (it must be something very basic)? Thank you in advance.
The issue was the Z-value (amateur mistake). I brought the ellipse to the foreground and now it is visible:
self.profileStopHandle.setZValue(self.sceneImage.zValue() + 1.0)
I am trying to used the seamsless cloning to blend to image together.
but I notice that after using the seamsless clone function the area in the
mask that I want to transfer is shift upward. So I have a question that
is this a normal behaviour of the seamsless clone function or it is a bug
on my implementation.
Here are the Source photo
Here are the destination photo
Here are the result photo
I encountered similar situation. Moreover, like #JoshuaCWebDeveloper noted, this shift disappeared when all one mask is used. Nevertheless, I got a fix for this. What I did is this. I cropped valid mask (non-zero sub-section) out using cv2.boundingRect. So my source image and mask image are reduced to a smaller size, while center is now calculated from boundingRect outputs (Since reference point is marked on destination image). This way, error got solved/shift got ridden.
(Based on the answer posted by Fractalic Forieu) You can achieve the same result without reducing the image size.
Instead of using the image center:
center = (width // 2, height // 2)
poissonImage = cv2.seamlessClone(srcImage, dstImage, maskImage, center)
use the center of the bounding rect:
monoMaskImage = cv2.split(maskImage)[0] # reducing the mask to a monochrome
br = cv2.boundingRect(monoMaskImage) # bounding rect (x,y,width,height)
centerOfBR = (br[0] + br[2] // 2, br[1] + br[3] // 2)
poissonImage = cv2.seamlessClone(srcImage, dstImage, maskImage, centerOfBR )
I've 3 (loader, locker and debug view) hidden views (touchEnabled and visible set to false, and zIndex to 1) above the main view (zIndex = 2).
Each 'over' view has this method:
$.debugView.show = function() {
$.debugView.touchEnabled = $.debugView.visible = true;
$.debugView.zIndex = 3;
};
$.debugView.hide = function() {
$.debugView.touchEnabled = $.debugView.visible = false;
$.debugView.zIndex = 1;
};
This screen has the 3 'over' views hidden:
Now, I'm opening the 'debug view', but, SOMETIMES it seems like it changes the positions (as if the center it's on the top left corner instead of the center of the device).
Instead of the required result:
If I use the opacity instead of the visible property, it works properly.
This might be an SDK bug right?
<Alloy>
<Window>
<View id="content"/>
<View id="locker"/>
<View id="loader"/>
<View id="debugView"/>
</Window>
</Alloy>
All of these 4 views don't have width or height (so it uses the Ti.UI.FILL as default)
I have noticed this too with a completely different implementation. I had just one view that I included in a window.
Apparently the left and top calculations were not done properly if the elements is hidden.
What I did to solve the issue is to hardcode the left/top position by calculating the left position using this:
$.content.left = (Ti.Platform.displayCaps.platformWidth - 75) / 2;
Where in my case 75 is the width the element has, so that'll be bigger in your case. You can do the same for height.
Now, this is an iOS only solution. On Android you will need to take DPI into consideration calculating it.
I do think it is a bug, though this solution works perfectly for me. I recommend looking at JIRA and see if it is a known issue, and if not, raise it with a very specific explanation of the problem, preferably with a reproducible case delivered as an app. Classic would help most. And if it is not reproducible in classic it might be an alloy issue.
It seems like given the information in stroke_extents() and the translate(x, y) and scale(x, y) functions, I should be able to take any arbitrary cairo (I'm using pycairo) path and "best fit" it. In other words, center it and expand it to fill the available space.
Before drawing the path, I have scaled the canvas such that the origin is the lower left corner, up is y+, right is x+, and the height and width are both 1. Given these conditions, this code seems to correctly scale the path:
# cr is the canvas
extents = cr.stroke_extents()
x_size = abs(extents[0]) + abs(extents[2])
y_size = abs(extents[1]) + abs(extents[3])
cr.scale(1.0 / x_size, 1.0 / y_size)
I cannot for the life of me figure out the translating though. Is there a simpler approach? How can I "best fit" a cairo path on its canvas?
Please ask for clarification if anything is unclear in this question.
I have found a solution that I like (at least for my purposes). Just create a new surface and paint the old surface on to the new one.
As for the scale only, I have done a similar thing to adjust an image inside a box with a "best-fit" approach. As about scale, here is the code:
available_width = 800
available_height = 600
path_width = 500
figure_height = 700
# formulas
width_ratio = float(available_width)/path_width
height_ratio = float(available_height)/figure_height
scale = min(height_ratio, width_ratio)
# result
new_path_width = path_width*scale
new_figure_height = figure_height*scale
print new_path_width, new_figure_height
The image gets drawn aligned to the origin (top left in my case), so perhaps a similar thing should be done to translate the path.
Also, this best fit is intended to preserve aspect ratio. If you want to stretch the figure, use each of the ratios instead of the 'scale' variable.
Hope I have helped