Hello i ask you how to save a image from OpenGL as jpg?

I draw on TPanel1 in C++Builder6 but i can't save this image. But i can't 
draw on T Image becouse i can't set a DC
hdc = GetDC(Image1->Picture->Bitmap->Handle); not works.

I need answer on quastion:
how to save a image from OpenGL as jpg?
or
how to draw OpenGL on TImage in c++Builder6

Thanks

wowiii wrote:

> Hello i ask you how to save a image from OpenGL as jpg?
> 
> I draw on TPanel1 in C++Builder6 but i can't save this image.
> But i can't draw on T Image becouse i can't set a DC
> hdc = GetDC(Image1->Picture->Bitmap->Handle); not works.
> 
> I need answer on quastion:
> how to save a image from OpenGL as jpg?
> or
> how to draw OpenGL on TImage in c++Builder6

Why so complicated? Use glReadPixels to get the image data and
put it through libjpeg to save it. Or even lazier: Use DevIL's
ilutScreenie function (http://openil.sourceforge.net)

Wolfgang Draxinger
-- 

> Why so complicated? Use glReadPixels to get the image data and
> put it through libjpeg to save it.

Some drivers return black pixels for those areas of the
window which are not on screen or which are overlapped
by other windows.
I decided to render to a DIB before saving/printing.
You fall back to the software implementation, but the
results are much more independent from the driver.
And you are not sticked to the screen resolution.

Uwe Kotyczka wrote:
 
> Some drivers return black pixels for those areas of the
> window which are not on screen or which are overlapped
> by other windows.

Use PBuffers or Framebuffer Objects (they seem to work now,
finally).

> I decided to render to a DIB before saving/printing.

With DIB you don't get Shaders, FSAA, Cube Maps, etc. Just say no
to DIB.

> You fall back to the software implementation, but the
> results are much more independent from the driver.

If you really want to use a SW renderer, then use Mesa (load the
library through glLoadLibrary and get the function addresses
manually so that it doesn't clash with the system's opengl32.dll

> And you are not sticked to the screen resolution.

For that's there is tiled rendering. It's fairly simple: Adjust
the values for left, right, bottom and top clipping planes to
cover multiple tiles of the scene and then join the generated
images.

Wolfgang Draxinger
-- 

Wolfgang Draxinger wrote:
> Uwe Kotyczka wrote:
>  
>> Some drivers return black pixels for those areas of the
>> window which are not on screen or which are overlapped
>> by other windows.
> 
> Use PBuffers or Framebuffer Objects (they seem to work now,
> finally).
> 

pbuffers are almost universal. Framebuffer objects
are only supported on the latest ATI/NVIDIA drivers.

See:

http://www.delphi3d.net/hardware/extsupport.php?extension=WGL_ARB_pbuffer
http://www.delphi3d.net/hardware/extsupport.php?extension=GL_EXT_framebuffer_object




-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again.  They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful.  But it happens
every day.  I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

"fungus" <umailMY@SOCKSartlum.com> wrote in message 
news:U1k8g.22889$un5.8066@news.ono.com...

> pbuffers are almost universal. Framebuffer objects
> are only supported on the latest ATI/NVIDIA drivers.

In sample applications using FBOs, my ATI and NVidia cards
work correctly when running Windows XP.  Those same cards
in the same machine, when running Red Hat Linux with latest
graphics drivers, fail to work.  The reported status is
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENTS_EXT.
This happens on something as simple as render-to-texture.

--
Dave Eberly
http://www.geometrictools.com

Dave Eberly wrote:

> graphics drivers, fail to work.  The reported status is
> GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENTS_EXT.
> This happens on something as simple as render-to-texture.

That's what I meant with "seems to work". It's really a shame,
that driver developers don't focus on FBOs; in theory they're
much easier to use and a lot more flexible than PBuffers.

Wolfgang Draxinger
-- 

"Wolfgang Draxinger" <wdraxinger@darkstargames.de> wrote in message 
news:ni0aj3-gva.ln1@darkstargames.dnsalias.net...

> That's what I meant with "seems to work". It's really a shame,
> that driver developers don't focus on FBOs; in theory they're
> much easier to use and a lot more flexible than PBuffers.

It is possible that I am not doing everything I need to
make this work--and that on a Windows box I get lucky.
But I've read as much as I can about FBOs, so I thought
I was doing what needs to be done and I don't know why
they are not working under Linux.  The sad thing is that I
need to keep PBuffers as a fallback when the FBO creation
fails.  I like not having to worry about platform-specific
creation :)

--
Dave Eberly
http://www.geometrictools.com