subject:"\[fpc\-pascal\] Implementing AggPas with PtcGraph"

On 06/22/2017 02:42 AM, Nikolay Nikolov wrote:

On 06/22/2017 01:21 AM, James Richters wrote:
putimage can be accelerated, although it would still have to do a
memory copy.

Like this?
https://github.com/Zaaphod/ptcpas/compare/Zaaphod_Custom?expand=1#diff-fb31461e009ff29fda5c35c5115978b4

This is amazingly faster. I ran a test of just ptcgraph.putimage()
in a loop, putting the same image over and over 1000 times and timing
it. The original ptcgraph.putimage() took 18.017 seconds. After I
applied this, the same loop took 1.056 seconds. Quite an
improvement!It's still nowhere near as fast as just drawing stuff
with ptcgraph directly, but for doing a memory copy of the entire
screen, it's very fast

Yes, that's a good start. That was exactly what I meant :)

I have an idea on how I could speed it up even further
If I set up a second array with 1 bit per pixel, then (somehow)
aggpas could set bits in this array to 1 whenever it changed a
corresponding bit. Now by analyzing the 'pixel changed' array one
word at a time, (or maybe longword or qword at a time) I could just
skip over all the words that =0 and when I come across a word that <>
0 I could do a binary search of that word to only change the pixels
that need to be changed. If very little on the screen has changed,
this would be quite a bit faster because the pixel changed array
would be 1/16 the size of the full buffer.

The only way this would be of any benefit though is if aggpas set the
bits in the 'pixel changed' array while it was changing the pixels of
the buffer, because at that time it already has the array position
and the fact that something changed available. If I had to analyze
the buffer separately and create the 'pixels changed' array, it would
take too long.
That sounds like a little bit of a special case - it'll work where
you're using putimage for a large area, that has very few pixels set.
Perhaps just reimplementing the general algorithm in inline asm, by
using SSE (or MMX) vector instructions would be the fastest, but maybe
it's not worth the pain and the pascal implementation is fast enough
for you. Just experiment and see what works best :)
Btw, I looked at your code again and saw a quick and cheap optimization
- just move the case statement (case BitBlt of) outside the inner loop
(for i:=X to X1 do), so the value of BitBlt is not checked once every
pixel, but once per row.

Nikolay
___
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

On 06/22/2017 01:21 AM, James Richters wrote:

putimage can be accelerated, although it would still have to do a memory copy.

Like this?
https://github.com/Zaaphod/ptcpas/compare/Zaaphod_Custom?expand=1#diff-fb31461e009ff29fda5c35c5115978b4

This is amazingly faster. I ran a test of just ptcgraph.putimage() in a loop,
putting the same image over and over 1000 times and timing it. The original
ptcgraph.putimage() took 18.017 seconds. After I applied this, the same loop
took 1.056 seconds. Quite an improvement!It's still nowhere near as fast
as just drawing stuff with ptcgraph directly, but for doing a memory copy of
the entire screen, it's very fast

Yes, that's a good start. That was exactly what I meant :)

I have an idea on how I could speed it up even further
If I set up a second array with 1 bit per pixel, then (somehow) aggpas could set bits
in this array to 1 whenever it changed a corresponding bit. Now by analyzing the
'pixel changed' array one word at a time, (or maybe longword or qword at a time) I
could just skip over all the words that =0 and when I come across a word that
<> 0 I could do a binary search of that word to only change the pixels that
need to be changed. If very little on the screen has changed, this would be quite a
bit faster because the pixel changed array would be 1/16 the size of the full buffer.

The only way this would be of any benefit though is if aggpas set the bits in
the 'pixel changed' array while it was changing the pixels of the buffer,
because at that time it already has the array position and the fact that
something changed available. If I had to analyze the buffer separately and
create the 'pixels changed' array, it would take too long.
That sounds like a little bit of a special case - it'll work where
you're using putimage for a large area, that has very few pixels set.
Perhaps just reimplementing the general algorithm in inline asm, by
using SSE (or MMX) vector instructions would be the fastest, but maybe
it's not worth the pain and the pascal implementation is fast enough for
you. Just experiment and see what works best :)

Nikolay
___
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

>putimage can be accelerated, although it would still have to do a memory copy.

Like this?
https://github.com/Zaaphod/ptcpas/compare/Zaaphod_Custom?expand=1#diff-fb31461e009ff29fda5c35c5115978b4

This is amazingly faster. I ran a test of just ptcgraph.putimage() in a loop,
putting the same image over and over 1000 times and timing it. The original
ptcgraph.putimage() took 18.017 seconds. After I applied this, the same loop
took 1.056 seconds. Quite an improvement!It's still nowhere near as fast
as just drawing stuff with ptcgraph directly, but for doing a memory copy of
the entire screen, it's very fast

I have an idea on how I could speed it up even further
If I set up a second array with 1 bit per pixel, then (somehow) aggpas could
set bits in this array to 1 whenever it changed a corresponding bit. Now by
analyzing the 'pixel changed' array one word at a time, (or maybe longword or
qword at a time) I could just skip over all the words that =0 and when I come
across a word that <> 0 I could do a binary search of that word to only
change the pixels that need to be changed. If very little on the screen has
changed, this would be quite a bit faster because the pixel changed array would
be 1/16 the size of the full buffer.

James

___
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




On 06/21/2017 10:27 PM, James Richters wrote:

I was trying to find putimage to see how it worked...  and I came across some 
notes about it in graph.inc as follows:
{ For significant speed improvements , is is recommended }
{ that these routines be hooked (otherwise the default,  }
{ slower routines will be used) :}
..
{   PutImage()   }
..

what does 'these routines be hooked'  mean?  Is that something I should be 
doing in my program or something that is already done internally with ptcgraph?
Something to be done in the ptcgraph sources, so that putimage becomes 
faster.


Nikolay
___
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

I was trying to find putimage to see how it worked...  and I came across some 
notes about it in graph.inc as follows:
{ For significant speed improvements , is is recommended }  
{ that these routines be hooked (otherwise the default,  }
{ slower routines will be used) :}
..
{   PutImage()   }
..

what does 'these routines be hooked'  mean?  Is that something I should be 
doing in my program or something that is already done internally with ptcgraph?


___
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




On 06/21/2017 08:05 PM, James Richters wrote:

Is there a more direct way of getting aggpas to send its output to ptcgraph?   
Currently I'm doing as in the demo programs and defining an array then using 
putimage() to transfer the array to ptcgraph... this is fairly slow, especially 
for fullscreen high resolution applications.   I'm trying to follow through 
some of the demos included with ptcpas and it seems they do something like:

{ lock surface pixels }
pixels := surface.lock;

Then using a pointer defined by pixels, the program makes changes to all the 
pixels, then

{ unlock surface }
surface.unlock;
and
{ copy surface to console }
  surface.copy(console, area, area);

send the changes to the screen.   I'm wondering if I can have aggpas work with 
the ptcgraph buffer directly, and maybe this would be more efficient than 
putimage()

Any ideas?
It's more complicated than that, because ptcgraph does all these 
operations in a separate thread. See the sources for ptcgraph and for 
the ptcwrapper unit. However, putimage can be accelerated, although it 
would still have to do a memory copy. This can be done, by implementing 
and adding a PutImage procedure in the TModeInfo record, which is filled 
in, during initialization. See the QueryAdapterInfo function in the 
ptcgraph.pp. It does a series of:


InitMode(graphmode);
with graphmode do
begin
  ...
end;

And inside the 'with' statement, various procedure variables are set. 
There, a PutImage routine can be added as well. Look at e.g. 
ptc_putpixelproc_16bpp to see how the surface is locked and how the 
actual drawing to the surface is done, inside ptcgraph.


Nikolay
___
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

Is there a more direct way of getting aggpas to send its output to ptcgraph?   
Currently I'm doing as in the demo programs and defining an array then using 
putimage() to transfer the array to ptcgraph... this is fairly slow, especially 
for fullscreen high resolution applications.   I'm trying to follow through 
some of the demos included with ptcpas and it seems they do something like:

{ lock surface pixels }
pixels := surface.lock;

Then using a pointer defined by pixels, the program makes changes to all the 
pixels, then

{ unlock surface }
surface.unlock;
and
{ copy surface to console }
 surface.copy(console, area, area);

send the changes to the screen.   I'm wondering if I can have aggpas work with 
the ptcgraph buffer directly, and maybe this would be more efficient than 
putimage()

Any ideas?

James

  

___
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

>The 2 part directory names is because other Canvas renderers will and 
>can be added to fpGUI. 

Yes the directory structure makes more sense if there will be other 
rendering options and render/aggpas/ also makes more sense than 
render/software for the same reason.


___
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-20 Thread Graeme Geldenhuys


On 2017-06-20 11:17, James Richters wrote:

That will be a great help.   Might I suggest mentioning the existence
and use of Agg2D in agg_2D and vice versa?  Something like:


Ah yes, I forgot about that. I'll add it now.



I also think you have made enough changes to it to warrant version
number changes.


After moving AggPas into the fpGUI repository, I don't consider it a 
separate "project" as such - even though it can still be used 
independent from fpGUI. So the original AggPas version numbering is of 
no concern to me any more, it will now follow the versions of fpGUI itself.


The unit header comment does mention that I forked it from the original 
2.4 RM3 AggPas, but that things diverged from there.




I'm also strongly considering renaming the "render/software/"
directory to "render/aggpas/". I'll mull this over for another day
or two.


I like the proposed directory name.  I wonder if it really needs 2
directories, why not just render-aggpas/ or aggpas-render/  ?


The 2 part directory names is because other Canvas renderers will and 
can be added to fpGUI. eg: Locally I already have a user contributed 
Cairo canvas renderer which lives in the "render/cairo/" directory, but 
has not been made public yet in the Github/SourceForge repositories. 
This is also why I think I should rename the "render/software/" 
directory to "render/aggpas/" - it makes things much clearer.


I'm also thinking of refactoring the X11 and GDI canvas rendering code, 
so they too live in the "render/*" directory hierarchy.


I also know of a user that is working on a OpenGL renderer for fpGUI.



Since there are going to be changes that require adjustments anyway,
I wonder if it would make sense to just make agg_2D always require
the pixel format in the constructor:

constructor Agg2D.Construct_PF(pixfmt:define_pixfmt);

It seems the original intention of aggpas was to have this
flexibility but somewhere along the way things like rgba ended up
getting hard coded into it.


A very good point. I'll make a note to commit those changes too.



Better off to just fix it then fix any programs as needed instead of
having an even bigger and more confusing mess that no one will
remember why it's like that in 5 years.


Exactly!



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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-19 Thread Graeme Geldenhuys


On 2017-06-19 01:35, James Richters wrote:

The problem is not with rendering with rgb565,  the problem is something in the 
original that was patched with the setcolor function:

