VBL in CoreGraphics?

Apprentice
Posts: 10
Joined: 2005.08
Post: #1
Is there a way to obtain an accurate VBL synchronization using CoreGraphics?
I have tried CGDisplayBeamPosition and CGDisplayWaitForBeamPositionOutsideLines but as the documentation states, they are simplu unreliable. Then I downloaded the BlitVBL from developer.apple.com and found that all it does is place a timer which fires each 1/50 sec...
I really hate OpenGL, so i'd prefer to stick with CoreGraphics as much as possible.

Thanks,
Claudio "Oblivion" Russo
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
No. Use OpenGL.

If you only need 10.3+, you can use CoreGraphics to render to a GL context.
Quote this message in a reply
Apprentice
Posts: 10
Joined: 2005.08
Post: #3
Are you thinking about glCopyPixels or the like? doesn't that require to work with the y axis flipped?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
no, I'm thinking of CGGLContext.
Quote this message in a reply
Apprentice
Posts: 10
Joined: 2005.08
Post: #5
never used it, how would I transfer my bitmap data?
I presently just memcopy to the right DirectDisplay base + offsets each scanline, but as you may imagine, i get an horible tearing effect.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #6
so if you're not actually using CoreGraphics, what's wrong with OpenGL?

you could upload your bitmap data to a texture, and draw a textured and possibly blended quad wherever you like, get a nice speed boost, and VBL sync.
Quote this message in a reply
Apprentice
Posts: 10
Joined: 2005.08
Post: #7
Well, I use CG to set the Display Mode, load the palettes and get the base addresses Wink
no, seriously, I have used OpenGL in the past but having to invert the y axis, use rgba (or inverted bgra!!) and its silly stack based operation ... yes, It's the future, but for now i prefer to use an API, not an FSM

also, I would not bet 20 cents on OpenGL surviving the Windows Vista/Aero disaster.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #8
... sez the man blitting directly to video memory Blink
Quote this message in a reply
Apprentice
Posts: 10
Joined: 2005.08
Post: #9
Yes, it's weird, but that's the way we used on the Amiga ... Wink
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #10
Since when do you have to invert the y axis? You are responsible for setting up the veiwport, not OpenGL. If you want to have your x axis go diagonally across the screen then thats great, you can do it. If you want the origin to be set at the top left corner with the y axis pointing downward, then you can do that too. Wink

Also, if you don't like the way OpenGL works then code some basic functionality around it and make your own API. Then you'll never have to touch it again.

Lastly, do you think that Apple and everyone else is simply going to drop OpenGL because Microsoft decided to deprecate it?
Quote this message in a reply
Apprentice
Posts: 10
Joined: 2005.08
Post: #11
Well, Skorche, I know about the viewport axis setup, the point here is the glCopyPixels function:
if that function uses Viewport coordinates it's good, otherwise I will have to flip the image at blit time. I cannot map the image onto a texture because I require pixel perfect quality and, as OpenGL.org pointed out, OpenGL cannot guarantee that each bitmap pixel is blitted exactly as is.

Even if I decide to go for the texture + quad mode, I will have to store the texture in local memory
due to the fact that I have to access pixels during collision detection but from what I have seen, my 9200 radeon cannot generate a texure greater than 2048x2048 in local memory.

Lastly, about OpenGL future ... Apple is a small player here:
If Microsoft decides that OpenGL is dead, OpenGL IS dead. Remember that linux uses Mesa (GL Like). The ARB will dissolve quickly if the OpenGL for windows does not allow for extensions/updates. No ARB no OpenGL. That day, the 68K->PPC->QD3d->OGL->Os9->OsX->x86 migration chain will get a another "Step"... but we have no control over this so let's keep coding.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #12
Ah, well if you're doing pixel collisions and modifying the bitmaps that would make things a bit harder then...

You could still just use a screen sized texture and use dirty rects when uploading. Despite the fact that OpenGL.org says that you can't rely on OpenGL for pixel perfect alignments, OSX going behind your back and using Quartz Extreme to composite things anyway. So it can't make that much difference.

