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.
[Please log in to post a comment]