Line 122 of agg_color pas has:
constructor rgba8.Construct;
begin
 b{*}:=int8u(r_ );
 g:=int8u(g_ );
 r:=int8u(b_ );
 a:=int8u(a_ );

end;



WOW, well spotted - and how that went unnoticed for all these years is 
beyond me. Well done for bringing it to our attention.


That is a fundamental bug in AggPas, and something I'll be fixing 
immediately in fpGUI's repository. As for the affects on other code and 
programs. I'll do some testing to see what exact affect it has, and then 
add some notes in the CHANGELOG document describing code-breaking 
changes and recommended fixes.


I have always been in the mind that fundamental code and API's should be 
100% correct, and fixed promptly when a bug is found. Applications that 
are affected by such changes need to be updated - that's the bottom 
line. No point in continue maintaining buggy code and API's and 
guaranteed that things will just get worse in the future - if not 
immediately fixed.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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-19 Thread Graeme Geldenhuys


On 2017-06-16 01:51, James Richters wrote:

Yeah, probably not the best naming convention.

>

Perhaps some comments at the top of both units explaining the
difference and also mentioning the other unit exits would save some
confusion



I have applied such a change. So far only to the Agg2D and agg_2D units, 
but I'll do the same to the rest of the units shortly.


I'm also strongly considering renaming the "render/software/" directory 
to "render/aggpas/". I'll mull this over for another day or two.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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-18 Thread Stefan V. Pantazi


Good find and great sleuth work.

It is possible that the original reason for switching R and B channels 
was to make the agg color object more compatible with LCL which seems to 
prefer BGR, order, but who knows... One obvious problem seems to be


function AggToLCLColor(const c: TAggColor): TColor;

in Agg_LCL, that relies for conversion on RGBToColor in the Graphics unit.

function RGBToColor(R, G, B: Byte): TColor;
begin
  Result := (B shl 16) or (G shl 8) or R;
end;

Anyway, a quick search of the agg source code shows that the rgba8 
object is used only by a handful of units directly. Most agg units and 
demos use the more complicated aggclr object to represent color. I tried 
a few demos and seem unaffected by your fix. This explains why the bug 
was only clearly visible in your case, most of the other agg demos seem 
indiferent to the bug. On the other hand, besides agg_2D there are 
agg_fpimage, Agg2D (the one that integrates with LCL) that also use the 
rgba8 (through the TAggColor alias) and are clearly affected by the R 
and B swap when using canvas methods that involve the TAggColor object 
(e.g., AggClearAll, AggClearClipBox, etc). These would need to be 
updated as well. As an example, after your fix, the call 
canvas.AggClearAll(255,0,0) to TAggFPCanvas.AggClearAll(const r ,g ,b : 
byte; a : byte = 255 ) produces a blue background, which is clearly wrong.


On 06/18/2017 08:35 PM, James Richters wrote:



I finally partially figured out the red / blue color problem.
After single stepping through tons of the aggpas code for hours (it's quite 
complicated even to draw a line) with a sample program that just made a red 
line at the top, I discovered that it's actually doing everything exactly 
correct!   The problem is not with rendering with rgb565,  the problem is 
something in the original that was patched with the setcolor function:

Line 122 of agg_color pas has:
constructor rgba8.Construct;
begin
 b{*}:=int8u(r_ );
 g:=int8u(g_ );
 r:=int8u(b_ );
 a:=int8u(a_ );

end;

This switches red and blue... if I correct it to:
constructor rgba8.Construct;
begin
 b{*}:=int8u(b_ );
 g:=int8u(g_ );
 r:=int8u(r_ );
 a:=int8u(a_ );

end;

now my colors with rgb565 are correct. Since this is no logical reason to 
make b:=R_ and r:=B_ it seems more likely that with the rgba format somewhere 
along the way someone got lazy and just switched red and blue instead of fixing 
the pixelformat.


___
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-18 Thread James Richters

>When you use the Windows GDI font engine, you don't have to specify the 
>location of the font - that is done for you in the font engine.
> Also you specify the font name like windows programs do, you don't specify 
> the font filename.

Thank you the information

I finally partially figured out the red / blue color problem.   
After single stepping through tons of the aggpas code for hours (it's quite 
complicated even to draw a line) with a sample program that just made a red 
line at the top, I discovered that it's actually doing everything exactly 
correct!   The problem is not with rendering with rgb565,  the problem is 
something in the original that was patched with the setcolor function:

Line 122 of agg_color pas has:
constructor rgba8.Construct;
begin
 b{*}:=int8u(r_ );
 g:=int8u(g_ );
 r:=int8u(b_ );
 a:=int8u(a_ );

end;

This switches red and blue... if I correct it to:
constructor rgba8.Construct;
begin
 b{*}:=int8u(b_ );
 g:=int8u(g_ );
 r:=int8u(r_ );
 a:=int8u(a_ );

end;

now my colors with rgb565 are correct. Since this is no logical reason to 
make b:=R_ and r:=B_ it seems more likely that with the rgba format somewhere 
along the way someone got lazy and just switched red and blue instead of fixing 
the pixelformat.

It became obvious that the original was the thing that was backwards, not the 
RGB565 patch because I kept stepping through things like:
constructor aggclr.Construct(rgba : rgba8 );
begin
 v:=(rgba.r * 77 + rgba.g * 150 + rgba.b * 29 ) shr 8;
 r:=rgba.r;
 g:=rgba.g;
 b:=rgba.b;
 a:=rgba.a;

end;
When I evaluated the variables 
R=0
G=0
B=255
A=255

But I defined a RED line, not a blue one.  

I used 
agg^.lineColor($FF, 0, 0, 255);

and according to:

procedure Agg2D.lineColor(r ,g ,b : unsigned; a : unsigned = 255 );
var
 clr : Color;

begin
 clr.Construct(r ,g ,b ,a );
 lineColor(clr );

end;

This should be red.

Every other function or procedure I came across with elements for red, green 
and blue kept coming up like this, so technically are incorrect.   Where the 
inconsistency come from to fix it properly.  For now I just made a compiler 
directive {$DEFINE AGG2D_USE_RGB565 } and use it to fix things in both agg_2D 
and agg_color.

I've committed these to a custom branch on my github fork of fpGUI at:
https://github.com/Zaaphod/fpGUI/tree/Zaaphod_Custom

I looked at the file history  in fpGUI and it looks like red and blue have been 
reversed like this since the initial import of aggpas into fpGUI,  when I look 
at the original example agg2dconsole.dpr, it has in it:
  c.red := getBufItemAsWord(2);
  c.green := getBufItemAsWord(1);
  c.blue := getBufItemAsWord(0);
  c.alpha := getBufItemAsWord(3);

but it should have been 

  c.red := getBufItemAsWord(0);
  c.green := getBufItemAsWord(1);
  c.blue := getBufItemAsWord(2);
  c.alpha := getBufItemAsWord(3);

and would have been if constructor rgba8.Construct; was correct... instead it 
was just re-reversed to compensate for the error in agg_color.pas.   My point 
here is that it may be too late to just correct it now, because then everyone 
who has programs that already 'fix' the problem will then all be wrong, so I'm 
not sure what the best way to fix this is.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Sunday, June 18, 2017 12:32 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

On 2017-06-16 18:49, James Richters wrote:
> agg^.Font('C:\Windows\Fonts\ConsolaB.ttf' ,45 ) works fine, but as I  
> mentioned I can't be sure windows is installed in C:\Windows 

When you use the Windows GDI font engine, you don't have to specify the 
location of the font - that is done for you in the font engine. Also you 
specify the font name like windows programs do, you don't specify the font 
filename.

For example:

   agg^.LineWidth(1);
   agg^.Font('Consola' ,45, True); // Bold
   agg^.Text(300 ,100 ,'Consola font here.' );
   agg^.Font('Courier New' ,45, False, True );  // Italics
   agg^.Text(300 ,150 ,'Courier New font here.' );

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal 
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp 
___
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] Implementing AggPas with PtcGraph

2017-06-18 Thread Graeme Geldenhuys


On 2017-06-16 18:49, James Richters wrote:

agg^.Font('C:\Windows\Fonts\ConsolaB.ttf' ,45 )
works fine, but as I mentioned I can't be sure windows is installed in 
C:\Windows


When you use the Windows GDI font engine, you don't have to specify the 
location of the font - that is done for you in the font engine. Also you 
specify the font name like windows programs do, you don't specify the 
font filename.


For example:

  agg^.LineWidth(1);
  agg^.Font('Consola' ,45, True); // Bold
  agg^.Text(300 ,100 ,'Consola font here.' );
  agg^.Font('Courier New' ,45, False, True );  // Italics
  agg^.Text(300 ,150 ,'Courier New font here.' );


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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-16 Thread James Richters

>You may be able to use CSIDL_FONTS or FOLDERID_Fonts as well.

 

Thank you for pointing me in the right direction.   I was able to get 
CSIDL_FONTS to work.  Getting the actual fonts folder is a better idea than 
assuming it’s in a \Fonts directory

 

I found an example on how to obtain the path from here:

http://wiki.lazarus.freepascal.org/Windows_Programming_Tips 

under “Getting special folders (My documents, Desktop, local application data, 
etc)”

 

Here is how I was able to get it to work.  I’m wondering if there is a better 
way to define my variables. I tried just making Font2Use a string but it didn’t 
compile;

 

Uses

  shlobj,

..

Var

  Font2Use,FontPath: Array[0..MaxPathLen] of Char; //Allocate memory

..

   SHGetSpecialFolderPath(0,FontPath,CSIDL_FONTS,false);

   writeln('Fonts: ' + FontPath);

   font2use:=FontPath+'\segoescb.ttf';

   Writeln(Font2use);

   agg^.Font(font2use ,45 );

..

 

 

James

___
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-16 Thread DaWorm

On Fri, Jun 16, 2017 at 1:49 PM, James Richters <
ja...@productionautomation.net> wrote:

>
> I would like to do something like:
> agg^.Font('%windir%\Fonts\ConsolaB.ttf' ,45 );
>
>
You should be able to use SHGetFolderPath() with CSIDL_WINDOWS.  Not sure
you can always count on Fonts being a subfolder of that, though.

https://msdn.microsoft.com/en-us/library/windows/desktop/bb762181(v=vs.85).aspx

You may be able to use CSIDL_FONTS or FOLDERID_Fonts as well.

https://msdn.microsoft.com/en-us/library/windows/desktop/bb762494(v=vs.85).aspx

Not sure if any are defined in FPC, but should be easy to create/import if
not.

Jeff.
___
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-16 Thread James Richters

I've been able to use windows fonts with aggpas with the following code:
 
   agg^.Font('ConsolaB.ttf' ,45 );
   agg^.Text(300 ,100 ,'Text Here' );

