Recent

Author Topic: [OpenGL] GLScene  (Read 15494 times)

Caperaven

  • Guest
[OpenGL] GLScene
« on: January 08, 2004, 11:32:51 am »
www.glscene.org / www.caperaven.co.za

GLScene provides RAD OpenGL development in delphi.
It is a great package with a large following.
The site is a bit dormant, but for the real action see the general forum.
(link is on the body page of caperaven.co.za)

The community is realy interested in supporting Freepascal and thus lazarus. This will enable RAD OpenGL development in Win and Lin.
How cool is that.

Any support that the lazarus community could provide in this process would be greatly appreciated and I believe to the benifit of both.

pepecito

  • Full Member
  • ***
  • Posts: 130
    • http://pepecito.zapto.org
[OpenGL] GLScene
« Reply #1 on: March 18, 2004, 04:11:39 pm »
Hi,
I am new here and getting lot of interest about Lazarus.
This about GLScene sounds very interesting!
Anyway I am interested in game development and 3D engines in general and thus with Lazarus too.
Which are ATM the possibilityies of 3D in Lazarus?
Bye,
Pepecito
:: Home Page ::

mattias

  • Administrator
  • Full Member
  • *
  • Posts: 170
    • http://www.lazarus.freepascal.org
gtkglarea
« Reply #2 on: March 19, 2004, 12:27:25 am »
Reimar Grabowski wrote some opengl bindings for linux, I wrote a gtkglarea control, which is a opengl control for the LCL. There is also an example.
This is somewhat linux specific at the moment, but maybe a start.
See also the asmoday project on sourceforge.
AFAIK he is currently writing an 3D editor, which should eventually become a plugin for lazarus.

Lord_ZealoN

  • Full Member
  • ***
  • Posts: 141
    • http://lordzealon.com
[OpenGL] GLScene
« Reply #3 on: May 31, 2004, 02:12:09 pm »
GlScene is GREAT!!

i hope see glscene working with lazarus in windows and linux soon.

EricGrange

  • New Member
  • *
  • Posts: 13
[OpenGL] GLScene
« Reply #4 on: June 04, 2004, 09:23:12 pm »
With current GLScene CVS, LCL release and FPC 1.9.4 there are now two GLScene "teapot' samples that run :)
- an SDL-based viewer (LCL used only for base classes)
- a LCL-based viewer (viewer component in a LCL TForm)

If any LCL guru is listening, there are currently two roadblocks:
- LM_ERASEBKGND isn't honoured (so the viewer component flickers like mad)
- TBitmap has no ScanLine property (so no texture support in LCL, as everything is based around TGraphic and conversion to raster data goes through TBitmap)

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2512
[OpenGL] GLScene
« Reply #5 on: June 09, 2004, 06:19:19 pm »
Quote from: "EricGrange"

If any LCL guru is listening, there are currently two roadblocks:
- LM_ERASEBKGND isn't honoured (so the viewer component flickers like mad)


:?:  What do you mean by "isn't honoured"


Quote

- TBitmap has no ScanLine property (so no texture support in LCL, as everything is based around TGraphic and conversion to raster data goes through TBitmap)


I doubt if TBitmap will ever get a scanline property. This is to win32 specific.
What have Scanlines to do with textures ?
//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

Anonymous

  • Guest
[OpenGL] GLScene
« Reply #6 on: June 09, 2004, 08:14:50 pm »
> What do you mean by "isn't honoured"

The background still gets erased, though the erase bkgnd message handler tells it not to.
This means that when the control gets updated, it is first painted in gray, then painted by OpenGL,
which results in very visible flickering.
Maybe there is another way to achieve that in LCL? (the compiler accepted it, so I assumed it was supposed to be supported)

> I doubt if TBitmap will ever get a scanline property.

ScanLines is just an access to the bitmap as a raster, and unless bitmaps have been assimilated to graphic objects, icons or glyphs in LCL, bitmaps are supposed to be... bitmaps, which are raster images (= rows of arrays of pixel color values/indices).

> What have Scanlines to do with textures ?

