date:20170602

Re: [fpc-pascal] Large file support

2017-06-02 Thread Mattias Gaertner

On Sat, 3 Jun 2017 01:02:35 +0200 (CEST)
mar...@stack.nl (Marco van de Voort) wrote:

> In our previous episode, Mattias Gaertner said:
> > mar...@stack.nl (Marco van de Voort) wrote:
> >   
> > >[...]
> > > {$if not defined(fs32bit)}
> > > off_t= cint64;  { used for file sizes  }
> > > {$else}
> > > off_t= cint;
> > > {$endif}
> > >[...]
> > > Maybe we could clean it out. Why the documentation tool picks the $ELSE
> > > branch I don't know. I grepped, and it didn't seem to find anything in 
> > > fpdoc
> > > or (doc/rtl) makefiles defining it.  
> > 
> > Is this with the 3.1.1 fpdoc?  
> 
> Afaik Michael always works with trunk fpdoc, but of course the 3.0.2 docs
> were generated in march.

The $if support was added recently to pscanner.

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implementing AggPas with PtcGraph

2017-06-02 Thread Stefan V. Pantazi

I literally just sent a reply with the solution. I had to guess the 
width and height were longints. Your message confirmed it. I attached an 
updated version of the test program, the old one had a few typos.


Thank you for your work on the ptcpas, I found it very useful for my 
projects.


On 06/02/2017 08:39 PM, Nikolay Nikolov wrote:



On 05/31/2017 02:51 PM, James Richters wrote:

I was doing some tests with Putpixel and that seems to be a word in
the format of RGBA with 4 bits each.I would think putimage would
use the same format, but I haven't tested that yet.

I'm still a bit confused by putimage, since it only has an X and Y
startpoint, how do you define the height and width of the bitmap?
Getimage() specifies a rectangle, and imagesize() figures out how much
memory you need, but I just don't what defines the size and shape of
the image to putimage.

The structure, used by putimage is as follows:

3 longints (12 bytes):
- image width
- image height
- reserved

followed by width*height 16-bit words. If you're a using a 16-bit color
mode (that's the highest supported - it's a limitation of the graph unit
include files, which ptcgraph reuses from the fpc sources), the color
format is rgb565.

Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
{
  This is a console application demo. It uses the Agg2D object,
  which has a much friendlier API, to do all the drawing.
  The drawing buffer is then displayed in a window using ptcgraph and 16 bit 
RGB565 color format.

  Requires modification of Agg2D object constructor to use the 16 bit RGB565 
color format.
  Uses a GraphBitmapBuffer type that includes contains the width and height of 
the image per the info at this URL:

http://pascal.net.ru/PutImage+(en)
[...]
"BitMap is an untyped parameter that contains the height and width of the 
region, and the bit image that will be put onto the screen."
[...]
}

program console_aggpas_2;

{$mode objfpc}{$H+}

uses
  ptcgraph,
  ptccrt,
  agg_2D,
  agg_basics;

const
  IMAGE_WIDTH = 800;
  IMAGE_HEIGHT = 600;
  RGBA_WIDTH =2; //16bit 565 format
  LINE_COUNT = 30;
  {$IFDEF Unix}
  FontFile = '../../arial.ttf';
  {$ENDIF}
  {$IFDEF Windows}
  FontFile = 'Arial';
  {$ENDIF}

type

TGraphBitmapBuffer=packed record
  width,
  height:   longint;
  data: array[0..2*IMAGE_WIDTH*IMAGE_HEIGHT-1] of byte;
end;

var
  gd,gm : smallint;
  graph_buffer: TGraphBitmapBuffer;

procedure DrawStuff(agg: Agg2D_ptr);
var
  i: Integer;
  x, y, px, py, d: Double;
  c1, c2: Color;
begin
  // draw a full screen graph with grid
  agg^.clearAll(0, 0, 0);
  agg^.lineColor(0, 0, 0, 255);
  agg^.lineWidth(3);
  agg^.rectangle(0, 0, IMAGE_WIDTH, IMAGE_HEIGHT);
  agg^.lineWidth(1);
  agg^.lineColor(0, 155, 0, 255);
  agg^.rectangle(10, 10, 50, 50);
//  agg^.font(fontfile, 16);
  d := IMAGE_WIDTH / LINE_COUNT;
  agg^.lineColor(0, 0, 0, 100);
  agg^.lineWidth(1);
  for i := 1 to LINE_COUNT - 1 do
  begin