Didn't Microsoft leave the ARB a few years ago anyway?
Quote this message in a reply
nabobnick
Unregistered
 
Post: #13
I'm currently experimenting with full window/screen blitting. I have written code that allows you to choose which method you want to use (NSImageBitMapReps, Core Graphics, OpenGL DrawPixels, and OpenGL Texture Rectangle). This isn't all the methods available as it leaves off OpenGL Texture2D and some options available in 10.4 which I do not have yet.

Your reasons for not using OpenGL are a little over the top. Doom 3 was written in OpenGL. Microsoft has no say in it's life as there are 100s of companies backing OpenGL, Microsoft can't ignore them and if it does the backlash would be severe. Antitrust issues would be popping up again.

Also worrying about your graphics card being limited to 2048 x 2048 textures is silly as if you are blitting to a screen at that resolution with a texture that big you are going to start running into performance problems fast as you'll be maxing out the data you can push down the bus. Graphics cards these days are not really accelerated for straight 2D work anymore and the trend continues away from this. So you can't do what you formerly could back in the day on Amigas and 486s as well, especially on Mac OS X.

You are right that if you use DrawPixels you have to deal with inverting Y coordinates. If you use the glPixelZoom and glRasterPos2i to correct it it will slow down your blitting. Since I'm doing old school 3d work I just rotate the camera by 180 degrees around the Y axis to account for this when using the DrawPixels blitting method. All the other methods (including the OpenGL texture rectangle method) already keep the Y coordinates the correct direction without any major slowdown.

Lastly OpenGLs non pixel perfect drawing is not a problem. In my code you have a memory buffer that contains pixel perfect copy of the screen. You can use this for collision detection. OpenGL then just uses this buffer to show on the screen, using CopyPixels to pull it back out of OpenGL is not a wise thing to do since you already have the memory buffer (which is effectively a offscreen back buffer) which contains the correct data.

See tricks for the code.
Quote this message in a reply
Apprentice
Posts: 10
Joined: 2005.08
Post: #14
excuse me for the short delay but I had to test everything ...
if nothing else works, I have to go another way, right?
well, OpenGL does the job, so I will keep two renderpaths: CG and OGL..
(as of the 2048x2048 blitting, I just used it for level pre-rendering since the
thing is going to be REALLY fast and don't want to do tiled map construction
to avoid scrolling glitches).

thanks to everyone, really.

just to end this forum, has anyone else noted that capturing tha scren, hiding the mouse
and grabbing the pointer seems to confuse the CGGetLastMouseDelta function?
at least on my Panther it always reports deltas of (0,0)

bye,
Claudio
Quote this message in a reply
Member
Posts: 260
Joined: 2005.05
Post: #15
Oblivion Wrote:Lastly, about OpenGL future ... Apple is a small player here:
If Microsoft decides that OpenGL is dead, OpenGL IS dead. Remember that linux uses Mesa (GL Like). The ARB will dissolve quickly if the OpenGL for windows does not allow for extensions/updates. No ARB no OpenGL. That day, the 68K->PPC->QD3d->OGL->Os9->OsX->x86 migration chain will get a another "Step"... but we have no control over this so let's keep coding.
That's pessimistic. I really hope that is not the future, because what can all non-Microsoft platforms do? License DirectX? I'd rather hope for stronger OpenGL support, with OpenGL ES in mobile devices and straight OpenGL in Sony and Nintendo consoles. (And Sony is a pretty big player.)

But is the conclusion of this thread that there is no way to do VBL sync these days? That can't be true. Retrace.h is dead alright, but surely there must be some way other than the one built into OpenGL?
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  CoreGraphics sucks? OpenGL for 2d? dave05 16 9,601 Jul 1, 2005 12:44 AM
Last Post: Ingemar
  QuickDraw(CopyBits) vs CoreGraphics(CGContextDrawImage) cloke 6 5,752 Aug 7, 2004 03:06 PM
Last Post: arekkusu