and it works fine if I copy the font to the same folder as my program.  I'm 
wondering how I can just use standard windows fonts without copying them... but 
not assuming windows is installed in c:\windows

agg^.Font('C:\Windows\Fonts\ConsolaB.ttf' ,45 )
works fine, but as I mentioned I can't be sure windows is installed in 
C:\Windows

I would like to do something like: 
agg^.Font('%windir%\Fonts\ConsolaB.ttf' ,45 );

but of course that won't work because the %windir% variable only works in batch 
files.   

Is there some other way I can capture the install directory of windows, or the 
system so I can make this work properly?


Also, while I was tinkering with this,  I also wanted to see what differences 
there are between Freetype and Windows True Type fonts, and I noticed something 
odd.. 
If I compile with {$DEFINE AGG2D_USE_FREETYPE }  it works fine... but if I 
compile with it commented out,  it does work, and I get text on the screen, but 
the font is not the one I selected.  It seems to be a default font that I can't 
change. Does the font need to be defined differently if using Win32 TT font 
engine?I am using the current 'develop' branch of fpGUI version of aggpas 
now.  I have not tried it with the release version.

I'm also wondering if there is a way to specify the font by the name used by 
windows applications, or is that more complicated than it is really worth?

James



___
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

>I use Git for just about any source code I work with. 
I've just recently started using GIT, and have been using it for my own 
applications.  My solution until now has been to duplicate any units that 
needed modification in with my source code so it would show up in my GIT 
repository.  But I like the idea of just maintain my own local copy and put a 
custom branch that I can keep maintained easier.. and who knows maybe I'll come 
up with something worth submitting to the project.

>We all love a mystery. ;-)
Especially once it's solved 

>Yeah, probably not the best naming convention.
Perhaps some comments at the top of both units explaining the difference and 
also mentioning the other unit exits would save some confusion

>The agg_2D.pas unit is a 100% non-GUI unit. It is meant for console or 
>web (eg: CGI) style applications. No GUI toolkit dependencies are required.

Sound like I was using the correct unit anyway for my console apps

James

___
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-15 Thread Stefan V. Pantazi

I was waiting for the right time to also offer my sincere thanks to all 
teams and individual contributors. I have been using fpc and Lazarus IDE 
for quite some years now and I am very pleased with the constant 
progress and improvement of these development tools. I have enjoyed 
reading and learned a lot on these mailing lists as well. My hope is 
that contributions continue for many years to come and that the 
community remains helpful as it has always been.


Stefan



Also when looking through the fpGUI as well as the Freepascal repositories,  
there are just thousands of commits.  looking at all those commits gives a real 
appreciation for the amount of work that has gone into the project.   So a huge 
thank you goes out to everyone who has worked so hard to make freepascal as 
awesome as it is, as well as the people who are such a tremendous help on this 
list.   Honestly if not for FreePascal, I would still be trying to put together 
Pentium 233 computers to run my old DOS applications on. (not fun, components 
are getting hard even to find on ebay now)   I just don't have time to do a 
massive re-write all at once, and FreePascal let me drop in my Turbo Pascal 
programs and pretty much just run them.

James


___
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


On 2017-06-15 22:17, James Richters wrote:

I specifically looked for agg_2d.pas (which is the one I was using)
I found that it also was fixed, but only 11 months ago... after 1.4.1
was released.


Yes, that's my bad. The agg_2d.pas unit was lagging behind for a while, 
because I never really used it until about 12-18 months ago.




So mystery solved... but.


We all love a mystery. ;-)



It raises a new question... What is the difference between agg2D.pas
and agg_2D.pas and which one do I want to be using?


Yeah, probably not the best naming convention.

The agg_2D.pas unit is a 100% non-GUI unit. It is meant for console or 
web (eg: CGI) style applications. No GUI toolkit dependencies are required.


The "agg2D.pas" unit depends on fpGUI Toolkit, because it implements a 
fpGUI Canvas that uses AggPas for all it's 2D drawing routines. So it's 
a descendant of TfpgCanvasBase (a fpGUI class).




Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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


On 2017-06-15 15:06, James Richters wrote:

I don't like modifying units that are part of a package
because then I would need to remember how I modified them when a new
version is released or have to figure out what's going on all over
again.


I use Git for just about any source code I work with. I even let Git 
manage a SubVersion repository. I also often have my own "custom 
changes" in 3rd party code. With Git I simply create a "custom-mods" 
branch where I commit all my personal preferences. As the 3rd party code 
moves forward, I can move my whole "custom-mods" branch forward to by 
using the Git command "rebase". It's very little effort, and I have 
dragged some of my custom-mods branches forward since around 2010 (in 
various 3rd party code).




3) Make sure you always rebuild the unit depending on the program
you want to compile (Compile -> Build).

Is there a way to force this with the command line?


Yes.  The -B compiler command line parameter.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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


On 2017-06-15 13:34, Tomas Hajny wrote:

Not quite - the text-mode IDE doesn't invoke fpc.exe binary (it has the
compiler built-in) and it passes the options as defined in the respective
IDE dialogs.



Thanks Tomas for correcting me. I wasn't 100% sure about the behaviour 
of a compiled-in compiler.



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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

>And if you look in the "develop" branch of fpGUI, there is an even later 
>AggPas version - last updated a month ago

I downloaded the fpGUI repository to have a look at it, and thought I would see 
if any of the things I was encountering with it were addressed yet.   Sure 
enough, I found

{$IFDEF AGG2D_USE_FREETYPE}
  {$UNDEF AGG2D_USE_WINFONTS}
{$ENDIF}

Already there,  actually formatted exactly the way I did to get it to compile.  
So I went back in the history of the file to see when that was added, and I 
found it 4 years ago!
This was really puzzling because I had to fix the version included with fpGUI 
1.4.1 which was from 2015.  

Well looking more closely, I discovered there are 2 units... agg2D.pas and 
agg_2D.pas.   well agg2D.pas is all the way at the bottom of all the agg_* 
units so I never knew it was there so when I specifically looked for 
agg_2d.pas (which is the one I was using)  I found that it also was fixed, but 
only 11 months ago... after 1.4.1 was released.  

So mystery solved... but.

It raises a new question... 
What is the difference between agg2D.pas and agg_2D.pas and which one do I want 
to be using?  

Also when looking through the fpGUI as well as the Freepascal repositories,  
there are just thousands of commits.  looking at all those commits gives a real 
appreciation for the amount of work that has gone into the project.   So a huge 
thank you goes out to everyone who has worked so hard to make freepascal as 
awesome as it is, as well as the people who are such a tremendous help on this 
list.   Honestly if not for FreePascal, I would still be trying to put together 
Pentium 233 computers to run my old DOS applications on. (not fun, components 
are getting hard even to find on ebay now)   I just don't have time to do a 
massive re-write all at once, and FreePascal let me drop in my Turbo Pascal 
programs and pretty much just run them.   

James

___
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-15 Thread Tomas Hajny

On Thu, June 15, 2017 16:06, James Richters wrote:
 .
 .
>> 3) Make sure you always rebuild the unit depending on the program you
>> want to compile (Compile -> Build).
>
> Is there a way to force this with the command line? (same as Compile >
> build from the IDE) ?

Yes, of course - it's the option '-B'.


 .
 .
> Oh, I see the issue here.   So If I were to write a unit that I wanted
> Programs to share, but have various options, I may be better off to define
> a variable in the unit and let the programs change the variable depending
> on what they want with the compiler directives, it's actually leaving
> out parts altogether, so you need to re-compile the unit if you want to
> change it... makes smaller files than always including things you don't
> want to use.
 .
 .

Yes, exactly (plus there are some more reasons, like that you want to
reduce unneeded dependencies which may not be fulfilled, etc.).

Tomas


___
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

Thanks everyone for explaining this,  and thanks for the various solutions.  I 
don't like modifying units that are part of a package because then I would need 
to remember how I modified them when a new version is released or have to 
figure out what's going on all over again.  

> 3) Make sure you always rebuild the unit depending on the program you want to 
> compile (Compile -> Build).

Is there a way to force this with the command line? (same as Compile > build 
from the IDE) ?

>Defines have impact only when compiling the particular source code. Having a 
>'global define' in a program could never have impact to a unit which might be 
>already compiled using different defines at the moment the particular program 
>is compiled. 

Oh, I see the issue here.   So If I were to write a unit that I wanted Programs 
to share, but have various options, I may be better off to define a variable in 
the unit and let the programs change the variable depending on what they 
want with the compiler directives, it's actually leaving out parts 
altogether, so you need to re-compile the unit if you want to change it... 
makes smaller files than always including things you don't want to use. 

>Yes, projects are 'a Lazarus thing'. However, you can achieve a similar effect 
>with local options and configuration files for the text-mode IDE (you just 
>need to use different directories for different 'projects').
Using directories sounds easy enough.  

>Alternatively you can pass @your.cfg to add a config.
That's good to know, and could be useful!   Since fp gets constantly re-saved 
when the IDE closes, it's possible that custom settings could be forgotten 
about and overwritten to not be there anymore.  Using a custom cfg with this 
method would allow the changes to be kept separate and be a more obvious 
reminder that they need to happen.  Can I add the custom config into the IDE 
someplace? 

James

___
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-15 Thread Mattias Gaertner

On Thu, 15 Jun 2017 07:57:14 -0400
"James Richters"  wrote:

> >The idea is that you have one project per program. You can compile them 
> >randomly without changing anything.  
> 
> I don't understand what you mean by 'one project per program' ?

Project is a Lazarus/msegui thing.

> I only have programs that I have sorted in sub directories.  I normally use 
> the Freepascal text IDE to compile them, and sometimes the command line.   I 
> might want to have ProgramA.pas have one define and ProgramB.pas have 
> another, both using the same unit, is there some method to do that?

Yes, via the fpc.cfg, via @your.cfg, via include files, via FPC IDE
config or by tools like Lazarus, msegui, make, etc.

> >There are already many ways to add defines. Adding another one would make it 
> >harder for newbies.  
> Is there some method to make a global define that is in the program itself?   
> I don't see how having options available makes anything harder for anyone, 
> they can just not use such features.

If someone else tries to understand your program he has to learn
your way. Too many options for the same thing can be a burden.
Especially when trying to find out why a macro was not defined.

>[...]
> Thanks for explaining that.  It looks like I can define where my units are 
> with fpc.cfg as well and then I won't need to keep putting them on the 
> command line.   If I put an fpc.cfg in a specific directory along with my 
> program to be compiled, will the one in that directory override the one in 
> \FPC\3.0.2\bin\i386-win32 ?

fpc takes the first it finds. You can see where fpc searches for configs using 
the -vt flag.
Alternatively you can pass @your.cfg to add a config.

