Main Menu

Sprite Rotation/Scaling

Started by kevin, December 02, 2003, 11:42:31 AM

Previous topic - Next topic

kevin

This screen shot is taken from the current sprite rotation /scaling rendering routines.  Even though it's fairly sloppy  (requires UV clamping every pixel, ouch )  it should be a useful feature at run time.  Again that's not to say you'll be able to rotate hundreds of sprites on screen at once, i'd say a hand ful (depends on the size obviously), but it should be fast enough for some nice effects in your programs.

So for the best results, one will probably use a combo of pre-rotated images and real time rotation.  You could prolly cache your rotation frames in real time if you wanted (ie. if the object doesn't change direction/size between frames). But That's up to you though :)

kevin

#1
Sprite Rotation.

 Been working on the sprite layer mainly the pass couple of days.  The picture shows 25/26 sprites (64*64) rotating, will a full backdrop plane of sprites also. The screen 640*480*16..  Only 16 and 32bit are supported at the more for real time effects like rotation/alpha blending and a few others :).  But that take time to implement.

Most the past two days have been investing into the design process/unification of the Sprite/Map/Shapes/Vector 2D to camera.  I've pretty decided to make perhaps the most radical design change of any 2D language to date.  Radical in the sense that you may  no long be able to render to the screen, but your gfx are processed to the world.  Then a view port is displayed from the cameras perspective.   This could practically work with anything, sprites/maps text , you name it.  

Why ?.

The main reason is so that the camera takes the major reasonability's off your shoulders, those being, render order and clipping to the view port. Since the drawing process is Z buffered (per item / not pixel) you get abilities and by products, you just can't easily do in other languages, if at all. For example like mixing vector gfx (dots/lines/boxes/circle/shapes/polygons etc) with the mapping and sprites layers. So lines could be drawn in front of some sprites and behind others.  As these entities have their own Z priority.  So they could move in and out of the scene, just any other element.  

If you want to draw directly to the screen, you still could. But then everything is manual.  

While this is not a new concept to PB, as entities were the older interface with the camera/world and z buffer..  But the more i think about it, the more logical it becomes to render everything through the camera  interface.

kevin

#2
Actual PlayBASIC Sprite Rotation / Code  (no camera)


PlayBASIC Code: [Select]
   MakeBitmapfont 1,$ffffff

cd ".."
loadimage currentdir$()+"gfx\bubble_64x64.bmp",1
PrepareFxImage 1


starsN = 25

Type Bubble
X#,y#,XSpeed#,YSpeed#,Angle#,RotSpeed#
EndType

Dim Stars(StarsN) as Bubble

for starsI=1 to starsN
stars(starsI).x = rnd(800)
stars(starsI).y = rnd(600)
stars(starsI).xspeed = rnd(5)
stars(starsI).yspeed = rnd(5)
stars(starsI).angle = rnd(360)
inc speed#
if speed#>10 then speed#=1
stars(starsI).rotspeed = speed#

CreateSprite starsI
SpriteImage starsI,1
SpriteTransparent starsI,1
PositionSprite starsI,starsX,starxY
SpriteDrawMode starsi,2
SpriteHAndle Starsi,(GetImageWIdth(1)/2)*-1,(GetImageHeight(1)/2)*-1
RotateSprite Starsi,stars(starsI).angle
Scalesprite StarsI,0.15+(Rnd(100.0)/100.0) ; ScalespriteXY StarsI,1.15,0.25; ScalespriteY StarsI,2.15

next starsI



RenderToScreen 1

do

cls 0
inc frames

for starsI=1 to starsN
x#=stars(starsI).x+stars(starsI).xspeed
Y#=stars(starsI).y+stars(starsI).Yspeed

if X#<0 or X#>800
stars(starsI).xspeed=stars(starsI).xspeed*-1
endif

if Y#<0 or Y#>600
stars(starsI).yspeed=stars(starsI).yspeed*-1
endif

TurnSprite Starsi,stars(starsI).rotspeed
PositionSprite Starsi,X#,Y#

stars(starsI).x=x#
stars(starsI).Y=y#
next starsI

DrawAllSprites


if timer()-starttime>1000 then starttime=timer() : fps=frames : frames=0
centertext GetScreenWidth()/2,20,"FRAMERATE: "+STR$(fps)
sync

loop







las6

SpriteHandle? is that the same as the point of origin for rotation and such?
system specs: Win XP pro, 2700+ (TB), 1024 Mb DDR, Radeon 9600 pro (128).

empty


las6

ah, good.

[slightly off-topic] Now, how would you go on about adding points that rotate with the sprite? Like for a spaceship, it would be nice to be able to set up the points for the cannons. so that you could position the "bullets" there. Can be done with code, I know cos I might have to do something like that in DBpro, but just thought it could be useful feature. ;)
system specs: Win XP pro, 2700+ (TB), 1024 Mb DDR, Radeon 9600 pro (128).

kevin

Well yeah, I could add vertex or limbs to sprites (still toying with an attach sprite) ..  But ideally for something like this, you'd better suited to use an entity.. The entity can have clusters of sprites / vector gfx / or just vertex attached to it..  

Entities currently only exist in a external library though.  But their all just driven through the scene buffer.

las6

good. I was thinking that it would be possible using a hidden vector entity that you've mentioned before... But if I can have clusters of sprites and mix them with vectors and such, it's even better. ;)
system specs: Win XP pro, 2700+ (TB), 1024 Mb DDR, Radeon 9600 pro (128).