That's how you access to a bitmap's raw data in raster fashion (whole line by whole line), instead of accessing them per pixel (which is the only other way to access a bitmap's pixel data, but is obviously very slow).
Textures are defined in a raster fashion, by specifying the color values for all their pixels in a single step. The texture/image loading relies on TGraphic classes to support multiple formats, and the only standard way in which a TGraphic's data can be accessed in a raster fashion in the VCL is by rendering it into a TBitmap, and then accessing the bitmap's ScanLines (pointers to the beginning of rows of pixels).
Other TGraphic classes, such as TJpegImage or TIcon f.i., can maintain their data in whichever way they prefer, like raw jpeg blocks or opaque GDI handles, thus the raster information doesn't exist until the jpeg/icon is rendered into a bitmap.

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2512
[OpenGL] GLScene
« Reply #7 on: June 10, 2004, 11:02:46 am »
Quote from: "Anonymous"
> What do you mean by "isn't honoured"

The background still gets erased, though the erase bkgnd message handler tells it not to.
This means that when the control gets updated, it is first painted in gray, then painted by OpenGL,
which results in very visible flickering.
Maybe there is another way to achieve that in LCL? (the compiler accepted it, so I assumed it was supposed to be supported)


AFAIK it is supported. It might have to do something with double buffered turned on (or off). I'm not sure, I'm not to deep into that area.

Quote

> I doubt if TBitmap will ever get a scanline property.

ScanLines is just an access to the bitmap as a raster, and unless bitmaps have been assimilated to graphic objects, icons or glyphs in LCL, bitmaps are supposed to be... bitmaps, which are raster images (= rows of arrays of pixel color values/indices).


This part I know.

Quote

> What have Scanlines to do with textures ?

That's how you access to a bitmap's raw data in raster fashion (whole line by whole line), instead of accessing them per pixel (which is the only other way to access a bitmap's pixel data, but is obviously very slow).


Bitmaps are win32 native. And so scanlines. Since Lazarus is multiplatfom/widgetset, we dont use bitmaps internally on all interfaces.
For graphic support we rely on fpImage (why reinvent the wheel), which AFAIK it has no scanline support.  
Sure we can emulate scanlines, but the data will be accessed pixel by pixel.

Quote

Textures are defined in a raster fashion, by specifying the color values for all their pixels in a single step. The texture/image loading relies on TGraphic classes to support multiple formats, and the only standard way in which a TGraphic's data can be accessed in a raster fashion in the VCL is by rendering it into a TBitmap, and then accessing the bitmap's ScanLines (pointers to the beginning of rows of pixels).
Other TGraphic classes, such as TJpegImage or TIcon f.i., can maintain their data in whichever way they prefer, like raw jpeg blocks or opaque GDI handles, thus the raster information doesn't exist until the jpeg/icon is rendered into a bitmap.

I've to look at the fpImage implementatios to see if there is a way to access the raw pixel buffer (if it exists)
//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

Anonymous

  • Guest
[OpenGL] GLScene
« Reply #8 on: June 10, 2004, 01:27:43 pm »
> Bitmaps are win32 native

Bitmap as an HBITMAP maybe, but bitmaps are a concept rather than an implementation, and they are not windows specific, f.i. the way textures are specified in OpenGL (which is cross-platform) is as a tightly packed raster bitmap (with no padding between rows of pixel values/indices).

>I've to look at the fpImage implementatios to see if there is a way to access the raw pixel buffer (if it exists)

I don't know fpImage but I would assume rasters are what they use internally, f.i. during format conversion. No idea if they resurface it though.
Otherwise, if fpImage supports streaming, a workaround could be to stream to a BMP file in memory (since the 24/32bits BMP format is essentially a raster bitmap with a small header), or better a RAW 32bits format if supported.
(ScanLines isn't needed as much as a way to access the pixel values as whole)

fatg

  • New Member
  • *
  • Posts: 33
[OpenGL] GLScene
« Reply #9 on: June 11, 2004, 07:24:59 pm »
Writing a bitmap to a stream would add unnecessary additional overhead. I believe there is an access to raw pixel data in every implementation of a bitmap. After all, when the bitmap is drawn, a block of memory is copied to another location. I don't see how could that be win32 specific.

On the side note, a lot of graphical delphi components use ScanLines, because of the speed of access. Without introducing the property, most of these will never be ported to Lazarus, since per pixel access is horribly slow. An example for such code could be Graphics32, a very powerful graphics library that uses ScanLines for most of its operations.

 

TinyPortal © 2005-2018