> I'm wondering if I am missing something with reference to 'projects' is that 
> a Lazarus thing?   How are 'projects' defined?

Many IDEs have "projects". Lazarus too. They contain build options and
other stuff. The FPC IDE does not call it "project", but its
local fpc.cfg, fp.ini and fp.dsk files have a similar purpose.

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-15 Thread Tomas Hajny

On Thu, June 15, 2017 13:57, James Richters wrote:
>>The idea is that you have one project per program. You can compile them
>> randomly without changing anything.
>
> I don't understand what you mean by 'one project per program' ?  I only
> have programs that I have sorted in sub directories.  I normally use the
> Freepascal text IDE to compile them, and sometimes the command line.   I
> might want to have ProgramA.pas have one define and ProgramB.pas have
> another, both using the same unit, is there some method to do that?

Yes:

1) Have sources of the two programs in different folders (directories) and
start the text-mode IDE in the respective folder depending on the
"project" / program you intend to build.

2) Set the compiler defines as necessary for the respective "project"
(i.e. differently for ProgramA when started from directory of ProgramA and
for ProgramB when started from directory of ProgramB) - Options ->
Compiler -> Conditional defines. By default, the configuration is
automaticaly saved when exiting the IDE.

3) Make sure you always rebuild the unit depending on the program you want
to compile (Compile -> Build). Obviously, this requires the source file of
the unit to be available for the compiler (i.e. in one of paths in Options
-> Directories -> Unit directories).

>>There are already many ways to add defines. Adding another one would make
>> it harder for newbies.
> Is there some method to make a global define that is in the program
> itself?   I don't see how having options available makes anything harder
> for anyone, they can just not use such features.

The hard thing is for the user to understand differences among the
available options and their implications.

Defines have impact only when compiling the particular source code. Having
a 'global define' in a program could never have impact to a unit which
might be already compiled using different defines at the moment the
particular program is compiled. One of possible solutions for this is
having a 'global include file' which is included in all the relevant units
and the program, the other is outlined above (defines stored in the
compiler / IDE configuration file).

>>If you want a compiler define for all projects, then simply add that
>> define in your fpc.cfg file. That is a "global options" file. I trust
>> those will take effect even if you use the FPC Text IDE, because it is
>> the fpc.exe binary that reads the fpc.cfg file and gets default settings
>> from there.

Not quite - the text-mode IDE doesn't invoke fpc.exe binary (it has the
compiler built-in) and it passes the options as defined in the respective
IDE dialogs.

> Thanks for explaining that.  It looks like I can define where my units are
> with fpc.cfg as well and then I won't need to keep putting them on the
> command line.   If I put an fpc.cfg in a specific directory along with my
> program to be compiled, will the one in that directory override the one in
> \FPC\3.0.2\bin\i386-win32 ?

Yes (if starting the _compiler_ in that directory). If using the IDE, you
can do the same with the fp.cfg file.

> I'm wondering if I am missing something with reference to 'projects' is
> that a Lazarus thing?   How are 'projects' defined?

Yes, projects are 'a Lazarus thing'. However, you can achieve a similar
effect with local options and configuration files for the text-mode IDE
(you just need to use different directories for different 'projects').

Hope this helps

Tomas

___
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

>The idea is that you have one project per program. You can compile them 
>randomly without changing anything.

I don't understand what you mean by 'one project per program' ?  I only have 
programs that I have sorted in sub directories.  I normally use the Freepascal 
text IDE to compile them, and sometimes the command line.   I might want to 
have ProgramA.pas have one define and ProgramB.pas have another, both using the 
same unit, is there some method to do that?

>There are already many ways to add defines. Adding another one would make it 
>harder for newbies.
Is there some method to make a global define that is in the program itself?   I 
don't see how having options available makes anything harder for anyone, they 
can just not use such features.

>If you want a compiler define for all projects, then simply add that define in 
>your fpc.cfg file. That is a "global options" file. I trust those will take 
>effect even if you use the FPC Text IDE, because it is the fpc.exe binary that 
>reads the fpc.cfg file and gets default settings from there.

Thanks for explaining that.  It looks like I can define where my units are with 
fpc.cfg as well and then I won't need to keep putting them on the command line. 
  If I put an fpc.cfg in a specific directory along with my program to be 
compiled, will the one in that directory override the one in 
\FPC\3.0.2\bin\i386-win32 ?

I'm wondering if I am missing something with reference to 'projects' is that a 
Lazarus thing?   How are 'projects' defined?

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Mattias Gaertner
Sent: Thursday, June 15, 2017 6:55 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

On Thu, 15 Jun 2017 06:37:41 -0400
"James Richters" <ja...@productionautomation.net> wrote:

>[...]
> I see, thanks for explaining.   For some reason, I was thinking it was 
> optional to put it in the compiler, but I could also put it in the program.
> Is there no way to set a global define in each program so I could have 
> several programs defined differently and randomly compile them without 
> changing any settings?  

The idea is that you have one project per program. You can compile them 
randomly without changing anything.

> It seems some method of doing that would be very useful... but maybe not easy 
> to implement... I suppose it probably compiles all the units first then the 
> main program, so putting anything in the main program wouldn't be seen until 
> it was too late.

There are already many ways to add defines. Adding another one would make it 
harder for newbies.

Mattias
___
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] Implementing AggPas with PtcGraph


On 2017-06-15 11:37, James Richters wrote:

 Maybe include Freetype32.dll and Freetype64.dll to make it very
clear.


That was exactly what I had in mind.


the program. Is there no way to set a global define in each program
so I could have several programs defined differently and randomly
compile them without changing any settings?


If you want a compiler define for all projects, then simply add that 
define in your fpc.cfg file. That is a "global options" file. I trust 
those will take effect even if you use the FPC Text IDE, because it is 
the fpc.exe binary that reads the fpc.cfg file and gets default settings 
from there.



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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-15 Thread Mattias Gaertner

On Thu, 15 Jun 2017 06:37:41 -0400
"James Richters"  wrote:

>[...]
> I see, thanks for explaining.   For some reason, I was thinking it was 
> optional to put it in the compiler, but I could also put it in the program.
> Is there no way to set a global define in each program so I could have 
> several programs defined differently and randomly compile them without 
> changing any settings?  

The idea is that you have one project per program. You can compile them
randomly without changing anything.


> It seems some method of doing that would be very useful... but maybe not easy 
> to implement... I suppose it probably compiles all the units first then the 
> main program, so putting anything in the main program wouldn't be seen until 
> it was too late.

There are already many ways to add defines. Adding another one would
make it harder for newbies.

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

>True. I'll include a 64-bit version too.

That would be great, because I don't have a clue where this 64bit version I 
found came from, what version it is, and things like that.  
Maybe include Freetype32.dll and Freetype64.dll to make it very clear.

>That is why I said you must put it in your Project's Compiler Settings instead 
>using your IDE of choice 
>(or via the command line when calling fpc.exe binary). That way the define is 
>active for all units of your project.

I see, thanks for explaining.   For some reason, I was thinking it was optional 
to put it in the compiler, but I could also put it in the program.
Is there no way to set a global define in each program so I could have several 
programs defined differently and randomly compile them without changing any 
settings?  
It seems some method of doing that would be very useful... but maybe not easy 
to implement... I suppose it probably compiles all the units first then the 
main program, so putting anything in the main program wouldn't be seen until it 
was too late.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Thursday, June 15, 2017 3:19 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

On 2017-06-15 02:40, James Richters wrote:
> That is what I thought should happen, but I put {$DEFINE 
> AGG2D_USE_FREETYPE}
>
> I don't know why the define isn't making it to the unit.  Do I need to 
> do something else?

Compiler defines defined with the $DEFINE directive is per unit only.

That is why I said you must put it in your Project's Compiler Settings instead 
using your IDE of choice (or via the command line when calling fpc.exe binary). 
That way the define is active for all units of your project.

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal 
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp 
___
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] Implementing AggPas with PtcGraph


On 2017-06-15 02:55, Stefan V. Pantazi wrote:

I think you need to use a global define passing a -d??? parameter
(-dAGG2D_USE_FREETYPE) to the compiler. Just adding it to a unit only
defines for that unit



The above statement is 100% correct.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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


On 2017-06-15 02:40, James Richters wrote:

That is what I thought should happen, but I put {$DEFINE
AGG2D_USE_FREETYPE}

I don't know why the define isn't making it to the unit.  Do I need
to do something else?


Compiler defines defined with the $DEFINE directive is per unit only.

That is why I said you must put it in your Project's Compiler Settings 
instead using your IDE of choice (or via the command line when calling 
fpc.exe binary). That way the define is active for all units of your 
project.



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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-14 Thread Stefan V. Pantazi

I think you need to use a global define passing a -d??? parameter 
(-dAGG2D_USE_FREETYPE) to the compiler. Just adding it to a unit only 
defines for that unit and to any file included in that one unit.


On 06/14/2017 09:40 PM, James Richters wrote:

The font rendering should all be controlled by compiler defines. You don't need 
to modify the unit to make it work.
Simply add the correct define in your project's Compiler Settings and recompile 
the code.


That is what I thought should happen, but I put
{$DEFINE AGG2D_USE_FREETYPE}

In my program under
{$mode objfpc}{$H+}

I still get:
FreeType: FALSE  Win32 True Type: TRUE

But if I uncomment
{$DEFINE AGG2D_USE_FREETYPE}
In agg_2D.pas

It's the only way I can get
FreeType: TRUE  Win32 True Type: FALSE

I don't know why the define isn't making it to the unit.  Do I need to do 
something else?   It's as if it's being un-defined somewhere else but I don't 
know where.. maybe the same place that is {$DEFINE AGG2D_USE_WINFONTS} because 
that is defiantly being set somewhere before the agg_2D.Pas unit and the only 
way to not get an error is for me to have this at the top of agg_2D.pas

{$IFDEF AGG2D_USE_FREETYPE }
 {$UNDEF AGG2D_USE_WINFONTS}
{$ENDIF }


And if you look in the "develop" branch of fpGUI, there is an even later
AggPas version - last updated a month ago.


Maybe I should go get this.. maybe some of these things are fixed already

Thank you for the help with this.

James

___
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] Implementing AggPas with PtcGraph

>The font rendering should all be controlled by compiler defines. You don't 
>need to modify the unit to make it work.
>Simply add the correct define in your project's Compiler Settings and 
>recompile the code. 

That is what I thought should happen, but I put 
{$DEFINE AGG2D_USE_FREETYPE}

In my program under 
{$mode objfpc}{$H+} 

I still get:
FreeType: FALSE  Win32 True Type: TRUE

But if I uncomment 
{$DEFINE AGG2D_USE_FREETYPE} 
In agg_2D.pas

It's the only way I can get
FreeType: TRUE  Win32 True Type: FALSE

