Scrolling Backgrounds
I am trying to find a more effecient way of drawing scrolling backgrounds. The way I currently draw them is very similar to the tutorial on this site. I have an offscreen gworld and just move a rect around the gworld and copybits from the rect to the screen. The problem with this is that it is very slow.
I wanted to know if anybody has a better suggestion. I have a feeling the answer may be, use OpenGl, but I was hoping for maybe something else as I planned on learning GL after this project.
If I do use OpenGL that brings up another question I have. All my sprites are done using Quartz. I know this isn't conventional, but I thought it would be something new, I get lots of goodies, and I actually get really fast frame rates (except when the screen is scrolling). So would there be an issue with overlaying Quartz graphics on top of GL stuff?
I wanted to know if anybody has a better suggestion. I have a feeling the answer may be, use OpenGl, but I was hoping for maybe something else as I planned on learning GL after this project.
If I do use OpenGL that brings up another question I have. All my sprites are done using Quartz. I know this isn't conventional, but I thought it would be something new, I get lots of goodies, and I actually get really fast frame rates (except when the screen is scrolling). So would there be an issue with overlaying Quartz graphics on top of GL stuff?
You can overlay Quartz on OpenGL in Jaguar. That's probably not your best option, though 
Chances are, rendering your sprites to a texture (still using Quartz), then rendering that texture using OpenGL would be a bit faster...

Chances are, rendering your sprites to a texture (still using Quartz), then rendering that texture using OpenGL would be a bit faster...
I gave up Carbon programming almost as soon as they called it that, which is before I became any good, but I have read that copybits was supposed to be really fast, not slow -- this is from an old book: Tricks of the Mac Game Programming Gurus. If I remember correctly there were ways to make it slower -- yeah, you have to ensure no scaling, and synch the bit depths between your source and target, and also something call the ctSeed has to match. Also, unaligned pixmaps are a time eater, too. Have you accounted for such things?
--FĂanor
--FĂanor
Yeah, CopyBits is really fast. Just nowhere near as fast as OpenGL
Quote:Originally posted by OneSadCookie
Yeah, CopyBits is really fast. Just nowhere near as fast as OpenGL![]()
Not on a Rage IIc! :-)
-Jon
Quote:Originally posted by aarku
Not on a Rage IIc! :-)
Ammendment: Not on a Rage IIc, on OS X! Works great on 9

Cheers,
Rocco
Virus Out
Big Bang Board Games
Adventures on Pirate Isle
Solace - Strategy, War, and Glory!
The Belt
Thanks for the suggestions. After looking over the code again I found that my src rect and dest rect for CopyBits were not the same size. By fixing this I increase FPS by almost 30.
Also, what is an unaligned pixmap? Would a pixmap that is 640x480 be aligned and one at 400x400 not be?
Also, what is an unaligned pixmap? Would a pixmap that is 640x480 be aligned and one at 400x400 not be?
If you make your offscreen graphics store with NewGWorld, QuickDraw takes care of the alignment for you.
If you're creating it with QTNewGWorldFromPtr, you should make sure that each row is 32-byte aligned (this is what NewGWorld guarantees currently). There's some code in QTValuePak showing how to do this.
If you're creating it with QTNewGWorldFromPtr, you should make sure that each row is 32-byte aligned (this is what NewGWorld guarantees currently). There's some code in QTValuePak showing how to do this.

