Dark Bit Factory & Gravity

PROGRAMMING => Freebasic => Topic started by: Dr_D on February 08, 2009

Title: Here's a rotozoomer...
Post by: Dr_D on February 08, 2009

I don't know if anyone needs it or not, but most of it's programmed inline x86 asm. There is a known bug when drawing to another fb.image, but we'll get that fixed asap. :)

rotozoom (http://drd.orly.mine.nu/download.php?id=46)

Title: Re: Here's a rotozoomer...
Post by: Shockwave on February 08, 2009

Thats nice and fast Dr.D :)

And it has source code too which could be helpful for people who want to load Bitmaps.

Thanks :)

Title: Re: Here's a rotozoomer...
Post by: Dr_D on February 09, 2009

Thanks Shockwave. That previously mentioned bug has been removed as well. ;)

Title: Re: Here's a rotozoomer...
Post by: benny! on February 09, 2009

Indeed. Well done, Dr_D

Title: Re: Here's a rotozoomer...
Post by: rdc on February 09, 2009

That's cool stuff, as always. Thanks!

Title: Re: Here's a rotozoomer...
Post by: Jim on February 10, 2009

Thanks Dr_D.  Would be interesting to compare what Freebasic compiler generates compared with hand optimised stuff.

Jim

Title: Re: Here's a rotozoomer...
Post by: Dr_D on February 10, 2009

Well, we did some stuff like leaving a few vars that get used a lot on the fpu stack. I can't be sure, but I don't think fb does that. I haven't looked at the asm fb generates for it normally, but that's an interesting idea! This one is quite a bit faster than one programmed directly in fb code though.

Title: Re: Here's a rotozoomer...
Post by: hellfire on February 10, 2009

I had a quick look at your source, some points that can be improved:
Bubble-sort is not a particularly fast way to pick the minimum/maximum from 4 values.
You're much faster by using integer coordinates for interpolation, the fpu just requires permanent "fisting".
Don't test every texel if it's inside texture-boundaries:
You can test where the current scanline enters/leaves the valid range and skip the according amount of pixels (or use a polygon) which makes the innerloop end up in just a few instructions.
You don't need a multiplication to build a texel's address:
"my" always increasing by the integer-part of "tsdzx" or one more if the fractional part causes an overflow. So you can pick the value from a table according to the carry flag (see here (http://www.exaflop.org/docs/fatmap/#Arbitrary%20size%20bitmap%20inner%20loop)).

Title: Re: Here's a rotozoomer...
Post by: matthew on February 10, 2009

Very nice & thanks for including the source.  :)

Title: Re: Here's a rotozoomer...
Post by: Clyde on February 11, 2009

Neat Dr_D, must of taken abit of doing.

Cheers And K++,
Clyde.

Title: Re: Here's a rotozoomer...
Post by: Shockwave on February 12, 2009

I can't seem to invoke the bug that you said was in the first version, where was it exactly?
It worked fine here.

Title: Re: Here's a rotozoomer...
Post by: Dr_D on February 12, 2009

Well, the fb.image structure now has pitch. We weren't taking that into consideration before, which caused errors when drawing to odd sized windows/images. It should be all good now though. :)

Title: Re: Here's a rotozoomer...
Post by: Shockwave on February 13, 2009

I see :)

Next things to do is add a scroller and a song ;)