I don't know why the define isn't making it to the unit.  Do I need to do 
something else?   It's as if it's being un-defined somewhere else but I don't 
know where.. maybe the same place that is {$DEFINE AGG2D_USE_WINFONTS} because 
that is defiantly being set somewhere before the agg_2D.Pas unit and the only 
way to not get an error is for me to have this at the top of agg_2D.pas

{$IFDEF AGG2D_USE_FREETYPE }
 {$UNDEF AGG2D_USE_WINFONTS}
{$ENDIF }

>And if you look in the "develop" branch of fpGUI, there is an even later 
>AggPas version - last updated a month ago.

Maybe I should go get this.. maybe some of these things are fixed already

Thank you for the help with this.

James

___
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


On 2017-06-14 19:15, James Richters wrote:

testing it are using the same thing, and people can have programs
that use either unit side by side without remembering how to modify /
unmodify a unit to make it work.


The font rendering should all be controlled by compiler defines. You 
don't need to modify the unit to make it work. Simply add the correct 
define in your project's Compiler Settings and recompile the code. If 
you know you are only every going to use one font render engine, then 
you can obviously modify the unit to make the default more to your liking.



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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


On 2017-06-14 19:15, James Richters wrote:

Here is what I found out... Freetype.dll included in
fpgui_src_1.4.1.zip indeed does not have a dependency for
msvcr71.dll...


Yup, that's what I thought. :)



however,  it only works if I compile with Win32.


True. I'll include a 64-bit version too.


Speaking of the AggPas in fpGUI only:
  As for the $DEFINE and $IFDEF comments. When you toggle one font 
renderer (or disable it completely), then the other defines should have 
been undefined. That's how it used to work. Maybe somewhere that go 
broken. I'll do some testing and fix anything that is needed. Thanks for 
mentioning it.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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


On 2017-06-14 16:37, James Richters wrote:

I was able to finally compile and run the test program for Win64.


Excellent news!



As for AggPas. I use the version of AggPas that is included with
fpGUI. I simply make sure the path to AggPas is specified in the


There are 3 forks of AggPas that I know of, and the one included with 
fpGUI is the most maintained version (features and bug fixes).




Previously I was using the only version of AggPas I could find by
doing an internet search which I downloaded from here:
http://www.crossgl.com/aggpas/aggpas-download.htm then downloaded
AggPas24-rm3.zip


Ah, that would explain it. That is the original and FINAL release of 
AggPas by Milano from many years ago. It doesn't support 64-bit, doesn't 
support FreeBSD and had some bugs.


All those issues have been resolved in the AggPas included with fpGUI.



So it looks like AggPas24-rm3.zip from
http://www.crossgl.com/aggpas/aggpas-download.htm was last updated in
2008, while FPGUI was updated in 2015 and the version there has had
some changes so it is now beyond 24-rm3.


And if you look in the "develop" branch of fpGUI, there is an even later 
AggPas version - last updated a month ago.




Very confusing.  Maybe
AggPas is not being maintained anymore at
http://www.crossgl.com/aggpas ?


Yes, it is a bit confusing. No, the original AgPass from the crossgl.com 
website is not being maintained for many years.


I think you main a valid point in your other mail about the unit header 
comments. I'll update the header comments in fpGUI repository and make 
sure that it mentions that it is beyond the origin 2.4-rm3 release.


ps:
  And if you wondered why I don't have AggPas in its own repository?
  AggPas is/has been integrated into fpGUI and is becoming the default
  renderer for fpGUI's Canvas class. So it's a critical dependency
  (and at the time I didn't know about Git Submodules). At least
  I kept all the AggPas code in its own directory, but in hindsight,
  I should probably have named that directory "render/aggpas/" and not
  "render/software/". Umm, I might just change that before the
  next fpGUI release.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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

I finally got freetype to work with AggPas, but I had to make a few changes.  I 
am wondering if there is a way to submit a request for changes so they will be 
part of the next release?

Here is what I found out... 
Freetype.dll included in fpgui_src_1.4.1.zip indeed does not have a dependency 
for msvcr71.dll... however,  it only works if I compile with Win32.

I did some searching and came up with something called libfreetype-6.dll listed 
as a 64bit Freetype library, so I copied that over and renamed it to 
freetype.lib, and now my Win64 program uses it and works... but as expected, 
the Win32 program no longer works.  

So I did some digging and fount 'freetype.dll' being assigned in 
agg_font_freetype_lib.pas on line 42 as follows:
-
const
{$IFDEF WINDOWS }
  ft_lib = 'freetype.dll';
{$ENDIF }

// Linux, FreeBSD etc.
{$if defined(UNIX) and not defined(darwin)}
  ft_lib = 'freetype';
{$ENDIF }

// Mac OS X
{$ifdef darwin}
  ft_lib = 'libfreetype';
{$ENDIF }
-
So I changed the Windows section to:
{$IFDEF WINDOWS }
{$IFDEF CPU64 }
  ft_lib = 'libfreetype-6.dll';
{$Else }
  ft_lib = 'freetype.dll';
{$ENDIF }
{$ENDIF }

Now if I compile it Win64 it uses the 64bit library and if I compile it Win32 
it uses the 32bit library, this way I can just randomly create whatever type 
program I want and get the correct library.   I suppose something similar would 
be needed for other platforms but have no way to test it.

Also I had issues with using freetype at all.  I used 
Writeln('FreeType: ',Agg2DUsesFreeType,'  Win32 True Type: 
',Agg2DUsesWin32TrueType); 
To show which font method was being used and found my program was using win32 
true type fonts

So I went to Agg_2D.pas on line 25 and found this:

// With this define uncommented you can use FreeType font engine
{ $DEFINE AGG2D_USE_FREETYPE }

It took me a while to figure out that the space between ( and $ was making this 
into a comment,  it would have been more clear to comment it out like:
//{$DEFINE AGG2D_USE_FREETYPE}  

But in any case I did figure it out and uncommented it,  but then I could not 
compile it because of:
agg_2D.pas(142,15) Error: Duplicate identifier "FontEngine"

So Agg_2D.pas line 138 - 143 are:
{$IFDEF AGG2D_USE_FREETYPE }
 FontEngine = font_engine_freetype_int32;
{$ENDIF }
{$IFDEF AGG2D_USE_WINFONTS}
 FontEngine = font_engine_win32_tt_int32;
{$ENDIF }

The only way the FontEngine = font_engine_win32_tt_int32; on line 142 could 
cause this error is if both  AGG2D_USE_WINFONTS and  AGG2D_USE_FREETYPE were 
defined.  I looked around and could not find where AGG2D_USE_WINFONTS was 
defined, but it seems obvious that both cannot be defined at once so I changed 
from line 25 in Agg_2D.pas to this:
// With this define uncommented you can use FreeType font engine
//{$DEFINE AGG2D_USE_FREETYPE}

{$IFDEF AGG2D_USE_FREETYPE }
  {$UNDEF AGG2D_USE_WINFONTS}
{$ENDIF }

And now if I run it as above I get Win32 true type fonts and if I comment out 
the freetype define I get freetype fonts.

I noticed that with the freetype define comment out, adding it to my program 
could not make it work.  I would prefer a method that did not involve modifying 
the Agg_2D unit to change which font package to use.

Also,  I have copied Agg_2D.pas to Agg_2D_RBG565.pas and modified that one as 
needed for ptcgraph.  I wonder if it would be beneficial to add this modified 
version of the unit to the development system so eventually it will be included 
in the official release.  That way everyone working on it and / or testing it 
are using the same thing, and people can have programs that use either unit 
side by side without remembering how to modify / unmodify a unit to make it 
work.I'm not sure where the proper place is to submit things like this, but 
I would be happy to contribute these changes if possible.

James



-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
James Richters
Sent: Wednesday, June 14, 2017 11:54 AM
To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

All this has me wondering about the freetype.dll version.  I've been using 
freetype.dll that I found in AggPas24-rm3.zip modified 9/17/2007 I notice there 
is another one in fpgui_src_1.4.1.zip in the 
fpgui-1.4.1\extras\freetype_windows directory modified 12/9/2012  Is this the 
best version to use?  

I was hoping to figure out a way to not have the dependency of msvcr71.dll I 
tried going all over https://www.freetype.org and even downloaded ft28.zip from 
there and tried to make sense of it, but just got more confused I haven't tried 
the version of freetype.dll included with fpgui yet, I thought I would just ask 
first

James

___
fpc-pascal maillis

Re: [fpc-pascal] Implementing AggPas with PtcGraph

All this has me wondering about the freetype.dll version.  I've been using 
freetype.dll that I found in AggPas24-rm3.zip modified 9/17/2007
I notice there is another one in fpgui_src_1.4.1.zip in the 
fpgui-1.4.1\extras\freetype_windows directory modified 12/9/2012  Is this the 
best version to use?  

I was hoping to figure out a way to not have the dependency of msvcr71.dll
I tried going all over https://www.freetype.org and even downloaded ft28.zip 
from there and tried to make sense of it, but just got more confused
I haven't tried the version of freetype.dll included with fpgui yet, I thought 
I would just ask first

James

___
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

I was able to finally compile and run the test program for Win64.   I wanted to 
change only one thing at a time so I could figure out what exactly the problem 
was.  The first thing I tried was to use the exact version of AggPas Graeme 
used.

>As for AggPas. I use the version of AggPas that is included with fpGUI. 
>I simply make sure the path to AggPas is specified in the project compiler 
>settings, which in the above command line parameter is:
>c:\devel\fpgui\src\corelib\render\software

Previously I was using the only version of AggPas I could find by doing an 
internet search which I downloaded from here:
http://www.crossgl.com/aggpas/aggpas-download.htm then downloaded 
AggPas24-rm3.zip 

So I removed that version and downloaded fpgui_src_1.4.1.zip from:
https://sourceforge.net/projects/fpgui/files/fpGUI/1.4.1/

I extracted it to my H: Drive and tested it out.
I did not change my path for this test so I just put in paths to everything and 
ran it from the H:\FPC64\3.0.2\x86_64-win64\bin directory then executed the 
following command line:
fpc -Fu..\units\$fpctarget\* -FuH:\fpgui-1.4.1\src\corelib\render\software 
J:\programming\Gcode\Graphics\aggpas_ptcgraph_output.pas

The compile was successful and the Win64 version of the program ran fine.

So just for fun, I replaced the aggpas units in my original setup with the ones 
from fpgui_src_1.4.1.zip and tried it the original way I was doing it with the 
cross compiler and the command:
fpc -FuJ:\Programming\FPC\3.0.2\units\$fpctarget\* -Px86_64 
aggpas_ptcgraph_output.pas 
This was also successful, so I tried a few other sample programs and they all 
seem to work as both Win32 and Win64

So I was wondering, why would this be?  So I looked at this:
>While in lazarus open agg_rasterizer_scanline_aa.pas, go ro line 611 press Ctr 
>and click on ptrcomp. It should open agg_basics.pas, the comment may apply to 
>your situation.

And did a compare between agg_basics from AggPas24-rm3.zip and agg_basics from 
fpgui_src_1.4.1.zip and noticed they are NOT the same.  They both indicate they 
are the same by the comments at the top 
// Anti-Grain Geometry - Version 2.4 Release Milano 3 (AggPas 2.4 RM3) 

But the version from AggPas24-rm3.zip has
// Pascal's pointer-in-an-array-access helper structures
 p32_ptr = ^p32;
 p32 = record
   case integer of
1 : (ptr : pointer );

   {$IFDEF CPU64 }
2 : (int : system.int64 );

   {$ELSE }
2 : (int : integer );

   {$ENDIF }

  end;

while the version from fpgui_src_1.4.1.zip has
// Pascal's pointer-in-an-array-access helper structures
 p32_ptr = ^p32;
 p32 = record
   case integer of
1 : (ptr : pointer );
2 : (int : ptrcomp );
  end;

There are also several other differences in the 2 files.   

So it looks like AggPas24-rm3.zip from 
http://www.crossgl.com/aggpas/aggpas-download.htm was last updated in 2008, 
while
FPGUI was updated in 2015 and the version there has had some changes so it is 
now beyond 24-rm3.  Very confusing.  Maybe AggPas is not being maintained 
anymore at http://www.crossgl.com/aggpas ?

Anyway Thank you to everyone for helping get to the bottom of this!  

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Wednesday, June 14, 2017 8:29 AM
To: fpc-pascal@lists.freepascal.org
Cc: James Richters <ja...@productionautomation.net>
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

On 2017-06-14 11:57, James Richters wrote:
> I've downloaded the zip file and extracted it to H:\FPC64.   But now
> I have a few questions to attempt to duplicate a successful 64bit 
> compile.

Two steps are required - sorry, I forgot to mention that in my previous post 
(though I did to the person i created this zip for originally).

1) I find it always useful to have the \bin\ directory in my PATH so that 
the fpc.exe executable can be run from anywhere.

2) You need to adjust the fpc.cfg file (located in the 'bin' directory) to 
match your install path. My path was:

c:\lazarus\fpc\3.0.2\x86_64-win64

Back in FPC 2.4.x I installed Lazarus which included FPC, which in turn 
installed the FPC under the c:\lazarus\fpc\ directory. Ever since every FPC 
update, I just stuck to that install location. So you don't need to have it 
like this obviously.

> Maybe it isn't valid to use the IDE with Win64?  I sure wish it would
> work.   I like and prefer the FPC text IDE.

The FPC Text IDE (64-bit) runs just fine here under Windows 7 64-bit. 
See attached screenshot. Even mouse support works inside the Text IDE.

I mostly use MSEide for all my console, web and fpGUI related programming. I 
created some custom project templates and away I go. 
Lazarus has some nice editor features, but is often buggy and the Lazarus 
Package system just doesn't work for me. With MSEide I use global (or per 
project) path macros instead. This gives much more reliable compilations.