x := i * d;
agg^.line(x, 0, x, IMAGE_HEIGHT);
  end;
  for i := 1 to trunc(IMAGE_HEIGHT / d) do
  begin
y := i * d;
agg^.line(0, y, IMAGE_WIDTH, y);
  end;
  x := 0;
  y := IMAGE_HEIGHT / 2;
  px := x;
  py := y;
  agg^.lineColor(255, 0, 0, 200);
  agg^.fillColor(0, 0, 0, 200);
  agg^.lineWidth(1);
  for i := 0 to LINE_COUNT - 1 do
  begin
x := x + d;
y := y + Random(Round(IMAGE_HEIGHT / 3)) - IMAGE_HEIGHT / 6;
if y < 0 then
  y := IMAGE_HEIGHT / 6;
if y >= IMAGE_HEIGHT then
  y := IMAGE_HEIGHT - IMAGE_HEIGHT / 6;
agg^.line(px, py, x, y);
//agg^.text(x, y, char_ptr(IntToStr(i) + ' point'));
px := x;
py := y;
  end;

  // Star shape
  agg^.LineCap(CapRound);
  agg^.LineWidth(5);
  agg^.LineColor($32 ,$cd ,$32 );
  c1.Construct(0, 0 , 255, 200);
  c2.Construct(0, 0, 255, 50);
  agg^.FillLinearGradient(100, 100, 150, 150, c1, c2);
  agg^.Star(100 ,150 ,30 ,70 ,55 ,5 );

  // Draw Arc from 45 degrees to 270 degrees
  agg^.LineColor($4C, $6C, $9C);
  agg^.LineWidth(5 );
  agg^.Arc(300 ,320 ,80 ,50 ,Deg2Rad(45 ) ,Deg2Rad(270 ) );
end;


procedure DrawAndDisplay;
var
  agg: Agg2D_ptr;
begin
//agg draw
  New(agg, Construct);
  agg^.attach(@graph_buffer.data, IMAGE_WIDTH, IMAGE_HEIGHT, -(IMAGE_WIDTH * 
RGBA_WIDTH));
  DrawStuff(agg);
  Dispose(agg, Destruct); // not necessary to keep it after rendering is 
finished

//display on ptc surface
graph_buffer.width:=IMAGE_WIDTH;
graph_buffer.height:=IMAGE_HEIGHT;
  ptcgraph.PutImage(0,0,graph_buffer,NormalPut);
  ptcgraph.Rectangle(10,10,100,100);
  ptcgraph.PieSlice(100,100,0,25,30);
  ptcgraph.OutTextXY(80,80,'It works!');
end;


begin
  gd:=d16Bit;
  gm:=m800x600;
  //Windowtitle:='ptcgraph';
  ptcgraph.Initgraph(gd,gm,'');
  Randomize;
  DrawAndDisplay;
  ReadKey;
end.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] Implementing AggPas with PtcGraph

2017-06-02 Thread Nikolay Nikolov




On 05/31/2017 02:51 PM, James Richters wrote:

I was doing some tests with Putpixel and that seems to be a word in the format 
of RGBA with 4 bits each.I would think putimage would use the same format, 
but I haven't tested that yet.

I'm still a bit confused by putimage, since it only has an X and Y startpoint, 
how do you define the height and width of the bitmap? Getimage() specifies a 
rectangle, and imagesize() figures out how much memory you need, but I just 
don't what defines the size and shape of the image to putimage.

The structure, used by putimage is as follows:

3 longints (12 bytes):
- image width
- image height
- reserved

followed by width*height 16-bit words. If you're a using a 16-bit color 
mode (that's the highest supported - it's a limitation of the graph unit 
include files, which ptcgraph reuses from the fpc sources), the color 
format is rgb565.


Nikolay
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Large file support

2017-06-02 Thread Marco van de Voort

In our previous episode, Mattias Gaertner said:
> mar...@stack.nl (Marco van de Voort) wrote:
> 
> >[...]
> > {$if not defined(fs32bit)}
> > off_t= cint64;  { used for file sizes  }
> > {$else}
> > off_t= cint;
> > {$endif}
> >[...]
> > Maybe we could clean it out. Why the documentation tool picks the $ELSE
> > branch I don't know. I grepped, and it didn't seem to find anything in fpdoc
> > or (doc/rtl) makefiles defining it.
> 
> Is this with the 3.1.1 fpdoc?

