Skew images (WIP)

[Wither362]

Yes dude! I finally got the algorithm to skew images!

TODO:

• [ ] Functions:
  • [x] movePixel(x, y, toX, toY)
  • [ ] movePixelByID(id, toX, toY) (may cause lag…)
• [ ] has functions:
  • [ ] hasPixelInRotation(x, y, angle) - Just a function I thought it would be great if the image is rotated, just for non-interfering the coordinates
  • [ ] hasFloatingPixelInRotation(x, y, angle)
  • [ ] hasPixelInRotationAndInView(x, y, angle) (optional) - a mixup
  • [ ] hasFloatingPixelInRotationAndInView
  • [ ] hasFloatingRotatedPixelInView
  • [ ] hasPixelInRotatedView
  • [ ] hasFloatingRotatedPixelInRotatedView
• [ ] Others:
  • [ ] skewInPoint(x, y, angle) - rotates the image from a point
  • [ ] skewFloatInPoint(x, y, angle)
  • [ ] skewView(x, y, angle) - rotates the view of the image (THIS NOT ROTATES THE IMAGE)
  • [ ] skewFloatView
  • [x] skewFloat(angle) - Rotates the image, but with perfect pixels coordinates
  • [x] skew(angle) - Rotates the image from the bottom left corner
  • [x] stampSkewed() (?) - Stamps an image but rotated
• [x] forEach
  • [x] forEachRotatedPixel
  • [x] forEachRotatedFloatingPixel
  • [x] forEachRotatedPixelInView
  • [x] forEachRotatedFloatingPixelInView
• [ ] Variables:
  • [ ] rotatedValue (?) - How much is the image rotated (might be changed)
  • [ ] rotationWidth - Width of the image but when it’s rotated
  • [ ] rotationHeight - Height of the image but when it’s rotated
• [x] Don’t rotate already rotated points in the same function (might not be necessary)
• [x] Check the Code Works

[ShaharMS]

Nice! I'll take a look at that later, rn I'm trying to make CI send you a url of the images generated from your PRs. Then, you could add a test, and it would display there.

[Wither362]

Nice! I'll take a look at that later, rn I'm trying to make CI send you a url of the images generated from your PRs. Then, you could add a test, and it would display there.

Thanks!

[Wither362]

How do I move a pixel from coordinates (x, y) to coordinates (x2, y2)?

I need it to finish this…

I found two solutions:

• Move pixel (I can’t find out how to do it)
• "Remove" pixel (x, y) and paint a new pixel with the same color at (x2, y2) (I can’t find out the functions I need to use)

[ShaharMS]

movePixel might already exist as copyPixel, but I'm not sure. A quick solution rn is to do setPixel(newX, newY, getPixel(oldX, oldY))

[Wither362]

movePixel might already exist as copyPixel, but I'm not sure. A quick solution rn is to do setPixel(newX, newY, getPixel(oldX, oldY))

Isn't setPixel(x, y, color) to change the color of the specified pixel?

I want to move the pixel, but it might work also…

[ShaharMS]

movePixel might already exist as copyPixel, but I'm not sure. A quick solution rn is to do setPixel(newX, newY, getPixel(oldX, oldY))

Isn't setPixel(x, y, color) to change the color of the specified pixel?

I want to move the pixel, but it might work also…

by moving do you mean switching between the pixels? setPixel(..., getPIxel(...)) simply "duplicates" the pixel at the old position to the new one. did you mean something else?

[ShaharMS]

or maybe you mean moving the pixel at the old position to the new position, and resetting it's color to the default (0x00000000)

[Wither362]

or maybe you mean moving the pixel at the old position to the new position, and resetting it's color to the default (0x00000000)

Yeah! That’s what I mean!

[ShaharMS]

ok! ill implement this as movePixel() and add an extra argument for the reset color:

movePixel(fromX, fromY, toX, toY, ?oldPixelColor)

[ShaharMS]

oh, that probably means implementing moveSafePixel and moveFloatingPixel

[Wither362]

ok! ill implement this as movePixel() and add an extra argument for the reset color:

movePixel(fromX, fromY, toX, toY, ?oldPixelColor)

That sounds good! Maybe I can help you with the function code, but I’m not sure…

[Wither362]

oh, that probably means implementing moveSafePixel and moveFloatingPixel

Yeah… 😅

[ShaharMS]

