This cool.
But I don't understand the purpose of the first line in update_positions().
self.vels *= 0.8 ** self.dt
What is 0.8, and why is it raised to the power of time elapsed?
Welcome!
This is the community forum for my apps Pythonista and Editorial.
For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.
This cool.
But I don't understand the purpose of the first line in update_positions().
self.vels *= 0.8 ** self.dt
What is 0.8, and why is it raised to the power of time elapsed?
Hi all,
In the previous beta, I was able to set the SpriteNode.texture using the image identifier returned from load_pil_image(). E.g. when initializing the SpriteNode:
my_img = Image.open('my_image_file.png')
my_sprite = SpriteNode(texture=load_pil_image(my_img), position=(0,0))
And when I set SpriteNode.texture directly, I found I needed to use a Texture object but using load_pil_image() stilll worked, e.g.:
my_sprite.texture = Texture(load_pil_image(my_img))
However, now (with the new beta) I find that neither of the above works. If I attempt either of the above Pythonista just closes. It seems that I need to first convert my image to a ui.Image before setting the SpriteNode.texture.
The documentation for scene.Texture does state that "Textures can be initialized using either the name of a built-in image (a string), or a ui.Image object." No mention here of supporting PIL images. However, as I said I could do this previously... and so I'm wondering if truly the SpriteNode.texture is only meant to be used with ui.Image (or built-in images), and if all PIL images will then need to be converted to ui.Image in order to be used with a SpriteNode.
Or if I'm doing something wrong.
Yeah thanks omz for getting that up there so fast. And in the nick of time, whew. Was not looking forward to the prospect of a day without Pythonista!
It's there now.
Woke up to find the 037 beta waiting in TestFlight!
Oops, looks like I missed the conversation on this from a couple of days ago. Sounds like another beta is in the works. (Opening up TestFlight must have had nothing to do with it, just a coincidence...)
And I can't open the app.
It happened right after I went into TestFlight to check the expiration of the Beta.
I was about to post this same question. It seems like all touches have to be handled at the Scene level in 1.6.
@ccc That is helpful information, thanks.
OK, I didn't even know that ui.ScrollView existed. That is going to come in handy!
m
I have a question about the right way to go about something, in general terms...
I have a large image (I can scale it to the width of the screen, but it will still be about twice the height of the screen). I would like to show just a part of the image that will fit on the screen, and then be able to scroll through the image to view different parts of it (using buttons or whatever).
But I am unsure of the best way to handle the displaying of the larger-than-screen-size image. I have it working now by creating a layer that is the width of the screen but twice the height of the screen, and then setting this Layer's image property to my image:
im = Image.open("bgnd.png").convert('RGBA')
w = int(self.bounds.w) # width of screen
h = int(im.size[1] * self.bounds.w / im.size[0]) # scale height keep aspect ratio
im = im.resize((w,h)) # scale image to fit screen width; image height > screen height
self.im_layer=Layer(Rect(0,0,w,h)) # this layer is larger than screen!
self.root_layer.add_layer(self.im_layer)
self.im_layer.image = load_pil_image(im)
This seems to work, but it feels wrong...
Is setting a Layer to be larger than the screen size OK to do? What does Pythonista do with the portion of the image that is off screen? Could this be problematic if the image were larger, say 10x the height of the screen? How should this issue -- scrolling through a image larger than the screen -- be handled in applications and on the pythonista platform in particular?
Using objc_util, which I really don't understand well at all, and working off examples I've found here and there on this forum, I feel like I almost have it.... just trying to put an animated GIF onto the clipboard so it can be pasted into another app.
Method 1 below (commented out) works, but when the image is pasted it is unfortunately a .PNG.
Method 2 allows you to specify image type. However, this does not seem to work at all. Clipboard is empty.
# coding: utf-8
from objc_util import *
UIPasteboard=ObjCClass('UIPasteboard')
pb=UIPasteboard.generalPasteboard()
#method 1: works but creates a .png:
#imgdata = UIImage.imageWithContentsOfFile_('test.gif')
#pb.setImage_(imgdata)
# method 2: does not work. pasteboard is empty
imgdata = NSData.dataWithContentsOfFile_('test.gif')
pb.setData_forPasteboardType_(imgdata, ns('kUTTypeGIF'))
I really don't know then.
Have you checked that the built-in images work, like
image('Sun_1', 0, 0)
Yeah that is all I changed.
Could it be an issue with the image itself?
What if, just for debug, you do a mapimage.show() to put it on the console, right after you get it from photos.pick_image. To see what it looks like there.
This code didn't work at all for me until I added a call to Scene's init() function, e.g. using super():
def __init__(self, mapimage):
mapimage2 = mapimage.convert('RGBA')
self.mapimage = load_pil_image(mapimage2)
super(MyScene,self).__init__()
Now I see the image I picked in the lower left of the screen.
OK, I can work with that. Yes, the performance benefit is worth it. Thanks!
-m
Hi All,
In Pythonista 1.5, I was able to subclass from scene.Rect. In the Beta, I can no longer do this. I get the following error:
TypeError: Error when calling the metaclass bases. type 'Rect' is not an acceptable base type.
A quick Internet search on this error did not yield anything intelligible to me. I bet there is a good reason I'm getting this error now, but I'm not clear on what it is.
@JonB Yes, this looks like an awesome solution. I see it uses the objc_util so I think that means I would need the beta, or else wait for the next release. But I think something like this is the long-term solution. Appreciate it!
@Webmaster4o Thanks for the tips. I can do your first one, but getting back to the editor involves closing the app -- so not quite ideal. Your second idea is interestings... I will look into that.
@Gerzer I do not have Workflow. Number of Frames can be anywhere between 4 and 12 or so.