Here is the

Re: [fpc-pascal] Implementing AggPas with PtcGraph

>> I also wonder if this is a windows 10 frootllooopy weirdness thing (it 
>> wouldn't be the first).  Can you just email me the exe file zipped and 
>> I'll just try to run it here?  Then I will know if it's a compiler 
>> issue or an OS issue

>I assume you mean the executable of the ptcgraph+aggpas demo? I'll do so in a 
>private email.

Thanks for mailing the demo executable.  I'm happy to report that it does run 
fine on my system as well (Windows 10 x64)
So there must be something different in the way I am compiling it that is 
causing the problem.

James


___
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

Thanks for all the info, I will try to get it working.

>I assume you mean the executable of the ptcgraph+aggpas demo? I'll do so in a 
>private email.
Yes, please.

___
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


On 2017-06-14 11:57, James Richters wrote:

I've downloaded the zip file and extracted it to H:\FPC64.   But now
I have a few questions to attempt to duplicate a successful 64bit
compile.


Two steps are required - sorry, I forgot to mention that in my previous 
post (though I did to the person i created this zip for originally).


1) I find it always useful to have the \bin\ directory in my PATH 
so that the fpc.exe executable can be run from anywhere.


2) You need to adjust the fpc.cfg file (located in the 'bin' directory) 
to match your install path. My path was:


   c:\lazarus\fpc\3.0.2\x86_64-win64

Back in FPC 2.4.x I installed Lazarus which included FPC, which in turn 
installed the FPC under the c:\lazarus\fpc\ directory. Ever since every 
FPC update, I just stuck to that install location. So you don't need to 
have it like this obviously.




Maybe it isn't valid to use the IDE with Win64?  I sure wish it would
work.   I like and prefer the FPC text IDE.


The FPC Text IDE (64-bit) runs just fine here under Windows 7 64-bit. 
See attached screenshot. Even mouse support works inside the Text IDE.


I mostly use MSEide for all my console, web and fpGUI related 
programming. I created some custom project templates and away I go. 
Lazarus has some nice editor features, but is often buggy and the 
Lazarus Package system just doesn't work for me. With MSEide I use 
global (or per project) path macros instead. This gives much more 
reliable compilations.


Here is the command line equivalent of what my MSEide project does for 
the ptcgraph + aggpas demo.


C:\lazarus\fpc\3.0.2\x86_64-win64\bin\fpc.exe 
-oaggpas_ptcgraph_output.exe -Fuc:\devel\fpgui\src\reportengine 
-Fuc:\devel\fpgui\src\corelib\render\software 
-Fic:\devel\fpgui\src\corelib\render\software -Fic:\devel\fpgui\src 
-Fuc:\devel\fpgui\src\corelib\gdi -Fic:\devel\fpgui\src\corelib\gdi 
-Fuc:\devel\fpgui\src\gui -Fuc:\devel\fpgui\src\corelib -l -Mobjfpc -Sh 
-Sc -Si -gl -O- -FUunits -viewnh aggpas_ptcgraph_output.pas



As for AggPas. I use the version of AggPas that is included with fpGUI. 
I simply make sure the path to AggPas is specified in the project 
compiler settings, which in the above command line parameter is:


   c:\devel\fpgui\src\corelib\render\software

FPC then compiles all units as it needs them, and I always output the 
compiled units into a project specific "units" directory (the -FUunits 
command line parameter seen above). I don't like mixing *.pas and 
*.o;*.ppu files in the same directories.




