Hello,

I need to save data stored in memory into .bmp or (which would be the better variant) into .jpg file. Actually what I want to do is to save the OpenGL screen (probably using glReadPixels() function) into image. I've downloaded PasJPEG, but it doesn't seem to be working. When I try to compile example program for PasJPEG, I get: 'Error: Wrong number of parameters specified for call to "error_exit"'

Do you know any efficient way to save glReadPixels into .bmp or .jpeg file? It would be very helpful for me.

I am looking forward for your answers. Thank you even for reading this post. :-)

Jakub Marian

try using fpimage ? packages/fcl-image

Michael.

fpimage doesn't support external image data. One can't tell it "here are the pixels, here is the pallette, go save", one needs to manually convert it first. Moreover it is horribly complex and undocumented (as I found out last weekend. Actually bmpcomn is now documented :-))

And since .bmp format is so simple (close to a memory dump of the pixel info), one can better write convesion code to push it directly to disk, specially if one is somewhat interested in speed.

To make that easier, one could recycle the bmp writer and code though.

A little shameless plug, but I have implemented in my engine exactly what you're looking for. See [http://vrmlengine.sourceforge.net/], in engine sources look in kambi_vrml_game_engine/images/ subdirectory.

Images.pas unit there is used to load/save images to various formats, including .bmp and .jpeg. BMP handling is done in images_bmp.inc file, and JPEG is inside images_jpeg.inc. JPEG support is quite a hack (although works successfully since a long time :) ) --- I use PasJPEG (see KambiPasJpeg unit) to just convert betweeen bmp<->jpeg, this allows me to save/load jpeg files by saving/loading bmp files under the hood.

The image format in the memory is clearly specified, as the main use of this unit is to cooperate with OpenGL (for loading images, textures, saving screenshots etc.). See TImage class comments, basically RawPixels is simply a pointer to an array of Width * Height pixel values, and each descendant of TImage specifies the exact layout of "pixel" --- e.g. for TRGBImage a pixel is just 3 bytes, for red/green/blue.

The way to grab screenshot to TRGBImage is inside
kambi_vrml_game_engine/opengl/glimages.pas unit, see SaveScreen_noflush. Yeah, it's basically just a glReadPixels call, with some safeguarding (setting OpenGL read buffer and pixel store pack parameters).

Hope this will help,
Michalis

Is the latter a hard requirement of OpenGL? In the fpimage rework, I had hoped to skip 24-bit color and use 32-bit for that.

Also, does OpenGL support bottom up (lines other way around in memory) layouts, or only top down?

There is GL_RGBA format, combined with GL_UNSIGNED_BYTE this makes 32 bit pixel (with the last byte for storing alpha --- depending on what you actually do with your image data, you may be able to simply ignore it).

Also, does OpenGL support bottom up (lines other way around in memory) layouts, or only top down?

AFAIK, no. That is, OpenGL images always have the lowest row first in the memory. Everyone simply swaps the rows in memory for OpenGL, since all image formats have this the other way around.

Michalis

Hi,

I'm new to Mac development environment, and I was looking thru the CoreMIDI/MIDIServices.h, to see how much work it's going to take (at least maybe partially) to implement some of the functions to own projects. I hit the wall with some typedef, for example "struct OpaqueMIDIClient * MIDIClientRef", and I now understand that Apple do not always want developers to know what is behind some type definitions. Is this true?

How can one come about this? I'm really open to any suggestions.

Kind regards,
Normann

Yes. This is not Apple-specific, this is a basic way of information hiding which is regularly used in C.

How can one come about this? I'm really open to any suggestions.

You don't need the contents (C programs don't have access to them either). As far as the declaration goes in Pascal, just do something like

type
   POpaqueMIDIClient = ^OpaqueMIDIClient;
   OpaqueMIDIClient = record
   end;
var
   MIDIClientRef: POpaqueMIDIClient;

Or you could even declare MIDIClientRef as a plain untyped pointer (although you'll lose some type checking when using {$t+} in that case).

Jonas

Aditionally you can take a look at my recent work with the opengl Apple bindings for an example of how to do translations:

http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/lcl/interfaces/carbon/opengl.pas?view=markup&revision=14226&root=lazarus

There I just transformed the hidden records into plain pointers.

Thanks, that I can understand. I will give it a go, and see how far I get ;-)

Kind regards

Thanks, I'll look it to that ;-)

As an aside - a lot of why Apple does this in Carbon stems back to the old MacOS 9.x heritage. In the old pre 10,x system, the memory manager forced the programmer to refer to data by "handles" that were references to pointers. This was historical and was originally because of the funky things it did with shuffling pointers around in memory to handle the fact that the early hardware (Mac 128 for example) was only barely able to run the OS within the memory constraints of the hardware. PowerPC might have altered this, dunno, but the basic OS worked on that premise for should have minimised the madness, but I
guess some still persists?

i haven't programmed for years in pascal. i downloaded fpc and played around with it's ide, i was wondering if it has context help like the old borland turbo 7? i tried it and the message returned was regarding downloading a *.htm doc. tried that but couldn't find it to download. what other ide's are fpc users using these days?

tia

I have installed FPC with a DOS emulator for Windows (DOS box). When it's installed that way I get that message to download the help files as you mention, but when it is installed from Windows itself, the help files are included and the context help works.

Anyway I use Lazarus a lot, which is a Delphi-like environment. It allows you to create console and GUI applications.

Regards!
-Marco

2008/2/22, wb :

Hi,

In unix/sysutils.pp on FPC for MacOSX you'll find FileOpen which only supports flags for fmOpenRead, fmOpenWrite, and fmOpenReadWrite.

Function FileOpen (Const FileName : string; Mode : Integer) : Longint;
Var LinuxFlags : longint;
BEGIN
  LinuxFlags:=0;
  Case (Mode and 3) of
    0 : LinuxFlags:=LinuxFlags or O_RdOnly;
    1 : LinuxFlags:=LinuxFlags or O_WrOnly;
    2 : LinuxFlags:=LinuxFlags or O_RdWr;
  end;
  FileOpen:=fpOpen (FileName,LinuxFlags);
  //!! We need to set locking based on Mode !!
end;

Does anybody have experience sharing files on MacOSX and knows which flags goes with fmShareDenyWrite and fmShareDenyNone for fpOpen?

TIA,
Normann