Textured Polygons for All!

[zorg]

Also please use [ code ] [ /code ] blocks, otherwise the posted code is a bit unreadable.

[ghurk]

Anyone know how are data stored in TransformMatrix?
modified the shader so that i am able to draw like this:

Code: Select all

	texture.setVertices( v[1],v[2],v[3],v[4] ) --same as mesh vertices now
	
	texture.preload(true)
		love.graphics.translate(120, 100)
		love.graphics.draw( mesh, 0, 200, 0, 1, 1)
	texture.preload(false)

but still need to find out how to pull out rotation and scale data from matrix. thanks. (still need to scale and rotate)
*achieved with:

Code: Select all

vec2 positionData = vec2( TransformMatrix[3][0], TransformMatrix[3][1] );
vec2 screen = screen_coords-positionData;

where "screen_coords" is "inverted" then renamed to "p" in original shader, but thats it yea.
and then basically anything that is "p" in original shader is now "screen" in my shader.

when it comes to scaling, when i set scale (both x and y) to "3" on mesh, i know i need to do this:

Code: Select all

vec2 screen = (screen_coords-positionData)/3;

but none of matrix pairs match this result so am in slump here

**solved:

//TransformMatrix[0][0] = vec2 containing both data

Code: Select all

vec2 scaleData = vec2( TransformMatrix[0][0] );
vec2 screen = (screen_coords-positionData)/scaleData;

this enables mesh scale and also love.graphics.scale()

[Davidobot]

Anyone know how are data stored in...

I'm not sure what you're saying here, but did you manage to improve the library or speed it up? If so, it would be greatly appreciated by a number of us here if you posted your changed library.

[ghurk]

actually i still have 3 steps left so not ready to post here yet.
1. decipher the data and extract+apply both rotation and skew in pixel shader.
2. use mesh vertex data instead sending them as extras for pixel shader.
at this point it will be able to save at least the amount u need to perform additional computations on final positions coming from the scaling, rotating and buddies.
also sending the data as draw(mesh) means all color settings available for mesh apply properly here.
3rd step would be sending custom vertex format with z and performing perspective calculations in shader, which will save hell lot, but to be useable by other people would need proper explanation of how to operate or modify the shader, so im saving it as last.

also yea, even if it is going to be more cpu expensive with the 1s and 2nd step at least possibility to draw "like normally" without having to reset changes to colors and draw coordinate modifications between batches when u use and dont use shader will surely help, at least me (combined 2d and fake 3d drawing).

by if i mean not rly sure if drawing as mesh ramps up cpu usage that much it would eat more than it would save.
also when it comes to mesh, currently shader generates vertices anyway, just without colors.
///////////
currently solved rotation, position and scale. transformations in shader below:

Code: Select all

    	//position
   	 vec2 positionData = vec2( TransformMatrix[3][0], TransformMatrix[3][1] );
	vec2 screenA = (screen_coords-positionData);

	//rotation
	float rotX = -TransformMatrix[1][0];
	float rotY = TransformMatrix[1][1];
	float dir = atan( rotX, rotY );

	float sin_factor = -sin( dir );
    	float cos_factor = cos( dir );

	vec2 screenB = vec2( screenA.x*cos_factor, screenA.y*cos_factor ) * mat2(cos_factor, -sin_factor, sin_factor, cos_factor);

	//scale
	vec2 scaleData = vec2( TransformMatrix[0][0], TransformMatrix[1][1] );
	vec2 screen = screenB / scaleData;

still need testing under various conditions, but separately and on basic tests all worked. complete modified shader after i link coordinates to mesh properly.
("screen" = "inverted" or later used as "p" in original shader)

[ghurk]

Ok. so i tried to implement only the transformations support now.
I will try to post new file, able to be drawn through draw() later when/if it is completed.
Please try out and comment if transformations work properly in all cases. also excuse the simplified functions.
Not sure if its going to be more cpu expensive to send vertices to shader through array like i did, reason for it being present is that id like you to test it against original shader which has different approach.
also note that it doesnt support skew. thanks.

[Popolon]

Really nice library . There is a problem with the zoom. it uses 0,0 map coordinates as centre of the zoom instead of the current view central position.

[cupz]

Love the lib, but calling love.window.setMode() seems to break it. Can anyone please help out with this? <3

Without setMode()


With setMode()

[cupz]

Fixed it! Was using an older version by accident.

[xXxMoNkEyMaNxXx]

Returned from the grave to clarify that I would like people to use this as they see fit (something like an MIT liscence), just give me credit for my math! I love what you've done with it ghurk, I hope that people will continue to make useful modifications to this as long as it is still relevant. I am shocked at how well-commented the math in my original code is. I would usually just pile it all into one line using those mathy single letter variables. Looking through this from the start, I regret arguing with Ref about modifying my code, but it looks like I also regretted it in 2013 in one of my posts back then. I won't be active in this forum, but I'll probably visit again one day!

[molul]

Wow, this is exactly what I needed for a retro tunnel effect I I was working on!

I have a question: would this run on an ARM Linux device? I'm not talking about performance, I'm asking if shaders are compatible with ARM devices. Sorry, I'm a bit clueless about GLSL, GLES, etc

Thanks a lot in advance!