Afaik Michael always works with trunk fpdoc, but of course the 3.0.2 docs
were generated in march.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Large file support

2017-06-02 Thread Mattias Gaertner

On Fri, 2 Jun 2017 12:50:57 +0200 (CEST)
mar...@stack.nl (Marco van de Voort) wrote:

>[...]
> {$if not defined(fs32bit)}
> off_t= cint64;  { used for file sizes  }
> {$else}
> off_t= cint;
> {$endif}
>[...]
> Maybe we could clean it out. Why the documentation tool picks the $ELSE
> branch I don't know. I grepped, and it didn't seem to find anything in fpdoc
> or (doc/rtl) makefiles defining it.

Is this with the 3.1.1 fpdoc?

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implementing AggPas with PtcGraph

2017-06-02 Thread James Richters

Thanks for the help. I was able to make a little progress.

>There is another agg unit agg_pixfmt_rgb_packed that seem to have the
>565 format that you need. Add it to the uses list and try to replace the
>pixfmt_rgba32 calls with pixfmt_rgb565. That will make agg use that format.
>The pixfmt_custom_blend_rgba calls may need further hacking too to make things 
>work, however, Agg2D should use a 16 bit format if you use
>pixfmt_rgb565 callse instead of pixfmt_rgba32. You should also set RGBA_Width 
>=2; in your program to reflect the change.

I did as you suggest here and changed my buffer to be an array of words, and I 
am able to get a representation of the image to screen by reading elements of 
the array and using putpixel() to put them on the screen,  however the colors 
are all wrong.  I am wondering if this m_pixformat variable that shows up 
everywhere needs to be set also?   The pixfmt_custom_blend_rgba calls may also 
be the problem with the colors.  There are no corresponding custom blend 
procedures in agg_pixfmt_rgb_packed.

>Anyway, this will probably still not make
>ptcgraph.putimage(0,0,buf[0],0);
No this still does not work, I am able to use a nested loop and putpixel() but 
that is very slow.  I still think something is missing with putimage because I 
don't see how it knows the shape of the image, maybe I need to actually do a 
getimage() at some point to set the shape of before putimage will work.. I'll 
do some experiments with it.  

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Stefan V. Pantazi
Sent: Thursday, June 01, 2017 9:47 AM
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

Have a look at the agg_2D unit. The agg_2D uses ..
  agg_pixfmt ,
  agg_pixfmt_rgba ,
..

Therefore, the rgba format is pretty much baked in. That is to say that the 
constructor of the main object Agg2D uses the pixfmt_rgba32 to set the pixel 
format.

...
{ CONSTRUCT }
constructor Agg2D.Construct;
begin
  m_rbuf.Construct;

  pixfmt_rgba32   (m_pixFormat ,@m_rbuf );
  pixfmt_custom_blend_rgba(m_pixFormatComp ,@m_rbuf ,@comp_op_adaptor_rgba 
,rgba_order );
  pixfmt_rgba32   (m_pixFormatPre ,@m_rbuf );
  pixfmt_custom_blend_rgba(m_pixFormatCompPre ,@m_rbuf ,@comp_op_adaptor_rgba 
,rgba_order ); ...

There is another agg unit agg_pixfmt_rgb_packed that seem to have the
565 format that you need. Add it to the uses list and try to replace the
pixfmt_rgba32 calls with pixfmt_rgb565. That will make agg use that format.

The pixfmt_custom_blend_rgba calls may need further hacking too to make things 
work, however, Agg2D should use a 16 bit format if you use
pixfmt_rgb565 callse instead of pixfmt_rgba32. You should also set RGBA_Width 
=2; in your program to reflect the change.

Anyway, this will probably still not make

ptcgraph.putimage(0,0,buf[0],0);
work, but that may be a ptcgraph problem.

Hope this helps,

Stefan

On 05/31/2017 02:57 PM, James Richters wrote:
>> And AggPas already has support for that pixel format
>
> How do I define that as the format I want?  I've been looking all through the 
> example and do not see how this is defined.  I've attached a test program, 
> it's basically Graeme's sample but going to screen instead of a file.  I just 
> don't see where the pixel format is defined.  I have it kind of working in a 
> funny way by just forcing the existing pixels to conform to the required 
> format.
>
> -Original Message-
> From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On 
> Behalf Of Graeme Geldenhuys
> Sent: Wednesday, May 31, 2017 1:17 PM
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
>
> On 2017-05-31 18:03, Reimar Grabowski wrote:
>>> I'm not sure what that's called
>> RGB565, maybe?
>
> And AggPas already has support for that pixel format.
>
> Regards,
>Graeme
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
>
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Large file support

