- right/left to increase/decrease amplitude
- up/down to increase/decrease wavelength
- Z/X to increase/decrease animation speed
- Q to change background
- W to change effect type
I've been toying around with my Pico-8 for the last few days and after a good amount of bashing my head against a wall I finally have something cool and somewhat presentable. It translates horizontal lines on the screen either horizontally or vertically in a sine-wave-like pattern, just like the battle backgrounds in Earthbound and Mother 3.
Thinking of making a short vertical slice of some sort of RPG with a basic battle system that makes use of it.
Here are the relevant code snippets if you'd like to use the effects in your own game:
-- horizontal distortion effect -- by qbicfeet -- -- t: time -- a: amplitude (in pixels) -- l: wavelength (in pixels) -- s: speed -- y1: first horizontal line -- y2: last horizontal line -- mode: interlaced y/n function sine_xshift(t,a,l,s,y1,y2,mode) for y=y1,y2 do local off = a * sin((y + flr(t*s + 0.5) + 0.5) / l) if mode and y%2 < 1 then off *= -1 end local x = flr(off/2 + 0.5) % 64 local addr = 0x6000+64*y memcpy(0x4300,addr,64) memcpy(addr+x,0x4300,64-x) memcpy(addr,0x4340-x,x) end end
-- vertical distortion effect -- by qbicfeet -- -- t: time -- a: amplitude (in pixels) -- l: wavelength (in pixels) -- s: speed -- y1: first horizontal line -- y2: last horizontal line -- -- note: the difference between -- y2 and y1 can not be greater -- than 111 or it will corrupt -- the draw state ram! function sine_yshift(t,a,l,s,y1,y2) local dy = y2-y1+1 memcpy(0x4300,0x6000+64*y1,64*dy) for y=y1,y2 do local yy = (y + flr(a * sin((y + flr(t*s + 0.5) + 0.5) / l) + 0.5)) % dy memcpy(0x6000+64*y,0x4300+64*yy,64) end end
Some things worth noting:
- y1 and y2 values lower than 0 and higher than 127 will likely corrupt data in the RAM and/or crash the game
- if the wavelength is set to 0 a division by zero happens, but it seems like Pico-8 handles division by zero implicitly
- you could technically get around the "max height 112" problem with sine_yshift if you copy the screen data to 0x3f00 instead of 0x4300, which will overwrite part of the sound region of the RAM but give you another 16 horizontal lines to work with
Not sure what else to say... If you have any questions or comments I'll happily answer them!
It's because it redefined the 'type' global, which is usually a built-in function that returns the type of the argument that's passed in. Looks like @zep is now using that in tostr(), which is used inside print(), so it broke here.
I don't know if @qbicfeet is still active, so for now, here's a fixed version with a different name for the naughty global variable.
[Please log in to post a comment]