Mode 7 still, this time with a fragment shader.
Controls:
WASD/UDLR: Move character
1 & 2: Change angle
3 & 4: Change scale
5 & 6: Change character location (how far up/down as a percentage of the screen)
Random question, will LOVE ever use anything above GLSL 1.20 so I can have nearest neighbor filtering? floor(pixel_coords)/screenwidth doesn't work.
Planned features:
☑: Psudo-3D track
☒: Racing physics
☒: AI
☒: Sprites
☒: Tracks
☒: A track editor
☒: Characters
☒: Loads of awesome pixel effects
☒: Stereoscopic 3D
History:
v1.0
- Initial
v1.5
- Adds some kart physics
- Adds shadow
Last edited by retrotails on Sun May 05, 2013 4:37 pm, edited 1 time in total.
retrotalis wrote:Random question, will LOVE ever use anything above GLSL 1.20 so I can have nearest neighbor filtering? floor(pixel_coords)/screenwidth doesn't work.
I'm not sure I understand. Nearest-neighbour filtering is controlled by (Image):setFilter and Canvas:setFilter. Changing an image's filter will affect it when it's drawn regardless of whether a shader is active, different GLSL versions don't change that.
retrotalis wrote:Random question, will LOVE ever use anything above GLSL 1.20 so I can have nearest neighbor filtering? floor(pixel_coords)/screenwidth doesn't work.
I'm not sure I understand. Nearest-neighbour filtering is controlled by (Image):setFilter and Canvas:setFilter. Changing an image's filter will affect it when it's drawn regardless of whether a shader is active, different GLSL versions don't change that.
Yes, but not when a texture is drawn in a shader. Only GLSL 1.30 can do that as far as I know.
retrotalis wrote:Random question, will LOVE ever use anything above GLSL 1.20 so I can have nearest neighbor filtering? floor(pixel_coords)/screenwidth doesn't work.
I'm not sure I understand. Nearest-neighbour filtering is controlled by (Image):setFilter and Canvas:setFilter. Changing an image's filter will affect it when it's drawn regardless of whether a shader is active, different GLSL versions don't change that.
Yes, but not when a texture is drawn in a shader. Only GLSL 1.30 can do that as far as I know.
No. As I just said, an image's (or canvas') filter mode is completely separate from shader versions. Changing it will affect Texel/texture2D function calls in shaders for that image no matter the GLSL version.
It's pretty easy to test this. Adding tex:setFilter("nearest", "nearest") to love.load changes it from this:
slime wrote:
It's pretty easy to test this. Adding tex:setFilter("nearest", "nearest") to love.load changes it
Tried it, doesn't work for me. You using a version above 0.8.0?
Nope. Are your video drivers up to date? If not, update them. What GPU do you have? Can you confirm that tex:getFilter() returns "nearest", "nearest" after the setFilter call?
slime wrote:
It's pretty easy to test this. Adding tex:setFilter("nearest", "nearest") to love.load changes it
Tried it, doesn't work for me. You using a version above 0.8.0?
Nope. Are your video drivers up to date? If not, update them. What GPU do you have? Can you confirm that tex:getFilter() returns "nearest", "nearest" after the setFilter call?
I used setDefaultImageFilter but I've tried setFilter on the texture and the canvas, to no avail.
See v1.5 above - it's still filtered for me.
In your updated version, you draw the track image to a canvas, and then use that canvas in the shader. love.graphics.setDefaultImageFilter doesn't affect canvases in 0.8.0, so your texture accesses in the shader still use linear filtering. Setting nearest-neighbour filtering for all of the canvases individually makes it work as expected.
Version 1.0 works fine by just setting the default image filter, because you're using the image directly in the shader.
