[solved] Clipping with rotation wizardry

Engines, Libraries and Tools
#1

Hi there guys.
I’ll be direct, I’m trying to clip a texture region that rotates on its center.
I have managed to do this but with wizardry. This doesn’t seem to be the correct way of doing it =P.

This is what I wanted and managed to do (all placeholder textures):
Charging launcher indicator:

http://a.pomf.se/yfxmfs.png

Full indicator:

http://a.pomf.se/rhjgux.png

The problem is that this method generates this weird trail:

http://a.pomf.se/mmlocb.png

This shows when you charge (only hold the mouse) a few ms, means low power shot. I believe that this is because I shift the TextureRegion back when I shrink it.
(edit) I think this is because the area after the texture is not an empty region, I believe on low level it just copies the last row of pixels and there is a black shade thingy there that is
creating this trail. I’ll experiment on this. The problem though is that this is not the correct solution. This is just rendering the clipped image and stretching the clipped area with empty pixels
so the image stays in place. The correct way would be to have a ‘empty’ transparent region where the image expands on it cropped without any stretching.

I don’t think this is the right way of rotating TextureRegions with clipping.

The code that produces this:



	...

	public void draw(SpriteBatch batch) {
		// Draw default under texture
		...
		// Draw the top charging texture
		batch.draw(
				overTexture,
				position.x - underTexture.getRegionWidth() * scale / 2,
				(position.y - underTexture.getRegionHeight() * scale / 2) - calculateOTHPerCharge() * scale,
				underTexture.getRegionWidth() * scale / 2,
				(underTexture.getRegionHeight() * scale) / 2f + calculateOTHPerCharge() * scale,
				underTexture.getRegionWidth() * scale,
				underTexture.getRegionHeight() * scale,
				1f,
				1f,
				angle);

	}

	...

	/**
	 * OTH = Over Texture height
	 */
	private float calculateOTHPerCharge() {
		return (1f - chargePercent) * overTexture.getTexture().getHeight();
	}

	public void setChargePercent(float chargePercent) {
		this.chargePercent = chargePercent;
		overTexture.setRegionY(0);
		overTexture.setRegionHeight(overTexture.getTexture().getHeight());
		overTexture.setRegionY((int) calculateOTHPerCharge());
		overTexture.setRegionHeight((int) (overTexture.getRegionHeight() + calculateOTHPerCharge()));
	}
#2

Kinda solved that. Not learning the correct way but with MORE MAGIC POWER.
I was thinking that some times get stuff done is more important. So I used all my developer mana (coffe) avaliable.
It is not done yet but it works as intended with some side-effects.

In the constructor I flip the textureregion that is supposed to be cut. This is done so the cut in height actually cuts the image upwards:

overTexture = new TextureRegion(new Texture(Gdx.files.internal("launcher_full_flip.png")));
		overTexture.flip(false, true);

Then when I draw the texture I use some information from the under texture. This is done so the position and rotation origin
of the over texture is unaffected by its height change:

batch.draw( overTexture,
				position.x - underTexture.getRegionWidth() * scale / 2,
				position.y - underTexture.getRegionHeight() * scale / 2,
				overTexture.getRegionWidth() * scale / 2,
				(underTexture.getRegionHeight() * scale) / 2f,
				overTexture.getRegionWidth() * scale,
				overTexture.getRegionHeight() * scale,
				1f,
				1f,
				angle);

The calculation that gets the height over charge is the same (inverted charge times height):

	private float calculateOTHPerCharge() {
		return (1f - chargePercent) * overTexture.getTexture().getHeight();
	}

The code that does the image height change is different though. It now only changes the region height (reseting it before change every time):

public void setChargePercent(float chargePercent) {
		this.chargePercent = chargePercent;

		overTexture.setRegionHeight(overTexture.getTexture().getHeight());
		overTexture.setRegionHeight(overTexture.getRegionHeight() - (int) (calculateOTHPerCharge()));
	}

The main catch with this way of doing it is that I had to physically(photoshop) flip vertically the image that I use as the over texture. This is because the flip on the
texture region also flips the image data. So though it cuts the image the right way (upwards) it cuts the ‘wrong’ flipped image.

Anyway, it works. If you guys do this any other better way please let me know ::slight_smile:

#3

I’m a bit late to the party… but if you see a trail, you’re either drawing more and more sprites per frame (from oldest position to newest position, rendered on top of eachother), or you are not clearing your frame buffer each frame, or your geometry is much larger than your sprite and the texture is configured to clamp-to-edge…

#4

This trail isn’t about the frame buffer. Frame buffer trails are related to translation or rotation (movement in general) because the last frame is always kept. This trails is because I’m drawing a region of the sprite that has ‘nothing’ on it. I think when I call the method, opengl just replicates the last row of pixels. Anyway, the problem is solved. Using trickery but still… solved.
KOP - Kludge Oriented Programming.