>I am also wondering if it would be beneficial to accelerate other procedures
>in the same way especially getimage()
I went ahead and tried it and I've got getimage() to about 18x faster on my
system. I changed how it works a little, the original was checking every
single pixel if it was in t
I've been having very good results with the accelerated putimage() in ptcgraph.
I am wondering if this modification could be added to 3.04, or some future
release, as I think everyone would want putimage() to happen as fast as
possible.I can't figure out how or where to submit this thoug
I defined a static array to convert the mode 13h VGA palette to separate red,
green and blue to send to aggpas as well as the packed RGB565 format needed to
send to ptcgraph 16bit colors.
James
Type
VGARGBRec= Record
R,G,B:Byte;
RGB:Word;
end;
Const
VGA25
I defined a static array to convert the mode 13h VGA palette to separate red,
green and blue to send to aggpas as well as the packed RGB565 format needed to
send to ptcgraph 16bit colors.
James
Type
VGARGBRec= Record
R,G,B:Byte;
RGB:Word;
end;
Const
VGA256: Array[0..255]
>Your palette looks like standard Int Mode 13h VGA palette (yes, I'm older).
>This are the RGB values (I'm quite sure):
Thank you, I appreciate the help identifying the format I have and the
conversion to RGB. I was able to also find methods to convert RGB to RGB565
and back by looking in the
El 28/06/2017 a las 23:50, James Richters escribió:
The two color schemes are nothing alike. 16bit is using this RGB565 format,
but 8bit colors (at least the version I was using) the colors have no real
relation to their bits (see thishttps://pasteboard.co/2K38l6Gk1.png) I can't
figure out a
I've figured out a way to get my animations to work fast and still have the
quality of aggpas. The problem I have is that even though I've managed to
accelerate putimage() and it's pretty fast, it's still not fast enough and my
animations in my program happen too slow, especially on slow comput
On 06/26/2017 10:21 AM, James Richters wrote:
Is there a way to re-scale a drawing with agg_2D?
I think so, scaling is one of the transformations that agg supports
well. The way I would go about this would be to study how agg manages
the parsing, storage and display of svg drawings, which ar
Is there a way to re-scale a drawing with agg_2D? Basically I'm wanting to
zoom in/out of a drawing made with lines and arcs and I'm wondering the most
efficient way to do it. I found a scale feature in aggpas but it only seems to
scale items drawn after the command is issued. I'm wondering i
> lineto is meant to be used multiple times, as part of a draw path. So, lineto
> does not really draw,
>it just adds a vertex to a vertex storage object. To draw a path, you need to
>use the drawPath(option):
Thank you for the information! I thought I was missing something.
James
__
When in doubt, have a look at the source code of the graphical
primitives to determine the semantics of each one. Unlike line primitive
which draws a path immediately, lineto is meant to be used multiple
times, as part of a draw path. So, lineto does not really draw, it just
adds a vertex to a
I'm trying to switch over a program to use aggpas but I'm not getting any
results from moveto or lineto am I missing something?
I made a little demo that illustrates what's happening
agg^.lineWidth(4);
agg^.lineColor(0, 155, 0, 255);
agg^.rectangle(10, 10, 50, 50);
agg^.lineColor(155, 0,
On Thursday 22 June 2017 18:47:40 James Richters wrote:
> I squeezed a little more out of putimage by doing as little math as
> possible with a couple of variables to store j*ptcwidth and i+j*ptcwidth I
> got my 1000x test loop down to 1.013 seconds. Here is what it looks like
> at the moment, an
On Friday 23 June 2017 06:38:18 Martin Schreiber wrote:
> On Thursday 22 June 2017 18:47:40 James Richters wrote:
> > I squeezed a little more out of putimage by doing as little math as
> > possible with a couple of variables to store j*ptcwidth and i+j*ptcwidth
> > I got my 1000x test loop down t
On Thursday 22 June 2017 18:47:40 James Richters wrote:
> I squeezed a little more out of putimage by doing as little math as
> possible with a couple of variables to store j*ptcwidth and i+j*ptcwidth I
> got my 1000x test loop down to 1.013 seconds. Here is what it looks like
> at the moment, an
I squeezed a little more out of putimage by doing as little math as possible
with a couple of variables to store j*ptcwidth and i+j*ptcwidth I got my 1000x
test loop down to 1.013 seconds. Here is what it looks like at the moment, any
ideas on how to optimize it further?
https://github.com
>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.
That is exactly what I have almost all the time. I’m wanting to use putimage
for the entire screen all the time, but very few pixels on the screen chang
In our previous episode, James Richters said:
> >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
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
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 ptcg
>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 imag
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 rou
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) :}
.
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 fullsc
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
>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.
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
>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.
That will be a great help. Might I suggest mentioning the existence and use
of Agg2D in agg_2D and vice versa? Something like:
agg_2D
This unit has NO graphical to
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_ );
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 a
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): TCol
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,
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 t
>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
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 subfo
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.
>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 li
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 learn
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
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.
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 compil
>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
{$IFDE
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 opti
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 yo
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 p
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 n
ing 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@list
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
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
> sev
f
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 d
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-platf
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
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
>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
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
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.
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
s
Sent: Wednesday, June 14, 2017 11:54 AM
To: 'FPC-Pascal users discussions'
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 noti
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 us
enhuys
Sent: Wednesday, June 14, 2017 8:29 AM
To: fpc-pascal@lists.freepascal.org
Cc: James Richters
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
>> 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+agg
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/c
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
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
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
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.
Tuesday, June 13, 2017 10:16 PM
To: 'FPC-Pascal users discussions'
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 sh
Behalf Of
Stefan V. Pantazi
Sent: Tuesday, June 13, 2017 9:25 PM
To: FPC-Pascal users discussions
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, th
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 targe
>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
>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 Lazar
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 ID
>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
-
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
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
There is a minus sign in the call:
agg^.attach(@graph_buffer
users discussions'
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.
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 con
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
---Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of
Stefan V. Pantazi
Sent: Monday, June 05, 2017 6:19 PM
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
How did you build/get freetype.dll? If it was
-boun...@lists.freepascal.org] On Behalf Of
Graeme Geldenhuys
Sent: Monday, June 05, 2017 2:25 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
On 2017-06-05 03:12, Stefan V. Pantazi wrote:
In my experience, the one dependency that AggPas has potenti
ccrt,
Sysutils,
Fpimage,
Fpwritepng,
Agg_2d,
Agg_Basics
James
-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of
Graeme Geldenhuys
Sent: Monday, June 05, 2017 2:25 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementi
On 2017-06-05 03:12, Stefan V. Pantazi wrote:
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 t
On 2017-06-04 23:30, James Richters wrote:
to run them I get a "system error: The Program can't start because
MSVCR71.dll is missing from your computer.
AggPas definitely doesn't require such a library, so your program must
be using something else that pulls that dependency in.
Regards,
Gr
On Behalf
Of Stefan V. Pantazi
Sent: Saturday, June 03, 2017 12:45 PM
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
I seem to have some problems with logging on the bug tracker. I've used it
in the recent past a couple of time but I am unable to
l [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf
Of Stefan V. Pantazi
Sent: Saturday, June 03, 2017 12:45 PM
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
I seem to have some problems with logging on the bug tracker. I've used it
in the re
The easiest workaround I could figure was to add a parameter to the
Agg2D object constructor. That should, in theory, allow the use of any
pixel format available in AggPas.
The ptcpas/ptcgraph units I used are the ones that came with fpc 3.0.1,
there was no need to download anything. They work
On 2017-06-03 17:45, Stefan V. Pantazi wrote:
Also, for the example
to work, the agg object constructor must be modified as well, I included
all the info in the example header.
I noted the remarks on the image buffer format being hard-coded for the
Agg_2D unit. I'll make a plan for improving t
I seem to have some problems with logging on the bug tracker. I've used
it in the recent past a couple of time but I am unable to log on for
some reason. I will try later to create a new account and submit a fpc
doc bug report.
At any rate, I attached the updated example based on Nikolay's rec
On 06/03/2017 01:52 PM, Graeme Geldenhuys wrote:
On 2017-06-03 01:56, Stefan V. Pantazi wrote:
http://pascal.net.ru/PutImage+(en)
[...]
"BitMap is an untyped parameter that contains the height and width of
the region, and the bit image that will be put onto the screen."
[...]
Could you file
On 2017-06-03 01:56, Stefan V. Pantazi wrote:
http://pascal.net.ru/PutImage+(en)
[...]
"BitMap is an untyped parameter that contains the height and width of
the region, and the bit image that will be put onto the screen."
[...]
Could you file a FPC Documentation bug report and ask that this
i
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
Have a look at the agg_2D unit. The agg_2D uses ..
agg_pixfmt ,
agg_pixfmt_rgba ,
..
Therefore, the rgba format is pretty much baked in. That is to say that the
constructor of the main object Agg2D uses
I literally just sent a reply with the solution. I had to guess the
width and height were longints. Your message confirmed it. I attached an
updated version of the test program, the old one had a few typos.
Thank you for your work on the ptcpas, I found it very useful for my
projects.
On 06/
On 05/31/2017 02:51 PM, James Richters wrote:
I was doing some tests with Putpixel and that seems to be a word in the format
of RGBA with 4 bits each.I would think putimage would use the same format,
but I haven't tested that yet.
I'm still a bit confused by putimage, since it only has a
do some experiments with it.
James
-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of
Stefan V. Pantazi
Sent: Thursday, June 01, 2017 9:47 AM
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
Have a loo
age-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of
Graeme Geldenhuys
Sent: Wednesday, May 31, 2017 1:17 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
On 2017-05-31 18:03, Reimar Grabowski wrote:
I'm not s
huys
Sent: Wednesday, May 31, 2017 1:17 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
On 2017-05-31 18:03, Reimar Grabowski wrote:
>> I'm not sure what that's called
> RGB565, maybe?
And AggPas already has sup
On 2017-05-31 18:03, Reimar Grabowski wrote:
I'm not sure what that's called
RGB565, maybe?
And AggPas already has support for that pixel format.
Regards,
Graeme
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.
On Wed, 31 May 2017 10:47:40 -0400
"James Richters" wrote:
> It's a word with:
> 5bits red, 6bits green, and 5bits blue like this:
>
> RGGB
>
> I'm not sure what that's called
RGB565, maybe?
R.
___
fpc-pascal maillist - fpc-pascal@lists
Sent: Wednesday, May 31, 2017 7:52 AM
To: 'FPC-Pascal users discussions'
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
I was doing some tests with Putpixel and that seems to be a word in the format
of RGBA with 4 bits each.I would think putimage would use the same form
-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of
Graeme Geldenhuys
Sent: Tuesday, May 30, 2017 8:19 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
On 2017-05-30 22:37, James Richters wrote:
> Putimage()
On 2017-05-30 22:37, James Richters wrote:
Putimage() takes
Initial X position
Initial Y position
Pointer to beginning of memory bitmap
In that case the AggPas code should be even faster, because PutImage()
only want a pointer to the bitmap data - thus no need to go through the
slow FPImage
1 - 100 of 103 matches
Mail list logo
