I'm having a little curious sense of art in programming at the moment. And I want to script my Autotouch App on my iOS to generate Pixel Art inside of another app.
I was doing this previously by typing in code to tap at the screen at one coordinate, I did this 2000+ times and it got the job done. But there should be a better, smarter way to get it done.
My test image is going to be very symetrical to make things easy.
There is a code in the Lua app that I'm using to simply tap on the screen,
tap(x, y)
But I want to set this up like:
tap({xTable}, y)
But I'm not sure if that will "tap" at each x coordinate that I've listed for the y variable.
I want to paint a pixel at one very specific coordinate, and then step 5 pixels away and paint the next one, and repeat that until the end of the line.
Is this at all possible or am I reaching beyond the language capabilities?
Edit: for some reason my phone is not blocking code when I'm asking a question, if someone sees this and wants to edit, I would be grateful.
Is this at all possible or am I reaching beyond the language capabilities?
Not even close. I recommend you read Programming in Lua.
tap({xTable}, y)
But I'm not sure if that will "tap" at each x coordinate that I've listed for the y variable.
Why are you not sure? Did you not write it? If not, you can trivially write it yourself given tap:
function tapxs(xs, y)
for i,x in ipairs(xs) do
tap(x,y)
end
end
...
tapxs({10,20,30,40}, 10) -- tap at 10,10; 20,10; 30,10; etc.
I want to paint a pixel at one very specific coordinate, and then step 5 pixels away and paint the next one, and repeat that until the end of the line.
What is "the line"? Is it purely horizontal? You could write:
function tapHorizontally(startX, maxX, y, increment)
for x=startX,maxX,increment do
tap(x,y)
end
end
...
tapHorizontally(10,100,20,5) -- tap from 10,20 to 100,20 in 5 pixel increments
Of course, that's a bizarrely specific function. You'd typically write something that takes a starting x,y and ending x,y and draws between them, so you can support horizontal, vertical, diagonal lines all with the same function, but that requires more math.
The bottom line is: Lua is a full blown, powerful, high level programming language. It could be used to write the very app you're tapping on, or the app you're using to generate taps, so the limits are going to be your knowledge of programming/algorithms/math/etc.
Related
I am using rdesktop with seamlessrdp. This way I can open Windows apps on my Linux machines. Also I added devilspie2 to the mix so I could control the window decorations. devilspie2 uses lua as its config management. I made everything work. The only issue left is to move the opening (dialog) windows a couple of pixels because the VNC windows will appear as if they had decorations (but without them). I got the code working by hard coding the amount of pixels needed to move. The issue is we have more than one distros here and they have different pixel sizes for their window decorations.
What I want is to GET the decoration size in pixels instead of hard coding them so it will work perfectly for all my distros.
Here is the piece of code that does it atm:
if get_window_class()=="SeamlessRDP" then
undecorate_window();
--x-1 and y-28 works for one distro but for the other I need to use x-6 and y-27
if get_window_type()=="WINDOW_TYPE_DIALOG" then
x, y = xy();
xy(x-1, y-28);
end
end
As you can see from the script. It would be much better if I could somehow call the size of the window decorations and then use them rather than hard coded pixels.
EDIT (ANSWER):
Even though I found the answer before the following post, I wanted to accept it anyways because it did show the right path to follow. I am only further commenting here to show the full answer:
--get x and y's for decorated and non-decorated windows
x1, y1, width1, height1 = get_window_geometry();
x2, y2, width2, height2 = get_window_client_geometry();
--calculate pixels to slide window
xpixel = x2-x1;
ypixel = y2-y1;
--check if class is seamlessrdp
if get_window_class()=="SeamlessRDP" then
undecorate_window();
--if window is a dialog then move it
if get_window_type()=="WINDOW_TYPE_DIALOG" then
xy(x1-xpixel, y1-ypixel);
end
end
devilspie2 provides only two ways to get the window size, get_window_geometry and get_window_client_geometry.
Whereby the last one excludes the window borders. If this does not work for you, you can create a file with a table for all values to make them easily editable. You could also use the window class names as table keys if possible to make the use easier.
I am trying to make a new tool for the tabletop simulator community based on my "pack up bag". The Packup Bag is a tool that remembers world position and rotation of objects you place inside it, so you can then place them back in the same positions and rotations they came from when "unpacking the bag".
I have been trying to modify this so it spits things out in a relative position and rotation to the bag, instead of using hardcoded world coordinates. The idea here is that players can sit at any location at the table, pick the faction bag they wish to play.. drop it on a known spot marked for them and press the place and it will populate contents of the bag relative to its location.
Now I have gotten some of this worked out... I am able to get the bag to place relative in some ways .. but I am finding it beyond my maths skills to work out the modifications of the transforms.
Basically I have this part working..
The mod understands relative position to the bag
The mod understands relative rotation to the bag
BUT.. the mod dose not understand relative position AND rotation at the same time.... I need someway to modify the position data relative to the rotational data... but can not work out how.
See this video....
https://screencast-o-matic.com/watch/cFiOeYFsyi
As you can see as I move the bag around the object is placed relative to it.... but if I rotate the bag, the object has the correct rotation but I need math to work out the correct position IF it is rotated. You can see it is just getting placed in the same position it was as if there was no rotation... as I haven't worked out how to code it to do this.
Now I have heard of something called "matrix math" but I couldn't understand it. I'm a self taught programmer of only a few months after I started modding TTS.
You can kinda understand what I mean I hope.. In the video example, when I rotate the bag, the object should be placed with the correct rotation but the world position needs to be changed.
See this Example to see relative rotation ....
https://screencast-o-matic.com/watch/cFiOeZFsyq
My code dose this by remembering the self.getPostion() of the bag and the obj.Position() of the object getting packed up.. it then dose a self - obj and stores that value for the X and Y position. It also remembers if it is negative or position and then when placing it uses the self.postion() and adds or subtracts the adjustment value. Same for rotation.
Still I do not know what ot go from here.. I have been kinda hurting my head on this and thought maybe some of you math guys might have a better idea on how to do this.
: TL;DR :
So I have
bag.getPosition() and obj.getRotation()
bag.getRotation(0 and obj.getRotation()
These return (x,y,z}
What math can I use to find the relative position and rotation of the objects to the bag so if I rotate the bag. The objects come out of it in a relative way...
Preferably in LUA.. thank you!
I'd hope you've found the answer by now, but for anyone else finding this page:
The problem is much simpler than what you're suggesting - it's basic right triangle trigonometry.
Refer to this diagram. You have a right triangle with points A, B, and C, where C is the right angle. (For brevity, I'll use abbreviations opp, adj, and hyp.) The bag is at point A, you want the object at point B. You have the angle and distance (angle A and the length of the hyp, respectively), but you need the x,y coordinates of point B relative to point A.
The x coord is the length of adj, and y coord is the length of opp. As shown, the formulas to calculate these are:
cos(angle A) = adj/hyp
sin(angle A) = opp/hyp
solving for the unknowns:
adj = hyp * cos(angle A)
opp = hyp * sin(angle A)
For your specific use, and taking into account the shift in coordinate system x,y,z => x,z,y:
obj_x_offset = distance * math.cos(bag.getRotation().y)
obj_z_offset = distance * math.sin(bag.getRotation().y)
obj_x_position = bag.getPosition().x + obj_x_offset
obj_z_position = bag.getPosition().z + obj_z_offset
Diagram source:
https://www.khanacademy.org/math/geometry/hs-geo-trig/hs-geo-modeling-with-right-triangles/a/right-triangle-trigonometry-review
I have some experience with Metal and quite a bit with Unity and am familiar with setting up meshes, buffers, and the backing data for drawing; but not so much the math/shader side. What I'm struggling with is how to get an endless scrolling world. So if I pan far to the right side I can see the left side and keep going.
The application of this would be a seamless terrain that a player could scroll in any direction forever and have it just wrap.
I don't want to duplicate everything on draw and offset it, that seems horrendously inefficient. I am hoping for a way to either use some magic matrix math or some sort of shader to get things wrapping/drawing where they should when panning the map. I've searched all over for some sort of guide or explanation of how to get this working but haven't come up with anything.
I know a lot of old (dos) games did this somehow, is it still possible? Is there a reason why it seems the industry has migrated away from this type of scrolling (bounding to edges vs wrapping)?
I have created a simple example demonstrating what you're looking for (I think).
The basic idea of it is that you draw the map in a repeating grid, using the drawPrimitives(type:vertexStart:vertexCount:instanceCount:) method on MTLRenderCommandEncoder. As the instance count you want to pass in the number of identical maps you want to draw, extending it as far as needed to not see where it ends. In my example I used a simple 5x5 grid.
To not have the user see the edge of the map, we're gonna calculate their position modulo 1 (or whatever size your map is):
func didDrag(dx: CGFloat, dy: CGFloat) {
// Move user position on drag, adding 1 to not get below 0
x += Float(dx) * draggingSpeed + 1
z += Float(dy) * draggingSpeed + 1
x.formTruncatingRemainder(dividingBy: 1)
z.formTruncatingRemainder(dividingBy: 1)
}
This is how it looks:
Just a follow up on what I have actually implemented. First I essentially have an array of x,y points with altitude, terrain type and all that jazz. Using some simple % and additions/subtractions it is trivial to get the nodes around a point to generate triangles
On a draw I calculate the first showing point and the last showing point and calculate the groups of triangles shown between those points. The first/last point take into account wrapping, it is then pretty trivial to have an endless wrapping world. For each group a translation offset is passed via a uniform matrix for that group which will position that section where it should belong.
I set it via renderEncoder.setVertexBytes(&uniform, length:..., offset:...)
I am trying to capture the pixel color of a specific letter in a font within an iOS app. I'd then use that color in an if/then statement to determine the next action of my script. I'm finding no easy way to determine if the color/colors I'm finding are the right ones. Here's my current process: I start recording my inputs and continuously click around the letter. I end up with something like touchdown(123,456). I change that to alert(getColor(123,456)) and run, which produces a popup that tells me the color such as 3094841 (not sure why the colors are in numeric format, but they are). I do this for each touchdown line that is captured. The problem is, I don't know an easy way to determine which color is the small letter I'm trying to tap.
Is there a lua function that will capture and display a range of colors between 2 points? If there were, I could see the commonality of all of the colors within the 2 points and make at least an educated guess as to which is the color in the font. Or even more useful - is there a tool I can use to type in the color I'm getting back and have it display the corresponding color, so I can compare them. That'd be the easiest. Hope this makes sense. Any help would be awesome. In case it matters, I'm using Autotouch 8 on an iPhone 5.
TIA
I use this function often in my games.
I find the easiest way to get a color you want to execute every single time is to take a snap of the screen you're checking and then use the helper on getColor(x, y)
And you can use this to alert your color.
local color = getColor(x, y)
alert(color)
-- You can also use:
log(color)--this one keeps it in your log in case you can write it down immediately.
To use this in an if/then statement
function = namedfunction()
local color = getColor(x, y)
if color == YOURCOLOR then
else
end
end
namedfunction();
Note that I have the iPhone 5 iOS 8.3 and I have the most recent AutoTouch from Cydia. If you don't have the helper when you're scripting it might be worth it to check if Cydia offers a capatable version.
Edit: I am running version 3.5.3-8 of Autotouch.
The problem is simple: I want to move (and later, be able to rotate) an image. For example, every time i press the right arrow on my keyboard, i want the image to move 0.12 pixels to the right, and every time i press the left arrow key, i want the image to move 0.12 pixels to the left.
Now, I have multiple solutions for this:
1) simply add the incremental value, i.e.:
image.x += 0.12;
this is of course assuming that we're going to the right.
2) i multiplicate the value of a single increment by the times i already went into this particular direction + 1, like this:
var result:Number = 0.12 * (numberOfTimesWentRight+1);
image.x = result;
Both of these approaches work but produce similiar, yet subtly different, results. If we add some kind of button component that simply resets the x and y coordinates of the image, you will see that with the first approach the numbers don't add up correctly.
it goes from .12, .24, .359999, .475 etc.
But with the second approach it works well. (It's pretty obvious as to why though, it seems like += operations with Numbers are not really precise).
Why not use the second approach then? Well, i want to rotate the image as well. This will work for the first attempt, but after that the image will jump around. Why? In the second approach we never took the original position of the image in account. So if the origin-point shifts a bit down or up because you rotated your image, and THEN you try to move the image again: it will move to the same position as if you hadn't rotated before.
Alright, to make this short:
How can i reliably move, scale and rotate images for 1/10 of a pixel?
Short answer: I don't know! You're fighting with floating point math!
Luckily, I have a workaround, if you don't mind.
You store the location (x and y) of the image in a separate variable... at a larger scale. Such as 100x. So 123.45 becomes 12345, and you then divide by 100 to set the attribute that flash uses to display.
Yes, there are limits to number sizes too, but if you're willing to accept some error rate, and the fact that you'll be limited to, I dunno, a million pixels in each direction, you can fit it in a regular int. The only rounding error you will encounter will be a single rounding error when you divide by 100 (or the factor you used). So instead of the compound rounding error which you described (0.12 * 4 = 0.475), you should see things like 0.47999999. Which doesn't matter because it's, well, so small.
To expand on #Pimgd answer a bit, you're probably hitting a floating point error (multiple +='s will exaggerate the error more than one *='s) - Numbers in Flash are 53-bit precision.
There's also another thing to keep in mind, which is probably playing a bigger role with such small movement values; Flash positions all objects using twips, which is roughly about 1/20th of a pixel, or 0.05, so all values are rounded to this. When you say image.x += 0.12, it's actually the equivalent of image.x += 0.10, hence which the different becomes apparent; you're losing 0.02 of a pixel with every move.
You should be able to get around it by moving to another scale, as #Pimgd says, or just storing your position separately - i.e. work from a property _x rather than image.x so you're not losing that precision everytime:
this._x += 0.12;
image.x = this._x;