I also wonder if this is a windows 10 frootllooopy weirdness thing
(it wouldn't be the first).  Can you just email me the exe file
zipped and l'll just try to run it here?  Then I will know if it's a
compiler issue or an OS issue


I assume you mean the executable of the ptcgraph+aggpas demo? I'll do so 
in a private email.




Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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

>Strange, as it works perfectly here. I compiled FPC 3.0.2 for win64 (I always 
>do that for Win64 - I never use the cross compiler). 
>Somebody else (I can't remember who) asked for a native win64 windows 
>compiler, and I zipped up the one I had. It is still available for download 
>from here...

I've downloaded the zip file and extracted it to H:\FPC64.   But now I have a 
few questions to attempt to duplicate a successful 64bit compile.  It's 
probably better to ask than to make a mess of things by doing it wrong.
Starting with the native win64 windows compiler I just downloaded,  how do I 
install the aggpas units?
How do you use this to compile the example successfully?  IDE? command line?  
Do I need to define unit directories somewhere?
Any other configurations or setups I need to do?
I notice there is a 64bit version of the IDE and in there under Options > 
Compiler > Processor the CoreI and Athlon64 are listed, so it seemed
Like it should just work (although I don't know how these should be set)

I tried to use the IDE to compile one of my simple programs but I get
Program generated a RTE 217
at address $.
Save your sources and restart the IDE.

Then after clicking OK

The IDE generated an internal error
and will now be closed.

Maybe it isn't valid to use the IDE with Win64?  I sure wish it would work.   I 
like and prefer the FPC text IDE.

I also wonder if this is a windows 10 frootllooopy weirdness thing (it wouldn't 
be the first).  Can you just email me the exe file zipped and l'll just try to 
run it here?  Then I will know if it's a compiler issue or an OS issue

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Graeme Geldenhuys
Sent: Wednesday, June 14, 2017 5:17 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

On 2017-06-14 01:25, James Richters wrote:
> I have just installed Lazarus but still can't get the 
> aggpas_ptcgraph_output.pas sample program to run when compiled for 
> x64. Here is what I have done.

Strange, as it works perfectly here. I compiled FPC 3.0.2 for win64 (I always 
do that for Win64 - I never use the cross compiler). Somebody else (I can't 
remember who) asked for a native win64 windows compiler, and I zipped up the 
one I had. It is still available for download from here...

http://geldenhuys.co.uk/~graemeg/fpc-3.0.2-win64.7z

I then compiled your sample program. It works and runs perfectly under Windows 
7 (64-bit). See the my second private email where I attached a screenshot. I 
don't have a later Windows version to test on.

The only mods I made:
   - modified agg_2D.pas so the constructor takes a pixfmt parameter.
   - flipped the Y-axis in the example program.

The pixel channel order is still an issue though - Red and Blue channels need 
to be swapped.

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal 
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp 
___
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] Implementing AggPas with PtcGraph


On 2017-06-14 01:25, James Richters wrote:

I have just installed Lazarus but still can't get the
aggpas_ptcgraph_output.pas sample program to run when compiled for
x64. Here is what I have done.



Strange, as it works perfectly here. I compiled FPC 3.0.2 for win64 (I
always do that for Win64 - I never use the cross compiler). Somebody
else (I can't remember who) asked for a native win64 windows compiler,
and I zipped up the one I had. It is still available for download from
here...

   http://geldenhuys.co.uk/~graemeg/fpc-3.0.2-win64.7z


I then compiled your sample program. It works and runs perfectly under
Windows 7 (64-bit). See the my second private email where I attached a
screenshot. I don't have a later Windows version to test on.

The only mods I made:
  - modified agg_2D.pas so the constructor takes a pixfmt parameter.
  - flipped the Y-axis in the example program.

The pixel channel order is still an issue though - Red and Blue channels
need to be swapped.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
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

Yes, it is puzzling. Different pointer sizes, compilers, OS, 32/64 bit 
library dependencies, can be potential causes.


Again, note that I compiled the example on a CentOS 7, 64bit Linux with 
Lazarus 1.5 + fpc 3.0.1


I can also confirm that the test program compiles and works fine on 
Ubuntu 16.04 64bit, with Lazarus 1.7 + fpc 3.1.1



On 06/13/2017 10:16 PM, James Richters wrote:

but I don't know what I can do about it and why you are able to cross 
compile for win64 and it works.


___
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

>If you are already on a win64 machine then your default target CPU should 
>already be x86_64. why do you need fpc-3.0.2-cross-i386-win32-win64?
Correction:  
I start with fpc-3.0.2.i386-win32 because there is no precompiled version for 
win64 of freepascal I tried to compile it myself is it's just a confusing mess 
that I can't get to work.
So I then need to install fpc-3.0.2-cross-i386-win32-win64 to compile x64 with 
the above fpc-3.0.2.i386-win32 running on my x64 machine.

With Lazarus I am able to do it the other way around, I install
lazarus-1.6.4-fpc-3.0.2-win64.exe so from there I can compile x64 programs, 
then install 
lazarus-1.6.4-fpc-3.0.2-cross-i386-win32-win64.exe so I can also compile Win32 
programs with Lazarus.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
James Richters
Sent: Tuesday, June 13, 2017 10:16 PM
To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

>It is unclear to me whether you are on a win32 or win64 OS?
I am on Windows 10 x64 OS

>If you are already on a win64 machine then your default target CPU should 
>already be x86_64. why do you need fpc-3.0.2-cross-i386-win32-win64?
fpc-3.0.2-cross-i386-win32-win64 is to be able to compile as a win32 program on 
a win64 machine.   I installed that so I could compile as win32 for comparison. 
 The test program works if compiled with Lazarus  for win32 but not win64

>While in lazarus open agg_rasterizer_scanline_aa.pas, go ro line 611 press Ctr 
>and click on ptrcomp. It should open agg_basics.pas, the comment may apply to 
>your situation.
I was able to follow this and get to the comment in agg_basics, I read the 
comment that indicates some difference and possible problem with pointers on 
win64 but I don't know what I can do about it and why you are able to cross 
compile for win64 and it works.   I wonder if this is an issue with Freepascal 
3.0.2, and aggpas hasn't been fixed for it yet and I need to use Freepascal 
3.0.1 to get it to work?

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Stefan V. Pantazi
Sent: Tuesday, June 13, 2017 9:25 PM
To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

While in lazarus open agg_rasterizer_scanline_aa.pas, go ro line 611 press Ctr 
and click on ptrcomp. It should open agg_basics.pas, the comment may apply to 
your situation.

It is unclear to me whether you are on a win32 or win64 OS? If you are already 
on a win64 machine then your default target CPU should already be x86_64. why 
do you need fpc-3.0.2-cross-i386-win32-win64?


On 06/13/2017 08:25 PM, James Richters wrote:
>> Noting your problems with compilation, you may want to consider using 
>> Lazarus IDE as well.
>
> I have just installed Lazarus but still can't get the 
> aggpas_ptcgraph_output.pas sample program to run when compiled for x64.
> Here is what I have done.
>
> Downloaded and installed lazarus-1.6.0-fpc-3.0.0-win64.exe and 
> accepted all defaults Downloaded and installed 
> lazarus-1.6.4-fpc-3.0.2-cross-i386-win32-win64.exe and accepted the default 
> install directory.
> Copied aggpas to C:\lazarus\fpc\3.0.2\units\i386-win32
> Copied aggpas to C:\lazarus\fpc\3.0.2\units\x86_64-win64
>
> Opened a sample program the uses just ptcgraph, when it asked to 
> create a project I said yes then selected 'Program' from the list I 
> was able to compile and run it with options for OS win32 CPU i386 as 
> well as OS  win64 CPU x86_64 and it ran fine with both versions I opened 
> aggpas_ptcgraph_output.pas the same way and selected program.  If I select OS 
> win32 CPU i386 it compiles and runs fine, no problems When I select OS  win64 
> CPU x86_64 and try to run it, it opens both the console window and graphics 
> window, then I get an error box reading:
>
> Project aggpas_ptcgraph_output raised exception class 'external: SIGSEGV'
> In file 'C:\lazarus\fpc\3.0.2\u..\agg_rasterizer_scanline_aa.pas' at 
> line 611 while cell_aa_ptr_prt(ptrcomp(j) + 1 * 4^^.x<J^.x do
>
> Any ideas why this is happening?
>
> James
>
>
>
> ___
> 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] Implementing AggPas with PtcGraph

>It is unclear to me whether you are on a win32 or win64 OS?
I am on Windows 10 x64 OS

>If you are already on a win64 machine then your default target CPU should 
>already be x86_64. why do you need fpc-3.0.2-cross-i386-win32-win64?
fpc-3.0.2-cross-i386-win32-win64 is to be able to compile as a win32 program on 
a win64 machine.   I installed that so I could compile as win32 for comparison. 
 The test program works if compiled with Lazarus  for win32 but not win64

>While in lazarus open agg_rasterizer_scanline_aa.pas, go ro line 611 press Ctr 
>and click on ptrcomp. It should open agg_basics.pas, the comment may apply to 
>your situation.
I was able to follow this and get to the comment in agg_basics, I read the 
comment that indicates some difference and possible problem with pointers on 
win64 but I don't know what I can do about it and why you are able to cross 
compile for win64 and it works.   I wonder if this is an issue with Freepascal 
3.0.2, and aggpas hasn't been fixed for it yet and I need to use Freepascal 
3.0.1 to get it to work?

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Stefan V. Pantazi
Sent: Tuesday, June 13, 2017 9:25 PM
To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

While in lazarus open agg_rasterizer_scanline_aa.pas, go ro line 611 press Ctr 
and click on ptrcomp. It should open agg_basics.pas, the comment may apply to 
your situation.

It is unclear to me whether you are on a win32 or win64 OS? If you are already 
on a win64 machine then your default target CPU should already be x86_64. why 
do you need fpc-3.0.2-cross-i386-win32-win64?


On 06/13/2017 08:25 PM, James Richters wrote:
>> Noting your problems with compilation, you may want to consider using 
>> Lazarus IDE as well.
>
> I have just installed Lazarus but still can't get the 
> aggpas_ptcgraph_output.pas sample program to run when compiled for x64.
> Here is what I have done.
>
> Downloaded and installed lazarus-1.6.0-fpc-3.0.0-win64.exe and 
> accepted all defaults Downloaded and installed 
> lazarus-1.6.4-fpc-3.0.2-cross-i386-win32-win64.exe and accepted the default 
> install directory.
> Copied aggpas to C:\lazarus\fpc\3.0.2\units\i386-win32
> Copied aggpas to C:\lazarus\fpc\3.0.2\units\x86_64-win64
>
> Opened a sample program the uses just ptcgraph, when it asked to 
> create a project I said yes then selected 'Program' from the list I 
> was able to compile and run it with options for OS win32 CPU i386 as 
> well as OS  win64 CPU x86_64 and it ran fine with both versions I opened 
> aggpas_ptcgraph_output.pas the same way and selected program.  If I select OS 
> win32 CPU i386 it compiles and runs fine, no problems When I select OS  win64 
> CPU x86_64 and try to run it, it opens both the console window and graphics 
> window, then I get an error box reading:
>
> Project aggpas_ptcgraph_output raised exception class 'external: SIGSEGV'
> In file 'C:\lazarus\fpc\3.0.2\u..\agg_rasterizer_scanline_aa.pas' at 
> line 611 while cell_aa_ptr_prt(ptrcomp(j) + 1 * 4^^.x<J^.x do
>
> Any ideas why this is happening?
>
> James
>
>
>
> ___
> 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] Implementing AggPas with PtcGraph

While in lazarus open agg_rasterizer_scanline_aa.pas, go ro line 611 
press Ctr and click on ptrcomp. It should open agg_basics.pas, the 
comment may apply to your situation.


It is unclear to me whether you are on a win32 or win64 OS? If you are 
already on a win64 machine then your default target CPU should already 
be x86_64. why do you need fpc-3.0.2-cross-i386-win32-win64?



On 06/13/2017 08:25 PM, James Richters wrote:

Noting your problems with compilation, you may want to consider using Lazarus 
IDE as well.


I have just installed Lazarus but still can't get the 
aggpas_ptcgraph_output.pas sample program to run when compiled for x64.
Here is what I have done.

Downloaded and installed lazarus-1.6.0-fpc-3.0.0-win64.exe and accepted all 
defaults
Downloaded and installed lazarus-1.6.4-fpc-3.0.2-cross-i386-win32-win64.exe and 
accepted the default install directory.
Copied aggpas to C:\lazarus\fpc\3.0.2\units\i386-win32
Copied aggpas to C:\lazarus\fpc\3.0.2\units\x86_64-win64

Opened a sample program the uses just ptcgraph, when it asked to create a 
project I said yes then selected 'Program' from the list
I was able to compile and run it with options for OS win32 CPU i386 as well as 
OS  win64 CPU x86_64 and it ran fine with both versions
I opened aggpas_ptcgraph_output.pas the same way and selected program.  If I 
select OS win32 CPU i386 it compiles and runs fine, no problems
When I select OS  win64 CPU x86_64 and try to run it, it opens both the console 
window and graphics window, then I get an error box reading:

Project aggpas_ptcgraph_output raised exception class 'external: SIGSEGV'
In file 'C:\lazarus\fpc\3.0.2\u..\agg_rasterizer_scanline_aa.pas' at line 611 
while cell_aa_ptr_prt(ptrcomp(j) + 1 * 4^^.x

Re: [fpc-pascal] Implementing AggPas with PtcGraph

Looks like it may be something specific to your setup. In my tests I 
used Lazarus 1.5 as IDE and fpc 3.0.1 on Linux. Crosscompiled example 
ran on Win7 64 bit. So there are already differences with your 
environment. Noting your problems with compilation, you may want to 
consider using Lazarus IDE as well. You get a debugger too.


One other thing that comes to mind is to be mindful of calls like this

  agg^.rectangle(0, 0, IMAGE_WIDTH, IMAGE_HEIGHT);

If the default fill color is black, then the result will be a black 
window, albeit not unresponsive. Again, if your program hangs for some 
reason, a debugger may come in handy.


Stefan

On 06/13/2017 04:44 PM, James Richters wrote:

I've tested the example on 64 bit linux as a native application as well cross 
compiled for a x86_64 windows target. Worked fine in both Wine and on a Win64 
machine.



In my experience, the one dependency that AggPas has potential to fail may be 
related to the freetype library. If you plan to run your app on windows only, 
then you can turn freetype off and
AggPas will happily use windows font libraries. Search for the 
AGG2D_USE_FREETYPE define and comment it out.


I thought I would try to compile the example for x86_64, because I would 
eventually like to make my final program an x86_64 program.

When I compile it with the command:
fpc -Fu'J:\programming\fpc\3.0.2\units\$fpctarget\*' aggpas_ptcgraph_output.pas
it works fine.

When I try
fpc -Fu'J:\programming\fpc\3.0.2\units\$fpctarget\*' -Px86_64 
aggpas_ptcgraph_output.pas
it compiles fine with no errors, and it executes with no errors, however I do 
not get any output in either window at all, they are both just black, and 
unresponsive.

I've commented out the AGG2D_USE_FREETYPE for now, because I'm not sure if the 
freetype.dll I have will work on 64bit programs, and thought I would eliminate 
that as a possible issue.

I am using FPC v3.0.2 on a windows 10 x64 machine
I normally use the freepascal IDE to compile my programs, so I'm not too 
familiar with compiling from the command line.  I'm wondering if I am doing 
something wrong.

Also, is there some way to set a default for my units so I don't have to use 
Fu'J:\programming\fpc\3.0.2\units\$fpctarget\*' all the time?  If I don't use 
that, then it can't find any units, even though it's set in the directories 
with the IDE

I have some other sample programs that use ptcgraph (without AggPas) that do 
not have this issue, they compile as 64bit programs and run fine.  This seems 
to be something with using AggPas that appears to be causing the problem. I  
put in a writeln('test'); at the beginning of the program and it does do that, 
and I move ptcgraph.Rectangle(10,10,100,100); to before drawstuff(agg); I will 
get the rectangle on the graph screen.   So I thought I would try to narrow 
down what was happening by drawing different rectangles in the middle of the 
code like this:
  ptcgraph.Rectangle(30,30,200,200);
  agg^.clearAll(0, 0, 0);
  agg^.lineColor(0, 0, 0, 255);
  agg^.lineWidth(3);
  agg^.rectangle(0, 0, IMAGE_WIDTH, IMAGE_HEIGHT);
  ptcgraph.Rectangle(30,30,200,300);
  agg^.lineWidth(1);
  agg^.lineColor(0, 155, 0, 255);
  agg^.rectangle(10, 10, 50, 50);
  ptcgraph.Rectangle(30,30,300,300);

I get the first rectangle right away, the second rectangle after 6 seconds, and 
the third after 6 more seconds.
I tried commenting out everything else, but I still never get the image from 
putimage();

I'm very confused by this and don't have a clue what could be wrong.  If I take 
out the -Px86_64 in the compile command line, the program runs as expected.  
Since Stefan said he compiled 64bit versions of the example program and it 
worked, I wonder why I am having this issue.

James

___
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] Implementing AggPas with PtcGraph

>I've tested the example on 64 bit linux as a native application as well cross 
>compiled for a x86_64 windows target. Worked fine in both Wine and on a Win64 
>machine.

>In my experience, the one dependency that AggPas has potential to fail may be 
>related to the freetype library. If you plan to run your app on windows only, 
>then you can turn freetype off and
>AggPas will happily use windows font libraries. Search for the 
>AGG2D_USE_FREETYPE define and comment it out.

I thought I would try to compile the example for x86_64, because I would 
eventually like to make my final program an x86_64 program. 

When I compile it with the command:
fpc -Fu'J:\programming\fpc\3.0.2\units\$fpctarget\*' aggpas_ptcgraph_output.pas
it works fine.

When I try
fpc -Fu'J:\programming\fpc\3.0.2\units\$fpctarget\*' -Px86_64 
aggpas_ptcgraph_output.pas
it compiles fine with no errors, and it executes with no errors, however I do 
not get any output in either window at all, they are both just black, and 
unresponsive.

I've commented out the AGG2D_USE_FREETYPE for now, because I'm not sure if the 
freetype.dll I have will work on 64bit programs, and thought I would eliminate 
that as a possible issue.

I am using FPC v3.0.2 on a windows 10 x64 machine
I normally use the freepascal IDE to compile my programs, so I'm not too 
familiar with compiling from the command line.  I'm wondering if I am doing 
something wrong.

Also, is there some way to set a default for my units so I don't have to use 
Fu'J:\programming\fpc\3.0.2\units\$fpctarget\*' all the time?  If I don't use 
that, then it can't find any units, even though it's set in the directories 
with the IDE

I have some other sample programs that use ptcgraph (without AggPas) that do 
not have this issue, they compile as 64bit programs and run fine.  This seems 
to be something with using AggPas that appears to be causing the problem. I  
put in a writeln('test'); at the beginning of the program and it does do that, 
and I move ptcgraph.Rectangle(10,10,100,100); to before drawstuff(agg); I will 
get the rectangle on the graph screen.   So I thought I would try to narrow 
down what was happening by drawing different rectangles in the middle of the 
code like this:
  ptcgraph.Rectangle(30,30,200,200);
  agg^.clearAll(0, 0, 0);
  agg^.lineColor(0, 0, 0, 255);
  agg^.lineWidth(3);
  agg^.rectangle(0, 0, IMAGE_WIDTH, IMAGE_HEIGHT);
  ptcgraph.Rectangle(30,30,200,300);
  agg^.lineWidth(1);
  agg^.lineColor(0, 155, 0, 255);
  agg^.rectangle(10, 10, 50, 50);
  ptcgraph.Rectangle(30,30,300,300);

I get the first rectangle right away, the second rectangle after 6 seconds, and 
the third after 6 more seconds.  
I tried commenting out everything else, but I still never get the image from 
putimage(); 

I'm very confused by this and don't have a clue what could be wrong.  If I take 
out the -Px86_64 in the compile command line, the program runs as expected.  
Since Stefan said he compiled 64bit versions of the example program and it 
worked, I wonder why I am having this issue.

James

___
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

Thanks for the help with this
> 1) the ideal way would be to specify the rgb order of a pixel format in the 
> Agg_2D constructor. The m_pixFormat 
> has a m_order field with the type order_type defined in agg_color.pas; have 
> not figured it yet

>2) knowing the R and B channels are swapped, you can do all your drawing with 
>colors there R and B are switched.
It sounds like it would be easier to figure out option 1.   That may also be 
better for compatibility if aggpas is updated in the future to be more 
compatible with ptcgraph.

James

-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Stefan V. Pantazi
Sent: Tuesday, June 13, 2017 2:03 PM
To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

There is a minus sign in the call:

  agg^.attach(@graph_buffer.data, IMAGE_WIDTH, IMAGE_HEIGHT, -(IMAGE_WIDTH * 
RGB_WIDTH))

Removing it will flip the Y axis.

With regard to color, there may be two options:

1) the ideal way would be to specify the rgb order of a pixel format in the 
Agg_2D constructor. The m_pixFormat has a m_order field with the type 
order_type defined in agg_color.pas; have not figured it yet