those shouldn't be hard to implement, just the same function but doesnt throw/gets different type params.

im also gonna implement moveUnsafePixel for that extra speeeed🚀

[ShaharMS]

implemented! merge the main branch to get these functions.

[ShaharMS]

there are 4 new functions:

• movePixel() - behavior discussed above
• moveSafePixel() - safe as above, but handles positions outside the bounds of the image
• moveFloatingPixel() - allows using floats for pixel positions, blends colors if necessary.
• moveUnsafePixel() - same as movePixel() but without error handling, always faster than movePixel() but errors may be vague

[Wither362]

there are 4 new functions:

• movePixel() - behavior discussed above
• moveSafePixel() - safe as above, but handles positions outside the bounds of the image
• moveFloatingPixel() - allows using floats for pixel positions, blends colors if necessary.
• moveUnsafePixel() - same as movePixel() but without error handling, always faster than movePixel() but errors may be vague

Thanks! I think I will use moveSafePixel() for better use

[Wither362]

there are 4 new functions:

• movePixel() - behavior discussed above
• moveSafePixel() - safe as above, but handles positions outside the bounds of the image
• moveFloatingPixel() - allows using floats for pixel positions, blends colors if necessary.
• moveUnsafePixel() - same as movePixel() but without error handling, always faster than movePixel() but errors may be vague

It would help me if you could add moveFloatingSafePixel(), but I don’t really care about doing the skewFloat() function anyway…

[ShaharMS]

I think CI is failing because of the added rotate car in the image class, variables shouldn't be added like that since they have to be based somewhere in the abstract (for example, width is stored in the first couple of bytes)

[ShaharMS]

Another thing, if it isn't slow, I think floating pixel checks should be safe by default, since you need to be super careful otherwise

[ShaharMS]

A stack overflow error is also interesting 🤔

And the error message seems lacking. I should revisit this sometime.

[ShaharMS]

Also, I think you're implementation of rotation only works if rotate is a storable value, which isn't the case here since image is an abstract. I wonder how much turning image into a regular class will effect performance...

[Wither362]

Ahh… so… what should I do?

[Wither362]

I’m kinda new in using abstracts…

[ShaharMS]

I’m kinda new in using abstracts…

Sorry for late reply, abstracts are pretty well explained (I think) here: https://haxe.org/manual/types-abstract.html

[Wither362]

I’m kinda new in using abstracts…

Sorry for late reply, abstracts are pretty well explained (I think) here: https://haxe.org/manual/types-abstract.html

Ok, thanks, so, I can’t use variables like I use them in classes…

About creating a new test

I think I’ll use addToScreen(), and I’ll copy one of the tests, so I’m not sure if it will work… but I’ll try

[ShaharMS]

Looking at this again, I don't think most of the functions mentioned in the first message are really needed. Another thing, this would be wayyy easier to implement if you don't try to create any custom properties on the image class. Simply an image skewing algorithm that rotates an image providing an image and angle is pretty much 90% of the work done, since it lays the foundation for other functions to be implemented

[Wither362]

Looking at this again, I don't think most of the functions mentioned in the first message are really needed. Another thing, this would be wayyy easier to implement if you don't try to create any custom properties on the image class. Simply an image skewing algorithm that rotates an image providing an image and angle is pretty much 90% of the work done, since it lays the foundation for other functions to be implemented

Ah, ok then

[Wither362]

Yey! It works!

[Wither362]

It works!

At least the functions

[Wither362]

@ShaharMS, can you also implement a moveFloatingSafePixel? It’s better when the rotation it’s almost exact, and not rounded like in Std.int()

[ShaharMS]

I'm pretty sure floating operations are safe by default on latest main

[Wither362]

I'm pretty sure floating operations are safe by default on latest main

I saw the functions, and nope, they aren’t safe

[ShaharMS]

Did you merge latest main? I just looked at the code and floating operations check for safety

[Wither362]

Oh! Now I see the changes, thanks!

[Wither362]

Where’s pixel (0, 1)?

[ShaharMS]

woah, just merged main into your pr, and looks like java doesnt like some of the functions here... you can ignore that for now, its probably because of the inline abuse in that class😂

[Wither362]

woah, just merged main into your pr, and looks like java doesnt like some of the functions here... you can ignore that for now, its probably because of the inline abuse in that class😂

:'( not happy wither… but thanks for merging it