Very nicely done ! I'm starting to see that FIREFOX is really not a good browser to play these PICO programs. I have one tab open in GOOGLE CHROME just for PICO and it plays there beautifully.
Will have to see the source to this when I get PICO, should be 48-hours from now.
Nice work! One thing that was confusing me was that when calculating the reverse rotation for xx and yy, the direction of the angle wasn't reversed. The reason it works is because the input angle is specified in a clockwise direction (10 degrees turns the ship right) while increasing angle goes anticlockwise in PICO-8 (10 degrees turns the ship left).
>Works great. Mind if I reuse it in my own project?
should be ok, the cart has a cc license (see the CC icon)
> I'm starting to see that FIREFOX is really not a good browser
running fine here, and it's on on a 5 years old laptop.
Can it be abstracted as to rotate around arbitrary point? I'm thinking about a game like Asteroids, but where you also have to fight other ships (which would be capable of shooting asteroids as well) and rotating around an arbitrary point would be useful for AI (as I want to make them circle strafe around player from time to time).
Hey @freds72 - I grabbed your code for a project and it seems like it doesn't quite work. When I rotate my sprite 180 degrees the drawing point seems to shift up and right one pixel - so the sprite is moved one pixel to the right and one pixel downwards which cuts off the right most and bottom lines of the sprite. Is this a known issue?
Hello, does anyone mind explaining how this works? I'm adapting the first example @fred72 provided to a Gyruss clone that I'm working on (couldn't get the second to work) and I managed to get it to function semi-decently, but doing so required some pretty nasty hacking since I'm just not familiar enough with the math involved.
Edit: I got the last example working. However when I use this one rather than the previous, the sprites streak at the edges. Does anyone know how to fix this?
My initial sample code misses a 0.5 offset.
Edit: fixed the fix!
(e.g. I needed to adjust the square center with a half pixel)
The sprite can now use the full 8x8 or 16x16 extent!!
The "streaks" you have seens are "normals", sprite "effective image" must fit within a circle (e.g. pixels outside sprite radius will get trimmed).
I also added a clear color (unfortunately needed for pixel outside of the 'safe' zone).
Set the rspr_clear_col to specify a color that matches your sprite palette.
As for the math behind, it comes from:
Fast Bitmap Rotation and Scaling
In short, the code draws the image line by line and calculate the line (in sprite space) that needs to be copied.
The band trick (to stay within sprite boundaries) is from:
Gyruss is a pseudo-3d game, suggest to use the rspr version I posted (e.g. drawing into spritesheet).
That will give you sspr for free and will allow you to scale sprites based on their distance (actually 1/z).
To get you started :)
Thank you so much for that link; that's exactly what I was hoping for :D
I did get the second example working after analyzing it for a little while; I was (somehow) under the impression that it required the players actual x and y coordinates to function (it was really late xD). As for the distortion I mentioned: I resolved that by trimming the sprite down a pixel, so the image is now effectively 14x14 rather than 16x16. That's fine, but I liked the original graphic I created more xD
As for the nasty hacks I mentioned, I removed those after I realized that I was calculating the players rotation using a method that didn't work with your function. I can't seem to find a link to where I got the method I was using, but essentially the only real difference between what I was using before, and what I'm using now is that it had me dividing the players angle by pi, which was causing the player object to veer off the origin I wanted it to orbit. After tweaking my function, I managed to get it working properly :D
Note: I noticed your edit while I was writing this, thanks for the help! As for the code, I'll definitely take a look, since it does a lot more already than what I managed to get working :)
Hey freds, thanks! When I added the 0.5s last time it appeared to work but then using a sprite which was a circle, so 3 pixels in each corner were transparent, seemed to have an issue where the bottom right corner was the same colour as the rest of the sprite instead of transparent.
I'm going to be working on the game tonight (UK time) so will try again with your latest version since I was still using the non sprite sheet version and let you know how I get on :D
Awesome, thanks freds! After studying your code, I've pretty much recreated it in a effort to figure it all out in my brain. The Gyruss part, that is. I'm not touching that sprite rotation function for a little bit xD
Have to say, working with your function is extremely easy now that I've worked out roughly how it works.
If you take a close look at SIN() and COS() for circles, they are really ragged compared to using a simple substitute like balancing comparisons thus:
-- note! requires floating -- point numbers, messy function uglycircle(x,y,r) local i x=x+r/1.05 for i=1,385 do pset(x,y) x+=sin(i/(r*6.1)) y+=cos(i/(r*6.1)) end end cls() for i=7,64,8 do uglycircle(64,64,i) end
-- lovely circle from dots for pico using balancers -- note! no floating point numbers are needed! function circle(x,y,r,c) local xo,yo,ba=0,r,3-2*r repeat pset(x-xo,y-yo)pset(x-xo,y+yo) pset(x+xo,y-yo)pset(x+xo,y+yo) pset(x-yo,y-xo)pset(x-yo,y+xo) pset(x+yo,y-xo)pset(x+yo,y+xo) if (ba<0) ba+=6+4*xo else ba+=10+4*(xo-yo) yo-=1 xo+=1 until xo>yo end cls() for i=7,64,8 do circle(64,64,i) end
@freds72 your second post says..
but your first code does not have..
in it but instead has..
can u explain?
right now it uses like a 7x7 tile space or something because the higher sprite index I use the worse it looks coming to a point where its not even drawing the correct sprite.
@dw817 hu.. not sure what to do with that. Sprite rotation needs a vector from an angle.
@Shadowblit16 look 2 lines below, I am reusing variables.
Also note that the code assumes the rotated sprite fits within a circle.
(eg if you want a bigger sprite, you need to ‘waste’ space - see the Gyrus example for some sprite examples)
Here is a simpler version that writes to screen:
function rspr(sx,sy,x,y,a,w) local ca,sa=cos(a),sin(a) local srcx,srcy local ddx0,ddy0=ca,sa local mask=shl(0xfff8,(w-1)) w*=4 ca*=w-0.5 sa*=w-0.5 local dx0,dy0=sa-ca+w,-ca-sa+w w=2*w-1 for ix=0,w do srcx,srcy=dx0,dy0 for iy=0,w do if band(bor(srcx,srcy),mask)==0 then local c=sget(sx+srcx,sy+srcy) pset(x+ix,y+iy,c) end srcx-=ddy0 srcy+=ddx0 end dx0+=ddx0 dy0+=ddy0 end end
You could always 1/2 the steps of the plotter. I think my idea would work.
I'm working on a data compressor right now, a powerful one that functions a little like a computer chess player in that it looks ahead for its moves.
I should be able to post it today. Then I'll see if it's possible to make a very smooth rotation engine using the balancers above.
Of course if ZEP would just add rotation plotting to P8, which is standard in most video game programming languages, we wouldn't be here. :)
GrabImage img_stripe,0,0 Repeat SetAlpha .008 Cls For i=-256 To 1024+256 Step 2 SetRotation bgswirl*.0005 DrawImage img_stripe,i,Sin(bgswirl/2000.0+(i/8.0))*200.0+350.0 If i Mod 4=0 bgswirl:+1 EndIf Next Flip -1 Until KeyDown(27)
If you're using the function spr_r defined at the top in jihem's code, I found a fix for a bug where the wrong spritesheet pixels would be taken (unless your sprite id is 0, pixels from a sprite too far will be taken. Sometimes this will go beyond the spritesheet, resulting in black pixels.
since there are 16 sprites per row in the spritesheet.
I continued working on the function and added flipping and custom pivot. I also refactored the code a bit to work directly with delta coords dx and dy and reduce extra operations.
I also now pass the sprite location (i, j) directly but if your prefer working with sprite id n, just compute yourself i = n % 16 and j = flr(n / 16).
Note that I'm not flooring x and y but if like me you observe jittering when applying rotation to your moving character while following it with the camera, this is due to pixel fractions bumping rotated pixels to the neighbor pixels. I suggest you floor x and y before passing them to spr_r in that case.
My code is a bit more expanded and has comments, I don't mind because I minify it, but if you don't, feel free to make it compact again as in the original version.
Adapted from jihem's spr_r
- w and h don't default to 1 (you can restore that easily)
- angle is passed directly as PICO-8 angle between 0 and 1 (no division by 360, counter-clockwise sign convention)
- support flipping
- support custom pivot
- support transparent_color
- draw pixels even the farthest from the pivot (e.g. square corner to opposite corner) by identifying target disc
- fixed yy <= sh -> yy < sh to avoid drawing an extra line from neighbor sprite
function spr_r(i, j, x, y, w, h, flip_x, flip_y, pivot_x, pivot_y, angle, transparent_color) -- precompute pixel values from tile indices: sprite source top-left, sprite size local sx = 8 * i local sy = 8 * j local sw = 8 * w local sh = 8 * h -- precompute angle trigonometry local sa = sin(angle) local ca = cos(angle) -- in the operations below, 0.5 offsets represent pixel "inside" -- we let PICO-8 functions floor coordinates at the last moment for more symmetrical results -- precompute "target disc": where we must draw pixels of the rotated sprite (relative to (x, y)) -- the target disc ratio is the distance between the pivot the farthest corner of the sprite rectangle local max_dx = max(pivot_x, sw - pivot_x) - 0.5 local max_dy = max(pivot_y, sh - pivot_y) - 0.5 local max_sqr_dist = max_dx * max_dx + max_dy * max_dy local max_dist_minus_half = ceil(sqrt(max_sqr_dist)) - 0.5 -- iterate over disc's bounding box, then check if pixel is really in disc for dx = - max_dist_minus_half, max_dist_minus_half do for dy = - max_dist_minus_half, max_dist_minus_half do if dx * dx + dy * dy <= max_sqr_dist then -- prepare flip factors local sign_x = flip_x and -1 or 1 local sign_y = flip_y and -1 or 1 -- if you don't use luamin (which has a bracket-related bug), -- you don't need those intermediate vars, you can just inline them if you want local rotated_dx = sign_x * ( ca * dx + sa * dy) local rotated_dy = sign_y * (-sa * dx + ca * dy) local xx = pivot_x + rotated_dx local yy = pivot_y + rotated_dy -- make sure to never draw pixels from the spritesheet -- that are outside the source sprite if xx >= 0 and xx < sw and yy >= 0 and yy < sh then -- get source pixel local c = sget(sx + xx, sy + yy) -- ignore if transparent color if c ~= transparent_color then -- set target pixel color to source pixel color pset(x + dx, y + dy, c) end end end end end end
Check the source if you need more comments, but note the actual file I'm using relies on some constant tile_size = 8 defined elsewhere.
[Please log in to post a comment]