2) knowing the R and B channels are swapped, you can do all your drawing with 
colors there R and B are switched.


Stefan


On 06/13/2017 12:42 PM, James Richters wrote:
> I've just realized that the red and blue channels are reversed.  The sample
> program aggpas_ptcgraph_output.pas has the star filled in with a red fade
> and a blue series of random lines while the original test.png file had a
> blue fade in the star with red random lines.   Also, the image is flipped on
> the Y axis compared to the original example. The small green square is in
> the upper left corner of test.png, but it is in the lower left corner of
> aggpas_ptcgraph_output.pas
>
> I've been able to duplicate the results of test.png by shifting the left 5
> bits 11 positions to the right and the right 5 bits 11 positions to the left
> and flipping the Y axis,  but I can only do that with putpixel and a nested
> loop, which is quite a bit slower than putimage.
>
> Any ideas how I can build the data correctly so putimage will work?
>
> James
>
> ___
> 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] Implementing AggPas with PtcGraph

>   Also, the image is flipped on
>the Y axis compared to the original example. The small green square is in the 
>upper left corner of test.png, but it is in the lower left corner of 
>aggpas_ptcgraph_output.pas

It appears there is some ambiguity on whether 0,0 should be the lower left of 
upper left, but 
I figured out how to flip the image on the Y axis:

agg^.attach(@graph_buffer.data, IMAGE_WIDTH, IMAGE_HEIGHT, -(IMAGE_WIDTH * 
RGB_WIDTH)); 
makes the image what I would consider upside down because
agg^.rectangle(10, 10, 50, 50); 
ends up in the lower left corner but
ptcgraph.Rectangle(10,10,100,100);
ends up in the upper right corner.

If I use 
agg^.attach(@graph_buffer.data, IMAGE_WIDTH, IMAGE_HEIGHT, IMAGE_WIDTH * 
RGB_WIDTH);
now both 
agg^.rectangle(10, 10, 50, 50); 
and
ptcgraph.Rectangle(10,10,100,100);
end up in the upper left corner with the 10,10 coordinates matching up

I still have not figured out how to switch red and blue bits around so 
putimage() will work.

James


-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
James Richters
Sent: Tuesday, June 13, 2017 12:43 PM
To: 'FPC-Pascal users discussions' <fpc-pascal@lists.freepascal.org>
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

I've just realized that the red and blue channels are reversed.  The sample 
program aggpas_ptcgraph_output.pas has the star filled in with a red fade and a 
blue series of random lines while the original test.png file had a
blue fade in the star with red random lines.   Also, the image is flipped on
the Y axis compared to the original example. The small green square is in the 
upper left corner of test.png, but it is in the lower left corner of 
aggpas_ptcgraph_output.pas

I've been able to duplicate the results of test.png by shifting the left 5 bits 
11 positions to the right and the right 5 bits 11 positions to the left and 
flipping the Y axis,  but I can only do that with putpixel and a nested
loop, which is quite a bit slower than putimage.   

Any ideas how I can build the data correctly so putimage will work?

James

___
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] Implementing AggPas with PtcGraph


There is a minus sign in the call:

 agg^.attach(@graph_buffer.data, IMAGE_WIDTH, IMAGE_HEIGHT, 
-(IMAGE_WIDTH * RGB_WIDTH))


Removing it will flip the Y axis.

With regard to color, there may be two options:

1) the ideal way would be to specify the rgb order of a pixel format in 
the Agg_2D constructor. The m_pixFormat has a m_order field with the 
type order_type defined in agg_color.pas; have not figured it yet


2) knowing the R and B channels are swapped, you can do all your drawing 
with colors there R and B are switched.



Stefan


On 06/13/2017 12:42 PM, James Richters wrote:

I've just realized that the red and blue channels are reversed.  The sample
program aggpas_ptcgraph_output.pas has the star filled in with a red fade
and a blue series of random lines while the original test.png file had a
blue fade in the star with red random lines.   Also, the image is flipped on
the Y axis compared to the original example. The small green square is in
the upper left corner of test.png, but it is in the lower left corner of
aggpas_ptcgraph_output.pas

I've been able to duplicate the results of test.png by shifting the left 5
bits 11 positions to the right and the right 5 bits 11 positions to the left
and flipping the Y axis,  but I can only do that with putpixel and a nested
loop, which is quite a bit slower than putimage.

Any ideas how I can build the data correctly so putimage will work?

James

___
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] Implementing AggPas with PtcGraph