2017-06-02 Thread Mark Morgan Lloyd


On 02/06/17 11:00, Marco van de Voort wrote:

In our previous episode, Mark Morgan Lloyd said:> > 8 apparently, but off_t is 
documented as a cint32.> > 
https://www.freepascal.org/docs-html/current/rtl/unixtype/off_t.html
The declaration is
{$if not defined(fs32bit)}off_t= cint64;  { used for file sizes 
 }{$else}off_t= cint;{$endif}
The 64bit is active, IIRC the 32-bit is for use with FPC_USE_LIBC for whenthe 
debian oldstable still defined 32-bit as seek (even though even 
somewhatrelevant distros already defined 64-bit).
FPC_USE_LIBC for linux and *bsd still is still hardly used afaik.
Maybe we could clean it out. Why the documentation tool picks the $ELSEbranch I 
don't know. I grepped, and it didn't seem to find anything in fpdocor (doc/rtl) 
makefiles defining it.


Thanks, I'll code defensively.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Large file support

2017-06-02 Thread Marco van de Voort

In our previous episode, Marco van de Voort said:
> 
> FPC_USE_LIBC for linux and *bsd still is still hardly used afaik.
> 
> Maybe we could clean it out. 

These sentences came close together while composing the message, so to be
clear: I didn't mean cleaning out FPC_USE_LIBC, only the fs32bit define(with
only two occurances)

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Large file support

2017-06-02 Thread Marco van de Voort

In our previous episode, Mark Morgan Lloyd said:
> 
> 8 apparently, but off_t is documented as a cint32.
> 
> https://www.freepascal.org/docs-html/current/rtl/unixtype/off_t.html

The declaration is 

{$if not defined(fs32bit)}
off_t= cint64;  { used for file sizes  }
{$else}
off_t= cint;
{$endif}

The 64bit is active, IIRC the 32-bit is for use with FPC_USE_LIBC for when
the debian oldstable still defined 32-bit as seek (even though even somewhat
relevant distros already defined 64-bit).  

FPC_USE_LIBC for linux and *bsd still is still hardly used afaik.

Maybe we could clean it out. Why the documentation tool picks the $ELSE
branch I don't know. I grepped, and it didn't seem to find anything in fpdoc
or (doc/rtl) makefiles defining it.






___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Large file support

2017-06-02 Thread Mark Morgan Lloyd


On 02/06/17 10:00, Marco van de Voort wrote:

In our previous episode, Mark Morgan Lloyd said:> Could I have a reality check 
please: is there no fpLSeek64() for files > larger than 2Gb?
Afaik, there is no such posix calls. In the past, most linux temporarily 
hadsome -64 calls while it left the main calls 32-bit to make 
transitionsmoother, but nowadays it is all 64-bit?
What does writeln(sizeof(off_t));  print ?


8 apparently, but off_t is documented as a cint32.

https://www.freepascal.org/docs-html/current/rtl/unixtype/off_t.html

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Large file support

2017-06-02 Thread Marco van de Voort

In our previous episode, Mark Morgan Lloyd said:
> Could I have a reality check please: is there no fpLSeek64() for files 
> larger than 2Gb?

Afaik, there is no such posix calls. In the past, most linux temporarily had
some -64 calls while it left the main calls 32-bit to make transition
smoother, but nowadays it is all 64-bit?

What does writeln(sizeof(off_t));  print ?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Large file support

2017-06-02 Thread Mark Morgan Lloyd

Could I have a reality check please: is there no fpLSeek64() for files 
larger than 2Gb?


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Large file support

Re: [fpc-pascal] Implementing AggPas with PtcGraph

Re: [fpc-pascal] Implementing AggPas with PtcGraph

Re: [fpc-pascal] Large file support

Re: [fpc-pascal] Large file support

Re: [fpc-pascal] Implementing AggPas with PtcGraph

Re: [fpc-pascal] Large file support

Re: [fpc-pascal] Large file support

Re: [fpc-pascal] Large file support

Re: [fpc-pascal] Large file support

Re: [fpc-pascal] Large file support

[fpc-pascal] Large file support

12 matches

Site Navigation

Mail list logo

Footer information