From: frenchc AT cadvision DOT com (frenchc) Newsgroups: comp.os.msdos.djgpp Subject: Re: Allegro Wierdness (rotate_sprite)... Date: 20 Jan 1997 04:07:52 GMT Organization: CADVision Development Corp. Lines: 37 Message-ID: <5bur2o$308i@elmo.cadvision.com> References: <5b8rfb$2da8 AT elmo DOT cadvision DOT com> NNTP-Posting-Host: ts35ip234.cadvision.com To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp In article , Shawn Hargreaves says: > >frenchc writes: >>I'm finding the allegro fix class to be a bit wierd. The overloaded >>operators seem to work ok, but why are the trig functions implemented the >>way they are? Is there something i'm not getting? Shouldn't they be >>designed to make the following possible: >> >>fix F, G; >>(whatever) = F.cos(); >>(whatever) = F.sin(); >>(whatever) = F.atan2( G ); > >What's wrong with just calling cos(F)? Allegro overloads the standard >function names, so if you call cos on a float you will get the standard >libc version, while if you pass it a fix object you'll get Allegro's >version. That seems to me to be simpler than having it as a member >function: my goal was to make the class as behave as similarly as >possible to the native C syntax for ints and floats... Ok, makes sense to me. I was just looking at the header, and thought from looking at it that I would have to use fix::cos( F ) which was too messy for me :) Thanks, anyways! Which brings me to my next question. When I rotate a sprite, the edge gets clipped. This isn't a big problem for square-ish sprites, but for elongated ones this is a real problem :( Is there an easy way around this? If neccesary, I guess I will have to hack out my own rotate_sprite routine, or else have the sprites all copied onto a 64x64 bitmap, then rotated, or something. I'll have a look at DEMO though, and see how the text rotation was done. >/* > * Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/ > * Ghoti: 'gh' as in 'enough', 'o' as in 'women', and 'ti' as in 'nation'. > */